Puzzle terminology is unclear. One of my favorite game genres is what I used to call “puzzles” until I heard some games of chance referred to as puzzles. So these days I say “logic puzzles”. I can’t give you an exact definition but if you find yourself frequently thinking “but if I put that here, then this has to go there, but then that can’t go there, but… oh, er, hmmm…” while playing a game then there is a good chance that it is a logic puzzle. A few other characteristic features are:

• no hidden information – everything you need to solve the level is there on the screen in front of you
• always solvable and with completely deterministic gameplay (no chance element)
• no or very low requirement to think quickly or perform tricky actions
• solving them should require some level of ingenuity – so a standard maze doesn’t count, nor a puzzle where most of the difficulty is working out the mechanics
• physics puzzles and puzzle platformers generally don’t count, but it depends on the “but if I put that here…” factor

Logic puzzles can have a cult following but they aren’t so common so I thought I would share a list of such games that I have found this Ludum Dare so other like-minded players can find them easily. I’m listing these games in no particular order, although I’m excluding obviously incomplete games.

I’m super sure that the list is not exhaustive so please let me know of any others you find! (Suggestions for better terminology are also welcome!)

Logic puzzles (according to my meaning of the phrase):
BaseCase – Delicious Ships!
khahem – Detached
Draknek – Slime Saga
thegdr – Splat
madlee – Unfinished Piece
panda – You! Are the monster
lessmilk – Gravity Snake
sprawl – Entropy
VelvelaJade – Zevy’s Puzzlers
Fanaen – Mindvasion
reheated – Milky Helps People (that’s mine)

The following games combine logic puzzles with a component of observing enemy movement. They really are logic puzzles but not all the information is on-screen at once.
ehtd – Eat Sheep
person124 – A Monster Is You!
Jacic – Team S.T.E.A.L.T.H
lubos – Dungeons Deep

Other games with a major logic puzzle element:
daveh – Lure.Lair.Lunch
bowlercaptain – The Terror of the Night of Day
TMW – Quarantine Zone # 1
avultima – Collateral Choice
Open Rift – Shadow Wolf
966623 – RGBlob
MSiddeek – Monster and Hero

Milky Helps people is a logic puzzle game. (Timelapse here.)

You have to place devices in the grid, according to some rules:

• You need to place exactly one device in every group of tiles
• When two devices line up, they automatically connect to each other. Each device must be connected to exactly one other device in the same row, and exactly one other device in the same column.

The solution to the above puzzle is as follows:

But the puzzles quickly get more complex.

In later levels, the game adds barriers that prevent connections from going through, making the puzzles more complex.

The puzzles are motivated by a story told in the form of a picture book with audio narration. The story is that Milky always likes being helpful, but sometimes he finds that he could be more helpful if he was just a little bit bigger. So he has to operate the professor’s devices to collect some mangosteen juice, a powerful substance that will make him bigger. But every time he gets big enough to solve one problem, a new problem arises that requires him to be even bigger.

What went well: puzzle rules

I usually make a puzzle game. My Ludum Dare 32 entry, Wellbeing (game, postmortem), had rules that enabled me to design some satisfying puzzles (I think the most satisfying puzzles are “smooth” – you can chip away at them piece by piece). I was pleased with Wellbeing’s puzzles… except the rules were kind of complex and confusing. Some players were put off in the first three levels while the rules were being explained. So, for LD33 I worked hard to come up with puzzle rules with a balance between simple enough to be easily understood and complex enough to allow me to design satisfying puzzles. Even when I had rules I thought were completely clear, when I showed it to my friend Brian Corr (who has entered LD in the past but didn’t have the time this time) he pointed out and helped to clear up some ambiguities. I haven’t had complaints about confusing rules this time so the plan seems to have succeeded!

Wellbeing had a storyline that branches depending on how you solve one of the puzzles. That went down well with players, so I decided to take it a step further: this game has two endings; once you’ve decided which ending you want, the solution of the final puzzle is determined uniquely. Well, I’m pleased with myself, even if you don’t like it.

What went badly: stylistic incongruity

Some players enjoyed both the story and the gameplay but felt that they seemed unrelated. I think that a big factor in this is the visual style. The puzzles are displayed in a clean, abstract way, and the story is told with some sketchy picture book drawings. If the puzzles were displayed in the same sketchy style, with a few mangosteen fruits here and there, players would have swallowed the connection more easily. But making sketchily-drawn tiles line up properly would have taken a lot of work, so there’s a trade-off to be made here.

Notes on how long tasks took

Going over my timelapse, I made some notes on how long certain tasks took. Naturally YMMV but perhaps these numbers give an idea of how much content it’s possible to create in a given time frame.

