The new old wolf

A long, long time ago — way back in 2014, in fact — some cool people came up with the idea of #LOWREZJAM — a game jam where you create games that run at a resolution of 32x32 pixels. (Later editions changed this to 64x64 pixels.) At the time, I had a bit of a nostalgia episode for old shooters, replaying Spear Of Destiny for the umpteenth time and trying out Blake Stone; so naturally, I figured that writing a small raytraced 3D game would be a great idea for the jam. And hey – with a resolution of 32x32, even if the per-ray performance was awful, it wouldn't matter much.

While this was a fun little exercise that kept me occupied for a couple afternoons, it turned out that the 32x32 resolution was way too low for a 3D experience. Even for a maze crawler game that you could play at your own pace, the image was just too blocky and it was difficult making out where to go. And so, like many times before, I gave up on the idea and didn't work on it any further.

I live, I die, I live again

A few months went by until, one dark evening of February 2015, I found myself yet again feeling an itch to tinker on some sort of game in 3D. I dusted off the raytracer and ported the code from Pascal to C. No longer bound by the game jam's requirements, I bumped the resolution to 320x200, similar to Wolfenstein 3D or Doom. (Well, not entirely similar, as those games had non-square pixels, by virtue of displaying a 16:10 aspect ratio image on 4:3 aspect ratio monitors of the time – but I digress.) I then proceeded to fix some glaring bugs, like this funny little fisheye-esque effect.

Satisfied with the wall-rendering bit, I turned my attention to making the game into a proper shooter. Of course, in order to do that, I needed assets — graphics and sounds for the player weapons, but most importantly, for the enemies. Naturally, I headed over to the Freedoom project and stole borrowed some of their stuff. As time went by, the project grew: I added projectile-based weapons and hitscan weapons; some basic stupid enemies, and some more tricky and intelligent enemies (with obligatory infighting).

I added normal doors, locked doors opened with a key, and locked doors opened with a switch. I implemented proper pathfinding for the enemies, first by running A* on the 2D tile map, and then by refining it to run on a quadtree representation of the map.

I added menus, allowing to tweak the game's settings and customize keybinds. I also implemented some basic support for internationalization — it'd be a tad weird to release the game only in English, without support for my native Polish. And of course, I added a save and load feature.

I even made a custom map editor — and when I say custom, I do mean custom: the UI is all original code, not using any widget library underneath. The editor map format recycles the savegame format, merely replacing item and monster entities with "prototype" equivalents.

While my pace wasn't particularly spectacular – all the progress described above took span over three years – I was having fun, and the project was steadily moving forward. Until one day... I just dropped it. On the 12th of March 2018, I made the last commit. It's not that I decided I no longer want to work on the game, that I made a conscious choice; it just... kinda happened. Like playing with your favourite childhood toy for the last time.

In the void, no one can see you fade away

And so, the project laid abandoned on my computer's SSD. A year went by... then another. And another. Recently however, I found myself playtesting the game a few times... and with each session, I felt a deepening sense of regret. The game definitely was playable, and it was actually quite fun. All the base mechanics were there – different weapons, cannon fodder enemies, tanky enemies, tricky enemies... While there were definitely quite a few rough patches, there were also many aspects that felt polished and well iterated upon.

In retrospect, it was probably a mistake to keep a low profile. Back then I had a habit of working mostly "in shadow"; I didn't like sharing information about my efforts in-progress, considering it to be taking credit for results not yet achieved. Thus, apart from showcasing an occasional screenshot, I avoided posting about the game. This meant that when work stopped, there wasn't really anyone to bug me about it.

So here we are. Eight years later, I'm willing to give this another go.

Talk is cheap, show me the code

Ugh. I wasn't a very experienced programmer when I wrote most of the code, and definitely not an experienced C programmer, so the code's a mess. That's not really an issue, though; shameful as the code may be, publishing it is not a risk.

I am a bit concerned about the game's assets; while I did a surprisingly good job in cataloguing most of the files, their origin and their licenses, there are some that are not accounted for – 52 out of 351, to be exact. Even then, some of the files have a known origin, but the author never specified a license – making them useless in a FLOSS context. This is the main thing I'd like to sort out before publishing the code or a demo version of the game.

So sorry, the git repository won't be public for some time still.

Something of a semblance of a plan

While it's too early for me to talk of a concrete plan, I have a list of various ideas that should keep me occupied for the nearest time:

