1. Pixel Bots
>
>C & K L wrote ...
>
>Please check out http://www.ticnet.com/thelesters/eubots/start.htm
>
>and provide your comments. We're trying to get a standard developed here
>so that the games may begin... :)
I've also had a bit of a busy weekend trying out various ideas for Pixel
Bots. I've concentrated on the interface API between the Bots and the
Arena program rather than any maze. I have a complete working program
and documentation on http://www.psynet.net/hippy/pixelbot.htm ( or, if
you have problems using that,
http://www.hippy.freeserve.co.uk/pixelbot.htm ).
I've tried to make the design generic so we can have maze solving,
battles, co-operation between Bots and, well any other type of 'game'
wanted using the same arena program and API. I've tried to keep to a
simple system of observation, movement and fighting. If it gets too
complex we'll end up doing something approaching
Sim-Dungeons-And-Dragons.
From all the posts it looks like there is a lot of interest in these
Bot's, the trouble now is, how do we come up with a definitive spec for
the concept, the Arena program and the API ?
Both C&KL EUbots and my Pixel Bots are a divergence on the original
idea; obviously we don't want to go off on separate tangents ( but then
again why not ? ) and start a flame war over who has the best wrapper
program or API.
It would be possible to design a standard API then we could have people
writing Bots and others writing Arena programs - keeping everyone happy.
Any thoughts ? I don't want to be stepping on people's toes and
upsetting anyone by going off in a totally different direction to the
rest of the Bot Club.
PS : To send plain-text, to Shroud or to Bind ?
One of the best things about this Bot idea is that beginners to Euphoria
can join in; it could well be the first program they write ( even if
they do crib from other Bot code ). I think that we should make the Bot
code ( and Arena program ) totally open to scrutiny so it's useful as
demonstration code and examples of Euphoria coding.
This means that we must use plain-text files ( arena.ex, pixelbot.e )
and of course, add lots of useful comments for newbies to see what we
are actually doing.
Even if a Bot does [ subversively rather than advertised ] try and take
a peek inside the Arena code to 'cheat'; someone will notice this and
I'm sure that someone will cry foul on the mailing list. Naming And
Shaming should be the ideal deterrant.
2. Re: Pixel Bots
Your API is indeed interesting.
Its a bit more on track than my code. But like I said, I gave my code to
show/prove/test some of the techniques.
However, no offense, lets reconsider, what cards we have, what we want and
how to keep a thing like this maintainable.
First of all, lets keep it much more generic. There are four parts to a bot
(that I could come up with)
-sensing: collision detection, 'hearing' a shot. etc.
-orientation: position, strenght, energy. etc.
-actions: move forward, turn left, shoot. etc.
-communications between bots: sending messages etc.
All of these sides could be 'generalized'.
This means, that have routines to add/register new communication methods,
orientation properties, sensing functions, action procedures. Not to use in
a bot. But to use in a much more specific BOTMatch..
There should also be a sort of generalized 'area' routines. This means that
the actual routines gets the area in a 2D image sequence, it calls every
method/event etc. when applyable.
Within such a framework, you could have a more specific maze solver library,
area battle etc. written...
Like, you said, I dont want to step on anybody's toes, but lets work on the
modelling a little bit more.
Ralf
