QuickStart Engine

Messaging System

I wrote to much on the forum regarding this topic to do this again in detail.
Here is a short summary:
* Bloated, way to complicated, user unfriendly, inefficient, defeats all OOP concepts throughout the QSE.
* The main reason having this system was that it would make multithreading easier - this just not true. Xna gives you basically an Update() and a Draw() per frame. The Draw() is practically impossible to split into multiple threads except for some very special tasks like culling - which can't utilize the messaging. Update() normally implies input processing, physics update and collision detection, although the last two tasks can be multitasked I don't see an easy way to utilize the QSE messaging system. Even if we could, the parallel extensions for .NET would be probably a much better choice. The only really useful background task would be loading content especially in a paging environment - again no use of the messaging system.
A small side note:
I converted one of my scenes to QSE; classical RPG scene, big terrain, lots of static outdoor objects (no vegetation yet), few dynamic meshes...The most common condition in games (RPG, FPS, RTS whatever) is that the user moves the mouse and has at least one key/button pressed, so the point here is that we have at least one mousemove and more often the mousemove + keypress per frame. QSE generates some internal messages per frame as well (like 'getheight'). So we end having 2 or easy 3-4 messages per frame. The invocation list of the message handling EngineMessageHandler delegate had about 3000 entries in its invocation list - so it had to invoke over 3000 functions per frame! Not to mention that the invoked functions (mostly handlers inside BaseEntity) have a function traversal chain with switch statements and enumerators, so in total we have 7-8K function invocations per frame per message! If we have say 3 messages it sums up to >20K function invocations per frame!

I suggest:
1) Don't generate automatically any messages at all. Have initially an empty delegate and let potential message consumers register them.
2) Don't let the BaseEntity handle any messages at all; instead let specialized entities which need some messages register a handler.
3) Optionally but not important, we could additionally divide all messages into categories and have one handler per category (input system, camera, etc)



Entity System and overall QSE parts interaction

* Some very specialized behavior is implemented in the very base class. The functionality there can really mess up the end user application e.g. if somewhere a message is generated which is consumed by the BaseEntity one could get unexpected behavior of its specialized entity which received this message.
I suggest: move the specialized implementation to specialized entities/components which really need it.

* The current Entity-Component System is not very intuitive: Everything is an entity except if its a component in which case it has to be attached to an entity.
* Its OK to have a basic 'glue' holding our system together but there must be clear definitions what other parts are or should do.
I suggest: rethink do we really need components? Do we have to attach components to entities in order to apply special behavior? Cant we have 'controlers' instead which have attached entities and control/change their behavior? Its also desirable to have some elements in the engine which are not entities like the camera which first crosses my mind.

* there are QueryForRenderChunks()which apparently do nothing all over the place although there are also few places where it is really used
* The same function is implemented in multiple classes without a common interface
* Therefore it is not clear how to approach Rendering, through a rendercomponent or simply by accessing the AllocateRenderChunk() of the GraphicsSystem. Just look at the mess inside BaseEntity/QuadTree/Terrain QueryForRenderChunks implementation to get the picture.
* Why do we have QueryForRenderChunks()at all if the implementation violently accesses the GraphicsSystem? So either drop the function or force updating GraphiscSystem internall data only through this function by making the data private and using some param or return value of the render chunks query.
* The standard Xna DrawableGameComponent pattern is not used so each component producing some visuals must send the vertices to the QSE graphics system which accumulates them and sends to GPU during Draw(). Although the RenderChunk is recycled from a 'pool' the vertex List holding the vertex buffers is recreated/cleared per chunk per frame!
This approach also makes extremely hard for a component to control anything except the vertices information (e.g. hardware/shader instancing, static vs dynamic buffers etc.)
I suggest: Unify the QeryForRenderChunks through an interface and pass a RenderChunk as a parameter or return value. Don't allow anyone outside the graphicssystem to access the renderchunks. That said one could see that in such a case we would again have the very same Xna's DrawableGameComponent pattern so maybe the best solution would be to revert to this?

* some parts of the engine are deciding instead of the user about certain application behavior and don’t even allow to change things. MouseHandler comes first to my mind. This class sets the mouse pointer to invisible and resets its position to 100, 100 every frame? What if I want to use a hardware cursor on screen? Is it hard to imagine I want let the end user (player) click on something on the screen, press a button, pick up a game asset, draw selection rectangles etc…???
I suggest: If it’s in the engine – it has to be (re)usable and it should be as generic as possible.
If it is something exclusive it must be parameterized or/and changeable. We have only one mouse and keyboard handler in the QSE so the user expects he could use them as they are and not only in one specialized way.


Input handling

I see two problems here:
1. The Xna framework already has build in access to Mouse, Keyboard and Gamepad inputs (not sure if Joysticks are interfaced through the GamePad class though). So why bother with the complicated input system when a user can pool the input state with something as simple as Keyboard.GetState().IsKeyDown(key)?
2. The whole QSE input system is user unfriendly:
* you first register a handler through the config Xml,
* you manually add input listeners (this.inputs.AddInputListener(MouseButton.Right);) etc. To do so one must have a central place for this code to make it maintainable
* If you miss adding a listener but query for it you will either get a runtime exception or not get the input message
* Because of the current QSE messaging system we get far to many function invocations per frame
* you need to override OnGameMessage() to process the inputs and know about the insides of the QSE entities and components since they can consume the very same messages and mess up your game, or one has to make workarounds like:
- process inputs inside the Update() where you would again pool the states like this.inputs.IsDown()- identically as with the pure Xna approach !
- Of course the risk of using same Messages which have implemented consumers inside the QSE still exists so you have to override and never OnGame_Message and never call base.OnGame_Message(). Isn’t it funny that in order to get something done you absolutely must override the base class functionality even if your override is an empty function?

What the end user really needs is:
a) not to register InputListeners but to have automatically all 'listeners' running so he could simply pool the input states for any key/button needed.
b) Registering a delegate for specifc listeners would be nice (read as: connecting keybindings to function pointers).
c) A 'listener' should never ever generate and dispatch messages to the whole system, instead 'dispatch mesages' only to entities/components which requested them which is actually the same as under b)

I suggest:
1) Refactor and reduce the whole Input system so it Don't generate automatically any messages at all. Have initialy an empty delegate and let potentiall message consumers register them.
2) Don't let the BaseEntity handle any messages at all, instead let specialized entities which need some messages register a handler.
3) Optionally but not important, we could additionally divide all messages into categories and have one handler per category (input, camera, etc)