I posted a characteristically long blog entry via my account at globalgamejam.org, which I will repost here:
I've survived the Global Game Jam, and my team created something resembling a game. To say that I'm happy with it or proud of it would be untrue, unfortunately. It's hard not to look back at all the things that could have been but weren't, or imagine what could have been added if only we had slightly more time.
In the end, we created an espresso stand themed mini-game, essentially. Was it innovative? Not really. Was it fun? Not in its 48-hour state, but there was potential at least. Was it the game I dreamed of making during the months preceding the Jam? No. Why? What went wrong? I will try to address these questions in a way that won't spiral into hopeless negativity.
My first blog entry listed the lessons I learned from my last Game Jam. I want to revisit them to see how well I did, and then see what new lessons I learned from this one:
* Find a team you mesh well with.
My teammates were cool people, but it was clear that we had very different goals and very different sets of experience. Dwelling on this will only sound like blaming, but suffice it to say I didn't do a good job here.
* Use source control.
We had an SVN server up and running pretty quickly, and this saved us. I don't even want to think about the challenges we would have faced otherwise.
* Scale scale scale
Our overall game idea was indeed very straightforward, but we aimed for far too many embellishments than we should have for a 48-hour game. Probably half of the time was spent creating/working with content in some form, rather than coding actual essential gameplay logic. Because of this, we ultimately had to cut key features of the game.
* Throw solid coding practices to the wayside
I feel we reached a really good balance here. Our code was structured in a fairly logical way but with some corners cut for the sake of time (for example, avoiding unnecessary future-proofness by hardcoding logic which assumes two players).
The lessons I learned from this Jam were mostly rehashes/reinforcements of the previous lessons:
* Find a team that you mesh well with, part 2: I had been excitedly anticipating this event for months in advance, and all my friends knew because I talked about it constantly. Naturally I arrived early, brought tons of supplies/food/drinks with me, set up my laptop with source control, etc. ahead of time. I should have immediately seeked out other developers who shared the same passion. And remember, you are inevitably going to have to compromise on a design idea. So find people who have design goals as close as possible to yours (e.g. don't group with someone who is passionate about Myth-esque puzzle games if you really want to make a retro shooter)
Speaking of design, I might get flak for saying this, but for a 48-hour game, a designer with little or no programming experience is dead space unless they're also an artist. Everyone is a designer. Everyone has ideas. Yes, there are good designers and there are horrible designers. But even a great designer who does nothing but design is not worth it on a 48-hour game. More likely than not, a dedicated designer will only increase the scope of the game by dreaming up infeasible features, causing friction with the developers who actually have to [dare I say] do the work.
If you're lucky, you'll find a programmer who is already good-enough at art. The artistic bar is not exactly high for a 48 hour game, so "good-enough" is all you need. A dedicated, exceptional artist is a great asset as well though, because it's often the aesthetics that really boost the appeal of games of this scope.
I didn't mention sound designers, because again, the scope of the game is so small that sound is often an afterthought, but they can be a great addition if you can afford the opportunity cost.
* Scale scale scale, part 2: Your design should be iterative even for a 48 hour game, but a crucial point is that this design should start extremely simple. Find a core mechanic, keep the mechanic DEAD SIMPLE, and if you have time, iterate on it. Here's a counter-example of what I mean:
For our espresso game, "Cheap Shots", the original plan was to have players create different drinks by pressing buttons in a particular sequence on an Xbox controller. So, one drink might be A, B, B, X and another might be X, Y, A, B (the buttons were supposedly associated with different ingredients). Before we had even completed implementing this basic mechanic, we began dreaming up new ways to add ingredients; for example, holding the trigger and releasing it at a particular time might be associated with steaming milk, or turning the thumbstick on the controller might be associated with stirring the drink. This was a mistake from the start. I ended up spending precious amounts of coding time trying to implement these special case scenarios (keep in mind they all required additional UI assets as well), while core gameplay mechanics were being neglected (score board, game timer, essential UI elements, etc.)
Further, we spent what felt like half of our time dealing with mountains of sound assets that were completely non-essential to the gameplay. These were the types of niceties that could be added after the fact, when the core gameplay was done.
So, in short, it's not just the game that needs to be simple; the core mechanic needs to start dead-simple and optionally build from there after you have a complete gameplay experience.
Here are some additional lessons I learned, though some are minor:
* Make sure that your working environment is comfortable.
DigiPen was great. There was an active work environment with plenty of space. But when you're working for 48 hours almost nonstop, even the minor things can become major annoyances. I was foolish enough to position myself in the middle of a long table, separated enough from my team that any time they called me over, I needed to practically climb over my table or else squeeze by several people to get to them. After the 25th time having to do this, I was ready to relocate.
Also, make sure you have the best setup you can get; a large monitor, comfortable mouse, etc.
As soon as you sense an annoyance, fix it, or it'll be a thorn in your side for the next 48 hours.
* Time is precious; don't waste it.
Yes, I know, this is obvious. My point isn't about goofing off excessively or being lazy. If you're inclined to do that at a game jam, you're probably not passionate enough for it to begin with. I'm talking about other time wasters. For example, you don't need to notify your team about every single change that doesn't affect them, show them every cool thing you added, or ask them questions that you can easily find the answer to yourself (i.e. "Where is X defined in the code?"; there's a search function for that). Remember, assuming you picked a good team, their time is every bit as valuable as yours. Every time you interrupt them in the middle of coding, you break their concentration. You force a "context switch", and it takes them time to regain their focus. Don't have needless conversations in which you explain at length how you intend to implement something; just do it. And similarly, don't explain at length how someone elsemight possibly implement something, unless they are requesting your help or are working on a shared component. They could be using that time to actually implement rather than discussing it.
In the off chance that anyone actually read through this in its entirety, I hope it provides some value.
1 comment:
i did.
Post a Comment