Lesson 22: Ways to Spend Gold: Unlocking / Upgrading characters

So in the previous lesson we’ve implemented a way to collect gold, an in-game resource. But the trouble is: there’s no way to spend it yet. Let’s fix it today!

I am planning to do two things today: make characters unlockable and enable „upgrade” button for unlocked characters. All characters (except for human) are going to be locked by default. As soon as player collects 1000 gold – he can unlock a character. The amount of gold is up to you. I think 500 is a good amount, because we’ll be able to introduce In-App-Purchases later which would grant enough gold, but also player can gather enough once he played some time (without paying a dime).

Alright, so let’s modify our progress file first. We’re going to adjust it gradually, according to the changes what we are making. First thing that we are going to do, let’s make a separate array of levels of each character. 0 will mean that the character is locked, any value above that will simply mean character level (1+). Introduce the following constants / variables:

public static final int CHARACTER_PRICE = 1000; // price to unlock a character

public static int levels[]; // level of each character, 0 = locked

private static final String SAVE_KEY_PLAYER_LEVEL = "playerlevel";

We’re going to init the array in our Load function. Since we are saving/loading multiple values, we’re simply going to add an index to the key.

public static void Load()
{
    levels = new int[CharacterRecord.CHARACTERS.length];

    Preferences prefs = Gdx.app.getPreferences(PROGRESS_SAVE_NAME);

    for (int i = 0; i < CharacterRecord.CHARACTERS.length; i++)
    {
        levels[i] = prefs.getInteger(SAVE_KEY_PLAYER_LEVEL + i, i == 0 ? 1 : 0);
    }

Something similar goes to saving. In our Save() function, add the following code:

for (int i = 0; i < CharacterRecord.CHARACTERS.length; i++)
{
    prefs.putInteger(SAVE_KEY_PLAYER_LEVEL + i, levels[i]);
}

This should do it for saving/loading. Now that the backend is (somewhat) handled – let’s adjust the menu to allow the magic to happen!

So, first, let’s modify our “Start” button to be replaced with “Unlock” button if character is locked. The code is pretty simple:

if (GameProgress.levels[GameProgress.currentCharacter] == 0)
{
    TextButton startBtn = new TextButton("Unlock(1000 Gold)", buttonStyle);
    startBtn.setPosition((uiStage.getWidth() - startBtn.getWidth()) / 2, uiStage.getHeight() / 6);
    startBtn.addListener(new ClickListener() {
        public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
            if (GameProgress.currentGold >= GameProgress.CHARACTER_PRICE)
            {
                GameProgress.currentGold -= GameProgress.CHARACTER_PRICE;
                GameProgress.levels[GameProgress.currentCharacter] = 1;
                prepareUi();
            }
        }
    });
    uiStage.addActor(startBtn);
}
else
{
    // start / upgrade button code goes here
    TextButton startBtn = new TextButton("START", buttonStyle);
    startBtn.setPosition((uiStage.getWidth() - startBtn.getWidth()) / 2, uiStage.getHeight() / 6);
    startBtn.addListener(new ClickListener() {
        public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
            dispose();
            game.setScreen(new GameScreen(game));
        }
    });
    uiStage.addActor(startBtn);
}

We just add a different button in case the character is locked.

You might have noticed that we have to call uiStage.clear() before every prepareUi call. So, this is redundant. Let’s simply move uiStage.clear() to the beginning of prepareUi() and remove all other uiStage.clear() calls on this screen.

Run the game and try switching characters. If you set the CHARACTER_PRICE to lower value for debugging purposes and try unlocking a character – you’ll see that it becomes available.

After that, let’s get to upgrade button. But first, I think it makes sense if we add a label with character level or just a warning (“char locked!”). First, move textStyle declaration/initialization on top of our prepareUi function, right above the buttonStyle declaration.

Now, let’s make a new label, after our heroSprite definition. (Because we’re going to use that as an orientation / position settings).

uiStage.addActor(heroSprite);

// char level
int lvl = GameProgress.levels[GameProgress.currentCharacter];
Label statusText = new Label(lvl > 0 ? "LVL: " + lvl : "LOCKED", textStyle);
statusText.setPosition(heroSprite.getX() + (heroSprite.getWidth() - statusText.getWidth()) / 2,
        heroSprite.getY() - statusText.getHeight() - 5);
uiStage.addActor(statusText);

Now we can finally get to upgrade button. You might have noticed, that the interface is getting a bit overcrowded. Let’s move the start button to the top and levelup button to the bottom (where there’s Unlock button for locked chars).

Here’s how the code looks like:

else
{
    // start / upgrade button code goes here
    TextButton startBtn = new TextButton("START", buttonStyle);
    startBtn.setPosition((uiStage.getWidth() - startBtn.getWidth()) / 2, uiStage.getHeight() * 5 / 6);
    startBtn.addListener(new ClickListener() {
        public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
            dispose();
            game.setScreen(new GameScreen(game));
        }
    });
    uiStage.addActor(startBtn);


    TextButton upgradeBtn = new TextButton(
            "LvlUp(" + GameProgress.getNextUpgradeCost(GameProgress.currentCharacter) + ")",
            buttonStyle);
    upgradeBtn.setPosition((uiStage.getWidth() - upgradeBtn.getWidth()) / 2, uiStage.getHeight() / 6);
    upgradeBtn.addListener(new ClickListener() {
        public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
            if (GameProgress.currentGold >= GameProgress.getNextUpgradeCost(GameProgress.currentCharacter))
            {
                GameProgress.currentGold -= GameProgress.getNextUpgradeCost(GameProgress.currentCharacter);
                GameProgress.levels[GameProgress.currentCharacter] += 1;
                prepareUi();
            }
        }
    });
    uiStage.addActor(upgradeBtn);
}

