basic gameplay done, faction diplomacy system done, sound done, controller support done, controller mapping ui done, game over screen done, TODO: eat

also gifs gifs gifs after the break

Since everybody said last time I should have posted this sooner:

You can make a game for a game jam that works great on your machine, but is still a pain to play/rate/criticise for others. I have done so in the past. Please respect your fellow developers and their time! Make sure they can rate your game easily.

Do not …

… call your download theme.zip, ludumdare.tar.gz, game.exe or ld48.jar: If two people name their file after the game jam, or the game jam theme, there will be confusion.

… put a “Web” link to a Unity WebPlayer thingy or Java Applet: This does not let players know if your game works on Linux/Android/RasPI/iOS.

… upload .exe files only for Java, Lua and Python games: This excludes players on OSX/Linux who could just run your game if you had spent less effort packaging it.

… write “there is no Linux build”: Now it shows up when you for “Linux”.

… make arrows+x+z your only control scheme: Some people have French or German or totally different keyboards

… terminate the program on victory or player death

Do …

… give unique filenames: something like developerjamgamename.zip

… put your name, twitter, game name in the title screen

… be specific about platforms: Name your links Web(HTML5), Web(Flash) or Web(Unity)

… provide platform-independent packages: Upload .love/.jar/.py/.z5 files for mac/linux users if you can’t make an .app or .deb file. Other game devs may have java or inform7 or löve installed for their own game development.

… say what language/engine you used: Some people can’t run certain engines or versions of engines (like UE4in Wine or Unity 5.1 with certain integrated graphics processors)

… make unusual requirements clear: This includes gamepads, LAN or local multiplayer, motion controllers like Kinect, VR hardware

… host a public server for online multiplayer

… test if your game works on another machine: Sometimes you forget to package an asset or other dependency like an mp3 codec.

… port to more platforms later

… keep the time/effort to play your game in mind: People who rate 25 games don’t have time to sit through half-hour cut scenes or clicker games that require you to click for half an hour straight.

Thanks, and please comment what common mistakes make rating hard for you!

Guess what you will have more of!

It's sheep!

I am not quite sure about the colour palette...

Good Night! I'm going to bed now. The Adequate Shepherd is not yet done, but I'm going to bed after fighting a stupid collision detection bug all day. I'll submit the game to the JAM tomorrow.

If you can't sleep, try my current progress: PROTOTYPE IN ITCH

Also @sheepolution, how did you miss this idea?

I did something wonky with collision detection in this LD, and it resulted in a lot of the problems everybody is noticing in The Adequate Shepherd. I did a bit of research on how to do it better, and I realised an my old Ludum Dare 35 compo game could profit from my new knowledge as well.

So I give you Shiftromino+, and updated version of Shiftromino with better controls and a new level. More levels will come!

Happy New Year!

The Adequate Shepherd was not very good, but not for interesting reasons. I just got stuck finding a stupid bug in collision detection caused by a stupid off-by-one error. Then I ran out of time, decided to add on another day, and added a rudimentary goal system to the bare bones mechanics on Monday evening, and uploaded what I had as a jam entry.

I am quite happy with my pixel art though.

The Adequate Shepherd has finnicky controls, stubborn sheep, and no interesting gameplay loops on top of the core mechanic with bad game feel. Sheep have constant speed and a randomly shifting direction angle. Sheep don't have good flocking or herd behaviour. There is some herd behaviour, but it is backwards: Sheep push but don't pull each other. The hitboxes on the dogs are too big. Dog path finding does not work. You can only select one dog at a time. I knew all of this when I submitted the game, but your comments really hammered the point home.

I could go back and fix the game, but I might as well start from scratch. In the best case, a fixed version could be a poor man's Stardew Valley, except with only sheep and nothing else. So I won't.

Instead, I decided to make a post-jam version of my LD35 game Shiftromino with better controls and more levels. Shiftromino could really benefit from more content.

This level will be the next version:

Maybe you will be able to rotate the tetrominos after all!

I wanted to write a post-mortem about our old game Wyst for some time. It's one of our games that deserves a post-mortem most. Based on LD32 and LD30, I have written about things that can go wrong in games in general on tumblr, and I have written a post-mortem on Mead Boy: design, drunk game feel, level design, what went wrong.

My post on Team Work for Game Jams and the third section of my post Puzzle Game Design pretty much describe our approach to Wyst team work and riddle/puzzle design. We avoided all kinds of mistakes we made in LD31 (too ambitious, too incoherent), LD32 (neat idea, more of a prototype than a game), and LD33 (main mechanic is too simple).

But instead of a post-mortem of Wyst two years later, I have decided to make this:

A developer commentary system! Click play and you hear something about this part of the game! Now I just need to get @gnihad, @fastpath, @fantasieleben, Fabian, Sven and Jonas to record something, and we could have something much cooler than a post-mortem. The exploration in Wyst is great for developer commentary, because you can stay a while and listen, without having to worry about running out of beer, wolves eating your sheep, or a marine biologist downgrading you from supernatural cryptid monster to mere aquatic animal.

Stay tuned!

A couple of years ago, I had written an angry longpost about bad puzzle games in Ludum Dare.

Now it's time for an angry listicle about rhythm games:

1. If you have music, please make the rhythm align with the beat of your music
2. Please let me correct for input delay or audio delay
3. At least have the same BPM in your gameplay and audio
4. Please let me pause the game

• Level Design
• Game Feel
• Potential to turn this idea into a long-form (or commercial) title
• User Friendliness
• Polish
• Story/Narrative

Post-Compo Version

I have replaced the LD version of Dear Clicker with a post-compo version with significantly cheaper upgrades (less clicking) and a speedrun timer (more replayability)

Play here: https://blubberquark.itch.io/dear-clicker

As you can see, you can now comfortably beat this game in under 10 minutes and with under 2000 clicks.

Rating Results

I was somewhat happy with my Ludum Dare 41 results, because this game is kind of obscure: Riffing on two other games, not fun, comedic but not laugh-out-loud funny, deliberately bare-bones. I made lot of things bad and weird on purpose: Invisible walls, jumping, empty areas. I felt that the slow walking speed, sparseness of the level layout and the absence of meaningful interactions called attention to the linear, gamified structure of Dear Esther, and I wanted to replicate that in an exaggerated way. If you don't know Dear Esther, this game is just weird and slow.

Nonetheless, this is the best I have ever hit the theme, and a good overall score. I was expecting far worse for such a meta, high-context joke game.

Postmortem

On the morning of day 1, I thought about themes. My first idea was to cross a social sim with a metroidvania, like in Persona, but you have to hang out with friends to get the double jump. I had thought about this idea before (somebody please make this!), but it was too ambitious.

Instead, I went with walk sim and clicker, two genres with lots of free time and waiting, and an emphasis on subtext and slow discovery. I generated an island with my trusty lowpoly-island-generation script, loaded the island into Wings3D, and sculpted a path. Then I re-sculpted the mountains around the path until it looked nothing like what my script had produced in the first place.

