It has been a while since my last post, which makes sense since for more than a month i didn't touch the game much (worked on some other stuff and then i was messing with Vulkan a bit :-P). Then i started doing some things that do not really show in images or videos so i decided to wait until i had something to show again.
Lately i decided to put some animations in the game - up until now everything was static. The engine has code for animations, but i never actually properly tested that beyond a quick test almost four years ago when i wrote the code :-P. However it turns out it worked almost fine from the get go (although i need to work on transitions). After that i also worked on the gameplay side on NPCs that chase you and you shooting and killing them. Here is a video from a couple of days ago:
Like i mentioned before, all assets are placeholders - the enemies use the same model as the player's model with a swapped texture.
Previously to create the models in a format that the engine understood i used a command line tool i wrote that parsed a script which described how to convert the model from OBJ files i exported from Blender. That was a bit tedious and error prone, so i decided to write a new tool for editing the models:
This tool keeps all models of the game in a single "project file" and generates the .rtm (model files), .rtt (texture files) and .lil (script files) that the engine needs to use the models. Strictly speaking the script files aren't needed, but the engine doesn't know about different animations, it only knows about which frames to playback which is set up via scripts. The generated script allows any other script to apply an animation to a model by calling a single function. For example to apply the animation walk of the don2 model to an entity ent, the call would be apply_don2_anim_walk $ent. Although this isn't exactly what the script for a monster/npc would call since it is wrapped with some other helper functions that keep the current animation state, etc.
Although the game will be top down, i added a behind the back camera some time ago and it shows how silly the current model looks like:
This was before i replaced the monsters and implemented chasing.
Another thing i worked on was building the game. Since my last post i switched back to Windows (i want to play more games :-P) but wanted to keep using the previous cross compiling setup. To do that, i installed a fresh copy of 64bit Debian into a QEMU image and recreated the native compiler setup for 32bit and 64bit Linux binaries and cross-compiler setup for 32bit Win32 binaries and 32bit and 64bit OS X binaries. Then i made the Debian automatically login to the default user and gave the user sudo access without asking for a password. Then i modified the .profile script that is automatically executed at startup to download a "package.zip" file using QEMU's TFTP server which gives access to a local folder, uncompress it to the home folder and execute a shell script in it. After i had all done, i wrote a batch file that created said package.zip file on the Windows side with the latest engine source code and data files of the game and placed a shell script to be executed from inside QEMU that builds the engine for Linux 32 bit and 64bit, OS X 32 bit and 64 bit and Windows 32 bit and packages the game and files into an archive. Then it copies the archive file to a freshly created QEMU image and shuts down Debian, which causes QEMU to exit. The batch file creates the blank QEMU image, calls QEMU, which downloads the "package.zip", builds the game and places to the newly created image and then shuts down QEMU. After QEMU is shut down, the batch file uses 7zip to extract the contents of the QEMU image to get the 7zip file and places it in a special folder that i can then distribute.
The above process basically allows me to create fresh builds for Windows, Linux and OS X with a single double click which is great for copying it to different test machines i have, giving it to others to test and of course archiving the progress of the game.
Sadly there is a negative here (well, beyond that builds take 10 times more than they would under a native Linux). The MinGW version i'm using seems to have a bug which is why the particle bug i mentioned above exists. Right now i have to replace the generated Win32 exe with something else manually since there isn't a newer version of MinGW on Debian that fixes it yet, but eventually i'll either try to manually build a newer version of the compiler or try to use a different compiler for creating the Windows version of the game.
What comes next is writing a "weapon" system into the game so that the main character and enemies can use different guns. Also i need to fix a few bugs with the chasing code (especially the code that turns enemies towards you which sometimes can cause them to fly... :-P).
You can download the latest build from here (753KB). It contains executables for Windows, Linux (both 32bit and 64bit) and OS X.