• Recording and editing the 5 minutes of narrative took about 1h20m, while drawing the corresponding art took nearly 5h. (Not counting the in-puzzle art)
• The 5 minutes of music took about 2h to make, all up.
• I didn’t write a line of code for the first 4h30m…. I was thinking up puzzle rules and puzzles, and planning everything out on paper. Is that weird?
• I planned the game out giving myself 10h of contingency time, i.e. planned to be done by 1am Melbourne time, and actually finished at 7am. So… good decision.

Here is I Have Brig Plans. It’s my 10th entry! What do I get?

I mostly make logic puzzles, and this is one of them. You have to design cells for prisoners. Each prisoner has a number on it telling you how many tiles they need for their cell. Each person’s cell needs to be a connected group. In addition, there are three types of prisoners, all having special rules inspired by two Nikoli puzzle types, Shikaku and Nurikabe:

• Humans require rectangular cells
• Cockroaches require cells with no 2×2 blocks
• Energy beasts’ cells must not touch each other.

As such the game plays out a little bit like Shikaku or Nurikabe, but also has its own unique flavour coming from the interactions between the rules. Later in the game, a shapeshifter is introduced whose type you have to figure out yourself.

My wife and baby daughter were overseas visiting relatives at the time, so I had the house to myself. That means less distractions, at least in principle. By the end of the weekend it was a pretty lonely experience, though. (I Skyped with them a couple of times which helped.) I had too much coffee on both days, which led to a more stressful weekend than necessary.

Since the rules were relaxed a year or two ago, every time I start a game, I grab my previous entry and empty out the stuff that’s not reusable. It’s worked well for me. The code I reuse is mostly file loading and audio stuff. (And a few miscellaneous things, like a function for finding “islands” in a grid of data; it’s served me well for 4 games in a row, with minor tweaks here and there to handle different data formats.) This time I added a simple “packager” consisting of a bit of python to dump all the resources in a single file, and a bit of client-end javascript to pull all the resources out. It saves having to request each sound/image file individually.

What went well

Puzzles: A big advantage of making a logic puzzle game (compared to, say, an action game) is that you can get an idea of whether it’s fun without coding it up. Just make some puzzles on paper, then forget the solutions (cinch) and try to solve them. I spent the first 5 hours making the puzzles before even starting to code! I think they are fun and satisfying if slightly on the easy side. (Though the final level of the final act is a decent difficulty.)

Music and SFX: Maybe it should have been obvious, but I only realised some time between the last two LDs, that even if a game has music and speech, it really ought to have sound effects too. It adds a lot to the game to have sounds that play in response to inputs; I think it makes the player feel more strongly that they are affecting something.

I decided to tune the sound effects to notes. To avoid too dissonant a sound, I placed some restrictions on the chords in the music. Maybe the music isn’t very challenging, but I think it sounds relaxing and goes with the rest of the game.

What went OK

The look: Well, I’m not much of an artist but I’ve started to learn how to draw… the player’s attention away from that. I drew the icons in Krita and used an edge detection filter to get a carved look. The rest of it was about fiddling with colours and border widths and things in the javascript.

What went badly

Story: Originally I wrote a funny story, but then I read it and realised it wasn’t funny at all. Also a funny story wouldn’t really go with the rest of the presentation. So I took out all the crummy attempts at jokes, and went for quirky instead of funny. It adds a bit of flavour to the puzzles, maybe. But I don’t think the story ended up very exciting or memorable.

Spending too much time on details: I spent a lot of time on tiny details like having a sound switch, and fiddling with the controls to make them as convenient as possible. Normally I advocate putting a high priority on polishing, on focusing on those minor details. But this time I might have overdone it, using up time that could have been better spent giving my game a bit more character, or making more levels.

My entry is The 16th Bit. You’ve been mysteriously invited to a LAN party, and upon arrival you find out that the host has gone missing! There is a computer in the room that serves up two types of puzzles. Firstly you get cryptic clues, which you solve by picking the right computer game from around the room.

The second is a tile-based puzzle where you have to fill all the tiles with blood or water according to some constraints.

I am a fan of cryptic crosswords and enjoyed The 11th Hour as a kid. The theme “One Room” seemed perfect for making something along those lines so I took a shot.

The game is fully voiced (I got my wife to voice the character who gives you hints – I did the others). One interesting problem I had to solve was how to have clickable objects placed around the room, without hard-coding the clickable regions. Probably some game engines provide a feature to do this but I had to implement it myself. Turned out not too hard: I used Krita to draw the graphics then opened the images in GIMP to create image maps for them. Then I wrote code to open up the image map files and extract all the polygons from them.

My big mistake: not playing to my strengths.

