Together with my wife i participated in 10 Game Jams. We mostly did Ludum Dare in the (Jam mode). We learned so much across those jams and it brought us from never finishing any of the games we started to reliably being able to ship small games. Maybe our learnings can help you too, but the best advice i can give is: participate in game jams yourself.
All advice is from my perspective, which is that of programmer + game designer + director. My wife created all the pixel art. I'll write all learnings as if i'd give advice to you directly, i hope you don't mind. I'll reference my games as examples. They are listed here here and can be played here.
When creating a game, you know all its systems intimately and have played it hundreds of times. You'll probably be vastly better than a new but competent player at the start, let alone a more casual player.
In other words: You'll probably loose all grasp of how the game will feel like for a new player. The best remedy for this is to test the game with new players. However, this is not always possible. My rule of thumb for balancing is this:
This will of course vary from game to game and depends a lot on how skilled you are as a gamer in general. This is meant as a starting point, not the final state of balancing.
If you intend to make a difficult game, you should ramp up the difficulty only after the player had a chance of learning the game properly. Systems that are not self-explanatory need special care in introducing them to the player. Ideally, there won't be too many of those, and they should be introduced one by one with some time in between.
Trahere was challenging and fun for me to play, but vastly too difficult for everyone else. There are many systems in play together, which aren't even clearly communicated and have small intricacies, that no one but me knows. This resulted in most players being quite frustrated, and a few really pushing far beyond what i would want them to endure, struggling for 45 minutes in a game that should take 5 minutes.
For Blackbird, this worked our really well. You play as a bird that tries to raise 3 chicks during one day. The question was: how much time should the player have for this, how long should the day be? I used my rule of thumb and found out, i need about 2 minutes to raise all 3, so i set the length of the day to 4 minutes. This worked out great. What helped here is that the win state is soft, in the sense that the player can raise 0-3 chicks, depending on how good he is. Most players were able to raise 1, and then were motivated to try more, which most managed on the second or third try.
No one likes reading long texts that explain what to do and how, if you want to play a game. Keep that in mind and try to avoid big frontloaded screens detailling all the rules. Ideally, a single instruction is enough for any player to start with, or even none at all. The same goes for classic tutorials that use dozens of textboxes. My rule of thumb is actually a question:
I saw many game jam games that have a lot of explanations on their game page in the browser, which usually results in people complaining about not knowing what to do and how to play. This also happens (though slightly less often) for frontloaded ingame explanations.
You have to be acutely aware of how well players will be able to relate what they see on screen to what they already know from other games and the real world. Everyone will understand how health works - if you stay within the usual usage. Everyone will know that arrow keys or WASD are typical choices for moving. Everyone knows that cat eat mice, or that birds can fly. No one will know the things explained below for Trahere. If you can change something in a way to relate better to what players already know, it probably is a good idea to do so.
Trahere again, man did i go wrong there. With some things at least. I made nice panels that explained all the games systems in a few words. It all made sense to me. The reality: Not a single player learned the game through reading these panels. I estimate that they usually remembered 1-2 panels. This is natural, no one keeps all that information for which no context exists in memory to access it when appropriate. This resulted in many people not understanding what to do and what the game is about.
What i should have done is introducing the systems one by one and teach them through play, not text panels. Text panels can only support the learning, not carry it.
For Fluffensnuff, i started with the simplest level that could exist. This made no sense from the perspective of designing challenging puzzles, but it worked great in teaching the player what to do without the need of any instructions. I didn't write anywhere how you could control the cat. Every player easily found out that the arrow keys are useful for this. After that, it is natural to assume that the cat has to catch the mouse - the player can relate this from the real world, and the size and look of the animals also supports this. Everyone found out that the mouse will flee, but can be sneaked upon from the high grass. This was great, as it allowed the players to figure this out for themselves, which feels much more rewarding than being told how it works.
Collaborating is fantastic and very few games are made without the help of great peers. That being said: Many people get easily motivated to start working on a game, but few have the discipline to stick with it and keep delivering. If you blindly pull in anyone that cries "yes", you are likely to invest a lot of time into onboarding, explaining, motivating and generally directing people. Your time is limited, especially in a game jam, and it can get easy to put more time into the person than the person puts into your game. So ideally, you know beforehand that a collaboration will be fruitful. The best indication for this is the person having a portfolio of some sort, a history of actually creating something.
For game jams, this is a great learning experience. For a game with a budget and timeline, this can be catastrophic. I believe many people are not used to working really hard in their free time - which is perfectly okay, but you shouldn't expect this to change only because you are passionate about your game, and they seem in for it. My rule of thumb for this:
Examples for red flags: communication is really difficult and unreliable even before the project starts, or that there is a clash of expressed motivation and portfolio. Someone who really really wants to make music but hasn't ever done anything towards that will likely not change completely by joining your project. Managing the risk means: Don't tie your deadline to the work under question and have a backup plan. So for example, what if my composer doesn't deliver music? Then i can still go for some free music.
The same holds true if you are looking to join a team. The biggest red flag that i've seen dozens of time is again a clash of ambition and reality. A project with a "studio lead" looking for 4 artists, 2 programmers, a composer, a marketing specialist a level designer (and so on), while having no traceable history of managing people or finishing any project will fail. I have no doubt about that. These kinds are really well meaning, probably hugely motivated and friendly, but it won't work out and you'll waste a lot of time in a team like that. Other red flags are generally not having anything to show for and accepting just anybody who wants to join. I think those are great predictors for projects doomed to fail.
Being pragmatic boils down to 3 points for me.
I like go for the simplest solution to any problem i can think of. I'd only consider something more sophisticated, if i have clear evidence that the simple solution is causing problems. This is especially true for performance aspects. On Aloisius (to the right), i created an embarrassingly limited (non cheating) AI that couldn't think more than one step ahead. But it worked and was still difficult to beat, while a proper AI would have taken 1-2 days alone.
Feature creep. Everyone knows it. But it seems so easy to avoid, if you ask yourself the right question every day:
I lost count how many times i had to answer that with a clear "obviously, no, but i'd rather work on the fun thing than on the necessary". The problem with this is, that while the work is more fun, the game won't get ahead with it. This is of course okay if you just play around with no intention of releasing. You can also do this safely if limit yourself strictly like "one day a week i do something fun but unimportant in the game".
I've regularly been in the situation, where i was frenzily working on something for hours, only to take a step back and realize, that i could be done in 5 minutes if i'd do it differently. On the right you can see Hamster Habits, one of our earlier games. As the hamster, you earn sunflower seeds by running in the wheel. The seeds are physically simulated objects. I was working hard on a little feeder ramp, where they slide down and into the hamster cage. My wife was also tasked with creating a sprite for that ramp. After working on it and having the first version in the game, i realized it would be much easier and cleaner, to just omit the ramp completely and let the seeds fall in from the top. I didn't consider this in the beginning, because it seemed like the seeds should be logically located in the world, not thrown in by an invisible god. Turns out, no one cares. Omitting the ramp was just as good and easily saved 3 hours of work, which is a lot if you have only 3 days to work on it.
In 2011, i was working on a isometric crafting survival game. While genre feels so exhausted right now, in 2011 this era was still ahead and if i had released anything in 2011, it probably would have been a good timing. However, i didn't, because i failed with every point from above. You can see a screenshot below, with the map, a little naked guy, a few rabbits and simulated water.
Fail 1: I created a chunk system, so i could have maps of any size. This was nonsense, i just didn't know how large the map should be and instead of going with a reasonable size, i tried to accomodate anything, so i wouldn't need to decide early. I wasted weeks over weeks on this, not keeping it simple.
Fail 2: I created a water system that flowed dynamically over the terrain. While this was nice to look at, this again took weeks and didn't add anything to the core gameplay. The core gameplay didn't even exist, you could only walk around, while the rabbits did the same. But the water seemed fun to do.
Fail 3: I created a map system that supports different heights. Not a single element from the intended game design/core loop would take terrain height into account. The height was purely cosmetic at that point, but caused many difficult problems. Need i say this took weeks? Easy alternative: Use a plain map, maybe add impassable cliffs like other 2D games do.
Fail 4: I didn't know where this was going, but programmed the systems already, with only a rough feeling how they'd tie together. I thought about water flows, and the water eroding the terrain, and the player rerouting the water flows by digging. Still sounds intriguing to me, but not if there is no core game, for which this system has meaning.
Yeah yeah, stock up on food, sleep well, clean your desk. Everyone has heard the tips in preparation to a game jam. I never had a problem with this, but i learned that i had overlooked some major points in preparation.
Version Control: If you work in a team, set up the repository beforehand and make sure everyone has the tools, the access, understands the workflow. I wasted hours on this during one jam.
Project Setup: You can set up the skeleton of the game and already push it into the VCS.
Export to HTML: Making the game playable in the browser is the best way to get many people to play it. Test this beforehand and make sure it works. I wasted sooo many hours on debugging this during our earlier jams.
Mhhh, kitsch! Honestly, don't be afraid to do something that is edgy, out there, strange, uncommon or might provoke or offend some people. In this day and age it might even be better to go for something like that, but it should always be honest and authentic, not something done for pure shock value (did anyone say dead babies?).
In Hamster Habits your goal is to become of a father of many. So naturally, we were at the point as a team where we had "the talk". I pushed for having an actual hamster sex scene in there, which the other team mates didn't really want to do. In the end, it turned out to be incredibly fun to watch streamers react on this scene, that comes totally unexpected from a rather cute game like this. I won't say it is clever or even better to have done it this way, but we definitely had more fun and the game stood out more.
For Microphage we only had 48 hours. We had trouble finding something that fit the jam theme of "out of control", limiting our time even more. In the end we went for a puzzle game, which is easy to do in many regards. The mechanics are often quickly programmed, and if you run out of time you'll just have fewer levels in the game than you hoped for. The game was well received, but overall, it felt like a safe bet and became the game i am least fond of, from all 10 entries.
That's it for now! I am sure there are many more things, which i'll add if they come to mind. I hope these things are as useful to you as they are useful to me. I know i mostly left out something crucial: scope. But this topic is huge, and should partially be approached through finishing many games. Rule of thumb: If you didn't have time to polish properly, the game was overscoped (which is ok). If you didn't even finish it, for example by having no end screen or, missing a core mechanic, it was vastly overscoped - which is not ok since this heaviliy limits what you can learn.
What would really interest me:
What did you learn during game jams?
What do you think other game makers should adhere to or think about, to make great games?
Where do you disagree?
Please tell me in the comments!