Risk Mitigation: Add more Details to Death Animation

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I tried quickly if more details for death animation would give the game more depth.

And it does. Need some more fine-tuning and random but the idea is there and looks good and funny. But I need to add some random explosion if I kill a mass of soldiers. The blood fragments have to be more random in the depth axis so the helmet is not all behind the blood fragments. But this is fine-tuning for a prototype this is enough.


I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Primary and Secondary Weapon Switch

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

The next idea I tried quickly to pitch was having a primary and a secondary weapon for more advanced levels. But I needed first the implementation, was only an hour to implement this and define the primary and secondary weapons, so cheap enough. I tested with an M4 and a semi-automatic handgun (Glock).

If I use a gamepad, I will have to separate the switch button from the shoot button, so that I can shoot and independently switch the weapon. Feels good. But at the moment the handgun doesn’t give any advantage over the rifle for melee attacks or in any other situation than running out of ammo with the rifle. This isn’t too exciting. I have to extend this test and see if it is a good idea to make a rifle not operatable in very close range so that the player just has to switch to a melee weapon which is the main purpose of a secondary weapon. I made as well the handgun ineffective for long-distance, the bullets lose their power over time.

One thing I observe is if my rifles are not working in melee it is not visible or clear it just does not shoot. I need some feedback. Could drop some curses from the player. This leads to another test besides just implementing the weapon switch between rifle and melee weapon. I will test this idea shortly and see if I like it. I tried ejecting some skulls and bones when he curses.

It gives now an indication that something bogs this little man when he tries to shoot at something too close. Looks cute in a way so I will go with that.
And last but not least a mini level where a weapon swtich makes sense.


I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Bloodstain for Bullet Exit Wounds

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

In this blog article I tested bloodstain for exit wounds, this makes it much crueler and in a weird way, satisfying to shoot those dummies. I took the damage into account to generate the amount of bloodstain when an enemy gets hit. But this is not just limited to the enemies but also the hero.

Looks quite satisfying but might be that it becomes a bit too violent. I apply to every character, robot, and object its own hit animation, so even when I shoot at a computer I can make some fitting nice animation for getting hit. I think this looks more interesting than just color the object flat white for one frame when get hit by bullets.

The test leads to a better-organized code and easier to add new hit and destroy animations for certain objects and characters.


I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test More Random for Shell Ejection

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I will play with the random factor for shell ejection, they currently look a bit like a waterfall as I only have random for the vertical component of the ejection force. So I tried to add as well random for the horizontal force. I will have to do this comparison for all my weapons that I want to use in the game.

For me, B looks a bit more vivid and a bit more out of control, actually exactly what I want to achieve. Anyway, I made a tweet but this time no feedback. I guess it doesn’t make a big difference. I go with a tiny bit more random and that’s it, looks more vivid.


I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

Risk Mitigation: Test Bigger Muzzles

This is the follow-up article about lens #16, the lens of risk mitigation from The Art of Game Design: A Book of Lenses written by Jesse Schell. If you buy books through the links in this article I will get a small commission for that.

I will try different sizes of muzzles and add a bit more random to it to see if that could make a difference. As well as experiment with different sizes for every gun. As well add some random to make it more vivid.

For fast prototyping, I need a simple way to switch between the weapons. There are a couple of ways. I can make a pickup command and exchange the gun with the previous gun and just put all guns in a row. Or add them programmatically and make a switch weapon button for this test.

I made a four-panel gif image with https://www.kapwing.com labeled with A: Constant muzzle with a flashlight, B: Random muzzle with a flashlight, C: Constant muzzle no light, and D: Random muzzle no light.

And made a tweet to get some feedback which is the best variant.

I also asked friends and family members. The outcome is that a bit more of the votes like B the best as it looks more vivid. The second large group preferred A because the muzzle leaks through the floor if I use a random muzzle size, which is simple to fix. Many said a tiny less random would be beneficial. There was one vote for C as the gradient muzzle would not fit the art style.

Furthermore, that way I could engage many more people on my tweet, much more than I expected.

So thanks a lot for helping me out to find the best muzzle style which is important for my game as it lives from the weapon, shell ejection, recoil, and muzzle. I will have at least 3 different sizes of muzzles, one for nine-millimeter weapons I have, one for the soldier rifles like M1 or M4, and one for the bigger guns. I will probably have to fine-tune this further.


I get a small commissions for purchases made through the following links, I only have books in this section which I bought myself and which I love. No bullshit.

M163 Vulcan from Sketch to Model

