【Game Development】Traditional Game Making Methods

Originally, this article was going to be written specifically focused on console game development.
Upon thinking about it, I realized that the fundamentals are basically the same as development for PC and smartphones, so I made the content applicable to all platforms.
However, as a console game developer, the majority of the article will focus on console game development.

Background

Specifically, since the 3DS and Wii U era, I have been making games for Nintendo systems.
Technically it started from the DS era, but that was at the end of its lifecycle, so I only made demos and never worked on a full-scale project.
However, I was one of the first third-party developers who was not a company.
As a result, I had the opportunity to communicate directly via email with famous developers from major companies.
This hasn't changed at NDP, but now names and email addresses are anonymized, so I no longer know who I'm talking to, which is unfortunate.

Thanks to being in such a unique position, I was able to deeply understand both using game engines and creating games from scratch.
The early 2010s was a transitional generation between the era when making games from scratch was mainstream and the era when using game engines became mainstream.

At first I was using Unity.
However, just the Unity runtime consumed almost all of the 3DS's available RAM, making it nearly impossible to create a proper game.
So right after releasing a 3DS game made with Unity, I started learning how to make games from scratch.
It was much more difficult, but far more enjoyable, and I haven't gone back since.

Why Make Games From Scratch?

Today, most developers use either Unity or Unreal.
This is because indie developers often lack resources and knowledge, while large companies lack patience and want to release to as many platforms as easily as possible.

However, there are also indies (like us) and large companies that create their own engines from scratch.
Most people probably think "Why go through the trouble when Unity and Unreal exist?" but there are legitimate reasons:

• You can optimize performance in ways that aren't possible with conventional engines
• You can experiment with concepts that conventional engines can't handle
• You can take special pride in your own achievements
• You learn a lot about the internal workings of platforms that are taken for granted when using conventional engines
• It's just fun

Also, most individuals and companies use conventional engines for financial reasons.
Because you can create shippable games much faster.
In our case, the game-making process itself takes priority.
We are a company, so of course making money is important, but we don't have investors to please, publishers to listen to, employees to pay salaries, or SaaS-like middleware.
Therefore, we can rearrange priorities however we like.

Occasionally we just need to make large purchases like dev kits, drawing tablets, DAW programs, etc.
Also, near game release there are significant costs for age ratings, marketing, and cartridge production, but these are all one-time expenses, not ongoing.
And much of the money spent is recovered directly via eShop or indirectly through retail once game sales begin.

How to Make Games From Scratch

PC

Especially on PC, there are multiple paths available.
PC offers the luxury of choosing from multiple SDKs, frameworks, programming languages, and stores.

Popular frameworks include SDL, SFML, and more recently Raylib.
If you're new to game development, I strongly recommend Raylib.
Because it's simple, easy to use, flexible, and has excellent documentation.

I used to use SDL as well, but because it depends on many libraries, it's the kind of thing where you have to distribute the entire OS together.
I used SDL2 for both Pong and Brick Breaker, but for future "for fun" projects I want to use Raylib.

Previously, I said I disliked using frameworks.
This mainly applies to web development.
In web development, frameworks often add unnecessary complexity compared to building websites or web backends from scratch.
I feel it's much easier to use real PHP than to set up a Laravel project.

However, the situation is different in game development.
Because the underlying systems are far more complex and fragmented, frameworks are actually welcomed.
Unlike the web, where the frontend is dominated by Blink and Gecko (which follow each other), and the backend is mainly Linux or BSD (quite similar), games must deal with various platform-specific APIs:

• Windowing and input: WinAPI, X11, Wayland, Cocoa
• Graphics: OpenGL, DirectX, Vulkan, Metal
• Shaders: GLSL, HLSL, MSL
• Audio: WASAPI, sndio, OSS, ALSA/Pipewire, and countless others for macOS, NetBSD, Haiku, Plan9, Redux, FreeDOS, TempleOS, AROS, Mac OS classic, etc.

