Splinter

I made another game! This was another single month project, as practice both for developing quickly and for keeping track of scope. It’s called Splinter, it’s about sword dueling, and it’s available on itch!


Of the month-projects that I’ve done so far, this was the least successful in terms of delivering a product but the most successful in terms of lessons learned. In fact, I learned so many things that I was able to procrastinate writing about it for many months. In no particular order, here’s a few of the things I took away.

  • System design and content design are separate, and they need to be budgeted for separately. I designed a neat system for dynamically simulating a sword duel and developed an AI to fight use it, but did not foresee the fact that I would then have to tune and balance the enemies to be fun on top of building the system.

  • Building physics simulations from first principles is non-trivially hard. I tried to put together a spring simulation to drive the sword using the math I remembered from high school physics, but it was very unstable. I hindered by not yet having a truly deep understanding of Unreal’s execution order and frame rate handling, which would have helped.

  • Asset creation isn’t necessarily the long pole task. I threw together a cave with some spooky flora and interesting lighting in an afternoon with some Houdini magic. Admittedly, this is easier if your game is mostly set in the dark.

  • Copying physics simulations works great in a pinch. I ended up replacing the spring with a slightly modified implementation of Verlet integration that I stole from the internet. This worked just fine for my purposes.

  • Complex gameplay systems need an abstraction layer to translate from engineering-semantics to design-semantics, even when I’m both the engineer and the designer. The sword simulation exposed a whole lot of variables about how the sword moved and bounced and curved and all sorts of things. This was great, but it would have been much easier to work with if I had just a few higher level knobs for things like “weight” and “responsiveness” that I could use to change things when designing enemies.

  • Mixing animation systems isn’t the end of the world. I had a few animation-minded friends working with me, and one person ended up building the player sword rig driven by IK while at the same time someone else was building the enemy sword as a system of blend shapes. I was a little worried that this would be confusing, but they were separate enough problems due to the different viewpoints to camera that it wasn’t an issue.

  • When they say C++ doesn’t do memory management for you, they mean it.

  • AI system benefit from being clear about requirements from the system design phase. The AI Duelist for this project had one or two different idle states, interspersed with brief (but not instant) sword maneuvers. Knowing these constraints from the start let me make a system quickly that felt very comfortable to build these specific behavior patterns on top of.

  • Concept art should be from the player perspective. I ran into this on Root Cause as well, but this project hammered home how important it is for all stages of asset creation to keep the player in mind. The enemy character was viewed head-on, and our modelling and animation poses would have been stronger if we had reviewed everything from the player perspective throughout the process.

  • Similarly, artists need a goal even if there isn’t a specific visual style determined yet. I was very hands-off with the art style on this game. Rather than creating unbounded creativity it caused unbounded anxiety, which does not make good art.

  • Levels! This felt so obvious once it clicked, but I didn’t understand until this project why so many games have multiple levels. Not only is it to give players more content (and therefore is out of scope for a quick prototype), levels also drastically reduce the need for perfect balancing. It was almost impossible to calibrate a duelist enemy that was exactly perfect difficult, but it was almost trivial to make a very easy one, a very hard one, and a few in between.

Next
Next

Root Cause