Monday, December 17, 2012

New 2013 Madness: One Game A Month

   That's it. I caught the game jam bug.

   Not the acute, 48h, Ludum Dare variety. More like the chronic, one month strain.

   It all started with the story of a guy called @McFunkypants. In 2012 he set up as a personnal quest, among others, to code 12 games over 12 months. He succeeded and challenged everybody to do the same in 2013. So he set up the OneGameAMonth website, to provide a public platform to record progress. There are no prizes, mostly no rules, except the main one: write one game each month of 2013. A system of experience points (XP) has been tacked upon it, to gamify the making of games.

   And I signed up.

   What was I thinking? Oh yes, I know. I'm still trying to generate some external pressure to help me gather motivation and momentum. It worked fairly well for the two game jams I did this year (Liberated Pixel Cup and GitHub Game Off 2012). I think it's more because of the peer pressure of the group of people who joined me than because of the eyes of all other internauts. Real people made of blood and flesh that I see daily have more impact than virtual people made of bits and bytes. I don't know if it means I'm normal or if it means I'm old-fashioned.

The Plan

   So now I have to come up with a plan for 2013. Maybe not an extremely detailed overarching plan for all of 2013, but at least a sketch, a bunch of directions.

  1. I need to get more disciplined if I want to achieve the goal. Build up a routine, probably, to avoid making excuses.
  2. I'll revive and explore further the "tree-growing" concept that we abandoned for game-off-2012. It's already got its own GitHub repository and the proof-of-concept is live at I need to work on core game mechanics, to make sure they are viable. And I want to explore some rendering options. As a first step, I already added a drifting, procedurally generated cloud in the background.
  3. In case I lack inspiration one month, I can expand on Domino Trail. There were several features that we had in mind at start and did not implement (edge-walls, cells with different speeds, new pieces with special behaviour).
  4. I resorted to to help me generate ideas. It's really fun. It's less prescriptive than game idea generators, because it only produces a name. And that's the nice point: you have to put your imagination to work to devise a game that would fit the name. I've had very good runs of the generator and will only reveal one title that could be the hit of 2013: "French Bubblegum Castle." You've been warned. 
   Here I come, 2013!

Monday, December 3, 2012

Another season, another game programming contest

   Just when I thought I could relax, waiting for the results of the Liberated Pixel Cup (not really thinking about winning, but hoping at least to have a decent score), here comes GitHub with a context of its own: Game-Off 2012. One month to come up with a game that should be web-playable and loosely based on git concepts: branches, clones, forks, pushes and pulls. What was I supposed to do? Well, of course, participate.

   I thought about some concepts on my own. The first idea was to go all out on the theme, with an action platformer where you would run and jump on branches, pushing and pulling clones with forks. Nothing really original for gameplay. My second idea was to play the French touch by using French words that sound close to the theme: poule (chicken) for pull, phoque (seal, the animal) for fork, clown for clone. I did not venture further. I'm not sure I want to imagine what a game with clowns, chickens and seals would be. My third idea was to make a puzzle game. They are generally easier to make than real-time action games, and it's possible to end up with something acceptable, even without a real artist: you can always go the "abstract" way. The first puzzle idea was about a tree that you have to grow somehow, using actions like "fork" to add branches, "push" to bend them and cut to stop them growing. I even started a proof of concept, to see if it had any potential. Since GitHub required the game to be web-playable, I settled for HTML and JavaScript. Let's even say HTML5, for buzzword compliance, because it uses the fantastic <canvas> element.

Orphaned tree game concept

   At about that time, I asked for volunteers among my coworkers to help me. I met with two of them, and after our first brainstorming session, the tree growing concept was abandoned. We could not see clearly enough what the goal could be or how to make the game challenging. I thought the goal could be to fill a predefined shape with a set of available actions, but I was afraid all levels would end up being too easy to solve. Being short on time, we focused instead on a domino game, for which the goals and constraints were easier to imagine. In each level, you would have starting points, goals to reach and an assorted set of pieces to make a path from start to goal. Oh, and the board would use hexagons, not squares, to give it an original touch.

   At that point, there were three and a half weeks left. I had already set up the "infrastructure" (github repo, Google Group) so we started coding, slowly, on the low-level parts: how to handle hexagons and their coordinates, how to draw them, how to match a mouse position to an hexagon. Nothing technically hard. The only problem is that it is difficult for several people to start coding from scratch simultaneously. Even more so when the other guys are not so fluent with JavaScript. Anyway, I did most of the initial coding, and we had one formal work meeting every Tuesday to share ideas and build momentum for the next week. As you can see on the graph below, representing the number of commits for the last seven weeks, momentum took some time to build, but when we stopped, we had quite a lot.

Project commit history

   The idea we had, to be able to share a bit of the workload, was to make pieces and levels as independent and pluggable as possible. I refactored a big part of the code to allow that, and one of my coworker coded some of the missing pieces, the ones that fork the path. I also coded the basic UI allowing to select pieces and to put them on the board. From that, it was quite easy to make a basic level editor. The other guy was then able to completely rewrite the drawing code, replacing my ugly looking black and white rectangles that were supposed to be dominos, by a more abstract look that was more pleasant and easier to animate. We thought about making 3D models and realistic domino renderings in Blender, but had to ditch it, by lack of time and competency.

The last tutorial level

   One week before the deadline, we had all the low-level mechanics and pieces we needed, but we had not yet produced a single level, and the global look was not very engaging. That's what we focused on in that last sprint. I wrote nine entry level tutorials, with texts explaining all the mechanics and each one of us tried to design about seven levels to reach about thirty. We got exactly there: 30 levels + 1 level editor.
   We enrolled a few more coworkers for beta-testing and mobile platform testing. I coded some important stuff on the last two days (level locking and in-place rotation and delete) in response to our limited user tests. My team mates worked hard the very last days to find or draw pleasing images and icons, and the game was finally ready. 

   You can play it on GitHub. And you can browse the source also on GitHub.

   For those of you who like numbers (like me), the game contains 3.500 lines of JavaScript code (blank and comment lines excluded), which is about a third of my port of Desktop Dungeons. 
The glorious splash screen, committed during the last 24 hours

Lessons learned

   Doing a game jam is nice, doing it with other people is nicer still, at least in a small team. Different opinions can combine to produce things that would not have been possible alone. And being a small team, we could avoid the "design by committee" pitfalls.
    JavaScript is really cool for short prototype-y projects like this one. And apart from Opera that has poor canvas rendering performance, the game works very well on all desktop and mobile browsers.
    Doing HTML5 makes it easy to target mobile platforms, but their specificity regarding screen size and input methods must be taken into account to produce a good experience. We'll try to find hardware for tests sooner in the project next time. Hopefully, we'll win an iPad from GitHub, and the problem will be solved.