Godot Port Update #3

Porting stats
Porting progress: ~25%
Hours with Godot: ~228h
Scripts transferred: 36
3D-assets transferred: 33
Audio files transferred: 78
Godot project size: 9.29GB

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.

What has been ported this week?

- Interaction system
- Interaction types
- Interaction tooltip
- Doors and window scripts
- Surface detection & masks
- Bullet SFX & impacts
- Custom building / interior tools
- Global illumination (experimental)
- Transition system (level manager)
- Splatmap & decal shaders
- Flashlight improvements
- Makarov + animations
- 3D props and common materials

Godot skills are improving

Productivity and being efficient with your development tools are really important when you're a solo developer and working on a large scale project like Road to Vostok.

This week I noticed significant increase in terms of productivity since scripting and handling Godot's editor is starting to feel "natural" and there's less and less need for tutorials or reading the documentation.

Unity felt almost like an arm extension for me, Godot is not quite there yet but my Godot skills are improving really fast and every week there's more discoveries and elegant ways to approach some porting problems.

I think this whole Unity to Godot port falls under the category "getting out of the comfort zone" and whenever this happens there's usually bunch of improvements when it comes to your personal skills as a developer.

In terms of programming, project management and game design, I truly feel like I have gained some new skills through this initial porting process and multiple ways to approach game development in a way that is more modular, smart and not engine-specific.

Asset management

Since these port updates are all about transparency, I would like to highlight one painpoint that has been my main issue with Godot so far and that's the asset management / importer.

Like mentioned in the first update, game developers handle hundreds of assets / files / folders on daily basis and all this happens around the engine's importer and asset management system.

In a perfect world asset management should work like in Windows, you drag and drop stuff, rename, move, assign and everything just works fast and reliably. I think this is one of the Unity's upsides that its importer and asset management worked pretty flawlessly, so you didn't even think about these topics since there weren't any issues.

Well, Godot is a bit different in this area. I'm not sure if I'm missing some important knowledge but for me it almost seems like Godot is constantly referencing assets on "absolute path" format, meaning there's a hard reference to some specific folders, assets and whenever you move or rename stuff that path needs to be "rescanned" since the editor is constantly loading and reimporting stuff once you make those changes.

Related to asset management, here's some of the Godot's common alerts and loading screens that happen on daily basis when you are handling hundreds of assets with your project.

There's of course some level of loading required each time when you rename or move your assets but it's easily x5 slower than in Unity and there's some major load errors that also lead to crashing the engine (just by moving stuff around the folders).

In order to avoid spending time on these loading screens and load errors, I have learned to consider the file structures before hand as much as possible and reduce those renaming situation overall. I think this way of working is not ideal since you lose some fast-paced testing / debugging when it comes to iterating with different assets, but for me it's the easy solution to this problem.

I do have to say one good thing about Godot in this context. I had one fatal crash this week (because I renamed and moved a terrain scene file) and I wasn't able to open my main sandbox scene after that because of this file path error.

I was really close to recovering the whole project though backup files but I found out that Godot has basically an internal "safe-mode" window for fixing the path errors called "Edit Dependencies" which allowed me to fix those errors manually without opening the actual file / scene.

I think this kind of editor tool is a really nice "safeguard" but I'm still taking multiple daily backups if there's a situation that some of those path errors would lead to possibly corrupting some files etc.

Disclaimer: I consider these load errors and importer "limitations" to be fairly minor still, they don't make working with Godot slow or unenjoyable, they are just routine things and I believe that this asset management experience can be easily improved in the future.

Visuals are good (IMO)

When it comes to comparing Unity's and Godot's 3D visuals, I think Godot is putting up a good fight even though the comparison isn't that fair yet since I don't have all the assets and visual features yet implemented in Godot.

Here's one example screenshot of the current visuals (Godot).

I think after I have this first map (Village) fully ported and few visual features added like custom time of day LUT's, I can provide good before and after comparisons, but so far I personally like the visuals that I currently have with Godot.

Only major thing that is still missing is that high-quality TAA solution (with options) since that's the bottleneck for making the alpha-cut nature elements look more smooth (grass / trees).

I do have to test the Godot 4.2 Beta FSR 2.2 (upscaler) if that would help with this issue but so far all the nature elements are without any anti-aliasing and totally static since I don't want to highlight the aliasing issue by moving them with wind etc.

Porting ~1/4 done

This week I implemented the interaction system which cover multiple sub-features and was one of the core features for this port. Now when this interaction is done, there's five major systems still left before the next demo with Godot which are:

- Inventory system
- Attachment system
- Character & Stats
- AI & Pathfinding
- Save system

There's of course bunch of assets and props still missing to remake those existing maps but that's the most straightforward thing to port and doesn't require that much effort since it's just a matter of importing stuff and moving them to correct positions.

In terms of porting progress, I think that I'm still quite confidently in that 2-3 month port timeline that I calculated for this entire thing. If there are no surprises, the next demo with Godot should be playable at the end of this year.

- Antti (Developer)