I modeled my M163 Vulcan tank with blender 3D for my game. The plan is that a soldier can control that tank alone, which of curse in reality it needs more people at least a gunner and a driver. And because one soldier can control this tank the player can take out that soldier and take over the tank. The next step is to bring the tank into my game and do some shooting prototyping to see if it looks cool. The real old M163 Vulcan does eject the shells visibly which fits in my concept so well.

Shoot in All Directions

I can now shoot in all directions with my little cute hero. And you can see he enjoys it a lot! My game goes now the action game path with a very simple level design. The idea is to improve the visuals with small little details. The ejected shells are one sample, the hearth if he collects new ammo, and the funny lauthter if he shoots like crazy. I plan to add more things which interacts with the hero or any NPC, like crickets which fly aroung and get disturbed in the the bullet hell.

I think it’s now quite hard to aim on something and as ammo is a limited resource I probably need kind of an automatic aim. The idea is that if there is something to shoot and I aim in a directions the automatic aim to the next shootable thing in that direction if it is in range. But I need to do first game testing. This is actually the next step any way to have a set of simple levels and let people play them so I can collect feedback. In the past I did that with steam, I probably also will look into itch.io as well.


I get commissions for purchases made through the following links, I only put stuff in this section I also would buy or I already bought

Lens #4: The Lens of Surprise

The next lens I want to look through on our game "All Fucked Up" is the lens of surprise from the book The Art of Game Design: A Book of Lenses written by Jesse Schell. I try to answer the following three questions:

  • What will surprise the players playing "All Fucked Up"?
  • Does the story have surprises? The mechanics? The artwork?
  • Does the mechanics give the player ways to surprise themselves?

Quite though to answer this for your own game. I give it a try and might be completely wrong. But at least it is documented. We placed cute funny animations that get played if you achieve a goal like kill two soldiers in a row which makes the character laugh. The artwork is not breathtaking to be honest, but what might be surprising is that every gun feels different. The gun itself is not visualized instead we focus on shell ejection, kickback on the characters (gun impacts the player, bullets provide kickback on the objects they hit).

I plan to have time limited levels as well, where everything explodes if you don’t make it in time. The time goes backward in those levels.

Improvements I can think of

  • Use the gun kickback to achieve something
  • Add a shootable grappling hook to climb up unreachable spots
  • Add defuse abilities
  • Compose weapons out of parts
  • Destroy locks or start a chain reaction on explosives

I think this is an important part and I will have to think more about it and collect more ideas.

Thanks for reading. I would appreciate your oppinion below in the comment section.


I get commissions for purchases made through the following links, I only put stuff in this section I also would buy or I already bought

Sneak Peek Of Our First Levels

We happily present you a sneak peek of our first couple of levels including failures.

The game gives instant feedback on failure and puts you at the beginning of the mini levels. It only needs little to get killed. The enemies are not very smart and shoot each other in the chaos of the battle.
It’s currently more feel-good gameplay than very challenging or surprising. The weapon and collecting ammo is the main mechanic in this simple platformer game. We would love to hear your opinion or maybe ideas about what kind of mechanics we could introduce.

Behavior Trees for Weapons

If it comes down to behavior trees many developers think of AI, robotics, or NPCs. I started to use behavior trees to make my stupid soldier NPCs patrol and shoot. They are still very stupid and sometimes shoot each other. I realized that I can use behavior trees for more than just my NPCs.

For example for my weapons. It’s actually so much fun to design and model weapons, not only from the visual representation but also in how it behaves and how it feels to use it.

Note that…

this blog article doesn’t want to explain behavior trees in all lengths and depths. There are many blogs and articles available which do a great job explaining behavior trees. Furthermore, you will probably also need to read the documentation for your behavior tree implementation at hand.

Here a small selection of links:

It starts always simple

When I first introduced my weapons to my platformer "All Fucked Up", I did it the classical way by simply programing them. It started simple with a weapon which eject a shell, launch a bullet, place a flash light and make a boom sound. Even when I modeled a submachine gun it was simple. I thougt well how messy can that possible go. And then a double barrel shot gun came along the way and everything started to get messy.

After two shots the shotgun should eject two shells, not imediately but with a small delay. As well I wanted to limit the rounds per minute. I managed to do this and ended up with the following code:

   public void shoot(double tpf, Vec3d location, Quatd orientation) {
        time += tpf;
        if (pull) {
            if (cartridge > 0 && time > 0.25) {
                cartridge -= 1;
                time = 0;
                launchProjectile(orientation, location);
                if (cartridge <= 0) {
                    eject = true;
                    ejectTime = 0;
                }
            }
            if (time > 2.5) {
                cartridge = 2;
            }
        }
        if (eject && ejectTime < 0.6) {
            ejectTime += tpf;
        } else if (eject) {
            eject = false;
            ejectShell(orientation, location);
        }
    }

