Post Mortem

Project Outcome

One of my main goals was to stay as flexible as I can with every element of the engine. The ability to combine freely every component with any game object enables the designer to stay creative. It is like working in a sandbox environment: the designers should be able to create worlds that I haven’t even thought about by combining the tools I provide. In general, I think that I have achieved that goal very successfully. If the year we are in would be 1992, we could go over into the production phase if we would have a real project.

Tasks left behind

The engine is providing enough functionality and stability to prototype first narratives.

Above all, it is lacking polishing:
  • The scaling of the character does not scale the distance between his head and his textbox and the speed at which he moves (should decrease if he gets smaller)
  • Real multi-layered rendering, right now, I provide the main update method, which renders each game object on top of each other in the same order they are in the XML and a late update Each object and component can be registered to be part of that late update. In that case, their draw call gets delayed after the main update one. The late update order is not that easy to predict, so there should only be a few per scene. The late update is mainly implemented for the text box components, to ensure they are always visible. Real multi-layered rendering would provide tools to set up the drawing order without demanding on the XML order.
  • Audio in a loop plays continuously even after switching the scene.
  • Efficiency: I did not implement an event system at all, therefore most of the objects and components are getting checked at least once a frame. This is highly inefficient and wouldn’t be possible 1992, but nowadays there is enough computing power to concentrate on other things. Retrospectively judged, I should have implement events from the beginning, adding them, later on, looked like having to touch every element again.
  • Resizing the screen causes some problems with getting the actual mouse position.
  • Etc.
But there are also main features missing that I planned to implement originally:
  • Real dialogs: Right now, you can only have sequences. A real dialog system would enable the player to choose an answer to influence the dialog’s outcome.
  • Pathfinding: This system should guide the characters around obstacles and should prevent the player to move his character into the skies.
  • Saving: If the application quits execution, any progress the player had made is lost.

Tasks left behind

From now one, the engine’s design must be aligned with a project’s direction and that is more or less the reason I will not continue working on the engine, as there is no real project, no real game to make. Also, I think I extruded most of the knowledge this task can provide:

  • An engine and an editor is not the same. The engine somehow defines a new file type and knows how to interpret it, while the editor is a convenient tool to create this new file type.
  • Deepen my knowledge in C++: abstract classes, the meaning of object-oriented programming, different programming patterns, etc.
  • “Tell” instead of “cast”: While the third-semester project was done with blueprints of the Unreal Engine, I got used to “cast” an object to a specific class to access it. Naturally, I transferred that habit over to C++ only to realize that it brings in some problems. Researching for an answer was quite quick and all of them were like “That is a design flaw” and it would offend the principles of object-oriented programming. I fixed most of the issues by concentrating on virtual classes.
  • Implement the knowledge I gained out of “Game Programming Patterns” from Robert Nystrom

Resume

After all, I really liked that task. On one hand, it is much less work as I thought it would be: as you can see at the feature list, only a hand full of features can provide enough tools to create a real game. On the other hand, it is much more work to implement a single feature as I thought it would be: Implementing a method that checks if the mouse cursor is colliding with another game object seems to be an easy one until you realize that you need to implement collision handling itself first.

This assignment also cleared my mind of which kind of programmer I want to be: definitely not an engine programmer. My preferences still are AI, Gameplay and procedural generated content, in that order.