UE4 3k price drop and democratization

On a related but slightly more subversive note... I teach at one of the top Art and Design colleges in the US. For a while, we had a butt load of Unity installs and game design classes where students learned Game dev though Unity. Unity was "all that..." Well, UT changed the rules for Schools and the installs came out and the game design courses went away this year. Fast forward now to Fall 2014. We will have a butt load of UE4 installs and the courses are coming back. Guess what our next generation of gaming professionals now want to learn and will grow their experience in and develop their undergrad projects in? Studios will have a fresh workforce trained up and ready to hire. Epic realized same as Autodesk, that early indoctrination is the key. This is why we are stuck with teaching Maya almost to the exclusion of all other 3d software. The studios count on a software specific workforce.

When UT changes the rules for EDU licenses, I firmly believe that Epic saw the opening and slid right in and seized the gold ring.

 

+1

Epic's response might as well be UT's own fault.
There have been numerous complains about their Pro Addon prices in the past as well as their ridiculous subscription model.
Blinded by money...

 

@ Sandboxgod, I wouldn't trust the inbuilt FPS / latency counter as far as I could throw it (with it being virtual not very far). I was looking through the source nearly everything is GPU bound especially the editor functions. So you'll never get a true reflection of the speed, best thing to do is to use chronos and a print at build time. It's not hard to do..

@ Outto, that is very interesting.. It could be a reflection of the next generation?

 

Seems to me that you're all pressuring Unity to use royalties. Isn't that a step backward?

 

I think that what I would do is.

* Raise the license fee to $5000 per seat but include PC, Android, Linux, iOS and Mac
* Release the full version, with source
* People can use the engine, but if they publish anything they have to get a per seat license

I don't think Unity's problem is the price per se. I think Unity's problem now is... that devs have to front-load costs modularily depending on what they want to do. I don't think the cost is that much of an issue, and a lot of people will probably prefer to know the actual cost rather than the more nebulous per cent of royalty. In the end, I think it will even out.

 

Royalties are not a step backwards. In fact, royalties can be a step forward when implemented correctly. Epic's UE4 offering reduces risk for the little guys and hobbyists. For as little as $19, a newbie can download UE4 and piddle around with it. Some people will only play around with the tutorials and demos, and other people will try to make a game with it. For those who make money with UE4, there will be a small royalty to pay on revenues beyond the first $3k per quarter.

Most people will never need to pay any royalties, because most people will never sell enough games to generate the revenues needed to trigger the royalties. The people who do need to pay royalties are going to pay them out of the revenues they made selling their game, so the royalty is not a problem. The cool thing about Epic's subscription model is that the risk is not front loaded. A little guy with big dreams is out $19/month, and can literally ignore the royalties until he gets lucky with a hit (which is of course very unlikely anyway).

Epic has come up with a subscription where the little guy is not scared to pay something each month to tinker with Pro grade tools. Epic will collect $19/month from everybody that dreams of making a game, even if most of those people fail to bring a game to market. The $19/month portion of the subscription will bring in an easy $100 Million per year once a few hundred thousand dreamers are signed up for the service. The 5% royalties portion of the subscription is most likely in place only to prevent the $19/month subscription from cannibalizing existing UE sales to big AAA game developers. I seriously doubt Epic cares as much about the 5% royalties as some people believe. The Epic subscription is all about getting $19/month from as many dreamers as possible.

Unity could copy Epic's plan, and it would yield awesome results. If there are currently 2 million Unity Free users, then it would be easy to convince a few hundred thousand of them to pay $19/month to upgrade to a Pro level subscription. Most won't worry about the 5% royalties. Those who make enough to worry about the 5% royalties can simply pay up front for Unity, just like they already do. In other words, Unity could use a 5% royalty system to protect the sales of $1500 licenses. Anyway, Unity could milk millions of dollars from existing Unity Free users simply by copying the pricing and terms of the Epic UE4 subscriptions, and there would be nearly no risk of losing the $1500 up front sales because of the 5% royalty in the subscription model.

The real question at this point is why Unity has not already done this. Unity could grab millions of dollars right now from existing Unity Free users. That is a huge opportunity for Unity, and it makes no sense not to do it.

 

Why not one-up Epic and just release Unity Pro, and only demand payment if you actually make a game? I think that this was Unity's original method, but they found that a lot didn't pay, and they changed it. It will probably be the same now, but I'm not sure that there's a choice any more. UT may have to accept reality, and hope that the ones who pay make up for the lost opportunities. Epic did change everything, and I think one-upping them is the chance to get back an advantage rather than to just 'keep up'. The former is being progressive to changing circumstance. The latter is just reacting to event, and being driven by events.

 

