Godot Port Update #2

Porting stats
Porting progress: ~15%
Hours with Godot: ~175h
Scripts transferred: 28
3D-assets transferred: 26
Audio files transferred: 41
Godot project size: 6.84GB

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.

Smooth sailing (so far)

Usually when you make risky decisions like changing a game engine, you calculate the worst scenarios and try to prepare for difficult tasks that might come as surprise for you.

When it comes to porting Road to Vostok, so far there have been only minor painpoints and porting process has actually been quite enjoyable for me. There's still many "scary" porting topics left like the inventory system and AI but so far everything that I have ported has moved quite nicely to this new engine (even with a different scripting language).

What has been ported?

Here's a rough list of the features that I have ported from Unity -> Godot within 2 weeks:

- Procedural FPS controller
- Procedural weapon handling
- Camera interpolation / impulses
- Inertia system
- Recoil system
- Custom audio solution (based on layered instance events)
- Custom billboard solution (rendering optimization)
- Keymapping / keybindings
- Setting menu (WIP)
- Main menu (WIP)
- Bullet decals and cartridges
- Time of day + Skyboxes + Ambients
- Flashlight
- 3 fully animated weapons
- 3 optics with custom RDS / Holographic shaders
- 26 3D-objects with textures / materials
- Custom Lit and Terrain shader
- Footsteps system (WIP)
- Various debug and test scenes

What's going to be ported next?

Currently I'm focused on porting the first map (Village) to Godot in order to set up a realistic playground for the upcoming AI-stuff which needs "challenges" for navigation and obstacle avoidance testing. This first map should be (mostly) ready next week.

Once the first map is ported, next topics will be:

- Initial AI testing (spawning, navigation, sensor)
- Character stats (health, stamina, weight etc.)
- Interaction system (interactables, doors, pickups)
- Looting system (item data, loot tables, loot spawning)

During these main topics, each day I will also transfer "dummy" stuff that won't need any scripting. These are audio files, textures, 3D-assets and so on.

Pipelines and formats

One of the biggest learning curves for this project (currently) has been moving from "industry standard" .fbx files to other formats like .gLTF / .obj which are linked to all 3D-assets and embedded animations.

In theory there shouldn't be any issues with these "open formats" but like everything in game development, there's always nuances and "nice to know" information which you just have to learn.

These new formats need new pipelines and workflows and there's have been quite an interesting lessons learned recently.

Let's take one example. Yesterday I tried to figure out this one visual bug with .gLTF based weapon rigs where the FPS-arms were totally messed up in terms of shading inside the game engine.

In this image, you can see example of the shading issues (right).



After working with one of the Road to Vostok's contractors and transferring .gLTF files back and forward this issues seemed to appear for both of us and required some extra .gLTF investigation (.fbx files had zero issues).

I probably spent few hours of reading Godot's documentation and reading about .gLTF import / export settings. After some time I found out that .gLTF is so called "last-mile format", meaning it's only designed for exporting.

Once you export a .gLTF file it basically "prepares" the mesh for the GPU and on top of basic triangulation it creates stuff like vertex doubles / splitting along the UV seams and multiple other small details that you can't control though export settings.

In this image, you can see for example the "hidden" vertex doubles that .gLTF created along with the UV-seam that caused those some of those shading issues along with few other import / export issues.




This was just one small example and there have been dozens of these "nice to know" format nuances so far, whether it's related to naming conventions, exporting or importing.

These types of things are not bugs, they are just format behaviors and there's no common "warnings" about these when you are watching tutorials or reading documentations, you just have to learn these as you go and arrange your new pipelines and workflows related to transferring assets between contractors or different tools.

Debug / template / benchmark scenes (FPS)

Every engine has feature limitations, unique bugs and characteristics that require different approaches. For example Godot's default character controller component / node is quite different than Unity's. There's differences in collision detection, physics, general movement settings and so on.

For this purpose the most efficient way of learning and gaining knowledge is usually engine related sample scenes. I have spent a good amount of hours of searching if there are samples / toolkits / stress-test examples in Godot that could be useful for realistic FPS projects like Road to Vostok.

After scavenging multiple sources and projects, I basically only found few old ones that are pretty limited and then few stylistic ones that are not based on realistic weapons or realistic visual style.

