Une nouvelle charte graphique
2023-01-18
3 Ways Video Games Can Teach
2023-02-10
When everyone else uses Unity, why did we make our own custom game engine?
CRISPR Crunch, like all of our games at Play Curious, is based on web technologies, sometimes called HTML5, using our own game engine that we called Booyah.
Now this is far from the norm in game development. Most studios, including indie developers, use popular game engines such as Unity, Unreal, or Game Maker. These tools have large, established user bases, 3D editor environments, and asset stores where you can buy existing content for your game such as 3D graphics or menu systems.
So why did we choose to strike out on our own using HTML5 and our custom engine? Well, there’s a few reasons, actually:
- Play anywhere, on anything - What I love about the web is how ubiquitous web browsers are. You can use them on a phone, on a tablet, or a desktop computer. So it’s just as great to play on your phone on a bus ride as it is to play at home on a giant screen
- Fast development & deployment times - Web development is usually very quick. With the previous generation of tools - JavaScript & HTML - you would just refresh your browser and see the new changes. Newer tools such as TypeScript and Webpack often require an extra compiling step, but it’s still quite fast - on the order of a few seconds - as compared to 20 minutes of compiling for your Unity or C++ project. The same goes for deployment - sending out an update is almost as simple as copying new files onto the server.
- Better structure - I have found that the Component Entity System pattern at the base of Unity projects gets in the way of developing flexible code bases. At my previous job, I developed a game engine integrated into a visual programming environment called RedWire. Though the tool proved hard to use in practice, it gave me lots of ideas that carried over to Booyah. I’ll talk about this more in a future post, but suffice to say that Booyah focuses on primarily on how to structure your code, instead of packing in features such as physics or advanced rendering. We assume that you can find other libraries that do those parts very well.
Of course, there are downsides to HTML5 as well:
- Offline access is still a pain - Despite years of effort, web apps aren’t as well integrated into the smartphone or desktop operating systems as native apps. I was rooting for the ill-fated Mozilla phone OS, which would have made web apps first-class citizens , but neither Apple nor Google seem to be taking web apps as seriously.
- No app stores - This means that for mobile, you basically need to package your app as a native mobile app. While it’s not particularly hard to do, it does mean a lot more work than just pushing out a new version of your website.
- No consoles - It’s not as easy to package up your web app for consoles. Even on PC, there’s not a great integration with game controllers. A game controller API does exist, but it doesn’t have ubiquitous support. Since we are focusing on mobile-friendly casual games with touch & mouse interaction, this isn’t a big problem for us.
So now that we’ve talked about the why of choosing web tech, what about the how? That will be the subject of my next post. Keep tuned, curious friends!
-- Written by Jesse
