“Games as a service” is fraud.

The only fraud I see is false advertisment. They say that they sell games but instead they sell what is basically a client to service provided by their servers.
I think that this won't stop and at best you could force companies to make sure to clearly state that the function of the software is just to allow access to their service and to make them run their servers for at least a certain period after they stop selling the client.

Therefore I think that going the way of games are art, has more of a chance of stopping games from dying. First step is easy - games are art and honestly it is surprising to me that it seems not obvious to many people. Film is a combination of pictures, music, storytelling and the filmmaker's ability to make it work together and it was accepted as art long ago. Video games are just the next step.
Successfuly arguing for the need to preserve this art, you would cover everything - subscribtion based games, multiplayer only games, emulators, online archives preserving games and when it is ok to upload game files to archive them (thus possibly solving the gray area of abandoned games).

Hello everyone,

Hope not to butt in too aggressively here.

i think the money part is obviously very important. This has been observed even when games where a far cry from the kind of business they are now, and even if games were not so widely lauded as art as they are today, they were at the same time not simply considered "products" to shell out each year as much either.

So for profits, the server model is probably not only about anti-piracy, but about selling "new" products continuously, and Ross mentioned some things in the video that do show this kind of "selling then breaking the games" might have something to do with it, for example when he relayed that it will take a week or so for the developers to make a game ready for long term enjoyment, just like we would hope for games or (non-live) art to be.

So the time and money involved is not too significant (and worth it, if the proud developers are trying to preserve an evergreen..) . It would also not affect the company's income in any way as they have stopped to sell the game at this point any way, it is "dead". Only that, were it still alive, fewer people would buy the next game that is exactly the same but with updated graphics.

 

By the way some people still play Tribes 1, it is possible to download for free, only most servers are in the US. Great game, but sadly people have wandered off to the sequels

 

Regards

 

Just playing a devils advocate here: companies can just create new shell entities to run the game and shutdown the whole controlling entity on game termination. No one to sue - no liability.

 

The point is - I really interested WHY companies are going with game-as-a-service. As you've correctly mentioned - it's a lot harder and actually maintaining the game servers cost money. So while it generates more money, it's also more risky and a bigger investment. Yet publishers seem to be throwing money at very weird projects, that would be quite risky even under normal model.

Thing is - if that's just piracy thing or microtransactions, then it would be not so (relatively) hard to "persuade" (using a strong argument of legal gun and a nice word) companies to stop ensure end-of-life plans. But if they have some other reasons - they may fight it to death.

And about that "minimal plan". I am a game engine programmer, so I know quite a bit about it. It's not that easy - there are third-party libs everyone are using that bound with license to the product. You can't just "release" the server in many cases - it's tied to client (code share) that uses those third-party libs, it's tied to platforms and SDKs that are usually under NDA.

So they have following options:
1. Release source code for the game/server side without third-party. In most codebases I've seen that would be a gigantic work (because most game codebases are a mess). Plus server side software is usually where know-how of a game is. Also depends if they are using some sort of commercial engine - their license may just well forbid it.

2. Release server executable - that really depends on the game. For MMOs that's practically impossible, as MMO server is a conglomerate of executables and services with special configuration, usually heavily tied to the platform it runs on. So basically they will have to provide a hell lot of stuff that will only be able to be run by someone who have enough money to run it on commercial cloud platform. I.e. they will just give it to their competitors.

3. Release game server assets and data and provide information about protocols and stuff. Same thing - most codebases are a mess and such information will usually show much of a mess it is. No one likes to be a laughing stock, plus yes - it may help "hackers" against other games with same tech. Which again may run into legal issues if they are using some third-party software to implement those algorithms.

4. Provide data and means to reverse-engineer everything else - legal problems against third-party. Plus it's like giving everyone a free pass on reverse-engineering their products. Legal teams will NEVER approve something like that.

Plus I do believe that in some cases games are being shut-down to avoid competition with a new game. Which kinda kills the purpose if you release it afterwards so people can play the game you were supposed to kill. Not all killed games are like that, of course, but companies will fight against any law that will forbid them doing that.

In short - while for some games (say Destiny) releasing their servers is trivial and won't take much effort, for others that will basically amount of giving up very expensive tech for free that can be used to build similar games in outside jurisdictions (i.e. China).

So I think it would be nice to distill down use-cases and reasons and try to find some compromise. I think in general large scale open-world MMOs with centralized server are most probably won't be able/willing to provide end of life solutions. They will just avoid legal trouble by moving into other jurisdicions, shell companies and whatnot.

Games that are basically single-player with additional multiplayer made online-only (such as Destiny, which is actually p2p with very little on the server, or many of online-only games like Sim City, Diablo 3) - those can be forced to develop such new games with end-of-life in mind. Existing games are probably lost.

