Week 3 of Dev Game | Insights

It was our third week developing an FPS video game with time-bending abilities, and it did not go as smoothly as I would have liked. However, I gained some insights that I would like to share that could benefit anyone venturing into game development with a team.

From the beginning of the last week, we got so caught up in implementing the game mechanics that we overlooked key questions such as: What is the game’s end goal? How does the user know they’ve completed the game? What specific tasks must the player undertake to achieve win? And what leads to failure? - that are crucial in ensuring clarity and coherence in game development. In my experience working in consultancy, I’ve encountered similar situations where technical inconsistencies arise due to a lack of strategic definition. If someone reading this is going through a similar situation, here are some learnings you might find worth pondering:

1. Start with a brief game design document before or at the same time you implement the mechanics.

Avoid assuming that everyone agrees on how the game will work, if there is no visible artifact that helps everyone have a clear picture of the game, assume that the discussion is still blurry. Marnix’s one-page template from BiteMe Games is a good start. I made some tweaks to the original, extending the aesthetics and the mechanics a little bit more. I suggested to the team that each one could take a couple of hours to download their assumption into the template and come up with a story and objective. It worked; on the next day, the team voted for the story of a prisoner who needed to escape from a high-tech facility.

Here you can have a look at the changes I made on Marnix’s template:

I came up with a story in which you play as a museum thief in a dystopian future. Your objective is to use your ability to manipulate time to outsmart security systems, evade guards, and steal valuable artworks from the museum’s exhibits without getting caught.

2. Prototyping starts long before you open Unity; take a whiteboard and start sketching.

Once you have a game design brief, which means a clear end goal and one or two possible mechanics, spend time with the team sketching possible levels on a whiteboard. It is cheaper than spending the entire day in Unity and keeps your head on the big picture. Although the team was skeptical about sketching the levels on a (digital) whiteboard, in the end, they all agreed it was a helpful activity. We drew possible game levels and described what would happen to the user at each step of the game experience.

In this example, you can see we used emojis, arrows, and squares to explain what could happen on a level.

3. Using ready-made assets is entirely worth it, especially when the team has agreed on the game genre.

In our case, since we decided to go with a first-person point of view, we used the “Starter Assets: Character Controllers | URP” from Unity and edited parts of the code to suit our needs.

4. When prototyping the mechanics, distribute the implementation workload into data structures and user inputs.

For instance, in our game, we knew that we would be using time-rewind as a core mechanic, and thus, the question was: How can we enable the storage and changing of time data? So Nicolas took care of how to store spatial-time data structures of game objects. Then, Zarco and I explored different ways the user could interact with these spatial-time data structures. I ended up creating an interaction inspired by Zelda’s Tears of the Kingdom’s time power, recall.

5. During prototyping, create GitHub template repositories for the team to enable complete creative freedom and avoid engineering your game too much.

This might sound obvious, but GitHub template repos are your best friends, mainly if you work with a team in which they have not defined code conventions yet. In the early stages of exploration, do not worry too much about engineering your game; it is best to have a basic starter template that anyone can use to create a new repository and change whatever they want without worrying too much about merging conflicts.

Video games are indeed fun, and one could expect that making them would also be fun. However, in the end, specifically, if you are working on a team, one needs to keep in mind that making a video game is not different from designing and developing user application software. You have an audience, a goal, features, visual identity, information architecture, frontend and backend development, testing, deadlines, and all that comes with making fun and usable ready-to-launch software. And this does not take away the fun part of making the game; it is just a reality check.

Next steps:

• We will have our elevator pitch on Monday, April 8, 2024, and based on the feedback we get, we will steer the project accordingly.
• Either way, I will be exploring how to implement level design on Unity for our game.