Originally my plan was only to make a cryptic clue-based game. It quickly became apparent that I wouldn’t be able to write a lot of satisfactory clues quickly enough. Furthermore, my plan to draw cheesy versions of the game art for each game would restrict how many games I could include (both as solutions to the puzzles and as red herrings). With not too many games to pick from, the gameplay was not going to last very long. I realised I had to supplement this gameplay with something a bit longer lasting. So the game alternates between cryptic clues and a new kind of tile-based puzzle. Fortunately I came up with some interesting rules and six nice puzzles using the rules.

The result, though, was that I basically had to make two games in one. The tile-based puzzle has simple rules and was easy to code up. But making a room that you can navigate and pick games out of, and drawing the room and the games, took a lot of work. Even though the art is very simple, it is not my strength, so it took a long time to make each graphic. It also took a lot of (thankfully not difficult) code to handle navigating the room and reacting to the player’s actions. So I was really pressed for time. I only slept about 3 hours out of the entire 48, and only had a couple of decent breaks. There was little time for polish and gameplay balancing, and I think the blood and water puzzles get too hard too quickly. If there was more time to polish and perhaps test the gameplay on people, I would have thought to make the puzzles a little easier and add more visual feedback/hints. Due to my tiredness I frequently had to deal with audio-related bugs. (And I forgot some other details, like an indicator of how far through the game you are.)

All of this spells out a lesson that I thought I had already learned. Between LD events, focus on weaknesses (for me: art, writing). During LD events focus on strengths (for me: puzzle design, programming). I’m happy that I stretched my limits a bit, but it’s better if most of the stretching is done before the event so that I’m comfortable and fluent with whatever skills I’m using during the 48 hours.

A second lesson is maybe not to try to make two games in one. The blood and water puzzle turned out interesting and if I’d spent the whole time focused on that (and got more sleep) I could have made a much more polished and balanced experience.

Well, that’s all I can think of to say right now! I think there are some things to enjoy about this game even if it is a bit under-polished. If you try the game out then I’d really appreciate your feedback because I’m always trying to improve and I’m sure there are things I’m just not aware of (or things I am aware of but don’t know how much they matter to the player).

My entry, Cold Dream, is a survival solitaire game. You've been exiled to Makemake and left to look after yourself. You have four vital resources: food, water, oxygen and heat, and you have to make sure you won't run out of any at the end of each turn. To make matters worse, every turn a random crisis occurs, that will reduce your resources at the end of the turn.

You have a bunch of other resources to work with, and 8 cards, dealt from a deck, that provide you with options for staying alive. Some cards let you build equipment that you can keep, giving you more options in future turns.

What went well

• Doing Ludum Dare for the first time in years. I used to take part in LD regularly, but eventually my lack of energy got the better of me, and the last time I competed was in LD37 (Dec 2016). I've really missed it though. So as soon as the situation afforded it, I took the chance to take part again. And I'm really happy I did.
• Pushing my personal envelope. Of my 12 previous Ludum Dare entries, 11 were puzzle games and 1 was an action game. At one point a couple of my puzzle games got good ratings and I sort of developed a fear of straying from the formula. It's been a slow realisation that the ratings aren't as important as just bloody doing the competition, and stretching myself. So I'm glad that I made a card game, something really different from what I normally do.

What didn't go as badly as I feared

• Doing things in the wrong order. I normally try to make sure I have a fun, balanced game before I get on to matters that I consider "polish" (things like menus, getting the graphics looking good, etc.) But for this card game, there was a lot of work to do on the interface before I could playtest it at all. And interface work takes a lot of effort for stuff that people barely notice (but would notice if it was missing) - e.g., dealing the cards out one at a time, tweening the card position when you click to look closer at it, etc. As a result, the game only really came together in the last 6 hours or so of the competition. So there was a worry that the gameplay just "wouldn't work". But I'm glad to say that on the whole it doesn't work too badly. It is not as perfectly balanced as I would like, but the gameplay works and my goal was accomplished.

What went badly

• Being rusty. Having not taken part for a couple of years, I was much slower at doing some things (mainly DOM manipulation code) than I used to be. Making a small practice game some time in the weeks beforehand probably would have helped with this.
• SVG. I normally use canvas graphics but decided to use SVG this time. The whole web page consists of one big SVG element, and all the code jams stuff into it. This is good for stuff like buttons. But it leads to lots of browser compatibility problems. In particular, the game doesn't look right at all on the Edge browser. Also, I tried to use an asset that was an svg file with an embedded png. This worked fine in Firefox, but Chrome didn't allow it. So I had to scratch that. So what would I do in future? Probably canvas. A mixture of canvas and SVG could work too, if I was sure that the SVG stuff I use is safe to use in most browsers.
• Lack of sleep. Every time I do this, I tell myself to set the scope small, and get lots of sleep. Every time, it doesn't work out. I will let you know when I figure out the solution to this.

My entry is called Juicefruit Orchard. You run a farm, making juice to sell to game developers. To get the juice you have to play an arcade minigame where you bounce around collecting fruit. As you upgrade the farm, the juice gets better, and the minigame gets juicier to reflect that.

