The journey from low-code developer to full time game dev

An informal introduction

Hi, I'm Luke and I want to build a game. I've spent a number of years as a software developer on a low-code platform, so I think I have a slightly different perspective to building a game than the average aspirational game dev. I recently switched to game development full-time using Godot, from being a full time low-code developer on the Pega platform. Enough about me! This post compares the development experience between these two technologies, and outlines the main similarities and differences between the two.

This post assumes you, dear reader, already understand the basic principles of object-orientened programming, specifically the first five points on this well explained blogpost on geeksforgeeks.

What is a low-code platform and what is a game engine

A low-code platform is an engine, typically browser-based, that will generate code automatically based on the developer's inputs in the UI. An example is that a flowchart diagram built in the low-code platform represents a process and is converted into code and runs when a user presses start. Different shapes can be added to the flowchart to represent different steps in the process. This includes steps that represent choices about which path in the flowchart to follow; steps that represent a web form to gather a user's data and steps that represent calculations for the engine to run in the background.

A game engine is a program, typically locally run, that provides templates with some baseline behaviour that a developer can extend. It also provides a way to queue events for execution that may not relate to how the object was created. An example of this is that a weapon can create a bullet, and the code on the bullet to inflict damage is not run until the bullet detects that it has collided with another object (or vice versa). The bullet and weapon will have visual assets, and the bullet will have some physics interaction, both of which will have templates in the game engine and can be extended.

Command line code

There are a number of parallels between a game engine and a low code platform. Both provide tools, templates and code generation wrapped in a UI to accelerate development. Both allow a developer to use command-line-like code to customise behaviour, but the attitude towards command line code is wildly different.

Command-line-like code on a low-code platform violates the best practice prescribed by the platform and is considered to be a deviation from the platform's principles. After all, one of the benefits of using a low-code platform is to avoid the use of command-line-like code. From a marketing standpoint, this makes sense. The low code platform is marketed as a complete solution to a business's digital workflow. It is the solution that provides value through development speed; seamlessly adopting new technologies; ease of upgrading to new platform versions and can often be understood by someone from a non-technical background without any training. If the platform cannot offer a full solution to a business need or even a particular issue within a business, it is viewed as a limitation of the platform itself and developers are often discouraged to fully solve the problem, even though they have the skill and capacity to do so.

There are many times in my career where the outcome to an issue was to accept the functional gap in the platform than to extend the behaviour through code to meet the business's needs. That being said, there are benefits to doing this: not everyone trained in a low-code platform may be trained in the underlying language and extending a script provided by the platform can cause conflicts, defects and loss of data integrity when the platform is upgraded. Furthermore, a newly released version of the platform may include a new standardised feature which solves the business’s original problem.

For a game engine, the attitude couldn't be more different. A game engine embraces custom code: many user-defined classes need custom scripts that determine their specific behaviour (after inheriting some behaviour from the game engine's template classes). Godot even goes one step further: not only does it support C#, but also supports its own language, GDScript. Continuing the bullet example, the game engine won't have templates for how a bullet does damage: is it a paint bullet, a holographic bullet or a real bullet. Will it apply enough pressure to pierce the object it hits and actually inflict damage? All of these different behaviours will need their own code to govern how the interactions should work.

As a low-code developer, I was constrained to build features on the platform following the platform’s guidelines; but as a game developer, I almost feel spoiled by how many possibilities I have to (badly) code a single feature.

Top level objects

Business processes are the main focus of a low-code platform. They are elevated above all other classes within the platform, usually by inheriting from a special template class that represents a generic business process. These classes are almost always the only top-level objects instantiated that can be directly interacted with. Everything else must be embedded within the process or accessed via references on the process. The benefit to this is that there is a single record in the platform's database that contains all of the relevant information for the customer/onboarding/provisioning/etc and previous versions of that information.

In contrast, in a game engine, there is no single top level object that must be instantiated. Obviously the game itself needs to be instantiated, in the same way that the user's session needs to be created, but after that, there is no strictly mandated class that needs to be created at runtime for the player to play the game. There can be many top level classes and these can change as the player navigates through different parts of the game, like main menus or levels. Even objects that model bullets in a level can be considered top level, and are accessed through signal or group patterns (Godot's terms, different game engines may have different names for these concepts). Essentially, it can be beneficial and correct for dynamically created objects to not be child entities of the object that created them. They may also be dynamically destroyed after they have served their purpose. There's no need to keep track of the position of a bullet after it's no longer a threat to the player, right?

Data modelling

Inheritance also works with a similar concept in mind to object instantiation: the organisation is a top-level class where almost all other custom classes should inherit from (in or way or another).

Because the inheritance is mandated to be certain way in the low-code platform, this constrains how a data model can be defined. There are pros and cons to this. There is usually only one correct way to define a data model on a low-code platform, which reduces the design overhead. On the other hand, there are usually functional trade-offs that have to be made when defining a data model in the "correct" way. Usually on a low-code platform, after the data model is created, it's very difficult to change, so building the data model in a way that doesn't match the business's needs can significantly slow down any development work until it is corrected.

There is a lot more freedom within a game engine. For example, should the playable character inherit from a visual asset template, from a character control template, or from a placeholder and have all other applicable classes embedded? Which classes need to be embedded and which specifically must not be embedded in order for the player to function correctly? For example, are the bullets they shoot considered the object's children? If so, should any movement the player makes also apply the same translation the bullets?

I have one fewer mental frameworks in which I think about code on a game engine when compared to a low-code platform. I found it difficult to unlearn at first and I honestly did try to resist this new freedom at first.

Development perspective

The end user's perspective is second to correctly modelling the business process on the low-code platform. Which user group will interact with a process is often considered before how each user group interacts with a process. Quality of life features are usually implemented for users after an MVP goes live, but any poor user experience is often collateral after the process is built for the first time.

This is the complete opposite to a video game: where the player's experience is at the heart of the development team's interests, or at least it ought to be.

Closing words

The game engine and low-code platform share many features: templated code, background processing options, debugging tools, and standardised shortcuts for development. However because the focal point for these features are radically different, the implementation and attitude towards using them is also radically different. I am already familiar with a lot of the features that a game engine has to offer me from my experience with working on a low-code platform, but I often approach them with the wrong context out of habit.

But habits can be broken and I’m looking forward to re-expanding the paradigm in how I think about designing and building a feature. I’m now working with fewer limitations and I have a greater capacity to express myself joyfully through code.