HierArch Emporium

[TechLord]

& Mystique Entity™ System
HOMEBLOGNEWSFUND		-------------------------------------------------
Description HierArch Emporium is a 3D Shopping Mall powered by Unreal Engine 4. Its a 3D Asset Store showcasing Modular Entities designed with the Mystique Entity™ System for use in UE4 and other 3D Engines/Apps. HierArch Emporium features an Editor/Sandbox/Arcade in which Game and Film Producers can: Navigate in First Person. Interact with Exhibits and Booths in a 3D Open World. Preview and assemble interchangeable parts into entities manually, semi-automatic with collaborative online assistance from Artist, or Fully Automatic assembly with the Random Assembler. Live Test Assets prior to purchase in The Lab; Test animations, physics, visuals: particles, lighting, Tweak and Test. Save Assemblies & Modifications to account for import into Application. Demo Assets prior to purchase with game mechanics in The Arcade. Select Assets, Create Bundles (Sub Carts for future purchase), Add to Shopping Cart for Purchase via Online in The Shop, or Visit the Web Browser version to purchase. All Content that comprises HierArch Emporium's 3D World is FOR SALE! All assets are for functional use in other 3D Games & Applications. Although, the Emporium primarily operates as a Marketplace, the Arcades provide a source of gaming entertainment. In addition to the sales of Assets, I'm reviewing 42 other strategies to monetize these areas, to include one of my own: 3D Treasure Hunts. For more information about the Mystique Entity™ System, review information in right side bar. Team Name: HierArch Consortium Team Structure: F.L.Taylor aka TechLord Project Manager, Game Systems Programmer\Scripter, Web Programming, Database Programming Royalty Structure Four (4) Person Seat Limit Royalty applied to All Emporium Sales. Production Quota and Quality Requirement to retain Seat. Royalty Percentage (%) Chart: 5% Epic Gross Revenue 15% Seat 0 (Me) 20% Seat 1 20% Seat 2 20% Seat 3 20% Seat 4 Previous Work: Name: F.L.Taylor aka TechLord Title: Game Systems Programmer/Web Application Programmer Portfolio: Hit Point Quest Talent Required: 4 Highly Skilled Modeler/Animators! The HierArch is a unique concept. I'm assembling a 4 Person Team of non-traditional 3D Artist open to the idea of: Research & Development of new art production workflow technique for developing the Mystique Entity™ System. Production of Assets specifically to be sold to the masses in a online marketplace. Royalty-based Partnership of 20% on ALL products and services sold in the Emporium. Non-exclusive End User Licensing Agreement. These individuals form The HierArch Consortium responsible for: Establishing Specifications for the Mystique Entity™ System. Authoring High Quality Parts Assets Supply for sell. Performing Quality Assurance for externally generated 3D Asset Submissions. Other administrative tasks to ensure the Mystique Entity™ System adoption, documentation, etc. Required Skills: Professionalism High Quality Output Organic, Mechanical, and Structural Modeling Texture & Materials Skeletal & Keyframe Animation Knowledge of UE4 Persona, Blendspaces, Morph Targets, Sockets Website: Temp Home Contact: E-mail: developer@arcadekomodo.com Skype: techlord_on_skype		Mystique Entity™ The Mystique Entity™ System is the brand name for the Universal Modular Entity Construction Hierarchical System (UMECHS*) Authoring process. UMECHS* is a system of processes that includes: Specifications Templates: Rig & Base Mesh Version Control Centralized Repository Application Modules: Entity Customization Interface Licensing Body of Administration (HierArch Consortium). UMECHS* was conceived specifically for authoring Modular Entities with Interchangeable Parts sold to the masses via online marketplaces. Motivations are to mutually benefit Artists and Game Devs: Provide Game & Producers: Mass Customization in which Interchangeable Parts can be mixed and matched to create an endless combination of unique Entities. Modular Entities/Interchangeable parts suitable for in-game prefabrication, player customization, destruction/dismemberment FX. Scalable Bundling Options with greater granularity. Design the Bundle that fits their Budget. Provide Modeler & Animators: Managed System for authoring and cataloging templates: Core Rigs & Base Meshes. Distributed Authoring in which the workload is divided between several Artists to minimize production time. Authoring Scalability is which Artists can produce one, some, or all the parts. Artist can even specialize in authoring specific types of Parts. Parts Version Control. Swap out existing or work-in-progress Parts with improved updated versions over a period of time. Maximize Profit potential by diversifying Assets in Scalable Bundles. The UMECHS* Authoring Process is similar to DAZ3D Genesis. It provides a core rig and base body/parts in which a huge range of other 3D Entities can be derived using morph targets, sockets, and material layers. UMECHS applies this methodology to common entity types found in 3D Games: Character & Creature Head/Body Vehicles/Crafts Machines Weapons Architecture Structures Furniture Plants Hybrids UMECHS is a open system in which Artist create new core rigs and base body parts or extend existing ones to evolving hierarchy of styles (ie: Master Rig and Re-targeting Compatibility). There are minimal layers of management for Quality Assurance (inspect and ensure Parts meet the UMECHS* specification and Game/Application compatibility) and Database Entity Base Mesh/Parts in the HierArch Compendium.

[slowJusko]

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

Wouldn't matter where people were or what they were using, that could join in on what ever game system they chose to use on what ever piece of hardware they happened to own.

Interesting...

[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.

[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]

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]

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!

[FraktalZero]

I like the concept. Keeping an eye on this
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 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 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]

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

[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]

I got my name on something cool! Yeah!

[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]

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.