I had a sore throat (it's better now) and a German accent (still there), so I sent out a "casting call" to my internet friends to record poems, and researched poems that fit the theme of the game.

On the afternoon of day 1, I loaded the island into Unity3D and started coding up the clicker game part. At first I added clickable buttons to the UI layer, but my first hacky prototype that used keyboard keys for buying upgrades looked better and was easier to use than having a split-screen where the mouse is used for looking around on one half of the screen and for buying things on the other.

On the morning of day 2, I added the first poems recorded by my voice-actors to the game, and uploaded an in-progress prototype for feedback. I played through the game several times to get the costs of the upgrades right, but it turns out I aimed much too high. I modelled some clicker game paraphernalia, and put them into the game.

On the evening of the second day, I integrated the last bits of voice acting, uploaded the finished game, and went to bed on my usual schedule.

What went right:

• Scope If anything, this idea was too small. I could accomplish everything I set out to do.
• Game Idea It fit the theme really well, and nobody else had the same idea!
• Tools I used Wings3D to edit the static meshes, Emacs to edit the code, and Audacity to cut up the sound files. Unity3D fit my game idea. Unity3D can be overkill for jam games, and the data structures of Unity can get in the way of just drawing stuff on the screen (use Löve or PyGame instead), but for a first-person exploration game, it was perfect.

What went wrong:

• Audio Quality I had talked to the voice actors on Discord and didn't think it was a problem at first, but a couple of them had really bad audio quality in comparison and had to be cut from the final game. One of the poems in the compo version sounded much too quiet.
• No background music/ambiance I didn't want the poems, which can be triggered at any time in the game, to be overshadowed by chirping bird or the sound of waves. I didn't add background music because I didn't know how much poems I would get in the end. The compo version has a lot of silence. The result is too sterile.

What could have gone better:

• Game Balance The game definitely required too many clicks.
• Visual Style Not enough going on, no exciting vistas.
• Game Idea I vastly overestimated how many of you have played Dear Esther.

Call For Participation

Dear Clicker is not quite done. The next version will address the sound issues. I would like to add more poetry to the game, a bit of randominsation and scatter more weird 3D artefacts in the landscape. If would like to read a poem for the next post-compo version of Dear Clicker, please comment below!

PLAY HERE (Sorry for quality. I wish I could upload a crisp 400kb WEBM instead of a shitty GIF)

I added more stuff to Asteroidvania: Two optional powerups, a map layout that makes a bit more sense, and bigger caves to explore. Right now it's a bit empty, but the next update will have more environmental hazards, power-ups to deal wit them, and new, more varied environment art.

play it here and tell me what you think or comment on the LD submission page

The search function is still "coming soon", and the third-party games browsers have not been updated for LD43.

So if your game has a native Linux build, or is a cross-platfrom game made with Java, Python (2.7/3.6/3.7), or Lua/Löve2D, comment here and I'll play/rate it. Or comment to tell me how to sort by platform, in case that feature has been implemented and I just could not find it ;-)

I have a level.

I have animations and controls.

And I have an idea I just need to follow through on.

Play and rate here

Deep Sea Settler is a puzzle-ish colony builder. It's loosely, or rather unconsciously inspired by Reus, Dorfromantik, and Solar Settlers from BrainGoodGames. I interpreted the theme thus: You have to slowly build out your underwater colony by placing buildings farther away from your base, deeper into the ocean, and spread in a hostile environment - without destroying said environment.

Day 1

I came up with two main game ideas for this theme: The first was a game about a submarine navigating in complete darkness based on sonar and dead reckoning. The second was an under-water colony builder with an ecological theme.

The first would either have looked really boring, with no visible environments, only 2D submarine controls and instruments, or it would have been too much work to mode the interior of a submarine and interesting underwater environments.

I decided to work on the colony builder, and to set it on a hexagonal grid. You start out just below sea level, and as you go on, the sea bed gets deeper and deeper, sunlight becomes scarce and pressure increases, so the game gets more difficult. (The depth and difficulty mechanic did not make it into the final game, but tiles of varying depth did.)

I started by working on the art and rendering code.

I made a simple renderer for infinite hex tilemaps (stored in a hash table), and drew some tiles. They all had a "base" or "depth" to them, allowing me to raise or lower them a bit without "floating" over the playing field. After seeing the tiles arranged like that, I decided to re-work the tile shape to allow for a better perspective when drawing tile contents, and I drew a bunch of tiles based on an ecological and "humorous" theme:

A fishing submarine with a fishing rod and a fish farm with fish fenced in in a 2D enclosure felt like the peak of humour to me at the time.

Day 2

I drew some graphics for UI elements and cursors, and started making the map clickable and interactive. For this, I repurposed the drawing code and the hex marker that shows the selected tile. After a broad-phase collision check, the game checks if the mouse is inside the drawn tile by checking a collision mask at the positions of nearby tiles, preferring the tile nearer to the "camera" if two or more overlap. This was easier to code than convex hex shape collisions, and allowed me to stay a bit more flexible with depth and overlapping tiles. At this point I was still thinking about making depth a more prominent mechanic, but the interaction with the map and judging of distances got a bit too difficult when tiles were occluded too much.

Then I added the wavy underwater effect. It took me way too long to add it, and although everybody tells me it's a bit too distracting, without it it's not clear that you are underwater, which is an important thing to convey at all times, because of the theme.

I drew some sprites for resources and tile products, but I was still unsure which should become which.

After playing around with different configurations, I decided to focus on just building, without a way to destroy built structures, and without "turns". There were discrete actions, but no "turns" and no way to pass time. There was also no way to accumulate resources over time. The only action was clicking on a tile and building, with instantaneous effects: Left-click a tile, select what to build, repeat.

This gave the way a much more puzzle-ish feel, that I really liked, but it also meshed with the "ecological" theme: Every action is irreversible, every tile is a precious resource, every decision is meaningful. Using a tile for building can cost you food or oxygen production. Expanding can destroy synergies between tiles.

To make this more obvious, I added a UI that shows a tile's output when you hover your cursor over it.

Day 3

The game was "feature-complete" after the second day, but I felt a bit unhappy with the balancing and the UI. I took a third day and spent Monday evening adding mining tiles to make tile space more precious, and UI improvements like drawing the perimeter of the buildable area (instead of the range of the current habitant) when the cursor is outside of the buildable area.

The farms were too easy to build, and the power plants were too difficult, so I added power lines to distribute energy (at the expense of building over more tiles) and mining of rifts for science juice to build farms. This way, food, energy, and oxygen are more of a trade-off, and you can't just tile the world with farms, but you can upgrade some of your farms to undo your worst mistakes. If there are not enough volcanoes where you want to build, you can build power lines, but that will make habitat placement more difficult.

What Went Right

Scope: I am really happy with the tight focus of the game, but at the same time, this game mechanic has "legs". It would be easy enough to add more tile types, make the map bigger, and to increase the goal population in the future based on what I have now. But as it stands, it's an interesting game already. Adding more systems would have made it harder to balance, and I am glad I didn't add turns with actions per turn, or tiles that generate resources over time.

Art: For the most part, I stuck with the db32 palette, plus some transparent shades of those colours in the domes and bubbles. I don't think the tiles are as funny as I first intended, but they are distinctive and legible enough.

Balance: After playtesting the game for hours, it's really easy for me, but it's a decent challenge the first few times. Some of the difficulty stems from not knowing what tiles are available and the lack of undo, but it's replayable for some time without feeling "solved" even after you have internalised all the mechanics. None of the tiles is too abundant or too rare.

Game Design: The core loop is build habitat->connect food and energy->expand range->build habitat, but it's also possible to go back and increase the population of existing habitats by mining, upgrading farms and connecting more energy. In the endgame, the player can sometimes increase the population by densely packing the centre of the map with habitats after spreading on the map, and sometimes, it's the other way round. That gives this game a thinky, puzzle-ish feel.

Tile products follow the pattern [adjacent tiles->built tile->product->habitat], so that there are no loops. It goes kelp->fishing sub->food->habitat; rift->power plant (->power line optionally?)->energy->habitat; kelp forest->oxygen->habitat; farm->food->habitat. Evaluating the output of a tile is straightforward both for the computer and the player.

Theme: I tried to work in an ecological theme, where Oxygen is in short supply, built structures cannot be reverted into pristine nature, and tiles are an important resource. Players picked up on that.

What Went Wrong

Jam Theme: Unfortunately, the jam theme "deeper and deeper" got a bit lost in the process. The game was already difficult enough without making tile depth contribute to building costs, and complicated enough for a jam game without adding more mechanics. Making the terrain generation more extreme would have made tile adjacency hard to determine. I would have needed to use a 3D engine to make 3D game mechanics.

(extreme terrain generation with deep cliffs makes world difficult to parse)

Tutorial: There is no in-game tutorial that introduces the tiles gradually. I added some text on the itch.io download page and the LDJAM submission, but that can easily be missed. The only way to learn what the tiles do is to place them and then examine what changed, or the tool tip. Only after the compo I implemented a bunch of UI improvements, but they need to be enabled in the game's options. Now the tool tips are also shown in the build menu. I should have thought of that right away.

UI: The UI is too busy and the mechanics are not discoverable enough. Adding more things to the UI would make it busier, removing things would make it harder to see what's going on. The UI needs a complete overhaul if I add anything more.

Time: Looking back, I could have implemented all this and some more polish, animations, and sound effects within the time constraints of the compo, if I hadn't had anything else to do that weekend. I really wish I could have added some audio.

What I learned

• Don't try making depth a mechanic thing in a 2D game if you can't rotate the camera and look behind things
• Some users get annoyed by waves even if they don't get sea-sick
• People call every visual effect a "shader", even if it doesn't use the GPU
• Hexes are cool. Some mechanics just don't work on a square grid
• My visual jokes are not as funny as I think they are
• I can do LDJAM without feeling hungover and tired on Monday
• Try not to accidentally take out the jam theme when cutting down the scope!
• See, my games don't have to be platformers
• Limiting your mechanics to simplify controls to one mouse button can pay off

I am making a city builder set in a world with permanently rising sea levels.

This is probably not very unique, but I am having fun coding the game.

Swim City 2000 is a city building game where you try to build a city while the world is slowly flooded by the water streaming in from the corner of the level. It does not have any city building gameplay yet, but I managed to make this cool flooding simulation. Now all I need is UI and actual gameplay!

But now there is a widescreen post-compo version with improved UI, proper particle occlusion, and some water flow balance changes.

Show underlying terrain on focus...

Select multiple tiles and build many at once. This also works for dams and roads (not pictured). This does not allow building zoning tiles where you previously couldn't, only next to roads.

https://ldjam.com/events/ludum-dare/50/swimcity-2000

What Went Wrong

The design of Signals Intelligence is overly elaborate, and has too many moving parts. Every part needs to work, and the parts that don't work drag down the core game loop. If the player doesn't like or understand one of the systems, the game suffers, and if the player can skip one of the systems, you might as well not bother. The scope wasn't all that ambitious, but it was ambitious for a 48 hour jam game built without an engine for turn-based games or genre-specific base code.

Programming

At least it runs now.

Spaghetti Code, 1970s programming

I wrote the whole program with one big main-loop and no abstractions. It's all enums, flags, (named) tuples, state machines, and one big loop. There were barely any classes or functions in the code. When I do this in a game jam, it's usually for more than one reason:

• I do not know yet which kinds of abstractions or data structures I actually need
• I cannot waste time on bottom-up functionality I might not need
• I do not have the time to refactor during the compo
• Once I have something running, I know what kinds of data structures I need

I never had the breathing room during the first 48 hours to sit back and refactor everything into OOP style, or at least OOP style where it made sense, so my whole code was just tuples, enums, and tables for data, and that really slowed me town. Still, I kept going, because I didn't have time to refactor, until the code reached 2200 lines, and then I really didn't have time to refactor, because it was so much code!

Rolling my own pathfinding

This was more or less an unforced error. I thought I could get away with a simple kind of pathfinding for enemy moves, some sort of greedy heuristics-based system that just tries a couple of moves in the right direction and returns when the solution is good enough. I should have used A* right away.

Unfortunately, I had already simplified the unit movement code to move only in a straight line, to simplify both the mechanics and the enemy AI. Later I had relaxed that to one corner turn by move action. I really liked how this made moves actions into more "chunky" decisions. If you move over a mountain, then your action is limited by the mountain movement range. This means I don't need to run A* on the player's turn. The movement is pretty deterministic, there are only two paths (with one corner) to check.

For the enemy movement, this turned a problem that could have been simplified or sped up into a problem that could be solved with A* or Dijkstra, but not any further! If only I had made the system use floating-point costs under the hood, so that "You movement range is 5 on fields, 8 on roads, and 2 on mountains" would translate into floating-point costs of 0.2, 0,125, and 0.5. That would have been easy! I could cache a lot. But with my system, I couldn't just cache the cost of moving over the mountain, because it really matters where you start. If you start on a road, you can stay on the road! In terms of game design, this is great! In terms of performance and caching, it is horrible. It wouldn't have been a problem if I hadn't written this all in Python. Maybe somebody in the comments can tell me why and how I could do JPS (jump point search) anyway, but it wasn't obvious to me, and I boneheadedly tried to do something weird instead, and that didn't work at all.

I only fixed this in the post-jam bugfix version, with the drawback that the game now freezes during the enemy turn. I can't stress enough how bad of an idea it actually was to do greedy depth-first pathfinding, and how correct it felt at the time, because A* was slow, and I couldn't do JPS!

To illustrate the problem some more, here's an example of a tank that can move two spaces over mountains, and four over open terrain. Although the top path and the bottom path contain the same amount of mountain tiles, the bottom path takes one less action.

If you try to find the optimal path over multiple moves, this leads to quite complex pathfinding situations like this one.

Procedural Generation

This is also an unforced error, but not as bad. I thought I didn't have time to design a map, so I used Perlin Noise to generate the outline of the map, more Perlin Noise to place mountains, and some greedy iterative process (I never learn!) to route two roads through the map. And then I also needed to place the units! The maps are all samey, and there is no reason I couldn't just have drawn a static map and shipped it with the game. There was no upside to this, apart from saving myself the time to write something that loads the level from an ASCII art map, but that would still have been faster than the code that randomly places units. It's not like there isn't already a python module for loading TMX maps!

Broken State Machine

I really lost hours of time on my game because I didn't properly do the state machine the first time. Now using a state machine in the main loop was itself not the error. You can achieve the same goals with OOP, and make one subclass for every state, with judicious use of design patterns like "Template Method" and "Subclass Sandbox", but realistically, a state machine like I ended up with is a better fit. There is a lot of overlap between different states: In every game state, the map needs to be drawn, and in most states, the game needs to read inputs. If you wanted to mirror this with a class hierarchy, you would end up with multiple inheritance, mixins, or questionable is-a relationships. Instead of one big switch statement, there are all kinds of conditionals for different things that happens in different states. The problem here was that a) I didn't use enough states, and b) I switched states in the middle of my game loop, inside the game loop logic. ```py while gameloop: if state==State.ENEMYTURN: ... planmovements() ... state=State.PLAYERSTURN if state==State.UNITMOVING: ... if state==State.PLAYERSTURN: ... if clickedendturnbutton(): state=State.ENEMY_TURN

# THERE IS NO COMMON GAME UPDATE LOGIC HERE
# BECAUSE THE GAME DOES NOT UPDATE EVERY TIME
# IT IS TURN BASED

calculate fog_of_war()
draw_map_and_units()
draw_particle_systems()
if state==State.UNIT_MOVING:
    draw_unit_path()
    ...
if state==State.PLAYERS_TURN:
    draw_UI_buttons()
    ...
update_screen()

``` The correct way to do it is this:

