Space Pirates post mortem
Space pirates has been released publicly just weeks ago. It’s been a fun journey. As usual, when I ship software, I only see the bugs, what we should have done, the failures … and it’s a bit more difficult to objectively appreciate what we have done.
Let’s take a minute, be honest and write a post-mortem. You can always learn from mistakes and be proud of the accomplishments at the same time.
The game demo is accessible here : https://spacepirates.babylonjs.com/
And, of course, the project is open! You can clone and hack this repo https://github.com/BabylonJS/SpacePirates
What went right
- platform and cooperative work
I’m a noob with modern web. I come from native and my hearth is still closer to the metal. This is my first TypeScript project starting from scratch. Babylon team is experienced. The forum is active so, I started without apprehension.
The tools are Github, npm, VSCode and a browser. I create a new project from this template ( https://github.com/syntheticmagus/probable-barnacle ), follow the readme to get something running and…
… it’s a bliss. Everything works first try. I can type code, get errors, fix them. Browsers refresh instantly after a quick recompilation.
Coding/testing iterations are quick. In a matter of a few hours I get a space ship moving on screen. After a few days I have the menus, the AI, explosions…80% at least of the core features.
Once pushed to GitHub, a GitHub action is deployed to build the game and publish it online. Teammates can clone, do changes and push their modifications and everyone is in sync.
The build never broke. Definitely the way to go with TypeScript and babylon.js. The clone/build steps are simple enough so that you can do modifications when you don’t have a tech background.
Updating dependencies, like upgrading the babylon.js version is a matter of changing package.json and an npm command. If there’s a bug or something goes wrong , you can easily get back to the previous version.
- art/game direction
The vision of the shipped product was in Patrick’s head since day 1 I think. Even with a solid tech stack, you can’t release a game (big or small) without the vision. You will need to adapt, fix things, change meshes and textures here and there for various reasons, but it’s important stay on the path.
It doesn’t mean that you have to develop every single feature you list when starting the project. Sometimes (well, most of the time), your game mechanics and feature set looks like a Christmas list. Too much, too many, too complicated.
You will have to drop some of them because of finite resources and deadlines. It’s fine. It’s part of the vision to cut off some. Without one, you’ll keep the wrong ones and end up with a bad product or no shipped product at all.
We all need to have a Patrick on our team! Just for the magic of seeing the game taking shape one asset after the other.
What We Can Learn
- planning
Depending on your project, whether it’s learning new tech on the side, releasing a product or work on a big open source project, you need planning.
For example, if it’s learning some math for a fluid sim, you have to split it in parts but the time boxing parts can be moving. The goal is to learn, not ship.
When working on babylon.js, we don’t know exactly what the next release will contain but we know when we want to release it. Some feature won’t be done or finished.
And for a game/demo, we know when we release and we know the core features. We also know it will need a period of polishing.
I think for this project, maybe because we are experienced developers, we didn’t take as much time for a war plan as needed.
We should have done a really rough sketch of menus, states, core gameplay mechanics,… then iterate. Prepare a plan in that sense. Features you believe will be mandatory might not actually be all that important.
We’ve lost a lot of time on asteroids: we started prototyping procedural meshes, complex collision detection,… to end up with a few different instanced mesh and sphere collision detection.
Start simple and only fix it if it’s an issue. 90% of the game should have been done in 2 weeks. Letting rest of the time to do the other 90%.
- multiplatform issues
The typescript project allows you to have multiple browsers from different devices to see your changes. I usually have 1 Android device, 1 iPhone and a desktop browser. Refresh on all devices is automatic but, it takes time to test and fix smaller issues.
GUI for example can be an expensive task. Between different resolution, size and ratio. When a menu is perfect for 1 screen, it’s totally broken on another.
I totally underestimated this part. Once text rendering is in the picture you have to be really careful. The new Babylon.js GUI editor was, unfortunately, available too late during development of the game, but I think it would have helped.
Another underestimated thing is the multiplatform aspect of it. Browsers are not 100% consistent between different platforms, or across API/systems (Hey Safari, I’m looking at you!). From the fullscreen that is difficult on Safari, to input issues on Firefox, you will face annoying little problems. Be prepared.
- performance
As a consequence of not taking the time to have an optimal plan, performance was the last thing we really had time for. It happened too late during development and I’m not very proud of that.
This project should also have been a vehicle to leverage for finding runtime performances issues in babylon.js. We have indeed found a bunch but this could be improved with upcoming demos.
It’s not only runtime/rendering perf. Loading is an issue as well. 2 days before the release we figured out that it was too long. I’ve split loading into 2 asset batches. The first needed for the menus and the rest.
That way, you can ‘quickly’ see something moving and when everything is loaded in the background, you can start playing.
It was not an issue for 99% of development time. As loading time gets slower little by little, it’s never an issue when you don’t have fresh eyes or performance monitoring.
It’s now common to have automatic build/deployment linked to your GitHub. For next project, I think having a tool that loads the build and runs pre-recorded game play footage is a must have.
No need to check that rendering is correct between 2 builds but at least something that records frame duration for a 30seconds gameplay. That way you can evaluate where you have slow downs.
When adding a resource you know it increases page load time by 2 seconds so you might add a proxy asset or load it differently. You need valid numbers to make good choices.
Acknowledgments
All Babylon team members contributed to this demo in a way or another. Demos are the perfect to showcase the engine features, help build a solid and invested team and everyone learns something new at the end.
I can’t wait to start working on the next one.
