We started out by visiting Limitless (fig. 1-3). We used this experience with VR to inspire us in regards to possibilities and limitations of the technology. Prior to actually trying the VR, we decided on what we wanted to explore, what we would focus on and how that experience could better allow us to “Change worlds / Change views”.
Once we got back to Schön we played “Keep Talking and Nobody Explodes” as to get a better understanding of asymmetrical gameplay.
Last step before we started our brainstorm was to have a group discussion/mini brainstorm about physical games that could provide inspiration for the actual brainstorm. Games such as Smørhul and Johann Sebastians’ game Joust (fig. 4) were brought up.
We made a brainstorm (fig. 5), keeping in mind our theory from blogpost #1. Instead of suggesting just game ideas, we decided to create 5 categories.
- Tech (Orange)
- Game mechanic (Yellow)
- Genre (Pink)
- Concrete game idea (Blue)
- Buzzword (Green)
We then used this board of ideas as inspiration for our further process.
The first problem we encountered was our idea of getting smartphones to work as controllers, so more players could join the game. Trying it out, the tech didn’t work, but we quickly decided to explain that the controllers are placeholders for smartphones when playing the demo.
We moved back and forth with how the Wizards and Warlock could and should win the game, but solved this through our numerous playtesting, seeing what worked best (fig. 6).
Taking our skills into consideration, we were able to do most things ourselves. But none of us have experience with making 3D art, which our game requires to create immersion. We ended up using art and props found online, making sure we used models where the license allowed us to distribute the game afterwards.
Overall, when running into challenges or disagreements in the group, we discussed it thoroughly and solved them democratically (fig. 7). We kept this mantra in mind always: KISSAKYD; “keep it simple, stupid and kill your darlings”.
When deciding on our game, we used the previously mentioned brainstorm and used that as a starting point (fig. 8).
We discussed which elements and ideas we really liked and wanted to move forward with. We chose two ideas that best included these key points and pinned them on a new board. Then we discussed these two ideas and came up with pros and cons for them (fig. 9).
When discussing these, we narrowed in on what we wanted to accomplish with our game, and we took turns saying what each of us felt best represented our project and which we were more exited to work with. That narrowed it down to one game idea; Warlock v Wizards.
Here, our work progress can be described with the diamond-process model; We diverged with the brainstorm. Then converged when we chose the best ideas. Then we diverged again when coming up with all pros/cons we could imagine with each idea, and converged again when we decided on the final idea (fig. 10).
Furthermore, when deciding on our project we used sketching as a way of conveying ideas to each other and pin down concepts (fig. 11-12).
When we started the process of developing the game, most of our decisions were made through discussion. We made all decisions together, based on our notes, sketches and through playtesting.
We made a mood-board (fig. 13) and soundscape early on in the process, to agree on a collective direction for the art style and atmosphere of the game, and to infuse the room with this atmosphere. One could say we moved the virtual space of our game, into our working environment.
We decided to introduce structure early on in the development of our game to make sure we were on time for the deadline. As well as to visually illustrate what had to be done, who were currently working on said task (using color coordinated pins to represent group members), and how far along we were in the process (fig. 14). This also served as a means of motivation as the tasks moved towards “done”.
We knew we wanted to playtests as soon as possible when we had a playable demo.
Internal playtesting allowed us to identify issues and adjustments that had to be made, while documenting the different iterations of the game (fig. 15-16). With each playtest, tasks were updated on our time schedule.
In addition to internal playtesting we did a few sessions of external playtesting to get unbiased opinions.
We documented everything throughout the development of our game, utilising several methods. This process of documenting our Game-Jam experience has allowed us to reflect both in action and on action.
- We co-notated as many discussions / updates as we could, but unfortunately when the network went down, leading to upload issues, we decided to just locally record our discussions.
- We made blogpost updates for each of our presentations.
- We made a chronological summary of the entire process in a google doc.