HierArch Emporium

[TechLord]

Just signed up for Steam to vote for In-Verbis-Virtus on Steam Greenlight. I started snooping around and ran into RPG Maker VX Ace. It brought back some fond memories of Final Fantasy for the Nintendo 8 Bit Game Console. This little discovery reaffirms my belief there is a deep need for a full powered modern 3D Adventure Construction System. As soon as I figure out a means to freely capture video footage from the UDK I'll start some VLOGS to show in game progress on Diegesis PI and other stuff.

[TechLord]

This sound very interesting. Visual cues for health and stamina are great. Now, the menu for items and overall equipment could be entirely replaced as well. Now, depends what's your design goal. When designing an idea, I often tend to look back at how things were done with little technology.

As far as my design goals go, my strategy is to design a GUI framework that I can gradually build-up features as needed. The system will support both 2D and 3D. The Canvas is capable of drawing a traditional 2D GUI gadget sprites and this gives me a quick start. My minimum requirement in 2D is to produce a simple button, the maximum requirement is to produce an editable textfield box. My GUI designs build composite gadgets (comboboxes, listboxes,etc) based on these two gadgets so they will be enough. I'm taking most of notes from here.

After the 2D requirements are completed I will expand on the 2D implementation to support 3D. The challenge here is that I've had plenty of 2D GUIs to learn from, not many 3D systems. TegLeg's example demonstrates the concept in its simplest form.

At the end of the day, I simply didn't want bog myself down with programming systems that are not related to the Game Entity Customization Systems. But, some form of Traditional GUI (checkboxes, sliders, textfields) is required for Customization Editor, so, its a double-edge sword. I've taken a short break from writing the Master Server Complex/Game Server Control Protocol 1.0 to start writing Diegesis PI (Player Interface) which is proving to a good starting point for digging into UDK interactivity systems.

[FraktalZero]

This sound very interesting. Visual cues for health and stamina are great. Now, the menu for items and overall equipment could be entirely replaced as well. Now, depends what's your design goal. When designing an idea, I often tend to look back at how things were done with little technology.
Can't wait to see more soon.

Cheers.

[TechLord]

As you know, UDK doesn't offer a Traditional GUI system natively in favor of using Scaleform. The lack of a GUI is somewhat unexpected, but, not totally uncommon with Game Engines. Fortunately, I've written several UI in various programming languages over the years and elected to create my final iteration of UI using UDK's available input, collision, triggers, 3D models, particle effects, and audio emitters. My previous project involved a component-based 3D UI design using input, collision, triggers, 3D model components so using UDK for this purposes is not reaching too far out of my design goals.

MAUI written in DBPro

So for the past week, I've been working on a Diegetic GUI System built on top of the Player Classes. Diegetic is a cool buzzword which means user interface elements exist within the game world (fiction and geometry) so the player and avatar can interact with them through visual, audible or haptic means. I'm developing OverArc's UDK GUI System with the philosophy that the entire game world is a user interface, and it incorporates all of the techniques described here. RPGs are often heavy UI dependent with menus etc usually powered by traditional GUI systems. Well, OverArc is getting a non-traditional UI.

[FraktalZero]

I got my name on something cool! Yeah!

[TechLord]

Deeper research into the Network Replication revealed the Server Packages process. With this process, the Game Server can allow Clients to download Content Packages. Taking this into consideration, a Master Game Server will be implemented to distribute Content Packages and compliment the Master WWW Server in its role to provide a centralized Content repository. The Network Topology now known as the Master Server Complex. From this point forward, the codename for the Master Game Server is FRAKTAL0, as credit to FraktalZero of UDK Forums for his suggestion.

I've also concluded that the JSON will be the exchange format of choice for encoding linear and hierarchical data. Until now, I was dead set on using XML, but, JSON is supported by UDK out-of-box. I picked up JSON in about 10 minutes with the JSON Tutorial on W3Schools. Its sorta funny that I never used this with all the javascript coding I do. I got all excited over the fact JSON is smaller than XML, and faster and easier to parse.

JSON is the the format of choice for my Game Server Control Protocol (GSCP). GSCP in a nutshell: a HTTP-Layer Protocol Inspired by SIP, that uses ordered Sequences of HTTP Transactions (Request/Response Message Pair) for multipurpose communications and control between Game Server to Master Server Complex. GSCP was conceived to provide a clean, structured, and standard means of handling communications between Game Client and Master Control Complex over HTTP TCP/IP.

[FraktalZero]

Hope to see more from this project. This seems very interesting. So keep us updated, mister!

[TechLord]

I don't know too much about programming, but I suppose it could work the same way Multiplayer games work, with Replication. Files wouldn't be sent, but rather called from the client's installation if that makes sense?

That's an excellent suggestion, FraktalZero. A Game Server could compliment the Master WWW Server in handling content distribution. I'll dig into the inner workings of UDK's Network Replication system. If this is viable solution, I will modify the Network Topology to include a Game Server to handle this task. The Master WWW Server will become the Master Server Complex.

bobble heads

Awesome! That would make GREEDY BLASTARDS even more comical.

[FraktalZero]

I don't know too much about programming, but I suppose it could work the same way Multiplayer games work, with Replication. Files wouldn't be sent, but rather called from the client's installation if that makes sense?

And thanks for liking big bobble head fat zombie lol

Cheers.

[TechLord]

I like the concept. Keeping an eye on this
Cheers!

