Best open-source engine around


#1

There’s a lot of negativity around these parts lately and I just wanted to thank the developers of Urho3D for making the best open-source game engine around. Not because of bells and whistles, but because of modularity, extensibility and code maintainability. It has one of the best architectures I’ve ever seen and you guys rock. I’m learning so much from it.


#2

I second this opinion!


#3

I agree, this engine is far more capable than other projects like Godot and is also quite robust already even though there’s hills left to climb. Honestly, this project is really suffering more than it deserves recently from the lack of distinct leadership. Without Cadaver, it feels like things are a bit unsteered right now even though it’s clear on github that people like Egor are contributing quality code and working hard. The project needs someone who has deep knowledge of the engine and the time to communicate with the communities both developing with and for Urho. It’s not fair to ask that of the remaining productive contributors if they don’t want to do it, though I think it’d be awesome if someone from Xamarin stepped up as project leadership. Microsoft is investing in Urho to some degree, but the community is languishing right now and that is not good for this kind of project. I’m surprised at how much more buzz Godot gets online than Urho. This is nearly an open source Unity competitor, and it runs on damn near everything. MS also dropped the ball on XNA so I don’t think we should count on them to keep this project afloat.

But there’s a great example: unless the Metal bindings happen it’ll be off iOS forever because nobody has been able to rally the troops any of the times the issue’s been raised. How can a mobile game developer be honestly expected to adopt an engine that can’t run in the most profitable mobile marketplace?

Edit: Actually, in the metal discussion thread there’s a guy bragging about how fast he built the bindings and selling them. That’s all you need to see.


#4

Here, I corrected this for you:

Honestly, this project is really suffering more than it deserves recently from the demoralizing leadership.


#5

Just to put the record straight. When cadaver stepping down as the project lead, no one else step up to fill his role, me included. I am merely keeping the project alive while waiting for cadaver to come back or any one who has the same passion to continue cadaver’s work. So, don’t let me hold anyone back. Please step up and show yourself. However, so far people that I know of that are capable of doing good to the project are shying away for taking more responsibility. I can understand people just want to make game and make money instead of making free game engine. What I don’t understand is, the very same people that should have taken bigger role in the project are the ones complain about the project lack of leadership.


#6

At least in my case I don’t want to step up because I don’t have that overview of every line of code in the engine as cadavar did. That and I have doubts about being able to deliver.


#7

