In game developing choosing to use a game engine like Unity might sound like a no-brainer. Do you really have time and willingness to make something that’s already there? But we chose not to go traditional route and make everything our own!

So you want to develop a multiplayer NFT game?

Developing any product requires a series of decisions. Each with unique pros and cons guarantee that no piece of software is the same. The most impactful overall is the tech stack. It dictates what technologies your team will have to use, on what platforms can you ship and what technical challenges will be difficult or downright impossible.

Needless to say, determining what languages, libraries and frameworks you’ll be using is tough decision with many unforeseeable consequences. There are some rules of thumb that can be followed however. Here are some of them that we considered while choosing our approach to BallisticFreaks development.

Not using a game engine means freedom to excel

Our prototype was made in GameMaker studio 2. A renounced 2D game engine with many years of experience and development. High development velocity and many fantastic features make it a perfect choice for any capable game developer. Same goes for engines like Unity, Unreal and Godot or any mature engine. However convenience comes at a cost and by that we don’t mean pricing. These tools are closed source or have licensing attached to them. If something breaks down you have little to no possibility to fix it.

Even for open source engines you’d have to learn the language and have deep knowledge of the engine to tinker with it. While that may not be an issue for many games, working with newly established technologies is often hard or the features are straight up unavailable.

Build process? It’s a mistery!

The main reason for this tough choice mostly because of our target platform – browsers. Browsers have the peculiarity that client always have access to the source code and have tools built in that make modifications very easy. Because game engines target multiple platforms we might run into issues where compiled code has security vulnerabilities and is exploitable (especially when talking about communication to multiplayer servers and Web3 integrations). Therefore we chose not to leave anything to chance and create our game optimize for the intended platform.

That’s why we chose TypeScript with PIXI.js graphics library. We are in control. Instead of having to bring an entire kitchen with an oven to make a meal we light a fire pit and weld a frame for the pan. We have the freedom to optimize for specific scenarios, have rich browser integration and write code in the native language of the web.

Composition beats inheritance

We use many pieces of software and chain them together into a working product. Therefore we have great modularity. Some library doesn’t support vector graphics? Just replace it with another one. Database acting vierd? Alternatives are ready right here and now. This gives us great flexibility to develop pieces of software that can be tested separately and optimized without the need for changes in any other parts of our game.

This pragmatic approach gives us the best way to deliver a solid and reliable user experience with most options. This would not be possible with a game engine, because it locks you down to a specific approach as it is built as one big mountain.