Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Intelligent Clients (was Re: CF: hello)
> On Sep 8, 5:24pm, Christian Stieber wrote:
> > Subject: Re: Intelligent Clients (was Re: CF: hello)
> > Martin Wille (m@ifib.uni-karlsruhe.de) wrote:
> >
> > > > However --- how do you know that something is a bot in the first place?
> > > > An authorizing scheme would mean you'd have to authorize players too...
> > > >
> > > What i was thinking about was the following scenario:
> > >
> > > o bots connect on a different port, so that
> > > they a are distinguished from other (regular) players.
> >
> > Well, why authorize them, then? After all, one can always write a bot and
> > let it connect to the player port to get around the authorizing scheme.
>
> Yeah - I don't see the point to using a different port. The only reason I
> could see to it is if it that port supplied/took different information to make
> bots easier to deal with. But this then makes the server more complicated (ie,
> if a bot, send this data, otherwise we send this. IF a bot, we take these
> commands, otherwise these). I don't see any compelling reason to use a
> different port for bots.
>
I think using the existing protocol it would be difficult to
write a bot which is able to recognize what is around, since afaik only the
bitmaps/pixmaps are sent from the server to the client. A human player has no
problem to see that a group of bitmaps make a certain monster or a wall.
Writing navigation code for a bot using only pixmap information will be a pain.
I think giving a bot some help by telling it what is around would not be
unfair
to human players and would make bot programming easier (of cause extending the
protocol makes only sence if someone is really using it).
Well, if there is a different protocol for bots then they have to be
distinguished from human players, since humans could abuse the bot protocol to
get advantages affecting playbalance.
Also a player who wants to cheat could also launch a helping bot (or lots of
them). This is why I think bots would have to be authorized while players
don't.
>
> > It would really be fun to make a NPC client --- like a shop where
> > people can actually steal stuff, with the shopkeeper hunting them down
> > :-) Or maybe a better "pet", a NPC asking you to help him solve a problem,
> > and actually taing part in the adventure. But that would be quite
> > complicated to program...
>
> It would certainly depend on the bot, and what type of server administrative
> support you get.
>
> For example, I could see setting up a trader type person pretty easily.
> Arrange with the server admin that he starts with some decent money or
> equipment, probably want to make sure he can't be killed. A player can come to
> him, and he might be 'good' stuff, and sell good stuff. All this really
> entails is a player comes to him, and if the player wants to sell something, he
> drops the item. The bot trader could move to it, if he likes it, picks it up,
> and drops whatever amount of gold (or perhaps says something like 'I will give
> you 500 gp for this'. IF the player says yes, then he drops the gold and picks
> up the item.
>
> Likewise, if a player wants to buy something, the bot could understand some
> spoken stuff (ie, what do you have)', 'I'll buy +3 longsword', bot replies with
> the price. IF the player agrees and drops that amount of gold, bot moves to
> it, picks up the money, and drops the item.
>
> This would be an easier bot to do because knowledge of the map is really
> limited. It doesn't need to figure out exits or be able to navigate around -
> all it really needs to do is be able to look at the squares around it, and move
> to one accordingly. If set up in the town square, where nothing would block
> movement, this could be a bit easier.
I agree, a trader could be built quite easy and without extensions to the
existing client-server protocol.
A trader could also introduce haggling to the game. One can also think of
auctions managed by a NPC.
>
> If someone was serious interested in bot writing, I would suggest they take
> the current client and change it around a bit (current client is a good start
> in that it alreayd knows how to log in and understand commands sent to it).
> Instead of display could, it would have to set up some other method to keep
> track of what is around it.
>
> I think it would probalby make sense to start with these simpler bots, and
> then start worrying about bots taht can navigate maps and more independently
> kill stuff or search for items.
>
>
> --
>
> -- Mark Wedel
> mark@pyramid.com
Martin.
References: