Slashdot Mirror
Switching Game Engines Halfway Through Development
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."
The increasing costs of making games have made middleware game engines popular because most software development houses can't afford to build their own engines (not enough time or money). And with middlemen come absurd fees and restrictions.
Daikatana
Switching from an easier engine such as Unity which I would only consider for prototyping or really low budget games, to a high-end professional engine would obviously come with issues, but it sounds like it is easier than I would have thought. I've worked with Unity only because of time constraints and I'm the only one working on it from beginning to end. I'd use Unreal or even better make my own with OpenGL or DirectX if I could, but speed of production is the issue.
Simply put, this sounds like an issue with the conceptual design stage of the project, which I hope was mostly done before code was made. The project grew bigger than you thought it would. I suppose it is merely an issue of not knowing the correct tools for the job. I hope the unreal licensing fees don't break your profits, if the project gets finished. That would be the worst outcome.
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 depending on what the base language/structure is.
Bullshit
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.
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
A consensus on this issue is starting to gel.
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 at a lower level?
I've been tossing the idea in my head for an Xwing vs TieFighter(like) MOBA in my mind, and it wouldn't be out of the scope of what I could do in 2-3 years.
God spoke to me
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.
moox. for a new generation.
Why is version control $500 per person? Haven't they heard of Subversion or GIT? These are problems that have already been solved!
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.
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.
You have to be running a dipshit-show if end up in this kind of a mess. Research the engine first before starting your project. Nowadays an engines benefits and limitations are presented quite accessibly for the general public through forums, shared developer experience, and the countless games they've already been used to create.
This is just the mark of an idiot developer. I remember talking to a member of 38 studios before their collapse, where they were using Unreal Engine 3, but they'd "decided not to use the material editor and go with something third-party", which is unarguably one of, if not the best and most flexible feature in UED3.0.
But hey, they did alright, right??
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.
As a man who worked enterprise for many years he is spot on
... but he cared about the 'why doesn't that work out of the box' part.
As another data point, I bought War for the Overworld early access and they don't (or didn't, I haven't checked in a while) have a Mac beta because of some Unity problem. I wouldn't trust the cross platform-ness of a game engine much when it's being programmed in C Sharp, to be honest. It smells like "all we know to do is Windows, and there is an overworked intern doing the other platforms".
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 performance issues. In the beginning I was doubting whether i had chosen the right engine, and I came across libgdx as a potential replacement. However, silly me concluded "I'll get this and that feature done and get the next alpha version up and running before I'll test with a different engine". My conclusion: If in doubt, try swapping the engine as fast as possible. It also enables you to rewrite parts you perhaps approached the wong way to begin with, from a design-perspective
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.
Principle 1. Create something you own
Spend time and energy making something that: (1) you own fully (2) is of value to others (3) you can exchange for value
This is because you can only ever give what you own. Examples: a mobile app, personal skills, bookshelf. Even raising poultry/vegetables in your backyard counts - you exchange these with yourself for money (a.k.a. 'saving cash').
Note, 'Writing code for cash' fails on point (1), but 'Honing C++ skills' ticks all three points. A life devoted tohelping others is the best deal of all - you exchange your life for treasure in heaven.
Principle 2. If you cannot work for yourself, search for a workplace like how long term investors search for stock.
Consider the most famous one of them all - Warren Buffet. He uses 'intrinsic value' to value stock. Companies with price to intrinsic value ratio (lets call it 'P/V' for this post) lower than 1 are more likely well-managed but undervalued -- and hungry to be valued higher -- so Warren 'buys' those companies.
My pet theory: unlike Warren, you want to 'buy into' workplaces that are consistently profitable and whose P/V ratio is as close to 1 as possible. This is because such companies are typically profitable, well run and will treat you fairly -- leaving you enough time and energy for Principle 1.
Let take a look at Netflix (NFLX) -- a well regarded company with a demanding work environment -- their ratio 1.85
http://www.gurufocus.com/term/...
(To check others, replace 'NFLX' in the URL with another stock ticker - remember, its the median ratio we're looking for)
NFLX (1.8) , AMZN (4), and EA (2.5) for instance, have high 'stock price/intrinsic value' ratios. So, while these are very successful companies, these are more likely high-pressure work environments with little time to yourself outside of work. Even GOOG (1.6) and APPL (1.5) are getting a bit up there.
Going lower: SPLS (1.3), MSFT, WMT (Walmart), BA (Boeing) (all 1.2), and INTL (1.1).
Now the magic unity figure -- BRK.A (Warren's Berkshire Hathaway itself), BAC (Bank of America), PFE (Pfizer) - all around 1. Strangely, so is ODP (Office Depot - 0.97).
Further down seems to be the domain of banks -- FNF (Fidelity National -- 0.9), PRU (Prudential - 0.28), MS (Morgan Stanley - 0.26), JPM (JP Morgan - 0.27)
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.
David Whatley
This is because you can only ever give what you own. Examples: a mobile app, personal skills, bookshelf. Even raising poultry/vegetables in your backyard counts - you exchange these with yourself for money (a.k.a. 'saving cash').
Until the city threatens imprisonment for growing a victory garden, or until the federal government steps in and seizes your crop under the legal theory that it competes with commerce among the states (see Wickard v. Filburn).
If you cannot work for yourself, search for a workplace like how long term investors search for stock.
For example, after having invested in your skills at a four-year college, you might have to "pay your dues" by working for a recognized video game studio in order to gain experience so that once you do start your own video game studio, you have 1. knowledge about how to get a project done, 2. contacts, and 3. enough verifiable industry experience to make the console makers more willing to sell you a devkit.
unity is a real piece of shit [...] I'd expect a product that doesn't have all kind of strange idiosyncracies and incompreshensible behavior. In several instances, Unity broke so badly that a reinstall did not fix the problem, and an OS restore was required.
Are you sure you aren't confusing Unity the game engine with Unity the Ubuntu desktop environment?
On top of that, the subject matter is questionable. It's a "furry's vs human's" game
Would it be any better if it were a "furries vs. dwarfs vs. congenital amputees" game like RHDE?
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 possibility of third-party stores compatible with Steam OS competing with Steam?
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.
Having started development of a very large and complex game ( estimated users 10,000+ with capabilities to expand to unlimited back-end servers as well as Unity servers) we gave up after 5 months as the tools were such a PITA. The usage of nearly obsolete versions of Mono development tools ( something like version 2.x) the integration between debugging and editing was a nightmare with way too many crashes. Having to use MonoDevelopment rather than Visual Studio cost us to much wasted time. Eventually we got to the point where we put all of our game logic into servers that would run VS and interface to Unity servers which would handle rendering and communications. Simple things that would work in Mono or .NET failed in Unity as they had deliberately broke them, such as message queues, signals, Remoting. As Unity can only run on a single-thread and that just won't cut it semaphores, remoting, signals, etc. would only work on the main thread, which makes it near worthless if you're familiar with the platform, or a lot of $$$ as we spend to overcome this.
And the latest version of Unity they have still refused to upgrade the Mono platform to something reasonable. :(
When picking a game engine to use, you need to weigh the pros and cons on a "where will things be 5 years from now" and if it's a MMORPG, make that 15.
Being locked to 32-bit, is a no-no and anything that can't be compiled to 64-bit should not be considered. EverQuest Next/Landmark is 64-bit only. Archeage is 32bit, but uses CryEngine3 IIRC, and that can be compiled to 64-bit. No other game engine off hand ships as 64-bit, though it's possible to get Source Engine and Unreal in 64-bit flavors.
There are massive amount of drawbacks when you consider MMO games. Single-threading and "hack proofing" are common problems that spell death for a project.
I mention Archeage above because the download is 22GB. And runs 32-bit only, likely because hackshield isn't available in 64bit. But I've been watching the CPU meters while I play it, and my 4-core (8 core in HT mode) is never going past 25%, which tells me it's not multithreaded very well, or at all.
A lot of games aren't making use of what hardware is available. If you are going to multi-thread, you need to multi-thread more than just "put sound on core 2", make more connections to the server, put the chat system on it's own thread and communications channel, put the world state and inventory on separate threads, quests on yet another. If the connection to the servers are lost for these parts of the games, then something simply doesn't update for a few seconds, it doesn't stall out the game. Many games are lag-sensative, and this is because everything is being pushed over one connection that has to deal with Nagle algorithms, crappy home ISP routers, and throttling. Push the game communication and chat communication over separate encrypted links.