Securing Urho3D’s future

I was wondering if there has been any thought on securing Urho3D’s future by setting up a Patreon or something? Maybe cadaver could setup an Urho Foundation (similar to Blender) that can take donations to fund development and maybe even bug bounties the core team deem critical enough.

I just really like Urho and I’ve done some pretty cool stuff with it but I’m concerned it might remain a toy and fizzle out someday and practically disappear kind of like, for example; the PixelLight and CrystalSpace engines. There are also a lot of other open source and commercial frameworks that Urho3D has to compete with in terms of interest such as; Ogre, Unity, Torque3D, Unreal, Crytek, Godot (recently setup a Patreon awhile ago to fund 3.0), Blender Game Engine and so forth.

Just throwing some thoughts out there. What are your thoughts?

I’m sorta worried about the same thing, especially after seeing the doldrums that settled in after cadaver stepped down from lead role. I’d be willing to swing some money toward keeping this going, if there were a foundation in place and some committed leadership. I like Urho3D and I want it to keep going.

A Patreon would be cool or something similiar Foundation like. I’ll be willing to help it.

I am ready to donate a small amount of 500$ if Cadaver will take back the lead role .
In addition based on the progress I will donate some money also in the future.
In my opinion the Godot way is the right way to go .
See reference : https://godotengine.org/article/shedding-light-on-godot-development-process

Others did made great contributions but I think Cadaver’s involvement is a must.

Cadaver had said that his staff do not use Urho3d engine now, if so, the project is going to death.

Yeah. We have kept that role open in the hope Lasse will take it back again.

I feel the same way, I really like Urho3D and hope to see it keep going. I’m willing to donate if cadaver or someone takes the lead to setup a foundation.

I also really like Urho3D and I’m willing to donate to keep it going.
But it will need strong, dedicated leadership.
I hope Lasse will reconsider.

I can very safely say I’m not coming back to the lead position. And I especially would not want to be obligated by any monetary contributions.

You certainly have my blessing to organize funding for the project as you desire; you don’t need me for that.

Though, I don’t think an open source project’s future can be forced into the better, if it doesn’t come naturally from the sheer joy of working on it, and from having contributors that have enough motivation and time.

Urho (the fish) was killed with a kitchen knife on the draining board when it was found too sick to thrive & fight in the fish tank any more. Then the halves were flushed down the toilet. If you someday decide to do the same for the project, you also have my blessing.

(edited for factual accuracy; misremembered & combined two separate fish executions at first)

Spoken like a true leader.

Let’s just try to keep the vultures at bay while we build a temple worthy of its spirit. Urho’s no ordinary fish.

Well, it’s my turn to say something…

I think Urho won’t benefit from donations now.
Since Urho is much less popular than e.g. Godot, I doubt that there would be enough donations to hire anybody on full or even half time, at least in the nearest future.

In my opinion, contribution is always the best donation. Best thing that one could do for the Urho’s future is to start using it in projects and be ready to implement and contribute missing features.

Why not take a Star Citizen approach then? Set goals then depending on stretch goal reached a dedicate person can be gotten to develop a feature. While this allows contributors to contribute coding on other aspects. The key part is using and showcasing on any available media.

Id like yo jump in on this and say @rku has been running his own Urho3d branch and small team keeping at least some form of progress and security alive. He is taking a slightly different approach to development but i feel it would work well for the future of Urho3D.

On the topic of the donations stuff it may be a good idea even if we dont have the popularity of Godot doesnt mean we dont have enough for a part time leader. and all donations are entirly optional, the leader should be willing to work unpaid just out of love for the engine.

Ideally we should also do a public voted roadmap where they can choose what they want to see in the engine and it also means people who want to help can see what features should be worked on.

I kinda think it’s a good idea. If there is a enougth donation / contributions it can go to the part time leader and/or developer. A roadmap would be nice 6 months. I don’t know a list of small goals then it’s voted on then made into a stretch goal like Star Citizen does.

It’s just a example.

Here are my two cents :

IMHO what Urho3d needs right now is popularity,And gaining in popularity doesn’t necessarily require money but lot of work and enthusiasm.The following changes could skyrocket Urho3d’d popularity :

1. Independent website. Right now everything is all over the place.There are some official and unofficial wiki pages , there’s the Github main page , and the discourse forum… (Which is in my opinion absolutely bad for a technical forum).No matter how great fast and easy to learn Urho3d is comparing to the other engines , nothing will turn down peple faster than a overcomplicated and badly designed website.Everything should be in one place.Garage projects , Tutorials , forum and a blog.
   2.Editor. We can keep everything but the current editor must go. It’s great it’s functional it’s cross platform but to be honest it won’t evolve because no one will fiddle with angelscript sources and scrolling through hundreds of lines of codes without an angelscript editor. It must be re-implemented in c++ and must be expandable with scripted plugins. The UI design must be replaced too either with a new skin or TurboBadger.

99% of forum is suggestions do this or that. But everyone hopes that someone else will do it. That’s the problem, but not something else.

I would love to hear what @rku is doing in his branch of Urho3D, and what goals he has with it.

Not much, just things i personally find useful. They do not align with goals of upstream and have little chance being accepted into main Urho3D project.

Some things i did there:

Completely rewrote build system. It is not as feature-full as current Urho3D build system, but is much more lightweight and easier to modify. Also added gradle build script for android so that new SDK/NDK can be used. Thanks to @Pencheff and others for doing research!