The start button code pretty much remains unchanged, except for Y position, which has moved to top of the screen.

UpgradeBtn is similar to start button, but it invokes getNextUpgradeCost function (will get to it later). The position is the same as the old “start” button position. The click function acts in a similar way, checks the next level upgrade cost and if it’s fine – takes the money and increases the character level. Looks good? Let’s go to GameProgress and define the function to get next level cost. As an experiment, I think it’s fine if we multiply the current level value by 2.

public static int getNextUpgradeCost(int currentCharacter) {
    return levels[currentCharacter] * 2;
}

I’ve also noticed a bug, CharacterSelectionScreen does not have resize handling, so resizing gets ugly. Let’s fix that!

@Override
public void resize(int width, int height)
{
    super.resize(width, height);
    uiStage.getViewport().update(width, height, true);
}

Run the game! If you have some gold already – upgrade your character. For now, the upgrade is only visual, but don’t get upset – we’re going to fix this in the next lesson! See you then.

Git commit: https://github.com/vladimirslav/dodginghero/commit/564990aeed19a887e568666bf85d9b52865c7466

Lesson 21: Gold Gathering

Last lesson, we’ve added multiple characters and made it possible to pick them. We’ve also introduced  the levelling stats. Unfortunately, since there are no levels, there’s no point of stats.

First thing’s first, how are we going to level up our characters? Well, this is quite easy! They’ll have to push the “Upgrade” button! What’s that? We cannot simply allow player to mash the upgrade button? Fine, we’ll introduce in-game currency to solve the issue of infinite upgrading.

