Closed Source Engines Are a Big Risk
stephaniehurlburt.com
stephaniehurlburt.com
Unity isn't just closed source, but your main access to the engine is through an ancient Mono .NET environment that hasn't been updated in years due to licensing issues. The latest re-licensing of Xamarin should help here, but as with many other features Unity will be afraid to make upgrades for fear of braking compatibility.
This means that most of the Unity game code that will set your game apart has to be written in C# 3.0, and your memory use and performance is heavily taxed, unless you resort to platform specific native plugins. As a game developer this scales down your ambition down to mostly casual games. The type of AAA games that Unity advertises are mostly distinguished by large amount of content, but nothing innovative in gameplay or technology besides what the engine provides. I can't imagine anyone starting a No Man's Sky or even a next Minecraft in Unity.
This is sad, because about 5 years ago I was cheering for Unity and having a lot of fun with some prototypes. They know they are a mill for casual clone games too, since they are shifting their business focus to online developer services like advertising and multiplayer hosting with per-player fees.
XNA used to sit in this space, and it was a pretty nifty little game development platform for C#. Monogame has carried on, and expanded the target platforms nicely, but hasn't really made many other improvements, from what I've seen, getting back into it after a few years away.
https://feedback.unity3d.com/suggestions/change-font-size-in...
http://forum.unity3d.com/threads/when-will-unity-support-hig...
Second threads ask for support for high DPI. It's a simple scale issue, but somehow hard to do it on Windows.
Stuff that should be easy but isn't is a strong indicator of technical debt.
It can also be an indicator that there is noone working on it. It's common to have fix which are relatively easy but noone to implement them.
Or, they just get their priorities wrong, meaning, they're being stupid. Not a safe assumption in my opinion.
> Or, they just get their priorities wrong
Most open source projects have very few or no people working at all. It's common to find bug reports opened for years that were never fixed. They don't have to be complex, just non-trivial.
From the link:
The Mono runtime we use in our Editor and Players has not been upgraded.
The compiler still targets the C# 4 language. This is approximately what our old compiler supported.
The compiler still target the .Net 3.5 framework profile we previously supported.I've contributed to Gang Garrison 2 (GG2), an open-source 2D multiplayer shooter (a "demake" of Team Fortress 2) for several years.
GG2 is built with Game Maker 8.0, an obsolete commercial game engine/RAD IDE product. Why? Because Game Maker 8.1 is buggy and broke things we needed, and its successor, GameMaker: Studio, broke even more (and is also much more expensive). We did try to move to GM8.1, but we had to give up on it.
This is unfortunate, because Game Maker 8.0, being now completely unsupported, does not even have working DRM servers. We literally have to pirate the product in order to continue development.
Game Maker 8.0 also produces executables that crash on recent versions of Windows when too many sounds are played simultaneously. This is probably fixed in newer versions, but we can't use them. So we have to work around it.
And “black box” bugs? This is a consistent theme of development with Game Maker. It's filled with them. There are lots of workarounds in our source code for such bugs. And there are some bugs we have never been able to work around, so sometimes the game crashes with inexplicable (i.e. incorrect) error messages.
Because of these experiences, any game I make in future will use an open-source engine. Proprietary engines are just too much of a risk.
http://blog.prime31.com/introducing-nez-2d-framework-for-mon...
I'm watching it closely and I hope it will be possible to leave Unity one day. Now it's too comfortable and incredibly fast to build 2D in Unity.
ALL software are at risk of being poorly maintained and abandoned.
open-source VS free VS closed-source VS paid is not directly relevant to the direction and the future of a software.
What you need to do is a proper risk analysis before you pick an engine (or any important dependency for the matter).
> Game Maker 8.0 also produces executables that crash on recent versions of Windows when too many sounds are played simultaneously.
If GameMaker were open-source, they could fix this. They could probably even backport a fix from 8.1 or Studio.
Yes, sure, but open-source at least gives you some hope of maintaining it yourself (even if poorly) if the creators abandon it, and it also means you can try to fix bugs that creators don't care about.
Unity is a wonderful prototyping tool but using it for production can be painful. That said I build engines for work so in my free time I like to just make games and using Unity for that purpose is refreshing and fun because the games I make in my spare time are simple enough that they rarely hit any limitations of the engine.
With smaller projects, pressure moves back towards development cost, ease of deployment and maintenance, which is a lot more like the model for small-site webdev. The necessary optimization for the runtime is more often at the level of just using correct algorithms, good-enough memory management, and feeding the GPU correctly. In turn, this is going to have a commodifying effect on engine runtimes - if your scene is already easily hitting its quality target at 144hz or whatever the high end is today, your concerns are just going to shift towards how fast you can iterate and debug, add and tune new assets, create one-off behaviors, and run off final builds for external use. You can hire for design rather than coding talent.
This favors a "game creation system" model like Ren'Py or Puzzlescript, where the underlying formats and protocols still allow a substantial degree of customization, including the possibility of moving the data to a different runtime altogether, but the developer's interface works on abstractions all tuned around that particular type of game. This path follows what's happened to audio with the development of synthesizers; after the early modular synthesizers proved the concept, a commercial market arose for delivering "complete instruments" that are less flexible in abstract, but are more portable, and offer an easier mix of performance and programmability, through presets and limited customization parameters. And today, for every popular genre, you can get started by "buying the sound" in the form of sample loops and synth presets, and then build out your own work by hanging off customizations. New genres appear simultaneously with the successful commercialization of new technologies - e.g. drum machines, or Autotune. There's no reason why games won't go in the same direction, given enough time.
Also when you evaluate engines what is there today is what you'll ship with, don't plan on features down the road. A lot of studios learned that one the hard way with UE3 and PS3.
Lastly two devs seems like a really small number for even more than the most simple of indie games. For a lot of the reasons that seem implied in the article. Every game I've worked on needed to retrofit a different engine in significant ways unless it was a direct clone of the platform/genre it came from.
On the other hand they did a very small project that was simple and for that they built their own engine and that was a lot of fun. "Building our own actually turned out to be a joyful experience. It was a simple app, didn't require a lot of features. It was an unexpected, fun breath of fresh air."
While I see how building something small and simple can really be a joyful experience, building something huge and complex for a client and supporting VR in this day and age is probably far from that.
Am I reading it wrong or is this apples and oranges?
And while I agree that having the source for the game engine is always preferable, often reading the comments (usually on facebook groups) makes it sound like EVERYONE has 20 years of experience in C++ and could actually fix everything as long as the source was provided.
Having the sources is often useful as it helps you to * partition the black box * observe the internal state * observe critical control flows * maybe not 100% diagnose and fix but mitigate an issue
Generally engines and frameworks are bigger than needed. They may be well tested but the sheer volume means there are a lot of corner case defects of holes left. Frameworks are particularly risky as they are supposed to be adapted to new situations and as a rule writing software for future requirements is fraught with problems.
Special purpose frameworks often beat general frameworks hands down in size, performance and cost. Going with a large established framework from a "commercial" vendor is often seen as a safe choice by management and as the article shows it is not. Then on the other hand there have been plenty of teams going down naively the road of custom engines and finding that they did not have to re-invent the wheel but build an advanced gasoline engine and were failing at that. As always understanding your requirements, options and capabilities priceless.
If you're building something simple and small It's easy-ish to build everything yourself. While if you're doing something big, the cost/benefit of doing it from scratch might be something else entirely.
My point was that for the second little project Unity might have worked brilliantly anyway. Or godot, or maybe any little 3D engine. While doing the first thing for a client, with VR support and God knows what might have been really really difficult.
Not sure if I made my point any clearer at this point really :D
I think The Witness might do it: it's a relatively big game, build with a custom engine. And it's quite clear it couldn't have been build with a classic engine such as Unity though telling why would be a bit spoiley. Likewise, Braid couldn't have been made with a generic 2D engine: its time mechanics are just too alien.
Another reason why Jonathan Blow chose not to use any 3rd party engine is, he wants his games to last. He wants the ability to port them to new platforms, and that ultimately means owning the code —if only to separate clearly the platform dependent parts from the rest. (I hope he'll release the code at some point, so others can continue that work.)
Being able to fix issues was also a reason. When you not only have the source code, but also have written the damn engine, you can fix anything.
First: in the article she says that they struggled on one very complex project while using Unity. And then she says (or that's my understanding) that she made a completely different project on her own engine. That's why I said apples and oranges. I can't build unity, u4 or frostibe from scratch but if you want Pong or a simple platformer, sure, I can do that from nothing. That would be me saying: "well I had serious problems recreating the Witness in Unity but look at my space invaders which i made in Elm for browser without an engine".
The second problem I have is with some members of the gamedev community. Feel like a lot of people are ready to jump on the "I wish the source was available" train while very few of them (or at least that's my perception) know what to do with the engine source. Actually I could extend this point to a lot of advocate of the open source community. There is this false perception that anyone can fix anything that's broken because the source is available and yet a lot of those apps are sadly still very much broken and sometimes the authors of those apps have difficulties in finding people who might help them. But if you read any post about it online it's usually "closed source sucks and open source is brilliant cause we can always fix that anytime".
Sorry, this is a lot of generalization and obviously not everyone is like that but I tried to make point clearer this time 'this all.
About the second problem, I think it is one of control. Source code access at least gives you a fighting chance.
That said, I have used Qt a couple times, and never dared to delve in its source code, it's just too big. If I have a problem, I just work around it. If you want control over your engine/framework, you pretty much have to have written it in the first place.
Of course, you're hoping your framework is fit enough for your purpose, so that you rarely have to inspect it —if at all.
Bethesda/id/Zenimax, are you just afraid of money, success, graditude, and forming long-lived communities around your games that can mod and hack them, to keep the games feeling fresh, and thus people buying them, decades into the future?
Most AAA game engines are good at making a game or a subset of games, and I imagine idtech 6 is great at making Doom, and by association pretty good at making first person shooters, but its not really possible to make a mobile match 3, 2D visual novel, or MOBA with it without heavily modifying C++ source. If you look at the HN discussion around Crytek open source, and peer into the source code, you'll have a good idea of the reality of many in house engines. In practice this is an advantage for AAA teams with strong engineers, because you can out compete people using licensed engines using features targeted for your game, but it makes it hard to do wide licenses to small teams that don't want to just make simple mods for your game.
With the right partners (E.G. some company making an FPS based on a movie) the deal might work in their favor.
For modding specifically, that also dictates how your game is built and requires extra work to do it right. Not every game needs it. The reality also is that it's easier to sell people games on a shorter cycle when the previous one doesn't have legs. I imagine the vast majority of the gaming population don't think twice about modability - they're happy playing a focused game and eventually leaving it behind.
Like others have said it isn't just about 'opening your engine' and leaving it at that. All of a sudden you have to polish up your editor for external consumption (ooops.... the editor is crashing on this PC config that we've never had in the office?), write documentation and tutorials, putting out really good examples, engaging with this new type of community, etc.
Is there honestly room in the market for an engine without a clear niche these days? I mean you seem to have Unity and UE4 at the top tiers, then engines carving out a niche (Godot comes to mind), your lower-level stuff (how's OGRE doing these days?). There's a few random ones on Steam even (Leadwerks, GameMaker Studio, RPG Maker, etc) for other use-cases.
I think of CryEngine 3 -- that's the most recent move by a big player into the engines-for-everyone space. How is it doing these days? My impression is that it's struggling to get mindshare, but it has been awhile since I've looked. I'd be wary of bringing a new engine into the space after watching how that's going for them.
There's also Lumberyard, Amazon's new entry into the game engine market: https://aws.amazon.com/lumberyard/
It's not Open Source, but you do get the engine and all the source for free. It's built on technology from CryEngine, Double Helix, AWS, Twitch, with a significant number of bugfixes, improvements, and features.
I'm genuinely excited to see where it goes, but, in full disclosure, I work for Amazon Games Studios (though not on Lumberyard).
>For modding specifically, that also dictates how your game is built and requires extra work to do it right.
That's not actually true. If opensource the engine code, then people can probably figure out a way. Heck, if they're dedicated enough, they'll do it even if you don't opensource the engine. See Minecraft.
Surely you're being facetious? I can't tell, my sarcasm detector is broken
Well money and success aren't guaranteed, graditude and a better community around your games is.
With regards to debugging software, I think being able to do so effectively even without source is an important and rather rare skill. And sometimes, even with the source, the compiler can introduce its own issues. Being able to read Asm and follow along with what the CPU is actually doing is exceptionally useful, especially when working with lower-level languages like C/C++. One of my friends has a saying along the lines of "if you can read Asm, software has no barriers to understanding."
There's not much point in pinpointing bugs in closed source software if you are unable to fix them.
In Windows, there isn't really any other ways around something that MS decides is "won't fix", or just ignores you completely.
My old car, a 2002 BMW 325i, fits that description with a 25 MHz 16 bit Infineon C167 processor and 512kb of flash in its Siemens MS43 ECU. That's properly a microcontroller in my mind.
My new car, a 2015 Ford Fiesta ST, has a 133MHz 32 bit Infineon TriCore processor and 4MB of flash in its Bosch MED17 ECU. That's more than many PCs had until the late 90s, so while it's definitely running a RTOS I have trouble calling it a microcontroller.
That's not even a new ECU either, a friend's '09 VW GTI had basically the same unit. Anything with direct injection almost definitely has a 32 bit ECU, especially if a turbo is involved. I'd imagine a higher end car these days has something more potent (or just doubles them up, like BMW used to do on V12s).
DISCLAIMER: I don't use Unity because, at the time I started getting back into game dev, I think you still needed a plugin to run in browser whereas I wanted to target purely HTML5, JavaScript and CSS for maximum device compatibility (hah!). That may no longer be true.
The thing is, I could make the same point as this post but about developing cross-browser games with standardised web technologies. You can waste days at a time fixing behavioural quirks that appear in only one particular browser - I've done exactly that fixing bugs in iOS Safari, whereas I don't even bother supporting Edge in Windows 10 Phone (yet) because very few people use it.
I've had a full screen bug in iOS appear multiple times in both of the games I'm currently working on - a "nearly done" version of Star Castle (https://arcade.ly/games/starcastle/), and a very alpha-ish take on Asteroids (https://arcade.ly/games/asteroids/ - takes a while to load due to graphics pre-generation, which I need to sort out) - due to very minor changes in markup and CSS. They largely share both an engine, along with many front-end components, so issues like that tend to affect both games.
Actually, my "engine" really isn't an engine at all: more an assorted set of libraries of useful functionality that can be bolted together to help build games of a certain type.
Back to the point, some browsers are open source but it really doesn't help because I can't (easily) change what's deployed on millions of peoples' computers around the world. Having access to the source might make it quicker/easier for me to come up with a workaround. I doubt it though because, for example, Firefox has a lot of source code, which it would take weeks to understand before you could figure out why it was behaving oddly in a particular case. It would just be easier to create a workaround. (Of course, it's fragile - the next release of FF might break your workaround, and then you have to have a workaround for the workaround for that release and later.)
I could make the same points about building on top of any platform, open source or otherwise. I've spent a lot of years professionally doing .NET and Java development. With .NET I spent years building desktop tools for developers and DBAs, and we couldn't redistribute a custom runtime so, again, you have to put in workarounds sometimes.
I'd still say the leg up these platforms gave us was worth the hassle of having to deal with some bizarre pieces of behaviour (and we did occasionally encounter some really nasty issues, like race conditions involving database connections, and suchlike).
With web development on an OSS platform and framework I can see it might be different. You have complete control over your deployment environment, so you can put the fix directly in the Fx and submit a patch, if that's the best way to deal with it.
Likewise, if you're distributing the runtime yourself you have control and can apply the fix in its code rather than a workaround in yours. But whilst it's easy to say that the reality probably wouldn't be, and it might cause headaches in the future.
The costs of building your own engine are pretty clear:
- You start from nothing, so it's harder to make progress initially,
- If you want to hire people well, there's a pool of Unity developers, but nobody with experience of your engine,
- Say you start developing for PC but want to release a PS4 version of your game: adding support for more platforms is going to be a lot of work (I don't just mean dev: Unity is tested across all platforms they support, but now you have to do that for your engine),
- When your game engine gets large and complex it's going to start exhibiting hard to debug behavioural quirks, just like everybody else's; you might be able to figure out why more easily, because you have the source, but that doesn't mean the fixes will always be easy.
So, yeah, closed source game engines are a risk, but then so are open source engines, as well as engines you create yourself: they're just a different set of risks. Which you choose should be defined by the objectives of your project(s).
- Music and sound effects, which are queued up and loaded in the background (it's even possible to play the game with missing music and SFX, and you'll start to hear them once they've loaded).
- Google Adsense content. This ticks me off because some of the ads are very poorly behaved. Some load relatively large amounts of content, and can often block page loading. I've therefore pushed the Adsense script itself right to the bottom of the page so it doesn't result in other requests from the game being blocked. I'd vastly prefer it if Adsense restricted ads to plain text or simple images, banning active content and Flash (which, at least up until recently, was still appearing). The reason for the ads is I need to cover the costs of the site, never mind actually earn a living, but I want to do so in a way that doesn't detract from the player experience.
http://blogs.unity3d.com/2009/03/20/why-you-probably-dont-ne...
I can understand that this pricing model doesn't appeal to amateurs and micro teams working in their free time. I can also understand that Unity doesn't care about this [non] customer base.
Source: shipped games, all had last minute hard to find problems. In-house engines every time.