Levelling up from a year of jams

Last year I moved to Berlin and started taking part in the Berlin Minijam. This is a game jam where people have 8 hours to create a game, whether digital, physical, board, pen & paper or just a design concept doesn't matter. There are no real rules, only guidelines. The jam usually starts at noon, participants mingle and vote on theme suggestions for about an hour. Then they form groups or go solo and start working until 21:00 (9pm) when the results are presented, these presentations are also recorded and uploaded to youtube.

Because of their nature videogames are multidisciplinary. However the most often seen backgrounds from participants tend to skew toward programming, probably because that's always been very fundamental to making videogames. I've participated in 12 minijams now, and I've written short postmortems for each of them. The most clear and concise way to consider the aspects of the minijam seemed to be a short list, so I'll start out with that, followed by a couple of boring but practical tips as intermission, and I'll close out with some thoughts on where to grow from there as developers and propose a concrete way to do this.

Aspects of the minijam

Monthly occurrence
+ Never a long wait for a jam, plenty of opportunities to participate and experiment.
- Regular interruptions, tend to occupy the mind, a lot of work for the organizers.

Short time (8 hours)
+ Small time investment, easy to try out, fits into people's schedules.
- Little time to get anything done, might deter people from trying out new ideas and instead fall back to cloning.

Environment
+ Lots of creativity, abundance of silliness, probably plenty therapeutic.
- Perhaps a bit too silly or noisy at times. For instance, close to presentation time some people are working really hard to get that last feature in, while some others are already done and eager to get an early peek at what everybody else is doing.

Themes
+ Themes focus attention, gives people something to talk about, gets them on the same page.
- Sometimes there's a tendency to conform and discard thoughts that deviate from themes.

Theme voting
+ Fair, most people will get something they're okay with.
- The lowest common denominators rise to the top. Themes like retro, 256 colors etc. do very well for instance.

Social stuff
+ Chance to meet new people.
- Sometimes you tend to talk all the time and not get much work done.

Brainstorming sessions
- Tendency for feature creep.
+ You do learn to cut features.

Creating, doing actual work.
+ It gives a decent impression of what making a game is like.
- The omission is of course the big content, refining and polish phases, which may lead people to think making games is little work.

Working together
+ Social skills, getting used to mindsets of people from different disciplines.
- Compromise on ideas, presentation, and redistribution of the work. Not everybody is comfortable with showing failure for instance.

New technology & techniques
+ A number of people use the minijam to try out a new framework or language. I'm impressed with how often this works out well.
You get exposure to different technology and techniques, and that helps you reflect on your own, be more critical, and find out what fits with you.
- It doesn't always work out. In learning new stuff you're very dependent on information, and that may not always be available.

Repeating and refining
+ Working with the same technology multiple times helps you build up a library of tiny helpful things. The code is horrible spaghetti in most cases with plenty of hard coded chunky bits. But, there's usually at least one thing you figured out, and that solution can be added to your utility belt.
- There's often a bit of arguing about which tech or technique is better, always sticking to the same thing can make you sensitive and devolve argumentation into snobbery and elitism (though I've rarely seen that happen, grasping at straws here).

Presentation
+ Resonance with peers, seeing what is doable (If he/she can do it, I can do it), learning from others, social skills++, free applause.
- Scary, sometimes feels like an obligation and that can make people leave early if things didn't really work out.

No contest
+ Room for showing failures to others. Everybody learns.
- Perhaps less drive because of lacking fear of competition. (Though the 8-hour time frame proves to be plenty challenging by itself.)

Small games
- Too small to make money off of them. No room for grand and complex structures in design.
+ Good for testing prototypes, new ideas.

Practical tips from personal experience

