Godot Port Update #1

Porting stats
Porting progress: ~10%
Hours with Godot: ~110h
Scripts transferred: 24
3D-assets transferred: 16
Audio files transferred: 32
Godot project size: 5.62GB

What are these Godot Port Updates?

Porting a game to another engine is a big and rather unique thing, so these post are my way of documenting this porting experience and giving some honest updates on how the porting process is going.

These posts are a weekly thing until all the core features have been ported and along with these posts there are also Patreon test builds each week. These test builds are directed to small audience and the main purpose is to get performance data and early feedback on the ported features.

Why Godot?

Let's start this first port update with a quick reasoning on why I decided to switch from Unity to Godot. The main situation is explained in the "New Beginning" video on Road to Vostok YT-channel, but here's some main reasons in a short form.

1. Long-term brand damage for Unity is scary, it created uncertainty and multiple negative side effects that I don't want to deal with. I want to focus on game development, have fun while doing that and not worry about some company's decision making, future financial situation etc.

2. When it comes to development cycle, this project was still in a reasonable "port window" which means that porting the game to another engine was still a possibility and strategic option without any major setbacks (financial/time).

3. I really like Godot. I like the open-source nature, potential, ecosystem and simple yet effective engine editor that works for this game idea. Godot is not Unity replacement and it should not be, it's a different engine with different workflows and those fit nicely for this project and my preferred ways of developing games.

First impressions

After using Godot now for +100h, I think I understand the engine well enough to give some first impressions and initial thoughts.

Godot is simple, nimble and minimalistic when it comes to game engines. There's less buttons to toggle, less features to play with but sometimes less can me more. When you have an engine that is simple, there's generally less stuff to learn, less stuff to be confused about and most likely less stuff that can break or cause unexpected problems. Godot has its own thing going with simple nodes (everything is pretty much a node), it works and it makes sense.

Godot doesn't need to challenge Unity or Unreal when it comes advanced features and tech innovations. I would any day take a solid engine with polished core features than an engine that offers everything and most of the stuff is experimental or constantly changing.

This topic has always been one of the main problems with Unity in recent years. Unity has introduced different rendering pipelines, acquired numerous of new technologies and spent huge amount resources on providing highly experimental non-production ready features. This mindset (most likely) comes from trying to compete with Unreal and trying to remain "relevant" state of art game engine and show investors some rapid growth tech company potential.

While competition is a good thing in every industry, everything doesn't need to be state of art, most developers just want useful tools, good resources to learn from and platforms that support their creativity. I think Godot does a good job of providing these based on my first impressions.

Minor Painpoints

When it comes to stability and daily usage for long-term game projects like Road to Vostok Godot can be surprising every now and then. Sometimes there's weird stuff happening with the importer when you're handling assets, sometimes there's bugs which appear and disappear without any understandable logic and sometimes there's just crashes and the whole thing suddenly shuts down. There have been maybe 3-4 crashes so far but either it's luck or Godot does something cool with auto file saving since there were few crashes that would have definitely lead to losing some progression in Unity, but in Godot everything remained there magically even without saving.

These stability issues are minor, they are not "dealbreakers" and I actually already faced these when I did the initial testing phase with Godot, so let's just say that there's certain things that you learn to avoid of doing in order to maximize the stability. For example dragging a 4K HDR skybox file around the editor rapidly is not a good idea, better to manually assign/load it through dedicated button.

There's still plenty of stuff for me to learn about the engine and correct way to do things, but  there are some minor development "routine issues" that are not related to developer skills or engine knowledge. One practical example of these is that renaming, moving or importing stuff is pretty slow and there's some processes that are happening with the importer which take unnormal amount of time (related to normal file transfer).

Game developers handle hundreds of assets / files / folders on daily basis so if you have small delays here and there the issue cumulates quite fast because the sheer amount of similar operations happening every day. I think there's one simple way to polish all these minor painpoints and improve the main workflow. The solution is the same that Unity should have used and that's to make a medium-sized game project with your own engine.

This means that Godot Foundation / feature owners / open-source contributors should make some kind of collective development team and effort to build a medium-sized game (3-6 months production cycle) in order to feel those daily routines and cumulative time sinks in a real game development environment. Even though it's time consuming and takes effort it's easily the best way to understand and polish the core features and those routine based nyanses. This collective game project would also act as a marketing tool and learning resource, so I strongly believe it would be worth the effort.

Can Godot handle realistic 3D?

Short answer is yes. Can Godot handle large open-worlds, chunk loading and high-polycount environments, I don't know, probably yes but that would require deep level of knowledge about optimizing genre-specific 3D-rendering from the developer and making custom tools to support that.

Godot is not Unreal or Unity when it comes to 3D-rendering, but it has all the core elements and performance to draw semi-detailed environments like in Road to Vostok.

My way of making game art is based on low-medium polycount models, simple photo textures without PBR (physically based rendering) workflows and fairly compact individual levels, so this project is not the ultimate 3D stress test for Godot.

I think realistic 3D is kind of twisted concept in many ways when it comes to game engines. Many people think that Godot can't handle that and there's weird narrative around that Godot is reliable for only 2D-games and hobbyist in general.

In terms of visuals, let's go through what core elements needs to be in place or happen in order to support 3D rendering:

