Godot Port Update #6

Porting stats
Porting progress: ~60%
Hours with Godot: ~382h
Scripts transferred: 61
3D-assets transferred: 48
Audio files transferred: 169
Godot project size: 11.9GB

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?

- Clothing system
- Item hover tooltip
- Item use / consume
- Item fast equip
- Item fast unequip
- Character preview equip
- Grid stats calculations
- Item drop from empty area
- Equipment slot size variations
- Improved item physics
- Initial medical system

Inventory system completed

When I started this porting process, I knew that there are going to be few big hurdles and one of those was porting the inventory system and the entire item architecture.

Inventory system are one of the most complicated features within a game, they contain multiple sub-features, they must scale along with the item database and most importantly they should be designed in a way that they are easy to understand and debug.

This week I finished the inventory system and added the main missing features from last week. This current inventory is now pretty much production ready for the upcoming demo and generally I'm really happy with the end result.

+50% ported

Since now the inventory system is ready, I can confidently say that more than half of the project features are now ported, which is a great milestone for me personally.

There's now clearly light at the end of this porting tunnel and I'm really excited that next month this entire porting process will be completed if there are no surprises.

There's basically only two main features left (AI and attachment system) and after that it's just drag and dropping the remaining 3D-assets to right places.

AI

Even though I'm pretty optimistic now with the porting timeline, there's still one "scary" porting left and that's the AI and "humanoid" animations that related to AI's behavior.

I think AI is the only thing left that could potentially provide those unwanted surprises since I already know that attachment system and rest of the small features are not that trivial for Godot.

I will start porting the AI tomorrow and I would consider that it's a one week task to get it fully working with this new engine. The biggest mystery for me is still nuances related to Godot's pathfinding meshes and AI agents, but I will know answers to these in the next port update post.

Experimental features (FSR 2.2)

Few days ago, I had a little bit of fun with Godot's latest beta build (4.2). I mostly wanted to test the new FSR 2.2 upscaling that introduced TAA-like temporal features.

I'm especially interested about this upscaling feature since there's currently no working AA-solution for alpha-cut elements in Godot. Godot's TAA is unusable for FPS projects and every other method is either too expensive or there's some other major drawback.

When I was testing this FSR 2.2 it was pretty rollercoaster ride in terms of feelings. First it almost provided that high-quality TAA and smoothed all the main alpha-cut elements (grass, trees) but then the problems started to show.

The first problem is that FRS 2.2 seems to basically just do one large "get all motion vectors" pass and then it adds that temporal element on top of everything. In paper this sounds fine, but in FPS games this becomes quickly quite problematic since there are a lot of elements where you don't want any temporal effects.

One of these elements are weapon optics, especially red dot sights and other optics that contain small transparent reticle textures. If those reticles are "anti-aliased" with TAA-fashion, the headache is pretty certain thing after long play session since those sight pictures and reticles will have nasty micro movements and blurriness based on your camera movement.

I don't know if there's a way to exclude some of those motion vectors (from optics) or modify the FSR to run per object basis, then it would be pretty magical feature for this project but unless there's those options, it's unfortunately quite unusable for FPS games with realistic optics.

This "TAA topic" can be addressed in multiple ways in the future and one of those ways is simply to implement a custom TAA solution specifically for this game through certain shader tricks and masking.

I still hope that some next FSR version will provide those per-object basis options or Godot will introduce some native solution to this, but I'm mentally (and financially) prepared to implement or hire some external contractor for this purpose since it's the only "visual quality bottleneck" left for this project while using Godot.

First curse words with Godot

Disclaimer: Consider this part of post more of a joke than actual problem :)

It's relatively easy to have small "bad moments" with game engines every now and then, stuff breaks and there's all kinds of small surprises no matter what game engine you use.

My first "bad moment" with Godot happened yesterday. I had been preparing this upcoming "from Unity to Godot" article for a multiple weeks now and I have consistently taken screenshots for this article to document the entire process.

I had taken these screenshots with normal windows print screen method (since they should work with every software...) and yesterday when I was starting to organize those screenshots, I found out that I only had a folder filled with hundreds of images of my project splash / loading screen.

When I found out that Godot does not support normal windows print screens or there's some other weird bug related to how Godot handles fullscreen applications, I may have slipt few nasty words towards Godot since I lost huge amount of cool documentation material for this article.

I learned one lesson from this. Never trust that print screen works with all software and checking few test screenshots first at the beginning would have been pretty wise thing to do...

I'm now once again peace with Godot after the "moment" and I implemented a custom screenshot tool for these kinds of purposes :)

- Antti