Thanks FraktalZero. I like your 'Big Head' Character Art Style. That Art style would have been perfect for my Comical Cash-Tournament Shooter: GREEDY BLASTARDS!. The highlight of the game was Player's creating a cartoon Big Head of themselves (with a front/side photo they submitted) attached to an avatar with 100s of wacky outfits and 100s of zany weapons to choose from. Now, that I think about it, I could re-animate that project within a week's time with the UTGame Template. Nah, I've been subconsciously planning OverArc for over a decade+. I must develop OverArc before I meet the ultimate the game maker.

In regards to OverArc Development, I ran up on my first hurdle this weekend. UDK presents a few challenges with reading/writing data to disk. I spent all weekend extending the TcpLink Classes and researching strategies to read/write data. I'm using UDK's TcpLink to provide a means to communicate to a Master WWW Server (and possibly other Game Servers and Clients) via HTTP. This network operation is desired to transfer media & data files from Master WWW Server to support World Persistence and Updates/Downloadable Content within the Game. Sending and receiving Files via HTTP is 100% functional at this time thanks to following references: 1, 2, 3. However, reading/writing data to disk is limited in UDK for what I suspect to be security (anti-hacking) reasons. I have yet to find a means to access raw binary data to read/write cached media objects. Still looking.

To sort out this situation I've listed the Data Input/Output methods I found available in UDK
(Please advise if some are missing. thanks):

Local
+ Disk
.. Read
... Engine Configuration *.ini ASCII Files
... Native Loading Object
.. Write
... Game Installer Application . Self.Installer Engine and Content
... Content Pack Installer Application . Self.Installer Content Pack
... Native Saving Object
... Savegames Are Possible In The UDK (Sapitu.ini) ASCII
... ServerPackages (UDK Game Server)
+ Memory
.. Read
... Cached Data from TcpLink HTTP Request/Response ASCII or Binary
.. Write
... TBD

Remote
+ Disk
.. TcpLink HTTP Request/Response
+ Database
.. Read
... TcpLink HTTP Request/Response

Taking that list into consideration I established the following Input/Output Strategies for OverArc

Strategy: Acquisition|Source|Storage|Access

1. Content Packs
   • Strategy: Manual|Remote (QA approved)|Disk|Write
   • Type: Media, Logic, Data Files
   • Formats: Binary|Ascii
   • Purpose: Provide self-extracting/installing content package for media {model parts packs/skin packs, music} files to disk, loaded during Game Level Load. Will implement super top secret Asset Proxy System.
   
   
2. ServerPackages
   • Strategy: Automatic|UDK Remote (QA approved) |LocalDisk|Write
   • Purposes: Uses Master Game Server to download Server Packages.
   
   
3. GameMaster Save/Load
   • Strategy: Manual+Automatic|Remote Database|Memory|Write+Read
   • Type: Assembly, Dialog, Logic
   • Formats: Ascii SQL
   • Purpose: Design-time. Game master can pre-create or create adventure in real-time during game play. This mechanism allows Query/Update to MWS Database Game-world Construction Data maintain Persistent Data.
   
   
4. Game-world Construction Data
   • Strategy: Automatic|Remote Database|Memory|Read
   • Type: Assembly, Dialog, Logic
   • Formats: Ascii SQL
   • Purpose: Play-time. This data is queried from MWS Database and formatted on demand for Game construction and Modular Prefabs Assembly. Require a Parser (written in Unrealscript) to data in the HTTP Body into Objects or execute UnrealScript functions to spawn and assemble Game-world.
   
   
5. Player Game Save/Load
   • Strategy: Manual+Automatic|Remote Database|Memory|Write+Read
   • Formats: Ascii SQL
   • Purpose: Play-time. Query/Update to MWS Database maintain Persistent Data of
   
   

[FraktalZero]

I like the concept. Keeping an eye on this
Cheers!

[Chosker]

heh glad to hear you like my project

I know the feeling, Elium used to live in an old and abandoned engine (Nebula2) which was really a graphics engine to build an actual 'game engine' with. After ~5 years with and without programmers I left it all behind and moved to UDK to program it myself. and I must say starting again was actually a step forward and not a step back.
so good luck again!

[TechLord]

btw I must say this looks like an interesting project, if only maybe too ambitious

Chosker, thanks for your reply (I've been secretly tracking Elium - Keep up the awesome work!)

I have to agree with you. OverArc was toooooo ambitious a few months back, especially when I tried to develop the Game Engine from scratch. I failed to take heed to good advice: 1) program games, not game engines; 2) don't try to develop a MMO. It was exciting in the beginning but, after several redesigns, core library changes, and no playable game mechanics, the excitement died out. I don't feel like a complete failure, I learned tons about programming game systems in C++ and I'm bringing that experience to UDK. With UDK, I can focus on programming fun stuff like game play and see the results instantly. I'm using all of UDK's functionality out-of-box with only a handful of additional systems. UDK will help me regain 3+ years of my life back.

[Chosker]

so hopefully mouse/keyboard input conversion to touchscreen will not be too painful.

you can use different PlayerControllers based on the platform, I believe the RTS UDN gem hints as to how to do it.

btw I must say this looks like an interesting project, if only maybe too ambitious
good luck!

[TechLord]

Be great to get this to work between multiple OS's - PC, Tablet etc.

slowJusko, thanks for your reply. My intentions are to deploy OverArc to all Platforms supported by UDK with initial focus on the PC. I have yet to develop an App for Tablet or mobile devices, so hopefully mouse/keyboard input conversion to touchscreen will not be too painful. OverArc is virtually divided into two interfaces: Editor and Game. I anticipate the Editor Interface to be cumbersome, but, functional on a mobile device simply due to screen size and input controls. However, a Game should run just fine.