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.

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.

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!


Debugging brings back memories... not always good hahahah