Re[2]: [Nel] RE: Nel miscellanea

[Dim Segebart]

IMHO,  cheating  is bad only then ones try to increase his stat's points: 
Health,
Power, Mana, etc. But this kind of cheating prevents by server-side decision 
making (I
hope)
Other  kind  of  tools like radars, wire framing, auto targeting, etc., etc. are
not  cheats  but features ;) Just provide enough of such tools as default set 
to the end user
and    he   will   be   happy   to  use  it, moreover telling the user which
helper   means  are  activated  by  his opponent will help him to adjust
his  behavior according to the current situation. The main point is - if two
opponents  has wire framing, auto targeting and healing switched on it's no more
cheating, but additional weapon which everyone can use without additional cost.
If you will provide API for creating bots, what will be the reason to create 
hunting
bot if your opponent will launch hunting-bots bot or just defence bot?
So,  prevent your game from Games Stat cheating, open it for hacking and 
extending and
game   balance   will  be  achieved by users themselves. It's just like  USA vs
Soviets  -  you  and  your  counterpart has enough of atom bombs to destroy each
other  but you are in the state of balance so you play everyday Game according 
to the
"normal" rules.


Thursday, January 03, 2002, 8:09:32 PM, you wrote:

TH> "Nel List" <address@hidden> wrote:
>> > >because this isn't a perfect world, what keeps a user from just
>> > recompiling
>> > >the code with for instance wireframing enabled to give himself an
>> > >unfair advantage over the other users. This is a real possibility
>> > >with GPL. My
>> 
>> If the data goes over the wire to the user's machine, it is visible
>> to an enterprising user (witness ShowEQ). Re-compiling the client
>> doesn't change this in any real way (as long as all decisions are
>> made on the server).

TH>   Some possable results of allowing the client to be released to the
TH> general public have been disccused before.  I believe someone here
TH> published a link to a website discussing this very issue, focusing on
TH> two key problems with open source clients.  And this is no matter what
TH> format you end up following, includeing the complete "Only send client
TH> location of things local to the player, and only the bare bones data as
TH> well (Location, moveing, apperence, and health in % for the case of a
TH> RPG style online game)

TH>   1) Radars: These are specialy dangerous for Player vs Player combat.
TH> since it can allow someone to know instantly 1) Who are your enemies
TH> around you, 2) How much health they have, and depending on how clever
TH> the hacker is 3) how strong the player is vs you.  The last bit of data
TH> comes from the fact that some online games offer you some clue as the
TH> level of the people around you, as well as monsters for your
TH> information.  This kind of information can lead to unfair advantages. 
TH> In Dark Age of Camelot, which is said to have taken the minimalist
TH> apporach to sending data to players, even they have recently had
TH> concernes about such "radar" 3rd party applications.   ShowEQ is all
TH> about this, and exploits the fact that the game sends all monsters spawn
TH> information to the client constantly.  Although not Player spawn
TH> information unless local to the player.

TH>  2) Auto-aimers: This doesn't sound like it could be a problem on say
TH> MMORPG's but it can be if it means players can auto-target the weakest
TH> player in a Player vs Player conflict and constantly attack them.
TH> Auto-targeting is still a problem here, no matter where it came from.

TH>    2a) Derived from this we get, Auto-Clickers or in other words,
TH> applications that automaticly perform repedative actions or  a macro of
TH> complex actins.  Perhaps, again in a RPG setting,  a healer could then
TH> put all his healing action onto a long string of intelligent macros that
TH> will watch some players health levels, and then auto-send a heal command
TH> at say 40% loss.  That's a combination of auto-targeting and
TH> auto-commands.  Reverse this for Combat mages,  Auto-targeting for spell
TH> attacks.. You get the idea.

TH>   2b) The final and worse form of this, Bots.  Auto-hunters that can run
TH> around, and hunt for players hour after hour without the player actually
TH> being there or only occasionaly monitoring.  Quite unfair from my stand
TH> point.

TH>   Now that's enough examples at the moment.  As you can say, and as the
TH> article said before (I wish I had the link) This problem is quite
TH> serious even if the source is not released.  Packet sniffing and reverse
TH> engineering will always result in the hackers discovering everything
TH> they need to know to make there tools work.

TH>   Possable solutions. These just came to me.  These will only work in a
TH> closed source solution.

TH>   1) Re-arrange the order of data in the packets every build or whenever
TH> you can.  This forces the hackers to re-sniff and learn all your packets
TH> again each time you come out with a new version of the client.

TH>   2) Update/change your encription: Again, they will discover what you
TH> are using, and just changeing one of the keys won't be enough.  I don't
TH> know a whole lot about encription but hopefully there's something that
TH> can be done to perlong the chance that the hackers will be successfull. 
TH> Please note that even this method is not invulnerable to de-compileing
TH> the application.

TH>   3) Change the ports you use for communication: Again a delaying tactic
TH> at best.  It's not a great solution but, it's better then nothing.   You
TH> can get really fancy with this, and make the port the client connects to
TH> the server for game data the result of a function based off of data sent
TH> from the 'connection' port and user data.  That idea may only work with
TH> tcp/ip though.

TH>   There are a thousand tactics you can use.  But all of them are simply
TH> slowing measure to prevent hacking.  Hackers are only successful nine
TH> times out of ten because the client never changes for long periods of
TH> time, and when it does change, changes only very minorly so.  This
TH> makeing it easy for a  hacker with enough time on his hands, (Or on the
TH> hands of a small team of them) to decode the packets, and then engineer
TH> a soultion to decode the packets for there own use.  ShowEQ is the best
TH> result of such a product (http://www.sourceforge.com/projects/seq)  The
TH> most trouble they ever have, is when the packets change size slightly,
TH> or the encription changes.   Other then that, it knows everything about
TH> anything that goes on.

TH>   Tony

>> 
>> 
>> > We have unified the export / bulid process for all NeL 3d media.
>> 
>> What I've found lacking the most when looking through the NeL sources
>> is simply documentation on how to build and use it; especially under
>> Windows. There's all kinds of miscellaneous DSW files scattered over
>> the source tree, and nowhere does it say which ones should be built,
>> in what order, or what the other requisite tools/libraries needed are.
>> 
>> 
>> > Yes, the scripts was missing ! Sorry for this. It should be ok now.
>> 
>> Does this mean you don't have an automated daily build? Having a
>> machine that checks out a clean source into an empty directory, and
>> turns the crank to build the real product, is a must-have for any
>> engineering organization. You may find that if your build is too
>> complicated to get that going, effort you put into fixing that may
>> improve the issue above, too.
>> 
>> 
>> 
>> _______________________________________________
>> Nel mailing list
>> address@hidden
>> http://www.nevrax.org/mailman/listinfo.cgi/nel
TH> _______________________________________________
TH> Nel mailing list
TH> address@hidden
TH> http://www.nevrax.org/mailman/listinfo.cgi/nel



-- 
Dim Segebart                         mailto:address@hidden