So it really goes on how much of technology and know-how a game company will have to forfeit to implement end-of-life. It's like enough to build a similar game on similar commercial scale - they will never do that.

18:57 Where do I find the List of the Video games, that got shut down?

1 hour ago, Heinz said:

18:57 Where do I find the List of the Video games, that got shut down?

Extended version: https://docs.google.com/spreadsheets/d/1vaNfqOv3rStBQ4_lR-dwGb8DGPhCJpRDF-q7gqtdhGA/edit

Ross should probably add it to the video description.

After watching your video i decided to add guaranteed working period in description for my games i think its very good practice.
Games have two parts: software and services. The software is good and ussualy you are actually buying software and in addition you are provided with access to the services.
And, as a game producer, i can say that it has nothing to do with a 'games as a service'.
GAAS is gamedev term which describes a way of managing game production. You have to spend more time and resources in operating stage by constantly providing new updates to retain players in contrast to 'traditional' model 'ship and forget' there you spent all money on initial development.  
Also, as a game developer, sometimes i don't want to share server and client code even if support of the game has ended, because i ussualy reuse that code a lot and i don't want to have my production code in public))

 

18 hours ago, NightNord said:

I really interested WHY companies are going with game-as-a-service

Because GAAS is very good for MMO, f2p games. Also it is less risky because you will release your game earlier in dev cycle, will receive players feedback and that will allow you to make changes w/o spending a lot of resources on remaking whole game. Better games with less resources is very good for small teams.

19 hours ago, NightNord said:

And about that "minimal plan". I am a game engine programmer, so I know quite a bit about it. It's not that easy - there are third-party libs everyone are using that bound with license to the product. You can't just "release" the server in many cases - it's tied to client (code share) that uses those third-party libs, it's tied to platforms and SDKs that are usually under NDA.

 

I'm not even pretending to be knowledgeable on that part, but I've gotten a few messages on this that I've been referring to the person who worked reverse engineering a server emulator.  Here's a general response I've been sending, no one's replied back yet:

 

I was only talking about the "minimum effort" options to give users a fighting CHANCE to create a server emulator.  To that, he replied with this:

 

"On the documentation part, it would highly unusual for the server engineers not to keep SOME packet documentation during development since the server developers and the client developers are often separate.There is guaranteed, at least SOME packet documentation. There has to be. Like imagine that packet 02A sent a 8 bit packet of numbers, and it had to do with say, MPH in a racing game. This is really simplified, but you'll get the point. Then one of the 20 programmers comes along and has to ask EACH TIME what packet to check for that info.There's no way, at that point it becomes a profit loss not to have the server developer just type what it fucking is into something like OpenKM so people can search for it."

 

He also attached a comment somebody else made in the comments (attached below)

 

 

If you're saying that's still way off base, feel free to give specifics that I can pass on to him.  If you have specific grievances, you can even get as technical as you want, so I can pass it along to him even if it goes over my head.  On that note, I have some questions for you if you don't mind:

 

1. Since you're saying his time estimate is way off base, in your opinion, what is the BARE MINIMUM of effort a developer can do upon game shutdown to give users a CHANCE to attempt to create a server emulator?  In other words, not a functional emulator, just enough info to not make things an almost-impossible task.  Everyone seems to agree that disabling packet encryption is a big one (that alone could save YEARS or work).  What else?

 

2. How long would you estimate your bare minimum effort solution would take to implement?

 

3. The above is referring only to games that had no EOL plan to begin with.  But say you were creating a game from the design phase where you knew you wanted an EOL plan upon shutdown so users would have some method to run the game upon shutdown.  Assume it doesn't need to retain 100% functionality, so it may not contain things like auction houses, matchmaking, or being able to handle the same volume of players as a central server.  Just as long as the player can technically run around in the game and get some of the bare bones playability from the game.  How much extra work / budget do you estimate creating the EOL would take?  Assume 2 different scenarios:

3a. A simple arena shooter like Nosgoth or Lawbreakers

3b. A moderately sized MMO like Firefall or Wildstar

 

 

Hi Ross,

 

I've been a silent follower of yours since Civil Protection days. I only wish there were more people around with this common sense approach to the game industry.

 

At 1:09:30 in the video you mention that Microtransactions is what companies/publishers care for the most, and how preserving games should not affect that. I would disagree here, we are all humans, and our life time is limited, we only have so much time we can spend every day playing games.

People behind these games would want us to spend the maximum possible amount of that time playing their game, validating our purchases and getting attached to our spendings and our time spent with the game, thus increasing the possibility of us spending even more money on the same game over and over.

Preserving old games, creates competition for that time. Especially when the older games are sometimes superior to the new, because often depth is sacrificed for accessibility and to push better performance to the limit to afford better graphics, or, simply to push out the new game out the door sooner. Finally, the market is saturated with competition, often competing games only differ in setting/looks/naming conventions, but mechanically are identical. Demand for our time is at premium here, they really don't want us to be distracted playing these "old and irrelevant" games that don't generate them any profit.

 

