Lens #5: The Lens of Fun

The next lens I want to look through on our game "All Fucked Up" is the lens of fun 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 parts of the game are fun?
  • What parts of the game need to be more fun?

I add my latest sneak peek to document the current state. That might of course and hopefully change over time while improving the game.

I have cute and very simple characters. And using weapons is fun, it looks fun too. The main character is cute, stupid, mean, and funny, I borrowed that from the minions. The dead animation is simple but effective, just a blood and meat splatter for all destroyable characters and targets with a boom sound.

The levels are short and I will add a timer to the game, so that you get points for enemy hits, ammo left and time. That could add extra fun to beat the highscore.

The enemies look a bit 1 dimensional and boring. I would like to improve the soldiers’ behavior and add some funny animations. I like the way BroForce did his enemies, especially when you throw a hand grenade and the enemies are coming close with questions marks above their heads, hilarious. I probably will not copy that, but find other ways to make my enemies funny. One funny thing they offer is, if you are in the middle of two soldiers and jump, one of the soldiers starts to shoot and kills his buddy. That wasn’t intentional but it’s kind of funny that you can outplay them. But not sure if I will keep this "feature".


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

Lens #3: The Lens of the Venue

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

I look through the third lens, the lens of the venue from the book [The Art of Game Design: A Book of Lenses](https://amzn.to/2EWvFk3) written by [Jesse Schell](https://en.wikipedia.org/wiki/Jesse_Schell) at our game “All Fucked Up” and try to answer the following questions

* What kind of venue suits our game the best
* What kind of special properties does the venue have to support our game
* How do the elements of our game harmonize with the chosen venue

This is quite tricky for me and I hardly can get my head around it. My game is a single-player game so far as co-op isn’t something I was thinking about when I started the game. It might be fun to watch somebody playing this game similar to [Mario Bros Games](https://en.wikipedia.org/wiki/Super_Mario) which are both fun to play and fun to watch. The funny cute elements shall make it joyful to watch not only to play it.

This game might be playable as a console, PC, or mobile game. The levels are short and quickly played. The story is implicit.

Let me know in the comments what you think about this lens and if I interpreted it properly?

————

*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 #2: The Lens of Essential Experience

Today I look through the second lens, the lens of essential experience at our game "All Fucked Up". Due to the book The Art of Game Design: A Book of Lenses written by Jesse Schell, we have to answer three questions

  • What experience do I want the player to have?
  • What is essential to that experience?
  • How can I capture this essence in our game?

I have some difficulties to see the real difference to Lens #1: The Lens of Emotion to be honest. Our game is all about guns and ammo. The emotion was feeling powerful with those weapons. The essential experience is all about guns and collecting ammo. Ammo is not limitless, you collect that and you have to take care that you do not waste ammo. This is a bit contradictory as firing a gun and feel powerful is all about lens #1.

  • Collecting ammo
  • Don’t waste ammo as it is not limitless
  • Add the possibility to switch between two weapons (handgun and rifle for example)

The smart handling of a handgun and a rifle could be interesting, but then I need the advantage of the handgun over the rifle, currently, there is none. One idea I have is when I’m too close to the opponent the rifle will not fire and you only can fire a handgun. The handgun on the other side should have only little effect on distance. That way I could improve the essential experience I think.


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 #1: The Lens of Emotion

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

The Art of Game Design: A Book of Lenses

This book is an awesome guide with more than 100 lenses to look at your game. Written by Jesse Schell a professor of entertainment technology for Carnegie Mellon University’s Entertainment Technology Center (ETC).

I like the concept of the lenses in this book, it let you look at your game from different angles to assure you have a fun game in the end. The lenses are summarized in orange boxes which makes this book an awesome guide through your process crafting a fun game. It’s like having an instructor on tap.

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.

ECS Pattern: Damage System

Writing games is often about dealing with health and damage. With entity component system this is fun to do. Furthermore you can give any entity health or damage any time, it is literally only adding the health or damage or both component to that entity.

Bullets And Characters

To handle health and damage we need health, damage, position, and shape components for the involved entities. A bullet usually does have a damage component besides a position and its shape. A character usually does have a health component besides a position and its shape. The damage system handles these entities and calculates the new damage and health of the involved entities. I usually remove the damage entity a soon it hits something, but if you think of a spell or an ax this is not necessarily true. For a bullet, you might add a very short decay component to let the bullet have a physical impact on the body it hits (read here about the decay pattern) before it vanishes.

A Monkey And Doctor Zaius

For this example I use jMonkeyEngine and Zay-ES. Zay-ES features EntityContainer with an update method which takes care of all created, updated and deleted entity and it provides an array of all entities which are currently in the set (not removed). This makes the code super easy. If your ECS system doesn’t have then you probably have to do a bit more leg work.

Components

I shortly introduce the components we will need. The components are pure data without methods that operate on this data which is very different from the OO programming paradigm.

Health

We just store the amount of health in this component. Furthermore, we define -1 as immortal (for concrete walls for example).

public class Health implements EntityComponent {
    static public int IMMORTAL = -1;
    private Integer health;
    public Health(Integer health) {
        this.health = health;
    }
    public Integer getHealth() {
        return health;
    }
}

Damage

We store the amount of damage in this component, that’s it.

public class Damage implements EntityComponent {
    private final int damage;
    public Damage(int damage) {
        this.damage = damage;
    }
    public int getDamage() {
        return damage;
    }
}

Position

And the position component holds the current 3D location (read my first ECS post how to move objects around).

public class Position implements EntityComponent {
    private final Vec3d location;
    public Position(Vec3d loc) {
        this.location = loc;
    }
    public Vec3d getLocation() {
        return location;
    }
}

Shape

And then finally the shape. To make our life simple we just have sphere objects with a radius.

public class SphereShape implements EntityComponent {
    private double radius;
    public SphereShape(double radius) {
        this.radius = radius;
    }
    public double getRadius() {
        return radius;
    }
}

Damage Entity Set

In the damage system we keep two sets of entities. The first set called the DamageContainer handles all entities with a position, shape and damage component.

    private class DamageData {

        EntityId entityId;
        AABB aabb;
        Vec3d location;
        int amount;
    }

    private class DamageContainer extends EntityContainer<DamageData> {

        DamageContainer(EntityData ed) {
            super(ed, Damage.class, Position.class, SphereShape.class);
        }

        Stream<DamageData> stream() {
            return Arrays.stream(getArray());
        }

        @Override
        protected DamageData addObject(Entity entity) {
            DamageData result = new DamageData();
            result.entityId = entity.getId();
            result.amount = entity.get(Damage.class).getDamage();
            updateObject(result, entity);
            return result;
        }

        @Override
        protected void updateObject(DamageData data, Entity entity) {
            SphereShape sphereShape = entity.get(SphereShape.class);
            data.location = entity.get(Position.class).getLocation();
            Vector2 center = new Vector2(data.location.x, data.location.y);
            data.aabb = new AABB(center, sphereShape.getRadius());
        }

        @Override
        protected void removeObject(DamageData t, Entity entity) {
        }
    }

The data we want is the entity id (to be able to get rid of), the location, amount of damage, and an AABB object for simple collision calculation.

Health Entity Set

On the other hand, we have the health set we call it HealthContainer and it goes like this

    private class HealthData {

        EntityId entityId;
        AABB aabb;
        int amount;
    }

    private class HealthContainer extends EntityContainer<HealthData> {

        HealthContainer(EntityData ed) {
            super(ed, Health.class, Position.class, RectangleShape.class);
        }

        Stream<HealthData> stream() {
            return Arrays.stream(getArray());
        }

        @Override
        protected HealthData addObject(Entity entity) {
            HealthData result = new HealthData();
            result.entityId = entity.getId();
            result.amount = entity.get(Health.class).getHealth();
            updateObject(result, entity);
            return result;
        }

        @Override
        protected void updateObject(HealthData data, Entity entity) {
            SphereShape sphereShape = entity.get(SphereShape.class);
            data.location = entity.get(Position.class).getLocation();
            Vector2 center = new Vector2(data.location.x, data.location.y);
            data.aabb = new AABB(center, sphereShape.getRadius());
        }

        @Override
        protected void removeObject(HealthData t, Entity entity) {
        }
    }

The data we want is the same as for the DamageContainer, the entity id (to be able to get rid of it as well), the location, amount of health and an AABB object for simple collision calculation.

The Update Loop

In the update loop we now update the HealthContainer and the DamageContainer and then we loop over all health entities and inside that we loop over all damage entities and calculate the new Health and Damage component. In our case, we remove the Damage component from the entities on collision and only calculate the new Health component.

   @Override
    public void update(float tpf) {
        healthConatiner.update();
        damageContainer.update();

        healthConatiner.stream().forEach(h -> {
            damageContainer.stream()
                    .filter(d -> !d.parentId.equals(h.entityId))
                    .filter(d -> d.aabb.overlaps(h.aabb))
                    .forEach(d -> {
                        handleHealthAndDamage(h, d);
                    });
        });
    }

Calculus

Let’s look into how we handle health and damage. First we check if the health entity is immortal like a concrete wall and skip the calculation. If the health entity is not immortal we calculate the new health and remove the health entity if the health is equal or below zero. In the end we remove the damage entity as it is used up on collision.

    private void handleHealthAndDamage(HealthData health, DamageData damage) {
        if (health.amount != Health.IMMORTAL) {
            health.amount = health.amount - damage.amount;
            if (health.amount > 0) {
                ed.setComponent(health.entityId, new Health(health.amount));
            } else {
                ed.removeEntity(health.entityId);
            }
        }
        ed.removeEntity(damage.entityId);
    }

Benefit

If your game designer has the famous idea at the last minute possible that your weapons should also be able to destroy the furniture you will not spend hours or days making this happen as you simply can add health to these furniture entities and you are done. Because the code is already in place which handles these entities on collision. This is the actual beauty of the entity component system.

I’m Reading

I’m currently reading the self-published Data Oriented Design from Richard Fabian to get me a deeper insight how to design games with entity component system or as the book title says data-oriented design. A very interesting and cool topic so much different from what I learned with OO approaches. Data-oriented design not only improves the execution time but also your developing performance. Counts especially for games with its short update cycle and the game data which is changing constantly.

The End

You can extend and tweak this example as you like. Go wild.

In case you have questions or suggestions, let me know in the comments below.

History Back and Forth

Whenever you write a level editor or maybe a turn-based game (like chess) it would be of great help having undo and redo functionality at hand.

Based on the Game Programming Patterns book from Robert Nystrom I did like to implement an undo/redo history class. The design pattern is based on the Design Patterns book of the gang of four.

Side Note

I use this programming pattern for my test-driven development workshop, I do occasionally. If you are interested in that, just let me know in the comments below.

Implementation

Introduction

A command can be anything from move one square to shoot, cast a spell, and more. The command must encapsulate everything needed to execute and to undo his action. Every command is an own instance. The commands then get stored in a history object which I will show you in this blog post.

Command Interface

The whole thing starts with a command interface which looks like this

package mygame;

public interface Command {
    public void execute();
    public void undo();
}

The only thing you need in command is execute and undo. With that, you can even make a redo. Really?

History Execute, Undo, and Redo

I’ll show you the idea of the history implementation.

package myexample;

public History {
    public void execute(Command command) {}
    public void undo() {}
    public void redo() {}
}

To make the whole thing work you need to encapsulate everything needed to execute the command in your command object, which is of great importance.

For the implementation of the history class, I used LinkedList as it was the simplest way I found for this. Of course, you can implement as well some ring buffer structure using plain arrays, but I did not have the nerve for this.

Ok, let’s start with the basics. First of all, we need to execute the command like this

public void execute(Command command) {
    command.execute();
}

That wasn’t too hard, but to be able to undo it, we need to hold that command instance in a data structure, a linked list in my case.

    private LinkedList<Command> commands;
    public History(int size) throws InstantiationException {
        commands = new LinkedList<>();
    }

    public void execute(Command command) {
        commands.add(command);
        command.execute();
    }

    public void undo() {
        commands.removeLast().undo();
    }

Oh, wait what if I undo when the list is empty? Yes, it fails, so we need some guards to protect it.

    public void undo() {
        if (!commands.isEmpty()) {
            commands.removeLast().undo();
        }
    }

Improvments

That looks not that bad and it works already. But let’s improve it a little more. For example, does this implementation not limit the number of commands in our history, so let’s introduce a size.

    private int size;

    public History(int size) throws InstantiationException {
        if (size == 0) {
            throw new InstantiationException("0 is not a valid history size");
        }
        this.size = size;
        commands = new LinkedList<>();
    }

And now we have to improve the execute method with this size information, by dropping the first command f we hit the capacity of our history.

    public void execute(Command command) {
        if (commands.size() >= size) {
            commands.removeFirst();
        }
        commands.add(command);
        command.execute();
    }

Redo

A redo would be cool and it turns out to be very simple. We need a second linked list for book-keeping.

    private LinkedList<Command> redoCommands;
    public History(int size) throws InstantiationException {
        // ...
        redoCommands = new LinkedList<>();
    }

Then we have to store all undoed commands in that redoCommands list.

    public void undo() {
        if (!commands.isEmpty()) {
            Command command = commands.removeLast();
            redoCommands.add(command);
            command.undo();
        }
    }

Now we are prepared for the redo method

    public void redo() {
        if (!redoCommands.isEmpty()) {
            execute(redoCommands.removeLast());
        }
    }

One small problem we have to solve, what if we did undo 2 times and then call execute and after that call redo? Yeah, it will end up in redo commands which actually should be cleared. So let’s clear the redo command list on execute. This is not that easy as the redo itself calls execute to have the command book-keeping for free. The easiest way is to have an internal execute which is called by execute and redo and only execute clears the redo commands list.

    public void execute(Command command) {
        redoCommands.clear();
        internalExecute(command);
    }

    public void redo() {
        if (!redoCommands.isEmpty()) {
            internalExecute(redoCommands.removeLast());
        }
    }

    private void internalExecute(Command command) {
        if (commands.size() >= size) {
            commands.removeFirst();
        }
        commands.add(command);
        command.execute();
    }

Copy & Paste Code

And to make it a simple copy&past task to take this into your project here the things you need

package myexample;

import java.util.LinkedList;

public class History {

    private LinkedList<Command> commands;
    private LinkedList<Command> redoCommands;
    private int size;

    public History(int size) throws InstantiationException {
        if (size == 0) {
            throw new InstantiationException("0 is not a valid history size");
        }
        this.size = size;
        commands = new LinkedList<>();
        redoCommands = new LinkedList<>();
    }

    public void execute(Command command) {
        redoCommands.clear();
        internalExecute(redoCommands.removeLast());
    }

    public void redo() {
        if (!redoCommands.isEmpty()) {
            internalExecute(redoCommands.removeLast());
        }
    }

    public void internalExecute(Command command) {
        if (commands.size() >= size) {
            commands.removeFirst();
        }
        commands.add(command);
        command.execute();
    }

    public void undo() {
        if (!commands.isEmpty()) {
            Command command = commands.removeLast();
            redoCommands.add(command);
            command.undo();
        }
    }
}

That’s it, folks.

Related Books

This design pattern is based on these two books, I have both ot them, I like the game programming patterns better than the original but the orignal is almost a must have a for any programmer.

Game Programming Patterns

I recently read Game Programming Patterns from Robert Nystrom one of the best books about programming I’ve ever read.


I get commissions for purchases made through the following link


I read the entire book from beginning to end in one go, I couldn’t stop. Normally I use programming books to fall asleep, the design pattern book of the gang of four doesn’t make any exception.

The book Game Programming Pattern from Robert Nystrom on the other hand is one of those very rare books which keeps me awake even late in the night. It is crispy, fun and it explains you the design patterns in a fresh and understandable way. It is also helpfull if you are not a game programmer as it explains the design patterns from the gang of four from a different perspective than you know from your daily work.

The author starts always simple without a pattern until he ends up in a dead end and solve the problem by applying graduadly the corresponding pattern which makes it so easy to understand the patterns in all his depts. It’s a very practical approach and even the samples are in C++ they can be easily adapted to any other language.

One of my favorit one is the command pattern with history functionality. Very use full for level construction tools.

If you are interested in design patterns and don’t like the original one, give this one a try.