![]() & Mystique Entity™ System |
||||||||||
------------------------------------------------- | ||||||||||
|
![]() 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:
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:
Provide Modeler & Animators:
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:
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. |
Announcement
Collapse
No announcement yet.
HierArch Emporium
Collapse
X
-
HierArch Emporium
Tags: None
-
Be great to get this to work between multiple OS's - PC, Tablet etc.
Comment
-
Originally posted by TechLord View Postso hopefully mouse/keyboard input conversion to touchscreen will not be too painful.
btw I must say this looks like an interesting project, if only maybe too ambitious
good luck!
Comment
-
btw I must say this looks like an interesting project, if only maybe too ambitious
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.
Comment
-
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!
Comment
-
I like the concept. Keeping an eye on this
Cheers!
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
- 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.
- ServerPackages
- Strategy: Automatic|UDK Remote (QA approved) |LocalDisk|Write
- Purposes: Uses Master Game Server to download Server Packages.
- 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.
- 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.
- 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
Comment
- Content Packs
-
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?
bobble heads
Comment
-
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.
Comment
-
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.
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.
Comment
-
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.
Comment
Comment