Re: Cool Game Idea - Anyone want to help?
--=====================_19188413==_.ALT
It also reminds me of a TCL/Tk program that was designed as a multi-threaded
app. It launched independent interpreters running their own "search and destroy
programs." Although the programs were rather simple in terms of how thaey were
scripted but the scripts for programming the robots themselves were in TCL/Tk.
At 11:11 AM 02/28/2000 +0000, you wrote:
>This game idea reminds me of a game on the playstation(!) would you believe,
>where you programmed the AI behind robots then watched them fight. You had
>to lay commands in the neural path saying things like "if no enemy seen,
>turn right, move forward, move forward, re scan" and with the inclusion of
>randomness it got quite interesting. However, your idea sounds better,
>because once programmed you couldn't control the robots at all... you had to
>watch and if you hadn't done a good enough job (like they ran out of ammo
>and you forgot to tell them to run away) they were doomed!
>
>-----Original Message-----
>From: Euphoria Programming for MS-DOS
>[mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On Behalf Of JJProg at CYBERBURY.NET
>Sent: Sunday, February 27, 2000 7:41 PM
>To: EUPHORIA at LISTSERV.MUOHIO.EDU
>Subject: Re: Cool Game Idea - Anyone want to help?
>
>
>>This game reminds meo f several others, one on linux I could never get to
>>run, and a programme called Robocom. http://www.cyty.com/robocom
>>Robocom is similar, but you start off with one robot and their only
>>functions are to a)Duplicate b)Transfer code. The latter can be into a
>newly
>>created 'empty' robot, or into an enemy robot. If a robot has it's banks
>>overwritten with blank ones, it dies.
>>However, yours sounds much more interesting and versatile, especially if
>you
>>could provide a GUI style scripted interface for beginners, and raw coding
>>for more advanced players (of course, to start the GUI Scripting Interface
>>would have to wait).
>
>Yeah. Probably most players would not take program the individual
>modules or even robots. Instead, most players could probably just
>script macros to run when they press a key - to bring up reinforcements,
>for example. Hopefully, the game would become popular enough that people
>would contribute more advanced scripts and add-ons for the game,
>including GUI interfaces for scripting. I think making it run on Linux
>would help with this, as Starcraft hasn't been ported to Linux.
>
>>I definitely like the idea of each module having it's
>>own programming - a processor per piece, and it would create a real
>>challenge in getting the parts to communicate succesfully.
>
>Actually, that's the wonderful part of the design. It should not be that
>difficult. For example, suppose a very simple robot includes a battery
>and a laser. When the laser is told to fire, it sends a request to the
>base robot to get energy. The base robot searches through its modules to
>find an energy supplier. It finds the battery and gets the energy and
>returns an OK to the laser. If it can't find the necessicary energy, it
>returns an error. The battery could easily be replaced by a materials to
>energy converter, for example.
>
>>Another suggestion - the basic robot should have neither resource gathering
>>nor duplicating facilities, but these should be able to be added - that way
>>you cans speciallise 'mother' bots who do nothing but duplicate, and
>resource
>>bots that get the materials, and lookout bots, etc. etc.
>
>Well, I meant that there is a base robot which doesn't include any
>modules, but when the game starts, each player gets a few more complete
>robots so they can build more.
>
>>How much user interaction were you considering once the game is underway?
>
>There could be a wide range of user interaction from none (for computer
>players) to the user controlling everything. The point of the scripting
>would be to simplify tasks and add a new level of strategy to the game.
>For example:
>
>* explorer bots could search for materials and collect them, or search
>for the enemy and call up reinforcements if it finds them
>* trojan modules could be programmed to malfunction if attached to an
>enemy robot
>* in an allied game, each ally could set aside some robots for
>reinforcements. when one ally needs reinforcements, they could just
>press a shortcut key and have the reinforcements come to help
>* robots could just be smarter. For example, in Starcraft there are
>two options to stop units: stop and hold position. Hold position has the
>disadvantage that a longer-range unit could be attacking them and they
>couldn't fight back, but they would continue to hold position. Stop has
>the disadvantage that the units will follow any enemy units, even if
>they lead them into an obvious trap. By programming a new stop mode, the
>units could run away, attack, or hold position depending on which would
>be better.
>
>>While not much of a GUI or game programmer, I would love to help in any
>way.
>
>Thanks. I'll put a page on my website for this project, and post some
>initial ideas. Once we have a basic plan, we can start writing code.
>
>>Nick.
>
>Jeff Fielding
>JJProg at cyberbury.net
>http://JJProg.tripod.com/
Joel H. Crook
Manager, Information Services
Certified Novell Administrator
Microsoft Certified Professional, OS Specialist
Kellogg & Andelson Accountancy Corp.
14724 Ventura Blvd. 2nd Floor
Sherman Oaks, CA 91403
(818) 971-5100
--=====================_19188413==_.ALT
<html><div>It also reminds me of a TCL/Tk program that was designed as a
multi-threaded app. It launched independent interpreters running their
own "search and destroy programs." Although the programs were
rather simple in terms of how thaey were scripted but the scripts for
programming the robots themselves were in TCL/Tk. </div>
<br>
<div>At 11:11 AM 02/28/2000 +0000, you wrote:</div>
<div>>This game idea reminds me of a game on the playstation(!) would
you believe,</div>
<div>>where you programmed the AI behind robots then watched them
fight. You had</div>
<div>>to lay commands in the neural path saying things like "if
no enemy seen,</div>
<div>>turn right, move forward, move forward, re scan" and with
the inclusion of</div>
<div>>randomness it got quite interesting. However, your idea sounds
better,</div>
<div>>because once programmed you couldn't control the robots at
all... you had to</div>
<div>>watch and if you hadn't done a good enough job (like they ran
out of ammo</div>
<div>>and you forgot to tell them to run away) they were
doomed!</div>
<div>></div>
<div>>-----Original Message-----</div>
<div>>From: Euphoria Programming for MS-DOS</div>
<div>>[<a href="mailto:EUPHORIA at LISTSERV.MUOHIO.EDU%5DOn"
EUDORA=AUTOURL>mailto:EUPHORIA at LISTSERV.MUOHIO.EDU]On</a>
Behalf Of JJProg at CYBERBURY.NET</div>
<div>>Sent: Sunday, February 27, 2000 7:41 PM</div>
<div>>To: EUPHORIA at LISTSERV.MUOHIO.EDU</div>
<div>>Subject: Re: Cool Game Idea - Anyone want to help?</div>
<div>></div>
<div>></div>
<div>>>This game reminds meo f several others, one on linux I could never
get to</div>
<div>>>run, and a programme called Robocom. <a
href="http://www.cyty.com/robocom"
EUDORA=AUTOURL>http://www.cyty.com/robocom</a></div>
<div>>>Robocom is similar, but you start off with one robot and their
only</div>
<div>>>functions are to a)Duplicate b)Transfer code. The latter can be
into a</div>
<div>>newly</div>
<div>>>created 'empty' robot, or into an enemy robot. If a robot has it's
banks</div>
<div>>>overwritten with blank ones, it dies.</div>
<div>>>However, yours sounds much more interesting and versatile,
especially if</div>
<div>>you</div>
<div>>>could provide a GUI style scripted interface for beginners, and raw
coding</div>
<div>>>for more advanced players (of course, to start the GUI Scripting
Interface</div>
<div>>>would have to wait).</div>
<div>></div>
<div>>Yeah. Probably most players would not take program the individual</div>
<div>>modules or even robots. Instead, most players could probably just</div>
<div>>script macros to run when they press a key - to bring up
reinforcements,</div>
<div>>for example. Hopefully, the game would become popular enough that
people</div>
<div>>would contribute more advanced scripts and add-ons for the game,</div>
<div>>including GUI interfaces for scripting. I think making it run on
Linux</div>
<div>>would help with this, as Starcraft hasn't been ported to Linux.</div>
<div>></div>
<div>>>I definitely like the idea of each module having it's</div>
<div>>>own programming - a processor per piece, and it would create a
real</div>
<div>>>challenge in getting the parts to communicate succesfully.</div>
<div>></div>
<div>>Actually, that's the wonderful part of the design. It should not be
that</div>
<div>>difficult. For example, suppose a very simple robot includes a
battery</div>
<div>>and a laser. When the laser is told to fire, it sends a request to
the</div>
<div>>base robot to get energy. The base robot searches through its modules
to</div>
<div>>find an energy supplier. It finds the battery and gets the energy
and</div>
<div>>returns an OK to the laser. If it can't find the necessicary energy,
it</div>
<div>>returns an error. The battery could easily be replaced by a materials
to</div>
<div>>energy converter, for example.</div>
<div>></div>
<div>>>Another suggestion - the basic robot should have neither resource
gathering</div>
<div>>>nor duplicating facilities, but these should be able to be added -
that way</div>
<div>>>you cans speciallise 'mother' bots who do nothing but duplicate,
and</div>
<div>>resource</div>
<div>>>bots that get the materials, and lookout bots, etc. etc.</div>
<div>></div>
<div>>Well, I meant that there is a base robot which doesn't include
any</div>
<div>>modules, but when the game starts, each player gets a few more
complete</div>
<div>>robots so they can build more.</div>
<div>></div>
<div>>>How much user interaction were you considering once the game is
underway?</div>
<div>></div>
<div>>There could be a wide range of user interaction from none (for
computer</div>
<div>>players) to the user controlling everything. The point of the
scripting</div>
<div>>would be to simplify tasks and add a new level of strategy to the
game.</div>
<div>>For example:</div>
<div>></div>
<div>>* explorer bots could search for materials and collect them, or
search</div>
<div>>for the enemy and call up reinforcements if it finds them</div>
<div>>* trojan modules could be programmed to malfunction if attached to
an</div>
<div>>enemy robot</div>
<div>>* in an allied game, each ally could set aside some robots for</div>
<div>>reinforcements. when one ally needs reinforcements, they could
just</div>
<div>>press a shortcut key and have the reinforcements come to help</div>
<div>>* robots could just be smarter. For example, in Starcraft there
are</div>
<div>>two options to stop units: stop and hold position. Hold position has
the</div>
<div>>disadvantage that a longer-range unit could be attacking them and
they</div>
<div>>couldn't fight back, but they would continue to hold position. Stop
has</div>
<div>>the disadvantage that the units will follow any enemy units, even
if</div>
<div>>they lead them into an obvious trap. By programming a new stop mode,
the</div>
<div>>units could run away, attack, or hold position depending on which
would</div>
<div>>be better.</div>
<div>></div>
<div>>>While not much of a GUI or game programmer, I would love to help in
any</div>
<div>>way.</div>
<div>></div>
<div>>Thanks. I'll put a page on my website for this project, and post
some</div>
<div>>initial ideas. Once we have a basic plan, we can start writing
code.</div>
<div>></div>
<div>>>Nick.</div>
<div>></div>
<div>>Jeff Fielding</div>
<div>>JJProg at cyberbury.net</div>
<div>><a href="http://jjprog.tripod.com/"
EUDORA=AUTOURL>http://JJProg.tripod.com/</a></div>
<br>
Joel H. Crook<br>
<br>
Manager, Information Services<br>
<font size=1>Certified Novell Administrator<br>
Microsoft Certified Professional, OS Specialist<br>
<br>
</font><b>Kellogg & Andelson Accountancy Corp.<br>
</b><font size=1>14724 Ventura Blvd. 2nd Floor<br>
Sherman Oaks, CA 91403<br>
(818) 971-5100<br>
</font></html>
--=====================_19188413==_.ALT--
|
Not Categorized, Please Help
|
|
