Make abilities or die trying pt II

In many games things like the ability to stand/sit/move are considered fundamental for the game unit. Behaviour and restrictions to these functions, if any, are hard-coded. In our case, ability is tied to the body part. When there’s no body part, there’s no ability. Idea worked well with one-time abilities: equip the gun and you can shoot, drop it — ability goes away. On contrary, it doesn’t work at all with continuous abilities like standing. Read On →

Art post 20.05

Some pictures for you.

Read On →

Make abilities or die trying pt I

Abilities were planned as an important part of the architecture almost ever since the game development was started. Scripted actions, totally customizable and very loosely coupled with the rest of the system, they were supposed to cover everything unit would ever want to do.  Unlimited modding capabilities, fast development, easy changes.

Then the reality kicked in.


As you can see in this advanced picture, the idea was rather simple and obvious: make separate body parts responsible for separate abilities. Then you can walk around the entire construction and obtain the final list of everything this unit can do.

And, of course, any changes in the body plan, including picking up items, dropping items, losing a limb or two, would automatically update the list of available actions:


Care was taken to avoid false additions, so as when soldier picks up item he doesn’t know how to use, or picking up things that only supposed to give abilities when they are properly attached to the body (goggles in your hand will do nothing).

I was able to find a solution for scripting, both support and performance-wise, so scripting is practically a breeze. But as I’ve been implementing various parts of the design, architecture problems started to rise.

There are three main problems: GUI interactions, ability cancelling and state concurrency.

This post is about the first one.

Read On →

Little post that couldn’t

Well, that was expected. As I said, I’ve been preparing the post about the abilities, but I still can’t quite get it the way I wanted. Sorry about that. The truth is this thing had grown into the heavy psychological block, and I’ve been dancing around it, cheating myself to postpone the unwanted work. Always trim your mental lawn, kids. So I laid down some work for the editor, which was required, but not a top priority, and I’ve implemented the debug console, completely with remaking the GUI system, which was even less needed right now. Read On →

Season Deux

We’re back in the saddle! Short news: Alone no more! Stephen White kindly agreed to help me and so there are two of us working on the project now. Big improvements. I’ve been training in code and drawing all this time, working on a serious business™ software with a very good team. Now i urge to rewrite most of my old code, but the improved speed, stability and maintainability are worth it. Read On →


Ok, where the hell.. I’ve been? Moved to the biiig city. No money. No job. Thug life. That happens. No progress on the game then? Yes. Nothing big, at least. I’ve planned to put up prototype before moving, but failed. And when? Couple of months, i’ll be damned but i’ll make the thing at least somewhat playable. Playable? One map, two teams, several soldiers, working bullet physics, hopefully working FOV (questionable), sandbox for object testing, that kind of things. Read On →


This is my Ludum Dare entry. There are many like it, but this one’s mine.It’s that kind of strategy where captured worlds are constantly building units, also bundled with an indirect control via routes and a twist with the world connections. Main feature of the game is the ability to connect the worlds. With each connected world conglomerate switch to the bigger ships. Tiers are untransitively balanced: fighters<-corvettes<-frigates<-fighters. So the two connected worlds beat two single worlds, but three connected worlds are worse than three singles. Read On →

Ludum dare warmup

  Ludum Dare is a great chance for training in making completed games. Given the time limits, you have no margin for straying around, only you and your idea. The skill i’m striving for. Here’s the entry i’ve prepared for the warm-up event. It’s the first ever game i’ve actually completed. Behold, the Gauss Flux! The idea was to make shmup with the ability of building your ship on the fly from various details. Read On →


Simple abilities implemented, call routes overhauled. Now everything regarding abilities goes through the actor, allowing me to influence ability calls with actor mental stats. Orders implemented. They are smart, they are strong, they could handle the failures. It’s an additional level of abstraction needed so the AI could operate constructions like “Go somewhere north, take sniping position” instead of “go 1 tile north, go 1 tile northeast, etc”. I’m considering making these scriptable. Read On →

Refactoring ideas

So, i’ve realised there’s no sense in releasing a prototype which contains no game at all. And it turned out there’s a bit more underlying work ahead, and suddenly i’ve got buried under the ideas which aren’t quite fit together as they were. Four days i’ve been writing and drawing diagrams, trying to fit every piece together, with some success. If you’d want, you could have a look at what’s my design documentation looks like. Read On →