Articles // dev

Game Development: where to start and potential mistakes

Sergey Grachev
published: ⏰ 10
article image

This came about spontaneously, as it’s a bit of an unconventional topic and I wasn’t planning on writing about it. I made it while I was tidying up the code for the New Year’s counter on the main page with a hidden game inside. I thought I’d publish it publicly (maybe someone will find it interesting). I’m not a game developer, but I do have some experience. :) Basically, here’s an outside perspective on the things you should consider if you decide to take this on.

Info

I’ve uploaded the source code for the counter and the game from the main page to GitHub – Project. It’s nothing special, but maybe someone will find it useful.

Introduction

Why and how? There are several reasons. Some are interested in it specifically as a development and professional development area. However, not everyone understands that it might not be as fun as it might seem–there’s a misconception that it’s just entertainment. While that’s partly true, there is an element of entertainment, but it also involves endless code and is quite complex. Those who have previously worked on websites and enterprises with tables and forms may be unpleasantly surprised by the difficulty of getting started when it comes to medium and large projects. There are also overtime, production hell, and other perks.

The second option is simply interesting and useful for general knowledge. Game development has its own specific features in terms of code organization, algorithm use, performance optimization, its own architectures, and so on. Many of these things, for example, won’t appear in corporate app or website development. However, algorithms and optimizations are applicable to both, and it helps to look at the code itself and the application structure from a different perspective.

Next, I’ll discuss several important points and mistakes that I believe are worth considering. The examples are given from the perspective of developing a story-driven RPG (closer to a JRPG).

Design Document

Game design document (GDD) – is a document that describes the main aspects of a game, including mechanics, story, visual style, and other important elements.

Unless it’s a quick, just-for-fun project, it’s worth starting with a GDD. The first mistake is not doing so; you’ll still have to write one later to structure your ideas and overall vision of the game. It’s incredibly helpful in gaining a general understanding of the concept, one that’s consistent from start to finish.

If the planned game is something more complex than Tetris, then without this document you will have to keep quite a lot of information in your head. This will be especially problematic if there are different mechanics and systems, plot components, world, characters, etc. In fact, that’s what ultimately made him write over time. What does this result in:

  • A clear understanding of the game’s concept: idea, plot, mechanics, and systems.
  • A consistent storyline that helps you build a smooth progression and avoid getting lost in your ideas.
  • Characters, locations, objects, and the game world, along with an artbook that can be used during development.
  • A description of the gameplay, with all its components.
  • A list of tasks to be completed and their priorities.
  • VFX, SFX, UI/UX.
  • Target audience, platforms, monetization (if planned).
  • Timeline and budget planning (if any).

What you shouldn’t do right away is try to write everything down to the smallest detail. I’ll say right away–it won’t work. It’s better to create a basic skeleton and gradually expand it. In any case, there will be a balancing phase, which will definitely change some components of the gameplay or the game world. This document will be especially useful if the development process is long and intermittent; it’s crucial to maintain a context that can always be returned to. Or if you’re working in a team, then the document will be the main source of information for all project participants.

A little about the plot. When I wrote it, neural networks weren’t yet so developed and weren’t used at all. Now, it can be significantly simplified by describing the basic skeleton as a plot outline, and then expanding it with details using a neural network trained on fiction. An example of this approach can be found in StoryCraftr. I think this will significantly reduce the time, especially if you need to add detail to the description of the world and characters.

Selecting an engine and tools

The choice of engine depends on the scale of your project and the available budget or time for learning. For example, there’s little point in using UE for developing a simple 2D platformer; there are simpler and free engines. Currently, the main ones include:

  • Unreal Engine – a powerful engine, but it requires significant resources (PC) and a steep learning curve. I ultimately settled on it.
  • Unity – a popular engine suitable for both beginners and advanced developers.
  • Godot – a good open-source engine.
  • Additional:

I don’t recommend writing your own from scratch unless you work in the industry and understand everything that goes on under the hood. You’ll spend a lot of time on the engine itself, and your enthusiasm for finishing it may wane. Of course, there are exceptions when unique features are needed, but in most cases, it’s better to use ready-made solutions.

I primarily used UE4/UE5. It’s definitely not the easiest path, and the engine isn’t for beginners, but I liked its capabilities the most. I had no desire to learn a new language (Godot) or C# (Unity), so I settled on this one. What I liked:

  • Open Source – the code is open, and you can make changes to the engine.
  • Development in C++ – I used to write it and didn’t need to learn it from scratch.
  • Powerful UI system (UMG) – this was important and convenient for rapid prototyping and UI development.
  • Rapid logic prototyping – Blueprint system. I rarely used them, but sometimes it’s easier to do things with them than with C++.
  • The material system (Material Graph) is a truly powerful and convenient tool for texturing and shaders.
  • The sound system (MetaSounds, formerly Sound Cue) is actually a decent replacement for the commercial wwise and fmod.
  • Epic Games has a marketplace with a lot of ready-made resources and plugins.
  • The Plugin system allows you to easily split your code into modules and use them in other projects. Plus, you can integrate third-party ones.
  • And there’s a lot more I haven’t listed; I can’t remember right now.