I have worked as a QA tester and environement/level designer in the industry for a few years, and one thing was always the same, people with money behind it always want more money back the fastest way possible. Because this industry is relatively new along with software development they often go into legally gray areas to maximize their profits. This is why I wouldn't put it past them to possibly have this reasoning behind not caring for preservation of old games. But its probably just lack of time/care for this in majority of the cases.

 

PS: I wish I had legal know how or means to help you in this Ross! But you can have my power! I am with you morally on this!

 

Thank you!

On 4/26/2019 at 7:19 PM, Ross Scott said:

You call it a technicality, countries like Canada define them as dead-to-rights goods.  As for loopholes, sure, that's possible, but do companies really want to kick off players who lapse for a couple months and lower their playerbase for not paying 3 cents?  Having other players run around in the server and keep it populated is worth more to them than that, that's the reason the free to play model is so successful.  Again, this is CHEAP, cheaper than finding ways of evading it.  The only thing that's cheaper is doing nothing at all, I'm trying to see if the law can slam that door shut.

Well, it just “seems” like a technicality to me, but I’m not a a lawyer. Not to mention, given that there are still free online only games even in Canada, I would imagine their legal teams for these companies would fight you on them being dead to rights. Not that I agree with them, but laws are usually not black and white. 

 

As to the loopholes, I think my scenario might be more plausible than you think, but even if it isn’t, there are certainly other  ways they could think of to get around a legal ruling that required them to fork over their part of the game when they shut down servers if they are so reluctant to now for whatever reason, if it really would be as cheap as you posit to not do so.

 

One problem you are probably going to have is that there are so many political and legal issues people are worried about right now due to the rise of the far-right—just yesterday they got back into the Spanish parliament for the first time since Franco—that they would see this sort of thing as low priority. Like, the effects of the environmental deregulation by the current U.S. administration are already pretty scary at this precarious point, so it’s easy to completely focus on things like that if you’re trying to reign in corporations.

 

 

On 4/26/2019 at 2:58 AM, Im_CIA said:

I don't care, there hasnt been a good video game since 2004. Gaming deserves to die

^^^ this.

I don't care if tomorrow the whole gaming industry just dies down. I have SO MANY games in my backlog that are GUARANTEED to be great, that they will be more than enough for me to play for my whole remaining life.

 

Also, right now the overwhelming majority of games that are worth my time are made by Slavs (most notably Poles), and they tend to despise restrictive DRM (need I remind you that GOG was created by CDPR?). And on the contrary, games that are prone to be turned into GaaS/streaming are Pachinko machines that I wouldn't even download from Torrents if I could.

On 4/28/2019 at 6:20 PM, Ross Scott said:

I was only talking about the "minimum effort" options to give users a fighting CHANCE to create a server emulator.

Ok, it's going to be a long one. I will go slightly out of order with your questions, just to make sure it's coherent[-ish]

 

Before all, I should clear some possible misunderstanding here. You are talking about legal enforcement, not some "gentlemen agreement" between fans and developers. And that means couple things:

1. Any proposed "minimal effort" should be enough so fans can "repair" the game legally. You can't make/interpret a law in such meaning that to repair the game an owner needs to break another law. Reverse-engineering is illegal and it holds in courts. So all those ideas "just give us encryption keys and we'll do the rest" imply reverse-engineering of the client, which won't hold in a court. License you get might be perpetual, but it's limited. It does not allow you to reverse-engineer the game. And developers will fight to the death against that - a loophole that will allow players to legally reverse-engineer the game is practically open-sourcing the code. And there will be legal problems with third-party.
   
   You really don't want to go that direction - it's a whole new battle on top of the battle you already subscribed for. This battle is fought by open-source/information freedom activists for quite some time already.
2. And just a well, such a "minimal effort" should be enough so fans can "repair" the game exactly. Again, many of existing game emulators are "derived works" at best. And this is a copyright problem. And it will fail at court. Same thing - developers who ok with derived works are usually not the part of the problem at hand.
   
   This is another battle you don't to be a part of - a battle of modding community.

With that in mind, you need a bit more than the guy you talked about proposes. How much depends on a game. But in total, if taken all together, that would be:

1. Protocol specification and communication logic
2. All the server-side data and game logic (at least in forms of design)

 

Now in detail about both

 

Protocol specification and communication

 

Game client-server communication (again, depends on the game) may be broken into three layers

