I've been doing Ludum Dare for 7 years now, and I've always had trouble managing my time. I always think I have enough time, until I don't. In recent years I developed a technique to improve my time estimations. Basically every hour I write down what I'm doing in a timetable like this:

What I like about this is that I can use my spatial intuition to compare time spent between programming, design, art, and sound. I can also look at the filled space and compare its size to the unfilled space to see how I'm doing overall. Also, the hourly update ritual keeps me accountable as I consider my priorities during the jam.

Hope that helps you with your next jam!

Oh, and you can check out the game I made this weekend, called Icy Mountain Hot Potato!

For my jam game Icy Mountain Hot Potato, I made the brilliant decision to once again roll my own collision code. As a result I introduced some mildly interesting unexpected behavior. As of just now, I've published fixed builds. I thought it was interesting enough to make a video documenting some of them, showing the before (bugged) and after (fixed). Have a look!

https://youtu.be/Bjr1IUajEUI

I finally got around to making a gameplay video of my game, Icy Mountain Hot Potato! If this looks interesting to you, head over to my page and try it out.

https://youtu.be/FV3XqUXI7zI

https://www.youtube.com/watch?v=0T2oQE-HSbI

Finally got around to making a Windows build! As I do not have a Windows machine at the moment, I had to figure out a way to cross-compile for Windows from Linux, which was a fun challenge. Head over to my page to check it out!

Check out our page: https://ldjam.com/events/ludum-dare/49/outer-space-transport-service

https://www.youtube.com/watch?v=nNRZa1580FM

Thought I would share an early concept drawing that ended up looking almost exactly like the end product.

the illusion of control

Implementing rotation control in a physics engine turned out to be more complex than expected, as you can see from this early planning diagram (which is almost exactly what ended up in the final game). Since the player's ship is part of the physics simulation, it's subject to all forces in the simulated world. That means that crashing the ship can result in angular velocity (i.e. spinning) that is impossible for the player to cancel out given only the basic Asteroids-style controls (e.g. hold left to turn left at a constant angular velocity, let go of left to stop turning instantaneously).

My solution to this was to add an auto-stabilizer that would stabilize the ship by applying a damping force until the angular velocity reached 0. However, trying to rotate the ship while the damping force is in effect makes for a rather janky experience, so I decided to simply ignore player input while the auto-stabilizer is in effect. After I did that, I noticed that it felt bad to have to wait for the ship to stabilize before trying to control the ship again, not to mention it would have seemed to new players that their inputs were being eaten, so I implemented input buffering, which is what you see taking up more than half of the state diagram. You still can't control the ship while the auto-stabilizer is active, but at least you can act as soon as the ship is fully stabilized.

Thank you for reading. You can play Outer Space Transport Service here.

well is a text adventure short story. Play it here: https://ldjam.com/events/ludum-dare/50/well

I spent the last few nights porting our C++/SDL text adventure short story game to build to WebAssembly using Emscripten, which means it's now playable in web browsers. Hooray! We're excited to share our game with more people who may not have access to a Windows machine.

That being said, however, our game is not very accessible or friendly or fun or fair. If you decide to play it, here's a hint that you can rot13 if you get stuck: gnxr xavsr

You can check out our game here: https://ldjam.com/events/ludum-dare/50/well

After some research, design, and paper prototyping, we now have a fairly concrete idea of what the first playable prototype should look like.

I've begun work on the asset pipeline. We're using SDL2 and Aseprite.

The level generation procedure is still pretty naive, but you can progress through the game now.

Also, the player can now pick up items (it's chalk).

There were a few problems before:

• Exit spawns too close to player
• Exit spawns inside wall
• Walls trapped player, making most of map inaccessible

I implemented Manhattan distance calculation to fix most of this. It'll also come in handy later when I start on enemy and familiar AI.

(assuming each enemy can move 1 square this turn and the enemies are all trying to get as close as possible to the player)

You'd have everyone move left, probably. But to come to that decision, you have to make sure (a) top minion doesn't get in the way of middle minion, (b) middle minion tells right minion that it's vacating its current position thus making room for right minion's advance. This will require something a bit more sophisticated than just iterating over all the minions and having them act independently in sequence...

My approach will probably be some kind of score maximizing search problem.

The hearts were too big, oops

nothing makes sense but hopefully it will soon

and it will attack your enemies