I'm Chris. I'm making games and I'm writing tools for different things. Such as games ;)

RSS My Blogs  (0 - 10 of 42)

Hey folks!

Thanks for sticking around my profile for so long. You guys are mostly silent but I know you're there :P

And I wish to thank you for that. I got so far with The Vrennman Case now that it's actually beneficial to do a real game page on indiedb. You can find it here: Indiedb.com

From now on you can find all the news and media there (there's new stuff to see, actually). The articles will be written by John who's teaming up with the programmer person, the graphics guy and the sound dude to re-create his adventures in the form of a game (The Vrennman Case).

These all seem to be the same person but John pays them separate anyway so there's that.

So, again. Thanks for sticking around and reading at least a bit of my mumbo jumbo here.

See you over there!



The Vrennman Case

damagefilter Blog


So as mentioned in the last Firewalker Dev Ramblings I've been working on a new project. One with smaller scale and more realistic goals - something a one-man show can actually pull off without working on it forever. One where there's a fixed feature set and the game mechanics are known and implementable as to prevent most of the feature creep.

And today I'll present a bit of that. It's the work of most of the last year.

The full title is "John Amry in: The Vrennman Case". Or short "The Vrennman Case" or even shorter "VC". As the full title would suggest it's a story you're going to play. Like with most adventures, really. You'll have a ghost companion that'll help you on your way to stop the Vrennman clan from summoning the six evil lord demons and raise hell on earth.

Here's a bit of 2D lightmap testing and Ghostmode. Which is very cheaty because A) In that scene you actually can't have ghost mode and B) With the ghost you can walk through walls (which is intended).

There's a lot of work already done here. I've got save games, controller friendly menus (an in-game controls of course) and a pretty advanced game-event system I dubbed CSP. The initial version of it was devised during the Firewalker development and is sort of a Unity port of the Source engines I/O system.

Vrennman Case Menus

You interact with the world via the Actions menu. There you have one to three options based on the thing you're interacting with. This door here can be kicked or it can be opened. Both actions have an effect, more or less. This system, on the technical side, is reusable and it scales nicely. This together with the CSP system allows for complex puzzle building and fast iterations. So that puzzle design should be quick and efficient.

Okay. So basically the foundations are all down and ready.

Currently I'm tiding up a little. Make sure the first level is rigged properly, the asset placeholders are, for the bigger part, replaced with real assets and colliders are in place where they need to be.

Current status in percent, I'd say is 10%. I'm working on the first couple of scenes to get the player to know John, his companion and the enemies they are facing.

And that's it for today. I might, finally, get around making an actual game page for this project. We shall see.

Have a good one, folks!


Hello folks!

Today, more than 12 months after the last DevRambling about Firewalker, I've come to put it on ice.

On Ice is not cancelled.

Personally I've got a bitter taste of the past about it, thinking about how Prison Island fell apart like a card house in the wind.
I do know the situation is a little different today then it was many many moons ago when I had to cancel the Prison Island project but still. I really want to do this project one day.

At any rate, here's my reasoning.
Firewalker is, and that seems to be very typical for me, a project with a scope which is simply too large for the limited time I have for making games. There are six dungeons and a whole city with (surprise) six districts. The workload to produce all the required assets alone is daunting.

However, the most important factor is, I am at this time, simply not up for the job. I was refactoring code every other day because I kept learning new things. I broke one system after another, wiring them up again, leaving a mess of unused code and undocumented features and corner cases. My knowledge when I started the project was simply not sufficient to really pull it off.

However, there are some really (probably) good systems going on in the Firewalker codebase and I didn't want to let them catch dust. There are savegames, a Source engine like IO system, behaviour trees and a corresponding editor ... these kind of things.
So I pulled it all apart and created a library of code that is independent from any game it may be used in.
It can be found here: Github.com
This is my Firewalker-takeaway so far and it's okay.

During the past 2 years I have been working on smaller projects, learning new stuff and actually making games. Mostly in 72h gamejams. I've been using the code of that library in these jam games. I've been extending the library with my real-life requirements when making games and prototypes. I will delve into a couple of smaller projects with this codebase in my virtual backpack and gather new knowledge about making games.
I might even get to release something a little bigger than a 72h game at some point.

Eventually I will come back to Firewalker. It wil probably not be titled Firewalker anymore but it will be the top-down slashing beasts and solving dungeons thing I wanted it to be.
Hopefully, by then, I'll be able to actually pull off a project with such a scale.

