Thread: RE: [GD-Design] Off-line vs. on-line play and cheating
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-design
|
From: Brian H. <bri...@py...> - 2002-07-22 18:15:10
|
> Wow. Attempting to make an always on line game cheat free is > already VERY hard. I am aware =) > However you are attempting to solve a much harder problem: > off line games. Correct. But, I think the approach is to solve by design, not by technology (which is why I posted to design instead of say algorithms), since trying to solve it technologically is a losing proposition since the client is inherently untrustworthy. > Oh, and I would change my binaries as frequently as > economically feasible. And make sure that each biniary is > different in some fundemental way (eg: automate the process > that changes the structures). This is why I don't want to solve it with technology: the time committed to trying to fix it is usually disproportionately longer than the benefits gained. Hackers have more time than game developers, so it's a losing battle when you try to fight them on their turf. Brian |
|
From: Brian H. <bri...@py...> - 2002-07-22 18:21:30
|
> one issue of balance here has to be: can you play the game > offline and _never_ come online? In theory, yes. Take a game like Elite, StarFlight, etc. then imagine a menu item that says "Go on-line". That's basically what I'd like to achieve -- make the game fundamentally interesting and playable for single person, but allow for a social aspect as well with on-line play. I think this is what Blizzard accomplished with Diablo, although I'm aiming for something with a larger scale in terms of universe. > irritating to have everything you'd ever discovered > permanently listed as 'claim pending'. I'm procedurally generating a BIG universe -- millions of star systems and millions of planets. The odds of two players claiming the same piece of rock are very, very slim. > possible solution, but maybe too intensive: part of the claim > verifying process downloads a replay of the claim, and plays > it back to make sure it's not a complete fib. I'm not too worried about this part, it's actually things like "Hi, I just logged in, check out my Armada Buster Level 999 Battleship that I acquired after hacking my data files" that have me more concerned. But in the end, it's all the same thing -- hack the data files locally, connect on-line, and then throw the universe out of whack. So as stated in another post, I don't think solving this with technology is going to be tenable in the long run, I think something with the design should arbitrate this. Brian |
|
From: Jamie F. <ja...@qu...> - 2002-07-23 10:13:37
|
<snip> I'm procedurally generating a BIG universe -- millions of star systems and millions of planets. The odds of two players claiming the same piece of rock are very, very slim. </snip> this, of course, assumes players are equally likely to hit any piece of rock. if you have a Frontier style system where everybody starts at one of a few locations, the places close to the starting points are likely to be claimed many times. <snip> I'm not too worried about this part, it's actually things like "Hi, I just logged in, check out my Armada Buster Level 999 Battleship that I acquired after hacking my data files" </snip> no accompanying replay, no ship :) still hacking a data file, but trivially generated by the game, and very hard to hack, i believe. i agree with Jeff, that we really need to know more about what the players do offline and online to be able to attempt to solve the problem in design. jamie -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Brian Hook Sent: 22 July 2002 19:21 To: gam...@li... Subject: RE: [GD-Design] Off-line vs. on-line play and cheating > one issue of balance here has to be: can you play the game > offline and _never_ come online? In theory, yes. Take a game like Elite, StarFlight, etc. then imagine a menu item that says "Go on-line". That's basically what I'd like to achieve -- make the game fundamentally interesting and playable for single person, but allow for a social aspect as well with on-line play. I think this is what Blizzard accomplished with Diablo, although I'm aiming for something with a larger scale in terms of universe. > irritating to have everything you'd ever discovered > permanently listed as 'claim pending'. I'm procedurally generating a BIG universe -- millions of star systems and millions of planets. The odds of two players claiming the same piece of rock are very, very slim. > possible solution, but maybe too intensive: part of the claim > verifying process downloads a replay of the claim, and plays > it back to make sure it's not a complete fib. I'm not too worried about this part, it's actually things like "Hi, I just logged in, check out my Armada Buster Level 999 Battleship that I acquired after hacking my data files" that have me more concerned. But in the end, it's all the same thing -- hack the data files locally, connect on-line, and then throw the universe out of whack. So as stated in another post, I don't think solving this with technology is going to be tenable in the long run, I think something with the design should arbitrate this. Brian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=556 |
|
From: Daniel C. <dan...@an...> - 2002-07-22 19:03:02
|
Three techniques the come to mind: - Balanced Characters - Social validation - Statistical validation *Balanced Characters* Balanced characters are the easiest conceptually. You set up the game = so that every character has tradeoffs. There is no linear character = growth, where a final character is more powerful than an advanced = character. Instead Character A has bigger weapons, but is slower and is = taxed heavily by the local police force. Character B has smaller = weapons, but they aren't taxed so they can make more money as traders.=20 In the single player or multi-player game, you quest in order to adapt = your character to your particular style of play. If you cheat, you are = just changing your character around. You aren't gaining an advantage = over anyone.=20 *Social Validation* Social validation is a process of storing data on your character = throughout all the other existing player machines, not based off the = local machine. Imagine you play with 5 other people and you win. The 5 = other machines record encrypted versions of your win. A central server = can generate an individual's 'reputation' score based off who is playing = at any one time. This system is difficult to hack assuming a large = number of players. You can use player ranking as part of this. "I = enjoyed playing with him. I didn't enjoy playing with him" This can be = reported as well. =20 What happens to a new player who logs on with an uber character and no = history? They are marked as newbies. (There is nothing more damning to = a cheater than to be marked as a newbie. :-) The only way they can make = a name for themselves is by playing and having their reputation = propagate throughout the network.=20 *Statistical Validation* This is the most theoretical, but I'd love to see it done. Imagine a = peer-to-peer network and a statically derived model of player = advancement. The player ends up generating a character history based = off playing the game. This history is then submitted to a central = server that does a statistical comparison to other histories. Anomalies = tend to pop out. When combined with a social validation system, it = becomes far more difficult for a user to 'suddenly' get an uber = character. Unfortunately, this particular system does not work with the = offline-online system you described.=20 -Danc.=20 -----Original Message----- From: Alain Hamel [mailto:ah...@re...] Sent: Monday, July 22, 2002 12:34 PM To: Brian Hook; gam...@li... Subject: Re: [GD-Design] Off-line vs. on-line play and cheating > But, I think the approach is to solve by design, not by technology > (which is why I posted to design instead of say algorithms), since > trying to solve it technologically is a losing proposition since the > client is inherently untrustworthy. Attempting to solve via design. I have to say that I don't see how it = can be done. I mean if you want some items in your game to have value (eg: the = ub3r starship) then I don't see how it won't be trivialized by hacks. But = that doesn't mean it can't be done, I'm about as far from omniscient as one = can get. > Hackers have more time than game developers, so it's a > losing battle when you try to fight them on their turf. I don't know if they will always win. For example, I think, but I'm not sure, that intertrust has not been hacked yet. Of course that could have something to do with no one adopting their technology... And you have a somewhat easier problem. If, for example, you required that the client = log in (for a new binary) every month or so you could make things much = harder on the hackers. ----- Original Message ----- From: "Brian Hook" <bri...@py...> To: <gam...@li...> Sent: Monday, July 22, 2002 11:15 AM Subject: RE: [GD-Design] Off-line vs. on-line play and cheating > > Wow. Attempting to make an always on line game cheat free is > > already VERY hard. > > I am aware =3D) > > > However you are attempting to solve a much harder problem: > > off line games. > > Correct. > > But, I think the approach is to solve by design, not by technology > (which is why I posted to design instead of say algorithms), since > trying to solve it technologically is a losing proposition since the > client is inherently untrustworthy. > > > Oh, and I would change my binaries as frequently as > > economically feasible. And make sure that each biniary is > > different in some fundemental way (eg: automate the process > > that changes the structures). > > This is why I don't want to solve it with technology: the time = committed > to trying to fix it is usually disproportionately longer than the > benefits gained. Hackers have more time than game developers, so it's = a > losing battle when you try to fight them on their turf. > > Brian > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-design mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-design > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D556 > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gamedevlists-design mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-design Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D556 |
|
From: Freeman, J. <jfr...@so...> - 2002-07-22 19:13:00
|
(Apologies if this is a double post.) From: Brian Hook > We're working on a game design that, at its core, is just a vast space > exploration RPG, but which happens to have the ability to connect with > other players at a central server so they can interact, trade, adventure > together, etc. I think I'd start by trying to divide the game into online and offline functions - and seperate those into "multiplayer activities" versus "single player activities". Standard approach has been sort of "Different world/characters, same gamesystem", but you could do "Same world/characters, different gamesystem". Socializing with other players is multiplayer only, by definition. So that's easy. You don't include it in the list of single-player activities at all (exception being maybe to compose email or the like, which will be delivered the next time you connect), and don't worry about its "impact" on the single-player game, since it doesn't have one. Trade is trickier, in that you're presumably trading things that will be useful in the offline game - so then, hrm... don't do that. You can limit what sorts of things can be traded to what sorts of things are useful to the multiplayer (only) aspect of the game. And "adventure" is the trickiest yet, unless there are two distinct types of adventuring to be done. If you do that, then it makes it easier to divide what sorts of tools are beneficial to which type of adventuring, and there's your guideline for trade as well. > The only problems will be when two players compete for the same resource, > and one "claims" the resource off-line. > This is easy enough to solve by simply stating that the first player > on-line gets to take their claim, e.g. you discover and name a mineral > rich planet, now you want to log-in to "lock in" your claim. Other > issues like this can also be solved the same way. Yah, or there again, can be different types of resources depending on whether you're online or off'. In the case of single-player type resources (which help you to craft single-player type tools which help you to complete single-player type adventures), say, fictionally justify them as resources the player doesn't so much discover as 'invent'. I go to planet-X and discover a resource which I call resource-X and I turn it into the X-gun which I use to fight crime, when I'm playing offline. I can't trade any of this stuff with anyone else. 'Doesn't impact other people's play experience even if I do cheat, because we'll never Fight Crime together, and my ability to Fight Crime doesn't help me to do whatever it is we do together in the online environment. > I'm not sure how Battle.net handles it, but I presume that on-line > players can't bring off-line characters with them. Yep, that's it. Separate characters playing the same game. So, a different approach is to have a single character playing two different games, in the same world-space. Coming up with adventure types that feel different (e.g. "The offline game is a game of exploration. The online game is a game of killing.") would be important though, I think. Over simplification: I play the Offline and Online games with the same avatar, in the "same space". * Offline: * I explore. * I acquire exploration-related skills. * I acquire exploration-related tools. * I acquire resources which enable me to craft exploration-related tools. * I cheat. :P * Online: * I kill stuff. * I acquire killing-related skills. * I acquire killing-related tools. * I acquire resources which enable mem to craft killing-related to tools. * I socialize. * I trade killing-related resources and tools with other players. Additionally, the offline and online games can be webbed-together in other ways (other than the shared-character aspect, that is): Such as * Offline: * Exploration unlocks new areas of the Online Space (in which I kill things). * Online: * Killing things unlocks new areas of Offline Space (for me to explore). So with that, you'd play and explore online for a bit, 'til there was no where else to go. Then hop online and kills some things to unlock "Sector 7". Then go back offline and explore sector 7. Or vice versa. Or divide it so that whatever people spend the most time doing is what's done offline, just for the sake of bandwidth. |
|
From: Brian H. <bri...@py...> - 2002-07-23 17:43:11
|
> I think I'd start by trying to divide the game into online > and offline functions - and seperate those into "multiplayer > activities" versus "single player activities". Standard > approach has been sort of "Different world/characters, same > gamesystem", but you could do "Same world/characters, > different gamesystem". Interesting idea. Skies of Arcadia had a kind of gimmick like this in that you had the regular game, then mini-games that could be played independently on the VMU (for DreamCast) which weren't vital to the main game but were minorly helpful at times. > Socializing with other players is multiplayer only, by > definition. So that's easy. You don't include it in the > list of single-player activities at all (exception being > maybe to compose email or the like, which will be delivered > the next time you connect), and don't worry about its > "impact" on the single-player game, since it doesn't have one. But there IS an impact -- you can't ask for help or advice or just see if a friend is around. For example, go to www.gamehouse.com and play Text Twist as a registered user. There's no way anyone else can play your game with you, but people sit in the chat rooms and post their puzzles and others chip in and try to help them find the 6 and 7 letter words. The social aspect can't be chalked up as just a "game element", because it's really an aspect of the milieu and overall flavor of the game, even if it's not fundamentally core to the game mechanics. Using EQ as an example, many people log in even if they don't plan on adventuring. Similarly speaking, it's like going to a coffee shop to read a book vs. reading it at home. Sometimes you just prefer a certain ambience for an ostensibly solitary activity. Using the MUD paradigm, some aspects can obviously be considered solitary, e.g. crafting. You could do that all off-line, but if given the choice, wouldn't you prefer to do it on-line so that you can see what's going on outside of your solitary activity. In my mind, off-line playing is only there if you don't have a choice in the matter, e.g. tying up a phone line or you're on a plane. It provides a non-optimal playing experience, but one that is still better than being denied play time at all. Using the MUD example again, if you couldn't log-in but all you wanted to do was craft, there's no reason (other than hacking/cheating concerns) that you shouldn't be able to do that on a limited local server. Separating the game play styles based on off-line/on-line is a valid direction, but it has the side effect of, well, separating the play styles =) I'd rather not make a distinction to the player other than what is available to them and personal choice. > Yah, or there again, can be different types of resources > depending on whether you're online or off'. In the case of > single-player type resources (which help you to craft > single-player type tools which help you to complete > single-player type adventures), say, fictionally justify them > as resources the player doesn't so much discover as 'invent'. The other problem with the above is that you effectively write two games. We went through this on Quake 2, where there was a huge amount of time devoted to writing the single-player portion, and then a huge amount of time writing the multiplayer portion, so it ended up being two games. In fact, you'd often meet players who only played one or the other part. > Yep, that's it. Separate characters playing the same game. Blech. I've always disliked this, especially with advancement oriented games. PSO did this as well. You lose net access for a week, and you now have a Level 28 Super Warrior, and then you login and find that you're stuck with your Level 4 Wimpy Dude. It feels like completely wasted effort. > So, a different approach is to have a single character > playing two different games, in the same world-space. Right, which goes back to the whole, "Ugh, we're writing two different games" thing =) > So with that, you'd play and explore online for a bit, 'til > there was no where else to go. Then hop online and kills > some things to unlock "Sector 7". Then go back offline and > explore sector 7. That makes sense, and is a different approach than just separating it into two games. Having them interleaved, but with the option of always playing on-line, makes sense. It makes more sense if you have a linear story like Diablo's. Brian |
|
From: Alain H. <ah...@re...> - 2002-07-22 18:33:33
|
> But, I think the approach is to solve by design, not by technology > (which is why I posted to design instead of say algorithms), since > trying to solve it technologically is a losing proposition since the > client is inherently untrustworthy. Attempting to solve via design. I have to say that I don't see how it can be done. I mean if you want some items in your game to have value (eg: the ub3r starship) then I don't see how it won't be trivialized by hacks. But that doesn't mean it can't be done, I'm about as far from omniscient as one can get. > Hackers have more time than game developers, so it's a > losing battle when you try to fight them on their turf. I don't know if they will always win. For example, I think, but I'm not sure, that intertrust has not been hacked yet. Of course that could have something to do with no one adopting their technology... And you have a somewhat easier problem. If, for example, you required that the client log in (for a new binary) every month or so you could make things much harder on the hackers. ----- Original Message ----- From: "Brian Hook" <bri...@py...> To: <gam...@li...> Sent: Monday, July 22, 2002 11:15 AM Subject: RE: [GD-Design] Off-line vs. on-line play and cheating > > Wow. Attempting to make an always on line game cheat free is > > already VERY hard. > > I am aware =) > > > However you are attempting to solve a much harder problem: > > off line games. > > Correct. > > But, I think the approach is to solve by design, not by technology > (which is why I posted to design instead of say algorithms), since > trying to solve it technologically is a losing proposition since the > client is inherently untrustworthy. > > > Oh, and I would change my binaries as frequently as > > economically feasible. And make sure that each biniary is > > different in some fundemental way (eg: automate the process > > that changes the structures). > > This is why I don't want to solve it with technology: the time committed > to trying to fix it is usually disproportionately longer than the > benefits gained. Hackers have more time than game developers, so it's a > losing battle when you try to fight them on their turf. > > Brian > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-design mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-design > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=556 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X