1. Low-level. This is usually some sort of "Robust UDP" implementation for PC/Console games or some sort of REST/REST-alike http-based protocol. This is just a definition of overall structures and logic how packets are being resent if lost, acked, etc.
   
   It usually also includes a definition on how things are being packed - server usually sends a single "packet" (as defined by the protocol - it might be many UDP packets) to the client containing all the data gathered through the server tick at the end of the tick. In some cases there could be some bandwidth limitation with protocol logic throwing out data that is considered less useful, there could be definition of data compression mechanics - like compressing position of a far-away entity from float3 (12 bytes) to single float (4 bytes) with loss of precision.
   
   But in either case there is nothing specific to the game - it's just a set of rules and algorithms that are usually data-driven in some sort. In the most simplistic variants it would be quite trivial, in more stream-alike protocols it would be quite complex.
   
   This is the easiest part - it's usually implemented via some sort of open-source third-party library, or not really anything "secret" or special. Aside of fear of embarrassment there is little preventing developers from even open-sourcing any in-house implementations. In fact most big publishers like EA already did that. Plus if it's some sort of crappy in-house implementation, it will most probably be of "simple" kind and even (which is quite probably) there is zero documentation, writing such documentation (if open-sourcing is unfeasible) won't take a lot of time.
    
2. Game core layer. This is definition of the messages - commands that client and server send to each other depicting certain events or actions required. Now how it's defined may vary wildly depending on low-level protocol, but usually it's some sort of ID for the message and message payload that is defined as set of fields. If low-level protocol does not define how fields are being packed, it might also include some sort of package mechanism that could be quite complex (something like google protobuf).
   
   Some commands could be reliable, others are not - say MoveTo could be unreliable, i.e. if the package holding it was lost, it won't be resent in the next package. The reliability mechanism is defined by low-level protocol, but which messages or even individual fields are reliable, which fields are compressed in which way is defined by a message specification.
   
   Examples of such commands would be: {CreateCharacter, characterId, templateId, position, whatever else args...}, {MoveTo, characterId, position, ...}.
   
   For older games that would be enough, because that's practically how server and client would talk to each other and notify about everything happening. For newer games there is a next layer. But for older games it might not be as easy as just defining a protocol or copying documentation (ha-ha-ha, documentation, ha)
   
   Most games I've seen and worked on would have their messages being constructed with code like that

   Quote

   ... write some fields ...
   if version check
      ... write more fields ...
   else
      ... write some fields and do some conversions ...
   
      if some other bullshit check
         ... go back in written data and patch it, because we can ...

   And I can 100% guarantee there is no documentation. Structure definitions/protobuf specifications is your best bet, but what inside those fields and what they are and where they are being written and how - that's something very non-trivial usually.
   
   Your source probably comes from some business software background if he thinks there will be documentation, because 10 people ask. In most cases there will be 1 person who even touches that code and when it breaks everyone are seeking this guy. When Bungie left MS, Halo was given to new studio named 539 or something like that. I have a friend working for them - they have no idea how network works. If they'll need to publish something like that (they aren't gaas though) - it would be close to "rewrite everything network from scratch". Yes, it is that bad.
   
   So this is going to be a problem, especially for games with lots of legacy. In some cases, like mentioned above Halo where they've basically lost all knowledge of that codebase - that may take months to re-construct the lost information AND it will take more months of actual support of fan team doing the emulator, because 146% you'll have mistakes while trying to reconstruct the protocol.
    

3. Communication logic. This is how the data in the messages are being interpreted by the client and compiled by the server.
   
   For modern games that have significant use of ECS paradigm, network communication is usually no event/command-based, but model-based. Basically in most cases server-to-client communication consists of one major message "Update" that sends a data diff essentially.
   
   And while it sounds even easier than above, it's not. Because in addition to the diff format itself, now you also need specification of the data that diff is being applied to - component specifications. And if they have good component design, it would be easy-ish - it's just structures. But I rarely seen good component design. In some of the worst cases that would be actual game-logic classes with all the quirks and non-network-related data.
   
   Extracting just network related information from that is possible - but with same caveat as in 2. - it will take additional active support time, because you'll surely make mistakes here. And no, no documentation either.
   
   In addition to newer games and ECS, even for older games there are various quirks like "character creation flow" (if you'll send inventory items before inventory itself, client will crash), deterministic algorithms (where data is assumed to be changed in exactly same way on both client and server, so you don't need to sync it as regularly - like time ticks, for instance) and other bits and bytes here.
   
   And no, really, there is no documentation for that either. And there will be shitload of places that no one even knows about.

So, to summarize - for a game with anywhere complex network communication, writing down docs that would be enough to build a working server emulator without resorting to client reverse-engineering may easily amount to rewriting the server from scratch writing documentation while doing so, because it might be the only way to ensure that documentation you'll publish will actually work. And as we talk about law enforcement - if you publish something that doesn't work, then you might be sued for that and get fined. Most game network programmers when asked to define how the network works exactly and without mistakes so someone without their knowledge and access to the codebase can replicate the server - they'll just leave via the window.

I worked at Wargaming on their games (World of *) and I can tell you - for them it will be nigh impossible. They won't even try

 

