Category: AllFuckedUp

Lens #1: The Lens of Emotion

cli Leave a comment

The first article of my game design diary, probably not daily. If you have recommendations or ideas you want to share let me know in the comments section below.

I look through the first lens of the book The Art of Game Design: A Book of Lenses written by Jesse Schell on our game, the emotion lens. There are three questions

  • What emotion shall my player experience?
  • What emotion do they have now?
  • How can I bridge the gap between these emotions?

The player should experience a powerful feeling using the guns, it’s a gun porn game and everything should be around these guns and ammo. The better the experience of these guns the better.
Cute characters should provide a playful experience.
As well it should have a badass experience with those badass comments.

When I play the game using the guns is already very nice, the kickback (camera and player), shell ejection, and also the sound is nicely put together and it feels really good to fire the weapons. As well the enemies are easy to kill which makes the feel of powerful guns even stronger. I have to be care full not to rush to the more powerful guns as this is the trophy of finishing levels. I probably need a lot of guns
I need to add more cuteness to it, the heart emoji is just one that needs to be improved. I like the minion’s way of speaking, so I want to add more of that to improve that "it is cute" emotion.

To improve it I have the following points on my list

  • Add more bass
  • Improve the flashlight
  • Add more weapons
  • Design the levels that I can use the weapons a lot
  • Add badass comments
  • Add more cute sound and animations if we accomplished something.

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

cli Leave a comment

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.

Laughing While Shooting

cli Leave a comment

The little hero starts to laugh when shooting a lot. It is bound to the number of rounds per second to make him start laughing, every weapon has his threshold. Or when he shoots two or more targets in a row.

It makes the game more fun.

I’m thinking of more little animations like the love it animation for picking up ammo. Currently, I’m thinking of a cursing animation, unfortunately, I can not use the hits I get because we die too easy and I don’t want to change that. He curses when he stucks somewhere maybe. Or when he struggles with something.


New Design Of Our Hero on Our Shop

cli Leave a comment

We are exciting to promote our cute angry little hero on our shop. You can buy it as hoodie, t-shirt, bag, or cap and support on this journey to develop this cute looking game.


We are working on the cursing and love it animation which takes place in the game on certain activities, like the crazy laughter after shooting down two or more enemies in a row.

Player control

cli Leave a comment

I recently worked on my jumping abilities. In the beginning, I only could do double jumps. Whenever the player hits the ground he gots one extra jump which can be pretty handy and looks fun. But to jump from walls was very shaky and sometimes you had the extra jump and sometimes you didn’t because you jumped too late and used up that extra jump instead of a wall jump.

Again behavior tree

As with the weapons, it started pretty simple and straight forward by just program the player control. But for the double jump, I already had a counter in place which had to be updated and consumed. Motivated by the early success modeling weapons with a behavior tree implementation I start over the character control implementation with a behavior tree.
First I had to split my stuff into tasks to be able to model the walking and jumping behavior of the player with the libgdx-ai behavior tree

The main goals were walking, jumping, double jumps, and wall jumps. The wall jump was especially tricky.

Move

The moving part is simple, we just apply force on the character, limit the speed to max speed and turn the character in the proper direction. The character model implementation has an update loop where it detects/measures the speed to do the walk animation properly. We apply also force to the player midair to give the player more control.

One improvement would be to let the character look in the direction he is shooting in that case he would just move forth and back but would not change the shoot direction. This is especially for fully automatic weapons.

Double jump

The double jump was just something I saw in so many games and wanted it for mine as well.

As long you jump in the same direction as you walk, I only stop midair the vertical movement to give more control else it feels very wobbly. But the horizontal movement is untouched.

In case the player also changes the direction hitting the jump button mid-air I stop completely horizontal and vertical this makes the jumps more controllable and fun. You can do all the impossible jumps you ever dreamt of.

Wall jump

If the player pushes the jump button sticking to the wall or is close enough and has no ground underneath it he gets pushed away from the wall. Actually, the push from the wall is away and slightly upward, the character also changes its direction. If you hold the movement towards the wall the jumps out and moves back to the wall and the player doesn’t change its direction. The wall jumps are unlimited. This keeps the gameplay pretty fast. The stickiness to the wall is not very strong and you have to move fast.

As soon the player jumps on a wall the vertical movement goes to a full stop. This makes the wall jumps nice and responsive. I tried it without and it feels very fluffy.

The push from the wall should make it possible to jump up a corridor with just pressing the jump button all the time without any midair movements.

Shooting

The shooting part is pretty simple, it just triggers the gun. Maybe set a marker that the trigger is pulled so the player doesn’t change direction while shooting, see moving chapter above.

Dashing

I’m not yet sure if I and how I want to model dashing. It’s already pretty fast. And it should do something. Maybe dodge bullets or distract enemies. This is working in progress.

Keep on testing

I do a lot of testing these days. And with the behavior tree approach, I can easily change the behavior of the controls. The downside of changing the control behavior also often means that I have to rework the levels, just think of a slightly higher jump or slightly less high jump, a tiny bit less speed, new abilities like dashing. So what’s easy still has a rat tail of other implications.

But it is fun as hell.

Conclusion

The jump topic is very tricky and needs by fare more testing until I can say this is it.




Behavior Trees for Weapons

cli Leave a comment

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.