Last weekend I participated in Ludum Dare 36. It was the fourth time I took part in Ludum Dare and the first time I failed to finish and submit my game. Despite this, it was my most enjoyable game jam experience so far.
Whilst in the past I have developed silly games for Ludum Dare, on this occasion I decided on a more conventional project. The theme was ancient technology and I decided to make a 2D top-down game. The player would take on the role of a woman from a more primitive time who navigates through an ancient cave looking for a powerful item. In the cave she would encounter robotic stone golems and strange creatures. To fight these enemies and help navigate the cave, she would use a torch and a bow that fired arrows. I envisioned the player sneaking past the powerful golems, fighting other creatures with the bow and lighting torches to distract/warn off enemies.
The main reason I had so much fun working on this was that it involved implementing many different features. This included firing arrows, lighting torches, enemy navigation, fields of view for the torches and golems, changing items etc. It was very satisfying to gradually add these features to the game and see how they interacted with each other.
There were a few reasons why I didn't finish within the 48 hours. As you might have noticed, this was quite an ambitious project for one person to do over only two days. Even if all the gameplay features were implemented, the project would still need a fair amount of level design work before it could be considered a playable game. I made the mistake of deciding to do some character artwork myself. Since I am not an artist, this meant I lost quite a few hours for two poorly made characters that didn't even have animations. I faced a major problem when, halfway through the second day, I discovered that Unity’s navigation features don’t work for 2D applications. This led to me wasting many hours trying to implement my own pathfinding solution but I was unable to develop something that met my needs in a suitable time frame. I also had a couple of other personal commitments on the same weekend that took away hours of valuable time.
I found myself nearing the end of the second day with only a few features finished and only some poor enemy navigation in place. I hadn't done any level design work yet and was uncertain of how all my various gameplay elements we’re going to interact with each other in a level. Even though there were still a few hours left before the deadline I decided to stop there. Any work I could've done in those last few hours, would have been very sloppy and rushed. I already knew I wanted to work on the project beyond the game jam. I realised I would rather step away from the project for a few days and then come back to it with a fresh mind. This way I wouldn't need to clean up hours of rushed work and I might be able to complete a game that more closely resembled my vision.
Having talked a lot about what I failed to do in two days, I would now like to talk about what I actually did succeed at. Despite them being of an unprofessional quality and having no animations, I did make functional character sprites.
First up is my player character:
Since neither the gender nor the race of the character affected the game and its simple narrative, I opted to have them be a woman of colour. It bothers me a lot that in video games, the go to character is usually a straight, white male. There’s already more than enough protagonists in games that meet this description and it doesn’t reflect the diversity of the world we live in. Unless there’s a genuine reason for using such a character (e.g. the story is about something like white privilege or insecure, male masculinity) I would prefer to use someone different.
Next up is my golem:
Next up is my golem:
I love golems. As soon as I read the jam’s theme I got really excited to see all the artwork that gets posted on Ludum Dare’s website. I’m a big fan of the sort of imagery associated with the fictional technology of ancient civilisations. Disney’s Atlantis and Studio Ghibli’s Laputa: Castle in the Sky are two of my favourite animated movies for this very reason. I’m particularly fond of golems though. There’s something about these stone, robot-like creatures with glowing eyes that is very endearing to me. I’m really proud of this and love seeing it wander around in the game.
Both characters have four sprites facing in different directions. I needed to devise a way to change between these sprites based on which direction the character is facing. For the golem, I stored all four sprites in a public array and created an enumerator for each direction. When the golem moves, I calculate which of the four directions it’s moving in and store it. I can then use the stored direction as an index to get the appropriate sprite from the array. Since the golem can move in 8 directions, it would switch between two sprites rapidly when moving diagonally. To fix this, I determine whether it’s moving faster horizontally or vertically. This helps to decide on the direction of the character and prevents the rapid sprite switching.
Since the player can hold different items, I needed different versions of the player. Each version has four sprites for the four directions. I created a struct that could store a group of sprites. The struct has a string for the name of the item and an array for the sprites. I used a public array of the sprite group struct so that the sprites for each item could be grouped and named in Unity’s editor. I then used an enumerator to keep track of the currently equipped item and a dictionary to switch between the sprite groups whenever the player changed items. So when the player presses the spacebar to switch from the torch to the bow, the enumerator will change to reflect this. A switch statement is used with the enumerator to get the name of the currently equipped item as a string and then the dictionary uses that string to look up the correct array of sprites. This array is then used in the same way as the golem’s array of sprites to change the direction the character faces.
The results can be seen in the gif below:
Both characters have four sprites facing in different directions. I needed to devise a way to change between these sprites based on which direction the character is facing. For the golem, I stored all four sprites in a public array and created an enumerator for each direction. When the golem moves, I calculate which of the four directions it’s moving in and store it. I can then use the stored direction as an index to get the appropriate sprite from the array. Since the golem can move in 8 directions, it would switch between two sprites rapidly when moving diagonally. To fix this, I determine whether it’s moving faster horizontally or vertically. This helps to decide on the direction of the character and prevents the rapid sprite switching.
Since the player can hold different items, I needed different versions of the player. Each version has four sprites for the four directions. I created a struct that could store a group of sprites. The struct has a string for the name of the item and an array for the sprites. I used a public array of the sprite group struct so that the sprites for each item could be grouped and named in Unity’s editor. I then used an enumerator to keep track of the currently equipped item and a dictionary to switch between the sprite groups whenever the player changed items. So when the player presses the spacebar to switch from the torch to the bow, the enumerator will change to reflect this. A switch statement is used with the enumerator to get the name of the currently equipped item as a string and then the dictionary uses that string to look up the correct array of sprites. This array is then used in the same way as the golem’s array of sprites to change the direction the character faces.
The results can be seen in the gif below:
When the player has the bow equipped they can fire arrows in the direction they’re facing. When they press the right mouse button down an arrow is nocked. In other words, an arrow object is created and placed in front of the player character. When they release the mouse button, a relative force is applied to the arrow. This fires it forward. The force used, depends on how long they held the mouse button down for. A variable stores the force and increments it every frame the arrow is nocked for. The force is initialised at a specified, minimum value and when it reaches a specified, maximum value, it stops incrementing. A bar on the UI shows the force of the nocked arrow. This bar works the same way as the wings melting bar in my Icarus game. When the nocked arrow is fully charged, a particle system activates to show how much energy the player character is exerting. After being released, an arrow stores the force it was fired with so that the force can affect how much damage the arrow inflicts on an enemy.
This gif shows the character firing arrows:
This gif shows the character firing arrows:
Torches are items that can be placed in the game and are either lit or unlit. The player’s own torch can also be either lit or unlit. If the player walks up to a lit torch with their unlit torch equipped, their torch will be lit. The opposite also works, i.e. their lit torch can light unlit torches in the level. Switching items from the player’s lit torch to the bow causes the torch to go out. Whether a torch is lit or unlit, effects two things about it. Firstly, it changes the sprite between one with a flame and one without. Secondly, it turns on and off a ‘field of view object’ that is attached to the torch. This field of view object is based off of a video tutorial series by Sebastian Lague that can be found here:
https://www.youtube.com/watch?v=rQG9aUWarwE&index=1&list=PLFt_AvWsXl0dohbtVgHDNmgZV_UY7xZv7
The field of view object can be used to display a character’s field of view and allow them to detect targets. It can also simulate a light since it creates a transparent, circular shape which doesn’t go over obstacles. This creates the effect of shadows. It works by casting out rays in a defined radius, that stop when they hit an object designated as an obstacle. When the rays hit objects, that are designated as targets, the targets are stored. This sort of technique is used in stealth games such as Volume and Mark of the Ninja. I use the field of view like this with my Golem characters to introduce stealth elements.
For the torches though, the field of view just acts like a circular light as shown below.
https://www.youtube.com/watch?v=rQG9aUWarwE&index=1&list=PLFt_AvWsXl0dohbtVgHDNmgZV_UY7xZv7
The field of view object can be used to display a character’s field of view and allow them to detect targets. It can also simulate a light since it creates a transparent, circular shape which doesn’t go over obstacles. This creates the effect of shadows. It works by casting out rays in a defined radius, that stop when they hit an object designated as an obstacle. When the rays hit objects, that are designated as targets, the targets are stored. This sort of technique is used in stealth games such as Volume and Mark of the Ninja. I use the field of view like this with my Golem characters to introduce stealth elements.
For the torches though, the field of view just acts like a circular light as shown below.
That sums up all the features I managed to finish during the game jam. There are quite few things I want to do with the project before I release it online. These are as follows:
Pathfinding/Navigation – I need a better way for the enemies to follow the player. I’m hoping that I might be able to get Unity’s navigation features to work by altering the dimensions of the game whilst keeping the 2D assets. This may prove awkward though as all the physics would need to be altered for 3D. I may resort to some simple following and obstacle avoidance behaviour instead.
Finish golem behaviour – My golems can already move around and their field of view can detect the player. Once I have a way to get them to follow the player, I want them to attack the player on contact. I also want them to patrol between defined waypoints when they don’t have visual contact on the player.
Other enemy type – I envision a small, fast creature that runs at the player when they’re on screen but fear fire. The player can’t hide from them like the golems but they can fight them with arrows and keep them at bay with torches.
Level designs – Once I have all the gameplay elements implemented I can design the levels of the cave. I also need to decide exactly how every element interacts with one another. The small enemies are scared of torches but how do the torches affect the golems? Will the torches factor into the stealth aspects, e.g. can golems detect when a player is in a light? Can arrows do anything to golems? How much damage do the small enemies inflict and how much does it take to kill them? These are only a few of the questions I still need to find an answer to.
Game ending – I have a pretty good idea in mind for what the player finds at the end of the cave but I don’t want to spoil that yet.
Narrative? – I keep changing my mind about how much story I want to put in the game. For now I’m content to focus on the gameplay and level design. Later I may decide to give more background to the character and possibly even a simple character arc.
As you may have noticed, my design for the game is still poorly defined and very messy. Is it a stealth game, an action game or an exploration game? I’m not sure. I think this is why I had so much fun during the game jam last week and why I’m excited to keep working on this project. By slowly discovering what I’m making rather than knowing from the start, I find the game remains fresh and interesting to me. It’s quite possible that the finished product won’t be very coherent as a result. Even if that’s the case though, each aspect of this game is improving my coding abilities and giving me interesting design challenges.
Hopefully in future posts, I’ll be able to show the game coming together.
Pathfinding/Navigation – I need a better way for the enemies to follow the player. I’m hoping that I might be able to get Unity’s navigation features to work by altering the dimensions of the game whilst keeping the 2D assets. This may prove awkward though as all the physics would need to be altered for 3D. I may resort to some simple following and obstacle avoidance behaviour instead.
Finish golem behaviour – My golems can already move around and their field of view can detect the player. Once I have a way to get them to follow the player, I want them to attack the player on contact. I also want them to patrol between defined waypoints when they don’t have visual contact on the player.
Other enemy type – I envision a small, fast creature that runs at the player when they’re on screen but fear fire. The player can’t hide from them like the golems but they can fight them with arrows and keep them at bay with torches.
Level designs – Once I have all the gameplay elements implemented I can design the levels of the cave. I also need to decide exactly how every element interacts with one another. The small enemies are scared of torches but how do the torches affect the golems? Will the torches factor into the stealth aspects, e.g. can golems detect when a player is in a light? Can arrows do anything to golems? How much damage do the small enemies inflict and how much does it take to kill them? These are only a few of the questions I still need to find an answer to.
Game ending – I have a pretty good idea in mind for what the player finds at the end of the cave but I don’t want to spoil that yet.
Narrative? – I keep changing my mind about how much story I want to put in the game. For now I’m content to focus on the gameplay and level design. Later I may decide to give more background to the character and possibly even a simple character arc.
As you may have noticed, my design for the game is still poorly defined and very messy. Is it a stealth game, an action game or an exploration game? I’m not sure. I think this is why I had so much fun during the game jam last week and why I’m excited to keep working on this project. By slowly discovering what I’m making rather than knowing from the start, I find the game remains fresh and interesting to me. It’s quite possible that the finished product won’t be very coherent as a result. Even if that’s the case though, each aspect of this game is improving my coding abilities and giving me interesting design challenges.
Hopefully in future posts, I’ll be able to show the game coming together.