Removed AngelScript and Lua bindings because IMHO they are toys that require way too much maintenance. Scripting languages have their place in scripting scene logic, but wrapping entire engine only to allow use it for someone who does not know how to compile c++ code… I am not interested in that.

Added imgui subsystem and integrated it with Urho3D UI so they do not fight when both are available on screen.

Started writing imgui editor in that fork. Future of editor is not clear to me at the moment. @Eugene wants to see it upstream but at the pace Urho3D is moving i find it very demotivating to contribute to upstream.

Added easy_profiler integration which was originally written for Atomic. Actually useful profiler is very important.

Convinced @boberfly to add bgfx backend. He is working on the code, i make build system happy. Porting happens on a fork of my fork. bgfx will land in my fork way before PR gets accepted by Urho3D.

Added my tasks (stackful coroutines) subsystem. Yes, it may not work on all platforms. They are still awesome.

Added convenience subsystem getters with pointer caching because writing GetCache() is definitely better than writing GerSubsystem<ResourceCache>() and hashmap lookups for getting subsystems is wasted work. I know hashmap lookups are fast. It is still wasted work. Practicality beats purity. This by the way was suggested to Urho3D in a PR and was declined.

I am working on c# wrapper generator using CppSharp. We will see what comes out of it. No promises

This fork does not offer hard backwards compatibility guarantees. This is a moving target and you will need to update your code after engine update. To be honest i did not really intend others to use this fork so i suggest to not grow dependant on it. I view it more like incubator of nice-to-haves. @dragonCASTjosh wants to contribute some cool shader work which may or may not be accepted by upstream. My fork is more accepting of all kind of code. This ultimately means that code will not be as stable as vanilla Urho3D. My work is oriented towards a powerusers who know what they are doing. Newbie users should not use this fork because they will definitely have a very bad time with it.

I’m going think on some ideas to help on that point.

I think Urho3D can be a game changer if we seriously regard the developement as a game engine, not a hobby project or test field, as a real game engine. It could be a real competitor of the commercial game engines out there.

I don’t know why Cadaver abandon this cool, elegant project in which he put his energy and showed everyone his extraordinary talent. I really love the code of Urho.

I truely believe that many commercial studio can take Urho and make some aggressive improvements and make really professional games. Maybe that’s the only way to show the true value and potential of this project (if they let ppl known).

It could be, it could be… like most of the open souce software.

Lasse worked on Urho for ten years. It’s a lot of time and effort.
I think that everybody needs rest.

If passion is gone, just leave and let others to continue the work. And come back if get passion back.
There is nothing good in passion becoming obesssion (or hatred).

I’m not really using urho, but i plan to use it in the near future (the c# version)

But i like what you listed here, i also think AngelScript is useless, nobody is willing to learn a niche language just to avoid writting C++, Godot for example made the choice to use C# (with lot other languages to come) and it gave them lot of echo

But i also believe splitting force (and community) is the worst that can happen

Breaking backward compatibility is sometimes needed if it improve the project for the future

To be fair, Godot’s C# support was funded by Microsoft. And “nobody” is such a strong word, especially coming from a programmer

But we live in a world where students are taught to prefer C#. It’s only a matter of time before the species is assimilated.

I really enjoy the current development of Urho. I find it to run at a pace that I can follow. Too many projects these days derail from their main objective. Trying to integrate as many things as they can. Hoping to satisfy everyone. And I would hate to see Urho follow the same path. We already have plenty of those.

They try to integrate as many eye-candy features as they can. Yeah, Vulkan baby, DX12 FTW! (just spouting whatever comes to mind here) If your game really needs some of those features. Perhaps you’ve chosen the wrong one. Or you should make your own. That’s like going to a car manufacturer and asking him to put wings on it because YOU need to fly with it.

Sure, each developer has their needs and most of the time they’re not the same as everyone else’s. And I’m pretty sure I can point some things in Urho that were added just to be there. Not that anyone is actually using them. You really need to find the right balance of what’s to be included.

As for monetary backing. Sure, nothing wrong with it. But I wouldn’t be surprised to see it getting in the way. For some reason, the people surrounding Urho’s development, don’t strike me as that kind of people. They just enjoy it. And there’s nothing wrong with it.

If a project is really appreciated by someone, then it can’t really die. Someone is bound to fork it and continue the work from there. Isn’t that one of the benefits of open source?

I doubt it, they received donation from xamarin (miguel) way after the C# project started

And it is not just about C#, they support lot more languages ( they put C# in the front because they knew it’d create lot of buzz)

They have good PR skills, and that’s where urho3d can improve imo

And and let’s be honest C#/Java/Lua/Python/JS tooling are far more superior than AngelScript or any other niche language

One of the reason unity abandonned UnityScript, people just didn’t care about it + add lot of burden for the maintenance

You are probably aware that MS owns xamarin and did in fact sanction a $24,000 donation to support it. From the horse’s mouth: Godot Engine - Introducing C# in Godot
Maybe we’re just arguing semantics.

That’s quite a strong opinion. I’ll concede that people do like the comforts of familiarity, and niche languages tend to break that. But (to me) AS is just C++ on easy mode for rapid prototyping. Didn’t feel like an obscure niche language when I picked it up. Wouldn’t mind seeing the PR rules 'laxed a bit though…

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

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:

• Occasional lag spikes every few seconds (even in an almost empty scene).
• Networking is broken.
• Unstable mouse input.

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:

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.

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.

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!

Ugh, I got off to a bad start
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

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

Hello,

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.

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.

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.

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.

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?

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!

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

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.