Unreal engine is used by students and indies to make commercial projects, it can suit lot of different people. You have some longer learning curve than Unity, but my self i got a game in some weeks, all tutorials on Youtube and from the forums helped me a lot. I encourage you to ask for help and answers on the forums, you will always have someone to help you or give you some directions.
Using Unreal engine is like learning to drive Supercopter, it’s not easy sometimes but once you get it right, it blows everything.
Just my two cents.
Epic is aware of API documentation and missing samples code, this should expand soon.
yes I have but it still not good, although I didn’t need to try it because I knew how to make a vehicle like that before the advanced template existed.
appearances can be deceptive.
well the only thing really missing is wheel collision but its not what’s missing it’s the fact that what is there is bugged, since you said GTA I might as well use it as an example, so if you drive a car in GTA the body leans with accelerating and turning but the body sits roughly in the middle of the suspensions travel but because of a bug(there is a fix but it’s not implemented) in UE4 vehicles bodies rise up to there highest point when you go ever 18KPH witch is something you wont see in just about any car game ever made, on top of that there is also a bug with the tyres the handbrake and wheels.
the physics of the sedan is the same as the advanced vehicle just with a few tweaked settings.
unfortunately yes there issues with crashes and hitting other cars.
that being said unlike tegleg I don’t think UE4 needs a new physics engine for vehicles but it does need the bugs fixed and exposed to the blueprint settings.
The only thing I see is stating UE being “bad” and Unity being “good”. Which is kinda stupid because I work with both of them and both have pros and cons.
Unity is good for mobile but its development is slow. It took 2 years for Unity to implement some kind of useful GUI elements (compare that to 6 months for UMG in UE4, even less if we talk about experimental stages). Unity was 3 months late with 4.6 release (they announced that they would release that in summer but didn’t). And you can’t speed this up. Epic gives us source code, so if you need something you can add that or improve things that are already here. Can you do that with Unity? Nope. You’ll have to wait till they implement that (if they ever will, of course).
I give Epic credit. They don’t promise things if they are not on their roadmap nearest markers. And they do things they promised. And do it fast. 2 months cycle is crazy.
All that UE lacks is some technical details that work out of the box. Right now it’s 100% ready for work tool.
I have my own critique for Epic but frankly speaking all those things could be done if I hired bigger team and implemented it by myself. It’s just a matter of time and money. If you need it faster you spend money doing it by yourself, if not you can wait till Epic will do it for you (just for $19/mo, btw). The core thing is that Epic gives you the choice.
The negative feedback can be useful if it helps to solve problems and improve the engine. This one doesn’t. Thread starter created two threads about the same “problem”. The problem is that he “hates f*cking C++, C# is easy”. Yeah right… very helpful feedback.
I’m primary a C++ developer (non-game stuff).
I’ve been interested in unreal engine from the start. I’ve tried to evaluate it (have used the first version and then 4.4, 4.5 versions). But after some testing I came to the conclusion that it isn’t suited for our needs (mainly my needs as a programmer).
We’re making a 2D isometric game, so I needed the robust 2D framework. But the Paper2D is only at the beginning - no real documentation there, some API missing. The documentation of the engine (I don’t mean tutorials but proper documentation) is very sparse, if any. Also the development with Unreal is kinda slow if you don’t have really great documentation. What I’m missing are some high level docs of the engine, that is what is loaded first, in which order objects are loaded, which functions are ran, how the things are handled, what is done level is loaded, how to extend editor, serialization, etc etc. And then would like to have some high level for each module (Paper2D, …). Also compile times are rather large but that isn’t problem of the Unreal (or maybe is, it could have something to do with build tools?). I like that unreal provide source code, because it is very valuable in situation where there is some bug and you need fast patch. I like that unreal has some goals it is aiming for, that is to be a robust, extensible, generic engine and don’t sacrifice the power over the simplicity of transforming everything to the button of “Make my game”. So even if I think that C++ is superior to the C# and the Unreal is from the design perspective superior to the unity, we’ve choose the unity.
Unity got some own problems, mainly the bugs (that aren’t fixed) you hit if you’re making something advanced than a little demo or tutorial. The lack of API - exposed API is really poor comparing it with Unreal. Unity documentation is moderate and there are far far better documented product than unity (but it is better than unreal one). Also we needed to use external 2D plugin (2dToolkit) because the unity built-in 2D wasn’t sufficient for us (in my opinion it is useful only for their 2D tutorials, anything beyond it and you hit the problems). The forums there are crowded with noobs whose basic knowledge about programming or making game is little or non-existent and lot of the interesting stuff in the forums is buried under the “how can I make my super game?” posts (I think this is because the unity tried to advertise itself as “everyone can make a game, now”). Also rather than trying to solve the long-standing bugs and usability features, they’re adding the features which aren’t so necessary - this because they don’t “eat their own dog food” and cannot even see the problems you’re encountering when you really dive in some advanced stuff (on the other side, epic is on opposite site which is greatly contributing the good engine design choices etc.). But even then I think that I’m more productive with Unity than Unreal.
But I’m always monitoring the unreal engine progress and hope that in 1 year the 2D stuff could be shaped up to at least what 2DToolkit provide for the unity.
So what? Having plenty of students and hobbyist’s is great for the community. Not only does it cycle in more money for Epic so they can continue to up the stakes, it also brings a larger knowledge pool into the community. They may not have the man power or the funding to create the next Gran Turismo, but neither does that matter.
I’ll agree with a lot of points here, the grass isn’t greener on the other side. UE4 is allowing is to make the game we wanted how we wanted it, Unity was a nightmare to work with (Especially with lack of 64-bit editor, we switched before their beta but I’ve messed around with it and it’s buggy, I can’t really tell any difference between U4 with Lux shaders and Unity 5. Finally Enlighten is slowwwwww!.).
Then again UE4 is very rough in some places and some might not agree with me, but they might be the exception not the rule. UMG is still experimental which is fine, it’ll get there and general performance has been horrible. Which you can’t convince me it should be because CryEngine ran fine with bigger scenes on worse hardware whilst looking better. Even between UE3 / UE4 (from what I tested), the difference isn’t big enough to warrant the pounding our test platforms get…
But still, the saving grace is the sheer power of the engine. The amazing tools and above all most importantly the Epic staff without that I’d probably go custom built being honest.
It is one of the best non-custom engines I’ve ever used period, it just needs a lot of TLC. Which will come in time…
Are there really many major differences in terms of the software/API architecture, like considerations for threading or content loading or physics API design, which would dramatically change your approach or your project’s coding design? C++ and C# differences, or specifics of rendering and physics, in practice?
The thing I am most concerned about is C++ build times being unusably slow for me, so I am adding C# support in my own specific way (no plugin). I considered remote procedure calls and inter process communication… new territory for someone who’s never even near-completed one game, but the state of UE4 right now makes this a necessity I feel. Sure, it will get better. But right now I need a streamlined iteration workflow.
Which is why I separated it into UE4 C++ (“renderer”) and C# (game logic), this way I can get started for a very quick mockup and move Actors around from C#. Custom serialization and so on. But most important, is that I’m really confused about the intersection of editor and the ingame runtime. It seems editor access is stripped out of the code that you can run “ingame”. So this makes me uncomfortable and I’d rather code everything myself so I know it works (spawn X object here). To me getting started is far more important than the speed the game runs at.
one of the thread starters other threads has info on bugs and lack of documentation witch even the epic devs said was useful feedback, he has also linked in a few threads that show some of the things he has issues with. sometimes just knowing people are so dissatisfied with anything UE related that they want to leave can then let epic see if they can improve in that area to make peoples experience with UE better so it can still be useful even if its only slightly useful.
I agree the first post could have been more in depth when first created.
Thing is do you honestly think Unity will be your saving grace though? You’re either stuck with a limited set, or a limited set and a buggy engine in it’s latest iteration. CryEngine is a pain to use to the point of a no-go and as buggy as the rest.
So the only thing you can do is keep working through it, tell Epic exactly what’s the problem and work through it together. If Epic don’t sort out the performance issues by release date, I will drop it in there laps and say hey guys what can we do about this?
Now here’s the impressive bit, they will actually help me.
Also price, forget about $1500.00 for pro (-tax) so you can actually use post and a profiler. Then you have to buy a slurry of third party assets and still not come anywhere close to UE, which are sometimes buggy within themselves. That’s if they don’t dump production after they decide it’s not worth it.
Personally I’d like a UE supported scripting language, doesn’t have to be C# but could be. But it’s not a deal breaker, as the end goal always is and will be, get that game out so I can keep a float.
Games no-matter what you use are hard and painful and yes I’ve lost my rag with UE4 a fair few times, but you just have to keep going. Work on something else and report the bug…
they know what the problem(s) are and are working on it
or use another engine that does what you need, then come back to ue4 some time in the future.
what gets me is why people are so amendment that ue4 is this magical 1 size fits all solution when right now it clearly is not, maybe one day it will be.
I’m not a fanboy with blinkers on sir, I know the flaws in CE/UE4/Unity and I still think UE4 is in beta being honest. Just saying make the best of what you have.
If UE isn’t for you than cool, I’m sure were all mature enough to say fine it’s not for you we wish you the best of luck. But at the moment I’m giving UE it’s dews, it gets better all the time and anything I needed fixing Epic has been great with me. So I still highly recommend it.
Let me know how you get on and hope to see you back :).
I actually consider these things to be downsides. Both are nice things to have when debugging, but you shouldn’t have to pay the penalty all of the time. Games can and should be able to guarantee some level of determinism unlike applications like tools, so paying for things you really don’t use is a problem. The primary things C# provides is the excellent reflection and module system, and the faster compile times (which is partly a result of the first thing).