That would one up Epic for sure, and it would lead to significantly more sales in the Unity Asset Store (which Unity takes 30%). I am not sure how Unity would solve the problem of people not paying once their game sells, though. And it would still suffer from not making money for Unity unless a games sells, while a low cost subscription model would collect money from people regardless of success or failure. However, I admit the sales from the Asset Store could make a lot of money.

A low cost subscription model (like $19/month) could actually make quite a bit more money for Unity. Once Unity convinces a few hundred thousand Unity Free users to pay $19/month, Unity would collect an additional $100 Million per year. That is big money where I come from. If Unity offered a $19/month subscription plan, they would be flooded with signups. $75/month (or $225/month for mobile) sounds like a lot, but $19/month is practically free. It would be easy to convince many thousands of Unity Free users to pay $19/month for Unity Pro.

 

What if UT is already paying royalties or some other yearly payment for each pro copy and for some/all of the stuff they have licenses and are available to pro users which then cover the costs currently? how do you think it would work?

Epic stripped out all 3rd party stuff from UE4.

 

Unity Pro being free would decrease sales of quite a few assets.

 

So? Basic functionality shouldn't be for purchase add-ons anyway. It's not in UE4 and can't be now in Unity. Assets should be the ingenious little work-saving snippets of code, art assets, and extended functionality. It shouldn't be things like profilers and flipping lighting.

 

I do believe Unity needs to review their price models and adapt to new market trends which is very low entry price points. But not a royalties model, I believe if Unity reduce their current prices without any royalties they will remain competitive while allowing a huge amount of new low budget developers (students, artists, bedroom devs, etc). Let's be honest here, The Asset Store cannot fulfill the lack of Unity free features, simply because the free version doesn't allowed it, you have either to get pro or simply get stuck without important features. A good example is the lack of RTs support, no matter how badly you want shadows on UT free, you can't even create them or sell it to Unity free users, it won't show up.

 

I was going on the impression I get from reading up about this subject is that Unity is much faster without all the post effects than UE4 is capable of. The game I am working on (as are many other mobile devs) has performance as a main priority. The effect of post effects isn't a consideration in my decisions.

 

Well if you remove all the post fx from unreal on mobile and remove all the unity post fx on unity, unity's still faster at mobile. That won't change until epic can allow you to remove large chunks of their engine (which I believe probably is on the cards for a future update).

Regarding Tato's comments: I think perhaps its really a matter of keeping things as they are (base price and all) but just offering a cheap sub. I mean personally I will just buy if I can, mostly because I get really stressed out with book keeping or paperwork. It's my big weakness and I'd merely be offsetting any perceived cheaper cost by hiring someone to do it monthly.

I just want to develop and I want to do it as simple as possible with as much flexibility as possible. It's taken me 4 years to get where I am with Unity and to throw that away is difficult. I would use UE4 for a next gen title with a large team over Unity 4 in a heartbeat. But that is because I've not seen Unity 5 yet or felt it out.

 

Right now it costs 4500 for all those platforms and everybody is complaining about that, why would I want to pay 500$ more? To get sources? No one here seems to be interested in Unity sources, if you want to spend all your precious time fixing Unity bugs or broken features you better apply for a Unity job and forget about creating your game! And no, I got at my disposal a team of 160+ talented engineering working on Unity for me, I'll let them do what they are good at and let us create games! You don't need Unity sources either to integrate/create game dev tool anyway. ^^

 

Yeah, some people are complaining about it, but just because they're complaining doesn't mea that UT should cater to them. Maybe they are complaining just because they want UT to fulfill all their expectations, never mind everybody else. And I just think it would probably be worth a five hundred extra to know exactly how much you'd end up paying, rather than try to prophesize about potential roytalty-percentages in case of a hit.

 

My thoughts exactly, I have spent too much time, money (assets not Pro/Addons), and effort on Unity thus far to back out at this point, and even if I wanted to go over to UE I would have so much catching up to do (like say... learning C++!) that it would be a bad business move at this stage. I also have come to love the Unity workflow, and easy building of android APK's I get with Unity (well maybe UE does that too idk...). Maybe I might be swayed if I had a team but I have been sticking to solo projects, and for me to re-learn a whole new workflow... yikes...

Plus porting over my WIP projects to UE might not even be possible without some kind of C# wrapper/whatever (Read somewhere that somebody was working on such a thing), and if it was - it would be a nightmare to overcome obstacles that I have already figured out for Unity, plus I know some of Unity's limitations, and thus tread away from using it for certain things.

