Unreal Engine 4.7 Released(unrealengine.com)
unrealengine.com
Unreal Engine 4.7 Released
https://www.unrealengine.com/blog/unreal-engine-47-released
89 comments
Point of correction: Unreal Engine is not open source, the source is merely available for perusal. You still need a license for most uses.
That being the case, it still has benefits of open source. For example if your game isn't working and you have the skills you may be able to find out exactly why and then have it requested to fix and verify the fix. I would credit them for that and I'm pretty sure that exact scenario has happened for a dev agency.
That's called a shared-source model.
So the source is open, it’s just not free.
(I don’t want to sound like I agree with Stallman. I’m just trying to clarify definitions.)
(I don’t want to sound like I agree with Stallman. I’m just trying to clarify definitions.)
Well, the source is only "open" to subscribers: it's in a private Github repository. Stop paying, and you stop getting access to it, and it's illegal to publish even for perusal.
Exactly: the source is "open" to paying subscribers, just as the source to... just about any closed source software anywhere, can be seen if you buy a licence to see it. It fits NO definition of OS that I'm aware of.
Oh, I was mistaken. I thought it was available for anyone to browse, and you just couldn’t use it unless you bought a license.
It's not "open-source" under the usual definition. It's "shared-source".
To be fair, this is a term invented by Microsoft and only used by them, but I think it's accurate.
To be fair, this is a term invented by Microsoft and only used by them, but I think it's accurate.
I believe that is still considered open source, just not Free, Open Source Software (FOSS). It's basically one point shy of the GPL in that you can't redistribute the source, but modifications are allowed. I believe they even take contributions.
Open source doesn't depend on whether you pay for it.
Open source doesn't depend on whether you pay for it.
The OSI definition of open source (which was the original coinage) requires that users be able to redistribute the source. Companies have been licensing the source to game engines for ages, but that's not open source.
> Companies have been licensing the source to game engines for ages
Exactly. Literally the only difference now is that UE4 is much, much cheaper.
Exactly. Literally the only difference now is that UE4 is much, much cheaper.
Oh I see, thanks for the info.
It's 2015 and people still don't know the difference between open source and free software?
As you describe it, Unreal Engine is open source.
As you describe it, Unreal Engine is open source.
Unreal is neither. The source is copyrighted, you must pay them to see it, and you're not permitted to redistribute it, and can only modify for your own purposes (or merging into mainline) I believe.
Ahh ok. That's not how he described it.
Open Source = source is available and free as in beer. Examples: libpng, zlib, apache, python, llvm, chrome, firefox
Free Software = source is available and free as in beer and copylefted (you must also release your derivatives as free software). Examples: gcc, mysql, linux, gnome, gimp
Unreal is neither of these. It's not free as in beer nor copylefted. It's just that if you are allowed to use the source if you license the engine.
Free Software = source is available and free as in beer and copylefted (you must also release your derivatives as free software). Examples: gcc, mysql, linux, gnome, gimp
Unreal is neither of these. It's not free as in beer nor copylefted. It's just that if you are allowed to use the source if you license the engine.
Completely wrong on both counts.
Open source software does not necessitate any price requirements, but rights to redistribution, modification and running for any purpose without restriction. The definition you gave - "source is available and free as in beer" can still very well apply to proprietary software, if redistribution is forbidden. There actually is such a thing, it's called "shared source" by Microsoft.
Free software is any software that satisfies the four essential freedoms [1], of which being copyleft is absolutely not required in any way.
For all practical purposes, OSI and FSF standards are equivalent. They differ in that the former is more oriented toward pragmatics and business, whereas the latter toward ethics and philosophy. As a result, the FSF tends to encourage copyleft more than the OSI do, but they do not necessitate it by any means.
[1] https://www.gnu.org/philosophy/free-sw.html
Open source software does not necessitate any price requirements, but rights to redistribution, modification and running for any purpose without restriction. The definition you gave - "source is available and free as in beer" can still very well apply to proprietary software, if redistribution is forbidden. There actually is such a thing, it's called "shared source" by Microsoft.
Free software is any software that satisfies the four essential freedoms [1], of which being copyleft is absolutely not required in any way.
For all practical purposes, OSI and FSF standards are equivalent. They differ in that the former is more oriented toward pragmatics and business, whereas the latter toward ethics and philosophy. As a result, the FSF tends to encourage copyleft more than the OSI do, but they do not necessitate it by any means.
[1] https://www.gnu.org/philosophy/free-sw.html
And I think the key differentiator between MS-style shared source and Unreal is that Unreal takes contributions.
Indies have been using it a lot recently. Off the top of my head I can only recall Antichamber [1] as a successful UE-made indie game but there are also a ton of small games made with it. You should check out RockLeeSmile's videos [2] if you want to see some.
[1]: http://www.antichamber-game.com/
[2]: https://www.youtube.com/user/RockLeeSmile/search?query=unrea...
[1]: http://www.antichamber-game.com/
[2]: https://www.youtube.com/user/RockLeeSmile/search?query=unrea...
Nice to see this:
> HTML5 platform + WebGL is ready to use -- run your game in a compatible browser with a single click!
> HTML5 platform + WebGL is ready to use -- run your game in a compatible browser with a single click!
It's not nearly that easy.
It would be good to know what the minimum size is. If all you want to do is put a cube on the screen how large is the JavaScript blob you have to download?
Then, most games have tens or hundreds of megs of data. Does Unreal do anything to help this? An ideal HTML5/WebGL game engine would have many of the features of flash letting the game start with a minimal amount of data and downloading the rest in the background and/or on demand.
I know of no WebGL game engine that handles that in any graceful and developer friendly way though I'm sure it will come at some point.
On top of that you need to deal with where the user is coming from. Are they on a phone or tablet with only touch controls? A slow desktop? A fast desktop? Do you handle both mouse and touchpad?
I've seen almost no games handle these issues. Almost all assume you're on a desktop with a mouse which might be true for gamers but is not true for most people browsing the web (mobile or desktop).
For mobile you could check and tell them to download the app.
Does Unreal deal with any of these issues in a dev and user friendly way?
Until then though most Unreal->WebGL or Unity->WebGL apps will probably have relatively poor user experiences.
It would be good to know what the minimum size is. If all you want to do is put a cube on the screen how large is the JavaScript blob you have to download?
Then, most games have tens or hundreds of megs of data. Does Unreal do anything to help this? An ideal HTML5/WebGL game engine would have many of the features of flash letting the game start with a minimal amount of data and downloading the rest in the background and/or on demand.
I know of no WebGL game engine that handles that in any graceful and developer friendly way though I'm sure it will come at some point.
On top of that you need to deal with where the user is coming from. Are they on a phone or tablet with only touch controls? A slow desktop? A fast desktop? Do you handle both mouse and touchpad?
I've seen almost no games handle these issues. Almost all assume you're on a desktop with a mouse which might be true for gamers but is not true for most people browsing the web (mobile or desktop).
For mobile you could check and tell them to download the app.
Does Unreal deal with any of these issues in a dev and user friendly way?
Until then though most Unreal->WebGL or Unity->WebGL apps will probably have relatively poor user experiences.
More detail on browser limitations would be nice. I know the article states you can ship builds in 32-bit browsers, but are there any significant limitations involved? This would be problematic since, for example, Chrome 64-bit isn't yet the default release build.
I really wish there was more comprehensive documentation relating to UE4's limitations in a WebGL context. For example, lighting, shading, post-process effects, anti-aliasing, how they all behave relative to a full-featured desktop environment. The same thing for mobile compile targets wouldn't be a bad idea, either.
Also, it seems some otherwise popular third party plugins aren't supported in UE4 WebGL projects:
https://forums.coherent-labs.com/index.php?topic=691.0
I understand Coherent's reasoning, but I imagine developers who built their UE4 projects with Coherent UI aren't very happy that their prospects of easily compiling to WebGL are non-existent due to the total headache involved. Plus, webkit.js for UE4 would be really cool, and that's essentially what CUI running in a UE4 web-exported context would be.
Despite all this I'm really happy for this release, and ultimately it's a huge step in the right direction.
I really wish there was more comprehensive documentation relating to UE4's limitations in a WebGL context. For example, lighting, shading, post-process effects, anti-aliasing, how they all behave relative to a full-featured desktop environment. The same thing for mobile compile targets wouldn't be a bad idea, either.
Also, it seems some otherwise popular third party plugins aren't supported in UE4 WebGL projects:
https://forums.coherent-labs.com/index.php?topic=691.0
I understand Coherent's reasoning, but I imagine developers who built their UE4 projects with Coherent UI aren't very happy that their prospects of easily compiling to WebGL are non-existent due to the total headache involved. Plus, webkit.js for UE4 would be really cool, and that's essentially what CUI running in a UE4 web-exported context would be.
Despite all this I'm really happy for this release, and ultimately it's a huge step in the right direction.
This is problematic since, for example, Chrome 64-bit isn't yet the default release build.
Surprisingly enough, there isn't even an official supported build of Firefox 64-bit for Windows. Coupled with the Chrome issue you mentioned, I'll bet that at least 80% of users out there aren't using a 64-bit browser.
Surprisingly enough, there isn't even an official supported build of Firefox 64-bit for Windows. Coupled with the Chrome issue you mentioned, I'll bet that at least 80% of users out there aren't using a 64-bit browser.
This is insane in 2015. I understand the difficulties of porting, but at the same time, I've had a 64-bit CPU since 2009 and I was late to the party :)
There used to be a 64-bit Firefox, I think it was short-sighted of Mozilla to drop it.
Oh well.
Oh well.
> I know the article states you can ship builds in 32-bit browsers, but are there any significant limitations involved
There shouldn't be any. asm.js is actually a 32-bit target (probably by sheer coincidence since JS only has 32-bit integers).
There shouldn't be any. asm.js is actually a 32-bit target (probably by sheer coincidence since JS only has 32-bit integers).
This is from October 2014, so some of it may be outdated:
https://forums.unrealengine.com/showthread.php?48463-HTML5-C...
>5. My Game doesn't run.
That section outlines the memory concerns that I failed to articulate earlier.
Assuming it's still true, then it seems half a gigabyte is the upper bound. This would then preclude precomputed lighting in most cases, but it seems like a moot point since you'd have to send the (baked) textures over the network anyways.
---
As an aside to my earlier questions about rendering (past the edit window on my other post):
>HTML5 builds uses the Mobile OpenGL ES 2 rendering code path and use WebGL internally and should be at feature parity with Android/IOS as a thumb rule.
Given that, the following seems to give a good idea of what the WebGL compile target is capable of as far as rendering features:
https://docs.unrealengine.com/latest/INT/Platforms/Mobile/in...
I'd say there still remains some ambiguity in certain areas, though. While mobile and WebGL compile targets both share the OpenGL ES 2.0 limitation, mobile seems far more performance-bound and that appears to influence its feature set accordingly.
https://forums.unrealengine.com/showthread.php?48463-HTML5-C...
>5. My Game doesn't run.
That section outlines the memory concerns that I failed to articulate earlier.
Assuming it's still true, then it seems half a gigabyte is the upper bound. This would then preclude precomputed lighting in most cases, but it seems like a moot point since you'd have to send the (baked) textures over the network anyways.
---
As an aside to my earlier questions about rendering (past the edit window on my other post):
>HTML5 builds uses the Mobile OpenGL ES 2 rendering code path and use WebGL internally and should be at feature parity with Android/IOS as a thumb rule.
Given that, the following seems to give a good idea of what the WebGL compile target is capable of as far as rendering features:
https://docs.unrealengine.com/latest/INT/Platforms/Mobile/in...
I'd say there still remains some ambiguity in certain areas, though. While mobile and WebGL compile targets both share the OpenGL ES 2.0 limitation, mobile seems far more performance-bound and that appears to influence its feature set accordingly.
(WINDOWS ONLY) :(
That's just building that is Windows-only, obviously the apps will work on any reasonably modern browser. And OSX support should likely come as soon as they can package the tools properly.
Do they mention output file size?
As a semi-recent Unity Developer, I find myself really wanting to jump ship to Unreal, really great stuff all around.
I really, really, REALLY hope that Unity fixes their editor UI in version 5 (I haven't tried the beta yet, so maybe it's the case already), but as it stands right now I can't use Unity for long stretches (visual impairment). The font rendering in the editor is terrible, even at 1920x1200 the text is too small (froget about Retina even). This has been a problem with Unity for YEARS, which is a shame because it's a great tool otherwise.
I'm still torn between the two tools, they're both fantastic for different reasons, but if Unity 5 can't fix their editor then I think I'll have to jump ship just out of necessity.
I'm still torn between the two tools, they're both fantastic for different reasons, but if Unity 5 can't fix their editor then I think I'll have to jump ship just out of necessity.
Same. Can someone pitch in please?
Unfortunately some more Googling has turned up a disappointing result:
http://forum.unity3d.com/threads/how-to-change-font-size-in-...
The thread has a recent answer down the bottom.
It amazes me how this has seemingly been such a low priority item for the Unity Editor team for so long. This is a tool that people are expected to live in for an extended amount of time. This problem needs more widespread recognition than it's getting.
http://forum.unity3d.com/threads/how-to-change-font-size-in-...
The thread has a recent answer down the bottom.
It amazes me how this has seemingly been such a low priority item for the Unity Editor team for so long. This is a tool that people are expected to live in for an extended amount of time. This problem needs more widespread recognition than it's getting.
Don't you think it not getting more widespread recognition means this isn't affecting as much people as you think?
That's a valid point, but I wonder how many people just don't complain but would be more productive if this were addressed?
The absence of a fix is frustrating but not in and of itself - I know what it's like to have an old codebase and the massive job that it can be to retro-fit a feature like that. I just wish that Unity had given some proper statement on it over the last few years. The editor is the face of their product - you're expected to spend a great deal of time in the tool. This _has_ been a frequent complaint (just Google 'increase Unity editor font size' for example).
I just wish there had been one statement as in "we know it's an issue, this is what we're going to do to fix it / this is why we want to fix it but can't right now". It's an issue that plenty of people seem to be having - I mean, anyone who owns a high-DPI display is going to run into it and there are many threads on the forum about that kind of thing.
I'm glad at least to see that they've started working on it. I hope it makes it into the 5.x cycle.
The absence of a fix is frustrating but not in and of itself - I know what it's like to have an old codebase and the massive job that it can be to retro-fit a feature like that. I just wish that Unity had given some proper statement on it over the last few years. The editor is the face of their product - you're expected to spend a great deal of time in the tool. This _has_ been a frequent complaint (just Google 'increase Unity editor font size' for example).
I just wish there had been one statement as in "we know it's an issue, this is what we're going to do to fix it / this is why we want to fix it but can't right now". It's an issue that plenty of people seem to be having - I mean, anyone who owns a high-DPI display is going to run into it and there are many threads on the forum about that kind of thing.
I'm glad at least to see that they've started working on it. I hope it makes it into the 5.x cycle.
Quick question, have there been any UE4 engine games released yet? I see tons of Unity stuff. I really wanted to try Unity but just can't afford their pricetag.
What price tag? Unity is free. It doesn't start costing money until you need to start doing slightly more complicated things or your revenue goes over 100k annually. That's plenty of time to experiment.
Not exactly free. I would like to learn from the pro version, but not at the price tag they charge:
http://unity3d.com/unity/licenses
I can learn from crippled free version, but eventually I'll be running into things stating "you need the pro version features for this, this, and that".
With UE4, $19 got me full engine to mess around with.
http://unity3d.com/unity/licenses
I can learn from crippled free version, but eventually I'll be running into things stating "you need the pro version features for this, this, and that".
With UE4, $19 got me full engine to mess around with.
What is crippled about it? The company I work for literally builds games and we very rarely have to use any of the pro features.
The free version contains nearly everything you could ever realistically want to do. And some of the "pro" features can easily be written into the engine manually. The only hard and fast licensing requirement is the sub-100k revenue requirement. Up until then, Unity is about as free as it gets.
The free version contains nearly everything you could ever realistically want to do. And some of the "pro" features can easily be written into the engine manually. The only hard and fast licensing requirement is the sub-100k revenue requirement. Up until then, Unity is about as free as it gets.
> The free version contains nearly everything you could ever realistically want to do.
Except publish to something other than desktop windows - or has that changed?
Except publish to something other than desktop windows - or has that changed?
You can publish to OS X, iOS, Android and Windows Phone on the free license of Unity.
Major restrictions are no render to texture and a Unity splash screen on the app boot.
I suspect html5 will be supported in free Unity 5.0 (it is in the pro version currently in beta).
Major restrictions are no render to texture and a Unity splash screen on the app boot.
I suspect html5 will be supported in free Unity 5.0 (it is in the pro version currently in beta).
Good to know. Thanks!
This wasn't obvious from their site.
This wasn't obvious from their site.
I'll give it a shot then and see what I can tinker with :)
That's far later. You might not even get there. Download it and start tinkering around if you're interested.
There is also a free 30-day trial. That should be long enough for you to realize if you want it or not.
There is also a free 30-day trial. That should be long enough for you to realize if you want it or not.
$19/month for the SDK + 5% of your sales.
The subscription entitles you to updates, but you can cancel it and still have access to the SDK, it's tools and can also release yr game without an active subscription. The 5% is still applied, but you have to reach a certain sum of sales before it's incurred.
5% only applies after $3000 per month per title. Per Tim Sweeney himself.
https://answers.unrealengine.com/questions/15056/need-some-c...
https://answers.unrealengine.com/questions/15056/need-some-c...
Wow, thanks for the link. Looks like a pretty decent sized list of games.
There have been a few. Murdered: Soul Suspect, Daylight, and D4: Dark Dreams Don't Die being the biggest ones.
Wikipedia has a list of a lot of titles either out or in development: https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Un...
Wikipedia has a list of a lot of titles either out or in development: https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games#Un...
Will the UI render correctly on a retina display? One (I know I know) minor quirk that always gets me about Unity is how crappy it looks on newer Macs.
Can this be used as a standalone 3d Engine without it being scene based for iOS applications? That is the big issue with Unity - and most engines actually - which keeps us from using it.
We can't find a robust (UE/Unity level) mobile 3D Engine that is not scene based or just built for level based games.
We can't find a robust (UE/Unity level) mobile 3D Engine that is not scene based or just built for level based games.
Not sure what the exact ask is here. Are you building an open world or virtual world game? Do you just want a 3D renderer without the game engine? Both Unity and Unreal 4 can be used for non-level based games, and Unreal has some special facilities to support that (world compositor specifically - https://docs.unrealengine.com/latest/INT/Engine/LevelStreami...).
Looking for an open world/3D renderer for AR rendering that can handle a lot of Polygons, textures and lighting. We don't need a game engine with physics and all that as it is but down the line, physics might be handy. A lot of the renderers like Ogre3D do too much file handling - we need something more bare bones.
OpenGL is what we are using but we would like something more powerful.
OpenGL is what we are using but we would like something more powerful.
Surely AR would be scene based? You've recognised an object through VR, you want to display a note near it, it would be much easier to specify that relative to the object (scene based) than relative to the bottom/left/close corner of the image (world space).
Not in the same "scene" sense that you have dedicated levels like in a game that load statically. With AR, you are generally putting an arbitrary model into the 3D rendering environment and then using different sensors to "place" it accurately.
Traditional game engines want you to build levels/scenes inside of their editors like Unity, as opposed to being an open engine that you can feed in real time from a separate library.
So yes, AR is based on the scene you are "shooting" at the time, but not the same way that game engines are built to be generally static at the time of loading.
Traditional game engines want you to build levels/scenes inside of their editors like Unity, as opposed to being an open engine that you can feed in real time from a separate library.
So yes, AR is based on the scene you are "shooting" at the time, but not the same way that game engines are built to be generally static at the time of loading.
I understand what you're saying - you need dynamic environments. Minor terminology quip (which might make discussion easier in future): that's a very different concern with being 'scene based', which is a specific term the 3D industry uses to mean 'items are located relative to their parents in a tree shaped data structure called a scene graph, and not absolutely positioned in world space'.
I only have one scene in my Unity games. I load and do everything I want with my own custom code. The feature to use scenes is there, but I don't bother to use it. Just like Minecraft clones built in Unity, the scene is empty, the code does all the work dynamically loading and displaying the level.
Engine-supported scenes are a convenience, you don't need to use them if their cons outweigh their pros.
Why is that an issue on iOS? Genuinely curious.
I believe the issue is that scenegraphs tend to make spatial partitioning more difficult, which means culling objects that are out of view is more difficult.
Depends on the application. For us we just need an open 3D rendering engine that allows for good lighting and textures.
How does the Unreal Engine compare to the CryEngine? I've the impression it's more efficient, this is important to get the best performance out of VR games.
People who develop on Unity: How does Unity compare to Unreal performance-wise? The only experience I have with Unity is playing Kerbal Space Program which is often a performance nightmare and I'm wondering if it's Unity or the game developers.
I don't know compared to Unreal but Unity has several hidden performance issues. I am currently working on Bullet Boy [1] and we had several obscure problems that you have to fix with a lot of trial and error. Specific combinations of components and attributes can cause frame rate to drop because of the internal organization of the engine (moving colliders without rigidbodies comes to mind).
That being said, it is really easy to use. The asset pipeline is great and artists learn to use it very fast. It works really well for small teams.
My recommendation is that you should consider it if you are not planning to make a very performance intensive game.
[1] http://bulletboygame.com
That being said, it is really easy to use. The asset pipeline is great and artists learn to use it very fast. It works really well for small teams.
My recommendation is that you should consider it if you are not planning to make a very performance intensive game.
[1] http://bulletboygame.com
Off Topic: For some reason on Chrome 40.0.2214.111 I can't click the play button on the YouTube video of your bulletboygame.com site.
Edit: The cloud-right div covers the top three quarters of the video player.
Edit: The cloud-right div covers the top three quarters of the video player.
Bullet Boy looks amazing.
Regarding Unity vs. Unreal, it looks to me like Unity is better for targeting mobile devices, at least if you're planning to deploy this year. Last time I played Tappy Chicken, it devastates my batter and makes my phone hot enough to cook on. Unreal has amazing advantages for the desktop, but it doesn't look to me to be a good way to make mobile games.
If I'm wrong about this, someone please tell me, because I'd rather use Unreal, but I need to deploy mobile, so I'm using Unity.
Regarding Unity vs. Unreal, it looks to me like Unity is better for targeting mobile devices, at least if you're planning to deploy this year. Last time I played Tappy Chicken, it devastates my batter and makes my phone hot enough to cook on. Unreal has amazing advantages for the desktop, but it doesn't look to me to be a good way to make mobile games.
If I'm wrong about this, someone please tell me, because I'd rather use Unreal, but I need to deploy mobile, so I'm using Unity.
Great game! Good luck finishing it!
I think developers looking for Unreal performance from Unity 3d will be disappointed. What Unity has over Unreal is C#, great interactive tools (a live stage within a running game), and the ability to publish to just about anything.
> live stage within a running game
Isn't that also a big selling feature of Unreal 4?...
> and the ability to publish to just about anything
Likewise with Unreal 4, except that they have a flat-rate for platforms, instead of expensive add-ons to support more platforms. (and no browser plugins required!)
Isn't that also a big selling feature of Unreal 4?...
> and the ability to publish to just about anything
Likewise with Unreal 4, except that they have a flat-rate for platforms, instead of expensive add-ons to support more platforms. (and no browser plugins required!)
Um, no AFAICT? Unless things have changed Unreal is no where near as interactive as Unity. Unity is an app (a game editor) designed to make games. Unreal is a game engine with an editor tacked on to make it editable. That difference in approach makes a huge difference in the experience of using each to make a game.
I'm sure you unity devs will laugh at this but in general Unity is designed to not crash. It's an app. Its document is a game. Unreal on the other hand is a game that assumes you have no bugs. By that I mean being a game it assumes the end goal is shipping code. It's not designed to be an editor so it not designed around being stable. It's designed around game code not editor code. If you want to edit code live requires you to use XCode or Visual Studio. If you make a mistake the game crashes taking down the editor (since that's running in the game) and everything with it.
I'm sure you unity devs will laugh at this but in general Unity is designed to not crash. It's an app. Its document is a game. Unreal on the other hand is a game that assumes you have no bugs. By that I mean being a game it assumes the end goal is shipping code. It's not designed to be an editor so it not designed around being stable. It's designed around game code not editor code. If you want to edit code live requires you to use XCode or Visual Studio. If you make a mistake the game crashes taking down the editor (since that's running in the game) and everything with it.
This the kind of stuff that gets me to leave HN. Random people downvoting what are basically facts, at least they were as of last June
I have licenses to both Unity and Unreal and have personally shipped 17 commercial games and written their engines from C64 all the way through 360/PS3. It's not like I have no clue
And yes you can downvote this shit too but gees. Nothing I said above is false. Post some counter facts if you disagree.
I have licenses to both Unity and Unreal and have personally shipped 17 commercial games and written their engines from C64 all the way through 360/PS3. It's not like I have no clue
And yes you can downvote this shit too but gees. Nothing I said above is false. Post some counter facts if you disagree.
Put a while(1) in one of your game scripts in unity and let me know how great it is
Yes, Unreal Engine 4 Editor has a live stage running within it that you can interact with in a very similar manner to Unity. I have worked with both tools and found them similar. The primary motivator for me to choose UE4 is that I always have the option to drop down to C++. I can implement game features or fundamentally change the engine and editor if I have a clear need.
Xamarin supports C# for Unreal with Mono:
http://mono-ue.github.io/
http://mono-ue.github.io/
Two different engines optimized for different purposes but in general Unity will run much better on low-end hardware than Unreal. Unreal has a renderer that is (out of the box) definitely aimed at high-end hardware.
KSP's performance is probably bound by a physics system that is abnormally complex for games. Unity's version of PhysX is based on an older, slower version. Unity 5 brings that up to date so if Squad decide to continue development on 5 there should be some improvements straight away. Unreal uses the same physics middleware out of the box.
KSP's performance is probably bound by a physics system that is abnormally complex for games. Unity's version of PhysX is based on an older, slower version. Unity 5 brings that up to date so if Squad decide to continue development on 5 there should be some improvements straight away. Unreal uses the same physics middleware out of the box.
I suspect it's a bit of both. My money's on Unreal as the highest performing in terms of fancy graphics. However, the "game programming" can vary hugely from game to game, even in the same engine. It's probably hard to compare the efficiency of game logic outside of game-to-game cases.
I have had faster development using unity.
I guess UE doesn't really target small games? When I think of Unreal Engine I think of AAA FPS Games with amazing graphics, but has anyone actually used it for small indie games?
Also nice to see it's opensource, I guess I read the news a couple of months ago but I forgot. I had no idea.