Securing Urho3D's future

Awesome, I believe I may be of some assistance.
Thanks for the issues link - that’s where I need to start!

I’ve recently moved from Windows to Linux, and it’s been decades since I touched a Unix-based OS, so I am on the back foot, and especially with regard to my toolchain - looking forward to contributing!

1 Like

Ugh, I got off to a bad start :frowning:
Today I patched issue #2352, then set up a github fork, uploaded my changed files ready to issue a pull request, and discovered that my project files, and the issue itself, were redundant.
Somebody needs to update the archive download links on the homepage (maybe just redirect to github master?), and curate the Open Issues for redundancy with respect to any wholesale changes that have occurred over the past year (such as the network system being replaced).

I’ll bring my files up to date now, and then take another look at the Issues :slight_smile:

1 Like

With the latest files pulled from the github master, I see that the problem in Networking still exists.
Essentially, the problem is that the Connection class is gathering the IDs of dirty nodes in an UNORDERED CONTAINER (HashSet) … this means that Clients can recreate nodes in a different order than that in which they were gathered, which spells trouble for reconstructing the node parenting. I believe the remedy is simple - change the container type for HashSet nodesToProcess_ to instead use Vector, which is an ORDERED container. This subtle change requires changes to several other files, and though I did not test the use-case of complex node structures being reconstructed out of order, it did compile very easily, and appears not to affect anything else. If I get time tonight, I’ll port the changes back in, and issue a Pull Request.


14 posts were split to a new topic: P2P Multiplayer


I wanted to add something motivating here. I mean Urho does not look to be unpopular.

I am newcomer and I droped here by looking for an engine to start my game…

Not only that, after making my decision, then I saw this post and thought that I may have to rethink my decision as this engine might not be so popular(that is not being loyal i know). But after remaking again my research dropped again here by the good comments found around the web.

Despite there are 2 weeks of hard learning curve(if it is your first game engine) is amazing what you achieve after that, and it is less than a month since my first post here…


Hi urnenfeld!

I did not mean to cast aspersions on Urho3D, but rather offer insight into a known bug.
Game engines are complicated, and I’ve never met one that did not have outright bugs or special corner-cases, including the major ones. One big difference between major engines, and urho, is that I can offer back my fixes to problems, and once vetted, see them released in public form, rather than selling solutions to engine issues.
I merely offered some information about the fix for one such bug, which I offered back to the community in my first week here (the code for the fix was issued as a “pull request” on our github master branch). I’m a mechanic, of sorts.

Urho3D is fairly mature, there’s not a whole lot that needs to be remedied in the engine, and I’m still learning parts of it a month from meeting the beast. There’s a lot to take in!

Hi @Leith !

Oh sure no, my reply was strictly going to the main topic about engine’s future & popularity.

1 Like

We’ve recently seen some efforts into a Vulkan renderer, which opens immense possibilities for optimized rendering (OpenGL was designed for most stuff to be executed by whatever thread owns the opengl context - although context sharing is possible across threads, its a headache and a performance bottleneck! Vulkan promises a smoother way to allow multiple threads to issue graphics calls). We’ve updated the networking system. There is a C# branch. We have a build for Android. But there is no clear direction ahead as far as I can tell - at this point, it’s more like we rely on the input of our users, because there is no lead developer. Cadaver still drops in from time to time to check on whats going on, but there is no round table, just a bunch of enthusiast contributors. Kind of like Ubuntu Linux. Anyone can complain about stuff and offer a remedy, through the correct channels, which will be vetted by a jury of peers.

I’ve come over to Urho via UrhoSharp and just wanna share my 2c. :slight_smile:

One of the biggest reasons I’ve decided to use UrhoSharp for my current project is because there is a startling lack of code-first C# game engines. Most C# engines out there are heavily editor-based - Xenko, Banshee, Wave, Unity and more recently Godot, with only MonoGame and UrhoSharp holding the line for code-first alternatives.

Editor based engines are usually easier to learn for non-programmers, but it has its drawbacks. The details of said drawbacks are probably for another discussion, but suffice to say developers who prefer doing most of their work in a text-based IDE like Visual Studio are left with very little options.

This is where UrhoSharp really shines. While MonoGame is very popular, it’s primarily known for it’s 2D capabilities, UrhoSharp on the other hand, is positioned as a mature 3D game engine. On top of that, Xamarin’s done a pretty good job creating easy to understand references and examples on its site to guide new users along. This is great for self-taught developers like myself (started from Gamemaker > Processing > Basic Java > Unity > UrhoSharp), who are warming up to C# because it’s easy to learn, yet powerful enough for most game projects.

The biggest problem is, UrhoSharp’s community is very young, with a lot more people asking questions than answering them. I found a lot of the answers to my questions here on the Urho3D forums instead and after the initial bumping around in the dark, I’m getting really comfortable with the engine and using it to prototype other ideas of mine on a daily basis.

I’m not sure, technically, what is the future of Urho3D, but I do know that it has its strengths. I guess I’m also hoping that we can bring the Urho3D and UrhoSharp communities closer a little so they don’t seem like entirely different projects.

1 Like

My hope is people will stop using/creating spyware and code-injecting IDEs like VS. When it comes to Urho my greatest fear may be for C# to be introduced to this project. I’d call for a fork.

I understand C# has a reputation of being easy to learn despite my personal opinion that most of the differences with C++ make it absolutely illogical, confusing and frustrating. When I’m helping out C# coders it is because I hope to increase the chances of them converting to reason, not because I want to support their current behavior.

For people that both like Urho3D and C# there’s - apart from UrhoSharp - @rku’s “rebel fork” now called rbfx.


I see. I think coming from a C++ coder’s perspective, what you said makes sense.

I’m not really a coder, my background is in fine arts, but I’ve been a game designer for about 12 years, and have recently gone indie. I’ve tried C++ before, but can never quite understand it.

I think coming from a blank slate like me, managed languages like C# and Python are a godsend. It eases a lot of the initial learning curve.

I don’t think there’s any shame in writing inefficient software to start with.

Like Donald Knuth once wrote:

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

I believe the adoption of a garbage collector to be an unwise optimization short-cut on the path to knowing what you’re doing. Simply avoid (or misuse) pointers until you’re forced to use them properly, and maybe try to understand const T& first. Similarly the existence of template metaprogramming should not be a reason to stick to assembly. Leaked memory is not obliterated, it will be released on the termination of your program.

@Barefists Have you tried AngelScript, btw?

1 Like

Count me in.

Count me in.

fuck donald knuth - did he demote his teachers when he was eight years old? you are surrounded by true friends now, welcome to our world - i still feel unsafe, but i am wearing running shoes

Yep! I messed with the Angelscript bindings a little, they we’re quite easy to understand. But I’m using Ink for my current project, which only has a C# runtime.

I’ll try out Angelscript proper for my next project! :smiley:


angelscript is mostly your friend, there will come times when its your enemy, im here for you

1 Like

I see, didn’t know about this ink thing. Last time I’ve inquired about those things I’ve managed to found this twine here…

It’s pretty neat, it’s most famously used to write Inkle Studio’s own 80 Days and Heaven’s Vault, and also Stoic’s Banner Saga 1 and 2, amongst other smaller indie titles.

Makes writing interactive stories very simple, and can plug easily right into any game engine, provided the runtime is implemented. Inkle Studios only provides the C# runtime, it’s the one they use for their own titles.