Pretty much the title, I was wondering if we would be forced to use logs to debug, as I couldn’t see any documentation or way to set it up in UEFN. If that’s the case, is there a timeline for getting the functionality ? It really gets in the way of doing anything coplex 
If Verse’s semantics do at all permit this, I strongly desire the ability to step debug code that I write, whatever the language. It’s just too easy to write logic that does something different than what is intended or for game state to end up in an unintended state. The question, I think, is if Verse’s semantics can even permit step-debugging and variable inspection? If not, then I’m not sure if Verse would be worth using for development tasks outside the scope of programming networked behavior.
It will be possible to do logpoints with snapshot debugging in Verse - though we don’t have an ETA on that functionality for UEFN users yet.
I have a theory on how to do Verse breakpoints with stepwise debugging for UEFN in such a way that even multiple authors could still work together on the same experience with little or no disruption to each other. If this proves possible, it would likely come after snapshot debugging.
Currently, it is debug prints with Print() and similar which are available now. We should be able to increase the manual debugging API (adding specific code to help debug) as well - though no specific ETA on that either.
1 Like
This would be ideal! Even if all we could manage was a step debugging experience that pauses the other players, that would be wonderful!
Personally, I want to be able to utilize Verse as a replacement for most of the current uses of Blueprints. I admit I mostly left Unreal for Unity when support for UnrealScript was dropped. I did not find Blueprints to be a sufficient tool for driving game behavior as they quickly grew too complex for their means of expression and made high-level game behavior too difficult to reason about.
As a functional game programmer (I’m the author of the functional Nu Game Engine), I was even considering experimenting with developing a model-view-update API on top of Verse. The model-view-update approach used in the Nu Game Engine allows you to write your entire game in the style of an Elm program (A Game Engine in the Elm Style! – Vsyncronicity), reducing implementation complexity by about 80-90%.
However, I’m not sure yet that implementing an MVU API on top of Verse would be practical. Perhaps it would be asking too much of the Verse runtime since all of the backing data used to apply model-view synchronization would (presumably) have to be propagated. Additionally we’d need algebraic sum types to make the API very usable. Probably some reflective facilities as well for implementing view diffing. And I’m not sure about how real-time Verse’s GC will be since I don’t know what tech it is based on (presumably Unreal’s existing GC?)
Functional programming with Verse will help us to simplify development for more tasks than just network programming. An MVU on top of Verse would simplify things significantly more (as Nu’s MVU-based programming model demonstrates). Perhaps my ultimate ambition of building an MVU API for Unreal is too much, but if I can just get a small amount of what I want (step-debugging w/ variable inspection), I would jump at the chance to get into Unreal for commercial game work again.