Unity vs Unreal

[grudgebringer]

Hey, Keldryn, how about Id tech then?

 

[Irenaeus II]

Wow I didn't know that Keldryn was a actual game developer for established companies... ]



Nice to have you here, bro

 

[JudasIscariot]

I am no programmer/developer/what have you but from an end user standpoint, Unreal is the better engine imho.

Unreal even manages to perform better on Linux. For example, Tower of Guns is an FPS based on Unreal and Ziggurat is an FPS based on Unity. I can load up ToG a LOT faster than Ziggurat on my current system and I don't hear my video card fans winding up like they're about to fly off with Unreal.

 

[Irenaeus II]

I don't care what perform better on Linux. Or even on Windows tbh, my computer is top of the top. No game I actually want to play comes close to its specs. Maybe in 4 years.

 

[a Goat]

Why haven't you got 1440p/4k monitor to push your system to the limit then?

 

[Irenaeus II]

Why would I, only bad games need that.

 

[a Goat]

I agree.

 

[Immortal]

They're all shit. If you find a game engine that isn't, then you haven't spent enough time with it.

Well played.

 

[Keldryn]

Hey, Keldryn, how about Id tech then?

I'm sure it's shit in its own way too.

Making a game engine is fucking hard. Most programmers are not up to the task (I readily admit that I'm not, at least in terms of the graphics/rendering side). Part of making an engine is building it such that the rest of the team can work with it as well; artists and designers are far more productive when they have good tools and aren't fighting with the tech every time they do something.

Wow I didn't know that Keldryn was a actual game developer for established companies...

Emphasis on the "was" of course. I worked at EA for a year as a test engineer and then as a designer at Rockstar for a little under two years. I quit in 2009 and went back to the saner hours and better pay of business software development when we were expecting our first baby.

 

[Burning Bridges]

The Algorithm I mentioned is used in almost every video game / networking system / gps calculation / artificial intelligence table / everything ever. It was published in 1959.. according to wiki?
It's literally the fastest algorithm we have for finding the shortest path between multiple nodes. This isn't a *~*~Unity~*~* thing.

Sim City will use the same algorithm. How they weight nodes or designed the game over top it is anyone's guess. I haven't played it.

If you mean Dijkstra, there are literally thousands of better pathfinding algorithms.

 

[Neckbeard Shitlord]

Thanks for summarizing it because I can't being lost in between the ''you're a retard''. I thought I would get nice information out of this thread but oh well...

Unity is shit.

Unreal is shit unless you have a couple millions to burn.

 

[Burning Bridges]

I can't say about Unreal, but it' very unlikely that anything is shittier than Unity. Unity provides a standard solution to the game problem, so people build whole games out of the same modules (they basically go directly from hello world to their first game). The result is that you see dozens of almost identical games that do exactly the same, and have the same problems. Unity has superseded the decline. While during the decline we had hardly any good new games, we now have thousands of shitty new games that look exactly the same. Thinking of Stean I can hardly remember new games anymore, or mix them up.

For a small game I would personally avoid both, and look at something more lightweight like SDL. Has somebody here tried SFML? Strategy games can even be written in plain Winforms, or in Qt if you need hardware acceleration.

 

[Zarniwoop]

Unity as an engine is just sick at its core.
Any game made with It uses about 10x as many resources as it has any right to, and that applied to disk usage, RAM usage, and CPU usage.
To date I cannot name single unity game that doesn't hog an entire CPU core to itself just to render a static main menu screen!
I've also yet to see a Unity based game release that isn't marred with technical issues related specifically to the engine.


Since I feel like making a hall of shame.

Banner Saga
- Framerate during combat is measured in seconds per frame at most intervals (this is curenttly fixed in a beta branch)
- Why does a simple 2D game need 2GB of RAM and have minute long load times!?

Expeditions Conquistador
- Game freezes whenever the mouse is changed into 'relative' mode, this happens when the camera rotates; Fixed in Unity 5, but they will never release an update to Unity 5.
- 'Dropdowns' are completely missing text in the options menu

Planet Explorers
- Slow
- Mouse completely spazzes out if you move it at anything other than a snail's pace, also above freezing issue. (Fixed in Unity 5, update with unity 5 still pending)

Cities: Skylines
- for the first few runs, the game tried to open the game as fullscreen over both my screens; it failed and ended up as 1920x1080 on my second one with all the game content off screen.
- The second run it was half-offscreen
- It needs nearly 6 GB of RAM to simulate a small 20k person town!!
- Game stops appears to hang after a few hours, but simulation still goes on in the background and it responds to input events appropriately (again, in the background), so you can't see what you're doing at all. But you can quicksave and then restart the game without losing any progress.

Shadowrun Returns
- Any moderately sized level has a very noticeable framerate drop.

Might and Magic X
- Very slow
- 32bit version had to remove all in-game sounds to lower RAM usage enough to avoid instantly crashing at start up.



Only engine I can think of that's worse than this is Bethesda's gamebryo that can't even reliably execute every statement in a script.

Oh shit, I never knew that about Cities. Explains much of the shittyness, that game had the potential of being the true Simcity 4 successor but turned out to be more of a SimTown successor with nice road building.

But you forgot Wasteland 2, the best example of how a game that should run on a calculator needs 8GB RAM, crashed more than a Russian truck driver and takes ages to load each (quite small) map.

Also instacrashed on 64 bit CPUs running 32 bit Windows.

 

[Excidium II]

But you forgot Wasteland 2, the best example of how a game that should run on a calculator needs 8GB RAM, crashed more than a Russian truck driver and takes ages to load each (quite small) map.

Loading times have increased significantly on the DC at least. Frame drops still happen though.

 

[:Flash:]

For a small game I would personally avoid both, and look at something more lightweight like SDL. Has somebody here tried SFML?

I use SFML.
It is similar to SDL in that it is not an engine. It is a hardware abstraction layer, but you have to do everything else yourself.
SFML is very well designed and documented and thus easier to get into than SDL.
On the other hand, it's not as widely used, doesn't have as many bindings and add-ons as SDL, and doesn't give you the fine-grained control over how things are rendered that SDL does.
SFML is good if you want to write a sprite-based engine yourself. I have advocated for writing your own engine before (because I share the sentiment that most games nowadays look and feel too samey), but you should now what you're getting into.

 

[Excidium II]

A friend of mine is making the next X-COM with SFML.

 

[Ninjerk]

A friend of mine is making the next X-COM with SFML.

Publicizing it at all?

 

[Excidium II]

Probably in the future.

 

[Karellen]

I use SFML.
It is similar to SDL in that it is not an engine. It is a hardware abstraction layer, but you have to do everything else yourself.
SFML is very well designed and documented and thus easier to get into than SDL.
On the other hand, it's not as widely used, doesn't have as many bindings and add-ons as SDL, and doesn't give you the fine-grained control over how things are rendered that SDL does.
SFML is good if you want to write a sprite-based engine yourself. I have advocated for writing your own engine before (because I share the sentiment that most games nowadays look and feel too samey), but you should now what you're getting into.

In my idle youth, I did once go through the process of writing a sprite-based engine and animation system, but predictably I never came even close to finishing the thing I was ostensibly making it for. It was an interesting experience, but I'm not really convinced it's necessarily a worthwhile effort for most people, especially if you're working alone or with a very small team. The real problem with game development comes after you have your tech done, when you're meant to start producing and trying out content, and that's where engines with a ready-made graphical editor like Unity, Unreal or Godot really shine - it's really easy to produce levels and areas and, more to the point, to edit and iterate on them as necessary, which is a very large part of the famous last ten percent that's actually ninety percent of the work that goes into making a game. Of course, you could make your own level editor (and even for Unity you might want to add stuff), but there's a reason why even professionally made level editors and modding tools are mostly pretty bad; making one is a whole lot of work and maintaining it doubly so, especially if your game is an evolving project where you need to add in new elements and capacities as you go along.

I haven't really used Unity 3D in any remotely professional capacity except for some very small multimedia projects, but my experience is that I'd have the whole thing designed, produced, tested and deployed, complete with assets, in less time than it would have taken to program just the fundaments from scratch. I don't think that indies or hobbyist developers can really afford to waste effort like that, so if I had a lot of content to put into the game and iterate on, I'd definitely go with an existing game engine and editor. Of course, it'd be different for games in which the content is mostly procedural, in which case the nice editor wouldn't be that big of an advantage and the scene and object-based workflow of Unity or Godot or the like would probably be more of an impediment. When it comes to games in which most of the content is hand-crafted, though, I think it's a good rule of thumb to concentrate as much as possible on getting the content and the user experience right rather than the underlying tech.

 

[:Flash:]

In my idle youth, I did once go through the process of writing a sprite-based engine and animation system, but predictably I never came even close to finishing the thing I was ostensibly making it for. It was an interesting experience, but I'm not really convinced it's necessarily a worthwhile effort for most people, especially if you're working alone or with a very small team. The real problem with game development comes after you have your tech done, when you're meant to start producing and trying out content, and that's where engines with a ready-made graphical editor like Unity, Unreal or Godot really shine - it's really easy to produce levels and areas and, more to the point, to edit and iterate on them as necessary, which is a very large part of the famous last ten percent that's actually ninety percent of the work that goes into making a game. Of course, you could make your own level editor (and even for Unity you might want to add stuff), but there's a reason why even professionally made level editors and modding tools are mostly pretty bad; making one is a whole lot of work and maintaining it doubly so, especially if your game is an evolving project where you need to add in new elements and capacities as you go along.

I haven't really used Unity 3D in any remotely professional capacity except for some very small multimedia projects, but my experience is that I'd have the whole thing designed, produced, tested and deployed, complete with assets, in less time than it would have taken to program just the fundaments from scratch. I don't think that indies or hobbyist developers can really afford to waste effort like that, so if I had a lot of content to put into the game and iterate on, I'd definitely go with an existing game engine and editor. Of course, it'd be different for games in which the content is mostly procedural, in which case the nice editor wouldn't be that big of an advantage and the scene and object-based workflow of Unity or Godot or the like would probably be more of an impediment. When it comes to games in which most of the content is hand-crafted, though, I think it's a good rule of thumb to concentrate as much as possible on getting the content and the user experience right rather than the underlying tech.

I think that from an economic / business point of view you are completely correct.
If you are trying to sustain yourself with your game, by all means use Unity or some other premade engine.
I was arguing from a techno-artistic point of view, and I miss the times when games had completely different technologies that made the games feel unique. Who remembers the ellipsoid engines of Ecstatica and LBA? That's why I immediately donated to Voxel Quest, even if I don't believe the game is ever going to be finished.

For me, this is purely a hobby. And some hobby model makers use premade models and others build their models from scratch, and neither does a business analysis of what he is doing.
I made a conscious decision not to try and make money with game programming. I don't care how long it takes. The first ideas for this game started almost 15 years ago. And if I never get finished I will have learned a lot of stuff that I wouldn't have learned if I were using Unity.

 

[Hirato]

if Indies want to use a premade engine, I'd much rather they use something like Unreal, Unigine, or even some Open Source engine (There's plenty, Ogre3D is one of the more popular ones) over Unity.