- XYZ coordinates (Z-axis provides depth, meaning the 3th dimension)
- Drawing bunch of vertex points (polygons) to XYZ coordinates
- Using shaders that tell the color of individual pixel on your screen.
- Support for lights, shadows, reflections and additional effects.
- Camera that can render these elements within it's 3D view frustum.
- Audio sources, positional / directional audio for 3D scenes.
- General physic calculations to support collision and gravity.
- Optimization for doing render and physics loops/cycles as fast as possible.

All these core elements can be found in Godot and none of these are not even directly linked for supporting realism, since realistic 3D is mostly based on:

- External realistic 3D-assets
- External realistic textures
- Engine parameters, settings and tools to modify the shaders, lighting and effects.
- Visually oriented developer who brings the assets to the scene and modifies the settings.

So, realistic 3D is mostly based on external assets, composition and general setting tweaking to blend various of effects together and that creates a visually pleasing realistic 3D environment inside a game engine.

There's definitely room for improving the 3D rendering in Godot, but in it's current state Godot does not block my attempt or creativity for making realistic 3D-environments to Road to Vostok. In terms of transparency, there's still bunch of unknown for me when it comes to AI-pathfinding and other nyansed 3D-topics, but if there's no out-of-box solution then I just make the solution myself.

When it comes to general 3D-quality feeling and support for multiple genres, I think visually Godot is just missing two things that are mostly effects and not tied to general 3D-rendering process. Things that are visual downgrades and what I miss from Unity are:

- Improved Temporal Anti-aliasing (TAA) with parameters for game-specific customization, sharpening and option to include exclude & include objects / nodes from the TAA (motion vectors).

Currently TAA is unusable for this project (blurs all FPS-animations), but eventually it's the only efficient way to implement antialiasing for alpha-cut nature elements like grass and trees. I had a near perfect solution for this in Unity and I know how much better the TAA can be and how it should be customizable.

One top-tier TAA solution with good anti-ghosting and sharpening can make pretty much all other anti-aliasing techniques unnecessary and that way it also improves the performance a lot, since you don't have to use expensive stuff like x4 / x8 MSAA or SSAA (supersampling) anymore.

- Improved Ambient Occlusion solution (SSAO/HBAO) with better visual stability, overall performance and "stacking" option.

In FPS-games, the best AO approach is to use two different AO solutions at once. One SSAO effect is used with really low radius and this makes the arms and gun models look pretty and other SSAO or HBAO effect is used with larger radius and that's aimed for the environment.

Currently Godot supports only one SSAO approach and for nearby objects like weapons you really have to crank it to absolute max quality to make it decent and visually stable. This is really expensive and then you still don't have anything left for the environment.

In Unity, I had a separate FPS-SSAO and World-SSAO, both running only half resolution, medium samples and the end quality and performance were really good. I know that Godot has a thing called SSIL and other GI/AO parameters to tweak but those will not provide the performance / quality ratio to FPS-games when compared to 2x high-quality SSAO or SSAO + HBAO solution.

One thing to mention in this context is that Godot could also provide much better "initial quality experience" when it comes to 3D game development (especially for beginners). Just by setting few default parameters differently and adding stuff like camera interpolation (without addons or scripting) to remove the movement jitter could improve the starting experience a lot.

Are you happy with the engine choice?

Yes, Godot fits really well for this project and I really believe it's future potential and stability thanks to its open-source approach and community.

Even though this engine switch is a calculated risk and will cost me few months of extra development time, I think this is the right choice for this project and my style of making video games when looking things in a career long timeline.

There's no denying that some things will need a bit of downgrading at first (compared to Unity) but there's bunch of extra upsides that will come through this initial porting experience.

One example of these extra upsides is that you are kind of forcefully going through your entire code base and scripts when porting to another engine. There have been already multiple "I don't know what I was thinking" moments when you found bugs and poor implementations lurking in your code.

For me this whole porting process is like a big house cleaning, it gives a bird's eye view on some of the features and it allows you to make better decision since you have a fresh start and unique ability to learn better ways to do stuff as you're porting your existing solutions.

What's the current porting phase?

Currently, I have rebuild the procedural controller, weapon system and other core features in Godot. I have really tried to port these features with a mentality to improve and learn some of the mistakes that I did back in Unity.

For example, this time I have redesigned multiple system in a way that they are fully frame-rate independent and there's no loosely defined values that can easily cause abstract problems in the future.

For the past week, I have been basically setting up the core elements in a way that they are easy to debug, control and there's a good foundation to continue porting. Most of these tasks are not "visible", they are background work but still really important and they will save time and money in the long-run.

I'm pretty much done with the foundation now and it's time to start bringing the assets into the project and luckily that's the most straightforward job related to porting. I will start rebuilding the first map next week and there should be pretty rapid porting progress when it comes these 3D-environments and general visuals.

The hard part of this porting process will be the inventory system and all the hundreds of small sub-features that are built around that. Luckily there's always options to downgrade and simplify since the working game loop is much more important than some individual fancy features.

Currently I'm really happy with porting progress and I think majority of the porting will be smooth sailing since it's just simple iterative work and requires only time / patience and I have both of those :)

- Antti (Developer)