Welcome, Guest. Please login or register.
April 25, 2024, 12:48:48 AM

Login with username, password and session length

Search:     Advanced search
we're back, baby
*
Home Help Search Login Register
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Offloading Stuff to the Client. 0 Members and 1 Guest are viewing this topic.
Pages: [1] Go Down Print
Author Topic: Offloading Stuff to the Client.  (Read 7228 times)
Sheepherder
Terracotta Army
Posts: 5192


on: February 09, 2010, 07:37:53 PM

Just a random neckbeardy concept: it's pretty well known that allowing the client to handle the game's stuff is a bad idea.  But what if the server offloaded very specific tasks to the clients which are hard to game to one's advantage?  Make it opt-in when not playing for a small in-game reward, with checks to ensure that the client is capable of reasonable ping and bandwidth.

Mostly I'm thinking of AI, and offloading the actual decision-making process of low risk/reward enemies to offline players with no presence on the server they are providing the service for.
Margalis
Terracotta Army
Posts: 12335


Reply #1 on: February 09, 2010, 10:05:26 PM

I imagine that most MMO clients have plenty of spare cycles lying around, sounds like a fine idea to me other than the bandwidth issues.

vampirehipi23: I would enjoy a book written by a monkey and turned into a movie rather than this.
Sheepherder
Terracotta Army
Posts: 5192


Reply #2 on: February 09, 2010, 11:03:18 PM

It would probably be as bandwidth intensive as having those computers that are offline doing AI routines behind a screensaver connected, so a developer would be looking at needing to accommodate twice the amount of their peak concurrent users.  But would have a free, nearly infinite pool of processing power to tap.

Hmm... lay some fiber, give players a discounted sub fee, power to annihilate name servers at will.  Seems like a good deal.
Jerrith
Developers
Posts: 145

Trion


WWW
Reply #3 on: February 10, 2010, 07:29:28 AM

Though I can't remember any specific titles off the top of my head, there's been some neat science fiction written about the problems this allows. 

A frequent theme is that you have multiple uninvolved clients each running their own copy of the simulation for an area, and either use the result that the majority calculate, or if there's disagreement, make an official server run the calculation...  The bad guys always end up corrupting (virus, etc) enough systems so that they can find areas where they control the majority or all the clients doing calculation, and do "evil" things... :)

It's an interesting idea, but I'm not sure if we'll ever get past the problems and get enough benefit from doing it.
Sheepherder
Terracotta Army
Posts: 5192


Reply #4 on: February 10, 2010, 02:50:40 PM

A frequent theme is that you have multiple uninvolved clients each running their own copy of the simulation for an area, and either use the result that the majority calculate, or if there's disagreement, make an official server run the calculation...  The bad guys always end up corrupting (virus, etc) enough systems so that they can find areas where they control the majority or all the clients doing calculation, and do "evil" things...

You randomly assign the clients work with minimal details.  At 13:00 he has all the Defias Knuckledusters on Doomhammer server, at 13:10 he's in command of all the penguins in Northrend on Burning Legion, at 13:20 it's the guards in Stormwind on Arthas, at 13:30 he's got the mobs in the non-instanced portions of Blackrock Mountain on Nazgrel.  All he runs is the AI, the server controls the random seed and results of input.

Or maybe you have one mob across 30 different servers, calculating whether each individual instance of that mob's AI is on / off / due for reset, then hammering out the details for the "on" ones and sending the results to a gateway server that then propagates the changes to each individual game server.
« Last Edit: February 10, 2010, 02:56:28 PM by Sheepherder »
Ingmar
Terracotta Army
Posts: 19280

Auto Assault Affectionado


Reply #5 on: February 10, 2010, 05:55:08 PM

The utility of this would seem to be to be pretty dependent on what costs more, server CPU cycles, or bandwidth. If I had to hazard a guess I would think bandwidth is a bigger cost these days.

The Transcendent One: AH... THE ROGUE CONSTRUCT.
Nordom: Sense of closure: imminent.
Tarami
Terracotta Army
Posts: 1980


Reply #6 on: February 11, 2010, 02:16:10 AM

Bandwidth and massive security issues aside, it's completely technically infeasible. Distributed computing (render farms, SETI@Home, cryptoanalysis et c.) doesn't work that way, it works by pushing a small or atleast very static set of data to a slave that can then largely work offline. Once the slave has done all the requested calculations the computed data is sent back and another packet of data is received. The fact that not every single sub-result needs to be communicated is what makes it work.

Game servers work the absolute opposite way. Data is deemed ancient if it's as much as a second old. A routine that calls a moderately complex sub-routine expects a result within a millisecond or so, not the 200 ms it takes for a trivial computation to travel back and forth to a node. It would absolutely slaughter the performance. As the slave, you can't "feed" the server computations because you have no backlog to compute and all the data that just arrived will be old by the time you've computed and returned it.