Also, as I did previously with Space Invaders, it's possible to create your own framework using only Xlib and C language.
Or you can use GLFW for windowing and controls and build everything else yourself.
Just like I did in all my programming language reviews.
However, most people outside the demoscene don't do that.

Difference Between Frameworks and Engines

On job boards, it's common to see "framework" and "engine" used interchangeably.
This is about as correct as calling a bicycle a truck.

A bicycle gives you wheels and handlebars to move faster and steer in a specific direction, but a truck provides many things a bicycle doesn't: an interior, a motor, space to carry cargo, seats for other people, multiple speed options, etc.
The same applies to game development.

A framework provides a cross-platform way to create windows, render OpenGL or Vulkan graphics inside them, and offers convenient features like input, cross-platform audio libraries, FPS counters, file systems, networking, UI systems, asset managers, etc.
A game engine provides all of that, but adds script editors, scene handlers, level editors, physics engines, platform abstraction layers, and more.

A framework is basically a bundle of abstraction layers stacked on top of the low-level SDK of the platform you're working on.
Therefore, instead of manually setting up WinAPI or X11, you can get an empty window by calling just one or a few functions.

A game engine is another abstraction layer stacked on top of the framework, but it adds physics engines, editors, scripting languages, asset managers, etc.
Of course, when creating your own engine, you can choose which features to include and which to exclude.
For example, I chose not to have a scripting language, and the editor runs on top of the runtime and is only available in debug builds.
I want to keep it as lean as possible so more development time and hardware resources can be allocated to the game itself.

Another difference to remember is that game engines should reflect the intended game design, while frameworks should be kept as generic as possible.
This is why it's common to use the same engine for game sequels or new games with similar mechanics, but frameworks remain the same across multiple genres.

Unity and Godot slightly distort this by being general-purpose engines.
Unreal Engine is now trying to do the same, but it originally started as Epic Games' first-person shooter engine, and before that it was exclusive to Unreal Tournament.
This is why Unreal often struggles with genres it wasn't intended for, while Unity and Godot do not — the latter two were designed as general-purpose engines from the beginning.

Therefore, in a sense, it's understandable that corporate managers and recruiters often confuse "engine" and "framework."

Console

In the case of consoles, this is much more harmonized.
C++ is the only choice, you must use the SDK provided by the platform holder, and you must use the platform holder's store.
The only freedom is in choosing the framework.
However, in most cases there is no favorite framework available, so you're highly likely to create your own.

On DS, you had to create your own framework from scratch, but on Wii, 3DS, Wii U, Switch, and Switch 2 you can use NintendoWare.
NintendoWare is the framework that Nintendo uses for its own flagship games and also provides to partner companies.

This is a good example to mention.
NintendoWare is a framework, but NintendoWare Bezel Engine is a full game engine built on top of NintendoWare that also implements Lua for scripting and PhysX for physics, which the framework itself does not have.

The advantage of consoles is that even if you create your own framework, you can continue using it throughout the entire console lifespan.
Creating a custom framework alone can take about 1-2 years depending on the platform.
Once the framework is complete, you then have to make the game.
Because the framework itself is not a commercial game, but a toolchain that can be reused for all subsequent projects.

On Switch and Switch 2, we are actually running two approaches in parallel: using NintendoWare and creating our own framework.
The reason is that using NintendoWare allows us to reach commercial games faster, while our own framework lets us master the platform.

NintendoWare is advertised as a very thin layer, but it pre-implements many details that would need to be implemented yourself in a custom framework.
For example, it provides access to highly optimized proprietary file formats for Nintendo systems.
In a custom framework, you would have to manually implement support for JPEG, PNG, glTF, WAV, etc. yourself.
Of course you can use stb_image or tiny_gltf, but implementing them yourself gives you a much deeper understanding of how these file formats actually work, which I consider extremely valuable.

The biggest difference is that when using NintendoWare you can immediately enter the game engine development phase, whereas with a custom framework you first have to build that and then create the game engine.
As I said before, game engines should reflect the intended game design.