First thing: we’ll add a coin that can be picked on the battlefield. Yes, similar to health / attack. Here’s how it looks (drawn by https://twitter.com/ElenaNazaire):

First, go to our Bonus.java file. Add a new static byte to mark our coin bonus.

public static byte BONUS_TYPE_COIN = 2;

In our “setup” function, add a case for bType == BONUS_TYPE_COIN:

else if (bType == BONUS_TYPE_HEALTH)
{
    set(res.healthBonus);
}
else if (bType == BONUS_TYPE_COIN)
{
    set(res.coinBonus);
}

You’ll notice that coinBonus is not defined yet. That’s allright. Go to Resources class and right under our healthBonus sprite, define a new sprite:

public Sprite healthBonus;
public Sprite coinBonus;

Then, down below, load it the same way you would load healthBonus.

healthBonus = gameSprites.createSprite("health");
coinBonus = gameSprites.createSprite("coin");

Now, make sure we create the bonus in-game. In GameLogic, let’s adjust oru SpawnBonus function. Now if you’ve played the game as much as I did, you can already notice that hearts spawn a bit too much. Let’s reduce their rate and increase the attack spawn rate a bit. Say, 5 out of 8 times we want attacks, 2 out of 8 times we want coins and 1 time we want health bonus.

Replace this part:

bonuses.add(Bonus.Create(fx,
        fy,
        MathUtils.random(3) < 1 ? Bonus.BONUS_TYPE_HEALTH : Bonus.BONUS_TYPE_ATTACK,
        game.res));

With:

byte activeBonus = Bonus.BONUS_TYPE_ATTACK; // use it by default
int rnd = MathUtils.random(7); // 0 .. 7
if (rnd > 6)
{
    activeBonus = Bonus.BONUS_TYPE_HEALTH;
}
else if (rnd > 4)
{
    activeBonus = Bonus.BONUS_TYPE_COIN;
}

bonuses.add(Bonus.Create(fx,
        fy,
        activeBonus,
        game.res));

Use attack bonus by default, then in a few special cases switch it to health and coins. Let’s run the game! You now see that the coins are spawning, but picking them does nothing. Let’s fix that!

Handling the logic behind coins

Great, so what do we do now? How do we make coins work? We need to introduce a separate variable that would store the coins. Let’s handle it in GameProgress.

public static int currentGold = 0;

Add saving/loading at once.

private static final String SAVE_KEY_PLAYER_GOLD = "playergold";

In our Load() function, let’s handle the loading of our gold:

currentGold = prefs.getInteger(SAVE_KEY_PLAYER_GOLD, 0);

And a bit further, in our Save() function, let’s handle the proper saving of the value!

prefs.putInteger(SAVE_KEY_PLAYER_GOLD, currentGold);

Good, the gold is saved, but it is not gathered properly. Time to implement that. Remember, in our GameLogic class, we have the AssignPlayerPosition function? In it, we process the bonus pickups. Let’s alter it to actually handle the coin pickups. Here’s how my full check looks now:

if (currentBonus.getBonusType() == Bonus.BONUS_TYPE_HEALTH)
{
    player.addLives(1);
}
else if (currentBonus.getBonusType() == Bonus.BONUS_TYPE_ATTACK)
{
    enemy.takeDamage(GameProgress.playerDamage);
    if (enemy.getLives() <= 0)
    {
        GameProgress.currentLevel++;
        player.markVictorious();
        eventListener.OnGameEnd(true);
    }
}
else if (currentBonus.getBonusType() == Bonus.BONUS_TYPE_COIN)
{
    GameProgress.currentGold += 1;
}

That should do it.

Displaying the coin amount to the player

Now let’s ensure we display our coins both in GameScreen and CharacterSelectionScreen.

Start with CharacterSelectionScreen. We want to display coins on the bottom left side of the screen. To do this, we’ll show the coin image and write amount of coins we have beside it. Open our CharacterSelectionScreen class. Go to prepareUi() function, and add the following lines to the end of it:

// coin image
Image coinImage = new Image(game.res.coinBonus);
coinImage.setPosition(1, 1);
uiStage.addActor(coinImage);

// amount of coins
Label.LabelStyle textStyle = new Label.LabelStyle(game.res.gamefont, Color.WHITE);
Label coinAmntLbl = new Label("" + GameProgress.currentGold, textStyle);

// set X position to the right of our coin and Y to be exactly in the middle of it
coinAmntLbl.setPosition(coinImage.getX() + coinImage.getWidth() + 3,
        coinImage.getY() + (coinImage.getHeight() - coinAmntLbl.getHeight())/ 2);
uiStage.addActor(coinAmntLbl);

Now let’s add it in our GameScreen now. Since we don’t use Stage in gamescreen for ui elements, let’s just draw it “roughly”. Go to our DrawUi function and add the following code:

batch.draw(game.res.coinBonus,
        gameStage.getViewport().getScreenX() + 2,
        gameStage.getViewport().getScreenY() + 5
);
DrawShadowed("" + GameProgress.currentGold,
        gameStage.getViewport().getScreenX() + game.res.coinBonus.getWidth() + 4,
        gameStage.getViewport().getScreenY() + 10 + game.res.coinBonus.getHeight() / 2,
        gameStage.getWidth() - 5,
        Align.left,
        Color.WHITE);

Pretty self-explanatory, first we draw a coin, then: the amount of gold we actually have. Run the game! You’re going to see the coins on our main screen and in the game, as well as notice how the amount increases after you pick them.

This took a bit more time and changes that I’ve expected, so I’ll try to cover levelling in our next tutorial.

Relevant git commit: https://github.com/vladimirslav/dodginghero/commit/6eb79301a6ce8727379edc00b431c6a17b6ff506

Tags:

Android game tutorial, game development, multiplatform game development, beginning game development, gamedev tutorial, libgdx, android gamedev

Lesson 20: Introducing Character Variety and Upgrade system

So as you’ve seen in our previous lesson, we had added the character select screen. Unfortunately, there were no characters to select 🙂 Let’s fix that!

What do we need? We’ll need a data structure to describe each character’s stats. We can do the following: introduce multiple characters and make them upgradable for game currency. The trick is: each character has its own strongpoints. I.e. one character will be getting +1 health after every upgrade, the other: after every two, another one: after every three. Same goes for attack strength from picking relevant bonus and for hp regeneration (how much hp you restore from picking hearts). That way we can create a character that restores lots of hp, but has small healthpool. Or the character that does lots of damage, but has trouble with hp regeneration.

In our logic/objects package, create a new class and name it “CharacterRecord.” I suggest we make four different stats:

• Upgrade levels needed for hp upgrade (player buys one upgrade level, the character’s hp upgrades after every N levels). Similar to that:
• Upgrade levels needed for hp regen upgrade (how much hp player regenerates per heart picked?)
• Upgrade levels needed for attack upgrade (how much damage player deals per attack?)
• Upgrade levels needed for bonus time upgrade (let’s make bonus spawn time dependant on player’s character!)

Obviously, each character will also need a name (at least for display purposes on the menu). CharacterRecord will store the base stats, but not the level by itself. So, it should be simple, really. We can create a simple constructor and pre-define the characters this way:

public class CharacterRecord {

    public final int levelsForHpUpgrade;
    public final int levelsForHpRegenUpgrade;
    public final int levelsForAttackUpgrade;
    public final int levelsForBonusSpawnUpgrade;

    public final String name;

    public CharacterRecord(int lvlHp, int lvlRegen, int lvlAttack, int lvlBonus, String _name)
    {
        levelsForHpUpgrade = lvlHp;
        levelsForHpRegenUpgrade = lvlRegen;
        levelsForAttackUpgrade = lvlAttack;
        levelsForBonusSpawnUpgrade = lvlBonus;
        name = _name;
    }

    public static String CHAR_NAME_HUMAN = "Human";
    public static String CHAR_NAME_SPIDER = "Spider";
    public static String CHAR_NAME_SKELETON = "Mr.Skeletal";
    public static String CHAR_NAME_GHOST = "Ghost";
    public static String CHAR_NAME_SLIME = "Slimey";

    public static CharacterRecord CHARACTERS[] =
    {
        new CharacterRecord(2, 2, 4, 4, CHAR_NAME_HUMAN),
        new CharacterRecord(3, 6, 3, 3, CHAR_NAME_SPIDER),
        new CharacterRecord(6, 12, 1, 3, CHAR_NAME_SKELETON),
        new CharacterRecord(4, 4, 2, 4, CHAR_NAME_GHOST),
        new CharacterRecord(3, 3, 4, 1, CHAR_NAME_SLIME),
    };
}

My general character idea is:

• Human has good health, but not so good attack / bonus spawn rate.
• Spider gets good health, but bad regen. Better attack than human, but bonus spawn times are getting upgraded slower.
• Skeleton is terrible at health/healing, but does good damage at good intervals.
• Ghost is mostly average. Good stats, but nothing exceptional.
• Slime has amazingly fast bonus spawns and a bit wors stats otherwise.

Adjusting the character selection screen

Before we actually make stats relevant, we’ll have to create different character selection at first. So we have some stats pre-defined, but what do we do now? Let’s actually start by allowing to select different characters. Before we even talk about swapping active character index, let’s discuss how we get the relevant character sprite and name to be displayed in our CharacterSelectionScreen. I suggest we start working on resources class. Similar to the way we return enemySprites, we should make a hashmap that stores player sprites. This time, I’m making it with <String,Sprite> pair (as I am going to use it sparcely), but I must let you know that using strings as lookup won’t do if you do some real-time rendering and not single sporadic lookups. It just takes a big hit on performance (alright, it probably depends on the implementation of hashmap, but I won’t go that deep in this tutorial).

Open up our Resources.java class. Right beside our enemySprites declaration, declare another Hashmap:

public HashMap<String, Sprite> playerSprites;

This will store various player sprites. Initialize it at the same place where you initialize the enemySprites. Then fill it with relevant content.

playerSprites = new HashMap<String, Sprite>();
playerSprites.put(CharacterRecord.CHAR_NAME_HUMAN, gameSprites.createSprite("player"));
playerSprites.put(CharacterRecord.CHAR_NAME_SPIDER, gameSprites.createSprite("spider"));
playerSprites.put(CharacterRecord.CHAR_NAME_SKELETON, gameSprites.createSprite("skeleton"));
playerSprites.put(CharacterRecord.CHAR_NAME_GHOST, gameSprites.createSprite("ghost"));
playerSprites.put(CharacterRecord.CHAR_NAME_SLIME, gameSprites.createSprite("slime"));

That should do it.

Making character selection work

OK, we got player sprite list. What do we do? Go to CharacterSelectionScreen. We’ll need to adjust a few things. First, move currentCharacter variable into GameProgress class:

public class GameProgress {

    public static int currentCharacter = 0;

This is necessary, because we’re going to save the selected character (a bit later). Go back to our CharacterSelectionScreen. See our hero image creation in prepareUi()? Let’s make heroSprite be initialized with the current selected character’s sprite.

Image heroSprite = new Image(
        game.res.playerSprites.get(CharacterRecord.CHARACTERS[GameProgress.currentCharacter].name)
);

Also, remove the line

currentCharacter = 0;

From constructor. Try running the game. You should see the good old human sprite. The difference is that we’re looking it up from our hashmap instead of directly providing it to our heroSprite Image. With that, the preparations are mostly done. Let’s finally get to switching the active character sprite! All we need to do is to add listeners to nextBtn and prevBtn (which are somewhat similar).

TextButton nextBtn = new TextButton(">>>", buttonStyle);
nextBtn.addListener(new ClickListener() {
    public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
        GameProgress.currentCharacter += 1;
        if (GameProgress.currentCharacter == CharacterRecord.CHARACTERS.length)
        {
            GameProgress.currentCharacter = 0;
        }
        uiStage.clear();
        prepareUi();
    }
});

nextBtn.setPosition(uiStage.getWidth() * 5 / 6 - nextBtn.getWidth() / 2, uiStage.getHeight() / 2);
uiStage.addActor(nextBtn);

TextButton prevBtn = new TextButton("<<<", buttonStyle);
prevBtn.addListener(new ClickListener() {
    public void touchUp (InputEvent event, float x, float y, int pointer, int button) {
        GameProgress.currentCharacter -= 1;
        if (GameProgress.currentCharacter < 0)
        {
            GameProgress.currentCharacter = CharacterRecord.CHARACTERS.length - 1;
        }
        uiStage.clear();
        prepareUi();
    }
});
prevBtn.setPosition(uiStage.getWidth() / 6 - prevBtn.getWidth() / 2, uiStage.getHeight() / 2);
uiStage.addActor(prevBtn);

Just to explain a bit: we assign click listeners to next/prev buttons. What we do is increase/decrease current character index. If it is out of bounds – go to the beginning/end of the list (to allow player scrolling through the characters without limitation). After that, we clear all Ui elements from the stage and reinitialize them. This might seem like an overkill (we just have to switch the heroSprite, right? But in truth this won’t be the only thing later on (when we’ll be writing stats on the main screen). So we clear all the ui elements from the screen and then repopulate it again.

Now as the final thing for this tutorial part, let’s just make out GameScreen to show the new selected sprite (but not be affected by the stats in any way).

Go to our Player.java file, and replace

set(res.player);

In player’s constructor with:

set(res.playerSprites.get(CharacterRecord.CHARACTERS[GameProgress.currentCharacter].name));

Run the game and try picking any character! You should see that our player character sprite has successfully changed. That concludes lesson 20! Next time, we’ll actually try to make those stats affect the game and introduce the upgrade/unlock system.

Relevant git commit: https://github.com/vladimirslav/dodginghero/commit/62d13eecf8b7d3a016d973276b7bf6af0c2515b0

Our game starts to take shape – let’s adjust the gameplay by adding multiple enemies with different attacks!

Loading the sprites

After developing the persistence and basic progression, it’s time to diversify the gameplay: our enemy quickly becomes boring. I think it makes sense to adjust the attack patterns.

Let’s cut out 4 new characters from our character spritesheet. (We’ve used it before: http://opengameart.org/content/tiny-16-basic )

Here’s what I have:

My idea is to make different attack patterns for different enemies. We have vertical lines for spider. Let’s make horizontal lines for ghost, diagonal lines for bat, random attack pattern for slime and all four possibilities for skeleton.

Before we load the resources in game, let’s adjust the Resources and Enemy class constructor: it is going to accept the type of enemy now. In our Resources class, make a public static final int constants, that would enumerate the enemy types.

public static final int ENEMY_VERTICAL = 0;
public static final int ENEMY_HORIZONTAL = 1;
public static final int ENEMY_DIAGONAL = 2;
public static final int ENEMY_RANDOM = 3;
public static final int ENEMY_UNIVERSAL = 4;

We are using the int’s instead of Enum because there’s no easy way in java to convert int to enum (and we are going to generate a random int to determine enemy type). Now, add the type variable to our Enemy class and adjust the Enemy constructor.

public final int type;

public Enemy(Resources res, EnemyAttackListener listener, int _type)
{
    super(GameProgress.getEnemyLives());
    type = _type;

Depending on type, we’re going to load the appropriate enemy sprite. Now, to load them, we could declare 5 different sprites, but let’s think of a more optimal approach (so it would be easy to lookup later). In our Resources class, Let’s remove our enemy sprite declaration. Instead, let’s make a HashMap of &lt;Integer, Sprite&gt; pair, which would link our enemy type integers to actual enemy sprite.

public HashMap<Integer, Sprite> enemySprites;

Remove our enemy sprite loading line of code in Resources constructor. Instead of this, let’s initialize the enemySprites HashMap and fill it with values:

enemySprites = new HashMap<Integer, Sprite>();
enemySprites.put(ENEMY_VERTICAL, gameSprites.createSprite("spider"));
enemySprites.put(ENEMY_HORIZONTAL, gameSprites.createSprite("ghost"));
enemySprites.put(ENEMY_DIAGONAL, gameSprites.createSprite("bat"));
enemySprites.put(ENEMY_RANDOM, gameSprites.createSprite("slime"));
enemySprites.put(ENEMY_UNIVERSAL, gameSprites.createSprite("skeleton"));

A bit repetitive, but I’m sure it will pay off 🙂 Now, let’s actually go to Enemy class and replace the

set(res.enemy);

command with something more advanced:

set(res.enemySprites.get(type));

We grab the sprite according to the type. Careful! In bigger projects, it’s better to create a getter function, which would check if enemySprites has the value of (type) first, in order to avoid nasty errors of all sorts when you add a new enemy.

Let’s make an in-between test run. However, the game won’t compile now. That’s because we’ve changed the Enemy constructor. In our GameLogic, when we create a new Enemy object, let’s add an extra parameter:

enemy = new Enemy(game.res, this, MathUtils.random(Resources.ENEMY_UNIVERSAL));

The enemy is going to be chosen randomly. Run the game. Repeat it a few times. The enemy sprite should be randomly chosen on launch now. Also, if you defeat an enemy (and progress to the next round), the enemy is chosen randomly too. Pretty cool, huh?

Adjusting the attack time

Meanwhile, let’s reduce the time between enemy attacks to make the game more dynamic. First, let’s save the player from being attack as the round starts. Add the constant:

private static final float WARM_UP_TIME = 2.0f;

Adjust the enemy update function a bit, the moment when we determine to attack:

if (timeAlive > WARM_UP_TIME && timeSinceAttack > nextAttackTime)
{

You can see that I’ve added the first condition: we don’t want an enemy to attack for the first two seconds, let’s call it a warm-up time for player to understand that the game started / level changed.

Then, change

private static final float BASE_ATTACK_TIME = 3.0f;

To

private static final float BASE_ATTACK_TIME = 1.0f;

 

It’s going to be OK, because we add 0..2 seconds between attacks in resetAttackTimer function. This should make the game much more dynamic.

Adjusting the attack patterns

If you check our Enemy class, update function, you’ll see where we determine the attack coordinates. You can imagine, if we add 4 different attack types, the function will get quite bloated. Let’s delegate it to a separate functions.

Move the code inside the

if (timeAlive > WARM_UP_TIME && timeSinceAttack > nextAttackTime)
{
    // FROM HERE
    int col1 = MathUtils.random(GameLogic.MAX_BASE_X);
    int col2 = 0;
    do {
        col2 = MathUtils.random(GameLogic.MAX_BASE_X);
    } while (col2 == col1);
    // not very effective, but guaranteed to get different results

    for (int x = 0; x <= GameLogic.MAX_BASE_X; x++)
    {
        for (int y = 0; y <= GameLogic.MAX_BASE_Y; y++)
        {
            targetTiles[x][y] = (col1 == x || col2 == x);
        }
    }
    // UP UNTIL HERE

    attackListener.OnAttack(targetTiles);
    resetAttackTimer();
}

Except for the two last lines! Into separate function, let’s name it performVerticalLineAttack();

Now, let’s make a similar function, which we’ll call performHorizontalLineAttack (it’s going to be pretty similar, so let’s copy performVerticalLineAttack and adjust it accordingly). In similar way, horizontal attack will choose 2 horizontal lines and mark them. Here’s how it looks:

private void performHorizontalLineAttack()
{
    int row1 = MathUtils.random(GameLogic.MAX_BASE_Y);
    int row2 = 0;
    do {
        row1 = MathUtils.random(GameLogic.MAX_BASE_Y);
    } while (row2 == row1);

    for (int x = 0; x <= GameLogic.MAX_BASE_X; x++)
    {
        for (int y = 0; y <= GameLogic.MAX_BASE_Y; y++)
        {
            targetTiles[x][y] = (row1 == y || row2 == y);
        }
    }
}

Now, let’s get to diagonal function. Let’s make a separate function which would fill a row (based on selected direction).

private void fillDiagonal(int xstart, int dx)
{
    for (int i = 0; i <= GameLogic.MAX_BASE_Y; i++) { int nx = xstart + dx * i; if (nx > GameLogic.MAX_BASE_X)
        {
            nx = nx - GameLogic.MAX_BASE_X - 1;
        }

        if (nx < 0)
        {
            nx = nx + GameLogic.MAX_BASE_X + 1;
        }

        targetTiles[nx][i] = true;
    }
}

We pass the initial x and the direction (dx). Then we go through full height of the field and pick one tile that is positioned diagonally to the previous one. All that is left is to make the function that actually picks two x coordinates and directions.

private void performDiagonalAttack()
{
    int dx1 = -1 + MathUtils.random(1) * 2; // either -1 or 1
    int dx2 = -1 + MathUtils.random(1) * 2; // either -1 or 1

    int col1 = 0;
    int col2 = 0;
    do {
        col1 = MathUtils.random(GameLogic.MAX_BASE_Y);
    } while (col2 == col1);

    // reset all the tiles to false
    for (int x = 0; x <= GameLogic.MAX_BASE_X; x++)
    {
        for (int y = 0; y <= GameLogic.MAX_BASE_Y; y++)
        {
            targetTiles[x][y] = false;
        }
    }

    // mark the necessary ones
    fillDiagonal(col1, dx1);
    fillDiagonal(col2, dx2);
}

3 done, 2 more to go! The random one is quite simple: let’s not care about filling the repeated tiles. It’s part of life. Instead, just pick 10 random tiles on the field and mark them as used for attack. Here’s the final function:

private void performRandomAttack()
{
    for (int x = 0; x <= GameLogic.MAX_BASE_X; x++)
    {
        for (int y = 0; y <= GameLogic.MAX_BASE_Y; y++)
        {
            targetTiles[x][y] = false;
        }
    }

    for (int i = 0; i < 10; i++)
    {
        int nx = MathUtils.random(GameLogic.MAX_BASE_X);
        int ny = MathUtils.random(GameLogic.MAX_BASE_Y);
        targetTiles[nx][ny] = true;
    }
}

The easiest one so far: reset the tiles, then generate random coordinates for 10 times and mark the tiles as “under attack” accordingly.

The final one will be a mix of all 4:

private void performUltimateAttack()
{
    int rnd = MathUtils.random(4);
    switch (rnd)
    {
        case 0:
            performVerticalLineAttack();
            break;
        case 1:
            performHorizontalLineAttack();
            break;
        case 2:
            performDiagonalAttack();
            break;
        default:
            performRandomAttack();
    };
}

The only thing left is to add a check on enemy type (and performing an attack based on that type). Do it in Enemy update function, after our attack timing check:

if (timeAlive > WARM_UP_TIME && timeSinceAttack > nextAttackTime)
{
    switch (type)
    {
        case Resources.ENEMY_VERTICAL:
            performVerticalLineAttack();
            break;
        case Resources.ENEMY_HORIZONTAL:
            performHorizontalLineAttack();
            break;
        case Resources.ENEMY_DIAGONAL:
            performDiagonalAttack();
            break;
        case Resources.ENEMY_RANDOM:
            performRandomAttack();
            break;
        default:
            performUltimateAttack();
            break;
    }

We’re done! Now, I’ve noticed that we’re drawing effects below the player. In this case, it won’t be a good idea because we need to explicitly show the red warning signs (and they are poorly visible otherwise). Move the

gameStage.getCamera().position.set(gameStage.getWidth() / 2, gameStage.getHeight() / 2, 0);

Line below

player.draw(batch, sizeEvaluator);
enemy.draw(batch, sizeEvaluator);
batch.end();
// place it here!

Great. Now the warning signs are going to be shown above player (timely telling him to get out of the blast zone!). The other thing: the delay of 0.5 seconds is not enough to react appropriately. Go to WarningEffect.java and change WARNING_TIME constant to be equal to 0.75f (up from 0.5f).

Relevant github commit: https://github.com/vladimirslav/dodginghero/commit/012b57d39ed7c12e902acc83a5e7f351069753db

Lesson 16: screen transition

Now that we have transactions, let’s switch to gameplay enhancements: first thing – move to next screens on victory.

In GameLogic class, create a new interface.

public interface GameEventListener
{
    void OnGameEnd(boolean playerWon);
}

Modify GameLogic to take the listener as one of the constructor’s parameters:

GameEventListener eventListener;

public GameLogic(DodgingHero _game, GameEventListener _listener)
{
    eventListener = _listener;

We should notify our victory listener at the same time when we mark our player as victorious.

In our AssignPlayerPosition, where we check bonus pickups and mark player victorious on killing enemy, add a new line:

if (enemy.getLives() <= 0)
{
    player.markVictorious();
    eventListener.OnGameEnd(true); // added this line!
}

It will notify the player about the end of the game. Now, make GameScreen implement the said listener.

public class GameScreen extends DefaultScreen implements InputProcessor, GameLogic.GameEventListener {

As usual, press Alt+Enter to implement the missing method.

Now, what do we want to do on GameEnd? We need a smooth fadeout, and then a progression to next level. Well, a restart for now. It is going to be a progression in the next lesson though. Since we are using sprites (and not gamestag eactors), we won’t be able to use libgdx in-built fadeout action. No worries, it’s not hard to implement ourselves. In advance, make two static constants at the beginning of the GameScreen class:

public static final float GAME_END_FADEOUT = 0.5f;
public static final float GAME_START_FADEIN = 0.25f;

Then, get to working on GameEnd function call.

@Override
public void OnGameEnd(boolean playerWon) {
    gameStage.addAction(Actions.sequence(
            new Action() {
                float t = 0;
                @Override
                public boolean act(float delta) {
                    t += delta;
                    float tempt = t / GAME_END_FADEOUT;
                    tempt *= tempt;
                    batch.setColor(1, 1, 1, 1 - tempt);
                    return t >= GAME_END_FADEOUT;
                }
            },
            new Action() {
                @Override
                public boolean act(float delta) {
                    dispose();
                    game.setScreen(new GameScreen(game));
                    return true;
                }
            }
    ));
}

We’ll ignore playerWon Boolean for now (we’ll implement another transaction on loss). Now, what do we want to do on GameEnd? We create a sequence of actions. First is essentially a fade-out timer, we fade the screen out for GAME_END_FADEOUT seconds (0.5 in this case), then we return true, which indicates that that time has been spent. And then actually we create a new GameScreen that restarts the game.

Now, to get further with our implementation, in our logic initialization, add the line:

logic = new GameLogic(game, this);

Now, that we’ve added a smooth fadeout, we should actually add a smooth fadein. In our GameScreen initialization, add a new action to our freshly initialized stage (at the end of GameScreen constructor).

gameStage.addAction(new Action() {
    float t = 0;
    @Override
    public boolean act(float delta) {
        t += delta;
        float tempT = t / GAME_START_FADEIN;
        tempT *= tempT;
        if (tempT > 1.0f)
        {
            tempT = 1.0f;
        }

        batch.setColor(1, 1, 1, tempT);
        return t >= GAME_START_FADEIN;
    }
});

It’s the same quadratic fadein as you’ve seen before: take the time, add the delta, divide by expected time for fadein (0.25) in our case, thus normalizing the value to 0..1. After that, square it. Great! We got a new transparency.

Finally, if the time has passed the necessary fadein time, return true (thus ending the action). Run the game. As you see when screens actually fadeIn, you have a quick flicker (if you look closer: it’s a scaled-down version of your screen). To prevent this, we need to update a gameStage camera before drawing frame one. At the end of GameStage constructor, add:

gameStage.getCamera().update();
batch.setProjectionMatrix(gameStage.getCamera().combined);

Final thing. By now you’ve probably noticed that enemy attacks are very easy to evade. Decrease WARNING_TIME from 0.75 to 0.5f. Try the game out. FadeIns/Fadeouts should be smooth now.

Relevant git commit:

https://github.com/vladimirslav/dodginghero/commit/1a2fb0896293a80e1b12ae4fc60ee73167cdcabf

Player Leaving On Victory

Now that we’ve implemented a smooth approach- let’s work on smooth leave. Whenever player wins a battle – let’s make him move to the right side of the screen (to make an illussion of leaving and progressing further).

In our Player.java, add two variables:

private boolean winning = false;
private float winTime = 0;

Now, we need to add an extra condition to our draw:

if (timeAlive < APPROACH_TIME)
{
    float t = timeAlive / APPROACH_TIME; // 0..1
    t = t * t;
    setPosition(
            t * sizeEvaluator.getBaseScreenX(fieldX),
            sizeEvaluator.getBaseScreenY(fieldY));
}
else if (winning)
{
    float t = 1;
    if (timeAlive - winTime < APPROACH_TIME)
    {
        t = (timeAlive - winTime) / APPROACH_TIME; // 0..1
        t = t * t;
    }
    float fx = sizeEvaluator.getBaseScreenX(fieldX);
    setPosition(
            fx + t * (sizeEvaluator.getRightSideX() - fx),
            sizeEvaluator.getBaseScreenY(fieldY));
}
else
{
    setPosition(sizeEvaluator.getBaseScreenX(fieldX),
            sizeEvaluator.getBaseScreenY(fieldY));
}

As you see, we need to know the right side of the screen. In our SizeEvaluator, let’s add methods setRightSideX and getRightSideX. Since the width of our window (and therefore screen) can change, we need to keep it updated. SizeEvaluator constructor should also accept right side x.

private float rightSideX;

public SizeEvaluator(Stage _stage, Resources _res, int maxBaseX, int maxBaseY, float _rightSideX)
{
    measuredStage = _stage;
    resources = _res;
    maxTileBaseX = maxBaseX;
    maxTileBaseY = maxBaseY;
    rightSideX = _rightSideX;
}

public void setRightSideX(float value)
{
    rightSideX = value;
}

public float getRightSideX() {
    return rightSideX;
}

Now adjust GameScreen constructor to pass gameStage.getWidth() as the last parameter into SizeEvaluator constructor.

sizeEvaluator = new SizeEvaluator(gameStage,
        game.res,
        GameLogic.MAX_BASE_X,
        GameLogic.MAX_BASE_Y,
        gameStage.getWidth());

Then, we have to take care that sizeEvaluator adjusts properly on screen resize. In our GameScreen’s resize method, add the call to sizeEvaluator’s setRightSideX function.

@Override
public void resize(int width, int height)
{
    super.resize(width, height);
    gameStage.getViewport().update(width, height, true);
    sizeEvaluator.setRightSideX(gameStage.getWidth());
}

One more thing: we need to tell our player class that the game is won. There’s also a problem now: the player’s time is updated inside our logic calls. But we’re not updating the logic if the game has ended (enemy or player died). Time for some refactoring! Change GameScreen’s update function from:

public void update(float delta)
{
    gameStage.act(delta);
    if (player.getLives() > 0 && logic.getEnemy().getLives() > 0)
    {
        logic.update(delta);
    }
}

To:

public void update(float delta)
{
    gameStage.act(delta);
    logic.update(delta);
}

And adjust GameLogic accordingly:

public void update(float delta)
{
    gameTime += delta;
    player.update(delta);

    if (player.getLives() > 0 && enemy.getLives() > 0) {
        effectEngine.update(delta);
        enemy.update(delta);

        if (lastBonusSpawn + BONUS_SPAWN_INTERVAL < gameTime &&
                bonuses.size() < MAX_BONUSES_ON_FIELD) {
            SpawnRandomBonus();
        }
    }
}

Player is always updated, but all the other stuff gets updated only if both player and enemy are alive. Now the only thing is left is to tell our player object that we won! In our Player class, add new function:

public void markVictorious()
{
    winTime = timeAlive;
    winning = true;
}

Then, in our gamelogic, when we damage the enemy, we have to check enemy health. If it equals zero – tell the player that we won! Adjust the part of code with attack bonus pickup:

else if (currentBonus.getBonusType() == Bonus.BONUS_TYPE_ATTACK)
{
    enemy.takeDamage(1);
    if (enemy.getLives() <= 0)
    {
        player.markVictorious();
    }
}

Great! Now our player leaves after the game ends, marking the continuation of the journey. Looks much better!

Screenshake

In our previous lesson, we made our character blink on hit. That feels better, but it’s not enough. Let’s make our screen shake to indicate how hurt the player is!

In our Character class, let’s make a public function that returns last time our character has been hurt:

public float getTimeOfDmgTaken()
{
    return timeOfDmgTaken;
}

We also need one getter to see time alive:

public float getTimeAlive()
{
    return timeAlive;
}

In our GameScreen.java, define two new constants:

private static final float SHAKE_TIME_ON_DMG = 0.3f;
private static final float SHAKE_DIST = 4.0f;

One is responsibe on how long the shake is going to happen, the other one for the intensity of shake (Shake Distance, amplitude). After we do that – we’re ready to start screenshake process! In our GameScreen render function, before DrawUi() call, we have to add the following lines:

gameStage.getCamera().position.set(gameStage.getWidth() / 2, gameStage.getHeight() / 2, 0);
if (player.getLives() > 0 &&
    player.getTimeAlive() - player.getTimeOfDmgTaken() < SHAKE_TIME_ON_DMG)

    gameStage.getCamera().translate(-(SHAKE_DIST/2) + MathUtils.random(SHAKE_DIST),
            -(SHAKE_DIST / 2) + MathUtils.random(SHAKE_DIST), 0);
}
gameStage.getCamera().update();

The sequence:

1. Reset camera position
2. If player has recently taken damage, move the camera. Note that player must be alive (otherwise we’ll get an infinite shake)
3. Apply our camera movement

Run the game and take damage! The screen should be shaking after receiving damage now 🙂

Appearance at the start of the game

Right now our player and enemy both appear at the fixed position at the start of the game. Let’s make them appear from the side of the screen and then take the initial positions.

In our Player class, make a separate constant,

private static final float APPROACH_TIME = 0.5f;

Then, modify our draw method call.

public void draw(SpriteBatch batch, SizeEvaluator sizeEval)
{
    preDraw();

    if (timeAlive < APPROACH_TIME)
    {
        float t = timeAlive / APPROACH_TIME;
        setPosition((t * t) * sizeEval.getBaseScreenX(fieldX), sizeEval.getBaseScreenY(fieldY));
    }
    else
    {
        setPosition(sizeEval.getBaseScreenX(fieldX), sizeEval.getBaseScreenY(fieldY));
    }
    super.draw(batch);

    postDraw();
}

To explain: in the first 0.5 seconds, the player is going to seemingly move from left to right side.

Let’s do something different for our enemy. Why not make him increase in size (starting from very small)?

Modify our Enemy class, declare a constant:

private static float SCALE_TIME = 0.5f;

And modify our Enemy.draw method:

public void draw(SpriteBatch batch, SizeEvaluator sizeEval)
{
    preDraw();
    setPosition(sizeEval.getEnemyX(this), sizeEval.getEnemyY(this));
    if (timeAlive < SCALE_TIME)
    {
        float t = timeAlive / SCALE_TIME;
        t = t * t;
        setScale(t);
    }
    else
    {
        setScale(1);
    }
    super.draw(batch);
    postDraw();
}

Finally, make a small bugfix to prevent spawning on already existing places: in our gamelogic.java, in SpawnRandomBonus function, change for cycle from

for (int i = 0; i < bonuses.size() && targetNonEmpty; i++)

to

for (int i = 0; i < bonuses.size() && (targetNonEmpty == false); i++)

Run the game. You can see that both player and spider smoothly appear on the screen now.

Relevant Github commit: https://github.com/vladimirslav/dodginghero/commit/ab9d4e938bf8dde615bacbccdc87005672770ebc