So there's that.


PS: If you feel like reviewing / using / forking / contributing to that library, please do :)

Hello there!

It has been a few weeks now without a word of us so here I am again. A lot of stuff has happened outside the game that consumed most of the time spent, however, it was all part of starting work on milestone 2.

The most important bits: I have re-done the website. Along with it, I ordered a new server on which I set up all the infrastructure for developing the game once again. That was a very time consuming task but now we have a shiny new and clean box at our disposal. For those of you knowing me from the CanaryMod project: That is why the canarymod.net site is currently down. I'm awaiting a response from the new domain owner.

Anyway. Have a look: Playblack.net

Now to gather some proper in-game screenshots.

Development wise, we also started on milestone 2 tickets.

Since we're using Unity 5 now, I re-wired the savegame system dramatically so it would load prefabs via the AssetBundle API instead of the Resources API. That means we don't have to load all the things into memory all at once and as added bonus, loading of save-games is now asynchronous, which means it feels more fluid.

Additionally there has been work to account for "fixed time situations". That's, for instance, inside dungeons and houses, where the time should not pass but stand still. Of course this leaves a large gaping hole for a lot of feature creep but I'll do my best not to let it in all that much. But the thought of mechanics to manipulate time is tempting!

Also, the sound system got a bit of refreshment. It too loads its audio clips from asset bundles and can be spoken to via the event system we're using.

Next thing in line: Getting some proper in-game material going. Then it's time for a new indiedb page. I think before that there will not be enough stuff to show off.

That was it for today folks, thanks for reading


Howdy out there!

I had to forcefully take a break on development once more because the usual real-life happenings. It happens. The good news is, I'm still on schedule for the first Firewalker milestone - the technology release. It's actually not a release but the name sounds funky.

This milestone means that all the basic technology that I need (or think I need) in order to make the game is ready. By that I don't mean "all the AI" or "all the entities" but things like "the sound system", "important editor UI", "system to execute scripted sequences", "Entity Signals System (like I/O in Hammer Editor)" ... stuff like that. With these in place I can add more and more logic (or content), as I progress through the further making of Firewalker.

The tech-release will be ready the coming sunday (that's June the 14th) and once this is through I'll start on some PR related work. I'll create a new IndieDB page, perhaps something on facebook, fix up the website and, although only loosely related, I'll re-design the playblack site to something more modern looking. Of course the pages will be updated accordingly with information about what Firewalker actually is. I realise that my personal blog is way too abstract to give the reader a big picture.

Once that is done, I'll progress with the second milestone - which contains first bits of proper gameplay, at least one dungeon and a bunch of mobs. On that occasion I'll also tie up some loose ends in the code that are open from milestone one, if any, and clean up "the code so far".

This time I have no fancy pictures for you, I'm sorry :(

And that's it for today. Rather short but I hear that's a good thing sometimes!



Hello there!
I'm writing again because I have a little progress. First and foremost I went ahead and turned these dynamic shadows I showed off a while ago (http://www.moddb.com/members/damagefilter/videos/dynamic-2d-volumetric-lights#imagebox) into soft shadows.
That looks something like this:
PARTY LIGHT  (Soft Shadows)

Pretty pretty. It's even better when it's moving. I'll have a video for you soon.
The cool thing is, I can have the shadow casters really low-poly now and it wouldn't matter.
That means ... MORE dynamic lights! Can never have enough dynamic lights.

A word on the visual style on the screenshots so far:
This is not the final artwork. The finished or final versions will look darker with more detailed and less like they are straight from a kids game. I'll have some of this for you soon! We're currently developing the city layout and after that it's remaking and creating new sprites.

Now, what took me most of the time the past weeks was the new sequence editor.
It is based on the behaviour tree implementation I also use for the AI and so creating a sequence structure was not the hard part. I have it all there already, including serialisation and save game compatibility.
What took me so long was all the editor code. It went down to an extend where I was wondering if it was worth all the trouble I had.
sequence ed

Turned out it was worth it indeed. You may recognise that pseudo code thing - once again I borrowed from the old RPG Makers. With this sequence editor ready, we can push out story and gameplay progress very rapidly. But of course, it's not 100% functional yet. Some event types are still missing, like Sound triggers.

Generally though, variable operations, switches, messages - all the basics - are in and working.
And that feels good. Seems like I'll make it to my tech-release deadline in a timely manner!

And that's it for today, thanks for reading!


Hello there!

It has been a funky week full of hunting regressions while finishing the attribute spreading in the combat system... which is a fancy description for "Weapons can put things on fire now".
Which is essentially what is happening now.

Generally, weapons can do anything with the attacked entities now for demonstration purposes I chose the classic fireball and letting thigns go up in flames. This was all done to enhance combat mechanics and also to finish up the status display.
That's kind of an indicator about what kind of problems a particular entity may or may not have.
The initial idea was to add little icons above entity heads but then it seemed easier and much better to just introduce actual image effects.
The poison effect makes you go all green, Diablo-style ;)
But first, here's the fireball effect working:

So that was what I've been working on all week.
Thanks for reading and have a nce week!


Goood morning, folks!

The last week I was busy finding new ways of lighting up scenes in Firewalker.
That's not putting them on fire, that's setting up point and spotlights and better ambient light.
Simple fake 2D light
I did find a way that seems to be alright. It imposes one extra draw call all in all and so far it seems that it doesn't have any significant impact on the time required to render the scene.

So, it works by dropping a few things into an extra rendering layer (lights, mainly). They can be of any shape and colour. They can even be 2D volumetric light meshes (for dynamic cutout shadows).
That light layer is not rendered by the main camera but by a second camera that is rendering only this one layer.
To fake the ambient light I simply use the clear colour of that camera. At night it clears to some dark blue colour and at day it clears to something that looks like day.
The result is put into a render texture.
I call that a lightmap. Strictly speaking it's not a lightmap but the idea is the same.
The lightmap gets multiplied onto the the image that is rendered by the main camera.
Et voila.
Lights and daylight cycle. All dynamic.
Simple fake 2D light
That was the big thing this week.
I also wanted to implement a combat system but it turned out I already did that.
So that was one free point on my list.
Next thing on my schedule is a status indicator to show the status of the player and enemies.
That means, is something poinsoned or burning or frozen or numb and so on.

There shall be more colours then!
And that was it for this time, thanks for reading!


Why, hello there!
It has been a while, hasn't it?
I fell behind my originally planned schedule quite severely ... by 6 months ... *cough*.
That is why I was unable to write anything - there simply was nothing I could write about.
However, these six months didn't go by while I did nothing. I did something but perhaps not as much as I would have liked.

There were 2 major refactorings (because I love kicking my own ass and breaking the code over and over ...?) going on. Following is a very nerdy (more or less technical) rambling about code stuff.

State Machines to Behaviour Trees

I got around to finish the conversion from state machines to behaviour trees for my AI. One would think that is easy, however there is only one BT library out there for Unity that is worth using but I couldn't because it comes with integrated path finding and that path finding does not work on a 2D plane.
At least that is the impression I got while trying it out.

So I made my own ... more or less.
I ported the JBT library - or rather the relevant parts of it - to C# and wrote a node editor for Unity to integrate it. That very editor was a major pain in the neck to write though. The first version I made assumed that the Unity serialiser can serialise anything that falls within the rules (GameObject or annotated with Serializable etc etc). However, it has a maximum nesting level of 7.
Magic constants. Great!
That meant I could only have behaviours with a rather limited complexity.
I supposed that a proper boss battle AI would have more than just 7 nested behaviours to function properly, with all the sensor checks, decorators, composite nodes and an undefined amount of actions a boss can have.
So 7 ... not gonna happen.
For version 2 I used ProtoBufs, the same library in use for the save game system.
This way I can have reference tracking (awesome for having parent nodes as real references instead of copies, which would really break a lot of things) and an unlimited amount of nesting.

So ProtoBuf serialises my behaviour tree into a simple byte array and Unity serialises that byte array back and forth. Job was finally done.
I have implemented a simple wandering behaviour and attack-on-sight behaviour so far.
It works a charme.

The new dialogues

The next big topic on my todo list was re-implementing the dialogue system.
It broke a while ago because it was too interconnected with all kinds of other parts like the input controller and inventory system. So I decided to decouple the whole thing and use my event bus to control it instead.

It can now be requested to do things by events, an "operator" does not need to know anything about the system doing the dialogues, it just makes requests. If there is no system in place, simply nothing will happen.

The dialogue manager itself dispatches events to notify all listeners that something happened. Specifically that a dialogue started or ended.
So that is done now too.

