Announcement

Collapse
No announcement yet.

4.7 -> 4.8 conversion quality assurance insufficient

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    4.7 -> 4.8 conversion quality assurance insufficient

    Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
    I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
    It is really big, and it takes a lot of time to discover things like 'generate overlap events' and so on being switched off after conversion for some actors.
    Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
    Not to mention physics being completely different.

    I perfectly understand why the Ark Survival guys were still on 4.5.
    It is really high risk for a large project to update with sloppy conversion stability like this.
    If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
    I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.
    Last edited by MaZi1; 06-21-2015, 01:45 PM.

    #2
    4.8 Is what finally drove us away from the engine for the type of game we are creating. It had a slew of bug fixes and features that were necessary for our game, but would require us to essentially re-do 6+ months of work. The inconsistencies between PIE, AMI, and the cooked version were just to insane.

    Unreal seems like it is a perfect choice for larger titles that have the resources to lock into a version, and a team that can pull bits of the repository to fix what they need. It also seems like if you are sticking to the "Unreal method" for physics and pawn interaction, PIE/AMI behave correctly.

    Unreal is not acceptable for any other type of smaller game that breaks those rules, nor is it really all that great for 2D. We ended up switching to Unity, and bypassed our progress in Unreal within days.

    Edit: Please know, I am a huge fanboy of Unreal and Epic, it really bugs me to say this. Unreal is a wicked awesome tool, it just wasn't right for our needs. Epic is epic.

    Comment


      #3
      I get where you are coming from and not trying to be offensive but switching to unity because a new UE4 version breaks compatibility.. doesn't make any sense man! .. you can always stay in 4.7 (that's kinda what you are supposed to do when your game is far in development), or are you are saying that 4.8 has a magical new set of features that every game absolutely needs to be further developed?

      Besides UE4 has a much more rapid development cycle (every UE4 release is HUGE, from what I have seen it doesn't even remotely compare to unity) which means you get tons new features each time (but with the added risk of breaking compatibility).

      But don't get me wrong, I absolutely agree that this is a problem and Epic needs to be more careful (like a LOT more careful) with backwards compatibility and properly document any potential compatibility-breaking changes, give us alternative code, examples, how should we go about this now etc.. for example lots of internal changes were made with physx, destructibles, overlap events etc. and there is literally no details about any of that in the 4.8 changelog! not cool.. the changelog is in many cases more like "titles" of the changes rather than actually explain the actual changes.

      The behavior on one of my games changed completely because of couple of changes and took me forever (well okay not that long ) to understand what runs different and why.

      I mean thank goodness for Rama and his transition threads which can help with some of that (I seriously have no idea what the community would do without this guy at this point ) but this shouldn't be the responsibility of the community though.. at least hire the guy or give him a grant or something just saying.

      4.10 Update! -> [Community Project] WIP Weather & Ocean Water Shader
      WIP Interactive Water Shader, WIP 2D Water Sim
      WIP FFT Ocean w/ Foam, Quad-tree Infinite Ocean LOD

      Comment


        #4
        Originally posted by MaZi1 View Post
        Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
        I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
        It is really big, and it takes a lot of time to discover things like 'generate overlap events' and so on being switched off after conversion for some actors.
        Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
        Not to mention physics being completely different.

        I perfectly understand why the Ark Survival guys were still on 4.5.
        It is really high risk for a large project to update with sloppy conversion stability like this.
        If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
        I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.
        Hi MaZi1,

        Unfortunately, this is something that is always a possibility when converting between engine versions and is why we highly recommend sticking with a single version unless you need to update to a more stable build or the new build has features that you need to work with. There is a possibility of corruption between engine versions, workflow changes may occur, or new bugs could potentially be introduced that can cause an unknown number of errors. Upgrading every version in a main project is always a risk with software that is under active development. If you do convert to the next version, always ensure that you make a copy of your project as opposed to converting in place to ensure that, if there is a problem, you have a way to backtrack to a stable point. Additionally, please make sure to report the bugs on the answerhub (http://answers.unrealengine.com) so we can address them as quickly as possible.

        4.8 Is what finally drove us away from the engine for the type of game we are creating. It had a slew of bug fixes and features that were necessary for our game, but would require us to essentially re-do 6+ months of work. The inconsistencies between PIE, AMI, and the cooked version were just to insane.

        Unreal seems like it is a perfect choice for larger titles that have the resources to lock into a version, and a team that can pull bits of the repository to fix what they need. It also seems like if you are sticking to the "Unreal method" for physics and pawn interaction, PIE/AMI behave correctly.

        Unreal is not acceptable for any other type of smaller game that breaks those rules, nor is it really all that great for 2D. We ended up switching to Unity, and bypassed our progress in Unreal within days.

        Edit: Please know, I am a huge fanboy of Unreal and Epic, it really bugs me to say this. Unreal is a wicked awesome tool, it just wasn't right for our needs. Epic is epic.
        I'm sorry to see you go, The Britain, though we certainly understand that you need to use the tool that is best for your project. Hopefully we'll see you in the future when the engine better suits your needs. Is there anything in particular that were trouble spots for you or that you think we could do better? We're always willing to hear suggestions on what we can do to deliver a better overall experience!
        Adam Davis | Marketplace Support | Epic Games
        How to report a bug? | Installation & Setup issues? | Answerhub Bug Reports | Twitter

        Comment


          #5
          Sometimes you have to update for key features, for example 4.8 allows for the first time to ship in 64bit.

          I agree that the change log should contain more explanations. It is only a titles collection - for example PCM for physics.
          I know this comes down to the developers. If they do not do it, all the non-dev guys are helpless. Some time ago it was mentioned that you have 'Epic Fridays' where everyone can do/try what they want. Make those really epic and make all developers write docs and code examples of what they do! See Unity API code snippets in their doc.
          I am a bit afraid UE4 will never reach such a well documented state, because I do not see the time coming where you slow down a bit between versions and take your devs for a few weeks to actually document what you are doing.
          Unity and other engines employ much more people, so it might be easier for them, but in your case it makes little sense to add and add with many users who potentially make a game that brings you revenue actually shying away from updating. I would happily pay a subscription fee to see more resources and a better documentation as a result. Anyone who goes for a revenue generating and larger game would. I am sure the ARK guys would. Documentation and stability/reliability is what makes the difference between freeware and paid-for software after all.
          Last edited by MaZi1; 06-22-2015, 01:08 PM.

          Comment


            #6
            The problem with the advice of "stick with 4.7" is that this is a fine recommendation if 4.8 isn't a big deal... But what about next month when 4.9 comes out? Or two months later when 4.10 comes out? What if one of THOSE engine versions finally fixes a bug you've been trying to work around?

            Unless 4.7 is totally perfect for your project (and let's be honest, that's the case for approximately 0% of users) it's a huge mistake to hold off upgrading because when you finally DO, ALL of those accumulated break-and-fix moments occur at the same time, and the whole process becomes infinitely more painful as a result.

            So that's easy talk to talk but it doesn't change the reality of more or less needing to upgrade if there are any major bugs or important features even remotely visible in the pipeline for the future.

            Comment


              #7
              Originally posted by TK-Master View Post
              I get where you are coming from and not trying to be offensive but switching to unity because a new UE4 version breaks compatibility.. doesn't make any sense man! .. you can always stay in 4.7 (that's kinda what you are supposed to do when your game is far in development), or are you are saying that 4.8 has a magical new set of features that every game absolutely needs to be further developed?

              Besides UE4 has a much more rapid development cycle (every UE4 release is HUGE, from what I have seen it doesn't even remotely compare to unity) which means you get tons new features each time (but with the added risk of breaking compatibility).

              But don't get me wrong, I absolutely agree that this is a problem and Epic needs to be more careful (like a LOT more careful) with backwards compatibility and properly document any potential compatibility-breaking changes, give us alternative code, examples, how should we go about this now etc.. for example lots of internal changes were made with physx, destructibles, overlap events etc. and there is literally no details about any of that in the 4.8 changelog! not cool.. the changelog is in many cases more like "titles" of the changes rather than actually explain the actual changes.

              The behavior on one of my games changed completely because of couple of changes and took me forever (well okay not that long ) to understand what runs different and why.

              I mean thank goodness for Rama and his transition threads which can help with some of that (I seriously have no idea what the community would do without this guy at this point ) but this shouldn't be the responsibility of the community though.. at least hire the guy or give him a grant or something just saying.
              This isn't a Unity vs. Unreal debate, I know those are popular. Unreal destroys Unity on a whole bunch of facets.

              4.8 doesn't have a magical set of features we need, it has massive bug fixes. The differences between AMI/PIE/Cooked was KILLING US. We would spend DAYS wrestling with the physics system, only to find it acted completely different once compiled, and completely different from that once cooked. The 2D feature set is nearly unusable for anything but a basic 2D game.

              Yes, it was 6 months of work, in Unreal. It is day 7 and we have now bypassed our progress in Unreal. Our game is a 2D smash clone, except using ponies (judge that as you will). We originally changed from Game Maker, and let me give a run down on some of our problems. [See response to Adam.]

              Originally posted by Adam Davis View Post
              Hi MaZi1,

              Unfortunately, this is something that is always a possibility when converting between engine versions and is why we highly recommend sticking with a single version unless you need to update to a more stable build or the new build has features that you need to work with. There is a possibility of corruption between engine versions, workflow changes may occur, or new bugs could potentially be introduced that can cause an unknown number of errors. Upgrading every version in a main project is always a risk with software that is under active development. If you do convert to the next version, always ensure that you make a copy of your project as opposed to converting in place to ensure that, if there is a problem, you have a way to backtrack to a stable point. Additionally, please make sure to report the bugs on the answerhub (http://answers.unrealengine.com) so we can address them as quickly as possible.

              I'm sorry to see you go, The Britain, though we certainly understand that you need to use the tool that is best for your project. Hopefully we'll see you in the future when the engine better suits your needs. Is there anything in particular that were trouble spots for you or that you think we could do better? We're always willing to hear suggestions on what we can do to deliver a better overall experience!
              Oh, don't get me wrong. I love Unreal. I went to college for Unreal 3. I think Unreal is untouchable for extensible power. Here is why we switched to Unity, and how we were capable of outdoing 6+ months of development in Unreal, in now, 7 days:

              1. We need DX and DI controllers to function in a way that the computer acts like a 4 port console. Even with a plugin, access to controller related hardware info is abysmal, we don't have the resources - in a free fan game - to constantly re-code a custom controller plugin between versions.

              Unity: Allowed us to access each controller via string at a hardware level. In this way, we have seamless XInput and DirectInput, this allowed me - without a plugin - to code our controller base in 2 hours.

              2.This is a 2D fighting game, and heavily based on frame information. Even with the 4.8 update, there is just no way to reliably get which frame you are on. This would be fine, but there is NO 2D ANIM GRAPH. That makes creating a 2D fighting game difficult to impossible.

              Unity: Unity has a 2D anim graph, 2D animation events, and 2D frame access. Basically, any information you would ever need is easily AND RELIABLY accessible.

              3. The physics engine is unpredictable and touchy if you are doing anything outside of a 3D game with standard physics. I complained about this before, and the response was "recode physX". Really? Our tiny team is suppose to recode part of an engine to make a 2D fighter? It wouldn't be so bad, but you are basically forced to use the physics system if you want to use collision, and even that is hit and miss.

              Let me give you an example. Let's say you are building a side scrolling shooter, with a ship moving forward. So you set your ship to flying. Now, you add colliders to the top and bottom of your screen. Your ship will get stuck. It doesn't matter if you only use collision on the capsule, it will eventually get stuck. How did we fix that? We made sure to set the ship back a few pixels on collision, so we had ugly jitter.

              To make the camera follow at the same speed, but keep it dependent of the character, we had to add a movement component so we could set and get its velocity.

              Unity: Let's us use transform.translate for movement. It just works. The collision is smooth and non-overlapping. That's the key, it just works. If I add a rigidbody2D, it just works. No character movement component to fight with, just a couple of simple variables. Everything else is controlled by our own code.

              4. Speaking of custom code, we did just that. Over and over since 4.5, we would re-code our custom plugins that fixed allot of what Unreal needed for our game, and the updates just kept breaking that. It wasn't a compatibility thing either, we literally had to re-code them. The differences in the physX engine changed, and changed, and changed, with each release, completely breaking our plugins.

              Unity: We haven't dealt with updates, but from what I can tell, they are pretty good about not breaking your existing code.

              5. No frustum code. Why? Why in a modern engine do I still need to add the math for camera bounds? This is a core component of our game.

              Unity: Built in frustum access.

              6. Why do I need to run a console command in Unreal to set the resolution? Why is resolution support so difficult? The quality scale curve doesn't work for every game, especially 2D games.

              Unity: One command on our persistent object for a fixed framerate, fixed size, and fixed VSync setting.

              7. The sprite pipeline is insanely time consuming. I think Unreal has some awesome advantages when it comes to how you handle sprites, but it is all to much.

              Import Texture (tell it half the time that it isn't a normal map) -> Right Click Create Sprite -> Select Sprites and Create Flipbook -> Wrestle with Flippbook.

              This increases the build size and causes us nothing but headaches.

              Unity: Drag PNGs in, select PNGs, drag to scene. Animation is created. No extra assets.

              8. Build size. Our game, deployed, was 2GB in Unreal.

              Unity: Our game, deployed (with the same resources), 532MB.

              9. Binary assets are a pain in the ***. I understand that the Unreal engine is large and storing blueprints as XML or whatever might be difficult, but I can not express how hard it is to share and diff assets with other programmers in Unreal. There isn't even documentation on what folders are needed and what are not when setting up a repository. I finally figured out that you can delete the binaries,intermediate, and saved folders.

              Unity: We have the option of using free Bitbucket because our source isn't of an unwieldy size. We can easily diff between programmers.

              10. Visual Studio is antiquated new technology (excuse the oxymoron).

              Unity: Mono is SO much lighter. I don't need to wait 10 minutes for auto-complete to show me a list of functions I don't need. Sure, I could buy a solution for VS, but that's nuts. We are not going to throw money at a problem that shouldn't exist in the modern programming world.

              11. The Unreal API is frighteningly large. This isn't a complaint, it's a compliment. Unreal has a bigger one... ;p

              Unity: But... For our little programming team, it would be to much for us to tackle fixing the bugs hiding in the source. We are forced to update, and that's where we come back to square one.

              12. The difference between PIE/AMI/Cooked is just insane. It's unusable. The only way we could figure out what our game was ACTUALLY going to do involved cooking the game, every time.

              Unity: WYSIWYG. (For the most part...)

              13. Undocumented weirdness when it comes to cooking. Did you know that you can't have a _ in your stage name or the cooker will fail? Sometimes. Sometimes it will magically work, and then on the next cook it fails until you take the _ out.

              14. TERRIBLE file manager. The file manager leaves ghost files behind. That bug from 13 took forever to debug, because even after renaming our stage, we still received the cook error. It wasn't until then we realized we had to hand remove files.

              Unity: Just works.

              15. Please, kill the pawn spawn system (or at least let us get rid of it ourselves). I see what Epic is going for, but it just doesn't work. I don't mean it is hard to use, I mean it LITERALLY doesn't work. As an example, we are trying to spawn 4 different players that are a child of a parent pawn class. Sometimes it works, sometimes it doesn't, sometimes it will change its mind, even in a cooked build.

              Unity: Simple instantiate. Nothing to it. I had the correct players spawning every single time with no issue.

              Every single one of these issues has not only been reported, but I gave a sample of our game to Ben, I believe. Support vanished after the $20 fee was waived.

              Please know, I love the work you all do. I really love Epic and Unreal. It just isn't right for our game. These complaints are specific to our game, and if we were building an insanely simple 2D game, or a 3D game, the story may be different. Also note, C++ is not one of my complaints, I think people who complain about which language they are using are insane.

              We can't fight with these bugs any longer. It's just not possible when a working solution is right in front of us.

              Originally posted by MaZi1 View Post
              Sometimes you have to update for key features, for example 4.8 allows for the first time to ship in 64bit.

              I agree that the change log should contain more explanations. It is only a titles collection - for example PCM for physics.
              I know this comes down to the developers. If they do not do it, all the non-dev guys are helpless. Some time ago it was mentioned that you have 'Epic Fridays' where everyone can do/try what they want. Make those really epic and make all developers write docs and code examples of what they do! See Unity API code snippets in their doc.
              I am a bit afraid UE4 will never reach such a well documented state, because I do not see the time coming where you slow down a bit between versions and take your devs for a few weeks to actually document what you are doing.
              Unity and other engines employ much more people, so it might be easier for them, but in your case it makes little sense to add and add with many users who potentially make a game that brings you revenue actually shying away from updating. I would happily pay a subscription fee to see more resources and a better documentation as a result. Anyone who goes for a revenue generating and larger game would. I am sure the ARK guys would. Documentation and stability/reliability is what makes the difference between freeware and paid-for software after all.
              I want to pay! Damnit, it means a better engine, I WANT TO PAY. Epic, I want to give you my money. I want to feel like I have the right to complain about issues, but our team ends up keeping it internal and trying to play whack-a-mole with the bugs. Those that can't afford $20 can't afford to develop a game. The minute Epic went free with Unreal, the support I was getting vanished.

              Comment


                #8
                Thanks for the list the Britain, really interesting to read!

                I guess UE4 is just not yet a good choice for a 2D game. Epic is working on improving the paper 2D stuff, but Unreal Engine was never really designed to be used in 2D games in the past I think, so it might just take some more time until UE4 is nice to use with 2D.

                I did never had really big problems with the conversion from one version to another. There were some issues, for example my AI worked in 4.7 and stopped working in 4.8, but only because I relied on the behavior tree to continuously runing after unposessing the pawn and posess a new pawn. In 4.7 it worked and in 4.8 it did not, but as always I wrote a bug report and until now I never have gotten no assistance on bugs from epic. So after 1 or 2 days Miezsko explained to me that this is actually intended and that it worked in 4.7 was wrong, but he will add a bool to tick to get the old behavior. Until this is added I can just workaround it, some hours of work, but not days or weeks, and the workaround works fine now for me. When it comes to AI, Mieszko is always there to help, he is awesome
                Another problem from 4.7 to 4.8 was that updating Instances stopped working, but after some hours I found out that there is just one wrong default bool which I have to tick and then everything worked again.
                The worst issue I got with 4.8 is that destructible meshes now can't get hit by a trace in the frame they were spawned, which worked fine in 4.7, I have not yet found a solution to workaround it, delaying the trace one frame should work. The bug is only the worst new one because it will probably not getting fixed because destructible bugs are backlogged, so introducing new bugs which won't get fixed is of course a problem.

                But all of these problems were reviewed by Epic really fast on the answerhub, I generally never experienced that Epic ignores bug reports. Some bugs never seem to be get fixed, but they always get looked at from Epic on the answerhub within some days. You can look at my profile on the answerhub, I have around 50 bug reports there and even more where I not myself asked the question but continued the discussion in existing threads. I always got really nice support from Epic.


                So I can't really comply too much, although I have already done it enough in various threads Yes UE4 is buggy and I absolutely hope they will do something like a 4.9 which is mostly only focused on stability. I also really would like to pay 20$ a month for supporting Epic. But I have not noticed any difference in the support from before GDC 2015 and after. Support from Epic was always really, really, really good. There are so many really great guys working at Epic and helping us, this alone is already enough for me to not even think about switching to Unity.

                I just hope I will ever be able to ship a game with UE4... At the moment the problem is just that I sometimes feel as if more new bugs get introduced than getting fixed. One single bug can be enough for not being able to ship a game, because it breaks stuff that is just needed. At the moment there are still at least 4 of these bugs in UE4 which makes it impossible for me to ship a game. One of these is that my game just crashes after being packaged, but that's most probably fixed in 4.8.1. Another one is flickering trees, I can't ship a game with trees which flicker once a second. Another one is the drastically decreasing performance after a certain amount of destructible meshes is reached, and another one is artifacts coming from drawing lines in UMG. This will also be fixed in 4.8.1. So the ones not getting fixed are flickering trees and destructibles, and both are "backlogged", so it might take 2 years until these are fixed. So I might need to wait 2 years until I can ship my game. Yeah, that's a problem, and that's why I hope for 4.9 being a bug squashing release.
                Easy to use UMG Mini Map on the UE4 Marketplace.
                Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                Comment


                  #9
                  Originally posted by John Alcatraz View Post
                  and another one is artifacts coming from drawing lines in UMG. This will also be fixed in 4.8.1.
                  Nope, I told you it was 4.8.2 on AnswerHub :P

                  Comment


                    #10
                    Yeah thanks Nick, does not matter whether 4.8.1 or 4.8.2 The only important thing is that it get's fixed
                    Easy to use UMG Mini Map on the UE4 Marketplace.
                    Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                    Comment


                      #11
                      Originally posted by The Britain View Post
                      We would spend DAYS wrestling with the physics system, only to find it acted completely different once compiled, and completely different from that once cooked.
                      I am pretty sure they attempted multi-threading with 4.8, but not very successful.
                      As a result, the physics are completely backwards-incompatible now.

                      See here about PhysX 3 and multithreading/performance
                      https://www.youtube.com/watch?v=ZtcAOQv9GWs
                      (starting 38:00)

                      Unity got it working, but they have Anthony. Epic does not have Anthony, so there are a few guys trying, but with less success.
                      You can see 'asnyc' everywhere in physics related tabs now in 4.8 and it refers to the asynchronous scene, i.e. multi-threading.
                      I just switched off everything that is new in the physics tabs to have it half-way working. For example, if you constrain two bodies, and one is in async, then they fall apart.
                      Even with all new things switched off, spring forces are different and all that.
                      They should not release something in that state. It is not release ready, if you convert 4.7 -> 4.8 and your project is completely blown apart.

                      Originally posted by The Britain View Post
                      I want to pay! Damnit, it means a better engine, I WANT TO PAY. Epic, I want to give you my money. I want to feel like I have the right to complain about issues, but our team ends up keeping it internal and trying to play whack-a-mole with the bugs. Those that can't afford $20 can't afford to develop a game. The minute Epic went free with Unreal, the support I was getting vanished.
                      Same here! Maybe make a basic support subscription or similar, along with the free non-support version.

                      I can not say for sure, because there are many variables involved, but the moment Epic went 100% for free, could as well have been the beginning of the end for them and a bad lomg-term management decision.
                      There are for sure huge numbers of beginners attracted by this. They will ask huge numbers of questions and will completely flood the Epic human resources (see answer hub madness -> it is not going to stop). The result is a really stretched thin Epic. As a result of that, there will be less quality. The thing is, the huge number of beginners will not generate revenue, and teams who potentially make it to steam or wherever will go away because there is no basic reliability/stability in the engine anymore and/or you have to battle with very basic things that come essentially on a silver plate and as one-liners in other engines.
                      I think it all comes down to company size and what you can do with it. Epic has only 100-150 employes, Unity ~500, Crytek ~ 500 and AAA companies many more. This is why you could bypass 6 months of UE4 in 7 days in Unity, TheBritain.
                      Essentially, with such a small number of employes, you can not stretch as thin as Epic is doing. It will backfire.
                      Last edited by MaZi1; 06-23-2015, 04:10 AM.

                      Comment


                        #12
                        The Britain made a good post there, all stuff worth taking on board! A lot of it like the Large API that Unreal has and the use of Visual Studio instead of Mono or other compilers probably isn't stuff that's easily fixable, but in terms of use-ability there's a lot of good info there that can be used I think.

                        I have to say I agree on the sentiments of the File Management system. The redirectors are horrible to work with, especially when your project is maintained with Source Control, you end up with hundreds of 1-4Kb files left behind every time you delete or move something, which isn't helpful. The only way around it is to go into explorer and (carefully & painstakingly) delete the files manually, then re-open the Engine and fix all the reference errors. Usually, that's quite a long process.

                        In terms of Comment 15 - what part of the Spawn Pawn system is the problematic part? I've not had too many issues with it so far in honesty - though it was difficult to set-up a reliable system for spawning players as DIFFERENT pawns. Eventually got it working but not in the way I'd like. Unreal Tournament has a system for that now, but UT's source isn't very well documented or commented so it can be hard to follow at times.

                        ---

                        In terms of the issues of updating between Engine Versions, that should really just be expected. The problem with keeping backwards compatibility for everything is that you end up with a messy codebase with a mixture of the old and new, and even bigger Engine sizes. It's just not worth it, and that in turn also decreases engine stability as well. It's far easier for dev teams to spend a month upgrading their project should they have to.

                        I keep having to say this to people, but you should NEVER instantly upgrade your working project when the Engine releases a new build. Always wait for the first hotfix at least, and when you do it, create a Branch in your source-control provided of choice and upgrade slowly. When you're happy that the game is stable, move everybody over to work in that branch. This isn't anything unique to Unreal, this is pretty much industry standard. Otherwise, you're effectively stating that you trust 100+ engineers that know nothing about your project, to make a huge upgrade to your codebase.

                        ---

                        I also don't believe Epic would switch back to a subscription model now that Free has been done. A lot of people who feel entitled to all these free tools would start kicking off and boycotting it (meh, good riddance) - but the main reason behind going free is to just get people using the Engine. The more freelancers and indies use the Engine, the more big studios will eventually have to front the money for the proper engine licensing (24 hour tech support, in-house engineers etc). Of course, a lot of those studios are actually developing their own engines as well. Ubisoft, EA, Naughty Dog etc. all have their own tools respectively. Anyway I could start raving on about that aspect of the industry but that's for another topic...

                        I didn't have an issue with the £19 a month either, it was still a bargain either way.
                        Last edited by TheJamsh; 06-23-2015, 04:54 AM.

                        Comment


                          #13
                          I agree it's not reasonable to expect continuing backwards compatibility between versions. The problem with saying we should just lock in to an existing version for the remainder of a project, though, is that as yet I don't think there has been a sufficiently stable release. As was said above, most of us don't have the resources to fix bugs or shortcomings in the engine ourselves. So people are effectively forced to upgrade in the hopes that the latest release will sort out the issues that are preventing their project from working; not because they just want to take advantage of new features.

                          If there was an engine version where all major issues with its core features were resolved to a reasonable point, then I think people well into their project would happily stick to it. But as has been said many times, this is never going to happen when every major release comes with a slew of new features which will inevitably introduce new issues and knock on effects with existing features.

                          Rather than designate a version as a bug fixing release, I'd suggest Epic designate a version as a stability oriented one and continue to focus on stabilising it even as it is superseded by subsequent versions. I think that's the only way we'll get to a stable version while still allowing new features to be constantly added to the engine for those that want them.

                          Comment


                            #14
                            Originally posted by MaZi1 View Post
                            I think it all comes down to company size and what you can do with it. Epic has only 100-150 employes, Unity ~500, Crytek ~ 500 and AAA companies many more. This is why you could bypass 6 months of UE4 in 7 days in Unity, TheBritain.
                            Really? How can this be? Why does Unity have 4 times as much people working on compared to Epic? I thought it would be the complete opposite... I mean, Unreal Engine 4 is far more advanced than Unity (Unity is not really called a AAA Engine), Epic is also working on 2 games and not only UE4 while Unity only works on their Engine, Unity uses a ton of middleware for everything while Epic tries to make most features completely themselves (so that they can share the source), and generally UE4 is advancing faster than Unity as far as I can tell. What are Unity's 500 people working on?
                            Easy to use UMG Mini Map on the UE4 Marketplace.
                            Forum thread: https://forums.unrealengine.com/show...-Plug-and-Play

                            Comment


                              #15
                              Originally posted by MaZi1 View Post
                              Not sure, but maybe it is possible to keep a better eye on backwards compatibility between versions.
                              I just spent three entire days retuning my project, that I worked on for many months, after switching to 4.8.
                              It is really big, and it takes a lot of time to discover things like 'generate overlap events' and so on being switched off after conversion for some actors.
                              Effectively, you have to do an entire beta-test again to discover any potential conversion flaw with a conversion like this.
                              Not to mention physics being completely different.

                              I perfectly understand why the Ark Survival guys were still on 4.5.
                              It is really high risk for a large project to update with sloppy conversion stability like this.
                              If it is like this, you have to run the entire beta tests again, all basic things, because you can not rely on clean conversion.
                              I know you are just a small company and other engines have more testing people and developers at hand, but please be more careful next time.
                              I'm doing the same thing. I took a look at 4.8 and my game had several issues. Being so far into development and looking to release in August, I believe I'm going to stick with 4.7 because when switching, there could be an issue that creeps up when only certain actors interact with each other. I did notice that the physics change some too. Again being so far into the game, these things change the whole feel of the game once levels are designed around specific settings. Love the features but I think I'm going to have to wait til my next project to utilize the new engine features. Converting from 4.6 to 4.7 wasn't to bad for me. I do believe that UE4 is at a point where you can take a build and stick with it and develop with the tools available. There's plenty to work with.
                              Last edited by Isaac Nichols; 06-23-2015, 12:43 PM.
                              Isaac Nichols
                              Game Developer & Music Producer - Threaded Pixel Studios
                              Currently working on Drones & Ruins a Sci-Fi twin-stick shooter.

                              Comment

                              Working...
                              X