Securing Urho3D's future

From the game developer point of view i don’t think so.If you want to use Unity and C# i’m cool with that.But if you’re a c++ programmer and work in a small team (perhaps alone like i do) AngelScript is a dream come true.
baiscally it’s a script version of c++ so you dont waste time to learn another language and follow tutorials and you can focus on the game and content.Semantilcally they’re so similar that after 1 day of practicing you’re ready to write absolutely complex scripts.I chose Urho3d because :

  1. It’s written in c++
  2. Scripting doesn’t force you to learn a new language
  3. It has a clean and well designed interface.

As i see there are people in this forum who intentionally want to turn Urho into a “better” Unity.If that’s the case then count me out.


As i see there are people in this forum who intentionally want to turn Urho into a “better” Unity.If that’s the case then count me out.

Who talked about unity ? Urho and Unity are two completely different engines

You guys sounds like you have a problem with C#, which is understandable but it is not my point anyway

What i meant is focus on what works now and improve what needs to be improved, AS is just a burden for maintenance, and having to expose API for scripting for each contribution is even more of a burden

Project should be split in multiple parts: Core, Scipting API, what ever language implementation, a bit like how Godot manages it


In fact, Unity engine’s architecture is the best, it exports well documented APIs to all script languages, and you can write add-ons with many languages, such as C, C++, etc.

The only shortcoming is that it does not let you write codes with C++, which may cause performance dropping.

Though C++ is my favorite language, I’d like to see Urho engine automatically exports its APIs to all script languages.

The success of Unity has told us one important fact: Users like script languages.

This is all good stuff IMHO.

Urho is already quite usable as a general C++ engine, but keep adding small, useful features, depreciate any bloat, and resist the temptation to go too wide and its future should be safe

1 Like

Everything is so reasonably stable and feature complete (to at least some baseline) that I don’t see fragmentation or death coming anytime soon.

There’s also still enough low hanging fruit for current and future contributors to latch onto to get a reign on things. Audio is as bare-bones as it gets; batching, instancing, and material constants need some serious love to fix the unreasonable draw-calls for trivial material tweaks (see PBR demo for an example of it run wild). Plenty of things.

Nevermind that documentation always needs love, especially as the usage context continues to expand (ie. “turn off reuse shadowmaps for mobile AR/VR”).

Worst case, it’s not that bad if the final fate is “awesome set of reasonable base code”.


3 posts were split to a new topic: Build support for Android and WebAssembly

IMO Urho’s main weaknesses are lack of more advanced graphics and audio features.

I think joining forces with other open source projects (if they’re high quality enough) like bgfx is a good move, since it “de-duplicates” work in the open source space.

Also I gave Godot a try (3D only).
While Godot is more popular and got nice features Urho doesn’t, it got some critical fundamental bugs:

These alone rule it out for me, and considering Godot is flooded with issues on GitHub (+3,200) it could take a long time before they’re fixed.

There are still good lessons to learn from Godot.

  • They focus a lot on optimizing development speed, which makes working and experimenting in its editor a bliss.
  • Creating new projects is as easy as clicking a button.
  • It seems (didn’t give it a try) it’s capable of exporting to any platform from the platform you develop on.
  • nice “prefab” system in which you can save nodes, and add them as references instead of copies to your scene, so when you edit the original node file anything that uses a reference to it automatically updates.

Godot’s interface is good. Very good. And yes, the export process is a breeze.
It’s still not mature as a 3d engine. It has born as a mobile oriented, 2d engine, and then evoluted into 3d. They started creating a 3d version, then remade into a new version recently, and then this one:

they’re changing it all over again.
For instance it has no deferred rendering. It’s all forward pass. Don’t know how much it bears, anyway…
Anyway they’re running quickly, so they’ll be on a good 3d roadshow, say, in a couple of year…

Curious what’s on your wish-list there.

What I find missing the most is global illumination and less expensive shadows (could be part of GI).
Other than that having common effects like SSAO included with Urho would be nice.

Also there are open source libraries for better audio, that include effects like Doppler and reverb.

1 Like

I spent 4 years trying to build a basic game engine on top of OpenGL and some other libs, and was working on a game and an editor for it in Qt. I couldn’t get anyone else interested in helping out on the project - and quickly found that, even though I knew the inner workings of everything in my “engine”, it was hard to stop adding features to the wish list. I sort of fell in to the “create a game not a game engine” trap.

I abandoned my project. Why? Everything I was trying to do was already done here. One day I was working on UI anchoring or something like that, and I googled lightweight 3d game engines. I found Urho3D and it took me like a week to get my game (Build and Battle) and my Qt based editor (BBToolkit) switched over to Urho3D.

So really this is the thing that is great about Urho3D currently. It just has a lot of code already written to do a lot of things - and the code is not very intrusive so you can use it or not use it. Also, it’s pretty easy to follow the source code to figure out what is going on.

I think of Urho3D more as a library than an engine. Because of this, IMO the future of Urho3D is really as others have mentioned, to be forked and used as a base building block for other projects.


Wow. have taken this all in. I have a bachelor degree (bachelor of games and virtual worlds) as a programmer, and would gladly step up, if I thought I was well received and backed up by my peers.
I have a lot to learn, but it’s all exactly what I would do, from what I have seen.


In that case I’d say familiarize yourself with the codebase, try tackling some issues, then reviewing some pull requests… and if you still seem as sensible and motivated after that you could mean a lot to this project and all that benefit from it under whatever consented title. :wink:

I think its best to see the project as quite a dynamic/organic whole where people grow into roles rather then having them assigned. Your contributions define your role rather than the other way around.

New breed gathers
Soon it will be
Like in the days before


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