That's not to mention the agonizing concurrency control that would be needed when you have hundreds of nodes tightly coupled to your game logic.

Sorry, it's not a viable option for another 20 or 30 years atleast.

- I'm giving you this one for free.
- Nothing's free in the waterworld.
Sheepherder
Terracotta Army
Posts: 5192


Reply #7 on: February 11, 2010, 03:25:44 AM

Game servers work the absolute opposite way.

And games are played almost exactly as I describe.  If you can accept that a person can cope with the latency involved in pvp, it's not a far stretch to suggest that decision making work could be offloaded to professionally made bots integrated into the way the servers work on client computers.  The largest problem with latency would be NPC movement, which gets fuckstupid when the difference between the server and client(s) is over half a second.  Which is why you'd limit the scope of time sensitive shit your clients have to do, and abstract it where shit gets needlessly bandwidth or latency intensive (Client says "move away from opponent", server decides vector and distance).

Or you could just hand off all the touchy-feely "the world is alive because the mobs randomly choose a direction to move five steps in in every three seconds while out of combat" stuff to the players.
Tarami
Terracotta Army
Posts: 1980


Reply #8 on: February 11, 2010, 05:00:30 AM

So you're going to have thousands of bots that need to pass through all the same server logic as untrusted normal clients, since they, in effect, are untrusted game clients? That sounds like putting more load on the server rather than moving load to the clients.

- I'm giving you this one for free.
- Nothing's free in the waterworld.
Sheepherder
Terracotta Army
Posts: 5192


Reply #9 on: February 11, 2010, 01:05:19 PM

A single computer can manage a shitton of bots, and outputs far less than the PC in a game, because you don't need to tell the server every movement the bot makes, just the start and end destination.  Or, alternatively, that the NPC needs to move in a way fitting a general pattern.  You're still offloading the decision making parts of the AI, the server still needs to handle pathing.
Venkman
Terracotta Army
Posts: 11536


Reply #10 on: February 13, 2010, 05:14:58 AM

Mostly I'm thinking of AI, and offloading the actual decision-making process of low risk/reward enemies to offline players with no presence on the server they are providing the service for.

Apologies if I'm reading this wrong, but it seems like you're looking for ways for a players to partake in an MMO when they're not connected to the 'net.

I prefer the current methods being explored: offline games that can impact your in-world presence. This creates a completely separate experience appropriate to whatever use cases exists in beyond sitting at your connected PC/laptop. It merely needs to send one or two values back to your user account. It means the experience is more appropriate for the use case. Like that new-ish Wizard 101 iPhone minigame which can give you currency in the world, or the forever-rumored Eve mobile app.

The alternative is something like Anrufen. Sure you can get a miniaturized MMO client for the iPhone, but only the most helplessly addicted would play it.  Oh ho ho ho. Reallllly?

I do like the idea of solving AI problems as a separate topic though.
Tarami
Terracotta Army
Posts: 1980


Reply #11 on: February 13, 2010, 07:09:26 PM

Game AI is much more restricted by design than by CPU share, thus it's a development time issue rather than a performance issue. Most interesting sorts of behaviour are some combination of manual scripting and custom animation, not so much the perceived intelligence itself. Things like mobs ganging up, vaulting over obstacles or detecting grenades are relatively easy on the CPU, it's the scripting of the presentation and the animation that's the big job to be done. Behaviour triggers in even advanced games (that aren't straight-up simulations) are fundamentally simple, because the game logic knows all the truths and has perfect information. A normal desktop computer could probably run several hundred Unreal Tournament 3 bots if it didn't have to anything else. With mods, the Sims 3 -does- maintain close to a hundred quite sophisticated bots while also running the game itself. There simply isn't a big gain to be had from distributing something like AI, because the CPU isn't the limiting factor and I'm pretty sure that's not the case for MMOs either. Hardware is cheap.

I think that current (...for the last 10 years) MMO mob AI is intentional for the most part. A truth with game AI is that the really clever monsters rarely make for the most interesting encounters. There's both an element of the player feeling cheated when the computer is too good - since the player is after all supposed to win, and a lack of flavour. Simplistic enemies are easy to niche and create rich flavour in (it pounces and gives you a big bleed DoT, because it's a panther,) while very complicated enemies are harder to design distinctly - in the real world, there's no real difference between fighting a lion and a bear, or a man from India and a man from Portugal. Even then, those are the easy ones - how the hell does a behemoth from Hell with six arms and three tails and five dozen of teeth fight if it's going to be intelligent about it?

