Engine Feedback :: An LD46 Postmortem

(Michael Burns) #1

Hi all, I had previously posted this on Discord and it was suggested I share these thoughts on the forum where they’ll be more discoverable. I’ve edited in some responses I got there which addressed (at least partially) a couple of the points so those resources are also discoverable.

POSTMORTEM

The game: https://ldjam.com/events/ludum-dare/46/feed-it-grapes-keep-it-alive

What worked

  • ECS - overall model was flexible and enabled quick iteration, even though we weren’t familiar with the pattern and probably used it wrong
  • We were able to bootstrap a core game that had multiple, independent workflows after only 2-3 hours of effort, which was a massive boon to velocity
  • Music and sounds made the mood neat without significant effort
  • We didn’t really write bugs, since writing bugs is hard (once you figured out what the engine is doing)
    • ~2k LOC without any significant bughunts
  • Rust
    • Is good
    • Is safe
    • Is fast
    • Is pretty ergonomic
    • But maybe the &/mut placement is a little arcane for the novice

What didn’t work

  • Documentation lacks a good 10,000 foot overview of what the engine looks like
    • A picture of the overall architecture would have been a huge benefit
    • We ended up sort of strip mining the examples and reverse engineering them into artifacts that did what we wanted
  • UI wasn’t low friction
    • Positioning didn’t work well (in particular, hidpi)
    • Prefabs didn’t work well (and we didn’t know there was an alternative)
    • Unclear why this needs a separate input bundle? (Probably the separate EventReader after some more reading, but this isn’t apparent.)
    • System inclusion can be order-dependent
    • It took 6 hours to make a button using the tutorials
    • Apparently there’s a way to do this without prefabs, but this isn’t even mentioned in the documentation (the prefabs were also hard to find to copy)
  • Pathfinding
    • Graphs in Rust are nontrivial thanks to the borrow checker
    • Not complete at the end
    • Got it now, thanks to r4cppp (I’m out of links since this is my first post, but a search for “r4cppp graphs” will turn it up)
  • System-specific grossness
    • Didn’t compile cross-platform without manual changes to GFX backend
    • Apparently had other issues on OSX for… reasons
    • hidpi support was inconsistent even though logging implied it could be automatic
  • Audio API seems immature
    • No way to loop a sound? (Naive approach takes infinite memory.)
    • No way to do something when a stream ends?

Where things just got by, mostly by accident

  • The core gameplay wasn’t really the result of a plan so much as cutting scope and accidentally being fun
  • We learned Rust… sort of
    • The end product functioned
    • It definitely wasn’t idiomatic
    • But we had fun
  • Input
    • We didn’t have a method that homogenized all coordinates to world space before being handled; this should have happened in some wrapper for the input system
    • Saw something in the issues that suggested the engine can do this and this was just noob-ness

Observations

  • GameState’s’ ability to mutate GameData object makes the data access/mutation patterns unclear, which wasn’t obvious from the documentation
7 Likes
(Nathan) #2

That’s fantastic feedback, thank you!

I’ve been wanting that 10,000 foot overview as well. Also, thank you for that presentation link! I’ve never seen that presentation.

I empathize here. Finding assets that the examples use was so difficult that I recently colocated all example assets into the example folders they are used, so at least you can find them. Next, all the prefabs really need to be decomposed back into code (maybe keep the prefab also, since there doesn’t seem to be any explanation on how to create prefabs?) They were originally in code, so a lot of that work will be looking back in the history and merging what worked in the past into the present state of things.

1 Like