When OgStar asked us to create kids reading app – with 106, multi-step, high-engagement lessons, requiring between 15 and 45min of content a piece – we knew we’d need to create a new form of lesson builder. We needed something that could ‘hammer out’ the lessons for us – and with that the Hammer Editor was born.

The idea of doing scene preprocessing at build time is nothing new (see PlayDead’s awesome publication (link) on preprocessing an experience for optimization.) But because of the mass amount of content in this project we knew we had to take preprocessing to another level. We didn’t want to rely on ton of scriptable objects assembled together, then parsed and executed at runtime. Instead, we made it much more fun. ))

We recognized that the lessons we needed to create had a discrete set of reoccurring scenarios – so we first built ‘Template Scenes’ for each that contained placeholder mechanics and logic.

Second, we created ‘Setup Scenes’ each containing art assets (backgrounds, characters and props) for each lesson stage – but no logic. Setup Scenes also included placeholders where prefabs could spawn – but rather than at runtime, we configured them to spawn during preprocessing.

On top of all of it we built our custom Hammer editor that housed a bunch of inter-connected scriptable objects designed to pull everything together. Instead of parsing every build, Hammer automatically assembled custom scenes by ingesting the required Scene Template and the correct Setup Scene and applying configs to needed mechanics and modules.

Output of this process was new, procedurally generated, scene that contained everything needed to play/execute the lesson. This not only allowed us to streamline the creation of the enormous number of lessons in the product, but it also allowed for a much more efficient QA process. This included runtime checks for “dirty” prefabs, correct theme and character cases, checks for missing VO and checks that all flows in the templates had corresponding configs – and many others.

Overall, the approach worked really well. Build time did increase but with CI and nightly builds it was a good tradeoff for runtime efficiency and significantly better project organization. And, allows us to develop a great series of apps that will hopefully help kids with (and without) learning disabilities learn to read better.