In our first technical workshop for this year, we started learning about Unity and coding with C#. Over the Christmas break I started learning C#, so most of the basic concepts we went over are things that I am familiar with, however this is the first time I have used Unity or coded anything in a game design context. Unity seems to be a lot easier to use than I first expected, but I do think that without that prior experience, limited though it may be, I would be completely overwhelmed by this.
This week we made something that could be called the beginning of a game. We created a landscape with platforms and pits, a character that can be moved around using the arrow keys, and is animated. All of the sprites used were downloaded from a free sprite website.
This week we built on what we learned last week, and made a simple game, where the player controls a character that can jump to other platforms and destroy ‘jellies’. Things learned:
- Spawn objects
- Destroy objects
- Simple mouse/touch tracking
- Public variables
For these weeks, we worked on a collaborative game project, to introduce us to working with Unity’s Collab feature. We were sorted into groups and given different tasks. My group focused on enemy sprites and programming. I was tasked with finding suitable sprites for ghost, bandit and slime enemies.
This is the first week that I began working on the practical side of my project. The game requires players to guess the order of materials needed to make a water filter. The player can click and drag materials from their bags to the funnel and then check to see if they got it right.
So far, I have been able to code the charcoal bag to be clickable, and once clicked, spawn charcoal to be dragged to the funnel. Unfortunately, there seems to be a bug where the camera view goes blank when the bag is clicked. I am working to try and fix this glitch.
We had a tutorial on mouse and touch controls, creating a simple game where the player moves a jelly onto a fire and kills it. So far, all I have working is the click-and-drag movement – the fire does nothing, despite my best efforts.
After much consideration about the appeal of my game, I have decided to switch to one of the other ideas I have had.
This game is a lot simpler and probably more fun than my original game. Players move their mouse around and a water drop chases it. When the water drop collides with germs, they are destroyed. The goal is to destroy all the germs before they overrun the screen (when they reach 100 germs, the player loses). I think this will be much easier to make in the time I have, and also easier to make visually appealing, which I have done by creating cute cartoon water drops and germs, and a bubbly water background.
The germs are coded to spawn another germ once every few seconds. Due to this the number of germs when left unattended increases exponentially, as one germ spawns a second, the both spawn to make four, and those four make eight, and so on. I decided to code my game like this so it would mimic the way cells multiply in real life.
This week we did a play test at MOTAT. My first build of my game was functional, and included win and lose screens, but it is too easy to win in the first few seconds of the game, as there isn’t enough time for the germ to spawn at the start of the game before the player kills it and wins. I also found that the lack of start and reset buttons meant that I had to keep opening the game executable file manually when someone wanted to play, since I couldn’t leave it open without it running to the lose screen.
WEEK 10, 11, 12:
After getting feedback on my game, I worked on some of the main problems, such as the easiness and the UI. Some problems were fixed – it is now much harder to win instantly – and some new problems came up – the germ counter is not accurate, and allows the player to win with germs left on screen. I added a start screen and reset buttons on the win and lose screens (although the reset buttons are not functional).
To increase the difficulty of the gameplay, I have slowed the speed of the water drop, and increased the number of germs at the start to four. They are placed in the corners, which means that even if the player can hit one or two before they spawn, the third and fourth will have time to multiply. I have also increased the spawn range to cover the entire screen (any germs that try to spawn outside the screen automatically spawn inside). This means that even as the player is closing in on the last few germs, they can spawn another on the other side of the screen, prolonging the play time.
While I haven’t been able to implement all of the changes I wanted to add – such as levels, multiple germ types and behaviours, animations, and post-game scores or leaderboards – I am quite happy with what I have so far.
My current build of the game can be played here.