• Actor collision. When I originally wrote the game, I didn't put in actor collision, meaning that monsters can phase through other, but also through the player — and vice versa, with the player phasing through enemies. While this can sometimes be an interesting gimmick, more often than not it leads to enemies bunching together. To be fair, just adding collision is trivial; the tricky part is having the pathfinding code being able to account for it and make enemies navigate around each other, if needed.

• Assets. As I already described, some of those will need hunting down their origin, while others will need coming up with a replacement. As I'm no longer a broke college student, I will consider comissioning some original art (which will help in making the game not feel like a blatant asset flip).

• Camera verticality. Right now the camera is fixed at 0.5 height and there's no support for moving it up or down. To be fair, this is fine for the player's perspective (though it means you don't get a "dropping onto the floor" effect on death); but I have a few gimmicks in mind that would benefit greatly if this was an option.

• Crashes. Welp, no point in sugar-coating it, the game does crash occasionally. Would be great to nail down the causes and fix them.

• Flat mapping. The game supports textured walls, but not floors or ceilings. This is a result of me straight-up just improvising the raycast renderer implementation, completely ignoring any and all existing knowledge on the matter. Now that I'm older and more humble, it would be a good idea to do some reading on the subject — flats aside, it will probably also help in improving performance.

• Hitscan. The game's hitscan implementation is a bit peculiar and misses objects sometimes.

• Map editor. The game's editor serves its purpose, but is rather clunky to use. Plus it's another heap of code that needs to be maintained. It would probably be a wiser approach to switch to using an external tool, such as Tiled, for creating the maps; though that comes with its own set of challenges, like the change in map file format.

• Minimap. The game features a minimap which can be used to navigate the levels easily. Right now the rendering on this baby's a little wonky — since it relies on tracking where your camera rays hit, the insides of corners fail to show up. Also the transparency effect is broken.

• Refactoring. As mentioned before, the code's a mess and there's quite a lot of stuff that I'd like to organize differently.

• Thumbnails. When saving your game, the program makes a thumbnail of the current game state that is then displayed on the loading screen to make it easier to figure out which save you want to load. This is a nice little feature that I'm very happy with; unfortunately, depending on your system, the thumbnails may come out flipped vertically.

• Wanderers. While some enemies utilise different forms of pathfinding, there are also some whose entire behaviour boils down to randomly wandering about until their target comes into view. This makes fighting them annoying, as the behaviour is unpredictable; it also makes enemy infighting uninteresting, as instead of closing in on their target, they'll often venture off in a completely different direction.

• Weapons. The game has a weapon roster straight up copied from Freedoom. On the one hand, sure, nothing beats the classics... on the other hand, it feels very uninspired. I'm particularly disappointed with the projectile-based weapons. I plan on experimenting a bit with different ideas to see what works, but I'm also considering straight up removing some of the guns.

• Worms. A melee-only enemy that moves very fast. They have perfect knowledge of their target's position and utilise pathfinding to swiftly navigate the levels. Coupled with the game's sound propagation system, the player may easily find themself in a situation where, after making a single noise, they're swarmed by every single worm in the level. This behaviour needs to be changed to something that's more fair to the player, while still offering a challenge.

All that being said, I plan on posting some regular updates – ideally every few weeks, at least once per quarer.

A game needs a name

Oh, right. All of this text, and I haven't dropped the game's title even once. Here it is: wilk320.

The title is very much a reference to the game's origin — a simple raytracer mimicking how Wolfenstein 3D worked. When people talk of Blazkowicz's first exploits, they often shorten the name to "Wolf3D" – and you can probably see where this is going. "wilk" is the Polish word for "wolf", and 320 is the fake-retro resolution the whole thing's running at. Simple as that.

As uninspired as the name may be, it's actually been with the project since the very beginning – it appears in the git repository's initial commit! For all its flaws, it's grown on me over time, so I'll probably keep it.

Credit where it's due

While I've been developing the game mostly solo, I did receive a lot of help along the way. I'd like to extend extra thanks to ŻbiXs, who has partnered with me on previous projects and did some original pixel art for the game, like the great hero portraits; and my wife, who patiently listened to me nerding out about the project, helped with turning vague ideas into more concrete ones, and even created some concept art, like the menu background above.

Also, as mentioned before, none of this would've been possible if not for the existence of the Freedom project, where I took most of the assets from. Xonotic was another a great source of sounds and textures. Many files were also taken from OpenGameArt and FreeSound. The soundtrack is comprised wholly of the great work of Deceased Superior Technician (nosoapradio_us).

External links

I will be posting future updates on my blog here, but if you can also follow the game's development on itch.io. Sometime in the future I will probably also launch a Steam page; this section will get updated as more options appear.