- Make sure you're well rested and prepared. Have everything you need ready and installed. Not having code completion sucks, not having the proper drawing tablet drivers sucks. You don't want to lose time on this.
- Bring pen and paper. It really helps communicate ideas and sometimes it helps as a reminder of why you chose to go with A instead of B.
- Bringing up existing games that everybody knows helps communicate your thoughts but also tends to keep new ideas confined, because everybody now has that game in their heads.
- Staying pragmatic often leads to good results. Make sure everybody can work, and doesn't have to wait on each other. Figure out at least some basic visuals and mechanics before you flesh out the story for instance so programmers and artists can start working.
- Make sure everybody's on the same page and knows what to do. Getting something on screen helps.
- Mostly the time limit is hard to deal with. You do not have the luxury to get stuck on a bug, rewrite code, or make lovely placeholder graphics first. In the subway ride to the jam I already tend to design more than I can implement in the time there is. But you learn to cut stuff often and early.
- Iterative development is very stimulating. Get something very simple working first, that helps give everybody a boost. And you'll see new ideas and even completely new designs popping up regularly.
- Don't change filenames, just overwrite files. It's ok to keep a _v1, _v2 around for yourself of course. But others should be able to just copy, paste, new files are in the game, done.
- Being able to show off some basic interactivity really helps. Interactivity is magic. I definitely suggest focusing on that first.
- Artificial Intelligence == Math.random(). Works fine for a 5 minute play session. The same goes for proper balancing, it can be done later, people will get it.
-Re-use stuff from previous jams, use public domain resources like graphics from opengameart.org or take pictures with your phone to create a quick background or even photorealistic in-game characters.
-Save early, save often. You really don't want to lose work because your OS crashed or somebody accidentally unplugged the wrong power cord.

Level up

A thing that often comes up is finishing/expanding the game after the jam. Adding some more features, perhaps try to sell it and make a couple of bucks. It rarely happens, because that's where a lot of the long monotonous days are required. And also, in case of a group of relative strangers who may not all continue to work on the game, it's likely reasonably difficult from a financial/legal perspective. Still, people often do want to do something more with it and not leave the small unfinished experiments as they are.

Some free options, doable by solo developers:
A pragmatic approach that might work could be to release a pack of prototypes in the style of Warioware or Mario Party. You could make a couple of these microgames in one day, collect a bunch of them over time, and release it as a single game. It's reasonably flexible but does have its constraints and you'd need to keep this in mind during development though.
Another approach might be to provide a marketable handle by doing something like Sharecart where certain games share a file between them which influences some aspect of the game, like colors or object placements or whatever. It would cause these games to have something in common to identify them by, so they could present this common thing as a front / image, which might be easier to market.

Of course it also happens sometimes that teams do actually develop jam games into full games. But often these are pre-formed teams from already established indie game studios. A lot of indie developers actually work solo and take jobs as freelancers to get money, and in the time left they make their games. It's not easy and it often happens you can't do everything by yourself, so you have to hire someone else. That quickly becomes expensive, so you end up not working on quirky games as much as you'd like. This is still the same way a lot of studios develop games, do some games for a publisher (movie tie-ins for example) in order to finance your own ip. This is a hard road to take by yourself.
At jams though, everybody works for free...

There might be some middle road here, a hidden path beyond those thorny bushes over there. So I'm proposing to have a look and test a new model. It's still in pre-alpha or whatever, so everything might change. I'll call it rotational tyranny for now. (Don't worry about the name, it's meant to provoke criticism. Consider how a large number of people spend most of their waking lives living in the voluntary dictatorship of a company rather than in an actual democracy as a reason.)

Rotational Tyranny

Minijams produce very small games, decent prototypes, and are small enough in scope that they can often can be polished, finished, adapted and released in a short amount of time. Let's say a week or 4 days by a team of 4 people. If you had to pay each team member let's say $1000 a week ($200 a day), that would be expensive. We're poor. It's an obstacle. It creates overhead. The smaller you are, the harder it is to deal with. So let's try to do without the money.

When would you want to work for free? Making your own game perhaps? Royalties? How about trading hours of work?
Let's say everybody on this team has a small game they really want to get out there, polished, finished, marketed. But it remains unfinished because they can't handle everything themselves or it would simply take too much time and resources for what is not a major project.

You could help each other out for a few days and get their help in return, the bonus being that everybody gained experience from working on multiple released games. Granted, they'd be tiny, but having a list of tiny polished & released games looks a lot better on your C.V./Resume, and that tiny size still allows for original designs and experimentation. The experience of taking a game from start to finish, including concept, multidisciplinary development, website, marketing etc. is very valuable. And it would be a step in closing the gap from creating unfinished gamejam experiments to having a regular job in the big game industry.

