Blood Ticket
Raul Esteban / October 2022 (580 Words, 4 Minutes)
Blood Ticket is a game made for submission for the MashUp Game Jam 2022.
Initially when joining the game jam, I was planning on working alone, but speaking with one of the participants I ended up forming a team. With a week ahead, we planned to have our brainstorm session on the first day.
The Brainstorm
“Give me six hours to chop down a tree, and I will spend the first four sharpening the axe.”
My role in the team is project management and gameplay designer. I oversaw the project and made sure all logistical needs were ready. A lot of the team was very proactive and started to set up a trello and a remote repository for our work, which was a requirement for our collaboration. From there, I told the team that we would be spending the first entire day brainstorming for the game idea. This was agreed on, and I think this was extremely important. Settling on an idea too quickly without thinking about it deeper in terms of how gameplay can be implemented is important in limiting our scope.
We had a lot of ideas, but settled on a top down shooter where we shoot zombies and bring their corpse to a vending machine for points. This is a very basic gameplay loop, being unique enough where it can stand out, and very easily done on a technical level, which is why I heavily recommended this during brainstorming. Without this, we might not have made a game with the quality we wanted, so on the next day we started to get to work.
Getting it Done
Because the team had two dedicated programmers, I let them do the work. However, I told them that I was going to work on the camera. The camera systems in top down shooters is important as a designer, as it’s effectively the viewport for the player, and what the player can see. With study on other games in this genre, most games use a dynamic camera that focuses on a lerped point between the player and where they are aiming. I’ve done this sort of thing plenty of times, so I implemented it easily and tweaked it so it felt good to the player. The camera also smoothly moves to the target point to avoid an anchored viewport, while being fast enough that the player doesn’t get motion sick or is unable to aim properly.
I knew this was key, as a camera that is simply static and anchored to a game object doesn’t feel right. With a viewport that smoothly transitions to their cursor, the player has a lot more dynamic control over how they see their surroundings, and it feels better to use compared to a camera that is on a static position relative to the player. Not only that, it expands the view compared to a static camera. Games like Enter The Gungeon and Nuclear Throne use similar camera styles, which is something I studied on.
Release
Nearing release, we started to code freeze and worked only on fixing bugs. At this time we were discussing balance, in which a lot of tweaks to ai and player code was needed. Anything that was sensitive to the final outcome of the game in terms of design is something I put my full focus to. UI elements were discussed with the artist and I programmed the UI Widgets at this point.
Once the game was released, a lot of the feedback was positive. Because of the limited time in a game jam, most of our negatives were in the performance of the game. However, the gameplay was praised in it’s challenge, which was important to engage the player. It was unique as well for most players which is what I anticipated with this idea that really only adds a layer of a gameplay element on top of a known genre. We were also told by the organizer that the game felt good to play, with snappy gameplay feel. This is something I tested extensively with the camera, making sure players felt as if looking around was easy and “felt good.”