All the server-side data and game logic (at least in forms of design)

So to create an exact copy you need to know how it works. And MMOs, especially big open-world ones, tend to have quite a significant amount of logic and data stored on the server. Speaking of projects I know about - Wargming's Wo* games are quite opposite of the scheme you've shown in the video. They have most of the logic and data in a server. Not on the client.

And any games working on BigWorld, Spacial OS. Games like upcoming Star Citizen. Well, practically any big MMO, especially without instances or with many people in an instance will have that problem. Client would have 3d models, textures, materials and some movement logic, but that's it. Most of actual game will be on a server.

So not only to "repair" the game fan team will have to basically write the whole game from scratch, they will also need an exact specification on how it worked gameplay-wise, because what players see in client might be a result of few complex mechanics working together behind the scenes. And all the data as well - all the balancing, item definitions, treasure tables, spawning formulas and whatnot.

 

Again, for games like Destiny, which is basically p2p Halo with small authoritative server controlling spawns and item generation, it will be quite trivial. For them it will be easier to just publish the server executables though.

For games like Revelation (I think? It's using BigWorld iirc) or Wargaming's games - yeah. You can forget about it. They won't open the code - because that will allow anyone do the same game without any effort, nor they will be able to define how the game works, because that's literally "write documentation about the whole game". No one knows how it works. Even if there are some design documentation it usually not up-to-date or complete.

 

Realistic (IMO) scenario

We must consider any effort required from a developer to comply with the law against effort required to bypass the law. Bypassing the law could easily be done by making the license non-perpetual. Say 4 month-long with automatic renewal each time you login. So they will have to announce 4 month in advance before shutting down servers that licenses are no longer automatically renewed and that's it.

So for:

1. Games with significant authoritative server (i.e. where most of game logic is on the server) that do not have some sort of private server as part of the package (like Star Citizen intend) - it's a lost battle. Either will have to publish too much (open-source) and that will create competition for them, or they will have to basically work alongside with the fan team providing them with support, explaining what is what and how it's done. Refund is also out of the question - they just don't have so much money, they've eaten all the money they've got. Epic only able to do that, because Paragon was never popular.
   
   WoT goes into that category
2. Games with lots of legacy, put on support into other's hands like Halo (assuming they would go gaas) - huge effort needed, most probably no one will do that.
3. Games like Battlefield, Lawbreakers, etc - session-based shooters with what seems to be just a dedicated server running on a cloud, but most logic on a client - yes, it will be possible, but usually those games are killed if no one plays them (low community interest - no one will actually build the server) or are killed to avoid internal competition - here there will be either no one to ask from (company goes bankrupt) or they will avoid compliance because that's the whole point of killing the game - go buy new Battlefield!

So the only realistic variant is to have companies building new games from scratch or with active codebase building EOL into their games, usually in forms of patching out the server dependency (possible for games like Sim City, the RTS you've once shown on Game Dungeon, Starcraft 2, etc - where online-only is mostly just DRM feature). Maybe, if we are very lucky, "fake" MMOs like Destiny or Anthem. They probably even have private servers running inside the company already, so it won't be much of a problem for them to release it.

 

On 4/28/2019 at 6:20 PM, Ross Scott said:

The above is referring only to games that had no EOL plan to begin with.  But say you were creating a game from the design phase where you knew you wanted an EOL plan upon shutdown so users would have some method to run the game upon shutdown.  Assume it doesn't need to retain 100% functionality, so it may not contain things like auction houses, matchmaking, or being able to handle the same volume of players as a central server.  Just as long as the player can technically run around in the game and get some of the bare bones playability from the game.  How much extra work / budget do you estimate creating the EOL would take?  Assume 2 different scenarios:

3a. A simple arena shooter like Nosgoth or Lawbreakers

3b. A moderately sized MMO like Firefall or Wildstar

It's simple actually. Say in WoT case except for being written in Python (hence they can't just release the server executable - it will be disassembled in no time) and having overly complex engine for the their use-case that can't be made easier (BigWorld is meant for big MMOs) - nothing really prevents them from having a dedicated server running locally. Example of that would be console version of WoT which is written on different engine and developers made a Windows-running small version of the server (and their logic is written in C++), which can be made public no problem.

Another good example is Star Citizen - they plan on releasing single-player to be-played-offline version of the game and they regularly show developers running local servers on their machines. This may change before the release (Elite: Dangerous was promising the same, but then bailed), but it's clear that in most cases during development programmers create some sort of dedicated servers anyway. If forced by law, they can just make those servers more production quality, limit them to number of players so they won't compete with any possible new version and that's it.

So in case of MMO, I don't think it will add much of an effort if considered from the very beginning and designed around. Even dedicated server won't be done from the get-go, I think in 2-4 month time, unless there are significant design issues (which is what "consider from the very beginning" part should ideally prevent) - it will be possible to make "private" server package that will be runnable by the players.

 

This is for MMOs, for arena shooters it will easily be "free". For other games - again, if considered and checked from the beginning, any connection to outside services could be designed to be stabbable/compiled without, so it won't take significant time or effort as well.

So technologically, if we consider a brand new game on a brand new code - it will be half-year in worst case, "free" in best case. A month on average case I think. But again - shooters will be more ok with that, MMOs will be very reluctant, because it will allow others to create similar mmos.

Sorry not to respond to all your points, but this part below determines a lot of other things:

 

Quote

Any proposed "minimal effort" should be enough so fans can "repair" the game legally. You can't make/interpret a law in such meaning that to repair the game an owner needs to break another law. Reverse-engineering is illegal and it holds in courts. So all those ideas "just give us encryption keys and we'll do the rest" imply reverse-engineering of the client, which won't hold in a court.

Okay, see now, I'm confused.  Wasn't that the purpose of the DMCA exemption created last year?

 

https://www.eff.org/deeplinks/2018/11/expanded-dmca-exemption-video-game-preservation-grants-small-victory-amidst

 

My understanding was the exemption of 1201 of the DMCA says it IS legal to reverse engineer a server of an online game for purposes of restoring the functionality of the purchased product.  Care to clarify? This a really important point, and a lot of what you wrote afterwards hinges on how that is interpreted.

 

And to be clear, no, I'm not talking about FULL functionality.  Hell, someone can run World of Warcraft on a server emulator right now, but it's not going to be technically FULL functionality with every last similarity.  I would even argue that might be impossible for many MMOs.  If the law leaves absolutely no provision for releasing a modified copy that's similar to the original product, you're right, there's no shortcut at all, nor is that even a feasible path in many cases.  Is this really accurate though?  It seems like every time a company updates a game, they're changing the terms of what the game is due to changes.  I wouldn't think a scaled down emulated copy of the game would be any less an acceptable change.

 

Anyway, you're right in that this is essentially an unsolvable problem if FULL functionality is required to provide an enforceable solution for this.  Definitely clarify that DMCA exemption though, we need to have that understood before we (or at least I) can discuss this more objectively.

On 4/27/2019 at 12:58 PM, NightNord said:

And about that "minimal plan". I am a game engine programmer, so I know quite a bit about it. It's not that easy - there are third-party libs everyone are using that bound with license to the product. You can't just "release" the server in many cases - it's tied to client (code share) that uses those third-party libs, it's tied to platforms and SDKs that are usually under NDA.
...

2. Release server executable - that really depends on the game. For MMOs that's practically impossible, as MMO server is a conglomerate of executables and services with special configuration, usually heavily tied to the platform it runs on. So basically they will have to provide a hell lot of stuff that will only be able to be run by someone who have enough money to run it on commercial cloud platform. I.e. they will just give it to their competitors.

 

Another possibility I considered was not necessarily actually releasing the server binary, but just making it available for use. This theoretically might be easier for issues like 3rd-party libs.

 

Consider something like the AWS marketplace. Basically, you pay them money, and they start up a server running certain code in their datacenter. Or perhaps a whole network of servers, because more than once machine is required to do some job. As the customer, you don't (I think) have access to the executables or the underlying virtual machine the way you would if you just purchased virtual server time via EC2. You can probably configure it to some extent (like setting a password so only you can use it), but that's it.

 

For a gamer, that's exactly what you want. Ross isn't primarily concerned with the ability to mod The Secret World. He wants to be able to play it after EA shuts down, even if he has to pay for it. So if EA were compelled to make the machine images to available to AWS, Ross could pay AWS to run some Secret World servers and connect to them. For the single-player experience Ross was describing in his video, I suspect this could easily cost $0.10/hour or less. And that's on AWS, which is notoriously more expensive than its competitors. No doubt any real rule of this kind would require EA to provide these images to all the major cloud providers, and perhaps any cloud provider who had been certified as meeting some level of security for customer data (various standards exist).

 

Moving on, considering the big question that Ross is asking, it seems to me that a class action lawsuit on behalf of all of the gamers who've had their games shut down is totally feasible. It would be extremely difficult, but good class action lawyers thrive on that sort of difficulty. The main issue for them is usually: is there a huge pile of money in it for me (and also the class I'm suing on behalf of, but mainly me)? It sure seems like there is. This is where the sort of research that Ross & others did for the video is useful, and can be usefully expanded upon.

 

