Gamejam (for IMT2581 Rapid Prototyping course at NTNU Gjøvik) in collaboration with Aksel Hjerpbakk and Halvor Bakken Smedås. The theme of the gamejam was Space and Fear, and we ended up creating a 2D platformer where you have to keep moving upwards to not lose the game.

Repository can be reached at: https://gitlab.com/avokadoen/gamejamspacefear

Some more information from a project report can be seen below:

Prototyping Report

Project date: 14. September 2018 - 16. September 2018

Development Environment:

  • Unity
  • Gitlab w/LFS
  • Gimp
  • GraphicsGale

Description

You play as the boogeyman. The boogeyman is scared of open spaces, and so the main idea is for you to avoid the open spaces. The room you are in is collapsing (in a really weird way) so the walls move outwards, away from the player. Staying in the open spaces causes your fear level to increase, and if it reaches max you will panic and uncontrollably die. The objective of the game is to maintain a manageable fear level while not falling to a certain death. You also have to be aware of the different platforms spawning over you. A lot of the platforms has properties that modify the gameplay. Red platforms are an indication of danger or debuffs. Green will help you and brown will be unpredictable. Fear is a fundamental mechanic of the game. As fear increases, it will also buff the player’s acceleration and jump force, which is part of a balancing act, so as the game goes further and gets more challenging, the player will be able to keep up to the max difficulty scaling.

As of the current state of the game, most of the mechanics are implemented to some degree, although proper balancing is lacking. We would like to have platforms be unlocked as the player get more confident with the gameplay. We would like fear to have more impact. Doing so would require a lot of playtesting. Knowing the max jump and move speed buff for fear is hard without having played the game for some time. We would also like a store where you could buy green platforms and increase the positive effects of fear. Score and highscore was not far away from implementation, but wasn’t the main focus when making a ‘prototype’ of a game in a game jam. But basically it would be about how far you could get without dying, so you would be able to beat your own or other’s scores.

The store would also introduce a new mechanic called mutations where you would be able to get certain trade-offs. Examples of such mutations would be: “2x fear buff effect, but 3x fear attrition”, “3x green platform spawnprobability, 75% jump height debuff”, etc.

My raw personal notes

Contribution

First day I was working on the player script, working on player movement and input. Used a lot of time messing around with how the player physics worked on floors, as either the movement was too “hard” or it ended up being too “smooth”, tried to solve it applying and messing with gravity and velocity of the Rigidbody2D with code, but was messing a lot with this. However we ended up making it pretty good on the 2nd day, when we found a way we could change the gravity on player input, which somehow made it a lot better.

Second day I worked on scripts for the different types of platforms and their buffs and debuffs that were added to the player. Furthermore I worked on the walls in our game, and sorting out how they would be placed and move in the level, also some on how they would apply fear attrition to the player. (Did some pair-programming with Aksel on this part as we were somewhat bottle-necked, and he had some good ideas on how to sort this out)

The last day I worked on UI elements on the game screen. Making buffs/debuffs visible to the player and also showing the fear level of the player. Last part of the jam was spent tweaking and fixing minor issues, and balancing certain parts of the game like the wallManager and playerController. Also added sound effects to play on certain triggers, like when hitting a platform or when the player panics.

Reflection

The good
  1. Good scope for a 48 hour jam - I feel that our initial idea and how we brought it together made for a pretty good scope for us to finish main features within the 48 hours of this jam. Didn’t end up feature-creeping, and we managed to complete a working prototype with all main features.
  2. Good schedule for work and sleep - Even though the jam started late on friday, I feel that I ended up managing when to go to sleep so I got enough sleep and was able to get back to work at a decent time the next day.
  3. Good core gameplay - Happy with how the product ended up being, as when we fit all parts together and was able to see the actual gameplay. I was pretty satisfied with how the end-product ended up being. Even though some time spent on balancing would be good to make it feel better.
  4. Learned a lot - I was introduced to a lot of new concepts and how they work in Unity. So I got a better understanding of how a lot of the tools worked and how to work with them. I am pretty happy with that as we also use Unity for our game project in the GameProgramming course.
  5. Good group - We were able to communicate and share our ideas pretty well, as well with implementation. Making the workflow and work distribution pretty smooth, except for some bottleneck at certain parts of the jam.
The bad
  1. Bottlenecked at certain parts - On the second day we started realizing that we were somewhat bottlenecked, because our scope wasn’t that big and some modules had to be implemented before we could work on others. So this caused a somewhat bottleneck that we realized the second day. Possibly we could’ve had a bit different approach either to how we managed worktimes, or what modules we initially worked on. However what we did do was pair-program some parts that were a bit hard, as we were bottlenecked either way.
  2. UI displaying buffs and debuffs should have been better - As buffs and debuffs apply with some timer, it was kind of hard to indicate or know when a debuff or buff would end. So as the UI at least ended up indicating whether you had a buff/debuff on or not, it should’ve displayed some sort of timer, on when it would expire. So this should have been implemented in another way, also buff’s should’ve been applied to the player with some sort of events instead, this way it would have been a much better solution to how the whole buff/debuff thing was implemented.
  3. Certain parts of the game would have needed more balancing - As all the core features were implemented and working well, we should’ve had some time to balance and tweak certain parts some more. Some mechanics, like the platform that decrease movement-speed are kind of broken. There is some, but not enough balancing done to make the game get harder as you go further. The main mechanic, which is the fear level, almost never ends up reaching max, as players tend to die earlier due to other mechanics that are too hard.

Things that I would do differently are

  1. Separate modules early - Try to separate modules earlier, and maybe write up individual tasks that can be picked up and done as early as possible. As this could mitigate some of the bottleneck that we experienced during this game jam, and could make it so some core features were implemented earlier.
  2. Spend some more time considering how certain things should be implemented - For example in this game jam, the way that the platforms applied buffs/debuffs should’ve been done differently from the beginning. If it would apply buffs/debuffs that were applied on the player script instead, we would’ve had a lot more control over them, and it would be easier and more correct ways of displaying debuffs in UI. So certain parts need some more thorough thinking before just jumping into implementation.
  3. Try to have core features implemented earlier - Try to have some core features/modules implemented earlier, so that they can be put together quicker, and some more time can be done on balancing and tweaking them to work well together.

Learning reflection

Overall very happy with the learning outcome of this jam. As stated earlier, I had a lot to learn about Unity development; and this was a great opportunity to learn more. I got a better understanding of a lot of Unity concepts. Some examples are:
UI elements in a Canvas.
How Audio in Unity is done, and how to trigger sound effects.
How physics in Unity is done, both on the player with input and other static or non-static gameobjects. Even though I was struggling at certain parts, which probably could’ve been done with more ease if I had more experience, I am happy about it either way, because I eventually got things to work, and thus learned a lot from it.

Apart from Unity, I think we were able to do pretty good scope-management for how much and how things should be implemented to some degree to at least have a good proper product in the end. Even though we hit some bottlenecks, but that’s also a part of the learning experience, lets us think about how we could’ve approached it differently to mitigate it. Like listing separate tasks earlier, scoping a bit differently, or distributing workflow better in different work hours. Those are all ways we could have mitigated it to some degree. To conclude: Very happy with the whole experience as this was my first jam. Pleased with how our end-result ended up, and how we worked together as a team. Learned a lot about different concepts in Unity in C# as well, so also very happy with the overall learning outcome.