Last time I try near 10 different engines. Result always was “NEGATIVE”. Usually all engines looks like unusable overweighted stuff. Things like Blitz doesnt have much features. Urho3d have all I need. Fast, compact, ultracomfortable, I dont need to launch slow-motion IDE. All I need is F7, F5 + notepad to make new project. And O`korz good perfomance. It looks like you make best thing.


#8

4 posts were split to a new topic: Choice of engine


#9

Now that isn’t very fair in my opinion, Blitz (3D/Max) or more recently Monkey aren’t on the same league, you can compare them to say XNA maybe, but comparing them to Urho is apples and oranges.
That being said I totally agree with everything else you said. Urho code is easy to pick up, it’s lightweight compared to other engines, and has all the important features.


#10

Godot has IMO earned its hype though, by the developers being active and community-oriented, even if there are shortcomings.

The flipside of hype / buzz is too many expectations and potentially getting burned out or bitter from those expectations not being realized, but that’s always everyone’s own responsibility.

And let me repeat one more time that I’m not coming back. I think you’re doing fine, as long as everyone maintains realistic expectations. I also now believe more firmly that engines should have a concrete game project behind them, so with the knowledge I have today I would likely not have started Urho at all, or at least kept a stronger disclaimer that hey, this is just a learning project for rendering techniques, do not use :slight_smile:


#11

“Do not use?” man I think this engine is awesome. Wish I have enough knowledge to take it up…


#12

Note the smiley. It’s all about expectations, so when you know exactly what you’re getting, then it’s no problem. Certainly the engine was a necessary “mistake” to make, especially in that time, when on the open source front there was practically just Ogre (+ some more smaller, obscure or abandoned / stalled engines).


#13

About engines and opinions… through some years I looked at some engines and created
some opinions which I’m more than happy to share now and then:

  1. Godot - hype/buzz based development. Most disappointment is from false expectations and developers’ false promises. Technically a problem with it is that their direction is quite chaotic.
    Also engine features are always have lower priority than ease of use/simplicity which is sometimes not quite logical. It is somewhat changed with 3.x versions, but still shows-up from time to time.
    There are some great people there which do stuff though, physics side was quite improved in 3.0, but they dropped GLES2 which makes me just observe Godot development, but not actually use it.
    Also it is hard to get help from the community for anything more complicated than some basic things, as the engine is mostly used for very simple games.

  2. Torque3D - been powerful once, but now one-man project with small community. Has a lot of features everyone forgot about and re-discovered again. Very powerful editor and if you’re going for a shooter with a small map, it is way to go. A problem is that it does not support OpenGL ES. Renderer is quite good, but no mobile path. The development is very slow but steady (it is developed in free time by single great person). Asset pipeline for characters is hardcoded on Biped from 3Ds max which is sad sad sad (lots of older code depend on 3Ds Max). Props and enemies are based on Collada and the asset pipeline is quite fluent, I’d say it is much better than any engine from this list except for Armory. Also use script as data everywhere is fantastic and much better than xml/json.

  3. Armory3D - a new bird. Been playing with it for some time, it leaves a lot to be desired (countless basic things are missing, but still looks great as a concept). Uses Blender as editor for everything. Implements node logic and haxe scripts (can run native code via haxe though). Targets lots of platforms, including Linux, Android, MacOS, iOS, html5, wasm, etc. Looks very promising as it implements both design-oriented and code-oriented approach. For me current serious shortcomings are lack of any sort of documentation for things like to/from ragdoll transition, complete lack of layered animation. But asset pipeline is so easy that I can’t stop playing with this engine for some things. The renderer is great and mature. Nice thing, definitely worth observing.

  4. Urho3D - I’d call it not engine per se but a framework/library to write engine for oneself with all features you need writing them from scratch. If that is your approach, then it is way to go. Urho3D is quite feature-complete on low-level (unlike Godot for example) but to actually make things work the needed way one is supposed to write middle-level and top-level subsystems/components. If you have serious experienced team who can do it, the go for it (I think in this case you could write engine from scratch too). Otherwise you can write simple games like in Godot but with inferior usability and less featured editor. Or you can like me learn things and write code for years in hope to not develop Alzheimer before you finish it. Asset pipeline is more friendly to simple models and low bone counts (bone count is better than with Godot and T3D, but worse than with Armory). Exporting meshes is simple, but for other things one is supposed to write exporters/tools/editors. But this gives great chance that when (if) you are complete with all this you will have most great tool set for you and your engine will lack any bloat. Probably. If some group of people did write some set of middle-level subsystems which would make some frequent tasks easier, that would make the engine more accessible, but that would turn away people who are against “bloat” “even on source level”.
    So to be honest, among 4 listed open source engines, if I just come here not spending some years making game using Urho, I would not recommend it for non-professional use. But this engine is most powerful of all four with things you can accomplish with it. If you can.


#14

Have to correct you here; things are now reversed. Opengles2 will be kept for low level rendering targets, and vulkan -> metal something for high level. Read here

Really?

:heartbeat::heartbeat::heartbeat::heartbeat:

NO!
Everything short of C++ is simply not serious for game development. You gain traction in the beginning, and stop in the middle. Anything script should simply be forbidden.

that is too much dependent on use cases to be really doable. Even if you do, contributing back could be a conversion hell…


#15

I think you guys might want to continue this discussion on the thread that @Modanung split: Choice of engine

Let’s keep this one for discussing the strengths of Urho and why it rocks! :slight_smile:


#16

What exactly is this knowledge you know now that would have prevented you from starting urho?


#17

As for Godot vs OpenGL ES 2 - these are only words, lets see when it is implemented. It was too frequent to be let down by Godot developers, so I never even read their plans or proclamatios - only git commits
and issues.

Torque3D is really cool, try it. Have shooter of your dream in a few hours is fun.
Also you can overcome much of it asset pipelime limitations using a bit of C++ knowledge, if you target only PCs.

As for Armory - it is WIP and progressing quite well. As I mentioned - you can use C++ code if you target native architectures (Linux, MacOS, Windows), but not when targeting html5/wasm/js.
Probably they eventually resolve this. I don’t care much though at this moment. Haxe is compiled to native code and looks fast enough for my purposes at this moment. I do not try to do something big like with Urho, just some small for a change.


#18

That engines are a shitload of stuff, not just the obvious graphics + physics + animation but platform support, social / advertising / IAP mechanisms etc. That it’s a constant struggle to stay current, with new API’s cropping up… That pro engines do it with tens (or even a hundred?) of fulltime employees. And that without a real game or other “do or die” project to back it up, I will eventually run out of interest.


#19

This could be said about any framework or library. Some game engines are just plain libraries, some are full-blown self-contained content development platforms. One just need to choose where to stop.
Having real project would of course make the whole thing easier, as most of commercial game engines was developed for a game first and then was made into all-purpose engines and evolved.
Understaffedness is common problem even for commercial engines, some projects overcome this by “bounty list” and roadmap thing, others by “doing what they can” and not allowing much development, but manage somehow. Some are so greedy that prefer to delete their github repository than let other people develop it, some just constantly whine about understaffedness when asked about features implemented but when you submit patch to them with feature implemented and tested by a few people they refuse your patch because they “did not have this feature planned”, would prefer to implement it themselves, and drop your PRs/submissions.

So everyone manages somehow, the situation is not unique and not something to feel bad about.
It just requires spending some time, creative ideas, people who are truly interested (not just saying that) and progress which is possible to show (not just constant architecture shuffling, the actual things people need. If people don’t need anything, your project is dead (as there is no such thing as completed software)).


#20

Sure, and now that Urho exists, you have all the opportunity in the world to solve these problems :slight_smile:

The problem of scope, related to open source engines, is interesting. Obviously a full game engine is a (too) large undertaking for a solo dev, yet I don’t think there have been very successful results from just putting together a bunch of libraries, or trying to provide a “core” for others to extend. Rather, the tempting approach is still to attempt doing the whole thing, or nearly the whole thing with perhaps only the graphics library as external.

This goes a bit back to the “make games not engines” mantra. For example, integrating a physics engine or a scripting language for just your own needs in a game will be more focused, likely faster, potentially also dirtier than providing the integration in an engine for others to build on.