Oh shit, I never knew that about Cities. Explains much of the shittyness, that game had the potential of being the true Simcity 4 successor but turned out to be more of a SimTown successor with nice road building.

But you forgot Wasteland 2, the best example of how a game that should run on a calculator needs 8GB RAM, crashed more than a Russian truck driver and takes ages to load each (quite small) map.

Also instacrashed on 64 bit CPUs running 32 bit Windows.

I didn't mention it because I either haven't played it enough or read much of anything about its performance.
Though in the brief 5 minutes I did fire it up in the past, it framerate was really poor until I reduced the texture resolution.
After that I killed it pretty much immediately as I couldn't stand the idiotic motion blur they put on the camera - and they had yet to add the option to disable it at the time.

 

[Stormcrowfleet]

Can you still make games out of the Fallout engine ? That would solve everything.

 

[Neckbeard Shitlord]

It's awful unfortunately. Google fan made fallout and see how that went.

 

[Davaris]

I can't say about Unreal, but it' very unlikely that anything is shittier than Unity. Unity provides a standard solution to the game problem, so people build whole games out of the same modules (they basically go directly from hello world to their first game). The result is that you see dozens of almost identical games that do exactly the same, and have the same problems. Unity has superseded the decline. While during the decline we had hardly any good new games, we now have thousands of shitty new games that look exactly the same. Thinking of Stean I can hardly remember new games anymore, or mix them up.