In other news

Unity 5!

The moment it was released I switched to it and it's gooood!
I can now stop loading all the assets into memory at once and work with asset bundles. That means I should probably change the part of the save game system that loads prefabs to populate / re-create a scene. Not that it would make a big difference as all the assets are but a few kilobytes in size but it will probably lower minimum specs so you could run the game with a pile of wooden sticks.

And that was it for todays very text heavy blog entry. Next time there will be more pictures, promise!


It's friday and a good time to write another dev rambling!
This week was a bit dev-unfriendly. I had a lot of stuff to do at RL work and managed to do only little things for Firewalker. But better little things than no things at all.

First official act this week was to change the ration of pixels to world units.
That describes how many world units to fit into the size of a pixel.
By lessening this value, pixels will grow larger, which is what I wanted. Large pixely goodness.
It also blew up all the test level arrangements. Oh well.

Derpy Pixels
That's what happened ... but at least the pixels are all there. Nice and large.

Other than that I finished the inventory refactoring I was about to do. It's now nice and clean like it should be. Entities can have "Inventory bags" and they will be projected on an inventory GUI when required. Previously it was ... well not like that. More ... messy.

Additionally to that, there was finally nothing left that was blocking the loot drops implementation. So I went ahead and wrote mobs dropping loot. Generally speaking it's a kind of loot dispenser that would dispense items upon certain inputs such as entity death or if something calls its Drop method.
That meant that I also had to start implementing items displayed in the world. A player can pick them up by clicking on them. Hovering over an item with the mouse will show its name. Upon collecting them they will be auto-sorted into the player inventory.

Items in World
Furthermore I re-implemented the player stats GUI.
Thanks to the new Unity GUI that went very smooth and did not make much problems.

Oh also, very important: My better half started on a new character spritesheet for the main player.
That new one looks pretty good and definitely a 1000x better than the old one. Although, movement animation is still iffy and needs adjustments. She's at it.

So this is what happened this week.
Here's a snippet of the road map so far (it's ever-changing but it represents a more or less accurate plan of things) - for your reading-pleasure (does not include artist stuff, only code).

- 0000019: [Feature] Sound Manager (damagefilter) - feedback.
- 0000006: [Feature] Dashing Movement (damagefilter) - assigned.
- 0000025: [Refactoring] Refactor AI State Machine into a Behaviour Tree (damagefilter) - assigned.
- 0000023: [Menu] ConVars Editor Window (damagefilter) - assigned.
- 0000022: [Feature] Quest System (Devenias) - assigned.
- 0000015: [Feature] Status Effect Display (damagefilter) - assigned.
- 0000010: [Feature] Loot Drops (damagefilter) - resolved.
- 0000012: [Feature] Inventory System & GUI (damagefilter) - resolved.
- 0000021: [Refactoring] Inventory Rendering (damagefilter) - resolved.
- 0000011: [Feature] Player elemental immunity (damagefilter) - resolved.
- 0000017: [Feature] Save State System (damagefilter) - resolved.
- 0000024: [Menu] Item Editor (damagefilter) - resolved.
- 0000013: [Feature] Items & Item Stacks System (damagefilter) - resolved.
- 0000020: [Feature] Monies! (damagefilter) - resolved.
- 0000016: [Feature] Game Logic System (damagefilter) - resolved.
- 0000009: [Refactoring] Move Player Movement into separate script (damagefilter) - resolved.
- 0000008: [Feature] ConVars & Global States (damagefilter) - resolved.
- 0000007: [Feature] Chat Display System (damagefilter) - resolved.
- 0000005: [General] Sprinting needs stamina (damagefilter) - resolved.
- 0000004: [Feature] Direct callbacks to state on state switch in FSM (damagefilter) - resolved.
- 0000003: [Feature] XML Dialog Flow System (damagefilter) - resolved.
- 0000002: [Feature] Day and Night Cycle and global clock (damagefilter) - resolved.
- 0000001: [Feature] Entity Attribute System (damagefilter) - resolved.

Next week I'm doing the status display and AI refactoring, which will likely take a lot of time as a behaviour tree is not exactly a trivial thing to implement.
Additionally, what is not in the roadmap yet, I need to re-implement the dialogue system. And maybe, while I'm at it, I can come up with something more fashionable.

That's it for this week,
thanks a lot for reading!