We submitted our game on time Monday night, and all seemed well. Until a couple of days later a commenter asked why she couldn't vote on Graphics, and we realised the horrible truth: in the rush to submit, I had mangled the categories, and accidentally removed Graphics, so my teammate wasn't going to get a score for their hard work making original sprites and backgrounds for the game.

There's no way to edit that part of a submission, so I had to send an email to the administrator (https://ldjam.com/contact). After a bit of back and forth we got it fixed, for which I am eternally grateful (Mike is a hero), but the real lesson is: prewrite your submission and double-check it after agreeing which categories you're entering for!

Unfortunately the late addition of the Graphics category means it's a lot of votes behind the others and still needs a few more to get a score, so if you have a moment feel free to drop by and take a look at our game: https://ldjam.com/events/ludum-dare/47/express-without-remorse

(feel free to skip Sound, however)

My team just published our game 'Witch Reactor' at https://ldjam.com/events/ludum-dare/49/witch-reactor. Take a look if you feel like risky magical experiments with more than one way to end badly.

This is our third Ludum Dare entry, making 3/3 successful attempts, and our first using the Godot game engine rather than Phaser. It was a a lot of fun and extremely powerful once we learned our way around it, not to mention git-collaboration-tolerant and a great programming learning tool, so I strongly recommend you give it a try if you're looking for a new engine.

nothing to see here! did you know the LDjam site has no way to delete posts lol

We've made three Ludum Dare entries in Godot as of this jam, and this third is by far our largest, because we dramatically changed how we built the game. Our first two were both built in an inexperienced, ad-hoc way focused on getting things working as quickly as possible (for godot users: abuse of autoloads, not enough signals). We didn't know our tool very well, and it doesn't matter for a small jam game, right? But both times it ended up biting us by the end of the jam.

For this third one we finally bit the bullet and built our game properly. We used a sensibly-organised heirarchy of scenes and network of signals to handle all game logic from the start, and converted existing components like placeholder enemies to a generic form when time came to extend them into additional types. The result was we were able to have one developer work 'vertically' and build game systems from top to bottom, and another developer work 'horizontally' and expand each system into full-fledged variety, because everything was properly separated and nothing was so confused or finicky only the person who wrote it could work with it. And the result of that is we were able to produce far more game than we'd managed in any previous jam.

It's definitely worth taking the time before the jam, even a short one, to sit down and think: what's a sensible way to organise things given the tools I'm going to use?

Check it out if you want a fast pseudo-roguelike shooter with nearly a dozen enemy types: https://ldjam.com/events/ludum-dare/51/witch-contractor

This is our 6th Ludum Dare as a pair of amateurs, and regardless of our game's final rating it feels like a success. I wanted to blog something about it, and a friend wanted to know something about our process and what we might have done differently, so I’m going to frame this around our essential principle: keep the game scope as small as possible until you’ve finished that scope.

We always prepare a list of possible ideas once the final theme vote starts, so that we have at least one viable concept for each possibility. So when ‘delivery’ was revealed we straightaway could pick up one we had on the list: a simple Kiki’s Delivery Service riff (like about a dozen other teams) in a more scuzzy modern setting with a gig economy theme for a fun tonal clash.

We decided we wanted to push graphics and audio this jam, and my collaborator @ruruie has a good blog post about the process of that on the graphics side. But leaving time for them to do art and for me to work on both music and game code meant we had to keep everything as simple as we could.

The first pass of the music was a simple ditty based on just cribbing a couple of chords from the mixolydian mode video by the excellent 8-bit music theory. The first pass of the gameplay was a simple random-A to random-B set of travel objectives on a basic random map. And those first passes were very close to the final passes because we carefully avoided adding anything non-essential until we had a shippable game with a reasonable degree of completeness and polish at the end of day two. No smartphone menu to interact with, no special mechanics for gravity. About the only concession to inessential charisma was the early implementation of walking rather than having the witch fly all the time.

This meant that by the start of the third day we had all our main gameplay, graphical and audio components done and ready and could dedicate ourselves to improving the product, which is a much better place to be psychologically than scrambling to complete core gameplay elements like can happen with an overscoped game. The last day was fun and featured things like implementing dogs with three hours to go and fun but technically tricky features like rooftop landings, besides expanding the music, greatly deepening the graphics and hunting down minor but relevant bugs.

But while it was fun, in retrospect there are probably better ways we could have spent our time. We left early placeholder assets (the delivery targets and the arrows) in place rather than replacing them. More crucially, we neglected to add an escalating difficulty component to the gameplay, so the player is more or less left to fly around doing deliveries until bored. This synergises poorly with the random maps we were so proud of and put effort into - there’s no factor booting players out and inspiring them to try again to see a different layout of the colourful city and maybe some features that were RNGed out on their first run.

The pitfall of focusing narrowly until the game is ‘shippable’ and then splurging on fun extras is that you can lose track of which improvements you most need to focus on once the baseline game is ready. This is something we’ll be sure to fix in the next jam.

We're all waiting on tenterhooks for the results or our last few ratings now, so I'm going to ruin the vibe and mention a few things I saw that annoyed me.