It doesn’t look too bad to be honest, if you carefully read it you will get your head around it. But you probably also see the problem with this approach. Just think of extending it with a limited amount of ammo you collected. A force-reload, where you want to reload the weapon even if you didn’t shoot all ammo. It was no fun to try to extend it.

There must be an alternative to this messy code, which is hard to maintain, extend, or adapt. I tried to refactor it in breaking it down to smaller and simpler pieces. The main problem remained, it was still hard to extend or adapt.*

The weapons do have behavior and why not use a behavior tree implementation as a way out. It was one of the best decision I made for this game.

A very short story about behavior trees

I use the behavior tree implementation from libgdx-ai.
We have tasks, sequences, selectors, and parallels. In this article, I don’t need parallels.

I just describe very short what the single parts do.

Task

A task can either fail, succeed or stay running. A task in the state running, will be reentered on the next execution of the behavior tree.

Sequence

A sequence is a special task that runs each of its child tasks in turn. It will fail immediately when one of its children fails. As long as its children succeed, it will keep going. If it runs out of children, it will succeed.

Selector

A selector is a special task that runs each of its child tasks in turn. It will succeed when one of its children succeed. As long as its children are failing, it will keep on trying the next child. If it runs out of children completely, it will fail.

Ok then let us use this behavior tree

On the top level of the behavior tree we have a sequence with two tasks, the first one will reload the gun if needed and if possible, the second task will shoot if the trigger is pulled and there is at least one round chambered.

Let’s look at how we model the "need reload" task. Probably not the best naming. The reload task consist of a selector with two child tasks. The first task checks if the ammo count of the gun is bigger than zero. The second task does a delayed reload of the gun and fails if the player does not have any shotgun rounds left else it succeeds. The check if it really can reload is done in the reload task.

Shooting is basically a sequence of tasks. First, we check if the trigger is pulled and fail if not. If the trigger is pulled we launch the projectiles, this task does always succeed. After that, we wait until the trigger gets released to have a controlled shooting. After we release the trigger we check if there is still life ammo chambered and fail if so. In the case there is no life ammo anymore we wait a fraction of a second and eject two shells and succeed.

As you can see the shoot task also returns with fail or succeed this is important and has to be considered if you want to proceed after the shooting task with an additional task whatever this might be…

And here the complete behavior tree

Looks cool. The code of this behavior tree looks like this

        this.bb = new WeaponBlackboard(main, this);

        Sequence<WeaponBlackboard> reloading = new Sequence<>();
        reloading.addChild(new Wait(1.4f));
        reloading.addChild(new Reload());

        Selector<WeaponBlackboard> needReload = new Selector<>();
        needReload.addChild(new AmmoCount());
        needReload.addChild(reloading);

        Sequence<WeaponBlackboard> shoot = new Sequence<>();
        shoot.addChild(new DetectPullTrigger());
        shoot.addChild(new LaunchProjectile());
        shoot.addChild(new WaitUntilSuccess<>(new Invert(new DetectPullTrigger())));
        shoot.addChild(new Invert<>(new AmmoCount()));
        shoot.addChild(new Wait<>(0.6f));
        shoot.addChild(new EjectShell());

        Sequence<WeaponBlackboard> gun = new Sequence<>();
        gun.addChild(needReload);
        gun.addChild(shoot);

        this.bh = new BehaviorTree<>(gun, bb);

And in the update loop you call something like

bh.next()

It is so much easier to change the behavior or to adapt it. And a new weapon is done literally in no time. Even if I don’t use a graphical editor. It’s so much fun to model weapons with this approach.

Tasks and reusable code

Because we have capsulated the stuff into tasks, we can reuse these tasks for new weapons. Like DetectPullTrigger(), LaunchProjectile(), AmmoCount() and EjectShell(). And also very generic tasks and decorators like Wait(seconds), WaitUnitlSucceed(task), AlwaysSucceed(task) and Invert(task).

For our own tasks, we can handover a weapon blackboard where we keep together everything we need. The weapon itself implements an interface with the basic actions, like launch bullets, eject shells and reloading as this is very weapon specific.

So let’s conclude

The main message of this blog article is not the solution for the double-barrel shotgun. The main message is that you can use behavior trees beyond NPC AI. Whatever has a behavior can be modeled with a behavior tree even if it is not too obvious in the beginning. If you have a graphical behavior tree editor your game designers can model that part of the game directly and have instant feedback if their ideas work out or not.

I also model my controller and the level switching logic with a behavior tree approach. These parts are much easier to adapt and to extend now. It’s also very handy as you simply can try out all your weird ideas without a lot of coding. What makes it really really fun.

The end

That’s it, I hope you enjoyed it.