Deja Entendu
Deja Entendu
What is Deja Entendu?
Deja Entendu (working title) is an amateur game engine that was started in an attempt to do several things:
- Cross off another item on my bucket list, namely creating a game engine (along with a game for it). Other items include creating an operating system and writing my own programming language (which, incidently, is also being covered now by Deja Entendu)
- Learn a new language. At the beginning of a data structures class, I asked if I could do the class in C++ rather than Java, as I knew I could implement many of the data structures in java without difficulty, and C++ would be a new language for me. Unfortunately, I eventually reverted back to Java, but after the class was over I decided to actually site down and learn it. This is what this project is for.
- To learn new technologies. SDL, OpenGL, DirectX and a variety of other technologies/system will incorporated into the game engine. This requires a great deal of work, as each system has its own guidelines and usage procedures.
- To give myself a platform to start work on other projects in the future. For example, the game engine will allow me to experiment with different game ideas as well as other theoretical information technology concepts, that may or may not relate to the game engine. The scripting engine I’m writing for example, is being written as a seperate entity, for easy integration into other projects if needed.
Deja Entendu has plans to include all the tools I will need to develop a game. This includes, but is not limited to:
- Scripting Functionality
- Toolset that includes tools for Modeling, Texturing, Sound development, Effect creation, etc.
- The engine itself: Renderer, Networking, Security, etc.
It is an on-going project and I don’t expect to be even half completed for at least another year. Work on it fluctuates back and fourth, unfortunately.
Completed Tasks
- A basic OO scripting engine was created called Amateura. This was to be used for all game logic and functionality for the engine. After some initial implementation tests, it sits dormant, unused for the time being. The same requirements that annoy me with implementing the Lua VM also plague Amateura (although, to a much more limited degree) so it was decided that implementing engine functionality along side the scripting engine would be inneficient. A bug was also found later in testing that limits the use of the engine as well but I have been occupied with other engine tasks. It will be fixed and put into use eventually, if not for game logic, then as a particle engine scripting language.
- Renderer. While not entirely completed, the renderer has a lot of what I need implemented, enough to start work on a game when all other functionality is built up. Recently, texturing was finally added in (albeit, only basic texturing support. I don’t believe textures with alpha channels will work yet) which is allowing me to make advancements. Lighting has still not been implemented but that won’t initially be a game requirement.
- A 2D collision engine, Chipmunk Physics, was also recently implemented into the engine. While the ultimate goal was to create a 3D game engine, Chipmunk will allow for 2D/3D hybrid games where the game area will be constrainted to 2D space but the visuals will have all the free roam of 3D space. This technique has been used several times before and each time it usually plays out very well.
Current Tasks
- A packaging system is in the process of being implemented. This will allow all game assets to be packaged into single file packages, similar to JAR files or U files from the UnrealEngine. When a package is loaded, all assets access will be controlled from the package manager. This is an optional requirement of the engine as basic asset functions will be available for use but the package manager will simplify things and allow a “pre-load it and forget it” style of programming that will increase efficiency.
All assets can be retrieved from packages by specifying the package the asset exists in and the name of the asset you want to access. For example: “myPackage.myModel” and the type of asset being loaded will often depend on the context but assets can be directly pulled out with direct calls such as “GetModel” or “GetSound.”
- The finalizing of architecture. Up until now I’ve been loading models onto game objects through the applications main function but an architecture should be finalized which will allow me to focus control on a particular part of the engine. Currently, I believe this control will center around game objects in that they will control all model loading and rendering. The renderer is a static class at the moment and I would really like to turn it into one class to be initialized by the application however I’m not sure what route I can take to allow the individual game objects control over how they render without making certain things generic, passing things back and fourth, or having vectors of data that the main application will use to load the right setttings for each game object.
- Some basic gameplay concepts are being worked on. Right now “test” models for the player and game objects are being worked on as well.