Many people think that making a game engine is extremely painful and takes 10 years.
In reality, it depends on the game design.
If it's a simple Snake or Pong clone, you can easily make the game + game engine in 30 minutes to 4 hours.
If you're trying to make something on the scale of FF7 Remake, the engine alone will actually take years and require many people.

This is why our strategy is to work on one large project and several small projects simultaneously.
This allows us to put a lot of effort into the large project while releasing small indie-style games on the eShop in a short time.

On the 076 Studio website, we recently revealed that "SB" means "Spacebeast".
This is not the final name but the codename for the large project.
The reason for doing so is that the project has progressed enough that we're confident it won't be canceled, but it's still too early to show the game itself.
We allow the community to speculate about the game's content.
However, once the game is ready to be announced, I think the meaning of "indie game" will change.

I'm very proud of it, so it's unfortunate that I can't talk about it much yet.
But at this stage there's no point in releasing it.
Because all you would see is one animated model and everything else being simple static placeholder assets.
Most of the current work is system-level implementation and art creation.
A lot of time is being spent on implementing one specific feature and its art.
Doing it properly will take even more time.

Initial Production Pipeline

In the engine phase, we are mainly creating collision detection, physics engine, scene loader, camera system, VFX system, and ways to manipulate assets.
At the same time, we usually also develop the game after the initial stages of the engine are implemented.
At first, the game consists only of simple scenes to test whether the implementation works.
In the game industry, this is called a "test stage".

In many cases, we create multiple test stages rather than just one.
This is to test many different mechanics without bloating a single test level.

After that, we create all the scenes planned for the game, but using simple primitives, simple materials, and simple textures.
Don't be afraid to create scenes that won't be used.
It's very common to have scenes that never make it into the final game.
Also, don't worry about how the stages look.
As long as they roughly look like what you want, it's enough.

This is called "grayboxing", and it's the stage where programming decreases and game design increases.
In large game companies, everything before grayboxing is usually done by the R&D department, and everything after is done by the core game development team.
In our case, since I'm completely alone, I'm essentially both the R&D department and the core game development team.

After that, gameplay programmers and artists start working, with artists creating final assets (corrections are possible), and programmers writing scripts for those assets.
However, only the first few stages are prepared and finalized, while the rest remain in placeholder state for now.
This is called "beautiful corner".

This is usually shown as a pitch for the game to the president, investors, publishers, etc., and needs to be approved.
The studio can choose whether to use these scenes as a small teaser for magazines or the company blog.
This is also why so-called "beta content" is born.
Because what is shown in early screenshots is very often different from the final product.
The differences can range from minor to major.

However, recently games tend to be announced at much later stages, so while pre-release games in the 1990s were often completely different from the final game, today's pre-release games are often almost identical to the final game.
This is not because planning has improved dramatically over time, but because announcements are happening closer to the release date.
Of course, each company can freely decide when to announce their game, so it doesn't mean very early prototype screenshots will never be seen again.

Basic Overview

Therefore, the general point is that games made from scratch are created like this:

1. Choose the platform's SDK
2. Build a framework on top of the SDK's API calls
3. Create a Game Design Document (GDD)
4. Build the engine on top of the framework while keeping the GDD in mind
5. Build the game while building the engine
6. Complete the game

If the game is made with an existing framework, steps 1 and 2 are likely minimized or completely omitted depending on the framework.
For people using game engines, steps 1, 2, and 4 are completely omitted, and step 5 is minimized to just "build the game".

It is possible to modify the source code of Unreal Engine and Godot to suit your needs, but not with Unity.
Because among the above three, only Unity is completely closed source.

I have internal documents prepared to teach new employees step-by-step how to create their own frameworks and engines from scratch with guidance.
However, I plan to rewrite them for PC game development and publish them on this blog without violating any NDAs.
The internal documents are almost the same but are adjusted for Switch and Switch 2 game development, so they cannot be legally published on this blog.

The intention of the upcoming tutorial series is to preserve low-level knowledge that is increasingly being lost in this era, and to have public resources for people who are interested in joining our company in the future.
We expect to start hiring within 2 years, so if you want to join early, there is still enough time to learn the necessary skills.

That's all