the game i've enjoyed the most this year is "slay the spire", which is a single player roguelike deck building game. it has a bit of nice art but in terms of whiz-bang graphical effects it only needs to handle a 2D UI for a turn based card game with some bonus effects when actions happen. in this case, the game isn't really about the graphics, it's about the gameplay, which is great.
there was another fantastic turn based strategy game released around a decade ago -- "solium infernum" -- i think this was implemented in some kind of commercial multimedia thing (an adobe product?) by one developer. it had a fascinating system of diplomacy and warfare -- each player was a competing prince of hell, and you weren't allowed to just attack people, you had to have an appropriate pretext (e.g. another player had insulted you, or had refused your unreasonable demands to give them tribute) and set limits to how long the war would run for, and declare up front what your goals for the war were (e.g. capture a particular enemy city). it was fascinating game with a great theme, and crazily enough supported multiplayer via play by email. i played a game with some people that was great fun but took about 3 months to complete, with a few occasions where i'd spend hours before taking a turn trying to grind out the different odds to figure out the best tactics for a particular engagement, or if it was worth taking a certain gamble.
from a tech perspective, the engine wasn't really worth discussing, but it let one developer implement and ship their vision, and the result was pretty great.
edit: there's a pretty good old "programming in the twenty-first century" blog post - "Write Code Like You Just Learned How to Program"
(not to argue that either of the games i've mentioned are technically inferior, but the engine tech is entirely secondary to delivering a high quality game with a good experience)
Yeah STS is a pretty interesting case because it's a game from a Java dev who wanted his own thing. So he programmed it by hand (using libraries like LibGDX, of course). The part that impressed me the most is how he mentions he spent two weeks getting the played cards part working, and it shows; I've played a few "card game" video games and STS' has, by far, the best and most fluid playing. As in, when I click and let go it does exactly as I would expect it to.
Please don't discourage people from asking questions, there's 48 upvotes on this submission and personally I would have liked to come in here and seen a succinct summary and comparison of the engines from a programmers perspective.
The hacker news community tends to be more programming/math focused and the summary we get here will likely be unique and insightful.
Questions of this kind often boil down to specifics, as the various competitors all have strong and weak points.
As such, It will be hard for anyone to answer meaningfully without more context: What kind of game do you want to write, what skills do you currently have, what do you want to learn from this project, etc.
Surely the best engine in this case is that one that your developers have the most relevant experience in? Unless you want to add the challenge of learning a new workflow on top of actually building a game.
I second the other comment. The best engine is going to be the one your devs are familiar with. And if nobody on your team has any prior experience in any engine, that's a huge problem which makes the risk of failure much bigger.
The main advantage of using Unity is its out of the box support for multiple platforms, and garbage collected runtime, other than that it's slower, and graphics are on the ok-ish side (the best looking Unity game i've seen is Battletech), and i'm not sure about its open-world capabilities (Firewatch and The Long Dark world sections were rather tiny), possibly there's a way around it.
It seems that Unreal Engine is a better choice (Mass Effects, for example), but its pure C++ (with lua scripting), which means x3-4 as much of code, and trickier interoperability.
I dunno, tough choice. Good luck with your project!
I would really like to see some more recent tests as Unity before the 2018.x releases had a "ux/easy of use/developer first" approach but they did significant improvements on rendering quality and efficiency on the 2018.x versions.
Don't forget that Unreal has Blueprints. You could practically finish an entire game on blueprints alone! I recall that The Solus Project was almost entirely blueprint based.
None are 'better', some have workflows subjectively better than others.
For example the C++/drag and drop scripting in Unreal I dislike.
Where I dislike unity's subscription model, and some of the newer features don't quite work as nicely as they could. (I've been using unity since the early days)
CryEngine/Lumberyard looks horrid (IMHO) when I last looked at it.
So while YMMV, I'd suggest that you do a "proof of concept/minimal project" that covers some significant features of your game, and get a feel of the workflow, and go with the one that everyone can get along with.
Unity is easier to learn, Unreal has a cool ecosystem AAA developers love, Unigine has some bleeding edge stuff with great performance not found elsewhere, CryEngine can destroy any GPU you throw at it...
This is the only post that mentioned Unigine and CryEngine - is there a reason for that. I.e. are there significant drawbacks to these compared to the "main" ones?
Unigine used to be very expensive, CryEngine difficult to master. In the meantime Unigine got cheaper and there was a lot of work to make CryEngine more accessible, so that might explain popularity of Unity (easy to learn) and Unreal ("golden standard" allowing AAA games with great developer backing).
I have mentioned UNIGINE cause I've heard that Dual Universe powered by that engine. It isn't free, which seems interesting, cause the best things aren't free. And best things and "widely advertised" and "common" are not necessarily the same
It really depends on your need, budget and skill set of your colleagues.
Unity is easy to learn and provides better support for mobile. Unreal has better rendering capabilities if you want to develop for PC and consoles but has more steep learning curve. I haven't used Unigine but it looks promising for serious games and simulation.
So every engine has its pros and cons.
It all comes down to your use case: Are you trying to learn game development or are you developing the next AAA-Title with hundreds of developers?
Which platforms are you targeting?
Are you willing to pay for the engine and/or the assets?
The best game engine is the one that YOU feel comfortable with and can learn what you need to to create the game you want.
I took one day and tried to make the same game with Unreal, Unity and Cocos2d-x. See which engine I could get the farthest with. It turned out it was Cocos2d-x. (http://cocos2d-x.org)
If I decide to start a new game in the future I will repeat the same test adding GoDot into the mix and see how I feel about each one.
You'll encounter more breaking changes with Unreal while it gives better graphics. For our in-game integrations for STOMT, we have to create a new branch for any new released Unreal version: https://github.com/stomt/stomt-unreal-plugin
Having good visual assets is far more important to the look than the choice of engine. Having good audio assets is fundamental to making an app feel complete. Pick the engine that uses the programming language you know best.
Unity is reworking the whole network stack and they did significant investments in this area. So at this point implementing multiplayer using UNET or external libraries is possible and tricky but it is not really a good or future proof idea.
Popular games like Undertale and Spelunky were made in Game Maker, FFS. There is no "better or worse" only "more or less appropriate."
Also consider Godot. It's open source and you can compile support for multiple scripting languages into it.