I was wondering how people were making games so fast. I thought these kids must be friggin geniuses, until I dug into the asset store and it all made sense. Unfortunately it doesn't matter how long you spend making a game. One you spent 10 years coding from scratch and optimizing to the nth degree, will most likely not be played let alone bought by anyone. While something some fool spent 3 months on could be loved by millions. I see former AAA devs complaining an indie game they spent half a year on only took $200 in sales. lol If that happened to you after spending 10 years, wouldn't you feel like an idiot that wasted his life?

Unreal will be the same as Unity in a few years, because they are trying to follow the same model. You can complain about what is happening, but its happening anyway. I've come to accept reality as it is and go with the flow. Buying stuff from an asset store is just a form of kitbashing.

For me, this is purely a hobby. And some hobby model makers use premade models and others build their models from scratch, and neither does a business analysis of what he is doing.
I made a conscious decision not to try and make money with game programming. I don't care how long it takes. The first ideas for this game started almost 15 years ago. And if I never get finished I will have learned a lot of stuff that I wouldn't have learned if I were using Unity.

Some prefer working on tools to making games and that's okay. For some working on tools is a way to avoid making a game. People need to admit this to themselves so they can either stop procrastinating, or focus on what they really like doing which is making tools.

 

[grudgebringer]

I'm sure it's shit in its own way too.

Making a game engine is fucking hard. Most programmers are not up to the task (I readily admit that I'm not, at least in terms of the graphics/rendering side). Part of making an engine is building it such that the rest of the team can work with it as well; artists and designers are far more productive when they have good tools and aren't fighting with the tech every time they do something.

Well, I got your point, but isn't it that Carmack is the man who started it all? He and his team were pioneers in the scene. They had been producing new engines like one time in 3 or 4 years, so he knows his shit.