🚀 go-pugleaf

In article <854166...@hkchan.pc.my>, hkc...@hkchan.pc.my wrote:
>
>In article <32e67266...@news.ntr.net> ske...@totaltel.com writes:
>
> > On Wed, 22 Jan 97 18:21:21 GMT, Pas...@Globalserve.net (FraggyBalls)
> > wrote:
> > 
> > >The stats that need to be saved on the server are much less than 1K.  Other
> 
> > >stuff can be saved on the PC.
> > >
> > >Stuff that needs to be saved on server is:
> > >
> > >Base Attibutes .  7 bytes
> > >Equipment and Inventory.
> > [SNIP!]
> > 
> > This is a really terrific idea.  The only feature that's lost, then,
> > is the ability to use battle.net players while not on battle.net.
>
>This idea is terrible. Everyone will suffer as long as there is one
>person decide to trash the server by creating several characters on
>the server.
>

Note in the above proposal, spell levels also need to be stored on the server.

Although bugs are likely, and server crashes also likely, there's no 
reason to think that creating multiple empty inventory (7 bytes + id, 
password) accounts are going to overwhelm a master server.


MultiPlayer is useless because cheating is simple, and multiPlayer save files 
get corrupted when you defrag your hd.

having a server based system, gives all the benefits of quakeworld.  Unique 
names.  Worldwide stats (ear count tracking).

in Blizzard's position on cheating article, they mention that it would still 
be possible to cheat with server based stats.

Ways I've thought of so far:

Sending the UDP for "I just visited an Enchanted shrine, or picked up super 
weapon".


Architecture that to me seems hard to crack: 

Whenever an attribute or spell level changes, a checksum type key that is 
computed based on current stat level is sent for verification.  If an 
incorrect checksum is submitted, the server can request the client to resend 
using a different checksum formula.
        
        To crack this, you need to find the level up and attribute up routine, 
and execute it, while the program is running (without crashing).  An 
extremmely challenging proposition.  Also, to cheat, the user would need a 
debbugger instead of a memory poking program


If all there was a limit on the number of Powerful items that can possibly 
exist in the Universe of games, then  an Inventory/Parcel tracking system can 
be put in place to insure an item is not carried by more than 1 person.

For example, there could be a limit of 5000 King's swords of Haste in the 
universe.  Each has a specific inventory id.  When you carry it, it is 
registered to you, when you drop it, it is registered  to available.  
Characters can only carry special items that they were previously carrying or 
were available.

I'm not suggesting that every special item in the game be cataloged by the 
inventory system, just that the super powerful ones be.  Lesser special items 
that exist in the game can also be given encyption key codes that ensures, one 
cannot have an item that does not exist in the game, and one cannot have a 
copy of an item that does exist in someone else's inventory (ie the shop).  
Items do not exist until someone visists the level they are on.

This way ppl cannot poke values into their inventory memory variables.  All 
items have a state of ownership:  Shop, Player, Monster, Ground.  Also, 
Inventory addition should be tightly integrated with the picking up 
functions, such that the game crashes when executing outside of picking up and 
buying actions.

Basically, for superpowerful items, the items' state of ownership should be 
stored on the server, as it seems possible (though not trivial, as it is 
now) to hack the ownership status of items if they're stored inside the pc 
game.

Spell levels can be treated the same as attributes.

Additional checks are possbile.  Spell Levels can only be increased if there 
exists items that can increase it, and these items are used.  Using items, 
involves first carrying/owning them, or being on the same level as shrines.

Checks can be made after each level is exited for unwarranted xp and spell 
advancement.

All of these above suggestions do not pose excessive server/bandwidth 
resources.

I invite hackers to challenge the security claims I've made, and to improve 
them if you can.