-
As a team of two, my game-dev partner and I created this demo project for a game-jam in five days. The goal of a game-jam is to create a playable game within a certain time period following a theme and constraints announced on the first day of the competition. The theme for this competition was “spin to win” - our game embodies this idea through the use of a spinning lazy-susan as the main game interaction.
-
“You are Agent Susan. Your mission? Murder. Your target? Unknown. Your coworkers? Lazy.”
“Deduce who your target is and which drink is poisoned. Spin the lazy susan to win in this very dangerous, very serious, game of death.”
(This is a submission to Juniper Dev's Very Serious Game Jam https://itch.io/jam/theveryseriousjuniperdevgamejam)
Credits:
Developers:
Systems & Gameplay Programmer: Jackie Lowery
Visual Artist & UI Programmer: Juliana Schlichting (this is me!)
-
The three main tools for my workflow on this project were Procreate, GitHub, and Godot. I created almost all of the assets, sprite sheets, and animations in procreate then implemented the sprites in Godot as we were developing the game. We used GitHub to manage different versions of the game which allowed us to carefully push changes and collaborate simultaneously without overwriting each others work and allowing us to reverting changes when needed.
We started the design process by creating a infinite whiteboard on canva to write every object and theme we could think of that related to the “spin to win concept”. As we wrote and shared ideas with each other we would add a star next to ideas we wanted to keep exploring. Eventually we came to the idea about a lazy-susan. At first we thought of diner-dash inspired cooking and food service games, then a family eating at home at the dinner table, but finally we decided to imagine the lazy-susan in a world of spies and assasination attempts since the secondary theme to the game-jam was “a very serious game”.
I illustrated all the visual assets for the game.
Iterations:
Given the limited 5 day timeline, assets and code had to be created quickly. We were able to work on the game asynchronously online to maximize our productivity based on our own schedules. This meant that place-holder assets were sometimes needed so that we could program certain parts of the game without the final art in place. For example, the character sprites and animations took the longest to design and illustrate so the image below was the basic sprite I drew so that our code still had an object to reference and target and the game could still be playable throughout the process. We could have used a blank box, but we found that a sprite that more closely represented the end-goal helped us to strengthen the composition of the scene and tone of the game
The game also required a lot of iteration for many of the visual assets. I believe that the best way to improve any design is to start with something that might not be ‘perfect’, but good enough to get the process started and to collect feedback. I found this mentality is also a core principal in game development through game play testing and constant feedback.
The gallery below shows more examples of how the visual assets developed as we designed and worked on the game.