So if the day comes where I take a peek at what UE has to offer, it will be while still developing on Unity regularly I'd bet, and probably would never grow out of a hobby because I would fallback to what I know, Unity!... and for these reasons I think Unity isn't gonna be going anywhere... for a long time. Heck if the prices of competitors engines keep getting cheaper or even free, and the "new guys" who jump into game design start to flock to it - that will take the pile of poor quality apps/games developed in Unity wayyy down... which would take away some of the "It was a Unity game so it must suck" way of thinking (that I don't really believe in either - but thats a whole 'nother topic haha) that happens when people see the ultra-amateur stuff branded with the Unity splash screen... Although at the flipside, Unity would lose out on potential sales of pro/addons to those newbies who no longer think Unity is the bee's knees I guess.

 

Keep in mind that UE4 runtime is lighter than Unity's one, it have less memory footprint and better multicore support. If you are targeting mobile without any post process or heavy effect your games will run faster on UE4. If you are targeting next gen mobile devices with heavy post process, your game will look prettier and run faster on UE4. But I do agree that simple applications can be developed faster with Unity, no brainer.

 

The fact is that the initial investment difference between Unity and Unreal to get going (pro) is vast and won't be ignored by a lot of Unity users, no matter the previous learning investment. Besides that, a lot of coding experience can be cross applied.

From what I see UT really has no choice but to come with an offer that matches Epic's. If they decide not to do this, I expect lots of pro customers complaining big time, loosing loyalty and eventually make the transition towards Unreal.
I must say, Epic made a brilliant strategic move here.

 

UE4 does have batch rendering support and handles draw calls better. Maybe you are doing some funky weirdo stuff at runtime that brakes batching on your side? Even so, it shouldn't, you must have been running in a bug?

 

from tests I've made with an almost identical scene, same objects, same benchmark logic, with Unity the fps were higher.

people gives too much credit to UE4 like its an alien theology. in real life its not great in performances with an harder workflow then unity, but sure the particles looks pretty and the GI is nice.

which unity can solve both if they invest their money and time.

 

+1

 

If your scenes are equally setup (turn off EU4 heavy effects or add the same effects on Unity) it'll run faster on UE4.
Homework: Try this, on both engines add 500 animated characters in Unreal vs 500 animated characters in Unity, let's see who's faster.

 

If it can be done in Blueprints, it can also be done in code. Blueprints essentially allow you to access already existing C++ functions for rapid visual prototyping or even final game logic. As ambershee pointed out in your second link, he was able to successfully test batching support a few months before UE4 was released.

 

I should have mentioned it was in mobile environment, as its my only concern and the minimum performance line an engine should work from.

 

Unreal Engine is primarily a engine for PC and console games. That's their focus.
Not mobile games, although Epic tries to get into that lucrative market as well.

 

What have you tried to find out whether or not it's faster? The in built FPS meter can't be trusted as the API heavily adds to the rendering costs.. You can't use things like Fraps because it just lies ... We stuck in a toggle FPS counter for builds so we could actually get an accurate reading.

That being said, the batching and occlusion methods are far better. You can stick in god knows how many meshes or KM of terrain and it pretty much laughs at the situation. Post effects I found to make little difference whether they are on or not they just look good and are performance friendly, what seems to knock UE4 over is:

1. Particles, best looking particles I have ever seen but VERY heavy, 2. shadows and lighting, if you look at the PS4 version they have been stripped down a fair amount, lighting isn't too bad with pre-comp and lightmass but still pretty heavy (Don't mention static lighting ) 3. Shader complexity, well this goes for any engine but from the examples Epic seem to heavy handed with it although I'd gather it's because they want to make everything look as pretty as possible.

 

I like Unity Tech and their engine - I know that they will respond in one way shape or form.

 

I don't think they will, I'm sure they would have judged by pre order sales and if they were bad they would have already said something.

 

Well Unreal has never been known to be a lightning fast engine (at least prior to UE4) and that was when it was a forward rendering pipe. Vendors have achieved 60 fps (such as Injustice) but this isn't common. Since the Artists have so much control over the shader pipeline you will quickly find your Shadercache full of thousands of shaders. Not sure about ue4, but in previous revisions characters were rendering to their own shader map instead of using a frustum divider like Cascade Shadow maps + blurring the shadow map directly (Variance shadow mapping, see Crytek paper). Which is pretty fast. You can render the scene to only 3 small render targets and directly blur the map to achieve great results

