I was going over ideas for a potential landmark exclusive for the Stadia platform, a game that not only excels on the conventional principles of game design but is also elevated by the unique features offered by a cloud gaming platform. It then occurred to me that while there are many quality of life conveniences that come with cloud gaming, such as click to play, there aren't many gimmicks that could spawn an exclusive that could ONLY work on a cloud gaming platform.
With that realization, I wanted to come to the community to float around some potential ideas of compelling game mechanics that could only work on Stadia. Thanks in advance to anyone who adds an idea!
The vast majority of innate cloud gaming features occur in the back-end, invisible to players, but one area (probably a decade from now) that could truly be unique to cloud is real-time game creation and play (with Artificial Neural Networks).
Machine learning has evolved to a certain point that you have Neural Networks that can compose music, paint, or even create games. Once the technology advances enough, exclusively in the cloud, you will have Neural Networks that create games that are played in real-time by gamers.
Basically, the game world and story are created on the fly, while gamers interact with them. So, in a sense, no one will know the storyline, including the game publishers because the Neural Networks decides the plot, builds the world a few nanoseconds before players access the content; which can change everytime, erasing repetition.
This is something that can only be achieved in cloud (for mass-multiplayer online games).
But I have heard Stadians fantasizing about this very thing. Particularly on reddit. Things like massively, MASSIVELY multiplayer online (MMMO) games with ludicrous numbers of simultaneous players in the same instance. Think medieval, colonial, or WWI era massive battles with hundreds of human players.
I remember some talk of Stadia instances borrowing adjacent resources to bolster performance... Idk, I'm not a close follower of the technical aspects of Stadia, but apparently it was a big deal that could allow for things that other gaming media can't achieve.
Also, Google has teased using it's AI experience to help make more personalized, believable NPCs with their own personalities and individual decision-making. Imagine a whole city filled with NPCs that seem like real people! I have now exhausted my knowledge on the subject, but I'm positive Stadia and cloud gaming in general willl be capable of some impressive new mechanics and features.
I don't think I have the creativity to come up with novel game ideas, but as a computer engineer with a few decades of experience, I can at least comment on a few of the technical capabilities that are available. The big one is proximity. Let's start with single-player to begin with. When a single-player game is running on a console or PC, it's like a small island. The game can only use what it has available locally. Trying to use cloud services is like relying on things that are on other islands that are fairly far away – we can't get a message to another island and back quickly enough to have it impact game state within a single frame. We might be able to rely on getting that response within a few frames, but that limits the kinds of things we could reasonably consider "off loading" to another "island". The result is a more limited scale and scope of the game. Not so much the rendering, but the game logic itself (e.g., how many enemies are on screen depends on how much CPU we can spend on their behavior code – things like path-finding, etc.).
When we start running the game code in the cloud, it's suddenly within a few milliseconds of other servers. The other "islands" are practically touching each other. Now, we can start offloading a lot more interesting parts of the game's code to those other islands (servers/services in the cloud) and be more confident we'll get responses back in time to apply them to the game state update we're currently working on. That does two good things: 1) It let's us expand the scale and scope of the game (more NPCs, for example); and 2) It leaves more CPU capacity available on the local game client node which can be used to feed the GPU, etc.
For example, let's say you can manage to support 100 NPCs in your game on a standalone system. But, by using a cloud server in close proximity, you can offload all NPC processing and support 1000 NPCs while reducing the game client CPU load to around what 10 NPCs would have cost.
This is basically a form of elasticity – we aren't trying to gang multiple game client nodes together, though. Just using cloud servers to offload parts of the game that otherwise would have to be done in the game client. Note that we don't need to dedicate a whole server to each game instance. The functions we're offloading may be "stateless" (meaning each request contains all the information needed to produce a response), which means we can have a pool of server instances providing those services to all of the currently running instances of that game – and we can dynamically scale the number of service instances based on the current load. This "statistical multiplexing" lets us more efficiently use the hardware that's available.
Now, let's start thinking about multiplayer games. Today, those games require a server. But, that server is relatively far away. So, it has to process all of the game client state changes (the inputs their players are making) and produce a new consistent set of shared state that gets pushed back out to all of the clients. The latency in doing that is what results in things like rubber-banding, or thinking you hit someone only to have the game say you were the one that got hit first. Multiplayer game servers have a "tick rate", which is sort of like a frame rate, but is typically lower. It's how many times per second they collect all of the inputs and generate a new consistent state. Some multiplayer games only run with a 20Hz tick rate, and this really shows in the resulting game play (more rubberbanding, more confusion).
But, when the game clients and the multiplayer game server are very close to each other, we can start running that game server with a higher tick rate – maybe even as high as the game's rendering frame rate. At that point, rubberbanding disappears. There's still a delay between pressing an input and seeing the result. But, that result is more likely to be consistent with what you thought.
We can also take advantage of all of the game clients being close to each other. They can share state directly with each other and use distributed consensus protocols to get consistent state changes without going through a multiplayer game server. That sort of thing isn't really an option when the game clients are far apart.
I know this has mostly boiled down to performance, but the thing is, the difference in proximity really is significant – an order of magnitude difference in latency really does make some new things possible.
Beyond proximity, we can move up a layer to think about what some of those off-loaded services might look like. Some of those services might be game-specific (e.g,. NPC behavior), but some could be reusable across multiple games (e.g., water physics). There are other Stadia features that fall into this bucket as well – the stadia.dev web site has a lot of great material on things like State Share, Crowd Choice, and others.
This is getting long, but hopefully it provokes some thinking.