Whenever someone infringes the rights of independent developers to freely choose and combine engines, platforms, services (including, self-interestedly here, Epic’s own services!) the air raid sirens go off and we move quickly.
I find that a bit dishonest tbh. Epic clearly sees the opportunity to gut punch it's competitor and use it to their advantage and lure devs away from Unity while getting good press in the process. Not so long ago Epic was selling their Engine for hundreds of thousands of USD while Unity was already way more accessible to indie devs. They are insanely rich from Fortnite fame right now, so for them this is peanuts.
Markets change. During the early 2000's, the going rate for a AAA engine license started at USD$250,000. The three main ones at the time were Quake 3 engine (id tech 5??), Unreal and Lithtech. Unity wasn't the first engine to try to make this more accessible (anyone remember Genesis3D?), but it was the first to do it well. It also came into maturity at the right time to take advantage of the App Store.
Unity has done an incredible job of making game development accessible. So much so that when I wanted an extra 30 days on their trial period, I reached out over Skype and was answered within minutes by the founder (who was CEO at the time) and issued a new license key.
Unreal adapted to that market change - they didn't do it half-assed either, they did it properly and with conviction. Their success with Fortnite isn't a one-off, it's come from an astute market awareness and adaptability.
The fact that they turned this fund into reality so quickly is exactly why Fortnite and the Unreal engine is a success.
>Their success with Fortnite isn't a one-off, it's come from an astute market awareness and adaptability.
It's impressive that they managed to build that Battle Royale mode so quickly and efficiently (although obviously it was helped by the fact that they could build on top of their pre-existing Fortnite game) but I think you're downplaying the luck factor. Or rather, if you don't think it's a one-off, do you really think that they will be able to replicate this level of success "at will" in the future?
And if so, why didn't they have the same amount of success and "market awareness" in the past? Remember Paragon?
>Paragon was a free-to-play multiplayer online battle arena game developed and published by Epic Games. Powered by their own Unreal Engine 4, the game started pay-to-play early access in March 2016, and free-to-play access to its open beta started in February 2017. Epic Games shut down its servers on April 27, 2018.
I definitely think that the Fortnite people were at the right place at the right time, they saw an opportunity and jumped on it. They saw PUBG had great potential but was struggling to deliver a polished multiplatform experience. They had this brand new Fortnite game that they could mod a BR mode into relatively easily. They released it on platforms where PUBG was not available and on top of that they released it for free. It's clever but this particular combination of events do not occur every month.
Some companies will have spectacular failures as well as spectacular successes. Successful companies are able to learn from both and iterate.
Unreal and Unreal Tournament were absolute block busters that paved the way for Fortnite, just as Paragon did. You wouldn't have arrived at Fortnite without first going through the ups and downs that preceded it.
By your logic, a company can only be considered successful if they never make mistakes, which is a severely flawed position.
You're right, I didn't articulate my point well. I'm not saying that they shouldn't be considered successful if they ever make a mistake, I'm saying that at this point I think Fortnite is effectively a fluke, Minecraft-style, the right game at the right time. IMO we have a sample size of one, they wouldn't be the first devs to strike gold once and fail to replicate the formula later.
I don't really consider Unreal and UT because, while they were definitely successful and I personally love UT, they're the product of a different time. The last truly successful UT was in 2004 (UT3 in 2007 didn't have quite the same long-lasting appeal and even that was 12 years ago!). There's also Gears of War that was quite popular on consoles but again, a completely different formula and nothing remotely close to what Fortnite is achieving today.
I seem to remember at the time that Unreal Tournament was felt to be a pivot that surprised a lot of people, very similarly to Fortnite. Unreal 1 was a very traditional FPS game focused heavily on single player storytelling. It was an interesting, wild risk at the time for Epic to release a multi-player only game in the series, that seemed to pay off for them pretty well (the original UT ended up outselling Unreal by a lot, if I recall). Admittedly there were signs that that was where the FPS genre was going (Q3A released only a month later). "Who would buy an FPS without a single player campaign?"
Gears too seemed to lead the pack on pulling together various gaming trends ahead of a lot of its competition. Cover-based Shooter wasn't its own "genre" until Gears (even admitting that fad may have passed, Gears was pretty central to the fad). Gears was also ahead of the pack in adding things like tower-defense elements to FPS/3PS multiplayer (Horde mode).
That's before you take into account their pre-Unreal successes, too. Epic had some big hits in the Shareware era that are perhaps more interesting pivots simply because of how much tougher distribution and sales were in that era.
Anyway, Epic seems to have a sample size greater that "striking gold once", for whatever it is worth.
> I'm saying that at this point I think Fortnite is effectively a fluke, Minecraft-style, the right game at the right time.
I mean, that literally describes every innovation. Luck is always part of the equation, you're just assuming luck was a bigger part of the equation than most people do, and I'd argue you have little evidence to support that position.
> Or rather, if you don't think it's a one-off, do you really think that they will be able to replicate this level of success "at will" in the future?
It's not a binary. If I can consistently roll a 6 on a die at 1/4 probability, I'm still doing _something_ based on skill, in aggregate, while the outcome of any given roll is still largely being governed by chance.
> It's clever but this particular combination of events do not occur every month.
Adaptability isn't about _making_ the opportunity. It's about having enough flexibility to capitalise on it when it presents itself.
Fortnite's success, without any doubt in my mind, was not luck. Its borderline offensive to the people behind that game to suggest so.
First of all, they weren't the first in the battle royale market. Many similarly styled games came before. Why hasn't PUBG, despite its absolute success, attained the relative success of Fortnite, which is likely driving 100x or more revenue? What about the many games or mods before PUBG?
In Epic's case, a big reason is the infrastructure. PUBG is a pretty bad game, from a technical sense. It runs like crap on PC, and the console ports are even worse. Comparatively, though not bug free, Fortnite is one of the most optimized, beautiful, performant AAA games out there.
They have in-house expertise with their engine. This is the difference between DICE making a technically amazing game like BF1 with Frostbite, then handing that exact same engine to the Bioware Montreal team to make Mass Effect Andromeda and getting that hot mess of a game. You can't just see a market trend like "oh battle royale games are popular" then become Fortnite. Their investment into the Unreal Engine helped make it possible.
And that's not including the investment into Save the World, which probably wasn't alone an investment that would have shown returns. But it made Fortnite BR possible. Game companies make poor performing games sometimes. That doesn't mean they're bad developers, or that they are "lucky" when they have a success. Their ability to identify that they could take the foundations laid by StW and capitalize on the battle royale market trend is nothing short of marketing genius, because its not immediately obvious from playing StW, specifically the building mechanics, that it would work well as a battle royale game. None of them had building before fortnite.
Ok, so they made a good game. Do you have any idea the engineering expertise that's necessary to scale a game like Fornite to the 8.3M concurrent players it experiences at peak? Fortnite is the most popular video game of all time, period. And, oh by the way, it's an online game with 100 player lobbies, real-time competitive-grade player interaction, and matchmaking within seconds. That's not easy. That's not "luck". And if they'd stumbled when they started achieving some small levels of success, people would have left. They didn't. 
Luck has almost nothing to do with it. They didn't get lucky that they had an amazing engine and a game like StW to build on top of; those things were the result of a decade of amazing engineering. They didn't get lucky when they scaled from 500k concurrent players to 8M in a period of months. There isn't more than a dozen people in the world reading this who have experienced scale that dramatic, and even if you had, probability states that you would have failed, and even if you hadn't, you're probably not working in an industry with customers as fickle and shitty as video gaming. Epic succeeded, and that's a testament to incredible engineering, planning, forethought, and likely some very late nights, missed sleep, and sacrificed time with loved ones.
They're successful because they're smart and they're hard working, not because they won the lottery.
> Why hasn't PUBG, despite its absolute success, attained the relative success of Fortnite, which is likely driving 100x or more revenue?
PUBG has had a following almost despite itself. The performance is terrible, the game assets are bland and most are store-bought, and the development behind it is incredibly slow. People played PUBG with conviction for, what, 6 months to a year?, before Fortnite showed up and started peeling players away. And when they launched on the Xbox, you couldn't use the same account that you had on the PC--which was a pretty big slap in the face for a game whose only rewards are collectable aesthetics.
While they're both technically the same genre, PUBG is slower and more methodical while Fortnite has quicker matches on the jump (if that's what you want), a more light hearted and original approach to style, and, of course, the building aspect.
On top of that, they were professional.
They released content on a regular schedule, with seasons and the season pass being something you could understand. They fix issues pretty quickly, and the game runs smooth. Plus the fact that it's not as intimidating as the gritty, slow pace of PUBG means there's likely a smaller barrier of entry.
The team behind Fortnite churn out good work, and I think the community sees and appreciates that. The game feels healthy and growing, rather than stuck in a perpetual 'alpha' phase that PUBG is still in.
I'm not sure what its like elsewhere in the world but here in Australia the playerbase of PUBG and Fortnite are very different and don't have a lot of crossover.
Fortnite is fundamentally much younger and less serious.
This may well differ quite a bit in other markets.
Also the narrative that PUBG is "under-performing crap" is only justified in the context that its a 100 player 8x8KM map. It performs better than basically all the other games that have tried to enter that arena with the partial exception of Fortnite. Except Epic wrote the engine (that PUBG is using) and they optimised it a lot for PUBG already and optimised Fortnite alot which PUBG then benefited from.
> They saw PUBG had great potential but was struggling to deliver a polished multiplatform experience. They had this brand new Fortnite game that they could mod a BR mode into relatively easily. They released it on platforms where PUBG was not available and on top of that they released it for free
Luck provided them with the opportunity, but their ingenuity is what let them take advantage of it and capitalise on it.
Of course it's not the same, but he's talking about "freely choosing and combining engines". UE was never even an option for indie devs a few years ago.
Besides, Unity clearly stated that Improbable knew about their TOS violation for at least half a year and Unity's reasoning also makes some sense, as Improbable is bundling Unity's SDK in their product. Problem is, that it's too late now because Improbable blew this up from their perspective omitting important information about what was actually going on.
Freely choosing does not mean getting things for free. You can freely choose to combine technologies/tools, but you must still have licenses for said tools. Unity’s terms out right prevent you from using some tools, regardless of if you have licenses or not.
As an analogy, I have the right to live anywhere I want in my country (where I live is a free choice), that doesn’t mean I can afford to actually do so.
No, Unity's terms state that you need an additional license if you want to use some tools because that's how it's monetized. Remember, Unity's licensing has to be more complex because it supports free usage as well as paid usage and does so all without royalties.
Saying that Unity is wrong because they have complex licensing is just as misguided as saying that Epic is wrong because they charge royalties. Should Unity invest $25 million into a fund for "royalty-free game engines"?
>Unity's terms state that you need an additional license if you want to use some tools because that's how it's monetized
That's a bit dishonest, when they say "you need an additional license" for cloud platforms they mean a custom license that has to be directly negotiated with Unity, it not just something you can click and buy; meaning no transparency and pretty much a closed door.
> Not so long ago Epic was selling their Engine for hundreds of thousands of USD
? Hasn’t Epic always been quite mod/dev/indie friendly, giving away the Unreal SDK for free, publishing is free for non-commercial projects and as long as you weren’t an AAA dev/publisher you ‘only’ had to pay 5% of your profits once you made over $100.000
Extensive mod support has been present in the Unreal Engine since day one - it wasn't full source access to the engine itself, but people built some really impressive stuff on top of the Unreal games back in the day.
UDK was Unreal 3 based. Prior to that, every AAA engine in existance was expensive, it took some time for that to change and Epic with UDK were part of that change. I remember UDK being the first up-to-date (ie not old engines like how id open sourced their old engines) big-name AAA engine that I could download and tinker with for free as a hobbyist.
it's dishonest only because you have a certain opinion. which kind of doesn't reflect how honesty and dishonesty are meant to be used to describe things. if you are surprised or disappointed that a big business acts like one, then perhaps you should do some market research.
epic had a fine licensing scheme before with udk which was modernised along with the market. as well as the additional services they now provide. without these services and the quality of games they produce they would have no fortune.
They realise, in the market, you need to keep growing or go bust, so further developments and improvements are made. its not dishonest or unfair - tried running a business lately?
Engine license fees, high or low, are known in advance and threaten only the optimists.
The "accessibility" that is at stake is of a different nature: game developers expecting Improbable middleware to serve them as dependably as their game engine, without suddenly disappearing into thin hair because of a usage terms dispute and at the whim of Unity.
They still sell their engine with royalty-free licensees for six to seven figures. Most large productions that use Unreal are opting for that. I assume they still make most of their licensing revenue from these sorts of royalty-free licenses, just as they did a decade ago.
> More than a year ago, we told Improbable in person that they were in violation of our Terms of Service or EULA. Six months ago, we informed Improbable about the violation in writing. Recent actions did not come as a surprise to Improbable; in fact, they’ve known about this for many months.
> Two weeks ago we took the action of turning off Improbable’s Unity Editor license keys. This is a unique case — and not a situation we take lightly — but Improbable left us no choice. This was the only course of action to protect the integrity and value of our technology and Unity developers.
Yikes. Not exactly what Improbable was claiming...
So Unity alerted them that where in breach, they had an ongoing discussion in which unity finally came to the conclusion that they where in fact not in breach... and then they changed the conditions and punished them. Is that how that is to be understood? I mean otherwise why alert them if being in breach before the license change, or why no punish them under the old license but change it first and then punish them?
No, they were in breach before hand, and Unity attempted (poorly) to make it more clear why Improbable was in breach with the ToS update. According to devs knowledgeable of Improbable's tech, Improbable has been in breach of the Unity ToS for more than a year. Negotiations on licensing probably broke down (as in, Improbable refused to pay the fee Unity was asking for a license), and so Improbable decided to publicly vent and mislead devs.
Regardless, the ToS are incredibly vague on what is/is not allowed, even for developers that have nothing to do with Improbable.
Finally, the $25M comes from the already established Unreal dev grant fund - it's not "new" money, they just rebranded a portion of the fund in a PR stunt.
Because they said "overnight" it make everything they said invalid? Because Unity contacted them a year ago make this an non issue?
Don't you agree that based on the EULA, that this:
> Projects that are currently in production or live using SpatialOS are not affected by any actions we have taken with Improbable.
> If a game developer runs a Unity-based game server on their own servers or generic cloud instances (like GCP, AWS or Azure), they are covered by our EULA.
This is merely saying that they will selectively apply their EULA, which from the beginning is extremely vague, even more so before the previous update.
What's even a year in game development? Could you abandon your whole game source code in a year based on Unity deciding to apply their EULA to you specifically? I don't think so.
Could you force your whole user base to stop using your whole system because Unity decided to apply their EULA to you specifically? That's what they asked them a year ago and overnight made more clear in their EULA.
What Improbable said is true, the issue Improbable raised, is true. Whether they have been told this a year ago, or today, doesn't change that this practice from Unity is extremely awful and put in danger EVERY SINGLE entity that Unity may not like in the future. Personally I think what Improbable did by waiting a year was extremely generous, they gave Unity a year to change their stance and not start to apply their EULA selectively like that.
Overnight, Improbable showed to the world the true nature of Unity.
Improbable stated, up front, that they were in negotiations with Unity. The disagreement seems to be that Unity claims they were in violation of the TOS the entire time, while Improbable claims the recent changes to the EULA are what they now violate.
> I really think Unity went above and beyond, here.
Nonsense. Unity likes to portray itself as the "open" alternative to other gaming engines, when in reality they have an iron-fisted grip on everything distantly involving their platform.
> You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity. Without limiting the foregoing, you may not use a managed service running on cloud infrastructure (a “Managed Service”) or a specific integration of a binary add-on (for example, a plugin or SDK) or source code to be integrated in the Unity Software or Your Project Content incorporating the Unity Runtime (an “SDK Integration”) to install or execute the Unity Runtime on the cloud or a remote server, unless such use of the Managed Service or SDK Integration has been specifically authorized by Unity. Additionally, you may not integrate the Unity Runtime with a Managed Service or SDK Integration and offer that integration to third parties for the purpose of installing or using the Unity Runtime on the cloud or a remote server. For a list of Unity authorized streaming platforms, Managed Services and SDK Integrations, click here.This restriction does not prevent end users from remotely accessing your Project Content from an end user device that is running on another end user device. You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services.
Here's  what it used to say:
> 2.4 Streaming and Cloud Gaming Restrictions.
> You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software, or your Project Content (if it incorporates the runtime portion) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by a server and transmitted over the Internet or other network to end user devices without a separate license from Unity. This restriction does not prevent end users from remotely accessing your Project Content from an end user device that is running on another end user device. You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services.
Whether that's a change or clarification of Unity's intent is rather subjective.
I've been using Unity on and off since 2008. All I can say is that the whole day's events were just bizarre. There's this thread on the Unity Forum with close to 500 replies as of now. In the thread are mostly people lashing out at Unity. Mr. Sweeney also linked this thread on twitter saying this thread is "full of highly intelligent indie devs having an insightful debate about engine EULAs and their legal ramifications".
I must have a very different set of eyes than Mr. Sweeney here. But the first 200 or so replies were made before Unity could even post a response. They were mostly speculations and mods asking people to calm down and wait for an official response. This is mostly because Improbable's first blog post did not give any specifics and made it sound like Unity pulled the plug overnight (later according to Unity, Improbable knew about the TOS violation for over a year).
So then Unity made a response blog post. Improbable made a 2nd blog post. And Epic made their 25mil announcement. Then, that Unity thread has pretty much turned into a conspiracy thread fueled by the f#$@ed up timing of everything. "Highly intelligent" and "insightful debate" would not be my choice words to describe that thread.
And lastly, I want to say, even if Mr. Sweeney had all the good intentions, it was really painful to see Epic capitalizing on Unity in such quick manner and intensity. I was actually in agreement with his tweets before he posted the lame thread link and announced the 25mil fund to help people transition from Unity to UE4.
>There should me more push for really open engines, as in FOSS. Unreal might be more open than Unity in some ways, but it's still not really open.
This just isn't possible with game engines. They are the single most advanced pieces of desktop software in existence. Sure, there are things like Godot that are perfectly suitable for a simple indie game. But making a AAA game engine requires the expertise of literally hundreds of top level senior engineers with advanced physics and mathematical knowledge. There's probably less than a few thousand people on earth with the level of skill and expertise to build something at the scale of UE4. Furthermore, open source is really the exception to the rule in game dev. Practically everything is done closed source with some kind of licensing fees involved. It's quite a different culture from web dev.
This sounds more like an excuse rather than any sort of rational argument as to why game engines can't be open sourced. The reality is that there are plenty of projects out there helmed by incredibly talented engineers with extremely high level knowledge that exist in the open source realm; one only has to look at the geospatial community to see this.
Unity fucked up hard here and I hope that their planetary-level screw up will lead to game developers pushing for open source engines to avoid the control of their games being stolen.
>This sounds more like an excuse rather than any sort of rational argument as to why game engines can't be open sourced. The reality is that there are plenty of projects out there helmed by incredibly talented engineers with extremely high level knowledge that exist in the open source realm; one only has to look at the geospatial community to see this.
I'm not saying there aren't talented developers working in open source. But the sheer breadth of expertise required is unimaginable. You need top-of-their-field engineers from practically every conceivable discipline within CS to build a AAA game engine. Physics, lighting, rendering, networking, audio, UI, and that's just the tip of what I can think of. Engines like Rockstar's RAGE are easily on par with the Linux kernel for complexity.
>What do you think makes the complexity of Linux achievable with FOSS while the comparable complexity of a AAA engine not?
It just comes down to incentives. Practically every living human being stood to gain from the existence of a high quality general purpose FOSS operating system, and so Linux naturally came about.
The people who would benefit from a AAA open source game engine are... closed source AAA game development studios. As such there's really no incentive for some physics whiz to spend their extremely valuable time toiling away on something that is only going to be used for someone else's profit. The intersection of people who build game engines, and people who make games with those engines, is extremely small.
There's really no such thing as open-source game development except for hobbyists, because that would be literally giving your product away. Games are a hit based, one-and-done type product much more akin to movies than other software.
They give out Academy Awards for those, so there's a large prestige element. Also, not commonly known, but many FX tools are research-based so there's a strong research component driving many FX developments.
I haven't the faintest idea, which is why I asked aphextron. Indeed, until today I thought the Unreal Engine was FOSS, but seems to be just source-available. That said, didn't id Software / John Carmack release a bunch of engines under FLOSS licenses in the past?
There are many more or less serious potential explanations: not enough people care, it wasn't (or still isn't) financially feasible, the people able to develop AAA engines are actively against sharing source or ideas, there's an engine development cartel actively pushing against it to keep their revenue.
Or it might just be a social or historical accident -- we may just have been extremely lucky with Linux and projects on that scale will never come again.
Or maybe everyone thought it would be a great idea but they also thought it would never work and so no one seriously ever started an open source engine. Maybe Godot will be a true AAA engine that will surpass them all in a few years.
id Software released their old deprecated engines as open source, when they had new engines they were pushing instead. It was a nice friendly gesture, but the engines typically weren’t competing anymore.
There's also Blender. 3D modelling is arguably a fairly complex and large field (lighting, rendering, physics, simulations etc). Yet, the team behind Blender are doing an amazing job and the gap between commercial software (e.g. Maya, 3ds Max) and Blender are closing with every release.
Godot doesn't get much interest from AAA developers because typically they are interested in shipping on consoles, and it's impossible to support the current crop of locked-down proprietary consoles in a free and open source engine. Despite this I am actually very surprised at the speed that Godot has accumulated features. I think we will start to see it shape up a lot more when Vulkan support becomes first class. The culture change is happening, give it time.
In my (admitedly limited) experience with Godot, I think one reason it doesn’t get more interest from AAA is that the 3D support doesn’t perform that well and isn’t so solid yet. It will improve though and they are actively working on it. On a more fundamental level, Godot’s design internally isn’t very data-oriented (lots of indirection in their data structures), while even unity has switched (or is in the process of doing so) to a data-oriented design (thanks in part to Mike Acton working for them now, it seems), this means that Godot will always leave some performance on the table, since cache-efficeincy is very important for high end games. It can be improved, of course, but it will take time and Godot devs are (rightly!) averse to changing core internal stuff.
About this time last year, I wanted to make a simple little 2D platform game in Godot and my experience was mixed. Some stuff was really easy and pleasant, some stuff was middling and then other stuff was frustrating enough that I gave up: for example, I had to spend an entire day just so I could get sprites correctly sorted so that tilemap tiles and objects that were in front of the player would be drawn in front and those that were behind were drawn behind. Basic stuff. There’s an option to enable for this (y-sort) but it did not work without a bunch of unintuitive tweaking. The docuentation didn’t help, reddit couldn’t help, their discord couldn’t help and I wasted a lot of time on it.
Having said that, I have high hopes for Godot and I do think it has a bright future, but it has a ways to go. I’ve even made some (very small) contributions to the gdnative c++ library, so its not like I’m just complaining ;)
My point is that Godot doesn’t get much interest for more reasons than just consoles (there’s commercial support for porting available). But, as you say, the culture change is happening, it just needs time.
> actually that is what saved them from the dumpster like quality
Did it? Lot's of gamers see consoles as something that holds developers back from using better hardware, since they need to target 5 year old systems. Quality both artistic and technical isn't something consoles can claim to be leading in. And clearly, "consolization" in its various forms isn't something gamers appreciate, when it spills out into PC gaming.
On the contrary, professional game developers love game consoles, precisily because they have a stable platform to target for at least 5 years, instead of dealing with each customer being a special case.
And that in spite of some bad apples still going through the gates, the large majority of flappy bird clones never makes.
Easier to work with doesn't make it higher quality overall. General perception of console games is exactly reduced quality, in the sense of art and games mechanics (due to mass market appeal and controller oriented design) and in technical aspects simply due to outdated hardware.
Incumbent consoles are trying to dig themselves out of this perception now, but they got it very deservedly.
There's a big difference between "not using cutting edge hardware" and "unplayable games sold at full price that become literal trash before they're ever even opened".
The average game on a console is going to be higher quality than the average game on PC because the average game on PC has to include the game I made in Visual Basic 6 when I was in high school. With no gatekeeper ensuring basic quality, my VB6 game is every bit as legitimate of a game as Battlefield 5. They both hold the title of "PC Game", but only one of them could ever be called "Xbox Game" because Microsoft would never allow my game on their console.
I don't think "average game" is a valuable metric. What is an "average book", or "average film"? Art isn't measured by averages really, but by what's available. I'd say, PC gaming offers better tools for artistic expression, including more complex games that console market deems as not fitting.
Technical limitations that hold developers back are only part of it. Another issue is simply creative control of incumbent console owners. PC gaming doesn't have it, so creators can do whatever they want. And masterpieces are always a minority, no matter in what form of art.
I feel like you're still missing the point. Your argument is that consoles have "dumpster quality" games simply because their hardware is outdated compared to state-of-the-art PC hardware, which is such a non-sequitur that I'm not even going to touch it.
Pre-crash there were tons of high quality artistic masterpieces on consoles too. But it was swimming in absolute garbage , turning a lot of customers off , losing their trust , and threatening the entire platform . If you haven't followed any of these links yet, PC gaming still has that problem.
The argument isn't that PCs have more powerful hardware (the reality of which is debatable ). The argument is "do console makers guarantee quality better post-crash than they did pre-crash" and the answer is unequivocally yes. The question you then raised was "do console makers guarantee quality better than PC games" and I would still argue unequivocally yes. And then I would point out that PC gaming benefits from this, because if Activision wants Call of Duty to sell on consoles, they're going to make sure it passes Sony and Microsoft's quality standards, which then the PC game most likely will pass as well.
This isn't always true, of course, because there are plenty of times a game runs better on consoles than it does on PC . That's probably what you refer to as "consolization", but again that's just missing the point. People buy consoles these days because they work and they work consistently. That's directly the result of the post-crash quality control that console makers implemented.
If you don't want to touch the topic, then don't. It's quite obvious outdated nature of consoles hardware is holding developers back, and "consolization" spills out to PC gaming, to the irritation of many gamers. You don't need gaming articles to know that.
> That's probably what you refer to as "consolization"
No, I refer to cut down design, oversimplified interfaces, lack of depth and etc. which were characteristic for console games, backfiring to PC games, when developers don't want to do extra work and simply use "one size fits all" method to save time.
Technical limitations is only part of the problem. The bigger one I'd say is the incumbents' control over the platform and heavy mass market bend. Quality has many meanings, and poor art (in many meanings of the word art, not simply graphics like you might think) caused by mass market commercialization can justifiably be understood as reduced quality.
So, I'll stick to what I said. Incumbent consoles didn't save games from worse quality, they actually made them worse.
Recent Nintendo eShop and PlayStation store releases are quickly driving down the average console quality. (See Life of Black Tiger, for example). Though, I must admit, it is not something I'm actually concerned about.
Sure, you can make good art with minimal tools. But consoles for a long time were not after good art (in its various meanings), but after mass market. So art suffered, same as technical side of things. My point is, consoles don't have any claim for higher quality in all meanings of the word.
Collaboration solves this. Instead of reinventing the wheel, collaborating on the engine can pool resources. This works in other cases, so why not with engines? It's not engines that are sold, but games. Having good open engine doesn't prevent developers from selling games made with them.
> There's probably less than a few thousand people on earth with the level of skill and expertise to build something at the scale of UE4.
That's really bunk. I mean "only elite can do it" it claim. Sure, it's not something you can create in one day, but it's not something that out of reach either, especially when people are collaborating on it.
>That's really bunk. I mean "only elite can do it" it claim. Sure, it's not something you can create in one day, but it's not something that out of reach either, especially when people are collaborating on it.
The graveyard of hundreds of abandoned open source game engines begs to disagree with you. I agree that it seems absurd, but you really can't underestimate the amount of man hours put into these things. Unreal has been under constant development for over 20 years.
It's the same as flight simulation. Why is there only one viable flight simulator (X-Plane) on the market? It's because that kind of coding is simply beyond 99% of developers, and it takes a huge well funded and focused team to make something state of the art.
Same claims have been made about codecs. "Only elite can do it", "you can't make it open" and etc. Yet, we have great open collaborative projects today for state of the art video and audio codecs. So it's not a technical issue.
There’re are some difference between a codec or OS with a game engine. One is the user base. I think there’re simply not enough game developers to extensively use the open source engines, every single computer needs an OS and in most cases needs a codec. But not everyone is a game developer.
Another one is requirements I guess. For OS and codecs, I think the requirements are much more defined and manageable, but for a game engine the user uses it to create something else, hence the capabilities needed from the game engine may change wildly per project.
What about the hundreds of thousands of abandoned open source web apps/tools/libraries? I guess only a small few elite are able to write any functionining code at all, then?
A commercial quality game engine is a huge project, and as such, requires a huge projects worth of time and effort to build. Same as any other huge software project (which all have countless abandoned open source attempts). Remember that most open source projects start of tiny (one developer is common, certainly very few start off with more than a handful) and work on it in their free time, while commercial teams like Unity have hundreds of peolpe working on it full time.
The reason they are abandoned is typicaally that 1) the developers, who are doing it in their spare time, don’t have the time anymore; or 2) they get frustrated at the amount of work/lack of contributors/lack of interest and stop working on it; or 3) they simply lose interest and work on something else.
Its not lack of ability, its lack of time/motivation/interest to keep working on it for many, many years.
There are hundreds of abandoned open source anything. There's no barrier to entry and and no incentives to keep working on things when you're no longer interested in doing so. It doesn't mean anything.
From what I've heard and experienced, you need at least the following knowledge to create a good game engine:
- Understanding of modern CPUs / GPUs and the capabilities/shortcomings they have
- Understanding the behaviors and quirks of the OS
- Familiarity with multicore programming
- Skillful memory management (such as making your data structures less prone to cache invalidations)
- Mastery of a low-level language (C++, Rust, whatever)
- Familiarity with build systems (CMake, SCons, etc, ... or sometimes you might have to roll your own)
Already I could see the number of contributors who would know all this stuff being pretty low. (I've dabbled a bit in graphics and made a simple OpenGL scene graph renderer and a fluid simulator, but I still don't feel like I'm competent enough...)
An engine is comprised of multiple components (Graphics, Sound, Physics, etc...). So you wouldn't need to know all of it, but contributors would need to have a clear grasp on at least one. So for each component, you would need...
- Entity System: You need a universal way to handle game entities. Implementing it efficiently requires a good knowledge of computer systems, because you need to think carefully about how you store data in the memory.
- Job System: You need a system to execute various tasks (rendering, physics, game logic, ...) simultaneously on multiple processors, so that a single game frame can finish in less than 16 milliseconds. Implementing this would require some knowledge in concurrency as well as OS concepts.
- Resource Management: You need a way to store and keep track of the game's various data stored in files, such as images, models, sounds, game objects and their parameters, settings, etc. You need to implement efficient serialization and compression for this.
- Graphics: Mastery of a graphics API (OpenGL, DirectX, Vulkan), and understanding its various patterns and shortcomings. You also need knowledge in how rendering works (which also requires some math), and nowadays a PBRT renderer (https://www.pbrt.org/) is basically a minimum requirement for modern 3D game engines.
- Physics: Lots of math and physics (Linear Algebra, Differential equations, Mechanics, etc.), and also optimization skills like assembly and SIMD (speed is critical in this area!). Fortunately many people just use already-built middleware such as Havok or Bullet..
- Sound: This is actually the most neglected part in game engine development, and it is hard to find good resources on this.
I think the people who would have the knowledge to build a game engine would be already busy working on other stuff, such as working for an AAA gamedev company (which sometimes does a lot of crunch, so they might not have enough time for open-source stuff), or a proprietary game engine company like Unity or Unreal. But I still see some hope around the edges. From what I've seen, Handmade Hero (https://handmadehero.org/, which is a livestream of making a game engine from scratch, accompanied with various education materials) is the most impressive. It tries to teach those skills needed to make a game engine to interested programmers, which I think is a crucial first step in encouraging open-source gamedev.
...and you need tools and editors to make the content for the engine in proper format. That is the "boring part" OSS projects usually lack since writing renderers and job systems is much more fun than fighting with inconsistencies in scene formats or writing custom importers.
Creating a high quality game engine is by no means an easy task, but you don’t need each contributor to know all of these things and you can use existing libraries for a lot of them. A lot of the things you mention have good quality MIT-licensed (or similarly liberal license) libraries you can use to save time. Its still going to be hard, but its not thaaaaat inaccessible.
Some examples: for entitiy systems, EnTT is amazing. For a job system you’ve got stuff like cpp-taskflow, for physics there’s bullet, for graphics there’s bgfx or full blown renderers. Sure, these won’t solve all of your needs, but they’re a good starting point that frees you from having to do a lot of stuff yourself.
> That's really bunk. I mean "only elite can do it" it claim. Sure, it's not something you can create in one day, but it's not something that out of reach either, especially when people are collaborating on it.
You need to be damn near Johnathan Blow levels of skill and perseverance to create a decent game engine.
Maybe you wouldn't classify him as an "elite", but I sure would.
It has been demonstrated possible for a large range of projects that are similar in complexity. For example: web browsers (Firefox), OS kernels (Linux), 3d-modelling applications (Blender), compilers (GCC), databases (PostgreSQL).
Won't be easy for sure, neither on technical nor marketing level. Many of the successful examples took 10+ years before they got really viable. But to say it is impossible to do this for a game engine, just because no-one has done it yet, is defeatist.
Exclusivity is key to break the Steam monopoly, unfortunately. Right now, everyone's game libraries are effectively Steam libraries. So when people go to buy one more game... they go to Steam, naturally.
The best way to break that is to not sell games on Steam. Another way is what Epic is also doing, giving away free games to build up people's library on their store as well.
If I recall correctly it still requires you to install all the clients for the different game stores and use them for purchases and updates and lutris simply displays all of your games. Not nearly as useful as we need but its significantly harder and probably against some ToSs to do what I am thinking.
That would probably be the easiest way to counteract Valve's near-monopoly. I know I don't want to have a dozen different store fronts with different interfaces, all demanding updates, all wanting to start on boot. I assume others feel similarly.
But if there was a single interface and all I had to do was add my credentials for store X? That's not so bad.
Are there websites that aggregate the games from all the stores? That would at least give visibility to the rest of stores. Combine with metacritic and show price over time and per region like steamdb.info and you have something many would use.
For every person that buys directly from the developer, I expect there are several order of magnitudes more people that buy through steam. If you're a drop in the ocean, that doesn't count as "not really".
I'm impressed with the speed at which Epic is capitalizing on this. Tim Sweeney's twitter feed has been brutal all day, and now this. It's possibly not even real money being spent, if it's just "Unreal dev grants" which I assume are licenses that probably cost Epic little or nothing, but this will keep the story alive tomorrow.
yeah I mean, it's impressive how they inked a $25m contract on the same day mostly after hours, and had time for their lawyers to write and negotiate the contract and their press people to put out the PR content for it. Like wow, Improbable's lawyers, and Epic's lawyers, and Improbable's PR, and Epic's PR are all so incredibly fast. Especially considering Improbable's own ToS forbids you from selling your game made on Epic's store (https://auth.improbable.io/auth/v1/eula section 4.4), so Epic and Improbable didn't have a standing relationship but started a new corporate partnership in like six hours. Wow, so fast!
or maybe the whole thing was orchestrated? I honestly can't fathom how people are buying the story that Improbable is putting out. It's ludicrous.
Is this related to the "commoditize your complements" article from Gwern? 
More open game engines = more high-quality games from developers that can be acquired, or lowering the barrier to see what new game types start gaining traction so they can come in with a AAA version of the next MOBA, Fortnite, Minecraft, etc.?
This project has actually really matured in a fantastic way! I have been toying around with it in the past few weeks and have been incredibly impressed with their progress! I would definitely want to use Godot for a serious project. Although I am a bit nervous that things become more challenging in more complex projects. Anyone have any experience here? I poked around for some serious Godot projects and haven’t really seen anything too large.
I've spent quite a few hours with games based on the Irrlicht. Nice to hear it's still being improved. Have you looked at the work the SuperTuxKart devs have done to add shader support? I've played a few round and the new tracks are gorgeous.
I really like Irrlicht so nice to see a mention. I played around with it a while back, using GDAL to read raster data and Irrlicht to display/animate it in 3D, and was very impressed by its simplicity even for someone coming to it with no C++. I learnt so much just from a few days hacking.
There's OGRE as well of course, but I seem to recall there was some weird preprocesser step to compilation that put me off it: https://www.ogre3d.org/
So section 2.4 is at least a month old at this point. They said nothing to their customers for over a month? Then they created a storm in a teacup, and a bunch of developers freaked out and took their own games down on their own account without ever receiving any sort of notice with Unity. Improbable intentionally manufactured a panic: none of these game developers were contacted by Unity or asked to take their games down.
And then there's the other thing: SpatialOS is NOT an open system. The fact that they're playing up their openness is the definition of smarm: the form of virtue without the substance. They have an open source client but the server is not open source. You can't run your own SpatialOS instances. If you integrate their GDK into your game, you can ONLY use their managed services to host your multiplayer server. It's purely a vendor lock-in model, they just pretend to be open source by having open source clients.
None of the articles that have written about this have had anything to say about Improbable's ToS, none have reached out to Unity for comment, and none have reached out to any of the game developers whose games "were affected", when none of the games were issued any sort of notices by Unity and none of the games had any reason to be taken offline. Everything about this story has been driven entirely by Improbable, without any scrutiny whatsoever, but if you look more closely at what's going on, there are a lot of stones to turn over.
Agreed. I have a platform that runs a headless version of the Unity editor on an EC2 instance, and I read their terms of service ~2 years ago that indicated that it might not be totally "ok". I then chatted with the guy from Unity who handles these kinds of licenses/partnerships and he said basically once real money starts coming in, then we'd put together some kind of licensing deal. Until then, totally fine.
My suspsicion is the price was too steep for Improbable, but they should have been talking to Unity about costs from the beginning. Even I have a backup plan.
And Epic... I didn't like the way they rolled out the "free" version of UE4, perfectly timed to fuck with Unity and this certainly feels similarly sleazy. Back in 2006 when I was first attempting to do some 3D interactive projects, I couldn't even EVALUATE unreal engine without paying something like $500. Unity was a miracle.
Absolutely. They have totally ignored their end customer - the game developer. Multiple studios have had to shut down their live services due to this.
If Improbable and Unity have a dispute - so be it. But they should have given 6 months notice that negotiations have failed and that services would no longer be available via Unity.
Its just all-round bad news for Unity though. With cloud services and multiplayer going to be a major force of gaming in the next 20 years - how much do you want to invest in a game engine which has locked you out of using an ancilliary service?
Unity need to just move on to charging a % of total revenue like Unreal does.
If Unreal used C#, I would have used that. But the reality is that as a micro-studio, its really difficult to find C++ programmers. In some cities there are 20x as many Unity programmers as Unreal programmers. Generally Unity is a bit more reliable and less crashy as well.
IANAL but for me that looks like also banning the usual method of implementing your games server in Unity if we think it also bans SpatialOS.
For me the old terms look like trying to get more money from services like PlayStation Now. However if they really did forbid SpatialOS then that means every single mobile game with server implemented in Unity are also breaking the TOS and should be shut down asap.
Rergardless this debacle proves that Unity is more than willing to interprete their TOS quite liberally if they smell money. So if you build a big MMO that rakes in billions you should expect Unity to barge in and use that, or some other, part of TOS to demand more money from you.
EDIT: My hunch in how this went down. Year ago unity told them that 2.4 breaks the TOS and wanted more money. Improbable said "Nuhhuh, can't you read?" until Unity changed their TOS and said "Yeah! It does!".
So if Unity ever says that you break their TOS and they want money it's better to pay them regardless of what the TOS says because otherwise they just change the TOS retroactively.
> For me the old terms look like trying to get more money from services like PlayStation Now. However if they really did forbid SpatialOS then that means every single mobile game with server implemented in Unity are also breaking the TOS and should be shut down asap.
> Rergardless this debacle proves that Unity is more than willing to interprete their TOS quite liberally if they smell money. So if you build a big MMO that rakes in billions you should expect Unity to barge in and use that, or some other, part of TOS to demand more money from you.
Everyone that defends Unity here seems to forget that, which is 100% of the issue here. When Unity warns them a year before or whatever won't change a thing, theses terms are so wide that everyone using it on their servers are in danger and this is the true issue.
There's not a single time frame that would allow any game to move out of Unity, even more so a whole platform like SpatialOS that would imply many games. That would be incredibly expensive too.
Personally you would have told me the same a week ago, I would have said I trust Unity not to do that to their customers, now because of Improbable, I know this is false. Now I know that if they see more money to be made, that I would actually actually lose the rights over my games binaries.
Right, the clock starts ticking when they make the TOS violation public knowledge, not when they privately confer about it, because it is only when it is public that how wide they are interpreting the TOS violation and how it may affect everyone else can be seen, including whether or not they plan to enforce it equally (which can be a determiner in courts if the TOS is enforceable at all if they are only picking and choosing violations per whim as opposed to equally enforcing all of them they become aware of, though IANAL).
Even from Improbable's standpoint it made at least some sense for them to assume it was just personal bullying until the very minute Unity made it a public issue.
They state: “At the core, the Streaming and Cloud Gaming Restrictions terms are still the same as before. We received feedback that the language was ambiguous, so we updated our Terms of Service to be clear on our distribution and streaming restrictions.”
Which I highly doubt. But IANAL.
It just seems silly that it went “your in breach of our conditions!” “No we aren’t” “Yes you are (also we just now changed them”.
"They broke our made up rules". I don't think after that post anyone is going to claim Improbable was right. But Unity cutting off access sends a we-can-kill-your-access chill which to many isn't "right". A more open platform can't do that.
Instead Steam/Valve should fund open-source game engines and development tools. For them it is a complement to their business model, so the incentives are aligned. And they can ensure a smooth path to market for the game developers. Everyone wins (well, maybe except for Epic/Unity).
OK, what does "more open engines" mean? UE4 is open source, with payments required if you have significant revenue. That's fine. Improbable is closed source running on Google servers with a big markup; you're just the client. Does this mean Improbable is opening up the back end? Or what?
Linux gaming support is really at the mercy of the engine Devs wanting to do it. There isn't enough of a market share for it to be "obviously viable" (i.e. stupid not to do it) last time I looked into the numbers.
Both Unity and Unreal Engine are multiplatform enough to support compiling a Linux version of your game just by clicking your mouse -- everything just works out-of-the-box with no extra work needed. That's why there have been so many more Linux games on Steam in the last few years than there ever have before (I remember 10 years ago when the iD Software games were pretty much all we Linux gamers had).
It's AAA games that use their own engines and developers that are too lazy to click the Compile for Linux button in Unity that are holding us back.
> everything just works out-of-the-box with no extra work needed
I would be extremely surprised if that was true for anything other than relatively simple games. No matter what cross-platform abstraction you use, you can never totally get away from dealing with the actual platforms.
Ah yeah, remember when Epic Games stole the concept of a popular multiplayer battle royale game? I'm talking, of course, about The Culling, a game about a year older than PUBG. And other than the 100 player sized games and parachute mechanic, it's frankly not that different from the rest of them.
Snark aside, PUBG built a little on the battle royale formula. Fortnite built a little on the battle royale formula. Both Bluehole and Epic Games were madly successful. Maybe PUBG would've done even better had Fortnite BR not done so well as a free to play experience. But it could've also done better if it wasn't a buggy mess for like an entire year after launch, one that costs $20 and never seems to be on sale.
There's a reason gameplay mechanics aren't copyrightable. This is how game design evolves. I'd hate to live in the world where ID software permanently owned the rights for making first person shooting games.
One could certainly argue there is some conflict of interest in that Epic Games has a conflict of interest because they licensed their engine to Bluehole. But Unreal Engine is a fairly popular game engine, and I think it's unreasonable for them to not be able to be inspired by games written on their game engine.
There's a reason gameplay mechanics aren't copyrightable. This is how game design evolves. I'd hate to live in the world where ID software permanently owned the rights for making first person shooting games
Wasn't there a problematic patent on The Incredible Machine that kind of killed that genre for a while?
Seems like all the major game companies have cloned PUBG. Activision with the new CoD, EA/Dice with Battlefield's upcoming battle royale mode, Epic with Fortnite (no gore and targeting a younger demographic and long since expanded into something a good bit different), and now finally Valve, who presumably took 30% of PUBG's revenue instead of the ~5% Epic were paid, without even providing much of the code, have also cloned it with CS:Go's new Battle Royale.
You can't copyright a game mode, and PUBG took lots of aspects from others too.
Other than the drop and the number of players, did PUBG really add that much _new_ to the film Battle Royale, which clearly inspired them (both in mechanics and skins)? It seems a little unfair to give them sole claim to the idea.
Bomber Man introduced 8 and 16 player battle royale in the 1990s. At the end of a match the arena begins shrinking to force players closer together. It also had variable size squad play. I’m surprised Bomber Man is never mentioned as an inspiration for these games.
Hmm, It's almost like you're implying that Epic didn't make those improvements available to Bluehole before Epic even released Fortnite.
Bluehole squandered part of their momentum by failing to continually rebase and track UE4 improvements that were made specifically for them. Allowed hackers to take over the game, and then cried foul when their player base dropped.
Also people seem to forget that H1Z1 had a royale mode before PUBG existed. ARMA 2 also had a mod, made by the same creator, who based the idea off of a movie of the same name.