Ludum Dare 56: Business Beetles

on



tl;dr: I participated with friends in the Ludum Dare 56 game jam, and we made a chill simulation game with business-oriented beetles and mafia crows!



The jam

The theme of the jam was "Tiny Creatures".

We made this game for the Ludum Dare 56 game jam. This was a "jam" submission, created in 72 hours.

We made all the design, code, images, sound effects, and music during the jam.

Screenshots

Shows a sales-beetle finding a customer, making a sale, and returning to the office with a money ball(an animated GIF of a recording from Business Beetles).
Beetles go about their business during the day.
Sales-beetles look for customers, make sales, and return with money balls to the office.

Shows the end-of-day screen where you can see stats from the day and where you can allocate new recruits into sales, recruiting, or guards (an animated GIF of a recording from Business Beetles).
You see your stats and allocate new recruits at the end of each day.

Shows a late-game day with a lot of beetles running around, and mafia crows coming to take your money (an animated GIF of a recording from Business Beetles).
Mafia crows want to take your money! Also, you can speed-up time.

Retrospective

  • I did this game jam with a group of friends that I've for a couple jams now.
  • I love working with artists and sound designers!
    • It's so much fun watching the game become beautiful!
  • Brainstorming
    • We struggled more to decide on an idea for this jam than we have in any other jam I've done.
    • But this got me thinking about our process for deciding on game designs in general. In most jams I've been in, we try to come up with all of the parts of the game ahead of time, and then implement our list. This is a very "waterfall" process, and doesn't give us much opportunity to iterate. The important consequence of this approach is that we don't get to explore the problem space much beyond what we can think of up-front, before actually experiencing any of the resulting gameplay.
    • I think, in general, we understand that prototyping and iteration are important to making a good game. But I think we still tend to feel the need to have all parts of the game described ahead of time during our initial brainstorming.
    • I think the take-away is to plan less of the game ahead of time. Instead, we should plan the general approach, and a very specific minimal and quick-to-create prototype to prove-out the main idea. We then should have another small brainstorming session after testing that prototype.
  • Behavior trees
    • Behavior trees execution flow is always tricky for folks to wrap their heads around.
    • But having a good behavior tree framework really helps!
    • We did _not_ have a good behavior tree framework. What we had was better than nothing--probably.
      • We used the Beehave plugin for Godot.
    • I ended up needing to make a few updates to the underlying behavior tree logic in order to support our basic needs.
    • Things I wish this plugin included:
      • Setting breakpoints in the debugger's visual node tree.
      • Interrupting long-running nodes based on a condition set in an earlier node.
        • The problem is that this framework won't ever re-run the earlier condition node while the current node is still running.
      • Tracking delta-time per tick.
      • Support for randomizing the time in their delay nodes.
    • Changes I made:
      • I added support for tracking the delta for the latest tick.
      • I removed the behavior tree's calling of `tick` in the render-frame, and we only call it now in the physics frame.
        • Calling it in the render frame was redundant, and led to inconsistent tick durations.
      • I added a custom Delay node for randomizing the amount of time spent in the delay.
        • Also, this let me hook-up the delay to our global time-scale value that we used for conditionally speeding-up gameplay.
      • I added a handful of nodes to support interrupting a long-running node according to a condition defined in an earlier node.
        • The problem is that this framework doesn't ever re-run the earlier condition node while the current node is still running.
        • So I added a SmartInterruptSequence node that checks the result of it's first condition child node during each tick, and then interrupts itself (and it's descendants) if that condition ever becomes false.
        • I added a similar node for selectors.
  • Git merge conflicts
    • This is inevitably a big pain point for folks on the team.
    • I guess this is somewhat inevitable, since we're all making so much progress so quickly across such a small space.
    • But Godot definitely wasn't helping this time around. It seems to make a lot of unnecessary updates to node path IDs in scene files, which leads to extra merge conflicts.
  • Starter project layout
    • I think this was the best starter project layout I've used in a group game jam!
    • I used to have a giant starter project layout I would use for all of my solo jams (Scaffolder), but it was pretty clunky to get started with, and wasn't very beginner friendly for sharing in a group setting.

🎉 Cheers!


This is a simple icon representing my sabbatical.

Comments

Post a Comment