```py while gameloop: state=checkswitchstate()

if state==State.ENEMY_TURN:
     next_move=planned_movements.pop(0)
     ...
     if empty(next_move):
         switch_state(State.PLAYERS_TURN)
if state==State.ENEMY_TURN_PLANNING:
     plan_movements()
     ...
if state==State.UNIT_MOVING:
     ...
if state==State.PLAYERS_TURN:
     ....
     if clicked_end_button():
         switch_state(State.ENEMY_TURN)

# NO COMMON GAME UPDATE LOGIC HERE AGAIN

calculate fog_of_war()
draw_map_and_units()
    if state==State.UNIT_MOVING:
    draw_unit_path()
    ...
if state==State.PLAYERS_TURN:
    draw_UI_buttons()
    ...
update_screen()

```

I had to add a system to transition states between frames, and I added more states to better mirror actual gameplay in the bugfix version. Now the "switching-during-game-logic" thing would never have been possible with the OOP approach. Every state has a draw() method, an update() method, and maybe additional methods for input handling and UI drawing, if you want to make it more fine-grained. But all I really needed to do was to switch in defined places, and not let the player press a button to switch from "enemy turn" to "player's turn". That led to a lot of crashes.

Project/Time Management

Originally, I wanted to participate in the compo. That's how far off I was.

