Pls stop release bugged updates.

Pls consider again doing updates once per 1 year.

0.5 year developing, 0.5 year testing/fixing.

Do more quality, less features.

I like the current pace of features and bug fixes.

Bugs will get fixed faster if they are released to the public for testing. If they spent 6 months working on new features, they could be building all kinds of systems on top of a corrupt foundation without fully realizing it.

Better to have lots of user feedback throughout the process.

You don’t have to update your current ‘stable’ version.

0.5 year developing version 1,
0.5 year testing/fixing version 1,
0.5-1 year feedback/fixing version 1, while developing version 2 cycle.

it wont matter if they spend 0.5 year fixing bugs only to reintroduce them the minute they add the next feature, better to get it all out then fix them otherwise its just gonna be a constant back and forth with it

also you can always find a stable build and stick with it instead of upgrading to the latest

They cannot do it for financial reasons. In order to keep you subscribed every month they have to give you something every month. It’s tricky situation indeed.
I definitely like the updates and fast fixes, but I definitely don’t like the instability which comes with it. Every coin has two sides I think.

Oh my god, it’s Christmas, I finally find a complaint [joke] :rolleyes:

If you read last release note , they are working hard for it

I vote for:

.1 Year New Features
.1 Year Fixing New Features
.1 Year New Features

I would love to see the numbers, but I doubt the subs actually produce that much revenue for them. Even if they have 20K subs, that is only $4.8Mil a year, and Epic makes $50-100Mil per year. Hardly a drop in the bucket worth making such major decisions over. I am pretty sure they are more intent on producing the best product they can, which is why they are not waiting half a year between feature releases.

Right now there are 17k member on github and that’s only the people with a linked account so 20k is pretty fair. Since the target is the indie market you can not expect people to stay subscribed while no releases happen and going a one year subscription for 140 bucks is already a lot higher point of entry and will intimidate a lot of people to even try it out.

Yes it’s only 1/5th to 1/10th of the income but why would you just throw those away for longer development cycle?

Epic did exactly that in previous versions of UE and it was a hard slap on the wrist. Some guys from Ubisoft even made a song about how long it took. (The Codedrop Song: Unreal Engine in 2001 - Unreal Engine).
To be fair it’s not directly about the long development cycle but the occasional super long once. But the same issue is created with super long cycles.

It was a different time and it would probably work a bit better nowadays but why not ship features in early stages? They are labeled and called “early versions” or even “experimental” but you can already look at them, do some feature requests and so on.

Developing blind is rather risky and yes the builds do not always get an experience boost but as long as you wait for the full release of a version I didn’t really have serious issues with bugs and if there are any (and there were as you can see in the answerhub and the forum) they usually got fixed with the next version or the version after (if it was close to the release).

Now if there is a bug (and there will always be bugs. Let’s hope we always only run into minor once) it can be fixed within one or two months. Well within your development time for really just about any game. On the other hand if you do super long development cycle (like a whole year) a but will stay this whole year. You also can’t show off new features or give away anything for 3/4th of the year at all because it’s not tested at all. You’d basically cap the connection to all your developer (with that I mean game devs. Unreal Engine users) for over half a year.

You can see pretty much all across the board that companies go through short development cycles and larger once maybe develop a couple larger features in the background and use the short development cycle to properly implement and test it but over all the features, bug fixes go out sooner and feedback helps greatly to enhance them and fix them up.

TLDR: Long development cycle are no guarantee for a system with less bugs or better features. But any issues will be there for a very long time which has a larger draw back than gain.

@OP: This pretty much sums it up. If you are unhappy with the quick releases and new features (not sure why … but anyway) then rather not upgrade right away. I for one am grateful that we get regular updates … so thank you Epic. 8-}

It is clearly said that we are early adopters of the engine, something like beta-testers. The engine is in the pahse of very rapid evolution, because it’s new, planned fgeatures have to be implemented, and actually many features make a more fullfilled development experience. Of course, there are bugs, and we should just report them on the answer hub.

Oh, we go over it again ;).

What is better I ask ? Wait half year for new feature (without knowing it is developed, knowing how it will work etc), and then after half year, get it broken, not meeting requirements, and in mean while it broken other parts of engine, because there is only so many people at Epic who can test it and develop it.

Right now, we get early access to all new features, you don’t want to use them ? No problem. Just don’t. New feature had broken old feature ? Write bug report, which allow to reproduce it. Whining that “this **** is broken, fix pl0x!” won’t get you anywhere.
If you have ever developed software bigger than command line calculator, you would know that there 2376897 more issues, waiting to be solved, which are properly documented and you know where to look for them. Some stupid 3 line post which do not explain anything, is not even worth considering.

Now we get feature fast, lots of people (including me), are using those early features, even if they are broken or will be broken because they will change. Now imagine how it would look, if only handful of people in Epic tested it before release… They are good, but time is not infinite resource (;. At least not yet.

I am on your side. :slight_smile: I just said that they aren’t going to have a short dev cycle just to keep subs up because the amount of money isn’t that big to them. They have quicker releases because it makes for a better product, which makes better games for them, as well as more royalty money from other people’s games. So basically I don’t think the sub money drives their release cycle because it isn’t a big enough pool of money.

My vote was for the status quo, .1 year = ~ 1 month releases.

I like the monthly updates for sure, it’s definitely the way to go.

I would like to ask Epic to step up their internal QA of builds though - the last few releases have had some pretty serious issues that probably shouldn’t have made it into a build ready for public consumption. 4.5 had completely broken context sensitivity as an example, which made working in Blueprints a complete and utter nightmare.

Hey ambershee -

If you are building from source via GitHub, the internal branch of the engine is actually completely available to the public. All you need to do is compile from the Master Branch which is the same Master Branch we use internally. We do not recommend people compile from this branch because while it may fix one or two issues which got to release it will absolutely break more because it has not gone through our QA testing yet. We’ve recently implemented the new Preview Release schedules for our engine releases starting with 4.7.0 Preview 1 to allow earlier access to user’s who can help us track down more bugs and ultimately have a more stable major engine releases.

Thank you all for your input though this is all excellent feedback.

I like the way updates are rolled out too.

Hi Eric!

We’re indeed compiling from Github, but we’re taking the release builds when they become available since we’re working in a production environment. It’d be good to be able to integrate critical fixes without needing to wait for the next version (which can be as much as two months away), but there doesn’t seem to be a good way of keeping track of specific issues and their resolution status? Preferably though, it’d be better if release builds really didn’t have critical issues that are severe enough to handicap something like Blueprint, hopefully your new preview releases will help catch that better.

Like the particle color values being broken in cascade. Workarounds are great but… A lot of us especially when broken things are related to art we aint coders nor have the tools nor should we need VS to compile a patch. The preview builds sound great but wont work as i already mentioned a preview build (since) already had a broken feature yet it got released like that and had to wait for .7 (IF) it would be fixed. Some stuff are broken and i don’t understand how they make it to release while everyone knows they are broken. Sooner or later by ignoring small errors you will end up with whole chunks of tools being broken. I’ve seen it before.

What I suggest is that for known errors a quick patch to be released, It seriously will take less time for you guys to copy paste a chunk and let people download rather than an Artist taking his whole day trying to understand what is going on (as a figure of speech).

Seems simple to me. Only update once a year.

He has a point.
The new features sometimes break stuff that works before.
If there has to be bugs, at least bugs should affect new features only.
So Epic developers should take a breath and check codes more before publishing it.