Most game jams are open to the public, and the games that are created are often allowed to be used or sold after the event. However, this particular game jam was done as a company event at my workplace. The intent was to inspire us and develop new ideas for possible games, and any games we created had to stay private and within the company unless permission was given otherwise.
The game jam took place during normal working hours (9-5) over the course of an entire work week, and it replaced our usual respective projects. This kept our groups focused and prevented burnout. Compared to how rushed and limited most game jams are, this was definitely a unique opportunity to practice team game-making.
Building the Team
We as a company split off into groups, deciding amongst ourselves the types of roles we needed. Basic roles you should expect to need are an engineer, a designer, and an artist. If you can get someone with sound design or narration experience that can help add more depth into your game, which is ideal. My team was made up of:
- The Engineer – helped in creating the main game system and working with all the other roles in integrations of their parts.
- The Designer – in charge of level design, enemy & character designs, and combat design. The Designer also took on the role of narration to create a base story for the player to follow.
- The Artist – in charge of creating the levels and character art to fit in with the design and layout, including both 2D and 3D.
- The Sound Designer – made sure there were sound effects (SFX) tied to most actions and narrations as well as having music in the background to add more depth and feel into the game.
Getting Started
As a group, we considered the allotted time given for the jam and started off with a planning phase. On the first day we went over the requirements of the game. For this game jam, the rules were:
- Must be a mobile game
- Must be made in Unity
We had a general idea of what type of game we were working towards, so we spent the rest of the first day creating a design document to plan everything we wanted. We strategized on how best to tackle each section of our game, then we fit these sections into a rough schedule to prevent overworking and ensure progression at a steady pace.
Executing the Plan
Each day we gave ourselves to-do lists of what we would like to have done in about 8hrs worth of work. We took time to help each other when necessary. The designer would work with the artist and engineer to get levels set up with the appropriate assets and scripts attached, then work with the sound designer to make sure the SFX was properly attached to objects/scenes.
If we ever reached a point where we did not believe we could complete a task, the group would come together to either conduct a redesign or decide whether it was worth the risk of keeping that section. As we approached our deadline, we ran into many bugs that prevented the game from playing as intended. This led to some of the team having to pull 10-12 hour workdays to get everything in a working state by the deadline.
In the end, we managed to fix enough bugs and implement enough final changes to create a playable game at the level the group aimed for. In a sense it became very much like a smaller-scale version of what we usually go through as a company when meeting a deadline for our major projects.
Conclusion
At the end of the week, we were proud to present a working game to everyone in the company. Each team started by pitching their game and its story, then showing some of the gameplay and setting it up on several devices for everyone in the company to play. After everyone presented, we held a vote for which game did best in several different categories. It was an exciting day for everyone, and the company relaxed while debating on how to utilize the games that were created.
We as a team were proud of the work we put in and of the end product, and we learned a lot of important lessons. Reflecting back on it, our time-crunch situation might have been avoided in several different ways:
- The rules stated that we could have 6 people on a team, but we only had 4. Having a full team to handle the workload would have helped immensely.
- If we built our team with members that had more experience, we probably wouldn’t have encountered as many bugs, and the bugs would be resolved faster.
- We could have lowered the scope and/or complexity of the game to build a more realistic schedule.
Despite all the obstacles, the one-week game jam was fun, and it definitely helped us grow and learn as a group. It would be a helpful experience for any game maker, and any company.