For week 10, I asked 4 peers who are interested in game development the following couple of questions, as well as suggesting they could give any other feedback:

Q1. What should I prioritise developing next (can rank)? 

Option A) Player Health / Points Overlay 

Option B) Sound Effects 

Option C) More Level (introduction to other enemy colours and scenarios) 

Option D) Anything else, such as laying mines 

Q2. Is there any small tweaks like speed or colouring you think could be changed?

Figure 1: My short questionnaire.

From the feedback I got, the two winning suggestions were: to focus on making more of the level; and making the player and health points overlay. There was little support for adding sound effects; but some support for powerups, such as laying mines.

Aside from providing a good means of prioritising my features to implement via a consensus, the participants also brought up some of the harder to solve issues:

● What to do when both enemy and player are trying to go through the wall. It’ll block one of them, but allow one of them to go through. When it allows one to go through, the sprite renderer is turned off though, so it’s invisible. So essentially one will be colliding with an invisible wall.

● What to do about the bullets going through walls.

Ideally I’d want part of the wall to go invisible for the first issue; but without me exploring solutions for the issue, it sounds complex to me. For the second issue, I’ve found it hard to block bullets, perhaps because of their speed.

One participant actually found a bug that I’d never encountered before, which I was very pleased about. It had to do with a blue enemy leaking through the wall when the game was switched between any of focused, unfocused and maximized modes.

I went onto fix this bug fairly quickly by making the walls quicker, and it is on my radar to try to fix similar bugs to these from now on.

One of the other issues people had was with the lack of health also. There was a minor bug due to some boolean arithmetic going wrong, which meant that there was a pause in damage that was missing when colliding with bullets. The first enemies were also lacking any health consumables spawning from them, so I changed the code so that all enemies spawn the health, and any collectible abilities also restore health. I tried upping the health a bit also, but it changed my vision for the opening part of the level, so I went against the idea in the end. Hopefully the other changes I’ve made have helped, but I am aware of the issue and am thinking about it a lot as I design more of the level.

Given the support for wanting to see more of the level, I started on making the second layer of the level, where combat with the 2nd ranked enemy, the red enemy, is introduced.

I also went through the checklist of features my lecturer wanted to see, and one of the remaining features from there was an attack-blocking mechanic. That missing mechanic was planned to be introduced by the red enemies, so it was a convenient target for this week’s development.

Figure 2: Left-side of second layer of the level in my Unity project.

To begin with my level expansion, I just built a horizontal rectangle on top of the tunnel going upwards from where the set of teleporters where. As I was putting the walls down, I was thinking about how to design this part of the level.

My initial idea was to have a red wall to the right, which you’d gain access by defeating the red enemies to the left and perhaps a teleporter to the top which you’d gain access to after defeating the enemies to the right. I wanted something to happen near the teleporter though, which didn’t really give me enough to space to work based on what you can see above. I didn’t really have many ideas for the right space, so it made sense to have that teleporter interaction there.

As for my enemies, I went with a similar structure to the first part of my level: three smaller enemies and one bigger enemy. At first, I wanted the big enemy to spawn the move-though-wall collectible; but one problem was that I initially placed the red wall to the right (would later put a green wall before it) and so it could have escaped to the right; the other problem is that it’d make the fight very difficult. Red enemies are stronger in both health and attack power, and lacking the red ability to match the damage would draw out the fight too long. Not only that, I planned to implement blocking also, which would make it even harder.

In the end, I went with placing the collectible behind the enemies, so the idea was the player would could move in and collect the ability, and then faced the enemies behind. Upon defeating them, the big red enemy would spawn the teleport ability.

Figure 3: Left-side of second layer of the level in my Unity project.

To round up the focus on the level design, I placed a green wall before the red wall on the right so that the red enemies couldn’t use the red wall to slide down and outside of where they are supposed to be. I tried thicker walls, but I couldn’t get it to work without disrupting the rest of the level.

Finally, the right section consisted of three big green enemies, which would act as a showcase of the new-found power of the red bullets. They now die in half the time. When you become red, your speed also gets increased relative to green.

For coding this week, the biggest challenge was adapting all the code to work with green and blue enemies. For instance you can see here that I generalized the spawning of the Teleport ability collectible:

                    Dictionary<float, string> colorID = new Dictionary<float, string>
                    {
                        { 3, "Red" },
                        { 2, "Green" },
                        { 1, "Blue" },
                    };
                    colorID.TryGetValue(calcColor, out string colorName);
                    GameObject abilityClone = Instantiate(teleportAbility, spawnPosition, Quaternion.identity);
                    abilityClone.GetComponent<SpriteRenderer>().color = enemyColor;
                    abilityClone.name = colorName + " Teleport Ability(Clone)";
                    return;

Figure 4: Teleport Ability Clone Spawning code for all 3 colours.

I also had to adapt the speed and attack power depending on the colours, and also for the player’s changing of colours. On top of that, the additional red and blue objects interactions with the coloured walls had to be accounted for, as well as the enemy’s bullets also having to change colours from the default green. It was a lot of minor changes to test.

One interesting bug I fixed was where: the bullets would get destroyed, but still leave the coloured wall they were going through invisible. I fixed it with this code: gameObject being the bullet and render being the sprite renderer of the wall:

    if (gameObject.activeSelf)
    {
        StartCoroutine(ReturnVisibility(obj));
    }
}

IEnumerator ReturnVisibility(GameObject obj)
{
    yield return new WaitForSeconds(0.6f);
    if (obj == null)
    {
        render.enabled = true;
    }
}

Figure 5: ReturnVisibility Co-routine.

Next week, I’ll explore the attack-blocking mechanic, checkpoints, the red teleport area and a Health / Points overlay.