This first iteration of the engine doesn't have many features, who am I kidding hardly any, but it's a start of what I want to call the Heatwave Engine.
With all the projects at Filmstorm, I've managed to find time to work on something that has been on my mind for a while, a custom in-house engine. I have spent a long time building custom features for engines like Unity and Unreal Engine to get the results. I have also spent a lot of time helping the community by developing tutorials and resources that help inspire development and ease creators into coding in their favourite engines.
At the end of 2019, we had a massive heatwave in Canberra, causing the terrible bushfires around Australia which lingered for a long time. Like most people I was in the house with my family for many days and was left looking at the computer to do next. I started tinkering building in C# building a basic engine which loads static models and lights them, not very impressive, but still a start. I personally prefer C# to C++ as it allows me to program faster and with less programming headaches (C++ is still great though).
This first iteration of the engine doesn't have many features, who am I kidding hardly any, but it's a start of what I want to call the Heatwave Engine. My aspirations for the engine are somewhat similar to what has been done with the Source Engine from Valve. The original Source Engine has been used by many studios since it's inception in 2006 with the port from GoldSrc which was a modified version of the id Software's Quake Engine.
The goal of my Heatwave Engine is to ship a working FPS title by the end of 2020, with features such as:
The iteration speed of the engine is one of the most important aspects that I want to focus on in the development cycle. Imagine opening the engine, loading the map you've been working on and just place objects, write and execute code there and then, no need for recompilation of the engine to account for the changes. I want as much to happen in what would be the "Game Window" and only recompile the actual engine side if we change the underlying codebase i.e. build a new shader or engine system.
For the first project designing the engine to allow for smooth manipulators and placement tools or creating the game world would make it easy, perhaps enabling the editor tools via an in-game terminal system would allow for easier debugging, so I can play the level and if unhappy with a particular placement of a wall, for example, could then quickly in a few keystrokes, load the tools, reposition the wall and re-test the area, without exiting the play mode. This would be extremely convenient and speed up development time dramatically - as most editors require a full reboot of play mode in order for changes to be saved.
I'm aiming to develop the engine and update the Dev Logs each week on how I go with this project as well as create video logs to show the development progress.
Check back soon for a preview of the Heatwave Engine, and a game design document overview of what's planned for the FPS.
Thanks for reading the start of the great adventure of the Heatwave Engine.
Join the newsletter to receive the latest updates in your inbox.