Forgot your password?
typodupeerror
Programming Games

Switching Game Engines Halfway Through Development 127

Posted by Soulskill
from the don't-change-horse-renderers-in-the-middle-of-a-stream dept.
An anonymous reader writes: Third-party game engines are wonderful creations, allowing developers to skip a lengthy and complicated part of the development process and spend more time on content creation. But each engine has its own strengths and weaknesses, and they may not be apparent at the beginning of a project. If you realize halfway through that your game doesn't work well on the engine you picked, what do you do? Jeff LaMarche describes how he and his team made the difficult decision to throw out all their work with Unity and start over with Unreal. He describes some technical limitations, like Unity's 32-bit nature, and some economic ones, like needing to pay $500 per person for effective version control. He notes that Unreal Engine 4 has its problems, too, but the biggest reason to switch was this: "Our team just wasn't finding it easy to collaborate. We weren't gelling as a cohesive team and we often felt like the tools were working against us."
This discussion has been archived. No new comments can be posted.

Switching Game Engines Halfway Through Development

Comments Filter:
  • by supersat (639745) on Friday August 15, 2014 @05:39PM (#47681951)
    Daikatana [wikipedia.org]
    • by RogueyWon (735973) on Saturday August 16, 2014 @04:23AM (#47683687) Journal

      Prey and Duke Nukem Forever fall into the exact same category. Games which were pitched as "we will make the content on somebody else's engine", but which felt they had to play catch-up on engine tech.

      When id released Quake 2, they caused an absolute cataclysm for many developers. In terms of looks, it was way ahead of the Quake 1 engine, particularly for people with new-fangled 3d video cards. Lots of people were out there making games on the Quake 1 engine, with contracts that gave them cheap access to the Quake 2 engine once available. The assumption had always been that porting from one to the other would be easy.

      It wasn't.

      So several studios, including those making Daikatana, Prey, Half-Life and Duke Nukem Forever had a choice between putting out a game on the old engine or restarting a lot of their work from scratch on the new one.

      The ones who went for the latter option ended up in engine hell. Only Valve came through it reasonably well. They took a hit on Half-Life's release date, but basically hacked around the Quake 1 engine to replicate some Q2 features and to make the (highly successful) bastardisation that became known as the Half-Life engine.

  • Sometimes a switch may be warranted if you're running into a physical limitation. One issue I could see is that - if upgrading just for the "looks better" factor - you might end up in the realm of Dude3d/DNF, where constant changes push your end date so far out it never reaches a realistic/satisfactory completion.

    That said, I see the issue of switching as one of the weakness of graphical toolkits. The underlying code could be fairly engine-agnostic in many ways, so a full rewrite shouldn't be necessary depe

  • by Anonymous Coward

    This managing partner has no idea how look dev works. Shaders are essentially written using the libraries from the GPU language. The GPU capabilities determine the look far more than the Engine.

    I can attest that Unity can look as good as any Unreal game and have the assets to prove it.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Woosh

      Did you read the article at all? It has nothing to do about quality of graphics, the article is about 2 things tools and collaboration. I've used both game engines for development and even though Unity is easy to pickup and build for, as already mentioned, collaboration is right out the window along with its tools. Unreal isn't great either but at least it offer a hell of lot better collaboration compared to Unity and this is the most important part of any team based development.

      Being a Unity fanboy is

      • by Mr0bvious (968303)

        What's the issue with collaboration?

        I use Unity every day with git, never had an issue (Unity saves meta data as text these days).

  • I am really, really, tired of that word. It is pitifully overused by management from one end of our continent to another. I just got used to being on a constant watch for paradigm shifts and now I am told I need to make sure that my team is gelling sufficiently. We need to campaign to have that word striken completely from the English language; gel should not be a verb for that sense.
    • by BillX (307153)

      Just wait 'til they start touching your bases. I could do without that.

      • Just wait 'til they start touching your bases. I could do without that.

        They're not going to stop touching your bases. First they see them. Then they touch them. Then they take them by force. Then all your base are belong to them.

    • by JanneM (7445) on Friday August 15, 2014 @09:41PM (#47682897) Homepage

      One function of special vocabulary is for specialists to easily communicate. But another, important, social function is as a badge of in-group membership. If you use the words correctly (from the point of view of the group) you show that you belong, and that you probably know and understand all the other explicit and implicit rules of the group. If the word use spreads too far it loses this function and the group needs to find new words and expressions instead.

      You dislike "gelling". You dislike "paradigm shifts". It would probably be a fairly risk-free bet on what you think of expressions like "optics" (as in "the optics of this decision is good") and the like. You dislike these words and refuse to use them. Which signals to management people that you are not management and should not be treated as part of their in-group. "gelling" works exactly as intended, in other words.

      Asking for words to not be used like this is futile. It would be like asking people to no longer care about fashion (another in-group signal) or to not form groups of like-minded people at all.

      • You dislike these words and refuse to use them. Which signals to management people that you are not management and should not be treated as part of their in-group. "gelling" works exactly as intended, in other words.

        You have a valid point. However, slashdot is not intended as a forum for middle management to trade buzzwords. Slashdot is supposed to be for technical discussions. Arguably even if we can't permanently strike "gelling" from the English Language it should be reasonable to present an argument against using it here.

        • by JWSmythe (446288)

          We could run that idea up the flagpole, to the cloud, to have a meeting of the minds. Then we could do lunch. Have your people call my people, and we'll set up a thing.

          I think I just made myself nauseous writing that.

  • Lets say I know how to make quality games in OpenGL already. Is there a reason for me to pick up Unity or UnrealEngine? To me, it seems like they don't have all the possible features having access to the raw data at the lowest level gives... Including really cutting edge networking techniques. I know all the jobs are looking for Unity developers, but it feels like I won't have as much control over the details. Should I spend a few months and learn Unity, or should I be content with getting things done a
    • Yes (Score:5, Insightful)

      by Sycraft-fu (314770) on Friday August 15, 2014 @06:32PM (#47682211)

      A game engine is a very, VERY big enterprise to make, particularity if you are talking one with modern 3D graphics. It is a big undertaking even for a company who's done it before and has a decent team of people. You will spend a lot of time and effort on it, and it still might not end up being very good.

      Game engines get a lot of that low level hard work out of the way. That's why they are so used. You see even large development studios with big budgets license an engine because the cost of doing so is far less than the cost of properly developing their own.

      If you want to build a game engine, that's great, but make that your goal. Build an engine for its own sake then, if you have one that seems to work well, think about using it for a game. Don't set off to make a game form the ground up, it isn't likely to happen.

    • UnrealEngine gives you complete source access. You can do whatever you want to the engine. If you want to spend a lot of time on access to the raw data at the lowest level instead of game design, then you can do so.

  • Unity is 64 bit now (Score:5, Interesting)

    by Hadlock (143607) on Friday August 15, 2014 @06:18PM (#47682153) Homepage Journal

    Kerbal Space Program (a bleeding edge physics sandbox game built in Unity that includes orbital space travel) had unofficial 64 bit support back in... February '14? And now has official 64-bit support.
     
    $500/developer is pretty cheap, did you buy the developers $250 Chromebook "workstations", too?
     
    Anonymous poster slamming Unity and praising Unreal 4 right after the Unreal team announces huge cuts due to lack of engine uptake, and Unity flying high right now reeks of ad-placement.

    • by Anonymous Coward

      If you look at his twitter hes pushing Unreal pretty hard. Considering unity has had 64 bit since February I wonder how much epic payed him to switch.

    • by Goragoth (544348) on Friday August 15, 2014 @06:50PM (#47682301) Homepage

      Unity has had the ability to create 64bit executables for a while but the editor is still a 32bit program, which can be very limiting if you are developing a large game. A 64bit editor is scheduled for Unity5 and indeed one of the biggest selling points of the new version. There's no release date for Unity5 yet though and I imagine it is at least 6 months out, considering there is at least one more big update to 4.x coming (4.6, which will include the new GUI tools).

    • And Unity 5 is supposed to support multi-threaded physics as well. That should translate into a huge performance boost.

      KSP, a game created by people who have never made a game before, that pushes both Unity and the best processors to their max. A game actually written to take advantage of a premium system instead of being written to a console level and ported.

      I find it amusing that an Xbox One and PS4 would rank as low end computers for this game.

      So much for Next-Gen.
      • Why is that amusing? It was true for last gen as well. And the one before that. Simply, a $300-400 computer designed for low power(low temps), small formfactor just won't compete with a $750-$1500 computer without those requirements.

        That is just a fact of life, no matter how it upsets fanbois.

        What amuses me is the angst over "why does Skyrim run at only 30FPS and make me motion sick?" and "why aren't there 64 player maps like on PC?" Well duh.
        • I just find the hypetrain amusing. And before they announced specifications, I truly hoped they would be a bit better than this. I mistakenly thought (I am not in the industry so this will show that ignorance) that the mass purchasing power of a new system would of generated a more capable machine in that price neighborhood.

          I never expected them to compete with a full on gaming PC, Just more capable than they turned out to be.

          On the plus side, I shouldn't have to upgrade for quite a while,

          Yea, I fanboid (is
        • Another difference is that the majority of desktop PCs include a Windows operating system. On a traditional video game console, the operating system is paid for by licensed game publishers, not by the end user.

          I wonder how Steam OS will approach this. It uses a proprietary store on top of the free GNU/Linux operating system. Yet because it runs GNOME apps, developers can skip paying a 30 percent cut to Valve by offering sideloadable copies for sale outside the store. How has Valve planned for the possibi

      • by tlhIngan (30335)

        And Unity 5 is supposed to support multi-threaded physics as well. That should translate into a huge performance boost.

        KSP, a game created by people who have never made a game before, that pushes both Unity and the best processors to their max. A game actually written to take advantage of a premium system instead of being written to a console level and ported.

        I find it amusing that an Xbox One and PS4 would rank as low end computers for this game.

        So much for Next-Gen.

        Well, given the purpose of the game is e

    • Kerbal Space Program (a bleeding edge physics sandbox game built in Unity that includes orbital space travel) had unofficial 64 bit support back in... February '14? And now has official 64-bit support.

      And KSP is full of weird engine based bugs, and the "official" 64 bit version is even buggier and (per the dev team) essentially use-at-your-own-risk.

      So no, it's not *quite* as simple as you would have it. (And yes, I do play KSP.)

  • Why is version control $500 per person? Haven't they heard of Subversion or GIT? These are problems that have already been solved!
    • by Anonymous Coward

      Based on TFA, it seems like they are using version control but pulling down changes can/will trigger Unity to rebuild its cache, which can take 45 minutes or longer on a dev machine for a sufficiently complicated game. The solution is a $500/seat asset cache server.

      The summary says effective version control, not version control.. It got me too!

      • by Mr0bvious (968303)

        I've never experienced this - perhaps I've been lucky.

        The only time I've had a cache rebuild is when:

        a) Switching platforms (alleviated by having a working folder for each platform)
        b) Upgrading to a new release of Unity (not all new releases, only some require a cache rebuild)

        Neither of which are issues I'd consider changing game engines for.

    • Re:Version control (Score:5, Insightful)

      by BitZtream (692029) on Friday August 15, 2014 @07:31PM (#47682481)

      Because the author is calling asset management 'version control'.

      The author really doesn't know what he's talking about and if you look at the full article, it shows.

      Another example would be that they basically rewrote the game, with no art and assets ... and then claim it looks better because of the Unreal engine, and not the fact that they changed the textures.

      Unity isn't the problem. The project management and developers are.

      • by H0p313ss (811249)

        Unity isn't the problem. The project management and developers are.

        This is generally the case, tools do matter, but people matter much more.

        Give a brilliant team a conference room and a supply of paper, pencils and food and they will turn the world on it's head. Give a team of idiots the best tools that money can buy and all you'll get is a steam pile of fertilizer.

        (Give the brilliant team the best tools... though, even if it only makes them 1% more efficient it's still cheaper than the tools.)

      • by Anonymous Coward

        You're talking out of your asshole. Unity's version control is pure garbage and broken. Asset management has to through their broken asset manager tool or Unity itself won't see the charges. Unity is a single person tool that has grown, but they have no understanding of team collaboration. It's been a massive Achilles heel, which they refuse to address.

        They don't fix bugs, and expect their customer to find workarounds.

        They pust the asset store to fill the void of missing functionality, except the asset stor

      • by Anonymous Coward

        "Because the author is calling asset management 'version control'."
        Can I ask, as someone who has never worked in games and probably never will, what asset management is if it isn't VC?
        TIA

        • by Mr0bvious (968303)

          I'd assume it's 'version control' of assets (Textures, Audio, etc - the binary elements of the game)

    • by Anonymous Coward

      If you RTFA, it's $500 per user for their fancy caching server which is significantly faster bringing in changes.
      As a 17 year veteran of the gaming industry I can tell you that git and subversion are jokes. They would fall apart with the quantity and rate of change of game-sized datasets. The only industrial-strength source control I've used is perforce. It still has its issues, but it doesn;t fall apart when the datasets are large.

      • I've used all of them, quite effectively. Sorry, but Perforce's overly centralized control and the administrative expense of error prone Perforce management makes it unusable for long projects. The centralized control is too vulnerable to central administrator errors, such as having to delete content and accidentally deleting the only copy. Subversion has some similar issues, and relatively poor performance and very confusing upgrade cycles to deal with.

        Git is working out _extremely_ well for small and larg

      • by MtHuurne (602934)

        Git is used to maintain the Linux kernel; I don't think any game has a rate of commits that comes even close to that. The problem you're referring to is probably that Git is not designed to handle large binary data efficiently. That doesn't make it a joke, but it could disqualify it for a particular use.

        • by Ja'Achan (827610)
          The emphasis was on "change of game-sized datasets", Linux kernel patches contribute on average 3,509 LoC per day [pingdom.com], which is about what, half a MB per day?
          • by Anonymous Coward

            For the last game I worked on (out of the industry for a few years) a MINIMAL dataset to build the game was around 50gb, which didn't include movies or multi-lingual audio. I checked today, the kernel is a little over a gig of source code which is small potatos. Before that game shipped there were well over 300K commits over the three years of development. I have no idea how many terabytes the history database was, but the bluearc storage wasn't cheap to store it.

        • by Anonymous Coward

          They are talking about 3d models, texture maps, sound, music, world maps, animation, rendered movies.
          These need to be version controlled as well and the disk requirements are a lot higher. Some of the assets such as movies can be rebuild, but the movies themselves you want to also keep on version control as cache.

  • by Reibisch (1261448) on Friday August 15, 2014 @07:24PM (#47682445)

    Switching game engines halfway through development says more to me about a lack of proper requirements analysis and planning than it does about the benefits of one engine over another.

    • The problem is that game design is art, and game engines follow hardware developments. It becomes pretty difficult to figure out what the prevailing technology will be past a year; thus the decision of game engine to adopt becomes a crapshoot as well. It gets even more difficult when a gaming group "knows" the engine they're using will be out of date in two years, and have to cobble their own hacks into the old game engine, to have some feature available in two years. What happens when the "new" engine t

  • Planning correctly can save you a lot of time and money... not to mention heartache.
  • He claims that Unreal engine works well on iOS, but this is not really true. Basic features like dynamic shadows are not supported at all and performance is pretty poor - you really need a A6 based device to run it well.

  • Well, not really... but it should be avoided for one obvious reason: Delays in a potential switch will only make the porting take longer. I can only speak from experience in regard to this android project of mine - I first started out in AndEngine due to the fact that simple things were simple, with ready-made libraries for most of what i wanted to do. However, with time, the effective speed of the project was slower and slower due to AndEngine's complete lack of documentation, coupled with some performanc
  • There are several comments suggesting that they had simply planned badly at the start of the project, which had resulted in a bad engine choice.

    He actually mentions it in the article; Unreal Engine 4 only became available at a feasible price when they had started the project.

  • by nsxdavid (254126) <dw@pla[ ]et ['y.n' in gap]> on Saturday August 16, 2014 @11:14AM (#47684667) Homepage

    I hate to say it, but this Jeff guy is fairly cluesless when it comes to Unity. And is, therefore, in a poor position to give any useful insight into Unity vs. UE4.

    My studio (of roughly 27 years) has used a lot of tech in its time. We even developed our own engine, HeroEngine (used in games like Star Wars The Old Republic MMO). We've made lots of games and have lots of experience with Unity. I used Unity to do the Android port of Temple Run, and we've made a lot other titles with it too. We're currently working on a marquee franchise for a major publisher... using Unity.

    Unity is not just for small teams. Jeff didn't do his homework on this one. Our team is 27 strong, using git for version control. We use a deep feature-branch approach and it works well not only for our developers, but our non-techies: artists, designers, sound guys, etc. Sure there are issues with Unity and version control, but you find ways to make it work through convention and approach. Same thing happens in all Engines. They all have their issues. The only engine that put collaboration at the forefront was our HeroEngine, but even that has issues. Though we sold off that tech, you can still check it yourself... just Google.

    The 32 bit editor limit is true, but is it really an issue? It never has been for us. His problems smell strongly of bad development practices... they can't seem to manage their memory resources well and that suggests other major issues in their group. Just reads a bit amateur to me. No engine will save you from bad practices. The game builds are 64 bit, and the Editor will be also in Unity 5 (how did he not know this?).

    It is notable that the guy is fascinated with a lot of things in UE4 that, as it turns out, you can also do as well or even better in Unity. He loves, for instance, Blueprint visual scripting... did he bother to check out uScript for Unity? He loves the node-based Shader in UE4.... well there is ShaderForge in Unity. He loves Physically Based Rendering in UE4 but doesn't mention Alloy in Unity. Sure some of these things are add on costs (usually pretty tiny) and there are also lower cost or sometimes even free alternatives to many of them. The best part is you can mix and match which pieces work best for you. If you don't like UE4's node-based shader... tough! But in Unity you have a few to pick form..... .... or better yet, you can make your own! The best part of Unity is how seamlessly extensible the editor is. This is a huge productivity booster. Every game we do we create custom tools that enhance the efficiency of the designers and artists. It's so easy to do, you just naturally create augmenting tools as the need comes up. Our designers and artists can do amazing things without ever having worry about writing any code... much less even a visual scripting system. This is because we made the tools specific to the game that let them express what they need all from the inspectors and the scene tools.

    Another cool thing: make a great addon that is generally useful... then wrap it up and sell it in the Asset Store. Monetize that sucker! Or give it away for free if you like.

    Is Unity perfect? Nope. But it is insanely efficient for developing games. Works with any sized team well enough, and creates titles that run across tons of platforms. And the Asset Store is a treasure trove of extensions that just make it better and better all the time.

    The places where it falls behind a tad are either addresseable from add ons, and ultimately in Unity 5.

    I am not advocating that one choose Unity over UE4... but if you are going to make an argument, at least make a balanced one with all the facts. I would take his critique with a grain of salt. Try each engine yourself, but make sure you take the time to fully understand both the tool and its eco-system and how it applies to what you are doing. And above all, make sure you have sharp developers on your team who understand the fundamentals. Like I said, no tool will get you out of a jam of your own making.

    • by nhat11 (1608159)

      I'm sure he can address your concerns if there's some type of Q&A but if you read the article it seems like a general overview on why they switch and the amount of work it needs for the switch.

As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie

Working...