So because of this lack of FPS samples, one of the first things that implemented when I decided to move to Godot was to make those sample scenes myself. I made multiple debug, benchmark and stress-test scenes that are especially designed around FPS-genres common problems.

I made these debug scenes for movement, physics, recoil, rendering, optics, lighting and all those main topics that are interesting for developers who might consider Godot's "suitability" for their realistic FPS-project.

Here's one small general example of the movement debug scene that I also added to these Godot test builds that I share here on Patreon each week during this porting process.



These are nothing super fancy but they are really helpful for acquiring that knowledge about the default engine features, potential or possible limitations.

Related to this, I sent few messages to one of the Godot's creators and mentioned that I have these FPS stress-test scenes available if needed. I don't yet fully understand how Godot's open-source ecosystem works for stuff like this or who should I contact, but I would be more than happy to share some of these scenes and test features for other developers or people generally interested in Godot's potential.

Whether it's rendering benchmarks or general FPS features, I think it would be a win-win situation if there was an easy to understand and high-quality FPS-template / stress-test scenes publicly available with realistic visuals since those would be beneficial for Godot and also for this project since others could find those unique FPS solutions from those.

This method worked extremely well in Unity's community since there were multiple "enhanced" character controllers and "extended" FPS features invented based on those original templates and they worked as a starting point for many cool assets and genre-specific addons that many developers and even big studios used (and still use) with that engine.

I also personally know that there are hundreds of developers who are currently considering Godot for their projects and one of main reputation problems with Godot is that many consider that this engine can't handle realistic FPS games like Road to Vostok. I have noticed this reputation thing on daily basis, because I get constantly messages and emails pointing out how I chose the wrong engine, how Godot can't support realistic FPS-games and many other unreasonable / unfair claims (based on my initial experience).

This is a weird stigma for Godot, I don't where they acquired this reputation, there might be something that I don't know about this engine's history or previous versions but the current version can definitely handle 3D and FPS-projects without any major problems.

This is becoming a bit off-topic from my porting update, but related to this context I still want to mention that Godot is currently making it's own benchmark scenes / benchmark server with the community but what I quickly read about those (GitHub), they are quite detail-oriented and not genre-specific. So, I still believe that Godot really needs visually appealing and genre tailored test scenes / templates on top of those optimization benchmarks.

It's much easier to "sell" the engine potential through something visually, when you can just play and see how it could behave for your game idea.

But it's awesome that Godot is developing those "internal" benchmarks since otherwise it's really hard to compare the optimization and performance changes, so those are definitely needed in order to standardize the results.

Quality over quantity

Final thing that I want to add to this port update is that I have taken a bit different approach towards building this game on Godot than I did with Unity. This porting process and "project restart" gives an unique possibility to learn from my previous mistakes, so I will definitely want to utilize this opportunity.

When it comes to game design and feature "implementation order",  in Unity I had tons of "extra features" and "nice to have" things before I even had a solid game loop ready. There were over 25 weapons (without animations) and probably +20 different attachments and stuff that are totally unnecessary until you have a working and enjoyable game loop.

I'm definitely interested of adding all those weapons and attachments back eventually (and more) but there's one core lesson that I learned from the Unity version. When it comes to FPS-genre there's multiple cumulative timesinks that activate when you start increasing the amount of weapons because they are one of the core elements of the project.

More weapons / attachments = more potential animations
More weapons / attachments = more weapon sounds
More weapons / attachments = more UI-stuff and icons
More weapons / attachments = more shaders and effects
More weapons / attachments = more bugs to fix

and so on.

So having a reasonable amount of weapons at first will release a huge amount of development time to other important elements like AI and achieving enjoyable core game loop which is a goal for that Public Demo 2.

So in terms of quality over quantity, I will have more weapons fully animated and "production-ready" compared to tons of "demo" weapons. This mentality is useful for other topics as well and I think it's wise choice, because it's not about "cutting stuff out" it's just using different "implementation order" until there's a solid game loop.

Next test build + devlog

Godot Test Build #2 will be shared on Monday.

Exited to hear your feedback and comparisons related to last build, especially related to the movement and weapon improvements.

I'm also planning to make a first Godot-themed devlog at the end of this month. This video will showcase some those behind the scenes test scenes and general progression with the engine.

- Antti (Developer)