Scripting approach

Alright, now that the editor is ready and so is the physical part of the game world, i can turn to the more interesting and complex thing: mechanics.

Mechanics is the third component of the object and it describes every behaviour which will be too complex (and stupid) for the engine to simulate physically.

Mechanics example


Let’s create a new object and call it “grenade_body”. Assign some physical properties like mass, size, material and sphere as the collide body. Then we’ll proceed to the construction section to attach another sphere called “grenade_detonator”. Now we’ll throw it into the wall (did i told you not to try this at home? pretend that i did).

What will happen?

Not much.

Physical engine will process the collision, calculate result, ricochet vector, velocity change, body damage, and that’s it. After some more violent throwing grenade_body will probably lose its integrity and will be removed from the game.

That’s not how grenades work! Mechanics to the rescue!

Mechanics will be composed of named fields and scripts that will be connected to the body. Fields will contain various kind of customizable and specific to this object data. Scripts work with that data. These cannot be hardcoded like the physical parameters and standart procedures because they will vary from object to object. First aid kit has morphine shots capacity. Rifles and stones aren’t. Engine doesn’t give a damn about morphine shots capacity when bullet penetrates your first aid kit. For engine it’s just a lead object penetrating the aluminium casing. First aid kit script that activates upon kinetic penetration can give a whole lot of damns, for example, reducing your morphine shot capacity to zero. Sorry! Engine code also isn’t moddable by anyone except me, while script code is a simple text in a game folder.

Revenons à nos grenades. Grenade interaction usually starts with a detonator or the bomb defusal kit. We’ll stick to the first.

For the simple implementation, we’ll only need two fields: boolean primed and integer timer. First will show whether the detonator has been primed, second will show how much time you have to run. And now methods: One for priming, which will set prime to true and timer to some time (in our case it is measured in turns). It could be a fixed number, fixed number + random deviation for slightly-less-reliable detonators, it could be a parameter passed from the hardcoded GUI or, most probably, this method will show its own selection window. Then what’s left is hook up to the new turn update and decrease the timer, so when it comes to zero, kaboom. Kaboom?

Well, not exactly. It would be just too simple. Instead of exploding, detonator applies some force to whatever it’s attached and self-destructs. Grenade_body has a script which runs every time the force is applied to the object. It simply checks if force is strong enough, and creates explosion and some fast-flying fragments in case it was.

This system has some interesting properties. For example, grenade_body didnt check what caused the stress. Therefore grenade could explode from another explosion or a bullet hit. Detonator that is set for more than one turn could be disattached with the right tools, effectively disarming the grenade. If the force mechanism isn’t quite what are you need, you can produce thermal detonators which will heat up its unlucky parent, or electric detonators that will zap it. Once done, this detonator can be reused with variety of grenade bodies, which in their turn can produce anything from the gas clouds to electric discharges.


Next in the list – grabbing, aiming and the mighty alien walking octopus.