Gizmo Rabbit is a game jam game made for the SURVIVE Game Jam 2022. The core game was build during a weekend, with the following couple of days used to polish and improvement of the game experience. Through this page you can explore our process, some of our core design decisions as well as dive into my contribution to the game.
If you want to play the game before reading, you can try it on my itch.io page:
Preparation & Ideation
Before starting the game jam, I prepared a jam plan documenting how we might approach the development process over the course of the jam. The purpose was not to define a static process which we had to follow rigiously, but instead to have a established structure prepared for during the jam. The theme for the game jam was: 'The Rules Changes as You Play'.
The Importance of openess in ideation
Openess in the ideation phase was an important learning experience from the project. This insight came from our refining process of figuring out which idea to develop from a pool of 5-6 different game ideas. The rifining process consisted of a brief talk exploring the potential gameplay elements and thematic relation, followed by a discussion of the pros and cons of that idea.
After refining the first of our ideas, I learned that it had already started solidifiyng for one of the members in our team. He was very open about feeling a strong motivational pull towards the first idea specifically, and when we started trying to analyze the next idea in the pool, he found it very challenging. To combat the potential negative impact of this, I quickly moved the post-its relating to the idea out of the ideation area temporarily. After a short while, it became much easier for the team member to evaluate the other ideas more objectively. When the time came to evaluate each idea in relation to each other we moved the first idea back to the ideation area.
In the end, the idea we went with was a concept nobody in the team initially had considered, but after spending time refining each idea, it had the greatest potential for further development. If the team member hadn't been open about his feelings towards the first idea, we might not have been able to adapt our ideation area and analyze all the ideas from an equal perspective.
The initial inspiration for the visual style of the game was drawn from danish cartoonist Storm P. and his drawings of Rube Goldberg-like vehicles. The concept of vehicles constructed from many different ordinary objects complimented theme: 'The Rules Changes as You Play'.
Dapper is a classic word which means 'neat and trim in dress and appearance'. This idea was very key in the design of the rabbit, as it effectively described the concept we wanted to convey. The main character Gizmo Rabbit was designed in Adobe Illustrator and animated in Adobe Animate. The decision to design the character around a rabbit was mainly to keep the tone light and humorous. When playing the game, the players would spend a lot of their time in the company of the Gizmo Rabbit, so it was important for us to make the character fluent and enjoyable to the overall experience. Therefore we decided to spend a lot of the allocated time on refining the design of the character.
Design Decision: Component Placement System
One of the decisions with the biggest impact on the final game was the design of the component placement system. The way each component attached together and to the bike would impact everything from the component design visuals and gameplay to the aethetics of our game universe as a whole. Therefore, this was the first and most discussion we had when starting to develop the game. Several different ideas was presented:
Initially, the component placement system would be designed based on a grid. In this way, it would be easy to control where to place each component. However, when sketching out the idea, we quickly learned that this approach would make the vehicle appear too static and rigid. The vehicles drawn by Storm P. had a much more dynamic and ragtag look, that we wanted to stay true to.
The second design concept to a component placement system was based on developing a script that could find the distance to the center of the bike and then use that to figure out where to place components. When sketching this concept, we saw that this would help making the vehicle more dynamic, however we was also at risk of making it very bulbous and round. This approach wasn't fitting as well.
Our third concept would end up being the actual solution we went with. For this, the component placement system would be based on a chain algorithm approach, where each attached component would consist of attachment nodes. Through sketching, we learned that this was the right approach, as the concept would allow component to be placed in a way that would make dynamic vehicles that was aesthetically pleasing.
Another important decision which originated from the discussion of the component placement system was how to make the connections between each component, and to the bike, as clear as possible. Initially, we discussed if the component placement system should draw lines between attached components, to represent the bicycle frame. However, we feared that this would reduce the aesthetic quality of the components, so we instead decided that the connection points should be communicated from the components themselves, and not be decided by the script.
Environment, Components &
Key Roles in the Project:
AUGH ok my best was 899 and I built an absolute monstrosity but this game is just!!!! So perfectly addicting! I can totally picture myself playing it as a young child in a flash games website. Great job!!
Really cool game - a bit confusing - I don't understand what the components do - especially the ones that don't require you to press a button.