Think of it like in the M.A.S.K. cartoon, or Mission:Impossible, or Shadowrun, or wherever you're the cool person that gets to put together a cool team to go do something cool. During your jams you see all this cool work from all these cool people. Imagine if you could work with any of them, cherry pick a well balanced team, and make a kick-ass game.
The trade-off would be that all the other team members get to do the same thing. And you'll have to work on their game as well. Of course every team member would have to agree beforehand, which is why it's a good idea to refine games from previous jams, so everybody knows what they're getting into. And if you can't offer anything of value to the games your team members want to make, you may have to compromise on cherry picking. It might prove a nice balance between specialists and jack-of-all-trades...

There's a lot of flexibility of course but let's take the example above where a team of 4 people (including you) is working on 4 games for 4 days each. That's an investment of 16 days everybody is making, including you, 16 * $200 = $3200. With that you'd pay for 3 other people working 4 days on your game, 3 * 4 * $200 = $2400. You could see it as working for 75% of your income, or a 25% pay cut.

But it's just an example, amount of people and days can vary of course, though I strongly suggest each team sticks with the same team members and amount of days until all the games are done. Otherwise it's likely things will get messed up.

Some more examples, just to get used to the idea:

4 people team, 4 projects lasting 3 days each. Comes to 12 days This could be done in 2 weeks, which makes it viable for a lot more people I think.
In 12 days by yourself, you might make about $2400.
Instead you'd get a team of: (4)3 people * 3 days * $200 = $1800
75% pay.

3 people team, 3 projects
(3)2 people, 3 days = $1200
9 days by yourself = $1800
66%

(3)2p, 4 days = $1600
1p, 12 days = $2400
66%

(2)1p, 2 days = $400
1 person, 4 days = $800
50%

(5)4p, 5 days = $4000
1p, 25 days = $5000
80%

(5)4p, 2 days = $1600
1p, 10d = $2000
80%

(8)7p, 3 days = $4200
1p, 24d = $4200
100%

I doubt really large teams or really long time investments are a good idea. Cover all your bases, from initial design to development with graphics and sounds, to publishing and marketing. But, ensure sure all team members you pick would have something to do all the time. And I'd try to stay below a month at least. Anything bigger is probably a step up from this "rotational tyranny" model. I'm not sure how it scales but it just seems impractical and more safeguards would have to be in place in case something went wrong.

Now you could say I'm being stupid and my time as a programmer is worth more money than the time of a story writer or game designer. But I'd say you were a capitalist and it's more important to create a solid group with solid motivation that can deal with tyranny. That tyranny comes from the leadership. Every team member has their own game which means they lead the development for that game and tell the other team members what to work on. To ensure people are invested in all games, I'd suggest splitting the revenue of all games equally. Perhaps even only selling the games together in a bundle. This also makes all team members look critically at each others games before they commit to working on it. And bundles might make a concise presentation and marketing effort easier as you can provide one front with a decent backstory, you could even provide a mini documentary, focus on leader personalities or whatever.
(Regarding game development order, I'd suggest throwing some dice to determine which goes first, second etc...)

It would probably help to aggregate these bundles on a single website, together with all the promotional material etc. So consumers really learn about what they can expect in general, and which developers they might want to keep an eye on. This also helps developers present themselves to other developers, which becomes a lot more important of course. I'm a strong believer in picking people based on the work they've done. Jams are a great way to illustrate what somebody could do with a couple of extra days and what skills might be relatively useless. (For example I programmed C & C++ for years and created a whole bunch of tools for Square Enix and did data visualization etc.. but it wouldn't really be of much use to these sorts of projects.)
Perhaps it could all be combined with a developer forum, profiles etc. It's very useful to have one place where you can go to get an overview of developers, their skills, their work, what they want to work on, in what capacity, taste in games etc. You want to get an impression of people you're forming a team with, though partially you'd know because you've been going to gamejams right? So it's all stuff that can be figured out after a couple of projects have succeeded.

A large part of this is wishful thinking of course, but I'm willing to give it a try. And it seems like a good way to have time investments in game jams pay off while at the same time maintaining game jams as a rich breeding ground to add to your personal repertoire. Might take a while to get something underway for me personally, and I'll do a writeup once I've got something, but there really is no reason why that should stop you from trying this out yourself right?