Scope

The game idea sprung out of Zeus's head in full plate armour – some time around 2013. I have to admit, I wanted to do a game like this for a long time: A war-game where you are limited by the fog of war. The idea in my head was considerably more elaborate, and instead of grid-based and turn-based, it was active-time battle, or real-time with pause. I keep a notebook (paper!) with my old game ideas I want to get around to, and this idea was waiting for me.

The design I went with was much more Advance Wars and much less Company of Heroes. Still, it was too big of an idea: Supply lines, pathfinding, turn-based fighting, enemy units who autonomously counter-attack when attacked, spotting for artillery, fuel, ammunition, food, fog of war, all these feel non-negotiable.

Sprites First

I started with the game's artwork. Since I had a pretty good idea of what I wanted the final game to be, I started by drawing all the sprites for the game's map tiles and units. This was kind of a mistake, because it committed me onto a path where I would use all these tiles and sprites, or my work would be wasted.

This didn't just commit me to a fixed scope, it also committed me to a certain design. I hadn't started with grey boxes or programmer art. On the other hand, I also didn't really have time to make the pixel art bad first, and then good, and it didn't take that long to get it right the first time.

No design iteration

Since I was running out of time, and since I had already committed to all these units and mechanics, I had no time to iterate on the basic design. I could have started with the idea of decrypting intercepted messages, and made that an integral part of a different kind of game, maybe some sort of rogue-like where you need to interpret scrolls you find on the floor, or a first-person Myst-style puzzle game. The connection to the theme "Signals" was always set in stone though, so I kept the military theme.