• Browser-embedded games too large to play in my browser window. I prefer not to have to fullscreen or maximise my window for jam games unless they really demand it. Sometimes even maximising the window isn't enough. Does your WebGL game with simple models/sprites really need to be 1080p?
• Controls based entirely on WASD + E/Q/etc. WASD controls are a standard on keyboards because the other hand is assumed to be using the mouse. Without that, you've crammed everything awkwardly onto one hand for no reason, and it's most people's off-hand to boot. And if your game only has directionals, you can allow both WASD and arrow keys.
• Blatant ChatGPT blurbs. Mate you spent all weekend working on this, give me a couple sentences of what you were thinking. Don't make me eat a bowl of someone else's dry oats.

by playing their (not my) game: https://ldjam.com/events/ludum-dare/53/spaceex-interstellar You gotta emulate it specifically if you don't have a Playdate but imo we should reward people with the nerve to make weird LDs. They only need a few votes to get 20!

I was vaguely aware of the concept of a state machine before this jam but hadn't really seen the significance. A thing moves between different states? So what? But my collaborator @ruruie had their eye on it and pointed out that the mechanic in our game (https://ldjam.com/events/ludum-dare/55/witch-courtier) where the cursor is variously a wand, a paintbrush, painted different colours, etc., would be a perfect use case. This turned out to be a fantastic idea.

I followed the tutorial here: https://gdscript.com/solutions/godot-state-machine/ and pulled the logic managing entry, exit and behaviour for each cursor type into self-contained classes that the 'cursor' class could swap out as needed. What would previously have produced a byzantine, bloated and bug-prone mess of tracking variables and conditional branches split into a handful of easily manageable files. Whole new behaviours could be plugged easily into place. My only regret is I didn't use more of them and that I wasn't architecturally stricter once the pattern was laid down (I say that part after every jam).

If your code is full of conditionals, state variables and bloated classes, ask your doctor if state machines are right for you.

you're lucky if people even read play instructions, don't put five paragraphs of generic backstory vaguely related to the jam theme between them and the itch.io link

Way back in LD47, as we were making Express Without Remorse, our first game, @ruruie made a request: could we have a beam?

We could not. We had no idea what we were doing, we barely (but successfully) made a game at all. Multiple shot types were right out.

Two years ago as we were making Witch Contractor, our fifth game, @ruruie made a request: could we have a beam?

We could not. We had to build out complex map logic and multiple enemy types to create some depths for the players to plumb and that took all of our dev capacity. We had different bullet types but they all behaved the same. We couldn’t introduce a whole new way for enemies, or the player, to interact with one another.

Is it really a shmup, if you don’t have a beam? We had to say ‘yes’. We had to compromise. You don’t need a beam, we lied to ourselves.

It’s LD56. We are making a game. It’s a shooter. Ruruie doesn’t even have to request the beam. We both know about the beam. It hangs over us. It is the shadow, the creeping death, the cold laughter in the back of the mind. We build out bullets. Change how bullets work. Develop enemy types. But something is missing, something is always missing. We need to cut features. There’s no bombs, no background variation, no procedural infinity. We need to get an MVP out. We can’t have another disaster like LD54. But we can’t cut everything. We have to push to make the jam worth it, to develop our powers and beyond what we've made before.

Bare hours before deadline. We’re in panic feature-completion mode. It’s a shmup. It needs a boss. We make a boss. It has spread fire, circle fire, a hypervelocity orange, the standards. But. The boss is a witch. It’s a shmup with a witch boss in it.

The time has come, it's now or never. We need a beam.

It turns out the mechanical logic for a beam is very straightforward with the systems we already have. It’s just a bullet with a different hitbox and movement logic. But that’s not enough. You can’t have a beam if you don’t have the actual beam. With a bare 80 minutes to go I ask @ruruie: Can we have a beam?

(read bottom to top)

All we need is a rectangle with a rounded end and some gradient, right? Nothing too fancy, I've given our artist a tall order but it's doable if we keep it simple.

The beam produced is not a rectangle with a rounded end and a little colour gradient.

In the middle of final crunch time @ruruie produces not just a beam but a beam, a fully-featured piece of firepower with a complete charge and fire animation, more spectacular than any of our other bullets. In the last hour of the last day of the jam where we had to do it, the dream of long years becomes real.

Our game has a beam in it.

(play it here:)

https://ldjam.com/events/ludum-dare/56/magical-girl-danmaku-dandelina

"Okay, maybe moving the whole universe to avoid moving the submarine wasn't the play."

(please play our game)

Normally @ruruie and I approach every LD as an operation, with extensive pre-conception of game ideas by theme finalist, time off work, full-time over the weekend, etc. This time neither of our IRL lives allowed such a focus. We had no time off work and were not rested. We decided to do it anyway and simply scope down as hard as possible and it turns out you can still make a satisfying game this way. It's worth doing an LD even if you think you can't do it 'properly' and you might find it refreshing to have permission to do a small trinket rather than push for a game bigger and better than your last. We also still learned a lot and used new features of the engine; it was surprisingly nontrivial to get the mirrors to work.

Also, we implemented beams (or more specifically, ruruie implemented beams while I was asleep), which is the second time I have said 'we can't have beams, they're out of scope, we need to triage' and then @ruruie will not give up and makes them happen. We even implemented cats.

(check the beams, the cats, and the game out here: https://ldjam.com/events/ludum-dare/58/witch-solar (we need one more rating to cover all categories))