top of page

Consider donating to help me bring Vessel to life!

Handling a QA-less Development #2

  • Feb 20
  • 2 min read

Last week we started this series where I aim to explain how we turned Vessel from a project that requires thoughts and prayers to exist to one that just needs some considerations. Up to the date we already presented feature flags and our crash early policy and why both are helpful at the moment for the project. That basically covers how we secure our work capability and software set up health. Today I will present how we are checking the runtime correctness. 


Debugging by default


Since QA doesn’t exist at the moment, the code team needs to ensure it can demonstrate the things are working as intended. In order to do that, we add debugging information by default. This might be kind of shocking if you are very junior or a non technical person but debugging shouldn’t be added once something fails but to ensure that something works as we intended.


Debugging meaningfully


Similarly to what happens with crashes, a debug information that isn’t clear it’s not only useless but another stone in the way. Every useless or cryptic message prevents your team from using these tools because they create inconvenience. Therefore, how can we ensure that we are showing meaningful information? Well usually the issue is not the information itself but how we present it. Almost all modern game engines allow filtering the debug information into categories and verbosity levels. And most important, all of them allow drawing information in the game world. So it’s really important to know the tools and use them properly to make sure any needed information is accessible and easily readable.


No one wants to scroll through infinite messages in a log file to find cryptic values unless there is no other option. For example, a designer won’t spend any minute navigating a log trying to understand which of the messages describes a bullet trajectory but they will love to see that same information drawn as an arrow inside the game world. 


Debugging Vessel  


In Vessel we are leveraging Unreal Engine 5 capabilities as much as we can. Specifically we are using the visual debugger tool extensively. This allows us to structure the information packed by feature or component, define different verbosity levels, and see it on a frame base time-line which allows us to follow the game execution frame by frame. 


Unreal Engine 5 Visual Logger Tool
Unreal Engine 5 Visual Logger Tool

These kinds of tools are extremely powerful, and Unreal comes with few of them out of the box. While this one is mostly intended for custom information, there are also specialized ones like the Rewind debugger for animations or Chaos visual debugger for physics. This is one of the main reasons we choose this tool.


Unreal Engine 5 Rewind Debugger Tool
Unreal Engine 5 Rewind Debugger Tool

In future posts I will talk about how we are future proofing  our code and our testing strategies.After that I will present you a system of Vessel as a full example of those techniques in action. Which one are you most curious about? Stay tuned for the next entries! Please share the post, drop a like, and if you like this type of content consider donating to help keep this page alive!


2 Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
DarkGreteus
Feb 20
Rated 5 out of 5 stars.

Debugging brings back memories... not always good hahahah

Like
Rickperros
Rickperros
Feb 23
Replying to

Hahahahaha that sounds exactly as a thing someone said when only debugs when issues arise! At that point you chasing and building systems to understand what is happening, debugging by default allows you to openly read the program before it gets complex, it is way less painful!

Like

Don't miss anything

Thank you for subscribing

Consider donating to help me bring Vessel to life!

Creativity works better in community
Get in touch!

Thank you for reaching out!

© 2025 all rights reserved

bottom of page