Early last year, Ubisoft Montreal held it’s second internal onsite game jam, and as per usual, I didn’t blog about it whilst it was happening. With the 2015 Global Game Jam on the way I thought I’d write a few words about that last experience. However, it is worth noting that I have left it a lot longer than I should have – the old brain doesn’t retain information like it used to, and 2014 is already becoming a bit of a blur. That said, I managed to write up a couple of notes during the tail end of the jam, so at least I’ve got something to work from and write up…
It seemed that everyone involved in the first Ubisoft game jam was itching to participate in another – upon announcement, the seats were filled and registration closed rapidly. It’s not like we couldn’t all just do a game jam whenever we wanted, it’s more the organisation – it’s having a site as a central location for participation. It’s having multiple teams around you, giving that sense of a community and proximity. And this is why I’ll be at the Global Game Jam this weekend.
The Team
Anshul Goyal (Programming)
Aidan Green (Design and audio)
Scott Morin (Design and audio)
Sean Noonan (Art and design)
The Theme
You and I.
We basically took this to mean “co-op”, or at least making a game with more than one player. From this, we decided that we wanted to push the theme as a real world constraint rather than an in game or narrative one. From early on Scott and I talked about using the jam as an opportunity to create an “installation” style game - something that would likely only ever be played on the weekend of the jam. Whether it be from physical constraints, hardware setup, or indeed Ubisoft-centric legal issues, we set out with the possibility in the back of our minds that our game may only ever be played once.
Unlike the Global Game Jam, the Ubijam provides the theme a couple days ahead of the event – this is where Scott and I did some brainstorming and wrote up a couple of ideas matching the “You and I” theme with our self-imposed “installation” constraint.
We came to the conclusion that we would use the philosophical maxim of the three mystic apes, known as; “see no evil”, “hear no evil” and “speak no evil” – directly serving as the source of inspiration for our real world constraints.
I wrote small first pass pitch document ahead of time to help cement the ideas that came about from our discussion…
The Jam
We started out our brainstorm with some debate. The private discussion between Scott and I before the jam, unsteadied the usual balance in our team – we were seemingly coming to the table with many of the angles already covered and there was a sense that much of the design was already done. In reality it was more that we’d established the treatment of the theme as well as imposed some additional constraints, and it wasn’t long before we were brainstorming the core design of the game with the approval of the rest of the team.
For the longest time we were confusing ourselves over which sense would be deprived from which player and how that would effect the game. Whiteboards were used heavily throughout these discussions as a constant reminder as to what each player could perceive and do. We agreed that to keep the game accessible and easy to read, we’d be willing to break the 4th wall and have the real world constraints not truly represented by a player’s in-game character.
Oddly enough, we had some heated discussions over the merits of elevators rather than ladders and vice versa – little did we know these would come back to bite us in the ass throughout development…
We left the meeting room with a design for a platform-puzzle game not too dissimilar to The Lost Vikings; with one player wearing a blindfold, another wearing noise-cancelling headphones, and another unable to speak (no ball gag present) – all puzzles were to be completed via communication that respected these constraints. This meant some communication had to be done within the game, and some in the real world.
Knowing that one of our players would be blind-folded, we quickly settled on tile-based movement in order for a blind player to be told to move X number of steps by the deaf player (Knightmare flashbacks) allowing them to tap a direction a number of times. The deaf obviously acted as the blind’s navigator – there was a clear partnership here. Our problem was the relatively autonomous mute player, whom couldn’t verbally help with direction, nor respond to audio from the game in the real world. The mute player naturally became the defender, fighting enemies around the other two players and participating in time based visual puzzles, allowing the deaf player to relay the action of both themselves and the mute to the blind. It was an interwoven design and difficult to summarise, but after a level or two we would drip feed the mechanics slow enough to teach players at a safe pace. Perhaps too safe…
Game production started fast, and we were able to see the game shaping up quickly thanks to the heavy use of placeholders. We were sticking to “form follows function” and were strict on that, we didn’t have a form until the end of the first night – after the game had already reached a playable state. This was completely down to me. I had a bizarre set of seemingly random ideas that somehow linked together in my head, but not when I said them out loud.
By morning I’d come up with a means to tie all of the disparate elements together. You’d be playing as souls of the dead in a series of challenges placed upon them by Death as a means to escape Purgatory.
There was never really a point when the game didn’t seem ‘weird’
– what with having a 17th century fusilier alongside a world war II field hospital nurse, that communicated via a gramophone, whilst an 18th century general sat on a gravestone with a hidden pressure switch to open a door…
Yup!
It made sense to me, alright?
All in all I was quite happy with the visuals, and the strange world I had concocted. I spent a little too long early in development with animation tests, not really thinking about the tile-based nature of our in-game movement. Animation would just add noise to the proceedings. We ended up just having the characters, or ‘pieces’, slide along the ground between tiles.
Scott and Aidan really hit it out of the park when it came to the level designs – they had a full plan and level progression with design patterns in place. A huge volume of content. By the end of the second night we had all of the art in the game and most of the levels fully playable. It was a pretty smooth jam from there…
…except for those FUCKING LADDERS. I’m not the code guy, that’s Anshul, so I can’t really shed any light on why they caused us so many problems, but they really did a number on us. We were basically screwed over by ladder bugs for the bulk of the (playable) production – many of which caused full on walkthrough breaks in the game. Some of these bugs were never fixed, halting progression through the levels at the midpoint of the final game.
Just some images of us playing the game…
The Postmortem
What went wrong
1. Brainstorming without the full team
Scott and I had discussions about the design before the jam and without the rest of the team. This meant we were going into a brainstorm session at the start of the jam with a pre thought-out plan. This perhaps alienated the other team members and resulted in a slightly slower conclusion being formed around the design in the early hours. If you work in a team, it’s best to have every member of that team involved from the outset. This is something I’ve seen happen in professional development also – the withholding of information in the early stages of production can leave an air of animosity or rebellion for those not on the “inside”. Games production is a collaborative effort and their conception should be also.
2. Unity still sucks at 2D
…or at least it did for us. Without good grid snapping and scale options, a tile-based game can be a real pain in the ass to build levels for. I’d made quite a lot of art for the game including purely aesthetic clutter that had specific layer and placement requirements – this slowed the polish phase down to a crawl, and caused some last minute friction as tiredness set in within the team.
3. Too much content, not enough testing
While our drip fed mechanics and level progression were admirable for a full production – they just killed pace in a demo environment. The difficulty curve and mechanic progression was far too slow. We had the game paced like a AAA retail title, not the installation style jam game we pitched at the beginning. Any time spent creating a lot of this content that went unseen by most players should have been spent on testing and polishing the content they did get to see.
What went right
1. We used placeholders
This was a massive improvement for us as a team, and a particularly huge benefit to me. With placeholders it meant whenever the rest of the team demanded assets from me, it was out of aesthetic desire rather than functionality - a great spot to be in, though sometimes the pressure to create something "not shit" can get to me and make my confidence waver (not difficult). Somehow up to this point I keep lucking out...
Anyway, this process was super smooth from my point of view, though I did witness the aforementioned Unity specific woes regarding grids, snapping and layers – from a distance (Disclaimer: I generally didn’t leave Photoshop) it appeared that the issues weren’t with the functionality of the tools, but rather the usability of them. This isn’t the first, second or even third time we’ve had issues with Unity in 2D.
2. Feature complete early
The majority of our code base, and most of the art placeholders were in good shape on the first night/second day. This gave us a clear idea of the amount of content we were going to be able to create and gave Anshul some time to work through any bugs (LADDERS) that were already scuttling about.
3. We all had a place
This was our fourth or fifth jam together, so we knew each other’s strengths and weaknesses, and therefore didn't need to spend time deciding roles. Knowing a person’s abilities, preferences and limitations can really help with communication, especially mid jam to late jam as tensions build. And possibly for the first time since we’ve jammed together, all of us were working up to the wire. We all had an essential role and could continue to contribute until the very end.
The Game
While the game isn’t available for download anywhere, it’s real world requirements would make it an unlikely sell to most people anyway. Not many people have a blindfold, noise-cancelling headphones, a ball gag, three people and three Xbox 360 controllers handy…
However, you can enjoy the trailer!
So that was a fun jam! Here’s a list of post mortems from some of the other jams I worked on…
- Global Game Jam 2014: Bad Mood Rising
- Game Boy Game Jam 2013: Jack B. Nimble
- Ubisoft Montreal Game Jam 2013: Spring Break
- Global Game Jam 2013: Hjarta
I had previously stated that I would be going back to do a post mortem of Bad Cloud (Game Boy Game Jam 2014) but now that the full version is on hold and likely cancelled, I won’t be talking about it any further. Sorry.
I hope you find those post mortems either useful or interesting. If you’d like to follow the development of the development of our next game jam game this weekend, then you can check my tumblr or go to my GameJolt page where we will be posting updates and test builds throughout development.
Wish us luck!
Posts