To start with, you have a list of ~100 games where the buyers presumably had a perpetual license, the game was disabled, and no compensation was provided. For each one of those games, can you determine:

 

0. How many copies were sold?

1. What channels were used to sell these games? For example, what percentage was sold on Steam, or the Xbox store, or UPlay?

2. Of the sales, what percentage are identifiable? For example, in the event that Valve's lawyer decides that EA owes Ross $30 for the Secret World, he can probably just refund him $30.

3. At what price were the copies sold? Were there different prices? Is there a mean price?

4. What microtransaction content was sold along with the game, and for how much?

5. Are the microtransaction sales identifiable?

 

And so on. If you know these numbers, you can start adding and multiplying until the quantifiable total-financial-harm-to-consumers becomes, when added to potential penalties for bad conduct (your "treble damages" and the like), irresistible to a sufficiently money-hungry class action lawyer. You also want to roll them up by potential targets. You can't sue "The Games Industry," but you can sue EA or Valve. So you get a figure of total games-related and microtransaction-related harm to consumers inflicted by just EA. Or the total amount from GAAS games sold on Steam. I'm guessing that you'd be suing EA (and the other publishers with large dollar values associated with them), rather than Steam, but who knows? Anyway, once you have all the numbers by game, it's easy enough to aggregate it different ways.

 

