Hi all, i'm working on a 3D top down shooter. The gameplay is mostly inspired by Raven's old Take No Prisoners game (ie. top down shooter with FPS-like controls). I haven't yet decided on a name, so i'm just calling it "vamp" (from vampire, see below why). The game is currently in early stages with placeholder art and there isn't much of gameplay yet, but... well, i wanted to share :-P.

Here is a screenshot from the game and the editor (the shots are from Linux, i use a classic windows-like theme for XFCE and GTK2):

Also here is a video i took from the engine today after i added a console:

The editor is brush-based, like Hammer and Radiant (although it has negative brushes which makes things a little easier when making indoor stuff) and it actually has a similar workflow to Hammer (although it is a bit easier to use). Like with Hammer and Source (or Quake and Radiant), the editor and the engine are fully separate and in fact i started writing the editor about three years prior to the engine (for another engine) :-P.

The engine is a simple engine written in C and uses my LIL scripting language (which is similar to Tcl). The console commands you see in the video above are the same commands which are used in the game scripts (the engine is script driven). It works under Windows, Linux and OS X with native backends for each (except Linux where it uses SDL 1.2 - that is because when i started the engine SDL 2 was still in beta, but eventually i'll port it to SDL 2) and has an OpenGL 1.x backend (it even works on an old Pentium 3 with an integrated Intel i850 GPU i have here :-P). There is also some code for iOS and Android with an OpenGL ES 1.x backend, but the code for those hasn't been updated in years and doesn't work. Finally at some point i also made an Emscripten build (using Emscripten's OpenGL 1.x layer) which worked ok-ish, but it was more for the "hack value" than something practical.

About the game itself... as i wrote, it is a top down 3D shooter (for debugging purposes i can also switch to first person perspective - as shown in the video above - but the final game will be top down only). Story-wise things aren't really finalized, when i started i had the idea that you were a vampire hunter storming a castle where vampires and other creatures live and prey on the nearby villages. The idea was that you'd be a Van Helsing-like character (like in the 2004 movie), shooting creatures in gothic-like castles.

Then the Incredible Adventures of Van Helsing happened :-P (actually it happened earlier, i just noticed it some months after it was released on Steam)

Now, the game isn't *exactly* like the adventures of Van Helsing, but still it is a top down shooter (even if mine has FPS-like controls and Van Helsin has twin-stick controls) and the theme was *too* close. So i decided to scrap that theme idea and go with something else.

And this something else is about a tormented character, bound to a higher being, put in a battle between two demonic factions. The game will chronicle your relationship with your captor, who groomed you as a killing machine and uses you as a weapon against the opposite faction. Style-wise the game will have a visual style similar to Gungrave on the PS2 (i'm talking about the "drawn" texture style mostly... and besides, remember, this is top-down shooter :-P).

So far that is the plan anyway :-). If it wasn't already obvious, at the moment i'm more focusing on the gameplay with the visuals and story taking a back seat for until i actually have things screaming, bleeding (well, they already do... but they don't react to that :-P), attacking you and dying (both them and you) :-P. The screaming bit (not literally), specifically, would be a bit somewhat tricky to do since the engine doesn't have yet any sound code beyond stubs to be filled later.

Generally what still needs to be done is most of the gameplay code, all the assets (right now they are placeholders) like world textures, models, animations, sounds, music (although i'm not sure yet if i'll actually have background music or i'll only do ambient sounds) and of course the levels. What is done is the engine (mostly, some bits are missing but those aren't big deals), editor (mostly) and some gameplay code. What i'm working on now is the core gameplay code (ie. what you'll do in a level) and next i'll try to start experimenting with the visual style (i mean, i want to make it look similar to Gungrave, but that doesn't mean i can actually do it :-P the only two styles i know i can kind of do is oldschool Quake 1-like graphics and still oldschool N64-like graphics :-P) and try to make a single small level that will play close to what i think the final game will be - something like a vertical slice of sorts (minus sounds).

If you want to check it as it is now (note: might crash and burn), you can download (link removed, see below). This contains executables for Windows and Linux (32bit and 64bit). The vamp.exe file is a launcher for Windows and the vamp.sh script is a launcher for Linux. The launcher will be eventually rewritten to also work in Linux and allow key rebinding without launching an external editor (currently all it does is to open notepad with the input.lil script file that contains the key binding commands). Under Windows all you need is working OpenGL drivers. Under Linux you need OpenGL drivers and SDL 1.2 (for debian you need the libsdl1.2debian package).

