of object system and hitspheres (longpost).

Meanwhile in the GS object system department the great construction has reached another milestone.

So, today i’ll tell you how you can build the hierarchy able to support rock pebbles covered in purple blood, or aliens with variable amount of hands.

#Basic hierarchy

I’ve already worked on a base hierarchy for my engine while designing the architecture. I’ve got something like this:


GenericObject class is the base class of all objects and controls various properties common for everything, like unique ID or Time-To-Live.

BattlescapeObject (BSO) inherited from it, and represents any object that can exist on the battlescape, containing physics, structural hierarchy (for complex objects, like windowed wall composed from brick part and glass part), collision bodies, various utility data and so on. It’s a level on which the integrator and collision detector are working. BSO object can only be controlled via forces, like flying bullet, and simple scripts, like homing rocket.

Battlescape object

ActorObject extends BSO to the active entity, capable of being directly controlled by player or AI. It contains many useful constructions like order queue, various attributes, etc. Pathfinding, user input, and everything about living creatures (or vehicles) work on this level.

Advanced hierarchy

But we’re gonna need something more detailed than that. Some kind of data format able to describe the variations of the game objects, and since i was aiming for the great degree of modability, this format should exist outside of the code.

So, what will we do?

We’ll go and look inside the raw format of the game with the most detailed object hierarchy i know. The Dwarf Fortress.

It’s amazing, complex, flexible, expandable format, capable of supporting simple commands, creating the objects based on other objects with added or removed parts, smart parcing and much more. It’s definitely can offer much to learn to, if you know how to ask. Of course, i can’t rip it whole due to the impoliteness of such act, different required functionality and, must important, it’s much better for you to do something by yourself than to copy other’s work.

I still took its general conception as the base, though:










Tokens are constructed very similarly:


Though i’ve added a two pass parsing because of the heavy cross-references, so tokens are parsed in the right order regardless of their position in file or even the file position in the library folder.

So, the final thing looks like this:

Advanced hierarchy

Of course, every generic parent can be omitted, but i tend to use them because it’s handful (you can set up things common for all birds in the generic bird, for example ability to fly. You are still able to create penguins and remove that ability explicitly).

Complex objects, like humans, contain several another objects as childs and internal parts (remember what i’ve said about dependencies?).  That will allow the creatures to have complex hitboxes, lose limbs, suffer damage to internal organs, have different abilities based on what body parts it still have, or what object it is holding in hand/claw/tentacle (think of weapon/motion detector), or just have it somewhere on the body, like walkie-talkie.

Also, because this walkie-talkie is the BSO on its own, it can take part in the collision detection as well! Think twice before stuffing your backpack (which is also BSO) with explosives, as the stray hit in the back can obliterate half of your team.

You may ask a reasonable question: How are you going to render all this nonsense? on which i’ll write sometime later. Have one of the preliminary research concepts instead. It’s composed of the 7 layers (arms, legs, torso, head, weapon) and separated light mask.


Today i’ve finished parser testing (it’s the fattest class in the project by now, mess of recursions, switch trees and subroutines, so i’ll have to clean it later. Make it work, then make it good.)

Visual reports are up:

screen1 screen2

These are the collision spheres of the (presumably) human body in two views (up and front). The engine is working in 3 dimensions, even though the default viewport will be isometric. Isometric is just the camera angle after all.

You can think of this view as of the probability map for the bullet to hit certain body part accounting the bullet travel path and angle (e.g. you can’t hit the legs of a man who is half-covered behind the wall until you penetrate that wall). Or you can think “hitboxes”. Well, hitspheres. I’m planning to add several more types of the collision bodies. Rectangles are a must, cuboids are wanted too.

Color coding: Red for torso and head, green for arms, blue for legs. This object was constructed entirely from parsed data.