The downside of this is that a good lawyer understands that the legal system does not exist to right wrongs so much as make people pay for their wrongs. He will see the virtue of settling 3 years in for 20% of the total quantifiable harm rather than spending another 7 years to probably get 85% of it. Now being forced to pay 20% plus penalties might be enough for publishers of the world to say to themselves "Shit, let's not try that again," but it might not. At 5%, with minor penalties, it might start to look like the cost of doing business.

14 hours ago, Ross Scott said:

Okay, see now, I'm confused.  Wasn't that the purpose of the DMCA exemption created last year?

First of all, I am not a lawyer, I am a programmer. I can speak of what companies I worked for would or won't do. I am also not even US citizen.

 

Yet, from the very link you've posted it's imo clear as day that no, it is not.

 

Not only original proposal was not adapted in full, even it wasn't proposing outright reverse engineering for everyone.

 

Quote

The new exemption, as with the 2015 exemption, allows both individual users and archival institutions to modify games to remove the need for verification by an external server in order to make games playable again after a verification server has shut down. However, this part of the exemption is still limited to games that don’t depend on any game content stored on an external server.

I.e. it's extension of "cracks are allowed for preservation" case for online only drm. That case does not allow you to reverse the network protocol or the whole game - just enough to shut down the check.

 

Quote

In addition, the new exemption allows institutions like libraries, archives, and museums to restore a broader group of games, including games that depended on content (such as graphics) that was stored on a server—as long as the institution has a lawfully acquired copy of the server code.

(emphasis mine). Basically museums are allowed to possess game servers of they've been given to them. And only museums. And they can't allow access beyond physical bounds of the institution.

 

No reverse engineering.

 

More on that below

 

Quote

First, the Librarian of Congress did not grant users the right to circumvent TPMs in order to recreate a game’s original server software.  The Copyright Office believed this request potentially infringed on game developers’ exclusive right to prepare derivative works because restoring the disconnected servers reflected reconstruction rather than preservation.

Case in point. Recreation is explicitly not allowed as it would be derivative work and not original.

 

Quote

Second, the Copyright Office did not adopt MADE’s proposal to expand the class of users to affiliate archivists, a group of supervised individuals who would contribute to the preservation cause.  Incorporating this proposal into the final rule would have allowed individuals to circumvent video game TPMs in their own homes.  The Acting Register was concerned that institutions would be unable to adequately supervise volunteers working remotely. In the short run, archivists won’t be able to tap into this pool of volunteers who could aid in  game preservation.

Still limited to museums and their workers.

 

I think the museum/foundation approach may have some merit though - developers would be a lot more happy to transfer software as is in hands of some established institution, especially if they would be able to take it back if they'll decide to reestablish the game themselves, than just release it into the wild. But from what I read there museums won't be able to provide access to wide public. Nor that would be sustainable.

 

 

In non US law I know about - Russian law - reversing is forbidden. Period. No one cares of course  - it's Russia after all - you won't be punished for doing so, but as far as law concerned - you aren't allowed to do it.

 

So as I've said you better pick your battles - this is not the battle you want be part of, imo.

 

Also, you may want to contact people who work /were working on games you are interested in and ask how much time it will take to make a releasable package. Talk to engineers, not ceos - they may just give you at least a rough estimate, maybe under anonymity. Use journalists if your authority is not enough. Guys like that kotaku editor posting researches on game messups sounds like someone who may get on board and he is quite popular in the industry, a lot of people will talk to him.

 

Also maybe you want to contact people like that eff for legal advice. After all that's the battle they are fighting for quite a while.

24 minutes ago, NightNord said:

Yet, from the very link you've posted it's imo clear as day that no, it is not.

Thanks for clearing that up.  That law is a little more useless than I thought then.  I still need to verify about reverse-engineering being illegal though.  For example, emulators have been held up as legal in the USA if they don't use any code from the original, as was established in Sony v. Bleem.  If the developer is only providing documentation and turning off encryption, that may not constitute any actual code use, but this is a thornier issue that might need an expert to verify.

 