Looking deeper into Blueprints it appears they are handicapped worst than UnrealScript lacking the ability to completely override their native counterparts. So Blueprint-Only games may/may not need exotic workarounds if they veer too far away from what Epic programmers intended. [edit- Actually, I guess UnrealScript couldn't override native functions either so BPs are no worse off]

Their C++ codebase is pretty massive like always. And just like I feared they are still assuming Z-Up or whatever. Unlike Unity, UE4 is not using Quaternions at the Actor scope. So doing true 3d math requires taking your Rotator into a Quat and back to avoid gimbal lock

Obviously, rapid prototyping has taken a dive and I have relayed this to Epic. Right now my game is small there and I intend to keep it that way. But if I ever added a lot of artists (which is easy to do in Unreal because the Art community is MASSIVE), your project will take longer to load in the editor. So when you restart the Editor you will experience longer loads. As I discussed with Epic on their forums, users on big projects will probably want an SSD drive. This is game industry stable. Every studio pretty much switched to SSDs around 2006 or even earlier.

All that being said, it is interesting technology and fun to play with. And you can try to compile your C++ code in the Editor but that appears to take bout 2 mins or so which is not ideal. What Epic engineers do is apparently load directly into the game with their changes. An SSD would probably significantly speed up the editor. I'll play around with this on another computer. Now- on a small indie project it seems to load in only 20 secs anyway.

Traditionally, a lot of your licenses will go with Unreal for the Tools. Because it gives Artists pure joygasms. But a lot of projects will rip apart the backend and significantly modify the front end client. For instance, DCUO went with a custom backend for their networking.

 

Just out of interest, where do you get the numbers for how much indies earn? Is there a discussion you have seen on the topic or do you speak with inside info?

 

I must say that I'm quite upset with the non-reaction from Unity's side. One month ago, I said that we'll see a response in a months time... but no...

My problem is that I'm currently doing some work for a customer. One of the requirements is that the software will run on Android and iOS (free versions are ok for this)... but I have to remove the splash screen... so, basically this means that I have to either directy lay down $3.000 or pay a substantial subscription fee (which is reduced for 1 year but since it automagically switches back to the full price afterwards, it's not a good offer... and it's still some $120/month).

UE4 isn't yet on par with Unity with their mobile stuff... so that isn't an option yet...

Gosh... those are some expensive splash screens.

 

sandboxgod just made the most sense I've read since this furore began.

 

Aren't they covered in your pricing..?

 

I "only" have the Unity Pro license but to remove the splash screen in Android and iOS versions, I must purchase the Pro licences for those...

 

I find it strange that this is nowhere mentioned on unreal page except that one answerhub post.. I'd think this is a big change yet no official anouncement,

 

Unity may not change anything.

 

A simple way for Unity to compete with UE4 licensing is to give all current Unity Pro owners full source including Android, iOS etc for existing versions including Unity 5. Then offer a monthly subscription plan like UE4 for new Pro users which includes source and features updates only up to the dates you subscribe to. I smaller one time fee could be added for Android, iOS etc. I think Unity users would pay the little bit extra for that as it's more optimized than Epics. This way they don't piss-off the current Pro owners and are matching Epics business model with a similar subscription plan.

 

But what makes you think they could even do that? Epic probably could not either from price or license point so they removed all external stuff from the engine source code. Now Unity has a lot more stuff licensed which they probably don't have rights to redistribute. Stripping em out would cripple it completely.

 

That isn't for indies, it is for the games category in general. It isn't really inside info, stats and reports are available from from a variety of companies. That particular number was from year end 2013. You can get detailed breakdowns of just about everything that happens on the app store.

 

A DTR should be even faster, there was always a solid reason to use DS because of consoles.

Blueprints are there to speed up some iterations of coding and for artists to test out their work, whilst it's possible I presume to make a full game in it logic dictates one wouldn't. I wouldn't like to debug a large scale RPG in blueprints.

Well this is something I'll have to look into, you're saying Epic couldn't figure out how to avoid gimbal lock when you can just GIT examples with all the quaternion classes containing transformation matrices and math done for you to avoid it? Even my rice pudding of an engine doesn't have issues with this, it would be amateurish at best if this is the actual case.

Our prototyping speed has increased 10 fold, then again we have a lot of engineers and artists with a lot of experience. We use WD Raptors and our storage devices for all the artwork are on 2TB 7.2K RPM drives, editor loads like lightning for us.

I don't agree with Hippo and I don't see your angle on this, Unreal Engine isn't a rendition of my first engine. I said before it has a higher learning curve than Unity then again in many ways it's simpler for larger teams to get things done. It's a benefit and downside, sure UE4 is not great for beginners (In some respects) but for teams who work in the 3D sector it's probably the best tool out there at the moment for fast iteration. Modifying backend systems is a given for mainly any game of decent stature, the beauty of it is I can and the core functions are there so I don't have to start from scratch. You should of seen all the tools we made for Unity and it still doesn't match up..

It all depends on what angle you're approaching it from? For people who are used to making games no matter how big or small, none of what you mention is an actual issue.

 

I personally don't really care about source code, especially when we talk about huge projects. I prefer to construct over and finish a game faster instead trying to understand some one else code and losing time with that. The game engine is here because we don't have time to do it, not because we cant.

 

+1, make games not engines. Even though it's fun to dabble and branch, I'm past the day of caring and just want to focus on making a good game..

 

I thought my post was really clear. Try running a character upside down. You will have rewrite some small parts of the movement code to accomplish this feat or do exotic workaround due to them using Pitch/Yaw/Roll (and they add to the Pitch directly in PlayerController.cpp). Typical gimbal lock issue. Not an issue for FPS games obviously but it is an issue for other types (see current ongoing thread where a dude is making a Sonic-type game)

Unfortunately I'm in a hurry again- so I dont have time to respond to any other points.

 

Most cannot.

Debugging issues with your engine or your code it can help a lot to have the engine source code. You just step into it, you don't need time to learn that (if you are an experienced coder). You only look at the piece that is relevant to you right now.

Often you realize some corner case of an API you use with looking at the code for less than 1 minute, where looking through all documentation would take way longer (if that corner case is documented at all). Or immediately realize that you use the API in a wrong way. Or you immediately see that the engine has a bug in this case.

Why do all large studios want source code access? Because it makes your work more efficient if you have the coders that can use it. Most of these studios will not do many changes to the core engine. Having the code is very valuable for other reasons.

 

I've only found it useful so far for bug fixing, but when you're paying for said item who's responsibility is it for bug fixes?

You still need to reverse engineer what someone else as done, as much as people say avoid delegation etc. etc. It's still generally used all over the place you change one thing and it can end up kicking you somewhere else. If it was just that easy to read some code and have all the answers people wouldn't shy away from CryEngine as much.

It's use is limited, but I don't look a gift horse in the mouth. It's better to have than not to have even if I do find it low on the food chain.

Why AAA's want source code is so they don't have to keep buying expensive upgrades every iteration, much like them I'd rather have more staff to finish off my game than pay another studio millions to keep the core tools ticking over. Look at Arkham Knight it's UE3 with a new shiny lighting system..

 

Ok, it depends on the beauty of the code.

But look at the issue about UE4 being z-up discussed on the previous page. With source you can change that if you need. This is not a hard change like a new lighting system. But nice to have if your game requires that. There sure are many such small issues if you don't want to adapt your game to the engine instead of the other way around.

And I'm bad with APIs (or RTFM), so I often find out I use it wrong when stepping into source code to find out why it does not work the way I want.

As you said, source code is often not needed but nice to have still.

 

That still falls as a bug, now when there is an issue with support from said company source code then becomes VERY important, so it's not like I completely disagree with you here. I just don't think it's the selling point for UE4 or most engines with decent support staff, if you have a closed engine with crashing bugs going on for months if not years then as I say, that source code becomes all the more appetising.

 

For me it is a huge selling point. If the community is big, it will do a lot of stuff that the core developers don't have time for. Fixing bugs fast, adding simple new features or even complex ones.

E.g. I think UE4 will get small binary builds for mobile, even it is not a priority for the core devs. But someone in the community will do it for sure. They will just create custom build options to rip out most of the engine that is not needed. If the previous 10 years of software development have shown one thing, then that no company can compete against a large community of dedicated developers.

 

I'd love to agree with you, but look at Ogre, irrlicht etc. they have been royalty free open source and nothing bar torchlight has come out of them. Plus I think you're over estimating how many people could do this sort of stuff. I know it will be great for clean integration with middleware developers but for the rest of us it won't ever make a huge impact. Plus for our sort of game there is little the engine doesn't do already, also if you're making a game worth it's salt then when do you have the time to do all of this?

I could rip out and upgrade tons of stuff in UE4 I'm quite partial to building my own engines etc. but I don't think I've touched a piece of core rendering code since I started making actual games. Also if I'm going to go that length I want some money for that time, I don't live off fairy dust.