There was also no time for play-testing iteration. I didn't show the working game to anybody before I submitted it. My normal philosophy is to have something that is playable (if not winnable) during the first day.

Non-Core Systems

Even worse for time management, I started with the systems that were core to the theme, not the systems that were part of the core loop, so I started with the map and units, message decrypting, coordinate scrambling, and fog of war. Then I wrote out all the unit stats, and then I actually implemented unit movement. In the middle of day two, I decided not to add a certain feature to the signal decoding (you won't know what is missing because I am not telling you). At the end of day two, I finally had player movement. I added a day, and in the evening of day three, I had the enemy player working, if only barely.

The deeper cause of the problem wasn't the design, but the fact that programming little systems and mechanics is fun, and there is little relationship between how much fun something is to code, and how much fun it is to play, or how vital it is to the game design. You can get lost in endless rabbit-holes with tangential game mechanics, or you get get carried away implementing engine features, just like you can get lost polishing your UI at the expense of game content.

Game Design

The design of Signals Intelligence was too rigid, too elaborate, and had too many moving parts. But more than that, I think I can determine a number of problems that aren't just described by "complexity". These are mistakes other people can learn from!

The Slow Death

The design of Signals Intelligence originally included some kind of "raw material" resources, but I quickly settled for a "money" resource, and then I didn't even do that, because fo time constraints. I thought it would be kind of funny if the GODLESS COMMIES didn't use money, and all their production was based on materials like "oil", "iron", "wood", "copper" and "potatoes", whereas the FREE WORLD uses the almighty dollar.

The version that exists now has some element of inevitability, because there is no way to build or buy new units. The main problem with this is that you can get to a state where you know you are going to lose, because you ran out of units, but the game doesn't know it, yet. I should really have added a "give up" or "try again" button, a menu, or a main menu to return to.

Anti-Pattern: Enemy AI, Level Design, Balance

Certain genres of games live and die not with their design or game mechanics, but with their content. In the case of both single-player strategy campaigns, and single-player stealth games, the content is the "enemy AI" and level design. AI is such an overhyped concept these days, but let me be clear: I don't mean LLMs, and I also don't mean alpha-beta search or GOAP. By AI, I basically mean "scripted behaviour". I think "AI" is a misnomer, but that's what it is called.

In both stealth games and single-player strategy campaigns, you don't want the computer to think through all the options. You want the computer to present a highly predictable challenge, almost a puzzle, so that the player can slowly overcome it. You don't want to play the campaign of StarCraft, Command & Conquer, or Age of Empires against a computer who is actively trying to in. You want to play against a computer who is beatable, again and again, in varied scenarios. In stealth games, you don't want to play against enemy lookouts who go out actively looking for you. You want them to say "It's probably just the wind" until it's too late.

This is really difficult! A good single-player strategy campaign is based on varied levels, with custom scripted behaviour, and that's a lot of work for a game jam. It's even more work to build a game AI that actively tries to win, because that's not only hard to program, it's also a complete nightmare to balance. It's easy to go from "Enemy AI that always glitches out" to "Enemy AI that always wins". Balancing an enemy that always tries to win is hard.

At this point, I usually start to hear the siren song of multiplayer, and I think "This could all be solved by making this a two-player game". Just imagine all the NPC AI/design/scripting/coding work Chris Hecker avoided by making Spy Party multiplayer!

It's not a good idea, of course. Sure, if instead of inventing a new chess AI for your new chess variant, you just let players play against each other, you only have to implement the game mechanics. Sure, if you get players to play against other humans, they will have fun figuring out the game together, even though they wouldn't have fun alone. But it's usually a bad idea during a game jam. Players won't have another jammer to play with at home, and they will be unlikely to rate Ludum Dare entries against their romantic partners, non-gamedev friends, or family. By making a multi-player game for Ludum Dare, I cut my player base down by a factor of 20 to 100, and I run the risk of getting comments that just say "looks interesting. I had nobody to play with so I played against myself".

The best case scenario is to implement online multi-player with matchmaking, so players have somebody else, but in the case of a game jam, that someone else will be rushing through 20 games to rate, and they won't all be online at the same time. That is, even if I could just snap my fingers and implement online multiplayer for Signals Intelligence, it wouldn't actually help the player experience.

If I make the game a two-player affair, I will have to make some concessions, and I would probably have to replace the "Signals Intelligence" gimmick, or at least tone it down. I can't expect the red player to actually have his units wait half a turn before attacking. Also, I would need to implement some sort of two minute turn timer.

Game Design Anti-Pattern: The Gimmick

If your game can be described as "$GENRE but with a twist", there is always a risk: What if your twist is bad? What if your game is better without the twist? What if your game would be better if you just made a generic $GENRE game?

The standard game design advice is probably to ignore the negative feedback and to double down on the twist. If your game is a puzzle platformer with a gimmicky gravity mechanic, you should consider toning down all the platforming, and to focus on the gravity puzzling. If your game is a rouguelike with chess elements, and the players don't like the chess elements, maybe you should re-frame it as a chess game with roguelike elements.

In the attention economy, the gimmick presents both a problem and a solution. Without the gimmick, YouTubers and games journalists wouldn't know what to say about your game, or how to describe it to audiences, and they might not even play or review your game, because "just another decent entry in the genre" doesn't cut it.

If you just look at it from a game design perspective, and not from a marketing perspective, the best advice is often "kill your darlings". If the chess elements make the roguelike that much worse, and you are trying desperately to shoehorn them in, maybe cut them. Maybe cut the whole gimmick and just make a good game!

Signals Intelligence could probably be a more fun game if it didn't have the signal gimmick, the decyphering, but then it would not have an identity. It would just be a turn-based tactics game that lacks complexity.

Anti-Pattern: Hidden Complex Systems

I have made this mistake before, and I have identified it. I even wrote a post about it. If your game has complex systems, you have to expose them to the player. If there is an enemy AI that makes interesting plans, it has to inform the player. If there is a trading system and all the enemy factions trade with each other, the player must know this. If your world is populated with little critters who eat and sleep and reproduce, then you better show little thought bubbles with food or hearts or ZzzzZZZzzz to explain why the critters are doing what they are doing. Otherwise, you might as well not bother. If the system is hidden from the player's view, the actions might as well be random. In Signals Intelligence, I have implemented fuel and ammunition as a game mechanic, so you can cut off enemy units from supply. You can starve enemy artillery, if you are good at decyphering, you can confidently attack enemy tanks and artillery with infantry, because they are out of fuel.

Most of the time though, the focus on Fog of War and signals means that the player won't interact with these systems directly, and all the resupplying and resource management is invisible to the player. It might as well not be there. As the developer though, you often struggle to see it. To you, this is all obvious and transparent. You know what moves the enemy is making under the fog of war, or just outside the edge of the screen, because you wrote it. You don't interact with it as "the enemy makes a random move at a random moment", because to you, it's all there.

Anti-Pattern: Vertical Slices/Minigames

I have already learned that making a game out of half a dozen minigames is a bad idea during a Ludum Dare. It's tempting, but usually you can't make something like WarioWare or Mario Party or GameSoup or even McPixel during a game jam. It's just too much work, and you waste time on the weakest link, or on games you cut from the collection. Adding more content to the signal part of Signals Intelligence would have meant adding more screens, more minigames.

It might be fun to imagine an interrogation mini-game or a mini-game where you develop microfilm, or a minigame about numbers stations, or one where you analyse enemy newspapers. But once you solve these, they would all be dead weight, in the same way the coordinate de-scrambling is dead is boring once you figure it out, and the way the whole signals intelligence stuff is redundant when you have enough vision of the map.

What Went Right

Symbol Drawing

Isn't this fun? You decode the enemy symbols by drawing, MSPAINT style. This has to be worth something! It neatly sidesteps the question whether the game will tell you if "Artillery" is the correct answer. It obviously won't.

Mechanical Theme

I had considered something about Morse Code, smoke signals, or a dating sim where you have to spend as much time as possible speed dating without ever getting the people you're dating enough information to make a decision. Mixed signals, get it? Yeah, I'm glad I went with SIGINT as my theme, too. I thought it was kind of obvious, but I have seen multiple games about routing traces/signal wires on circuit boards, and not that many about intercepting messages. I really like the theme, and I like that my interpretation is mechanical, deeply integrated into the game and not just something I mention in the intro, not a stretch, but still straightforward.

Cold War Setting

At least nobody told me yet that it's offensive, so there's that.

Mouse-Only Controls

At some point I considered to add some things that require keyboard presses, but I decided to just use the mouse, and that made it possible to play the web version on an iPad. I hadn't even thought about it at the time!

PyGame-CE

I couldn't have made this game with an actual engine. I'm sure I could have made it with raylib or libGDX, and I'm sure there are turn-based game construction kits for Unity and Godot, just like there are RPG kits, and point-and-click adventure kits. PyGame-CE has all the stuff I needed, and some features that I used that the old pygame didn't have. I literally couldn't have made this like this game five years ago, because old pygame didn't have some features I rely on.

Pygbag and WASM

In the past, I have used certain game engines and libraries just because I wanted to let people play my game in the browser. I like making games by writing Python code. All I need is GNU Emacs and aseprite and I'm good. That doesn't mean I don't like Godot or Flixel or Unity, but a full-fat engine is not what I would choose in a game jam. Pygbag/pygame-wasm let me run my PyGame-CE code through WASM, and it just works. So next time, I won't have to choose between my old comfy shoes and having a version playable in the browser. I still might, if I want to make a 3D game.

Lessons Learned

I learned very little. To be honest, I already knew most of the lessons, and yet I persisted, against my better judgement. I ignored my own rules. I had a ton of fun, though.

This isn't the first time I'm saying this. I might even have said it on the old site.

There's a problem with the rating categories that Ludum Dare has. To a certain extent, all rating systems have this problem, but Ludum Dare is especially susceptible. If you look at "Fun", it's at least self-explanatory and obviously subjective. I might even call it intersubjectively subjective. My idea of fun is different from your idea of fun, but we all have an intuitive idea of fun. I use my fun, you use your fun, and then we vote. There's no objective measure of how much fun I had, and so I'll just wing it. Nobody would ever play a game and say: "I had no fun at all, it was actually tedious, not merely boring, but a painful slog with no high points. Objectively speaking though, this game is high in fun, and I think I should rate it five out of five stars on the Fun scale."

With all due respect to Raph Koster, nobody thinks about fun that way, at least in Ludum Dare. Nobody applies A Theory of Fun for Game Design to game jam ratings. and I think, again, with all due respect and without trying to be presumptuous, that Raph Koster would agree. I mean, I don't know him personally, but his book communicates his idea really well, I think, and that should count for something.

"Overall" is at the other end of the spectrum: It's not universal, but I think that when jammers rate a game in "Overall", they often disagree with one another about the rubric, but they try to apply an objective rubric. It could be either about balancing the parts of the whole, the graphics, audio, narrative, and so on, or it could be about all the effort put into the game, and all the game design that is apparent from playing, even if the game design didn't turn into fun, or it could be about an appreciation of the game even if you personally didn't like it and didn't have fun, because you personally hate management sims or horror games or visual novels and just can't get into them. It just feels to me, from my experience with Ludum Dare and from talking to other developers, that everybody is trying to be the most objective.

Then there's "Audio", "Graphics", and "Humour". There is no clear rubric for grading, and some games have no audio, some games have no jokes, and some games even have no "graphics" in the narrow sense. Some people give low grades for simple, not very elaborate graphics, and some people give five stars if the simple graphics are what's called for. I am not griping about by own pixel art not getting high ratings here. I made simple pixel art on a white background to evoke a feeling of grid squares on a paper map. You're not looking at the battlefield. You're looking at a map in an office. If I had had a much, much bigger budget in terms of time/money/staffing than a solo jam allows, I could have beaten the player over the head with a view of the map in an office, with real people who look very different from the pixel art style, analysts and suits and ties. But I'm happy with my 3 stars. I put about 3 stars of work into my graphics, and I can see how others have made graphics deserving of 4 or 5 stars. But when I look at my game, I don't want to make the graphics better, you know? I think they are about as good as they need to be. I should really have been working on all the other stuff. I get it.

But his is not about me. Some people rate games with more elaborate graphics higher, and some people rate games five out of five when the graphics "fit". The same goes for music. Different people apply a different rubric to "Audio". Different people also apply a different rubric to "Humour". Does a game get more stars for having more jokes? Does a horror game with some subtle background jokes/references get two stars? Is dry wit worth fewer stars than slapstick? Humour is highly subjective, but it's not really clear how you should rate a game on humour. I know that "Mood" and "Humour" are ways for games to be recognised for being engaging when they are well-made but aren't, strictly speaking, "Fun", but this creates problems. I always think I should just opt out of these categories, but I never do.

All of the above was just to give you some perspective. "Fun" is subjective, but there's a agreement about what it means and how you should rate it. "Overall" is tough to grasp, but the variance is probably on par with "Fun". The others all have their own corner cases.

And then there's "Theme": Some people rate games highly for sticking close to the theme, and some people rate games highly for getting as far away from the theme as possible. If you're doing something "clever" with the theme, by interpreting the letters of the theme as a license plate or the designation of a robot, or by interpreting "Beneath the Surface" as "Ben Eath, The Surf Ace", you will win some favour with some people for being clever, creative, and unique, even though there were at least three games that used the exact name "Ben Eath, The Surf Ace" modulo punctuation and capitalisation (lord, afal, goerp), at least two more that had a variation on that title, and at least five just contained "Surf Ace". I picked that one in particular because it is a clever way to interpret it, it just turned out not to be very unique.

The "Theme" category, perhaps inevitably, sometimes rewards people for doing the most obvious thing, for sticking to the theme, at least if their take on the theme feels "comprehensive". It also rewards people for getting as far away from the theme as possible. I would expect some games to have a "Theme" ratings distribution with peaks at 5 and 2, because the game uses the theme as a loose inspiration for doing something unique.

Personally, I don't really like to participate when the theme is too similar to a theme I have already done, like Depths/Beneath the Surface, Collector/The More You Have, Tiny Creatures/Tiny World, Limited Space/Running Out Of Space or Delay the Inevitable/Advancing Wall of Doom. But when I do, and I see a game that fits a dissimilar theme better then the current theme, for example when I see a game that fits the theme "Unstable" or "Depths" better than "Signal" for this Ludum Dare 59, then I deduct points.

Every time I do that, I see somebody else in the comments praising the game for doing something totally unexpected with the theme. They applaud the game and the dev for doing something nobody else thought of.

Maybe I'm overthinking this. Maybe the rating categories aren't supposed to produce any kind of consensus. Maybe it's a good thing that the theme category has some people interpreting it the opposite way from the way I interpret it in some cases. Maybe the theme category is supposed to be polarising. Maybe this is all just in the comments, the part I see, and the ratings have less disagreement and less variance. Or maybe I'm the odd one out.

This time I have rated 6 games at or below 2 stars in "Theme", and one of the games I rated had opted out of the category completely. In every case when I rated a game really low, it wasn't because the game was a straightforward and boring take on the theme, like something about signal processing, but because it was a generic game that might not really have had a connection to the theme at all.