So technologically, if we consider a brand new game on a brand new code - it will be half-year in worst case, "free" in best case. A month on average case I think. But again - shooters will be more ok with that, MMOs will be very reluctant, because it will allow others to create similar mmos.

Just wanted to verify, are you saying releasing ONLY compiled code and not any source would create a risk to a company that may have other games sharing some of the same codebase?

6 hours ago, Ross Scott said:

For example, emulators have been held up as legal in the USA if they don't use any code from the original, as was established in Sony v. Bleem. 

In my understanding it's like cracks. Making them is illegal (unless you are a museum and yada yada), but once you have them - use of them for own use is not illegal. Though yeah, it needs some more knowledgeable input.

 

6 hours ago, Ross Scott said:

are you saying releasing ONLY compiled code and not any source would create a risk to a company that may have other games sharing some of the same codebase?

Most modern mmos are heavily data driven. Meaning you can take that server executable, put different data and boom - you got new mmo. And it will be hard to prove that they are using your server software, unless you start specifically putting some effort in ensuring that.

 

It's not security risk - at least I don't see any immediate problem in that, - but it's definitely commercial risk, regardless if that server code is shared or not.

On 4/26/2019 at 1:50 AM, Elfing said:

I was actually quite surprised Ross didn't mention that "games as a service" eliminates piracy at the "pros and cons" part. Now I am in no way arguing that setting up your game so that it is dependent on a central server is a sane and ethical way of preventing piracy -even though current regular DRM is extremely weak and gets cracked within days or even hours upon release-, however I think that was another counter argument that you had to answer towards the end. Games as a service is objectively better for the seller when it comes to maintaining profits by eliminating the chance for "cracks" of the game to be made but it is NOT fully defensable since you do breach the deal you made with the buyer by also preventing those who obtained the game legitimately to play it again.

I agree that piracy and cheats should be part of the discussion.
But that's about it
GaaS automatically elimitates neither piracy nor cheating.
Plus, those two arguments are irrelevant when talking about 'de-GaaSing' a game post-mortem.
And why would any accept of unethical or illegal behaviour just because it makes life easier for a company?

Cheats can only be challenged effectively by validating the player's actions. There were cheats in WoW.
Performing the simulation on a trusted platform, however, would help a lot.
But most simulations are to expensive to perform in one place. Scaling is also free when the player provides the computation power. And there's always be the issue of lag.
I'm interested to see how cheating develops with Stadia et al.

Ignoring whether GaaS is effective againt piracy, the right to backup copies and preservation generally trumps copyright protection - at least in Europe.

Let me know what you think.

Just on reverse engineering - a minor point to throw into the melting pot which I haven't seen/heard mentioned (at least directly) in the discussion so far is the concept of "clean room" reverse engineering. Wikipedia covers this under the term "clean room design", for whatever that's worth.

 

This is essentially where you observe the behaviour of a piece of software, then write new code from scratch to imitate that behaviour as closely as possible without duplicating any copyrighted aspects.

 

This approach has been legal under US law since at least the 80's, as far as I'm aware. Sony Computer Entertainment, Inc. v. Connectix Corporation (about 20 years ago now) even extended it to include disassembly of actual code in cases where behavioural observation is impossible any other way. Having said that the risks in doing actual disassembly are still much higher regardless.

 

I've done software reverse engineering professionally for 20 years or thereabouts, but I'm no lawyer... Obviously none of this precludes legal action being taken, but precedent definitely seems to indicate that (done correctly) reverse engineering itself is absolutely legal.

 

I'd argue that writing a server emulator should be almost inherently "clean" since it's vanishingly unlikely that you'd have access to the game server software in the first place. BUT then you run into the data problem as others have already mentioned. If the server provides non-trivial amounts of (copyright-protected) data to the client then providing a legal set of alternate data might be by far the larger undertaking - if it's even possible in any practical sense.

 

Quote

In my understanding it's like cracks. Making them is illegal (unless you are a museum and yada yada), but once you have them - use of them for own use is not illegal. Though yeah, it needs some more knowledgeable input.

I literally brought this question up in a discussion I did yesterday on the topic:

 

link

 

It's a long video though, bottom line is, reverse engineering appears to be completely legal if it doesn't use any copyrighted data without consent.  The company can easily give that consent for the "minimum effort" option upon releasing that data on its own terms without compromising its IP ownership in other areas.

 

So I would like to re-pose my earlier question:  As a developer, in your opinion, how long do you estimate it would take to perform the actions listed in one the "minimum effort" options?  NOT a full server replacement, NOT a functioning games, JUST what's listed on that slide (releasing packet documentation, disabling encryption, etc.) for an online game that was being shut down?  If it makes a difference, you can use the arena game v. MMORPG examples again.