You might have heard that we’ve opened up our game engine Defold, to the world for free. During GDC16 Thomas Hartwig, our CTO, together with the team presented the engine and how it can help more people create games. This is Ragnar Svensson’s story of how Defold was created and the choices they made during development.
Defold started with me (Ragnar) and Christian discussing how to best create new games. With years of industry experience, me as lead programmer and Christian as engine architect, we often discussed trends, technology and best practices in the industry. At the time we were both impressed by what we saw from some of the AAA games. Comparing some of their technical solutions to the mobile games industry we felt there was improvements to be made.
I remember specifically, one late night when Christian suddenly said: “I’m actually making a game engine at home”, and I replied: “Me too!” Realising we should build together instead of separately, started the story of Defold.
A few of the key things we considered while building Defold was Performance.
Performance affects everything. Not only run time but also workflows, load time and everything else that has to do with a game engine and creating games. Without performance you have nothing and that’s why we value it the most.
We also wanted to maximize creativity, which we’ve achieved by removing obstacles, friction and minimizing waiting-around-time.
Scalability is another aspect of performance. If your game grows with more levels or bigger playable worlds, it shouldn’t be restricted by the engine. A game engine should efficiently create complex scenes or structures and reuse objects. Basically it should just work for you, not against you.
When we started working on Defold the game industry also started opening up to not only use Windows but also Mac, Linux and so on. So we wanted to make Defold a cross platform from scratch.
Cross platform is an important factor when you’re making a game. Because it’s not always obvious what platform will work the best when you start creating your game. That choice should instead come at the end of the project when you have all the pieces of the puzzle at hand. In the end, it’s all about shipping games.
A problem we saw with in-house technology was the insider knowledge you needed to be able use it: “Oh, it doesn’t work for you? Here’s a script.” All of these workarounds and systems that just weren’t ever fixed. We wanted to create a solid product. Something that worked and that you could depend on.
So we turned Defold into a web service with a Git version control. A complete package that would take care of everything for you so that you wouldn’t have to make all of these choices, like: “What version control should I use?.” It should just be a system that you turned on and started creating games in.
When we started we were only two programmers so we knew that we had a monumental challenge ahead of us. We realised that we could never rewrite code. We just had to solve problems, once and for all. We couldn’t afford spending time fixing bugs so we were very careful to avoid mistakes from the start.
That meant that we had to have a very strong design focus even before we started to code. In fact, we spent more time in Google Docs than coding, making sure that we had cracked every problem before we dove into the code.
When the coding began, we sprinkled it with automated tests. All to be certain that we quickly found out if we broke anything with any new line of code.
Being only two, automation became the mantra for us. We even went as far as implementing a video recorder in the engine (it’s still there!) just for the sake of being able to run test examples, capture videos, upload to Youtube, and include them in the documentation without any manual interventions.
Another key piece that was important to us, was frequent release cycles, so we implemented a biweekly release cycle. And these were not just about bug fixes, but actual significant releases! We wanted to bring features that people would get happy and exited about. To make them trust our promises. Something which still stands: We promise 100 percent backwards compatibility at all times!
As a final note, I often compare creating games with sculpting in clay. Clay is the perfect interactive environment to instantly see how your action is affecting the material. We want to create the same situation in Defold where you can test things and instantly explore the result. This to me, is really how a creative workflow should be and what making games is all about.
