-
-
App Icon
-
Building & exploring
-
Turning the world
-
Multiplayer screenshot
-
Inventory
Inspiration
Don't Go To Bed started with my boys, Leo and Ian, and the sort of game ideas that make perfect sense when you're a child: build things, fight monsters, turn the world sideways, and find Mammy.
Inspired by Minecraft, Super Mario Bros. and the boys’ own drawings and ideas, we wanted to make something together as a family. Leo, Ian and Papa became the playable characters.
The story is simple: Mammy has gone out, Daddy has forgotten where, and we need to find her before dark. We have some building blocks and a plan.
The plan is mostly building blocks.
What it does
Don't Go To Bed is a 2.5D adventure, now available on Google Play and the App Store for iPhone and iPad.
Players can explore, break and place blocks, collect materials, fight zombies and skeleton archers, use potions and search for Mammy before nightfall. Turning the world switches between two directions through the same world, revealing different routes and nearby terrain.
You can play solo or join another player over local Wi-Fi. Multiplayer shares the adventure: players see one another, change the same terrain and face the same enemies.
The game includes music that changes between the menu, the search and the night-time panic, alongside sound effects, separate volume controls and accessibility options for movement and reduced flashing.
All characters and gameplay are free. RevenueCat powers optional, repeatable one-time tips in a grown-up support section. Tips do not unlock content or give players an advantage, and there is no subscription.
How we built it
The project began as an Android game and grew into a Kotlin Multiplatform application.
Shared Kotlin code handles the game rules, world, inventory, combat and multiplayer messages. Compose Multiplatform provides the interface and rendering, with platform-specific integrations for networking, audio and device settings.
We built it without a dedicated game engine. That meant implementing systems such as movement, collisions, enemy behaviour, world projection and animation ourselves.
Multiplayer uses a host-controlled world with WebSocket connections. The host coordinates terrain changes and shared entities so that actions such as mining a block or firing an arrow can stay consistent between players.
Testing has included Android emulators and physical Apple and Android devices, including an older iPad. We have played together across physical Android and iOS devices; multiplayer still has bugs. Automated tests cover shared game logic. Release preparation included device checks and real gameplay footage.
Challenges we faced
One of the biggest challenges was making a world that turns without making the game lose track of where everything belongs. Terrain, enemies, arrows and other players all need to remain consistent when viewed from a different direction.
Multiplayer added another layer: two players can act at the same time, join at different moments or leave unexpectedly. We had to think carefully about which device owns the world state and how actions and updates travel between devices.
Performance also mattered. A game that feels fine on a development machine can behave very differently on an older tablet.
One particularly surprising crash came from a skeleton archer's flashing effect. A tiny positive opacity value rounded down to fully transparent in the graphics library, triggering a native rendering failure. It looked random while playing, but several device crash reports led us to the same cause. We added a guard and regression tests for that boundary.
And, of course, there was the ongoing challenge of turning an enthusiastic family wish list into something we could actually finish.
What we learned
Sharing code across platforms is valuable, but it doesn't remove the need to understand and test each platform.
We learned to separate game rules from rendering, make ownership explicit in multiplayer, and use real crash reports rather than guessing from what a player sees.
We also learned that “it builds,” “it opens,” and “it survives a proper play session” are three different milestones.
Most of all, we learned how much personality a project gains when the people helping to imagine it also become its characters.
Accomplishments we're proud of
- Releasing our family game on both Google Play and the Apple App Store.
- Receiving our first €9.99 Android support tip while keeping all gameplay free.
- Building shared gameplay and local multiplayer without a dedicated game engine.
- Making world turning part of exploration.
- Adding music, sound effects and accessibility settings.
- Creating a trailer with our own narration and real two-player footage.
- Preparing the code for public collaboration, while keeping private release material and credentials separate.
During the multiplatform migration, the build passed 92 Android unit tests and an unsigned iOS Release build. Since then, we have released on both stores and played together across physical Android and iOS devices. Multiplayer still has bugs to resolve.
What's next
The game is released on Android and iOS. Next comes improving the experience on real devices and choosing small additions with the boys.
In our September 28 family discussion, we worked through a crafting idea together: a workbench opens a recipe list, and we start with a simple version the boys can play and refine. Crafting is not in the released build. We also revisited character specials: a drum-kit ability and a giant dog, replacing an earlier giant-cat idea. Larger worlds, more building materials and Jenny's quests remain future candidates rather than promised release features.
The code is MIT licensed, with separate terms for family artwork and branding. We welcome people exploring the code and making their own versions with their own identities and assets.
For now, we just need to find Mammy.
Preferably before somebody puts another twelve blocks of dirt in the bag.
Log in or sign up for Devpost to join the conversation.