In short, there's a design (and definition) challenge there that just isn't worth it. Humans have a tendency to consider human-like intelligence the only kind of intelligence, so when we try to give imaginary creatures intelligence, they become humans with pointy ears. Or green skin. Or big beards. Or, the more intelligent we try to make a fictional race, the more they become us and the more we relate to them; which is almost exclusively a bad thing when you're trying to create scary monsters. If we say "ok, this giant spider likes dark pits and eating people," we can conveniently side-step that issue. Making the spider take cover to shoot webs at you from a distance doesn't really make it more spidery or monstrous, it really just makes it more human.
« Last Edit: February 13, 2010, 07:43:16 PM by Tarami »

- I'm giving you this one for free.
- Nothing's free in the waterworld.
Sheepherder
Terracotta Army
Posts: 5192


Reply #12 on: February 13, 2010, 08:13:11 PM

Apologies if I'm reading this wrong, but it seems like you're looking for ways for a players to partake in an MMO when they're not connected to the 'net.

You're reading it wrong.  The idea is for the server to share it's workload with the clients in a way that the clients cannot abuse.

A normal desktop computer could probably run several hundred Unreal Tournament 3 bots if it didn't have to anything else. With mods, the Sims 3 -does- maintain close to a hundred quite sophisticated bots while also running the game itself. There simply isn't a big gain to be had from distributing something like AI, because the CPU isn't the limiting factor and I'm pretty sure that's not the case for MMOs either. Hardware is cheap.

It's about 500 bots locally with UT99 on a P4 HT.  Made for an interesting game of CTF-Face.  You might be right, now that I think about it.
Lantyssa
Terracotta Army
Posts: 20848


Reply #13 on: February 15, 2010, 11:38:31 AM

The only place I see this being of use would be something with procedurally generated worlds.  Something like what Star Trek Online was supposed to have for its exploration system.  Send a system a set of data, let it hash out the finer details and that the seed generates a world within its parameters, then it sends back the okay.  It doesn't matter if a machine or data set is never heard from again.

Having clients handle AI routines or other things happening in a game right now is bound to end in disaster for any of a variety of reasons.

Hahahaha!  I'm really good at this!
Famine
Developers
Posts: 61

Funcom


WWW
Reply #14 on: February 15, 2010, 12:18:55 PM

Apologies if I'm reading this wrong, but it seems like you're looking for ways for a players to partake in an MMO when they're not connected to the 'net.

You're reading it wrong.  The idea is for the server to share it's workload with the clients in a way that the clients cannot abuse.

Define what's being abused first. That may help the question or solve the problem.
« Last Edit: February 15, 2010, 12:24:20 PM by Famine »

Glen 'Famine' Swan
Senior Assistant Community Manager
Funcom Inc.
Sheepherder
Terracotta Army
Posts: 5192


Reply #15 on: February 15, 2010, 03:11:37 PM

For the AI example: if you gave the player the ability to select the server they are lending processor cycles to and the ability to choose which mobs they lend them to you would see hordes of bears, boars, zombies, and dragons pillaging their way across capital cities in no time.
Famine
Developers
Posts: 61

Funcom


WWW
Reply #16 on: February 15, 2010, 05:31:37 PM

For the AI example: if you gave the player the ability to select the server they are lending processor cycles to and the ability to choose which mobs they lend them to you would see hordes of bears, boars, zombies, and dragons pillaging their way across capital cities in no time.

I might be confused here but I'm trying to grasp the concept in the above replies. If you're referring to a system where it's client-to-client rather than gameserver-to-client then you would need to remove any ability for the player to choose. If most of the work is handled client-to-client then there would need to be a process on the gameserver that queues and assigns the processor cycles and where mobs are distributed. Unless for some reason that takes away the intention of the design.

In order to prevent abuse you must add control. In this example, you control where the resources are distributed. Assuming  you're talking about clients providing their own resources to support the game (processing power and bandwith).

Glen 'Famine' Swan
Senior Assistant Community Manager
Funcom Inc.
Sheepherder
Terracotta Army
Posts: 5192


Reply #17 on: February 16, 2010, 12:02:19 AM

Which is what I meant by "share it's workload in a way that the client cannot abuse."
Famine
Developers
Posts: 61

Funcom


WWW
Reply #18 on: February 16, 2010, 12:17:45 AM

Which is what I meant by "share it's workload in a way that the client cannot abuse."

It's out the norm. Traditionally, you offload work from the server that's still communicating with the server. Good example, would be like math or bandwith.

« Last Edit: February 16, 2010, 12:29:45 AM by Famine »

Glen 'Famine' Swan
Senior Assistant Community Manager
Funcom Inc.
Pages: [1] Go Up Print 
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Offloading Stuff to the Client.  
Jump to:  

Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC