 - Main/News - About - CVS - Docs - Downloads - Screenshots - Team  - Compiling with Visual C++ 6  - Links - SourceForge.net Project Page |
Final Frontier Trader Design
UDHS - User Defined Hook System
The UHDS is a tool that simplifies the work of game programmers within a certain genre. It is intended for developers only and is a very effective simulation of the main game loop. The base simplified functionality of the UDHS is to provide an interface where the developer(s) can integrate their own hooks for processing that are later called by the UDHS at specific intervals and in specific order, while processing things of its own.
UDHS as a system is not very complicated, since it is a very simple idea but the possibilities are endless. Concepts such as AI-frequency, precedence, etc. are eliminated by the system. The developer(s) can solely concentrate on providing the functionality of the game without actually worrying how it all sticks together.
- Why UDHS? -
The use of UDHS is optional, it is not a must to develop games, but it is a great help. A developer working with a game might frequently come upon problems such as where to implement a certain method, what the best way to process AI is and exactly when collision should come in.
The simplicity makes it very easy for a developer to actually produce functions, since all interaction between different processes, such as AI, movement and other base-line methods such as drawing and music.
- Base structure -
The structure of the UDHS is as follows:
2. UDHS::CPUAi() - Processes the NPC AI at a determined interval
3. UDHS::CPUMove() - Processes all NPC movement with the Ai
4. UDHS::PLMove() - Processes player movement
5. UDHS::PLAi() - Eventual player Ai to be processed at an interval
6. UDHS::Draw() - Draws all the data onto a screen surface
7. UDHS::Music() - A function that plays music (sounds not included)*
8. UDHS::Calc() - A function that calculates values each cycle.
(*) Sound effects need to be played in one of the other functions.
All above functions prefixed with an 'a' are attach functions.
The UDHS example presented here is a main loop of a Real-Time shooter but the UDHS system is far from limited to this. Every UDHS unit created must always pass a reference to itself whenever one of the functions finishes, which may seem weird. The actual use of this is when multiple UDHS systems are integrated. Let me explain this by putting up another example:
Say that the UDHS::Music() calls a function called CheckTriggers() that checks to see if certain conditions are met to see if music should be changed, stopped or altered in any other way. Maybe the UDHS::Music() function also calls CalcTriggers() that does processing based on the triggers calculated in the CheckTriggers() function. This means that we have two music-related functions in the music processing thread (UDHS::Music()). This is where another UDHS system should be integrated, to further simplify code. A UDHS system for Music calculation, a UDHSMusic. Now the UDHSMusic class has multiple static variables that manage processing of music, easier put the UDHS class represents the two functions CheckTriggers() and CalcTriggers() in one integrated system. So every time the UDHS::Music starts it calls the UDHSMusic::Main() which, when finished operating, returns a reference to the UDHSMusic object holding all the important music data.
Virtually, a UDHS system can consist out of an infinite amount of integrated systems that cooperate and manage various aspects of a game. To put forth another example, imagine that there exists a UDHSSystem class that manages all system processing that isn't fit for the main loop, now the UDHSSystem::Main should then call the UDHS::Main and save the reference dropped by UDHS::Main that is later used to manage various processes.
- UDHS - Ultra Dandy Helpful Shizmabob -
It's only a developers imagination that sets the boundaries for how far and how helpful a UDHS system can be. While the idea may seem complicated, the base functionality truly isn't. It cuts game code development and problems by at least 30%. Many problems vanish, no new come. There is no actual increase in debugging either, since all that the UDHS does is call user functions that are to be debugged by you anyway. That is all.
If you wish to contribute, email TomT64.