New executable (December 4, 2015): here it is (760K). It now contains Windows, Linux and Mac OS X executables.

Newer executable (March 5, 2016): here is that too (753K). Like above it contains versions for WIndows, Linux and OS X. Read below for the changes.

I worked on the Mac OS X backend... or more precisely, i rewrote the Mac OS X backend from scratch. This was done to remove the Xcode dependency - everything is now built from a Makefile. This also made the OS X code *much* smaller (only a couple of files instead of a bunch of resources, files, classes, etc generated by Xcode) and fixed a couple of issues i had. Also implemented fullscreen mode (although it doesn't change resolution yet) and, most importantly, raw mouse input. I think my engine is one of the few engines on Mac OS X to do raw mouse input since a lot of games seem to be affected by mouse acceleration. This was done by registering a callback with the HID API introduced in OS X 10.5 (and is very badly documented - probably why many people miss it) and checking for mouse motion events there (the button press and release events are still done in the regular event loop).

Another thing that i managed to do today was to setup cross-compiling for OS X from Linux, so now with a single script under Linux i can make builds for Linux, Windows and Mac OS X (32 and 64 bit for all except Windows which only has 32 bit builds since Windows has good 32-on-64 bit support). The .tar.xz i updated in the original post was made using this script. This was also the reason i wanted to remove the Xcode dependency. I used the osxcross project to build the crosscompiler (i also had to build a recent version of Clang because the one bundled with Debian Jessy is too old to be used with the latest OS X SDK).

I also added a cvar to limit the framerate. Can be helpful if you are near the 60fps that the engine updates (e.g you get 70 or 80fps) at and it doesn't feel smooth. It can be enabled with enabling the console with ~ and typing cset fpslimit 60 (or any other value). Alternatively enabling vsync might help, although the only OS so far i've seen vsync to feel good is OS X (where it feels almost perfect). I'll need to investigate that.

Game-wise there seems to be a bug with the particles not spawning in some cases in the Windows version when it is run under Windows (ie. it doesn't happen under Wine). Those are always fun to debug :-/.

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.

I added decals and decided to stress it out a bit by leaving a blood of trail as i walk around:

Decals are basically done from the engine side, except that i need to write the code for importing them from the world files so manually placed decals will show up in the world (which should help to enrich a bit the environments with dirt, cracks, foliage, debris, etc). The editor needs to make decal manipulation a bit easier, but nothing big.

After that the next is making the enemies fire back. Yeah, i know that i wrote above that i'd work on this next :-P, but after having blood puffs in the world disappear i wanted shooting and killing enemies to leave something more permanent (after making the video i made the enemies spray blood in nearby walls when you shoot them :-P).

My immediate ToDo list for the game from a programm PoV is basically:

• Game menu and HUD (the engine side is done and i'll use parts of another project of mine for the scripting side)
• Weapons system (monster and player weapons) and monsters fighting back
• Pick up items (ammo, weapons, health - these need both HUD and weapons system)
• Doors and lifts with lockable versions and keys to unlock them
• Dialogs (the game wont be big on that but there'll be a couple of places where people will talk to you)
• Save/load

The engine side needs some stuff too:

• Import decals from the world file
• Add support for audio resources (the engine has no audio code at all at the moment)
• Ambient audio playback
• 3D audio playback
• Support for save/load (will need GUID generation from the editor)

Finally the editor needs:

• Better decal manipulation
• Finish the undo/redo code (not everything is undoable at the moment)
• Generate and retain GUIDs for entities so that saves can be implemented in a forward compatible way

From the content side i need to basically do everything since almost all of the existing assets are placeholders. I did some tests for level layout (the video shows one), but i need to have enough of the gameplay bits working before thinking more seriously about the level design.

And as for the models and textures, i still haven't decided 100% how exactly things will look (at least beyond the main character).

Implemented some initial audio code in the engine. The engine side was very simple, took only about four hours to write it, but the editor side took me some days (although tbh i did procrastinate a bit there :-P). Here is a video with some placeholder sounds and music:

In the video you can also see some other minor improvements, like loading decals from the world editor as i mentioned in my previous post (the big vertical banner things are decals placed in the editor - the editor also calculates lighting for them, although in this map it isn't very visible).

I still haven't implemented 3D audio playback. The API and script hooks are there, i just need to feed the 3D position for the listener to the sound mixer and update the mixing code to do panning based on that position.