I challenged myself to make a really juicy game, which I don't normally do. That's what led to the idea.

What went well (for me): - Solidarity. I took part at a friend's place. There were three of us trying to make compo games but the others didn't manage to finish. For me, doing the compo with others was motivating; everything felt less dire than usual. We'd interrupt each other with feedback. This helped me: if I'm working alone, I have to contact others to ask for feedback, and I always take too long to get to that point.

What went badly: - The usual: setting too large a scope and not getting enough sleep. In the rush at the end, I failed to think of some obvious little features that would have really improved the game. Like, a few commenters have suggested having a shortcut to quickly sell a stack of juice. And looking back, it's pretty obvious that the game should have had that.

I've made most of my past entries in HTML with Javascript. Typically I start each entry by extracting the reusable parts from one of my earlier entries. Now, I've decided to switch to TypeScript, and while I'm at it, make a proper starting point for future games. So! Here is my framework, made by refactoring my last entry, Juicefruit Orchard.

I'm sharing this so that everyone can access the code base I'm starting with. But at this early stage, the value proposition for you to use this as your own code base is not very strong. The included library is pretty bare-bones, and I feel that I should put what is there through its paces in one or two jams before I can confidently recommend it to others to use. For now, the best way you can use it is probably to look through and see if there are any pieces you want to extract for your own code base or snippet library.

Here is my compo entry, Autoexec. The basic idea is a shmup game with a level-up system, but where you have to decide all the upgrades you'll get before starting.

The idea was inspired by Dungeons of Dredmor, a roguelike in which you choose several classes from a long list before you start. There are still some decisions to make when you level up, but most of your decisions happen at character creation. Dredmor also has a "no time to grind" mode, which makes the dungeon smaller and the level-ups happen thick and fast. So it ends up being a game of coming up with a plan, designing a character around that plan, testing it out in the dungeon, and refining it based on what did or did not work. I loved the idea of a game that distills that idea down as much as possible, by having all the skill choices made before the game, and then a very short gameplay sequence where you test out your choices. In this LD, a shmup seemed compatible with the theme, and I realised I could have a go at this idea, in the context of a shmup instead of a roguelike.

Challenges faced

Making a scrolling shmup. This turned out to be not too hard. Most of the coding was straightforward. The one thing that turned out a little interesting is the puzzle of how to make guns that fire faster than the game's frame rate. My solution was basically that the weapons have to work out, every frame, how many bullets they should have fired since the last frame, and then work backwards to figure out where to put them. It worked out fine, although, due to the rush, I ended up re-implementing some parts separately for each weapon. For this and other rush-induced reasons, the code is pretty high in technical debt.

Making a game with so much content. To make a satisfying shmup, the game would need multiple enemies, and to make the level-up system work, it would need a lot of skill options. So this idea ended up needing a lot of content. There are 5 basic enemies, 1 boss, 5 waves, parallax background layers, 16 skills, a skill selection menu, icons for all the skills, sound effects and music. So there was not just a lot of coding to do but also a lot of graphics and sound content. I did worse than usual in terms of sleep. I saved a little time by letting some skills share sound effects. In my initial brainstorm, I had a list of 14 skills, but I ended up adding, removing and redesigning skills based on whatever would be fastest to code up. Somehow I ended up with 16. I didn't get to give the music as much care as I would like, although it turned out OK.

Playtesting/balancing. I ended up not spending nearly enough time on playtesting and balancing. If I had, I would have made the earlier waves harder and probably shorter too, and tuned the XP cost per level-up. As it is, the early part of the game is a bit slow/boring, and it's too easy to get the first couple of level-ups. It gets better later in the game. (The boss ends up being the best part. If I make another shmup it might be all-bosses, a la Warning Forever.) I would also have made enemy bullets bigger. These are all the kinds of details that are important, but hard to get right when everything is such a rush.

All in all, I think it worked out alright. I'm satisfied that the basic idea is a good one, and I think the game turned out reasonably fun, despite some balance issues.

My game is called Rail and in it you are a light blue square that has to help a red ball get to the purple exit. There are switches on the path and you switch them by driving over them. Meanwhile there are enemies that you have to avoid or destroy. I guess I should post something about my game, so here's a gif of me playing it very badly.

In this example I set up some switches right, but then the enemies chased me over them, causing them to switch back, costing me time and lives.

I won't do a postmortem because there isn't much to say. Except that for once I managed to set a reasonable scope - i.e., a game idea that didn't necessitate making large amounts of content right up until the end. In principle, this means I had a slightly more relaxed time and got a bit more time to polish. I have to admit that I still exhausted myself. At one point on the second day I wrote code to rotate a polygon. Because in my stupor I forgot that the HTML canvas already has the feature of drawing things rotated.