First we needed to decide if we were going to make multiple games, say 1 game for every couple of people, or have all 6 of us work on the same game. We decided to make 1 game together.
My first idea was to make a game where blocks fall from the top and you control the platform they fall on. You need to try to stack them as high as you can. You can move the platform around with the mouse but there are physics so if you move too fast the blocks you have already placed will fall over. That game seems like it wouldn’t have taken more than an hour or 2 given that we have access to physics libraries like box2d-js. It would have also been hard to do that game as a team.
There were a few others ideas.
The idea we settled on was to make a 2d tile based dungeon crawl type of game, the twist being that the hero is computer controlled and as the player all you can do is place level blocks to help the hero or hinder the monsters as the hero tries to get to the exit.
We had 2 days, about 13 hours on Saturday (10am till 11pm) and 7 on Sunday (10am to 5pm) and with 6 people we had some big ideas. One was we wanted a level editor because ultimately this game is about making puzzles and without an editor it can be rather tedious to make levels. It also occurred to us that editing levels to make puzzles and allowing the player to place blocks is almost the same activity so we could use the editing code for both features. We also wanted to make it connect to Google App Engine so users could make their own levels and share them with friends. It sounded easy enough.
It was easy to split up tasks. Someone could work on the tile based level system, another could work on the editing system, another on the entity system, yet another on an animation system, someone on graphics, another on an audio system, someone on the App Engine part, etc..
Vincent pointed out there were some sets of tile based graphics from another game jam which meant we didn’t have to spend too much time futsing with graphics.
It was interesting to get started. Most people who do game jams already have a game engine. They already have libraries for simple game UIs, input, loading assets, various editors, audio, collisions, etc. We had nothing. We did have all the features that HTML5 gives you. HTML5 already has some input, it already loads JPGs, PNGs and GIFs, it can play audio, layer things, etc but still we were really starting from scratch.
We didn’t know how late we were planning on staying but we had started at 10am on Saturday and by 6pm we had almost nothing working.
Progress did happen quickly after that though. We got stuff on the screen, we got our first hand edited level up. We got the editor working. Got sound in. Path finding was added. Characters started moving around. Animation was added. Loading and saving levels locally was added. By afternoon on Sunday we actually had a working game. We didn’t have time to design any levels but we were pretty happy with how much we got in.
No it’s not an amazing game but I’m still proud of how far we got. We learned a lot and had a great time doing it and made some new friends as well.
Picking something easy to split up. Because of the idea we picked it was easy for each person to find something to work on at all times. Of course if he had had an engine already or picked really simple ideas we could have worked on multiple games which would have removed the need to split up the work.
Letting people do it their way. When coding as a group it’s easy to spend a lot of time discussing code design. In our case though, given that we only had a few hours, it was better just to let each person do whatever they wanted and then work with their choices. If we had discussed code design for hours we would never have finished.
Choosing something that needed an editor. At the end of the jam we shared our game with the guys in Research Triangle. They had created 4 games to our 1 game and something that was stuck out to me was that none of their games needed an editor. Writing an editor not a small amount of work, especially if it is going to be presented to the user because it needs an understandable UI and UIs take forever. If we had chosen a game that didn’t need an editor we probably could have made more progress.
Trying to do too much. Originally we wanted users to be able to create levels and save them in App Engine to share with their friends. It sounds easy enough. Each level is just a JSON object so all we’d need to do is send and receive JSON objects from App Engine. While that would actually be easy you then start running into all kinds of UI issues that will end up taking a ton of time. You’d like people to be able to browse levels so now you need screenshots and pagination, maybe even search or list by user. You’d like to some way to rank them so the good ones make it to the top of the list. You’d like people to be able to name them, own them, delete them but not let non owners delete them. You need people to register so only they can edit their levels. I could probably make a huge list of things that would be needed to actually make sharing levels useful. Needless to say, we didn’t get the game integrated with App Engine in the time we had.
Next time it would be nice to start with an existing engine. The ability to load assets would be great (animated models if it’s 3d). To already have a working entity system. A collision system. Path finding. Possibly physics and even various editors. All of those would be great.
Another is to choose something that doesn’t need an editor. See above.
I also wished we could have chosen a tighter theme. The idea of “placing blocks” is pretty broad and in fact we arguably failed. We started with the idea the player would place “blocks” but if you check out the game we made I’d argue the player is placing “items”. The distinction might be subtle but personally I think we fudged it.
In the future though I’d really like to see a stronger theme and some prep around that theme. I met some of the guys that participated in what may have been the first game jams. They had lots of prep. They’d pick a theme. Some of them would spend time making a library to support that theme and only then would they meet and jam. For example their first theme was lots of 2d sprites so they made an engine that could draw 100,000 sprites at a reasonable frame rate and then all the games were based on that engine. For another they created a 2d physics engine and based all the games off that. For yet another they created a camera library for image processing live video and made games based around cameras. They also did an audio one where they made an audio library and based all the games around audio.
I think the stronger the theme the more likely strong and interesting ideas will come out of the jam. Constraints lead to more creative solutions in my experience and on top of that, picking a theme and then writing code to support that theme before the jam means that when the jam starts there’s a lot of code to start from.
I’m hoping we’ll do it again soon.
Added: Vincent posted about the game jam as well, head over there for a video of how it’s played.