This weekend, I participated in the Global Game Jam with 29 other students and two of our lecturers. It was an extremely good experience and I’m glad I was there. Despite the exhausting amount of time spent at the school working hard with my team of four (Marc, Daniel, and Adam), we managed to pull through and created something I think we all should be extremely proud of.
We gathered in the main theatre of the building at 5:30pm to watch a quick introductory video and keynotes for the Game Jam – we got to hear from Extra Credits about the things we should consider during the 48-hour jam. A lot of them were good to keep in mind, but the one I knew was the most important was: start small. There might be huge, grandiose ideas during the jam, but take the distilled version of those big dreams so that it’s a feasible endeavour. Our motto this weekend? Minimum viable product. As long as the core mechanics and graphics are there, the potential of the game can shine through.
The theme this year was:
At first I was a bit hesitant about the theme, thinking it was actually quite specific. However, thinking about it in a less literal sense, there are plenty of things that have to do with waves. Of course water is one of them, but there are sound waves, Mexican waves, hands waving, waves of enemies, wind causing a wave through the trees, and so on.
Pairing up with Marc, Dan, and Adam, we started our brainstorming by picking from three general ideas: a surfer on a wave, lights moving in wave-like motion that have to be controlled, and sonar/sound waves that help the player see the area. After some further talking, we decided on the last one and then developed it a bit further. Since bats use sonar to determine their surroundings, we could have a bat flying through a cave and avoiding obstacles by sending out sound waves. This would be represented by a light that would grow and shrink to show the obstacles in the way.
Before we finished up for the evening, we each picked up a section that we could think on before reconvening the next day. I was going to be the core programmer for the game, so I decided it was best to start building the bare bones of the game to bring in on Saturday. Marc was going to work on the background and environment, Adam was going to do the character design for the bat, and Daniel was going to look into what sort of pick-ups we could have based on what bat’s might eat.
With those things on the table, the game jam was away!
I didn’t really get to bed until 2am, so I was a bit tired by the time we were back into school at 9am – however, I’d managed to white box a lot of the basic ideas and learned quite a bit along the way. I won’t go into detail about what the others did, since they’ll likely be blogging about their experiences anyway, so I’ll mainly focus on my programming from this point onward.
We had decided on Friday that the game should have three usable controls: up and down to control where the bat was on the X axis and the space bar to send out the sonar wave. We’d also decided that it was going to be an endless runner, where the goal was to survive as long as possible without hitting any obstacles. While I knew of one way to make a scrolling background (placing a tiled material on a cylinder and then rotating it, like I did for practice in my asteroid game), we needed something different. I research ways to script a tiling material on a quad, using the offset to make it appear like an endless loop. I did have to tell Marc the background he was working on had to seamlessly tile.
On Unity, someone had posted a tutorial on how to make a space shooter and had a video on how to do this kind of scrolling background. It was perfect for what we needed!
If you tile the material by two, the texture looks like it’s constantly moving. I also had to do the same for the ceiling and floor walls, which took a bit more effort if only because of their odd shapes. For the bat’s movements, I just used a transform.position plus transform.up multiplied by moveSpeed (which was a public float while I tried to determine what a god speed was). This was something we learned during our Asteroid game lessons, so it felt like the easiest thing to implement.
While at school on the Saturday, I worked on several things, the most important being the instantiation of the obstacles and the pickups. This wasn’t the first time I’d come across instantiation, since I did some practice spawning the asteroids following a tutorial Ant had done. However, the randomisation of the spawn locations and the way they moved weren’t quite what I wanted. Instead, I surfed the internet to find something that I could combine with this knowledge.
Using a counter to count down the next obstacle generation seemed like a good idea as well, since at a later date we could make the obstacles appear more clustered and faster the longer the player lasted in the game. We did this a lot throughout the game – we kept calling it “stretch goals,” where we had an idea we knew would be good to implement either on Sunday after everything major was done or even after the jam was over, just because the breadth of the idea was too large for the core time of the game jam.
After getting the obstacles to generate (although it was all the same obstacle at that moment), I also got pickups to do the same thing. I was struggling a little to figure out how to make a list to randomise the generation of the obstacles/pickups when one of the second years helped me out. He showed me how to take my code and just implement a list variant by adding square brackets and Random.Range to call on the items in the list. This meant I could put all my prefabs into the list and the items would cycle through.
We finally had something that was working quite well. The last thing I did for the day was get the sonar wave to work with a spotlight. I had a bit of trouble getting a smooth movement on the light angle change, so I did it staggered. We started off with the sonar vision lasting for 3 seconds – I had to use coroutines and IEnumerators to get the timing right.
On the evening, the only thing I decided to do was set up the scenes and menu system with the buttons Marc had given me, and then had some well-earned rest!
We had one more day – we were to have our games ready for the last hurdles of debugging and checking by 2pm and then have them uploaded by 3:30pm, so time was of the essence!
My main goals were simple for the day: polish as much as I could with the time I had. Okay, perhaps it wasn’t as simple as it sounds, but the game jam had been going pretty smoothly without too many stresses, so the team was in good spirits.
I implemented a newer scoring system and timer, where the score went up the longer the player lasted, but also that the pickups would add bonuses to your score for even more points. This felt like it worked better with a bigger end score, rather than just scoring depending on how many pickups were got. I then needed a little help linking them to the final lose scene, because for some reason I wasn’t using the correct code.
I also learned about lerps in Unity, which help pseudo tween between two numbers, such as our cone angle for the sonar light. They linearly interpolate between the numbers to allow for a much smoother transition. Asking the team what they thought, we all agreed that it looked much better than the staggered light growth/shrink we’d had before.
We also all came together to decide on the music and sound effects for the game. It was rather easy to bang together a script for the music to work while transitioning from the main screen to the credits and how to play scenes. It would then play a different song while in the cave.
I think the biggest shame was we didn’t have the capacity to put in the animation Adam worked really hard on, if only because of Unity’s restrictions on needing QuickTime to play movie textures. This frustrated all of us, since the computers at the college don’t have it installed. Instead, we had to temporarily put in a screenshot, which I did by putting it on the canvas and then attaching a quickie script to it that manipulated the alpha.
We managed to upload out game despite the lag on the site and it was done for the day. After that, we were asked to Twitch about our game and what we did to make it. Our team went first, so we didn’t really know what to say, but we did get some good feedback from the guest, Jon, brought in. He suggested we could implement a gradual darkening of the cave, to make sure the player doesn’t just want to rage-quit if the difficulty is too high at the very beginning.
Here’s the link to the Twitch video Ant did with us.
Here’s the link to my Dropbox, where the .exe file and data folder can be downloaded.
Overall, as I said at the beginning, it was a very good experience and I’m looking forward to doing another game jam… although maybe not until I get some much-needed sleep! I’ve already put out a version two of the game, where I fixed some of the colliders on the crystals and changed it so the player starts with a sonar right at the start of the game. There are still a number of ideas I would like to do with the game, which I’m sure the guys would agree on, and I also want to put in the animation that Adam did to complete the core of the work we did on the weekend.
We all worked really hard and the end result was much better than I expected. I learned a lot, both about game jams and code I never knew before. Other than that, I think I’ve written enough!