TOJam was a great skill development opportunity and really brings developers back to a grass-roots, guerrilla-style development cycle. It was exhausting, challenging, and ultimately, very fulfilling. The weekend was full of ups and downs, and was a great learning experience.
Chris Regnier, Tim McLennan, Jeff Canam and I, were team Unskippable Cutscene. The game we worked on was called Quotidian Shift, a puzzle game presented as a monthly calendar where you must shift around days on the calendar to avoid apocalyptic scenarios by making sure those days don't happen in the timeline.
Here's an outline of what went right, and what went wrong during the TOJam weekend.
-----------
What Went Right
1. Focused team of pros
The team was mostly made up of development professionals who have been making games for a few years, so we had a deep understanding of what we needed to accomplish and how we were going to do so. This also made communication between team members very easy, as we were all on the same wavelength.
2. Jeff's pixel art
What could have been a potential problem actually turned out to be the best part of the process. Jeff's pixel art was the big draw for our game. His images were beautiful, and were created with the most unlikely of tools (MS Paint, no less). For someone with no game design experience, Jeff produced assets on schedule and was a huge motivating force on the team. We couldn't wait to see what he'd be making next.
3. Project scope
Being experienced professionals, we knew how to keep our game's scope nice and tight. We didn't have any plans for an RPG combat system, dynamic enemy A.I., or customizable character equipment, we had a simple, and focused game experience outlined.
As a designer, I was able to immediately identify, and define, what kind of experience I wanted for the player and created a plan to bring that to life. The project wasn't too big or unmanageable.
4. No pressure
TOJam is a fun event, and we came to have fun! While the jam is an intense experience, it is not a competitive one. Everyone spends the weekend working towards the same goals and the atmosphere is pretty light. We really wanted to have something really great to show off at the end, but we knew that no matter what happened, we would be proud.
5. Managed to make some decent tools for the engine
By Sunday, some key components of the game engine had been completed and it became easier to put graphics and sounds into the game. Finishing these engine elements sped-up development significantly, but so much time was put into them in the first place (most of Friday and Saturday). Our goal was to create updates to Chris' engine that will help make it easier to develop future projects. A possible downside is that many of these features were too quickly "hacked in" and are were not created in the most efficient way possible.
-----------
What Went Wrong
1. Worked on an engine; not on a game
We were using a completely custom-built game engine to build the game, and there was a lot of work that had to be put into that engine during the weekend. Even on Sunday, very little game logic had been put into the game; engine features were being refined and figured out.
The work that was done to the engine will prove to be very beneficial in the long term, though (see conclusion).
2 .First time jammers
Most of the team (Chris, Jeff and I), had never participated in a game jam before and some of us (mostly me) were unprepared for the physical and mental toll that this event would take on us.
Jeff and I had to commute to the event, and did not bring supplies (pillows, toothbrushes, etc.), and discovered that going back home would not be an option. This made the late nights (well into 3 or 4am) much harder to deal with. And our determination to pull an all-nighter during the first night was just a recipe for disaster (what a bad idea).
3. Not enough work for the designer
The concept was completed beforehand, but there was still a lot for me to do on the first day. I wrote a bunch of documentation and outlined an asset checklist for art and defined what features would be needed for the game.
Into the second and third days, however, there wasn't a ton of work for me to do. I was formatting game assets and creating sprite sheets from Jeff's art, as well as some minor scripting. I was acting as a facilitator for everyone else, doing whatever tasks I could do to make everyone else's lives easier. Still though, I was often left wondering what more I could do for the team, and could have been busier. Next time, I will come prepared to dive head-first into the game code and will pitch-in with the programmers.
4. No testing
The game was being worked on right up until the very end. Things really came down to the wire, so there was no time for any testing. As we continue work on the game, there will be a greater focus on testing, there was just no time for it at the jam.
5. Too much time spent on an unimportant feature
Sleep deprivation may be to blame for this one. A lot of time was spent working on getting a custom font system built into the engine. Of course, the realization that we didn't even really need a working font at all came far too late (after quite a few hours had already been spent on it)
-----------
It's always great to test your limits and work within an extreme time constraint. It's a great way to learn some of the most important things when under stress: scope and priority. The most common problem that is encountered during a game jam is keeping the scope of the game tight and focused (it's all too easy for things to get out of hand and impossible to accomplish). The scope of our game was appropriate and we remain proud of what we were able to accomplish over the weekend.
TOJam was a fantastic experience and I personally feel better for having participated! I'll definitely be back next year, and every year from now on.
The story of Quotidian Shift is not over, though, as we're still at work on the game. So stay tuned for more updates!