Ready-made assets

Another important factor is the availability of ready-made assets, preferably for the chosen engine. There are both paid and free marketplaces. It’s worth noting that they have one problem: it’s not always possible to find resources in a consistent style, requiring modification or creation. However, it’s still very convenient to have ready-made resources, such as VFX or SFX.

Now, neural networks are very helpful; they can generate models (3D), textures/sprites (2D), animations, sounds, etc.

  • With 2D, things have been quite good for a long time, and in most cases, you can do it yourself. This is especially useful when generating artbooks for design docs or references.
  • With 3D, there are still some issues, but progress has been very noticeable recently. You can now use generated models as backdrops without much modification. If you’re interested in the process itself, you might want to look at those involved in 3D printing. There are options for generating projections first using Nano Banana, and then 3D models based on them.
  • Characters can be animated in Mixamo (https://www.mixamo.com). I got most of my animations from there.

Several examples of marketplaces where you can find ready-made resources for games and engines:

Development process

Your best friend here is the GDD (Game Design Document) and the task decomposition from the work plan. At the same time, the main idea is to move from simple to complex, and not try to implement everything at once. As an example, blockout is done first. This could be a level with simple dice that tests mechanics, progression, and so on. That is, the movement occurs first in breadth, and then in depth along each element. The most important thing is to check the idea of the game and that it works well. If there are problems, you can immediately review it and make edits, since in the next stages it will become more and more difficult. It is also important to understand that all elements of the game must be interconnected. That is, if you make mechanics, then it should be related to progression, plot, visuals, and so on.

If you try to work through some element at once, you may simply waste time and not get the desired result. As I said earlier, the GDD is being refined throughout the process and some elements may be quite heavily reworked or removed altogether. Both in terms of gameplay and visual implementation. For example, a mechanic with jumping was planned, but it turned out that it does not work very well in the game and needs to be removed or changed, and the time for its development has already been spent (animations, physics, code, etc.). There is no need to focus on one element, but rather move on the project as a whole.

Another important point is the ease of use of the engine. If the choice is poor, you can waste a lot of time tinkering with it without any useful results. For example, I spent a lot of time (days) in LibGDX trying to implement various things that would have taken minutes or hours to implement in UE. Was it worth it? I don’t think so. That said, I won’t lie, UE has its fair share of problems, but they’re mostly related to the engine’s relatively complex nature and the time it takes to master. This is in addition to the complaints about UE5 and its performance. UE is a huge, complex engine with a lot of functionality, some of which is simply redundant and can be disabled. But not everyone can or wants to do that kind of optimization.

We also need to mention tools for prototyping. I won’t say anything about other engines, but UE has such a thing as Blueprints, which allows you to create logic without writing code. This is very convenient if you need to quickly check something. For example, I also used them as an alternative to scripts - a game with CCG elements and the algorithm for using the map was described on Blueprint without code. There is also a trap hidden in them - they are good for prototyping and undemanding logic. Subsequently, they must be rewritten in C++, which, of course, is not always done, resulting in lags when executing them.

Well, the development process itself is still different from creating all sorts of websites and forms. It is necessary to understand that all calculations and interaction logic must fit into at least 16ms (60 FPS) per frame. This means that if you do something complex in tick (UE), it will be a problem. We’ll have to think about how to optimize this and change development approaches. And UE, for example, renders in one thread in the general case (as in general, most engines). This is actually not bad, it allows you to look at development differently and look for more optimal options for solving various problems and expanding your overall horizons. New concepts appear, such as DOD design (Data Oriented Design), ECS architecture (Entity Component System), various algorithms ( graphs, spatial structures, BFS, A*, physics, etc.). All of this will have to be dealt with one way or another.

Publishing the game

Once the game is ready, it needs to be published. There’s not much I can say about that. If you live in a country not under sanctions, there are plenty of options: Steam, Epic, Google Play, and the App Store. They all typically charge a commission of 10% to 30%. It all depends on which platform you choose.

If you live in a country under sanctions, then either local platforms with a small reach will do. For an indie, this will likely bring nothing. Or you’ll become a Cypriot :)

Conclusion

Overall, it’s a pretty interesting topic, if you have the time and inclination. One opportunity is to take a break from the bloody enterprise or UI form development. Try working with a completely different tech stack and development approaches, write your own story and game world, develop systems and mechanics (analysis after the fact), and so on.

To be honest, I gave up on this a long time ago because I had to switch to something else. But the experience and many skills remained, which later came in handy in other projects unrelated to game development.

Gamedev Essentials Devmix
GameDev 1 of 2
Creating a 3D fog of war →