From ???@??? Wed Nov 16 00:15:11 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id AAA03143 for ; Wed, 16 Nov 1994 00:08:45 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7cbi-000fIrC; Tue, 15 Nov 94 21:08 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA02625; Tue, 15 Nov 1994 21:07:12 -0800 From: Charles Ofria Message-Id: <9411160507.AA02625@altair.krl.caltech.edu> Subject: Mailing list... To: alife-game@alnilam.krl.caltech.edu Date: Tue, 15 Nov 1994 21:07:11 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 796 Greetings, I just updated the mailing list - here is what it currently looks like: a.fraser@eee.salford.ac.uk adamsch1@student.msu.edu belial@gorgo.manawatu.planet.co.nz brett@iit.com chance@wetware.sps.mot.com charles@krl.caltech.edu christian@darkin.demon.co.uk cs323093@mailbox.uq.oz.au ematteso@icogsci1.ucsd.edu g-j@chameleon.alt.za gtaylor@violin.aix.calpoly.edu hand@cs.utk.edu jmlait@undergrad.math.uwaterloo.ca kim@cs.city.ac.uk Martijn.Faassen@phil.ruu.nl mbbad@seqnet.dl.ac.uk relsner@k12.colostate.edu st944m5h@post.drexel.edu uwingcat@mcl.mcl.ucsb.edu wsteele@efn.org Please someone souble check it and report back to me any mistakes I've made. Also, I'm in the process of acquiring and ftp site to base ourselves out of. I should have more on that tomorrow. --- Charles From ???@??? Wed Nov 16 02:18:35 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA13950 for ; Wed, 16 Nov 1994 01:47:17 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA95661; Tue, 15 Nov 1994 22:49:41 -0800 Date: Tue, 15 Nov 1994 22:49:40 -0800 (PST) From: Gregory Glen Taylor Sender: Gregory Glen Taylor Reply-To: Gregory Glen Taylor Subject: The "IMPORTANT STUFF" initial draft, for directors only. To: charles@krl.caltech.edu, g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII To : Charles, Gert-Jan, Jeff Lait, Martijn, Mike Mitchenen, Adrian Tymes =-=-=-=-=-=-=-=-=-=-= - Important Stuff - =-=-=-=-=-=-=-=-=-=-= /* This section will be removed. To the 'DIRECTORS' of the AI.GA project: Please read, add, delete and revise this file, then mail your revisions to me, I'll patch them all together and post it to the group. NOTE - this is not yet for the group, it must be refined by us first! */ Hello all. This is the 'project so far' file, which attempts to standardize some of the basic pieces of the project. The other directors and I have sorted through all of the ideas and methods presented thus far and have merged and such to form what we believe to be the 'ideal' game outline. Please do not be offended too much if one of your ideas was ommited or rejected, we either overlooked it or found it inferior to another method in some way. With a group of 20+ people now, not all of us can be wholely satisfied with it, we've attempted to patch together a fun, exciting, changing, game that should please most of us. The stuff listed below is mostly-fixed; that is, it will likely stick unless a brilliant idea is presented. If you have any brilliant ideas, make sure you get them soon and tell the group about them. The directors are beginning to lay out the program outline and header file, thus things are going to be solidifying real soon... The specifics of the implementation will be decided within the sub-groups. Below is a discription of the project outline... ---------------- - Universe.h - ---------------- The header file for the game outlines the parameters and names of all of the global functions. This way all of the functions in the various sections of code will be able to call functions in other sections of code (ie the Universe can call Front-End routines). The code can then be worked on independently, and the other groups will know how to access and what data to send to the external routines. This will keep compatibility high and re-coding to a minimum. The key to a sucessful Universe.h is a -complete- function list which has all or nearly all of the gloabal functions and variables that will need to be accessed by the other groups; because adding forgotten functions will mean work for -all- of the groups...which could possibly be avoided. --------------- - Front End - --------------- This section of the code is the only machine/compiler specific code. It may be coded in assembly, or whatever the FE team deems they'd like to do. The only restrictions is that it must be accessable by the C header file (universe.h), so the functions must be written so that they will be able to be accessed through those defines... It will include : Graphics: Setting the mode, sprite manipulation, fonts, and a 'movie' displayer that will display our standard intro and plot sequences (we'll develop a standard .mov file which will have various pictures and sounds/music in a sequence). Sound: Playing midi files or mods (not sure yet) also sound efx, will have to work closely with the Art/Sound team in order to implement their ideas effectively. Control: Keyboard caching (grabbing multiple chars if multiple are pressed, ie turn+acc+fire), joystick control, mouse control etc. Others?: This will handle other stuff that I've forgotten for now....hmmm The sound is still in question for which file formats it will use, most likely midi's or mods to increase portability. If evolving music is developed by the Art/Sound team, then that will have to be implemented. The most likely 'general' function for the FE for sound will be a 'int Music(blah, blah:junk);' type thing, then the FE group would either call a routine written by the Art/Sound group or perhaps send a midi file etc... As for the '.mov' file. I envision this as a file with large x large x 24bit original pictures for the intro sequence, with embedded music and sfx. This way when a FE group is fine-tuning for their format, they can run a converter program on the .mov file to reduce the pictures down to the desired size for that FE. The pictures in the intro will likely be Ray-traced, 'cause drawing frame after frame of large x large x 24bit pictures by hand is a weighty task. The actual .mov files will be produced by the Art/Sound group, and the FE need only convert and display them. The current FE groups are : PC/MAC/Amiga Other Front Ends may be formed if someone will direct a group to code them. The FE-PC will need to be developed first, this is because the PC is the most common computer within the development team, thus it would be most useful to test other group's routines. Other groups can either wait for the FE-PC to be reasonably finished and convert that code -or- code simultainiously. ---------------- - Universe.c - ---------------- This portion of the game will be written in standard ANSI C. It contains the main() procedure and is basically the 'controller' of the game. It will call FE routines for it's user input and output, use AI/GA and Art/Sound routines for generating the aliens and their behaviour. Aside from it's control-center aspect, it also handles things like the physical aspects of the universe, acceleration, turning, etc. This text specifies the Universe part of the game. Anything that is not basic will have the word OPTION: in front of it. [Martijn's Note: this file is mostly about my ideas on it; of course you may disagree, please say so if you do. This text isn't (yet) final about anything] The Universe ------------ - is relatively independent of the actual front-end. - is flat; 2d. - has wrap around borders, and has thus no borders, but it's finite too. The Objects in the Universe --------------------------- - each have a speed (may be zero). - are inertial, so do not slow down without any force on it. (no friction) - each have a _objective direction_. The direction angle is 0-255. 0 is N, 128 is S, etc. This is the _objective direction_. - each have a _facing direction_, which is the direction the object is facing, usually the same as the _objective direction_. 0-255 deg as well. - can turn smoothly. 16 different rotations is probably enough. [though we might just send the _facing direction_ to the FE and let them decide how many rotations to implement..:)] Kinds of objects ---------------- The ships --------- - can turn left and right. - can add thrust. - have two types of energy: 'Armour' : How many 'hit points' the ship has left, before it dies. 'Usable' : Energy it has to fire, mate, move, etc. - decrease armour energy (and perhaps Usable as well) if hit by a weapon. - can gain energy by eating energy pods (perhaps the remains of killed enemies, eggs, and misc other sources). OPTION: this might be 'plant growth', or asteroids, or pods that come free when a ship is destroyed. This remains to be decided. - can fire their weapons (up to two weapons?). [Martijn's _relative direction_ stuff omitted. If my method doesn't work, put it back in...] - _relative directions_ of other objs can be obtained by comparing the _objective directions_ of both objs. This way it can be determined if another obj is heading towards an obj... - can view the distance another obj is at. - can view the speed (relative speed?) another obj is flying with. The player ship --------------- - is controlled by the player, by a 'thrust' key, left and right rotation keys, a fire key. OPTION: a breed key, an eat key, a 'weapon option' key, etc. The aliens ships ---------------- - are controlled by alien pilots. A pilot is a piece of behaviour code. - have essentially the same control methods as the player, using 'virtual' keys. (they call the same functions as the ones that get called when a key is pressed by the human) Projectiles (missiles, bullets) ------------------------------- - can collide with ships. The ships loose a certain amount of energy when hit, dependent on the type of projectile. - may have very primitive behaviour code in them. Projectiles may evolve! OPTION: energy donation projectiles might also exist. Vampiristic projectiles can also exist. (they suck energy out of the ship that is hit, and transfer it to the ship that fired the projectile) - are always destroyed upon collision. (they explode) - are fired by ships. (of course :) Other objects ------------- Asteroids, obstacles, energy pods, plants, motherships, etc. ------------ - AIGA.C -- ------------ // This section is in a huge disarray, it will get organized later, once // more definite alien-type datastructure and global vars are developed. // for now it is the director's forum on AI/GA implementation. This piece of code must be written in either C or C++, preferrably C, we'll let the AI/GA group decide (C++ is fairly non-standard right now, but ANSI C is a portable standard. I think there's a C++ standard too...hmmm). Anyway there will be a few types of routines that the AI/GA group will have to develop: A routine to decide an alien's bahaviour (this will be the -main- procedure that they'll write), which will obviously call probably several smaller, local procedures to decide upon a behaviour. The output will be in the same format as the human player's controls (ie left, right, thrust, begin mating, fire weapon A, fire weapon B etc). This procedure will have access to all of the global variables... - Aliens may access the map within a certain range, just like the human player's viewwindow. - Aliens may access a set of alien-only variables. These would be things like global distress calls, species group action calls, boss presence and other vars which an alien might respond to. This will be the alien equivilent to the player's radar. - Alien may access other aliens stats etc. (for mating purposes...) What follows is -my- method for alien behaviour control. Keep in mind that I am not a member of the AI/GA group, and this is not at all fixed; just my ideas reiterated... Definitions: TRAITS : Both Aliens and the player have these as part of their makeup, these are the physical attributes...acc, max speed, max armour, max usuble, shot type A, shot type B, etc. etc. etc. GENES : Only aliens have these. These are the code which decides the behaviour of the aliens. ACTIONS : Only aliens. The actual action-sequence that will achive a certain aim. PRIORITY: Genes are given a priority (0-255). When selecting an alien action, you would first check the area of 'sight' of the alien, for any 'new' action going on. If anything has changed since the current bahaviour has been selected (ie something like a new alien in sight or a new shot has been fired etc) then it would re-evaluate it's behaviour. It would also check the global vars for stuff that has been enterred. If nothing disturbs it's current behaviour, it will continue it until it finishes at which time it will choose a new bahaviour. When re-evaluating it's behaviour it would proceed through it's list of genes in a fashion semi-ordered by the priorities of the genes (some randomness is added to keep things interresting). I would seperate the genes into different categories of genes...(not a complete list) Group behaviour genes, Temper genes, and of course run-time genes. The run-time genes would be a set of evolved genes that would not be pre- coded. These would call actions just like normal genes, but the conditions for them would be variable, changing... There might also be room for evolving actions... A gene would be a series of 'if' statements which would test the conditions of that gene. If one is true then it will set the alien's behaviour to the action called for... An example for one of the group behaviour genes might be... x is the species identifier (siblings who share same make-up) (GENE). y is the individual alien TRAIT data identifier. z is the number of a nearby alien... if (alien[y].armour<10) { LocalDistress[x].call=1; // Sends out sibling distress call LocalDistress[x].x=alien[y].x; // Sets coords of distress point LocalDistress[x].y=alien[y].y; Flee3(); } if ((GlobalDistress.call==1) || (LocalDistress[x].call==1) Assist2(); if (NonRelativeNear==1) Attack2(alien[z]); ... This particular gene example will readily assist distressed aliens, but will also readily attack any nearby non-sibling if there is no distress call... It will also flee if it has less than 10 points of damage remaining... Each statement will call an action (Attack2(), Assist()2 etc) which will become the alien's behaviour until a new action is triggered... Having the computer generate funky non-preprogrammed genes would be a nice touch, since I think we'd all rather not have to hard-code -all- of those genes and actions. The functions would have other params and such, these are just demos to get the idea across. I would lay out an initial alien's stats as such... TRAITS = Each psuedo-randomly generated. The bounds of the random generation would be relative to the current player's 'price'. They also would be limited by previously generated TRAITS, (ie a speedy ship would rarely also have massive armour) we could weight the random generations to keep the aliens focused a bit. These would be generated for a whole batch of alien siblings. GENES = Each psuedo-randomly generated. There should be a good mix of pre defined genes and randomly generated ones (half and half?). The pre-defined ones are essential, I believe, to allow us to get some behaviours that are unlikely to evolve otherwise. The randomly generated ones are also essential to offer new, strange behaviours and let us be lazy :). These would each be given a priority rating. These would be generated for a whole batch of alien siblings. There will be two major alien data-types. One will cover the defines of an alien species (several alien siblings will have the same make-up). And the other would be an individual alien data-type, this would cover the current behaviour, recent knowledge, damage taken, energies left, current position in the current behaviour (perhaps each action will have several actions in squence, this will store which sub-action is currently being exicuted) etc. When mating a semi-random assortment of both parents will form the hybrid daughter (genes and traits). I think that each alien's sight square should be randomly generated. I also From ???@??? Wed Nov 16 02:18:35 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA13950 for ; Wed, 16 Nov 1994 01:47:17 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA95661; Tue, 15 Nov 1994 22:49:41 -0800 Date: Tue, 15 Nov 1994 22:49:40 -0800 (PST) From: Gregory Glen Taylor Sender: Gregory Glen Taylor Reply-To: Gregory Glen Taylor Subject: The "IMPORTANT STUFF" initial draft, for directors only. To: charles@krl.caltech.edu, g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII think that all of the player's traits should be randomized thru the same routine as the alien's. :) Below is Martijn's method. // please revise if desired Martijn. Ship configuration ------------------ Each pilot gets a standard amount of 'money' to configure a ship with. An alien pilot distributes its money in the following way. <% of total money invested in it> <% of total money invested in this> ... ... Total of <%> is 100% (obviously :). So, if the amount of money increases, configuration behaviour automatically adapts to it. Configuration behaviour evolves. (new things to invest in may be added, some may be deleted, % may be increased or decreased: these are the types of mutations possible) The conversion of % into money upon investing is not exact, sometimes a ship is lucky and gets some extra money, sometimes it's unlucky and gets less. This luck and unluck should average out over many cases. (in this way it's possible to get evolutionary pressure towards a better 'stage' of weapon even though actually not enough % is added to get this stage all the time.. but by chance a ship may get it anyway.) Example: Pilot A invests 100 money in the following manner: Thrust: 10% (increases thrust power of ship) Max Speed: 20% (increases max speed attainable by ship) Shields: 20% (increase power of shield of ship, so when hit is gets less damage in energy amounts) Start energy: 10% (increases energy the ship starts with) Weapon: powerlaser 15% (invests in a powerlaser weapon) Weapon: ultrabomb 25% (invests in ultrabomb weapon) The actual money invested may be: Thrust: 11 Max Speed: 16 Shields: 20 Start energy: 23 Weapon: powerlaser: 14 Weapon: ultrabomb: 30 As you see, this doesn't add up to hundred, but more; this ship is lucky. Now, we can't code smooth weaponlevels completely, some weapons may only have three types, for example, the ultrabomb may be 'basic type' above 10 but below 30, 'medium type' 30 or higher but below 60, and 'supertype' above 60. If the conversion from % to actual money invested would be exact, there would be no pressure 'upwards' to higher levels, because 25% investing in ultrabomb or 27% investing wouldn't matter at all. Because the conversion is inexact however, there is a higher chance to obtain 'medium type' when at 27% than when at 25%. (I hope anybody actually understands me here..it's quite a simple concept, but quite hard to explain..ask questions!) Boss aliens ----------- Boss aliens get simply a lot more config money than the normal aliens. [GT's ideas follow] I think a scaled up picture (larger) would make a boss much more menacing. I thru my method I would proportionally augment the stats of his siblings. Either way it would produce a mighty alien to be dealt with, which might bring his siblings with him to attack! Reproduction ------------ Different schemes are possible. I'll concentrate on the 'egg lay' scheme here. - ships can lay eggs, this costs an amount of energy. - ships can lay eggs only after they mated with another ship. This would simply involve another ship being at a close distance while the 'mate' command is invoked. If the other ship agrees upon mating, the egglaying of the mating initiating ship will happen. OPTION: this is quite complicated. Uncooperative mating would be easier to accomplish; mating is then always possible when another ship is close enough. Even easier would be asexual reproduction; a ship simply lays eggs which the same genetic code as itself, though it may be mutated somewhat. (experiments have shown that evolution with sexual reproduction of a kind goes quicker, however, there's more exchange of genetic material) - eggs hatch after a while. This may be a preset time, or this may be simply the result of a 'hatch-chance' every timestep. (if hatch chance is 10%, an egg will on the average hatch after 10 timesteps) - the player can breed with aliens also. The eggs will be 'lives' after they hatch. A 'life' will have a configuration that is a mix of the players ship and the alien ship it mated with. This way the player can obtain new weapons. [Gt's ideas follow] I think that there should be a mutation that happens every-so often (like boss aliens) that would trigger an alien to have the 'mate with player' behaviour. // we don't need to decide on an exact method in this file, but the defines // of -alien datatypes- and the -global vars- must be decided soon, for they // will be included in the 'Universe.h' for everyone to access. // In summary, the details need not be figured out, but the -general methods- // should be solidified in order to set the global defines. ------------------- - Art.c Sound.c - ------------------- This group will be in charge of either producing the pictures and music/sfx or writing routines to produce it (the latter is obviously preferred). Their code will have to be a C/C++ standard (ANSI C or the C++ standard), as it will also have to be portable. Also the sound, music, sfx files should also be done in a format that is easily portable. ------------- - Summary - ------------- OK, it's time for everyone to split into sub-groups. Please send me a simple msg with all of the subgroups you'd like to join (try to keep it to two max). If a group is still lacking a director, I will be accepting volunteers for those too. If you'd like to start a new FE, tell me about it. Also, we're looking for a co-director to manage the sound portion of the ART/SOUND group, this may envolve 'evolving' music and such as has been discussed. Keep it short, with the subject as 'SUB-GROUPS'. If you have comments on this file, save them for the mentioning in your subgroups; if they're very important and you definitely want everyone to see it, go ahead and do a general post. I'm trying to get us split into the sub-groups now, since we've gotten so huge in numbers. This way we can discuss the finer points of the specific areas of the project that we're interrested in. I'm going to ask Charles to set up a mailing list for each sub-group as well, we'll see. The current project outline is as such... PROJECT DIRECTOR : Greg Taylor INFO COORDINATOR : Charles AI/GA : Martijn Faassen UNIVERSE : Adrian Tymes ART/SOUND : Jeff Lait FRONT END - PC/X : FRONT END - MAC : Mike Mitchenen FRONT END - AMIGA : Please choose one or two groups you'd like to join and email me (gtaylor) direct with a brief list of the groups you'd like to be in with the Subject as 'SUB-GROUPS'. Don't waste your time typing the exact role in the group you'd like to fill, tell the group that after it's set up. More later. I'm tired and I want to get this off to the directors for their revisions. I'll write the rest of the summary later. // Below is a sample 'universe.h' I wrote up for Martijn a few weeks ago... // it's a bit out of date with my current scheme for the game, but it // gives an idea. Directors, this is the start of the header file for the game. All of the functions that will cross over between the groups are to be defined here. Any inner-functions that the other groups need not see are defined else- where. This is the 'general' header file to keep things compatible between the various groups. Note that I haven't -finished- it, I just started to get a sense of how we'd lay things out. The game is still far from the coding stage, and I based the Alien-structure on my 'trait/gene' method outlined in my earlier message. Since you're in charge of this field however, it is likely to change as your group discusses their attack plan on the GA/AI etc. This header tries to give an example of the style of comments and layout I'd like to see them use. My question is, do you like this 'standard' or do you think another style might be more effective? I start each function with an abreviation for the group that is coding it FE, UN, GA (Front End, UNiverse, GA) followed by an underscore, then the function name...Please give me some feedback on this... With this header file, the groups can code their code in any language, as long as it can be called through the header file (which would allow C++, ASM and Pascal I think...) But I think we'll stick with C, and the occational C++ or ASM, thrown in where it would be more efficient. The Universe will -have- to be in C, as it will contain the main () function. // Code example begins.. /*************************************************************************\ * The still nameless game... * *-------------------------------------------------------------------------* * Copyright by us 1994 All Rights Reserved. * *-------------------------------------------------------------------------* * Filename : Universe.h * \*************************************************************************/ #define GALAXYSIZE 128 // the size of the fighting-zone... #define VIEWSIZE 9 // the size of the viewed portion of the galaxy... #define TRAITNUM 8 // the number of alien traits #define GENENUM 12 // the number of genes an alien can have typedef struct { unsigned char trait[TRAITNUM]; // Values for all of the traits (0-255) unsigned char genetype[GENENUM]; // Which genes the Alien has (0-255) unsigned char geneval[GENENUM]; // What priority each gene has (0-255) unsigned char pictnum; // Index of where it's picture(s) are // stored at... // etc. } AlienType; //** FRONT END FUNCTIONS ************************************************** //** Filename : Frontend.c ** short FE_InitGraphics ( void ); // INPUT : None // OUTPUT : 0 success, -1 failure // ACTION : Sets the graphics mode. void FE_DeInitGraphics ( void ); // INPUT : None // OUTPUT : None // ACTION : Returns to previous mode //** UNIVERSE FUNCTIONS *************************************************** //** Filename : Universe.c ** short UN_Accellerate ( short acc, short speed, short maxspd); // INPUT : The alien's accelleration, it's current speed, and the maximum // speed of that alien. // OUTPUT : The resultant speed. // ACTION : Calculates the increase in speed of alien... //** BEHAVIOR FUNCTIONS *************************************************** //** Filename : AIGA.c ** AlienType GA_CreateOffspring ( AlienType parent1, AlienType parent2); // INPUT : The two 'parent' Alien gene-structures. // OUTPUT : The 'child' Alien gene-structure // ACTION : Combines the two parents to form one child structure... // Code example ends. I'm not a physics major, but from what I remember of my high school physics class, Accelleration needs those variables right? Well it's an example anyway. Please correct my spelling errors where you find them for the function names, I'm not the best speller...I usually switch between Brittish and American English spellings of certain words...behavior being one of them. Note that 'behavior.c' is the American spelling, due to the fact that the Brittish one would take 9 spaces (too long for PC filenames). I thought another thought for the breeding aspect. We ought to have the total sum of the traits, make for a higher chance of drastic mutation. That way as things dull out, due to better and better aliens, they also mutate more and the offstring are less predictable...This might keep things from getting stagnant.... We should also be constantly introducing new aliens to replace those lost. The big question still remains, how do we measure 'winning' or if there's no winning it, how does a player have some goal or measurement of their success. Simcity has this aspect covered, we ought to at least either have it be winnable, or have some sort of thing aside from the genetic evoltution, to keep things interresting for the player...hmmmm.. I guess we'll discuss this with the group... We ought to compile our results from these messages back and forth for the group to see...sometime (probably after the survey stuff is all wrapped up). When we get people divided into sub-groups, the code progression will go like this, PC people will work on the PC Front End. Non PC programmers will work on the Universe. AI/GA team will begin work on designing the format and "methods to your madness" (to quote Hamlet loosely), since this will take a while. Then when the bare-bones versions of the PC-FE and the Universe, we can all swap code and then the AI/GA team can get to work transfering their test-code and algorhythms into the game environment to test it out in action. From there we (the directors) would guide our teams towards improved modules in an efficient manner, with the most important improvements first; trading code when at a break-point. The PC will be first, due to the fact that most all of us either have a PC or have access to one, so it makes it the best for us to develop the game on. Those without PCs would have to work on the Universe, participate in the AI/GA discussion or work out general ideas and what not. With a good header-file, all of the functions should mix well with the other modules flawlessly, but we must try to think of everything before- hand, which will be tough. Even though I'm not a Genetic Evolution kinda guy, I think that my trait/ gene scheme has potential...hmmmm...we'll see what other methods are presented. // Directors summary. This file is currently -very- messy, and much of the latter portion (the header file) will be removed in the group version. I'd rather not have 25 people posting -their- versions of the header file, it'd get messy. We will have to work up the header file relatively on our own, discussing within our groups, for which functions we'll need. This file, when completed, will call for everyone to join groups, and then things will start to be dealt with within the sub-groups and general msgs will become fewer... This way the sub-groups can focus on their particular aspect of the game. Please add stuff and mark stuff for deletion etc. in this file, and mail me your additions/subtractions etc. I'll patch all of our responses together and remail them to you all for approval. Once we get an agreeable file together I'll post it to the group. I want to get this sent, I've been typing long enough for one day. (I doubt it's coherent at all...try to make some sense of it.) Try to get your revisions back to me soon, I want to get this to the group soon, the natives are restless! -=GT=- From ???@??? Wed Nov 16 10:26:48 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA16269 for ; Wed, 16 Nov 1994 10:05:00 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7lsT-000fIrC; Wed, 16 Nov 94 07:02 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id ac17795; 16 Nov 94 14:24 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA002ye; Wed, 2 Sep 92 14:31:56 GMT Date: Wed, 2 Sep 92 14:31:56 GMT Message-Id: <9209021431.AA002yd@darkin.demon.co.uk> In-Reply-To: <199411160537.GAA06174@laurel.stud.phil.ruu.nl> (from Martijn Faassen ) (at Wed, 16 Nov 1994 06:37:52 +0100 (MET)) X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Reply-To: christian@darkin.demon.co.uk MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit From: Christian Darkin To: alife-game@alnilam.krl.caltech.edu Subject: Re: Various... Hi Martijn and all, > > I think we're going to be using far more advanced techniques > > than simple GA's (especially if I get involved with it... BAHAHAHA... oh > > excuse me.:-) ) Already we are talking about creatures laying eggs to > > determine who gets to reproduce rather than a more artificial method - > > this is vastly superior than the classic GA, and allows for a much better > > integration with the environment than otherwise. We don't have to worry > > about coming up with a fitness function which takes everything into acount > > because that aspect becomes removed from us. This same principle is what > > has caused the great success of systems like Tierra and Avida. > > Right, I'm glad you come up with that, using eggs instead of a fitness > function. I think the game might improve with some kind of what you call a fittness function. I think that some things we want the creatures to select for will not neccessarily be immediately beneficial to them. Eg, being aggressive. We do want aggressive creatures, not ones that would rather live together in peace and harmony. There needs to be some reward, therefore that can be gained by attacking the player. I also think that evolution will be helped along if `fitter` aliens are more attractive to their mates. > We should create the Behaviour code as low level as possible. > People are for example talking about 'enslavement' of aliens by other > aliens. While this is a nice idea, it would be better in my opinion > to leave things like this more open ended, and let it (possibly) evolve. > If that turns out not to work, we can always include some 'hard coded' > genes which do more complicated stuff (actually this would be standard > functions every alien could use). I`m a little confused. As you mentioned in a previous post, I developed my ideas on electronic evolution completely independently from anyone else. I`d never even heard of a GA before I posted this game idea. I just had my own theories on how un-natural selection might be accomplished, and you tell me that they`ve turned out to be pretty close to what the current thinking is (which is quite flattering, actually!). This means I`m trying to get my head around what`s actually being developed. My question is this; You say above that if you leave things `open ended` then advanced behaviours like enslavement might evolve on their own. Surely there is only the potential in any computer program to spit out what has been put in in the first place. If you want something to have a chance of happening, don`t you first need to give it the potential to happen? I mean, if you don`t define what (for example) a sense of hearing is, then surely the creature cannot independently find out? If you don`t define an ability for one alien to control another, then it is no more likely to invent that ability than it is to evolve the capacity to climb out of the screen? I`m sure you`re right in what you say. I`m sure there are ways to give creatures that kind of open endedness. I just want to understand it.~:) > > > Anyway, I think that we should refer to the team in charge of these > > details as the Alife design team and so forth. > > We were currently talking about Behaviour team, though Alife sounds > fine to me too. :) > > By the way, talking about Alife, Charles, here in Utrecht I followed > a class in september and october called 'bioinformatics', tought by > Pauline Hogeweg. Ever heard of her? At least she just about knows everybody in > the Alife field personally. :) > > It's good to have you in the group, Charles! > (and good to have all the others too of course..we really got some > talent in it..sorry for sounded so excited, this is just going better > than I expected. :) I agree with that!! We`re getting some really top rate stuff into this game, and people with skills in all kinds of areas. I think it won`t just be a revolutionary video game, it`s also got the skills to be a very polished production as well. I`m really excited by the way this is going, and I hope we can just keep this momentum up. It also strikes me that if we`re putting into this some quite advanced theory, we could also be creating a unique scientific experiment in alife. Consider this: I don`t know what the true figures are, but say an average game player plays our game for 1 hour a night for 3 months, and let`s say we get the game published and get 250,000 users worldwide (not unlikely considering the size of the games industry). If we could encourage data (evolved creatures, etc) to be swapped around between players, and if we could get feedback from the players about what is developing, as the game is played, we effectively have 885 years of simulated evolution! Has an experiment with alife ever been conducted on that kind of scale?? Christian. -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For #10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Wed Nov 16 10:26:50 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA18034 for ; Wed, 16 Nov 1994 10:14:06 -0500 Received: from yuma.ACNS.ColoState.EDU by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7m2t-000fIsC; Wed, 16 Nov 94 07:13 PST Received: from K12.ColoState.EDU by yuma.ACNS.ColoState.EDU (AIX 3.2/UCB 5.64/4.03) id AA60946; Wed, 16 Nov 1994 08:11:09 -0700 Received: by k12 (4.1/SMI-4.1) id AA13754; Wed, 16 Nov 94 08:16:42 MST Date: Wed, 16 Nov 1994 08:16:42 -0700 (MST) From: Robert Elsner X-Sender: relsner@k12 To: Christian Darkin Cc: alife-game@alnilam.krl.caltech.edu Subject: Re: Various... In-Reply-To: <9209021431.AA002yd@darkin.demon.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII My plans for this game: Release it 1-4 months before target date on sharware. Then give the user an option to buy the final version. Which has more of something??? What baffels me. I guess we could have you able to play it for _ amount of hrs. I don't really know, but hey!! My other idea is to have it a net game. If you had for instance a UNIX, DOS, MAC, and SUN linked on a lan, you could play a 4 way game. In the net game, the other players would appear to be just another alien to BLOW away. Also, you could (if we found the experienced people) play over the internet. Robert Elsner relsner@k12.colostate.edu Platte Canyon High School Bailey, Colorado 80421 Barney-Mania will be the future. For us to survive, we must adopt to Barney. He is our GOD!!!!! --Famous quote from: Will Box 2095 From ???@??? Wed Nov 16 10:55:54 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA23466 for ; Wed, 16 Nov 1994 10:50:57 -0500 Received: from mail.massey.ac.nz by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7mcF-000fItC; Wed, 16 Nov 94 07:49 PST Received: from gorgo.manawatu.planet.co.nz by mail.massey.ac.nz id <28046-0@mail.massey.ac.nz>; Thu, 17 Nov 1994 04:47:46 +1300 Received: (from uucp@localhost) by papaioea.manawatu.planet.co.nz (8.6.9/8.6.9) with UUCP id CAA01704 for alife-game@alnilam.krl.caltech.edu; Thu, 17 Nov 1994 02:34:47 +1300 Received: by gorgo.manawatu.planet.co.nz (1.65/waf) via UUCP; Wed, 16 Nov 94 20:01:14 +1200 for alife-game@alnilam.krl.caltech.edu From: belial@gorgo.manawatu.planet.co.nz (Turtle Dragon) To: alife-game@alnilam.krl.caltech.edu Subject: Re: universe Date: Wed, 16 Nov 1994 19:36:00 +1200 Message-Id: <111694193639Rnf0.78@gorgo.manawatu.planet.co.nz> Organization: Razor Software/S.A.W. Design. Developers of GUI-BBS and GUI-Term. X-Mailer: Rnf 0.78 Christian Darkin writes: >> The Objects in the Universe >> --------------------------- >> >> - each have a speed (may be zero). >> - are inertial, so do not slow down without any force on it. (no friction) I think we should have some friction, It gives things a nicer feel and look. >> - each have a direction. >> The direction angle is 0-255. 0 is N, 128 is S, etc. This is the >> _objective direction_. >> - can turn smoothly. 16 different rotations is probably enough. >Also, objects should have MASS. That way, a force (engine) used on a >small light ship will allow it to travel much faster than the same force on >a big, heavy ship (a boss ship, for example). Thus, bosses don`t zip around >like mad things, and there will be a nice kind of payoff between speed and >power (armourment, etc). Definately >I`m very keen (as I keep saying) on having a series of `movement patterns` >for each alien ship which are triggered by sensory events rather than just >a series of movements. The difference is that if an alien receives a >sensory signal which it wants to react to, just being able to make a single >`rotate and thrust` movement isn`t going to be as interesting either at >the time, or in 100 generations as jumping into a routine which makes it >circle, or zig-zag, or do a double loop around the nearest asteroid. OK, say the Alien keeps track of what patterns prove to be successful, ie if it decides to "Attack" a prospective food source by "Movement pattern X", if this is successful it stores this result.. when it comes time to "breed" or whatever, these statistics can be used to pass successful reactions/behaviours to the new species... So movement code would consist of some kind of library of methods, larger methods could be built from these... in the end however its all built up from turning and thrusting. from the aliens perspective it might be "Circle that non-threatening object", followed by "Zig Zag approach that food source while trying to destroy it" If it is damaged while attempting that form of approach, it becomes less likely to use it again, and less likely to pass that approach onto a new alien.. >Here`s a thought: What about releasing an `alien writer` allong with the >game so people can build their own (we`re going to have to write one anyway) >Then we can encourage people to swap their invented (or evolved) beasties >around. We could set up a kind of FTP site `gene pool` where people dump >and collect strange creatures! Sounds great. >Why not make the projectiles just aliens written in a different way to other >aliens. (ie, they`d have no desire to mate or be mated with. They wouldn`t >be able to be shot - or maybe they would. They would only have one >movement pattern, etc.) That way, when two creature`s mated, you could just >mate their bullets in the same way. I think that projectiles should just be a simplistic alien, this would give everything besides the main character as being a "alien" of some sort, what it actually is/does is its own business. >Also, by making projectiles just aliens without personality ;? there would >be the possibility of having aliens fire other aliens instead of bullets - >just like boss ships do in some games, or pods do in Defender when they`re >shot and explode into many tiny ships. That would be great.. BTW are we looking at some kind of large map top view asteroidish game here?? how about building in several forms of movement. Aliens could exist on the ground, in the air, or be able to change. >Again, we should try to write them with the same system we use to make >aliens. After all, all life on earth - animal or vegetable - has the same >set of genetic codes! Everything is an alien of sorts. >>You mention `obstacles`. What are they? If we give our aliens the ability >to move objects around by knocking into them, and `bouncing` them about, and >then produce various `obstacles` with different properties and leave them >lying around, then maybe the alien`s would evolve to use them - like tools. >or maybe not ;D Sounds very complex. >Why have aliens and pilots and ships? Why not just say the aliens are part >organic, part machine. They are advanced reproducing robots which use >nannocomputers and GA`s to evolve. That way our plot and what we`re >*really* doing become interwoven to make a sort of surreal point about the >future of *real* computer technology. (You can tell I`m a writer!) I don't like the idea of aliens being generated. the game should start with various mixes of stats and movement routines.. they should then naturally develop >If we breed the firepower, then there would be a smooth weaponlevel. Also, >if the `rating` given to a projectile (and remember I said projectiles >should be constructed using the same system as aliens) is it`s cost, and >also the power needed to shoot it, then we`ve got quite a good system going. What about the players weaponry??? I personally think this should be in pre-defined weapons and types with options to purchase weaponry between levels... sortof like a Human excursion to wipe out an alien planets eco-system in order to move in and terraform for human colonization. ie. Our already developed tech ends up facing a developing alien resistance. >I think that aliens should be going on and off `heat` all the time, but when >two aliens are on heat at the same time, they both switch to their own >mating `movement pattern` which would involve going off to look for each >other. Yes, movement code modules should meet success/failure criteria for different purposes, one movement pattern could be a failure when it comes to attacking, but very successful as a defence. Of course the aliens might evolve effective methods of dealing with your weaponry, but what about when you go and buy a new "gun", the old aliens that are now extinct may have been better able to deal with it. Older forms of movement would have to be being constantly re-injected into the system to give them a chance. >How about alien/player crosses coming out as live young, not eggs. They >can be sort of jelly blobs which wander about. Their movement patterns >would mostly make them stay in groups, but occasionaly wander about alone. >That way, the player would have to try to keep his clutch under control as >they were attacked, and the player tried to wipe out aliens. Alien<->Player crosses??? are we going to have friendly aliens or something??? >>We should have quite a high turnover of player embryos so the player is in >constant danger of loosing them all, and has to frantically seek out mates >to keep the numbers up. Are these like some form of extra lives??? or are they actually babies that help out when they grow up?? *-- --* C Warner, belial@gorgo.manawatu.planet.co.nz, Razor Software (NZ) *-- --* From ???@??? Wed Nov 16 13:29:51 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id LAA26450 for ; Wed, 16 Nov 1994 11:10:09 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7mrX-000fItC; Wed, 16 Nov 94 08:05 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA04748; Wed, 16 Nov 1994 08:04:11 -0800 From: Charles Ofria Message-Id: <9411161604.AA04748@altair.krl.caltech.edu> Subject: Re: Devils Advocate To: alife-game@alnilam.krl.caltech.edu Date: Wed, 16 Nov 1994 08:04:11 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 8317 Before I start ripping (or at least trying to) his ideas apart, I must say that Kim makes some excellent arguments here, and most of his points in and of themselves are quite valid. -- From: HARRIES K A [munch] > There is understandably a certain amount of euphoria in many peoples > comments and suggestions, especially those concerning the most important > aspect of the game: the evolving behaviour. > > Comments such as - > "The beauty of ALife is that it can handle any level of complexity > w/o a problem, but the humans making tanks (or whatever) will not be able to > integrate as perfectly. The reason I especially like this is that a player > will develop a type of tank with specific skills and drawbacks, and no > matter what those drawbacks are, the alife *will* find them and use them." ... a somewhat paraphrase version of my comment I believe. > You may find that the evolving critters aren't so good at finding a > weekness niche as you'd like to think. Not that the wouldn't in the long > run of course, but a game like this is gonna present such a noisey > environment for learning in that it may be very difficult for evolution > to get a grip. I know from experience that high hopes of evolving complex > behaviour etc. can turn out to be too optimistic. If you look at the kind > of behaviour that has been evolved in ALife to date you wont find > anything as complicated as your group is talking about (in your more > enthusiastic moments ;). Often what appears to be really clever behaviour > in an ALife experiment turns out to be not so impressive when you read the > actual details of the experiment. Well, I agree that evolving complex behaviors is an extrodinarily difficult thing, but you must admit that *optimizing* complex behaviors is what programs like this are best at. The way I see this working is that we are going to seed the universe with working creatures and then let evolution take over from there. Those behaviors which work best for specific locations or against specific players will thrive and minor variations will optimize them. I think that we will see the creation of occasional brand new behaviors (both from unexpected mergings of old behaviors and spontaniously), but not often enough to make the game fully playable. Side note: If you are interested, I can give you references to a good number of papers where signifigant complex behaviors were evolved. > Of course you have the big advantage of being able to 'cheat'. You do not > have to show that your complex behaviour evolved from very simple basic > moves, or without any human intervention etc. - If you come up clever > evolving aliens in an ace game, who cares how it was done? The only 'cheating' that I see needed is to seed the universe with creatures. In theory we could do this by simply running the program for a very long time before we give it to the players, but I think that seeding it by hand is not so far off. Even then I think we should run it for a short amount of time before its ready to play. Having cheats beyond that ruins some of its appeal as an alife game - to encourage traits which we think it should desire (rather than just offering at the begining them an seeing if they take a hold on their own) will usually inadvertantly discourage other things and potentially limit evolution in unforseen ways. We've struggeled with this problem for a long time in avida and discovered that the best way to breed programs which can carry out desired algorithms is to just create a proper landscape where this helps the program survive (in avida's case, increase the creatures CPU time). > I have recently written a program which is currently attempting to learn > a *VERY* simple game: Basically a two-planes-trying-to-shoot-each-other > kind of thing. The only actions are fly straight, turn left, turn right, > and shoot. The program is trying to evolve at set of simple production > rules for playing this game by playing against itself in a tournament > selection GA. Dead simple eh? Not so. The poor guys have been running for > days now, and despite improvements in behaviour have not shown the > expertise I hoped for. Again, for this example if you had started off with creatures that could play the game, they would have optimized themselves nicely. We also have the advantage that all rewards are instant for this game - if you shoot the player you immediately get an additional x ammount of energy; It a more realistic envirionment and thus better for evolution. > The morale of this story is basically that your priority should be to get > something simple working *soon*. From this you can learn what sort of > difficulties you will be up against. Forget the poncy graphics etc., it's > all been done before and can be grafted on at any point. This I can agree with whole-heartedly. Start with a basic game, and add details in latter. For example, we don't need players to be able to build their ships in the start; we can even start with a universe where all the aliens have the same ships to control and just get some kind of controller working. Heck, we don't even need them to evolve to begin with. Granted this would be a very boring game, but at least it would be a basis to work off of. We should start writing up a set of immediate goals (as soon as we break up into teams that is) of just what we need before we can have *something* working. > Of course my planes labour under the great disadvantage (imposed by me) > of only receiving payoff information of whether they win,lose or draw, > i.e. no helping hints from the designer such as 'being behind opponent is > good'. You need not impose such constraints, although the less specific > information provided by you the more potential for surprising behaviour > the aliens will have. In overall potential, this is not a big problem, it will simply cause you to have to do more runs; even then it shouldn't be all that bad. If I creature dies, it would have died in either case. The only problem I can see it causing is that creatures need to be devoloped as a whole rather than one behavior at a time. > One thing that learning systems and ALife experiment repeatedly > demonstrate is their ability to find loopholes in what the programmers > intended tasks were and those they actually set. Be sure that if the > aliens can survive by running away and not fighting the player they'll be > happy to do so! Ugh! Sometimes I think I'm spending my life patching said loopholes. Tell me about it. Another good reason to start from a bare bones program and add one feature on at a time so we can see when problems crop up immediately. There is nothing worse than to have a creature taking advantage of a loophole that you can't even find with looking at the creature. We'll still have problems with unforseen results of combinations of additions, but there isn't much we can do about that. > Also, although some of the responses to my point about any sensible player > killing the tough aliens first look viable part of my point (badly made, > no doubt :) was that it is all too easy to design a system whose dynamics > are a knife-edge rather than a trough. In other words if you just make > the aliens tougher in some way so that the player finds it tough just > picking on the nasties, the outcome of the game may be determined by who > gets on top in the crucial early stages rather than being a constant > battle against gradually improving opposition. Another idea that just poped into my head is that we might also want to somehow take into account the rate at which enemies cause damage to the player, thus even if they are killed off quickly, this rating will be somewhat acurate (or heck, it may even be too high if the player rushes up to the creature taking an extra hit just to kill it quickly). > Well, that's enough scepticism for one day I think. Please don't get the > wrong impression - I am very keen on your idea and hope to see it work. I > wouldn't be raising so many questions if I thought for one moment it > would put any of you off! > > Keep up the good work, > > Kim. Thanks for all the ideas Kim! I must say its gotten me thinking along a number of interesting tracks. --- Charles From ???@??? Wed Nov 16 13:29:53 1994 Received: from undergrad.math.uwaterloo.ca (root@undergrad.math.uwaterloo.ca [129.97.204.13]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id LAA27132 for ; Wed, 16 Nov 1994 11:14:51 -0500 Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56982-3>; Wed, 16 Nov 1994 11:14:55 -0500 Date: Wed, 16 Nov 1994 11:14:33 -0500 From: Jeff Lait Subject: Re: The "IMPORTANT STUFF" initial draft, for directors only. To: Gregory Glen Taylor cc: charles@krl.caltech.edu, g-j@chameleon.alt.za, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Nov 1994, Gregory Glen Taylor wrote: > To : Charles, Gert-Jan, Jeff Lait, Martijn, Mike Mitchenen, Adrian Tymes > > ---------------- > - Universe.h - > ---------------- > The header file for the game outlines the parameters and names of all of the > global functions. This way all of the functions in the various sections of > code will be able to call functions in other sections of code (ie the > Universe can call Front-End routines). The code can then be worked on > independently, and the other groups will know how to access and what data to > send to the external routines. This will keep compatibility high and > re-coding to a minimum. The key to a sucessful Universe.h is a -complete- > function list which has all or nearly all of the gloabal functions and > variables that will need to be accessed by the other groups; because adding > forgotten functions will mean work for -all- of the groups...which could > possibly be avoided. > Agreed... > --------------- > - Front End - > --------------- > This section of the code is the only machine/compiler specific code. It may > be coded in assembly, or whatever the FE team deems they'd like to do. The > only restrictions is that it must be accessable by the C header file > (universe.h), so the functions must be written so that they will be able to > be accessed through those defines... > > It will include : > Graphics: Setting the mode, sprite manipulation, fonts, and a 'movie' > displayer that will display our standard intro and plot > sequences (we'll develop a standard .mov file which will have > various pictures and sounds/music in a sequence). `Compile' routines for taking generic sprites into specific format sprites. Serios compression is required to get a 640x480x24bit movie small enough. Matter of fact, I've dealt with some of the issues already (320x200x24bit movie player... Uses delta compression - not very efficient, the technique used should depend upon what our data ends up looking like... Raytracings, fortunately, usually compress well. > Sound: Playing midi files or mods (not sure yet) also sound efx, > will have to work closely with the Art/Sound team in order to > implement their ideas effectively. > Control: Keyboard caching (grabbing multiple chars if multiple are pressed, > ie turn+acc+fire), joystick control, mouse control etc. Timer: A function which allows us to have a local variable passed to it updated every screen redraw - allows us to determine how far ships accelerate etc. > Others?: This will handle other stuff that I've forgotten for now....hmmm > > > The sound is still in question for which file formats it will use, most likely > midi's or mods to increase portability. If evolving music is developed by > the Art/Sound team, then that will have to be implemented. The most likely > 'general' function for the FE for sound will be a 'int Music(blah, blah:junk);' > type thing, then the FE group would either call a routine written by the > Art/Sound group or perhaps send a midi file etc... > > As for the '.mov' file. I envision this as a file with large x large x 24bit > original pictures for the intro sequence, with embedded music and sfx. This music/sfx no problem. Depends how tightly synced you want the music - even if we use MODs, you can use a couple of the unused special control commands as sync commands for the movie. Remember, for a lot of effects, real time code is WAY better than raytraced movies... > way when a FE group is fine-tuning for their format, they can run a converter > program on the .mov file to reduce the pictures down to the desired size for > that FE. The pictures in the intro will likely be Ray-traced, 'cause drawing > frame after frame of large x large x 24bit pictures by hand is a weighty > task. The actual .mov files will be produced by the Art/Sound group, and > the FE need only convert and display them. > > The current FE groups are : PC/MAC/Amiga > > Other Front Ends may be formed if someone will direct a group to code them. > The FE-PC will need to be developed first, this is because the PC is the > most common computer within the development team, thus it would be most > useful to test other group's routines. Other groups can either wait for > the FE-PC to be reasonably finished and convert that code -or- code > simultainiously. > > > ---------------- > - Universe.c - > ---------------- > Universe Design post> > > This portion of the game will be written in standard ANSI C. It contains > the main() procedure and is basically the 'controller' of the game. It will > call FE routines for it's user input and output, use AI/GA and Art/Sound > routines for generating the aliens and their behaviour. > Okay, just a clarification, so the breeding code is found both in Art/Sound and AI/GA? Ie: - Code for generating new appearance of alien is in Art/Sound. - Code for generating new behaviour code in AI/GA? Because, if we are to do timesplicing to reduce overhead, we'll either need some code in the UNIVERSE to successively call MorphAlien every frame until it is complete, or through something on the timer loop - I'd vode for the former. Note, however, that this implies that the front end must also have texture mapping and bit map scaling/rotating for the sake of the Art/Sound code, which being platform independent, cannot necessarily achieve the desired speeds. > Aside from it's control-center aspect, it also handles things like the > physical aspects of the universe, acceleration, turning, etc. > > This text specifies the Universe part of the game. Anything that is not > basic will have the word OPTION: in front of it. > > [Martijn's Note: this file is mostly about my ideas on it; of course you > may disagree, please say so if you do. This text isn't (yet) final about > anything] > > The Universe > ------------ > > - is relatively independent of the actual front-end. > - is flat; 2d. > - has wrap around borders, and has thus no borders, but it's > finite too. > > The Objects in the Universe > --------------------------- > > - each have a speed (may be zero). > - are inertial, so do not slow down without any force on it. (no friction) > - each have a _objective direction_. > The direction angle is 0-255. 0 is N, 128 is S, etc. This is the > _objective direction_. > - each have a _facing direction_, which is the direction the object is > facing, usually the same as the _objective direction_. 0-255 deg as well. > - can turn smoothly. 16 different rotations is probably enough. > [though we might just send the _facing direction_ to the FE and let them > decide how many rotations to implement..:)] - As someonme mentioned, we should also include mass. > > Kinds of objects > ---------------- > > The ships > --------- > - can turn left and right. > - can add thrust. - IMOO, they should be able to add forward & reverse thrust. > - have two types of energy: > 'Armour' : How many 'hit points' the ship has left, before it dies. > 'Usable' : Energy it has to fire, mate, move, etc. > - decrease armour energy (and perhaps Usable as well) if hit by a weapon. > - can gain energy by eating energy pods (perhaps the remains of killed > enemies, eggs, and misc other sources). > OPTION: this might be 'plant growth', or asteroids, or pods that come free > when a ship is destroyed. This remains to be decided. > - can fire their weapons (up to two weapons?). > [Martijn's _relative direction_ stuff omitted. If my method doesn't work, > put it back in...] > - _relative directions_ of other objs can be obtained by comparing the > _objective directions_ of both objs. This way it can be determined if > another obj is heading towards an obj... > - can view the distance another obj is at. > - can view the speed (relative speed?) another obj is flying with. > > > The player ship > --------------- > > - is controlled by the player, by a 'thrust' key, left and right rotation > keys, a fire key. > OPTION: a breed key, an eat key, a 'weapon option' key, etc. > > The aliens ships > ---------------- > > - are controlled by alien pilots. A pilot is a piece of behaviour code. > - have essentially the same control methods as the player, using 'virtual' > keys. (they call the same functions as the ones that get called when a > key is pressed by the human) > > Projectiles (missiles, bullets) > ------------------------------- > > - can collide with ships. The ships loose a certain amount of energy when > hit, dependent on the type of projectile. > - may have very primitive behaviour code in them. Projectiles may evolve! > OPTION: energy donation projectiles might also exist. Vampiristic projectiles > can also exist. (they suck energy out of the ship that is hit, and transfer > it to the ship that fired the projectile) > - are always destroyed upon collision. (they explode) > - are fired by ships. (of course :) > > Other objects > ------------- > > Asteroids, obstacles, energy pods, plants, motherships, etc. > > > ------------ > - AIGA.C -- > ------------ > // This section is in a huge disarray, it will get organized later, once > // more definite alien-type datastructure and global vars are developed. > // for now it is the director's forum on AI/GA implementation. > > // we don't need to decide on an exact method in this file, but the defines > // of -alien datatypes- and the -global vars- must be decided soon, for they > // will be included in the 'Universe.h' for everyone to access. > Precisely - the Frontend must also know the alien data types (specifically, their position and current frame of animation (Universe is responsible for animation (While they are updating coords, looking for collisions etc.) according to the current time click.) > // In summary, the details need not be figured out, but the -general methods- > // should be solidified in order to set the global defines. > > > ------------------- > - Art.c Sound.c - > ------------------- > This group will be in charge of either producing the pictures and music/sfx > or writing routines to produce it (the latter is obviously preferred). > > Their code will have to be a C/C++ standard (ANSI C or the C++ standard), as > it will also have to be portable. Also the sound, music, sfx files should > also be done in a format that is easily portable. > Though note stuff like texture mapping has to be sloughed off to the front end. > > ------------- > - Summary - > ------------- > OK, it's time for everyone to split into sub-groups. Please send me a > simple msg with all of the subgroups you'd like to join (try to keep it > to two max). If a group is still lacking a director, I will be accepting > volunteers for those too. If you'd like to start a new FE, tell me about > it. Also, we're looking for a co-director to manage the sound portion > of the ART/SOUND group, this may envolve 'evolving' music and such as has > been discussed. Keep it short, with the subject as 'SUB-GROUPS'. If you > have comments on this file, save them for the mentioning in your subgroups; > if they're very important and you definitely want everyone to see it, go > ahead and do a general post. > > I'm trying to get us split into the sub-groups now, since we've gotten so > huge in numbers. This way we can discuss the finer points of the specific > areas of the project that we're interrested in. I'm going to ask Charles > to set up a mailing list for each sub-group as well, we'll see. > Just as a note, cs2333 whatever (Sorry, I can't even remember my own name half the time) e-mailed me saying he's interested in the Art/Sound sub group. He's currently working on the texture mixing... > The current project outline is as such... > > > PROJECT DIRECTOR : Greg Taylor > INFO COORDINATOR : Charles > > AI/GA : Martijn Faassen > UNIVERSE : Adrian Tymes > ART/SOUND : Jeff Lait > FRONT END - PC/X : As I said, I am willing to fill this as well - it will enable me to get an idea as to what is required in the front end :> > FRONT END - MAC : Mike Mitchenen > FRONT END - AMIGA : > > Please choose one or two groups you'd like to join and email me (gtaylor) > direct with a brief list of the groups you'd like to be in with the > Subject as 'SUB-GROUPS'. Don't waste your time typing the exact role in > the group you'd like to fill, tell the group that after it's set up. > > More later. > > > I'm tired and I want to get this off to the directors for their revisions. > I'll write the rest of the summary later. > > > // Below is a sample 'universe.h' I wrote up for Martijn a few weeks ago... > // it's a bit out of date with my current scheme for the game, but it > // gives an idea. > > Directors, this is the start of the header file for the game. All of the > functions that will cross over between the groups are to be defined here. > Any inner-functions that the other groups need not see are defined else- > where. This is the 'general' header file to keep things compatible between > the various groups. Note that I haven't -finished- it, I just started to > get a sense of how we'd lay things out. The game is still far from the > coding stage, and I based the Alien-structure on my 'trait/gene' method > outlined in my earlier message. Since you're in charge of this field > however, it is likely to change as your group discusses their attack plan > on the GA/AI etc. This header tries to give an example of the style of > comments and layout I'd like to see them use. My question is, do you like > this 'standard' or do you think another style might be more effective? > > I start each function with an abreviation for the group that is coding it > FE, UN, GA (Front End, UNiverse, GA) followed by an underscore, then > the function name...Please give me some feedback on this... With this > header file, the groups can code their code in any language, as long as > it can be called through the header file (which would allow C++, ASM and > Pascal I think...) But I think we'll stick with C, and the occational > C++ or ASM, thrown in where it would be more efficient. The Universe will > -have- to be in C, as it will contain the main () function. > I have nothing against said prefixes. Also, those with C++ compilers will have to remember to through in extern "C" when dealing with normal c or asm files, to avoid name mangling. To include Pascal, I believe only the PASCAL directive is required to set the appropriate calling convention (Pascal would not be able to call ASM easily, however, because of there screwed up calling convention - stuff is shoved on the stack backwards, and its the called proc's job to clear the stack of parameters). > > // Code example begins.. > > /*************************************************************************\ > * The still nameless game... * > *-------------------------------------------------------------------------* > * Copyright by us 1994 All Rights Reserved. * > *-------------------------------------------------------------------------* > * Filename : Universe.h * > \*************************************************************************/ > > #define GALAXYSIZE 128 // the size of the fighting-zone... > #define VIEWSIZE 9 // the size of the viewed portion of the galaxy... Thoughts about this... How 'bout viewing size being 1024x1024 and galaxy size being 64kx64k. Gives us a playfield 64 times wide as high, and makes fixed point for alien positions easy to deal with. Furthermore, checking if a ship in bounds does not require extra code for wrapping playfield... > #define TRAITNUM 8 // the number of alien traits > #define GENENUM 12 // the number of genes an alien can have > > Is it possible for the Front end (Which will be accessing this in ASM, so requires fixed offsets) to reserve the first few elements of this structure: ie: > typedef struct > { unsigned long x, y; // Alien position, 16.16 fixed char *currentpic; // Current animation pic. 32bit. > unsigned char trait[TRAITNUM]; // Values for all of the traits (0-255) > unsigned char genetype[GENENUM]; // Which genes the Alien has (0-255) > unsigned char geneval[GENENUM]; // What priority each gene has (0-255) > unsigned char pictnum; // Index of where it's picture(s) are > // stored at... > // etc. > } AlienType; > > > //** FRONT END FUNCTIONS ************************************************** > //** Filename : Frontend.c ** > > short FE_InitGraphics ( int sx, sy ); > // INPUT : None > // OUTPUT : 0 success, -1 failure sx is the correct ship width, sy height. > // ACTION : Sets the graphics mode. > > void FE_DeInitGraphics ( void ); > // INPUT : None > // OUTPUT : None > // ACTION : Returns to previous mode > void FE_RedrawScreen(AlienType *Aliens, *You, int num_aliens, int *tick); Or there abouts - you might be stored in a SHIP type, but essentially something with X,Y,char *ShipPic. ShipPic is of course also the correct ship for the current heading. Tick is set to the current time, allowing the called to find the dt. void FE_CompileShip(char *source, char *dest); Converts a raw bit map sxxsy into the compiled version which this prog likes. Also, some texture/rotation algorithms must be included here. > //** UNIVERSE FUNCTIONS *************************************************** > //** Filename : Universe.c ** > > short UN_Accellerate ( short acc, short speed, short maxspd); > // INPUT : The alien's accelleration, it's current speed, and the maximum > // speed of that alien. > // OUTPUT : The resultant speed. > // ACTION : Calculates the increase in speed of alien... Actually, I think a better format would be:\ short UN_accelerate(short force, short mass, short speed, short maxspeed, short delta_time); As we do not necessarily know the time interval from one time click to another. > > > //** BEHAVIOR FUNCTIONS *************************************************** > //** Filename : AIGA.c ** > > AlienType GA_CreateOffspring ( AlienType parent1, AlienType parent2); > // INPUT : The two 'parent' Alien gene-structures. > // OUTPUT : The 'child' Alien gene-structure > // ACTION : Combines the two parents to form one child structure... > > > // Code example ends. > > > I'm not a physics major, but from what I remember of my high school physics > class, Accelleration needs those variables right? Well it's an example > anyway. Please correct my spelling errors where you find them for the > function names, I'm not the best speller...I usually switch between > Brittish and American English spellings of certain words...behavior being > one of them. Note that 'behavior.c' is the American spelling, due to the > fact that the Brittish one would take 9 spaces (too long for PC filenames). Actually, British spelling is very useful - you can happily use colour as a variable even if color is a function :> > > I thought another thought for the breeding aspect. We ought to have the > total sum of the traits, make for a higher chance of drastic mutation. > That way as things dull out, due to better and better aliens, they also > mutate more and the offstring are less predictable...This might keep things > from getting stagnant.... We should also be constantly introducing new > aliens to replace those lost. > > The big question still remains, how do we measure 'winning' or if there's > no winning it, how does a player have some goal or measurement of their > success. Simcity has this aspect covered, we ought to at least either have > it be winnable, or have some sort of thing aside from the genetic > evoltution, to keep things interresting for the player...hmmmm.. I guess > we'll discuss this with the group... > > We ought to compile our results from these messages back and forth for the > group to see...sometime (probably after the survey stuff is all wrapped > up). > > When we get people divided into sub-groups, the code progression will go > like this, PC people will work on the PC Front End. Non PC programmers > will work on the Universe. AI/GA team will begin work on > designing the format and "methods to your madness" (to quote Hamlet > loosely), since this will take a while. Then when the bare-bones versions > of the PC-FE and the Universe, we can all swap code and then the AI/GA team > can get to work transfering their test-code and algorhythms into the game > environment to test it out in action. From there we (the directors) would > guide our teams towards improved modules in an efficient manner, with the > most important improvements first; trading code when at a break-point. > > The PC will be first, due to the fact that most all of us either have a > PC or have access to one, so it makes it the best for us to develop the > game on. Those without PCs would have to work on the Universe, participate > in the AI/GA discussion or work out general ideas and what not. > > With a good header-file, all of the functions should mix well with the > other modules flawlessly, but we must try to think of everything before- > hand, which will be tough. > > Even though I'm not a Genetic Evolution kinda guy, I think that my trait/ > gene scheme has potential...hmmmm...we'll see what other methods are > presented. > > > // Directors summary. > > This file is currently -very- messy, and much of the latter portion (the > header file) will be removed in the group version. I'd rather not have 25 > people posting -their- versions of the header file, it'd get messy. We will > have to work up the header file relatively on our own, discussing within our > groups, for which functions we'll need. > > This file, when completed, will call for everyone to join groups, and then > things will start to be dealt with within the sub-groups and general msgs > will become fewer... This way the sub-groups can focus on their particular > aspect of the game. > > Please add stuff and mark stuff for deletion etc. in this file, and mail > me your additions/subtractions etc. I'll patch all of our responses together > and remail them to you all for approval. Once we get an agreeable file > together I'll post it to the group. > > I want to get this sent, I've been typing long enough for one day. > (I doubt it's coherent at all...try to make some sense of it.) > > Try to get your revisions back to me soon, I want to get this to the group > soon, the natives are restless! > > -=GT=- > > From ???@??? Wed Nov 16 13:29:57 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA11298 for ; Wed, 16 Nov 1994 12:41:45 -0500 Received: from fred.cs.city.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7oJj-000fIsC; Wed, 16 Nov 94 09:38 PST Received: from strongbow.cs.city.ac.uk by fred.cs.city.ac.uk with smtp (Smail3.1.28.1 #14) id m0r7oIA-000645C; Wed, 16 Nov 94 17:37 GMT Date: Wed, 16 Nov 1994 17:37:10 +0000 (GMT) From: HARRIES K A To: Charles Ofria cc: alife-game@alnilam.krl.caltech.edu Subject: Re: Devils Advocate In-Reply-To: <9411161604.AA04748@altair.krl.caltech.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Nov 1994, Charles Ofria wrote: > Before I start ripping (or at least trying to) his ideas apart, I must say > that Kim makes some excellent arguments here, and most of his points in and > of themselves are quite valid. On a similar note I'd like to say that this response is just the kind of thing I was hoping for - it shows that Charles has an understanding of the possible problems that may occur for the project, and if someone has that I think you are far more likely to be successful. > > -- From: HARRIES K A > > [munch] > > > There is understandably a certain amount of euphoria in many peoples > > comments and suggestions, especially those concerning the most important > > aspect of the game: the evolving behaviour. > > > > Comments such as - > > "The beauty of ALife is that it can handle any level of complexity > > w/o a problem, but the humans making tanks (or whatever) will not be able to > > integrate as perfectly. The reason I especially like this is that a player > > will develop a type of tank with specific skills and drawbacks, and no > > matter what those drawbacks are, the alife *will* find them and use them." > > ... a somewhat paraphrase version of my comment I believe. - It was cut and pasted actually ;) , though I'm not sure who from... > > > You may find that the evolving critters aren't so good at finding a > > weekness niche as you'd like to think. Not that the wouldn't in the long > > run of course, but a game like this is gonna present such a noisey > > environment for learning in that it may be very difficult for evolution > > to get a grip. I know from experience that high hopes of evolving complex > > behaviour etc. can turn out to be too optimistic. If you look at the kind > > of behaviour that has been evolved in ALife to date you wont find > > anything as complicated as your group is talking about (in your more > > enthusiastic moments ;). Often what appears to be really clever behaviour > > in an ALife experiment turns out to be not so impressive when you read the > > actual details of the experiment. > > Well, I agree that evolving complex behaviors is an extrodinarily difficult > thing, but you must admit that *optimizing* complex behaviors is what > programs like this are best at. The way I see this working is that we are > going to seed the universe with working creatures and then let evolution > take over from there. Those behaviors which work best for specific locations > or against specific players will thrive and minor variations will optimize > them. I think that we will see the creation of occasional brand new > behaviors (both from unexpected mergings of old behaviors and spontaniously), > but not often enough to make the game fully playable. > This is precisely what I wanted to see - don't rely too heavily on evolution, it can be very slow and frequently get stuck in suboptimal states due to system dynamics if you are not careful. A helping hand or hearty kick up the backside in a project such as yours is nothing to be squemish about (though *would* be cause for concern if you were doing research!) > Side note: If you are interested, I can give you references to a good number > of papers where signifigant complex behaviors were evolved. > I would be interested, although I suspect that we may be referring to similar work. Do any of them show behaviour similar to that which you hope for? Larry Yaegers[?] PolyWorld for instance doesn't in my opinion. That is why I feel you may need more human intervention. References to more recent/better results would be appreciated though... > > Of course you have the big advantage of being able to 'cheat'. You do not > > have to show that your complex behaviour evolved from very simple basic > > moves, or without any human intervention etc. - If you come up clever > > evolving aliens in an ace game, who cares how it was done? > > The only 'cheating' that I see needed is to seed the universe with creatures. > In theory we could do this by simply running the program for a very long time > before we give it to the players, but I think that seeding it by hand is not > so far off. Even then I think we should run it for a short amount of time > before its ready to play. > I used the term 'cheating' rather cheekily. Seeding etc. is precisely the kind of thing I was referring to. I merely meant that compared to say producing a paper to convince ALife sceptics that 'intelligent' behaviour can be evolved in a reasonable time-span (in which case seeding would be viewed with great suspicion) there are many techniques available to you that should be exploited - all you want is results. > Having cheats beyond that ruins some of its appeal as an alife game - to > encourage traits which we think it should desire (rather than just offering > at the begining them an seeing if they take a hold on their own) will usually > inadvertantly discourage other things and potentially limit evolution in > unforseen ways. We've struggeled with this problem for a long time in avida > and discovered that the best way to breed programs which can carry out desired > algorithms is to just create a proper landscape where this helps the program > survive (in avida's case, increase the creatures CPU time). > I agree that built-in incentives can limit potential, but they may still be necessary for sufficiently rapid evolution - if you had to play the game a hundred times before significant beneficial traits appeared the evolving aspect of the game would be minimal. However, the incentives can be removed at a later date - or alternatively they could be subject to evolution themselves (an idea I'm toying with for CS type systems at the moment). Even if this didn't produce more effective aliens it might well produce more *interesting* ones - i.e. ones that have their own agenda for what they consider important. > > I have recently written a program which is currently attempting to learn > > a *VERY* simple game: Basically a two-planes-trying-to-shoot-each-other > > kind of thing. The only actions are fly straight, turn left, turn right, > > and shoot. The program is trying to evolve at set of simple production > > rules for playing this game by playing against itself in a tournament > > selection GA. Dead simple eh? Not so. The poor guys have been running for > > days now, and despite improvements in behaviour have not shown the > > expertise I hoped for. > > Again, for this example if you had started off with creatures that could play > the game, they would have optimized themselves nicely. We also have the > advantage that all rewards are instant for this game - if you shoot the > player you immediately get an additional x ammount of energy; It a more > realistic envirionment and thus better for evolution. > I have actually seeded my planes population with what I thought would be a simple successful strategy (always turn towards opponent and then keep firing). Most of the already partly evolved planes beat it, despite often simply flying straight and shooting all the time! However the new influx of useful rules into the population had the affect of greatly increasing the speed of development - exactly the kind of helping hand we have been talking about. I think there are still a number of 'loop-holes' to be removed, after all I only knocked it up in a few days the other week. I'll see how my darlings are doing when I get home tonight... > > The morale of this story is basically that your priority should be to get > > something simple working *soon*. From this you can learn what sort of > > difficulties you will be up against. Forget the poncy graphics etc., it's > > all been done before and can be grafted on at any point. > > This I can agree with whole-heartedly. Start with a basic game, and add > details in latter. For example, we don't need players to be able to build > their ships in the start; we can even start with a universe where all the > aliens have the same ships to control and just get some kind of controller > working. Heck, we don't even need them to evolve to begin with. Granted > this would be a very boring game, but at least it would be a basis to work > off of. That's the idea: start simple, build up. > > We should start writing up a set of immediate goals (as soon as we break up > into teams that is) of just what we need before we can have *something* > working. > > > Of course my planes labour under the great disadvantage (imposed by me) > > of only receiving payoff information of whether they win,lose or draw, > > i.e. no helping hints from the designer such as 'being behind opponent is > > good'. You need not impose such constraints, although the less specific > > information provided by you the more potential for surprising behaviour > > the aliens will have. > > In overall potential, this is not a big problem, it will simply cause you to > have to do more runs; even then it shouldn't be all that bad. If I creature > dies, it would have died in either case. The only problem I can see it > causing is that creatures need to be devoloped as a whole rather than one > behavior at a time. Perhaps what I should have pointed out was that there is probably some problem with the way that I chose to represent behaviour in the system such that although not impossible to design an effective set of rules it would be very difficult for them to evolve. Since each generation in the game takes up to half an hour it simply isn't true in a useful sense that more runs can solve the problem. I agree however that this is avoidable, but attention must be paid to getting a good system for behaviour that allows easy development and improvement, not just any old system. > > > One thing that learning systems and ALife experiment repeatedly > > demonstrate is their ability to find loopholes in what the programmers > > intended tasks were and those they actually set. Be sure that if the > > aliens can survive by running away and not fighting the player they'll be > > happy to do so! > > Ugh! Sometimes I think I'm spending my life patching said loopholes. Tell > me about it. Another good reason to start from a bare bones program and add > one feature on at a time so we can see when problems crop up immediately. > There is nothing worse than to have a creature taking advantage of a loophole > that you can't even find with looking at the creature. We'll still have > problems with unforseen results of combinations of additions, but there isn't > much we can do about that. > > > Also, although some of the responses to my point about any sensible player > > killing the tough aliens first look viable part of my point (badly made, > > no doubt :) was that it is all too easy to design a system whose dynamics > > are a knife-edge rather than a trough. In other words if you just make > > the aliens tougher in some way so that the player finds it tough just > > picking on the nasties, the outcome of the game may be determined by who > > gets on top in the crucial early stages rather than being a constant > > battle against gradually improving opposition. > > Another idea that just poped into my head is that we might also want to > somehow take into account the rate at which enemies cause damage to the player, > thus even if they are killed off quickly, this rating will be somewhat > acurate (or heck, it may even be too high if the player rushes up to the > creature taking an extra hit just to kill it quickly). > > > Well, that's enough scepticism for one day I think. Please don't get the > > wrong impression - I am very keen on your idea and hope to see it work. I > > wouldn't be raising so many questions if I thought for one moment it > > would put any of you off! > > > > Keep up the good work, > > > > Kim. > > Thanks for all the ideas Kim! I must say its gotten me thinking along > a number of interesting tracks. > > --- Charles > Talking of ideas I thought that seeing as I have had a purely negative tone so far I might throw in a few enthusiastic over-zealous ideas of my own :-) What about the notion of the aliens being GeneStealers in a very real way? If the behaviour patterns exhibited by the player are kept track of (need not be totally accurate etc.) then when an alien devours you it could choose to use some of _your_ genetic material when it next makes a child - you could find your own cunning tactics thrown right back at you! The player might well choose to self destruct rather than let his genes into the hands of the aliens...but then when is a hopeless situation truly hopeless? (Guess who is a Stephen Donaldson fan :) Actually mention of Donaldson (and his excellent Gap series - rush out and buy it now, even if you've already got a copy) makes me think why not make the plot a bit more involved than you standard shoot-em-up. Maybe you have to also protect friendly traders, supply routes etc. from the aliens - but if the aliens get hold of their Genes they can produce aliens that look like traders on the surface but are alien underneath. Hmmmm - maybe best to keep things simpler though. Anyway, more later, I've got some evolving to do right now, Kim. From ???@??? Wed Nov 16 14:10:40 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA21064 for ; Wed, 16 Nov 1994 13:33:54 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7pAL-000fIrC; Wed, 16 Nov 94 10:33 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id TAA15008 for ; Wed, 16 Nov 1994 19:31:37 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id TAA18559 for alife-game@alnilam.krl.caltech.edu; Wed, 16 Nov 1994 19:31:34 +0100 From: Martijn Faassen Message-Id: <199411161831.TAA18559@laurel.stud.phil.ruu.nl> Subject: Alife: Behaviour Code To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Wed, 16 Nov 1994 19:31:34 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3163 Charles and Kim, thanks for the excellent discussion on the possibilities and problems we face in creating this game. Keeping the game simple initially, and easily extendable is what I've been advocating since the start, that's why we've got the split into front end, universe, alife, and art/sound. Fancy graphics and all, that's the art/sound group, and front end, and the alife and universe people don't have to think about those, except if they want of course. It doesn't matter for the behaviour of the ship if the ship is texture mapping polygon whatever, though of course it does matter for the game, it has to look slick too. On the interface between the alife part and the universe, what about my 'virtual key' idea? In effect the aliens also have a 'keyboard' with keys they can press (functions they can call), which are exactly the same as the functions that get called when the player presses a real key. (except of course 'pause game' and 'toggle music' though we might create a 'wacky' option which actually lets the aliens press these keys too :) This way, it doesn't matter for the alien code which weapons are exactly available, the Universe team can simply add more weapons without bothering the Alife team. The more complicated part is the perception capabilities of the aliens. How can they look at other ships? Ideally the aliens should see exactly the same from their point of view as the player can see when looking at the screen, but this is naturally not very feasible. Thus, I've proposed making it possible for the aliens to see other objects (perhaps any objects within a certain range), their speed, orientation, distance and direction. ("Bogie at 12 o'clock, distance 5 miles captain, coming at us fast!") The alien should have some way to 'skip' through the different objects surrounding it, checking if it's good or dangerous, and determining its behaviour according to that. This should be an important consideration when designing the behaviour control code. The Behaviour Control Code (BCC) should also be evolvable, that is, being robust (shouldn't fall apart completely when a mutation happens, generally), executable in steps (for the timeslicing we *need* to implement in a real time game), combinable in some way (somekind of cross over to let advantageous behaviour spread through the alien population), and with good input/output. (for perception and 'key' pressing) And I'm sure others can come up with more requirements. This is a tough problem, and I'm still unsure what kind of representation is best suited for this (of course, as Charles say, we should remain open for other representations too, like neural nets, etc, but we should keep things basic in the beginning). Currently my ideas go into the direction of a heavily adapted Genetic Programming approach, possibly a list of different programs for each aliens, with some priority structure, or possibly different programs (genes?) activating each other. But, this is all very vague, and I'm open for everything. So, I'm hoping for everybodies input on this. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Wed Nov 16 14:24:45 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA29080 for ; Wed, 16 Nov 1994 14:17:43 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA34211; Wed, 16 Nov 1994 11:19:47 -0800 Date: Wed, 16 Nov 1994 11:19:47 -0800 (PST) From: Gregory Glen Taylor Subject: Re: The "IMPORTANT STUFF" initial draft, for directors only. To: Jeff Lait Cc: charles@krl.caltech.edu, g-j@chameleon.alt.za, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jeff's ideas are very good, I've got only one comment... TEXTUREMAPPING ROUTINES : These should definitely be handled by the front end for speed purposes. Since they will need to be done in real-time (most likely in some queue or cache split up between screen redraws). Jeff : You've got the FE-PC/X director spot as well. I'm seeking someone for the 'sound' portion of the art/sound group... Also the AI/GA group has been officially changed to the Alife group, minor change, but easier to say. 'Bye for now...-=GT=- From ???@??? Wed Nov 16 16:33:09 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA13536 for ; Wed, 16 Nov 1994 15:44:25 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7rAo-000fIrC; Wed, 16 Nov 94 12:41 PST Received: from rigel.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA07559; Wed, 16 Nov 1994 12:40:21 -0800 From: Charles Ofria Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/29Jun94-0757AM) id AA21641; Wed, 16 Nov 1994 12:40:18 -0800 Message-Id: <9411162040.AA21641@rigel.krl.caltech.edu> Subject: Re: Various... To: alife-game@alnilam.krl.caltech.edu Date: Wed, 16 Nov 1994 12:40:15 -0800 (PST) In-Reply-To: <9209021431.AA002yd@darkin.demon.co.uk> from "Christian Darkin" at Sep 2, 92 02:31:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4519 > I think the game might improve with some kind of what you call a fittness > function. I think that some things we want the creatures to select for > will not neccessarily be immediately beneficial to them. Eg, being > aggressive. We do want aggressive creatures, not ones that would rather > live together in peace and harmony. There needs to be some reward, > therefore that can be gained by attacking the player. This requirement goes without saying, but it doesn't need to be done with a fitness function. I think the way that has been decided on for the moment is to give the creatures and energy bonus if they successfully strike the player (and perhaps a smaller bonus if they attack each other.) > I also think that > evolution will be helped along if `fitter` aliens are more attractive to > their mates. This idea I really like - since we are going to use energy to encourage creatures, we can make creatures with more energy be more attractive. Actually, since we probably don't want to impose any hardcoded preferences on creatures, we can simply make the energy of other creatures visable to them, and thus those creatures which look for others with high energy will have a better chance of their own genes moving on successfuly (when mixed with these "good" genes). [munch] > My question is this; You say above that if you leave things `open ended` > then advanced behaviours like enslavement might evolve on their own. Surely > there is only the potential in any computer program to spit out what has > been put in in the first place. If you want something to have a chance of > happening, don`t you first need to give it the potential to happen? I mean, > if you don`t define what (for example) a sense of hearing is, then surely > the creature cannot independently find out? If you don`t define an ability > for one alien to control another, then it is no more likely to invent that > ability than it is to evolve the capacity to climb out of the screen? > > I`m sure you`re right in what you say. I`m sure there are ways to give > creatures that kind of open endedness. I just want to understand it.~:) You're absolutely correct, we must allow for the potential for the enslavement for it to somehow develop, I just don't like the idea of having something like an enslave command - its too unnatural. Perhaps communication would let this eventually develop (by creatures effectively telling each other what to do - or else), but I don't see such a thing developing in out lifetimes from such a simple system. I'd be interested to hear what ideas you have that will allow this without handing it to them. The best I can come up with is that bigger creatures could kill off the smaller ones that don't do what they want and effectively evolve its slaves. [munch] > I`m really excited by the way this is going, and I hope we can just keep > this momentum up. > > It also strikes me that if we`re putting into this some quite advanced > theory, we could also be creating a unique scientific experiment in alife. > Consider this: I don`t know what the true figures are, but say an average > game player plays our game for 1 hour a night for 3 months, and let`s say > we get the game published and get 250,000 users worldwide (not unlikely > considering the size of the games industry). If we could encourage data > (evolved creatures, etc) to be swapped around between players, and if we > could get feedback from the players about what is developing, as the game > is played, we effectively have 885 years of simulated evolution! That's whats now attracting me to it most! I think it has a *lot* of potential. Just in the idea that we might create a non-stagnating artificial eco-system would be a major accomplishment! > Has an experiment with alife ever been conducted on that kind of scale?? > > Christian. Not yet - Tom Ray is trying something like this with Tierra where systems around the world will be connected togeather as a "digital game reserve", but I'm not very ummm... entheusiastic about the results. In looking at the system he's using, I think that the brittleness of the instruction set he's using to make the creatures will slow down evolution more than the extreme paralelization will speed it up. Tom Ray's done some brilliant stuff in the past (heck, all of my work is based off of principles founded in Tierra), but I really think this one is going to flop. Note: I *do* hope that he will prove me wrong! --- Charles From ???@??? Wed Nov 16 16:33:29 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA15891 for ; Wed, 16 Nov 1994 15:58:29 -0500 Received: from iitbarr.iit.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7rOF-000fIrC; Wed, 16 Nov 94 12:55 PST Received: from iit.iit.com by iitbarr.iit.com (4.1/AI-4.10) id AA07068; Wed, 16 Nov 94 12:48:30 PST Received: from manila.iitengr by iit.iit.com (4.0/SMI-4.1) id AA25631; Wed, 16 Nov 94 12:52:37 PST Date: Wed, 16 Nov 94 12:52:37 PST From: brett@iit.com (Brett Coon) Message-Id: <9411162052.AA25631@iit.iit.com> To: alife-game@alnilam.krl.caltech.edu Subject: Re: Devils Advocate Kim> I seem to have fallen in to the role of Devils Advocate concerning the Kim> game. This is probably not such a bad thing because I cannot really make Kim> the commitment of getting involved in the coding/serious development (and Kim> I aint no expert at programming anyway), but I am very interested to see how Kim> the project continues. I'd like to join you in the Devil's Advocate position. I have also read many comments that I think are overly- optimistic and grandiose. When I first heard about this game, it sounded like Space Invaders with intelligent invaders. That sounded reasonable to me. But now, it seems as if the idea has exploded into something vastly more complex, which I think is just asking for disappointment. To my knowledge, nobody has ever successfully evolved computer opponents to a game even as simple as Space Invaders. I have trouble believing this is only because nobody thought of trying. I think it's because it is so hard to evolve behavior of even modest complexity, that any human player will learn counter-strategies at a superior rate and easily de- feat anything that evolves on its own. That's not to say that I think this is a waste of time. Evolving opponents is a cool idea, and would be a lot of fun to play with for people (like most of us) who are interested in genetic algo- rithms and artificial life. But to be realistic, I think the scope of the game should be extremely limited until we have proof that evolving more complex behavior is feasible. Consider the Genetic Programming experiments described in John Koza's book "Genetic Programming". Typical experiments in that book use populations of at least 500 members, for 30 to 50 gen- erations, just to evolve behavior to control a lawnmower or an ant as it follows a trail of food. Note that these behaviors are very simple, probably simpler than movement control of an alien, and certainly far simpler than much of what has been described in previous posts. Translated into aliens, that's a minimum of about 500*30 = 15,000 aliens. The experiments from the book typ- ically evaluate each individual on several "fitness cases", so the genetic operators have fairly accurate fitness information for _every_ individual with which to work. In the game environ- ment, aliens will often get shot before they have had a chance to do anything useful, and thus their fitness will not yet be accu- rately determined. So we will effectively need even more aliens to get the same behavioral complexity to evolve. At a minimum, you might create 3 aliens under the control of each evolved pro- gram, and use the combined scores of all three aliens as a meas- ure of the fitness of that control program. This would increase the alien requirements to 45,000. That's a lot of aliens. Addi- tional complexity tends to _exponentially_ increase the popula- tion sizes you need, so this number explodes as you ask more and more from the evolved algorithm. My point is that I don't think behavior of the complexity I have seen described here (laying eggs, enslaving other aliens, using power-ups, etc) will evolve at a rate that would make the game interesting. Isn't anyone satisfied with just Space Invaders? Other comments: I think trying to make money from the game is a bad idea. Get- ting interesting behavior evolved hinges on being able to run huge numbers of simulations, which in turn requires lots of peo- ple to play the game. Charging money just reduces the number of people who might play it. There must be safeguards of some sort (either explicit or just factors in the fitness evaluation) that prevent certain unwanted behaviors from evolving. For example, we probably don't want meek aliens that run or hide, and we also don't want large groups that storm the player and are impossible to defeat. If the alien control and evolution is encapsulated into separate modules, it should be trivial to have a non-evolving, hand- generated-opponents version of the game. This would also make it easy for completely different evolutionary approaches to be tried, such as the low-level evolve-everything approach vs the higher-level approach that just mixes and matches canned actions. -Brett +------------------------------------------------------------+ | Brett Coon - brett@iit.com or brettc@leland.stanford.edu | | Integrated Information Technology Inc. (408) 654-0936 | +------> finger brettc@leland.stanford.edu for PGP key <-----+ From ???@??? Wed Nov 16 17:02:46 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA21466 for ; Wed, 16 Nov 1994 16:34:26 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7rkR-000fIrC; Wed, 16 Nov 94 13:18 PST Received: from rigel.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA07801; Wed, 16 Nov 1994 13:17:10 -0800 From: Charles Ofria Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/29Jun94-0757AM) id AA21692; Wed, 16 Nov 1994 13:17:07 -0800 Message-Id: <9411162117.AA21692@rigel.krl.caltech.edu> Subject: Energy and such... To: alife-game@alnilam.krl.caltech.edu Date: Wed, 16 Nov 1994 13:16:53 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3042 Greetings, So, I added all of the new names that people sent me to the mailing list - please e-mail me back if your name is incorrectly on the list. I'll also place a copy of the mailing list in the ftp site unless anyone has objections to that. Onto the topic of the letter - I'm just going to present a few of my ideas on how we should use energy in the game: At the begining of the game, all creatures start with a fixed amount of energy. After that, when a creature lays an egg, it has to put a certain amount of energy into it. As time goes on, the egg slowly loses energy. If ever the egg runs out of energy (ie. it doesn't get fertilized in time), the creature inside of it dies. If another creature does come along and fertilizes the egg, then it also can add more energy to it if it chooses. A set (short) amount of time after an egg is fertilized, it hatches. Also note that creatures should be able to see how much energy is in an egg in making their choice to fertilize or not - they may want to only fertilize eggs with a lot of energy so they don't have to add their own. Then again, they may want to just eat eggs with a lot of energy. :-) Now, here are a few ways for a creature to spend energy: Doing nothing - energy drains (at a very slow rate) in time. Using thrust - proportional to the amount of thrust used. (should it be more than that? Perhaps square of thrust so that creatures use thrust over time, and don't just jump to the speed they want?) Turning - again very minimal Shooting - creatures control how much energy they put into each shot. One big one might do more damage, but its also more of a waste if it misses. Also its a waste if it overkills. Smaller ones take more time to get enough off. Creatures have to work out there own system for this. Also there may be different types of weapons. If we want them to bread their own, we can simply have various feature multiply the cost by a set amount. Getting shot - I'm not sure about this one - are the creatures going to have a seperate armor? If so we might still want them to lose a small amount of energy if they get shot... Creatures gain energy by: shooting another creature - I'm thinking that perhaps this should be based on how different the two creatures are, with the player being maximally different from all others. This encourages creatures of the same type to work togeather rather than cause their own extinction. Wouldn't it be neat to develop collective behaviors... eating a power source or an egg - the environment should naturally grow power sources for the creatures. Thus some types of creatures would be benevolent only wanting to eat these "space plants". It would be easy to ensure that there is no way for these sources to power all of the creatures, so they still would end up resorting to carnivorism... I think that should be it unless anyone else has other ideas. I just wanted to lay these down (most of them have been talked about) clearly... Sound good? --- Charles From ???@??? Wed Nov 16 17:02:49 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA23215 for ; Wed, 16 Nov 1994 16:46:02 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7s5Q-000fIrC; Wed, 16 Nov 94 13:40 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id WAA18711 for ; Wed, 16 Nov 1994 22:38:39 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id WAA21321 for alife-game@alnilam.krl.caltech.edu; Wed, 16 Nov 1994 22:38:36 +0100 From: Martijn Faassen Message-Id: <199411162138.WAA21321@laurel.stud.phil.ruu.nl> Subject: Re: Devils Advocate To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Wed, 16 Nov 1994 22:38:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8574 Forwarded message: > From brett@iit.com Wed Nov 16 22:00 MET 1994 > Date: Wed, 16 Nov 94 12:52:37 PST > From: brett@iit.com (Brett Coon) > Message-Id: <9411162052.AA25631@iit.iit.com> > To: alife-game@alnilam.krl.caltech.edu > Subject: Re: Devils Advocate > Content-Type: text > Content-Length: 4580 > > Kim> I seem to have fallen in to the role of Devils Advocate concerning the > Kim> game. This is probably not such a bad thing because I cannot really make > Kim> the commitment of getting involved in the coding/serious development (and > Kim> I aint no expert at programming anyway), but I am very interested to see how > Kim> the project continues. > > I'd like to join you in the Devil's Advocate position. > > I have also read many comments that I think are overly- > optimistic and grandiose. When I first heard about this game, it > sounded like Space Invaders with intelligent invaders. That > sounded reasonable to me. But now, it seems as if the idea has > exploded into something vastly more complex, which I think is > just asking for disappointment. To my knowledge, nobody has ever > successfully evolved computer opponents to a game even as simple > as Space Invaders. I have trouble believing this is only because > nobody thought of trying. I think it's because it is so hard to > evolve behavior of even modest complexity, that any human player > will learn counter-strategies at a superior rate and easily de- > feat anything that evolves on its own. That's possible. That's why we'll probably need to 'seed' the game with already fairly 'smart' aliens. We don't know though. (I haven't heard of any tries, I know I thought of trying, but I never got around to it till now :) > That's not to say that I think this is a waste of time. Evolving > opponents is a cool idea, and would be a lot of fun to play with > for people (like most of us) who are interested in genetic algo- > rithms and artificial life. But to be realistic, I think the > scope of the game should be extremely limited until we have proof > that evolving more complex behavior is feasible. The scope of the game, though many ideas are of course brought forward, isn't that complicated if you strip it to the basic essentials. Plus, wasn't it Simon who said something about ants behaving in complicated ways because their environment was complicated? Of course we'll keep the game simple at the start, and later extend it if it seems feasible. I don't think anybody ever said anything else. (though of course the graphics and the sounds may be complicated, that's another area though) > Consider the Genetic Programming experiments described in John > Koza's book "Genetic Programming". Typical experiments in that > book use populations of at least 500 members, for 30 to 50 gen- > erations, just to evolve behavior to control a lawnmower or an > ant as it follows a trail of food. Note that these behaviors are > very simple, probably simpler than movement control of an alien, > and certainly far simpler than much of what has been described in > previous posts. Translated into aliens, that's a minimum of > about 500*30 = 15,000 aliens. The experiments from the book typ- > ically evaluate each individual on several "fitness cases", so > the genetic operators have fairly accurate fitness information > for _every_ individual with which to work. In the game environ- > ment, aliens will often get shot before they have had a chance to > do anything useful, and thus their fitness will not yet be accu- > rately determined. So we will effectively need even more aliens > to get the same behavioral complexity to evolve. At a minimum, > you might create 3 aliens under the control of each evolved pro- > gram, and use the combined scores of all three aliens as a meas- > ure of the fitness of that control program. This would increase > the alien requirements to 45,000. That's a lot of aliens. Addi- > tional complexity tends to _exponentially_ increase the popula- > tion sizes you need, so this number explodes as you ask more and > more from the evolved algorithm. It would depend on the replacement rate of the aliens and the total amount of aliens the game can manage at the same time. If we can get those two large enough 45,000 aliens might be reachable in playable time. Plus, as was said before, we can cheat and put in more complex aliens from the start, too. Example: if we can run 450 (feasible? I don't know..maybe not at all) aliens at the same time and the replacement rate at a speed of all aliens replaced by new ones once every 20 minutes (again, feasible?) then it would take 45,000/450 * 20 = 2000 minutes = about 33 hours of playing time. That's not too excessive, if the game is fun to play (and has a save game option:). Then again, this is all pure magic with numbers, because we just don't know how fast evolution will go in this system, including shortcuts, maybe slowed down again by big complexity. I'm sure someone else can manipulate the numbers such that it'll become totally impossible again. Be my guest. :) > > My point is that I don't think behavior of the complexity I have > seen described here (laying eggs, enslaving other aliens, using > power-ups, etc) will evolve at a rate that would make the game > interesting. Isn't anyone satisfied with just Space Invaders? The enslaving is probably not feasible to reach without some heavy predefined coding. Finding food (power ups) or laying eggs isn't that complicated however, in my opinion. Now, egg guarding behaviour and things like that might be more complicated! > Other comments: > > I think trying to make money from the game is a bad idea. Get- > ting interesting behavior evolved hinges on being able to run > huge numbers of simulations, which in turn requires lots of peo- > ple to play the game. Charging money just reduces the number of > people who might play it. Everybody seems to have different goals with this game. I think we should keep in mind that the main goal is to make a fun game using these new techniques, all else is an extra. (which doesn't mean we shouldn't try to get the extra's of course :) I think it's not very useful going into a 'make money or not' discussion now while we don't got anything but a bunch of ideas. Plenty of time for such a discussion later. (although I can't refrain from mentioning that there is nothing wrong with making money..making the game is more important than that though!) > > There must be safeguards of some sort (either explicit or just > factors in the fitness evaluation) that prevent certain unwanted > behaviors from evolving. For example, we probably don't want > meek aliens that run or hide, and we also don't want large groups > that storm the player and are impossible to defeat. > I'd love to see aliens running and hiding, and then the human player hunting them down and killing them. I'd also love to see large groups of aliens storming the poor unsuspecting player. :) That's what's *different* about this game! Not this all powerful human player who destroys thousands of aliens without getting scratched, no, actually cunning aliens who get back at the player! This is this first generation of really strategic arcade games, to get all hyped up again. :) > If the alien control and evolution is encapsulated into separate > modules, it should be trivial to have a non-evolving, hand- > generated-opponents version of the game. This would also make it > easy for completely different evolutionary approaches to be > tried, such as the low-level evolve-everything approach vs the > higher-level approach that just mixes and matches canned actions. Agreed! We should definitely keep the game open for this. A nice intermediate might be hand coded higher level aliens which evolve optimizations. > > -Brett > > +------------------------------------------------------------+ > | Brett Coon - brett@iit.com or brettc@leland.stanford.edu | > | Integrated Information Technology Inc. (408) 654-0936 | > +------> finger brettc@leland.stanford.edu for PGP key <-----+ > Thanks for your input, I'm sure we did need some devil's advocates to restrain our ideas from getting too wild. It's all talking in the dark right now, we just don't know what the game will turn out to be. (though we will of course try to make it turn out to be as good as possible) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Wed Nov 16 17:04:59 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id QAA25280 for ; Wed, 16 Nov 1994 16:59:52 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7sLQ-000fIrC; Wed, 16 Nov 94 13:56 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id WAA18962 for ; Wed, 16 Nov 1994 22:55:18 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id WAA21636 for alife-game@alnilam.krl.caltech.edu; Wed, 16 Nov 1994 22:55:15 +0100 From: Martijn Faassen Message-Id: <199411162155.WAA21636@laurel.stud.phil.ruu.nl> Subject: Re: Energy and such... To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Wed, 16 Nov 1994 22:55:15 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5503 Charles writes: > Greetings, > > So, I added all of the new names that people sent me to the mailing > list - please e-mail me back if your name is incorrectly on the list. I'll > also place a copy of the mailing list in the ftp site unless anyone has > objections to that. > > Onto the topic of the letter - I'm just going to present a few of > my ideas on how we should use energy in the game: > > At the begining of the game, all creatures start with a fixed amount of > energy. After that, when a creature lays an egg, it has to put a certain > amount of energy into it. As time goes on, the egg slowly loses energy. > If ever the egg runs out of energy (ie. it doesn't get fertilized in time), > the creature inside of it dies. If another creature does come along and > fertilizes the egg, then it also can add more energy to it if it chooses. > A set (short) amount of time after an egg is fertilized, it hatches. I wonder, a hatched alien, how much energy will it have? As much as was in the egg? Some amount dependent on how much it invested in it? (following my percentage 'money' investment scheme, each alien gets a fixed amount of money which it can invest in configuration, among which is starting energy.. hmm..maybe not let it be a fixed amount of money but an amount dependent on the amount of energy in the egg..this would make a more natural mechanism to get 'boss' aliens..I suppose we should include all options as things the player can turn on and off in the game, that wouldn't be too hard to do once we get the basic game running) > Also note that creatures should be able to see how much energy is in an > egg in making their choice to fertilize or not - they may want to only > fertilize eggs with a lot of energy so they don't have to add their own. > Then again, they may want to just eat eggs with a lot of energy. :-) Wonderful, prisoner's dillema like problems. :) I wonder if we'll get to see evolutionary stable system phenomena and such. > Now, here are a few ways for a creature to spend energy: > > Doing nothing - energy drains (at a very slow rate) in time. > Using thrust - proportional to the amount of thrust used. (should it be > more than that? Perhaps square of thrust so that creatures use > thrust over time, and don't just jump to the speed they want?) > Turning - again very minimal > Shooting - creatures control how much energy they put into each shot. One > big one might do more damage, but its also more of a waste if it > misses. Also its a waste if it overkills. Smaller ones take more > time to get enough off. Creatures have to work out there own system > for this. Also there may be different types of weapons. If we want > them to bread their own, we can simply have various feature multiply > the cost by a set amount. Right, maybe 'range' and 'size of onboard program' influence the energy cost of the weapons. > Getting shot - I'm not sure about this one - are the creatures going to have > a seperate armor? If so we might still want them to lose a small > amount of energy if they get shot... I think currently we have: - usable energy (which is what we're talking about here) - armour energy (when it reaches 0 the ship is destroyed) When the alien configures the ship using the money scheme, it can invest a part of its money in both things (among the many other things it might invest in..many different configuration strategies are hopefully possible!). Armour energy shouldn't decay, I think, but only decrease when hit. Perhaps we can let the aliens transfer usable energy to armour energy (and back?). When hit the alien might also loose some usable energy (another option the player can turn on and off? I'd love to fiddle with this..interface builders, make you sure you implement nice option windows or whatever :) > Creatures gain energy by: > > shooting another creature - I'm thinking that perhaps this should be based on > how different the two creatures are, with the player being maximally > different from all others. This encourages creatures of the same type > to work togeather rather than cause their own extinction. Wouldn't > it be neat to develop collective behaviors... That would be interesting, though it might be difficult to determine the difference. This could also evolve of course, it's obviously not very advantagous for a gene if it makes the alien should its relatives (which also might possess that gene). So, maybe this difference thing should be an option again. :) Perhaps we could make this whole thing an option, if we make eating dead aliens give energy instead. > eating a power source or an egg - the environment should naturally grow > power sources for the creatures. Thus some types of creatures would > be benevolent only wanting to eat these "space plants". It would be > easy to ensure that there is no way for these sources to power all of > the creatures, so they still would end up resorting to carnivorism... > Eating dead hulks of aliens or the player. Getting hit by 'energy donation bullets'. (maybe option if we allow these :) Vampiristic (energy sucking) bullets might be interesting too. Not part of the basic game however. > I think that should be it unless anyone else has other ideas. I just wanted > to lay these down (most of them have been talked about) clearly... Sound > good? Sounds fine! > > --- Charles Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Wed Nov 16 17:20:52 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA27092 for ; Wed, 16 Nov 1994 17:11:03 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7sXT-000fIsC; Wed, 16 Nov 94 14:09 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA49403; Wed, 16 Nov 1994 14:08:49 -0800 Date: Wed, 16 Nov 1994 14:08:49 -0800 (PST) From: Gregory Glen Taylor Subject: Re: Various... To: Robert Elsner Cc: Christian Darkin , alife-game@alnilam.krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Let's get a -game- somewhat close to production levels before we begin to discuss the Shareware vs. Commercial aspects...We need a product to sell before we can think about selling it. -=GT=- From ???@??? Wed Nov 16 18:10:50 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id RAA04043 for ; Wed, 16 Nov 1994 17:55:56 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7tEm-000fIrC; Wed, 16 Nov 94 14:54 PST Received: from rigel.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA09181; Wed, 16 Nov 1994 14:52:35 -0800 From: Charles Ofria Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/29Jun94-0757AM) id AA21783; Wed, 16 Nov 1994 14:52:34 -0800 Message-Id: <9411162252.AA21783@rigel.krl.caltech.edu> Subject: Re: Devils Advocate To: alife-game@alnilam.krl.caltech.edu Date: Wed, 16 Nov 1994 14:52:33 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 10379 *sigh* I think I should just give up on trying to respond to all of these - I'm getting far too behind.... Oh, one note about the ftp site. There is an alife directory in addition to the alife-game directory. The alife directory is not part of this game in any way - its for the real work that we're doing here (on the other hand, if anyone is interested in that work, fell free to pick up copies of our papers!) On to the reply... > > I have also read many comments that I think are overly- > > optimistic and grandiose. When I first heard about this game, it > > sounded like Space Invaders with intelligent invaders. That > > sounded reasonable to me. But now, it seems as if the idea has > > exploded into something vastly more complex, which I think is > > just asking for disappointment. To my knowledge, nobody has ever > > successfully evolved computer opponents to a game even as simple > > as Space Invaders. I have trouble believing this is only because > > nobody thought of trying. I think it's because it is so hard to > > evolve behavior of even modest complexity, that any human player > > will learn counter-strategies at a superior rate and easily de- > > feat anything that evolves on its own. > > That's possible. That's why we'll probably need to 'seed' the > game with already fairly 'smart' aliens. We don't know though. > (I haven't heard of any tries, I know I thought of trying, but > I never got around to it till now :) Having read many of the papers on the project mentioned, I must point out that we are using very different techniques from them. It all depends on how complex the world is, and how plastic the creatures code is. If we were going to start out with simply random creatures, the chance for them to form something worthwhile is quite slim, and thus the genetic environment is too difficult to navigate through; the fitness landscape is mostly flat so mutations only cause a random walk across the landscape until something useful is found - which may take an extremely long time. On the other hand, since we seed the soup (sorry - term I keep using after working with tierra) with initial creatures, we start them off in an interesting portion of the landscape where they are capable of actually moving uphill. Aditionally, I will make sure that the "language" the creatures are in is sufficuiantly plastic so that creatures can survive a larger percentage of the mutations they face. I've had a lot of experience in designing instruction sets for avida (which is one of the reasons it has a signifigantly fast rate of evolution than tierra). > > That's not to say that I think this is a waste of time. Evolving > > opponents is a cool idea, and would be a lot of fun to play with > > for people (like most of us) who are interested in genetic algo- > > rithms and artificial life. But to be realistic, I think the > > scope of the game should be extremely limited until we have proof > > that evolving more complex behavior is feasible. > > The scope of the game, though many ideas are of course brought forward, > isn't that complicated if you strip it to the basic essentials. > Plus, wasn't it Simon who said something about ants behaving in complicated > ways because their environment was complicated? > > Of course we'll keep the game simple at the start, and later extend it > if it seems feasible. I don't think anybody ever said anything else. > (though of course the graphics and the sounds may be complicated, that's > another area though) I completely agree - as we add in new features one at a time, we will have a chance to fully deal with how they impact the game. [munch on debate over population sizes] > Then again, this is all pure magic with numbers, because we just don't know > how fast evolution will go in this system, including shortcuts, maybe > slowed down again by big complexity. Right - its not possible for us to know good numbers for this since its a new kind of system of its own - certainly not a genetic algorithm. Creatures in genetic algorithms are killed off each update, and then replicated if they were successful. In this game, creatures simply survive and reproduce if they are successful with no artificial mechanism in between. A truely successful creature could live for a very long time, while in a genetic algorithm it would have been counted as a new creature each update. Living systems such have this are better at devising "undetermined" complex behaviors, while genetic algorithms are better for causing a specific behavior to be created. We don't need (or want!) the restriction of funneling it towards a specific behavior. > I'm sure someone else can manipulate the numbers such that it'll become > totally impossible again. Be my guest. :) Sure, if you really wany me too. :-) Lets see... in an average avida run we use about 1600 creatures in the soup, and it takes upwards of 800 updates to learn a simple task like addition.... (yes I'm leaving out lots of facts here... like creatures are not killed off during updates, and the system processes updates in minimal time - 800 is under a half hour). Any system that you can come up with, though, I'm sure I can come up with a very convincing argument against. I think for something of this nature we should just wait and see what we encounter. Very few problems will not be able to be overcome.... > > My point is that I don't think behavior of the complexity I have > > seen described here (laying eggs, enslaving other aliens, using > > power-ups, etc) will evolve at a rate that would make the game > > interesting. Isn't anyone satisfied with just Space Invaders? > > The enslaving is probably not feasible to reach without some heavy > predefined coding. Finding food (power ups) or laying eggs isn't that > complicated however, in my opinion. This has been done in minimal time in many systems.... both finding food and mating. > Now, egg guarding behaviour and things like that might be more complicated! That would be *very* nice. > > Other comments: > > > > I think trying to make money from the game is a bad idea. Get- > > ting interesting behavior evolved hinges on being able to run > > huge numbers of simulations, which in turn requires lots of peo- > > ple to play the game. Charging money just reduces the number of > > people who might play it. > > Everybody seems to have different goals with this game. I think we should > keep in mind that the main goal is to make a fun game using these new > techniques, all else is an extra. > (which doesn't mean we shouldn't try to get the extra's of course :) > > I think it's not very useful going into a 'make money or not' discussion > now while we don't got anything but a bunch of ideas. Plenty of time for > such a discussion later. (although I can't refrain from mentioning that there > is nothing wrong with making money..making the game is more important than > that though!) Agreed completely. Money making would become an unweildy prospect at the moment, especially with so many people involved... > > There must be safeguards of some sort (either explicit or just > > factors in the fitness evaluation) that prevent certain unwanted > > behaviors from evolving. For example, we probably don't want > > meek aliens that run or hide, and we also don't want large groups > > that storm the player and are impossible to defeat. > > > I'd love to see aliens running and hiding, and then the human player > hunting them down and killing them. I'd also love to see large groups > of aliens storming the poor unsuspecting player. :) That's what's *different* > about this game! Not this all powerful human player who destroys > thousands of aliens without getting scratched, no, actually cunning aliens > who get back at the player! > This is this first generation of really strategic arcade games, to get > all hyped up again. :) Again, completely agreed! One thing that we should stress in the environment is that if all the creatures are acting the same way, then it would be easy for other creatures to take advantage of this. For example, if they all run and hide, they will run out of food sources, so only those going out to seek them will survive. If they all hunt for food, they will kill each other off (running out of food) so only those who eat natural sources can survive. I want a *lot* of situations like that in the long term. Recently I was at an artificial life retreat with people from UCLA and UC San Diego (and I think a few other people from other places in southern California) and I presented a model for avida which I am working on to develop an eco-system in a similar fashion. Although they liked the general idea of an real eco-system forming, what they liked most was the fact that this encouraged all creatures of the same species to act slightly different from each other. Some of the Alife professors there thought that this was one of the best things they'd ever seen in alife for that simple reason. I think this game will demonstrate that a bit more. I'm going to hold back for a while before I give a full alife analysis about it, until we have more developed. At that point there are also a number of other people here I'd like to show it to... > > If the alien control and evolution is encapsulated into separate > > modules, it should be trivial to have a non-evolving, hand- > > generated-opponents version of the game. This would also make it > > easy for completely different evolutionary approaches to be > > tried, such as the low-level evolve-everything approach vs the > > higher-level approach that just mixes and matches canned actions. > > Agreed! We should definitely keep the game open for this. A nice intermediate > might be hand coded higher level aliens which evolve optimizations. Agreed here too - I was actually suggesting something quite similar earlier. > Thanks for your input, I'm sure we did need some devil's advocates to > restrain our ideas from getting too wild. It's all talking in the dark > right now, we just don't know what the game will turn out to be. (though > we will of course try to make it turn out to be as good as possible) *yawn* it is useful, but I think I'm getting a bit tired right now to reapond to any more... --- Charles From ???@??? Wed Nov 16 18:49:45 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA12472 for ; Wed, 16 Nov 1994 18:42:10 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA37178; Wed, 16 Nov 1994 14:45:20 -0800 Date: Wed, 16 Nov 1994 14:45:20 -0800 (PST) From: Gregory Glen Taylor Subject: The Important Stuff To: Alife_game_directors , g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've thought about it and I plan on splitting the important stuff file into two seperate msgs: Game Design Specs 1 : Mostly what the Important Stuff file is that I sent out last night. Describes each group and the organization of the project. The Questions 1 : This file will include all of the current game options and methods. It will also clear up the already decided things (like -no 3d- or -Realtime Raytracing-). These files will serve two distinct purposes. The first will describe the structure of the project and give people a feel for where they belong etc. The second will get the group discussing the important stuff for right now. Currently I see a lot of bickering about exact methods of Alife, and no particular methods are being discussed. With a file outlining the various methods, pros and cons, etc. it would facilitate a more efficient groups discussion, and we could point them to specific topics we (the directors) want them to discuss. The first file will be basically what the 'IMPORTANT STUFF' file contained, but hacking out the various methodologies on Alife and focus more on the -structure- of the game. The second file I will begin work on in a few minutes. It will take some of the most popular methods and questions/problems and attempt to counterpoint them and lay them out in a reasonable, informative manner. Sort of like a 'Voter Information Guide' for those of us who have such. I'll send initial drafts of both files later today for your editing and additions. Please do as complete job as you can in addressing as many pros/cons and new ideas as possible, and also try to do it quickly, so that I can get all of your revisions compiled and ready for the group in a timely fashion. These files are urgent and I want to get them to the group quickly, so a quick-response from the directors would definitely assist in that. Thanks guys......More later-=GT=- From ???@??? Wed Nov 16 20:12:47 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id UAA23841 for ; Wed, 16 Nov 1994 20:03:42 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA97191; Wed, 16 Nov 1994 17:05:53 -0800 Date: Wed, 16 Nov 1994 17:05:51 -0800 (PST) From: Gregory Glen Taylor Sender: Gregory Glen Taylor Reply-To: Gregory Glen Taylor Subject: PROJECT STRUCTURE #1 To: AI Game Design Team , g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2126430457-2078917053-785034351:#39711" I mentioned in an earlier post that I will be splitting the 'IMPORTANT STUFF' file into two specific files. The first of which is finished. Please note that it is mostly what was included in the I.S. file, with some minor additions/deletions for clarity. Before I post it, I want feedback on it, more specifically: for those of you who -have- sub-groups that you are directing, please revise your sub-group description section. Also comments on other groups are welcome. I want this document to be clear, concise, and as complete as possible. The purpose of it is to call for the beginning of sub-group formation. As directors, you should be beginning to synthesize how you want to organize your group. Please prepare a file, in the next week or so, that describes your group in greater detail, describes the positions needed and what they require, and such. Also include in that file a summary of your attack plan for the group...what to do first, and how to go about it. It would be wise to send a copy of this 'syllibus' (to use the college terminology) to the other directors as well, so they are familiar with how you plan on directing your group. There will be a number of mailing lists...(if Charles can set them up for us...of course. Otherwise we'll have to do it the caveman way we were doing before...) General - Everyone on the project, will include only those who are in one or more subgroup. Directors - Us. We'll discuss compatibility and such between our seperate groups. FE-PCX - PC-Mode X front end group. FE-MAC - Mac front end group. FE-AMIGA - Amiga front end group. FE-?? - etc. Universe - The universe group. Alife - The alife group. Art-Sound - the Art/Sound group. Spectators - The testers and people who never joined a subgroup. this group will be for people who'd rather just keep informed on the game, but not actually -do- anything about it. That's a lot of Mailing-Lists. I hope that the auto-bouncer thing doesn't require too much upkeep, or I'm asking too much of Charles. BTW thanks to Charles for managing the info stuff, FTP and Mailing lists will help this project be more efficient. On the subject of FTP. We should send all of our -code- for our specific groups thru the 'Directors' group, to preserve security. We need to guard the security of the code as much as possible, just in case we decide upon a commercial marketing for it. The directors of each group would then send the -code- to the appropriate people within the group (most likely most of them, but the Alife group may have some onlookers who won't really have need of the code, etc.) The FTP site should be used to hold standard files, like the Project Structure outline (attached) and the other file I hope to send later tonight. It will also be a storage place for morph.zip (I tried it,good work Jeff!), the 'survey', the survey response files, and other important msgs as they come up. This way people who are interrersted in joining the project can simply download the valid info. The other files on the FTP should be the non-code portions of the game, which cannot be passed via email. Without the code, the image, sound, and other such non-code files are rendered essentially useless. With the code going thru email and the other files on the site, we can preserve a decent level of security, since I doubt Charles can lock the site to allow only project members to access the info. I'll type more later, for now read the attached file and revise it, and re-mail it to me soon. I'd like to get it to the group tomorrow if possible. Thanks...-=GT=- Content-Type: TEXT/PLAIN; charset=US-ASCII; name="alife_ps.001" Content-ID: Content-Description: The PROJECT STRUCTURE #1 file, initial draft. =-=-=-=-=-=-=-=-=-=-=-= - Project Structure - =-=-=-=-=-=-=-=-=-=-=-= This file attempts to outline the structure of the project and how the various sub-groups will be split. It describes each of the sub-groups and what their main function/goal is. Once the sub-groups are set up, the director of each group will send a file detailing the group's aims and goals in greater detail. The discussion thus-far has been mostly on a group-level, with everyone throwing ideas out into the group. This has been a good method for generating a basic outline of what the game will entail. Now that we've gotten that and since the group has grown much larger, it is necisary that we split into sub-groups to discuss the game. Most of the discussion from this point on should be conducted within the sub-group that it pertains to. The directors of the groups will discuss compatibility issues between the groups. In most cases the director will discuss new functions that are needed or the like with other group directors, rather than an individual posting in another group. The directors are a form of middle-management. The will be a group's link to the rest of the project. Only on rare occations will there be group msgs, most things should be discussed in groups. Also, directors are the boss in the group. They will direct how and what will be coded. How a director sets up their sub-group is completely up to them. If you have complaints about how a director is handling things in a group, please post a msg to me (gtaylor) concerning it (but I doubt this will be necisary). This file outlines the various sub-groups and their basic design. It also lists the current directors for each sub-group. If you plan on remaining on the project you must join at least one sub-group. (it is preferred that you not join more than 2). The director will split the work load up amongst the various members according to their desires as well as the skills each member has. How to join a sub-group ----------------------- email : gtaylor@oboe.aix.calpoly.edu with the Subject as 'SUB-GROUPS' then the body of the message will contain a brief list of one or more groups you'd like to join. Please don't waste your time detailing the -exact- role in the group that you'd like to play, tell that to the group director, later. Soon, mailing lists will be set up for the various sub-groups and the directors will send a msg detailing their plan of attack. ---------------- - Universe.h - ---------------- Director : Greg Taylor - gtaylor@oboe.aix.calpoly.edu The header file for the game outlines the parameters and names of all of the global functions. This way all of the functions in the various sections of code will be able to call functions in other sections of code (ie the Universe can call Front-End routines). The code can then be worked on independently, and the other groups will know how to access and what data to send to the external routines. This will keep compatibility high and re-coding to a minimum. The key to a sucessful Universe.h is a -complete- function list which has all or nearly all of the global functions and variables that will need to be accessed by the other groups; because adding forgotten functions will mean work for -all- of the groups...which could possibly be avoided. *********** SUB-GROUPS ************ ---------------- - Front Ends - ---------------- FE-PC/X Director : Jeff Lait - jmlait@undergrad.math.waterloo.ca FE-Mac Director : Mike Mitchener - st944m5h@post.drexel.edu FE-Amiga Director: This section of the code is the only machine/compiler specific code. It may be coded in assembly, or whatever the FE team deems they'd like to do. The only restrictions is that it must be accessable by the C header file (universe.h), so the functions must be written so that they will be able to be accessed through those defines... It will include : Graphics: Setting the mode, sprite manipulation, fonts, and a 'movie' displayer that will display our standard intro and plot sequences (we'll develop a standard .mov file which will have various pictures and sounds/music in a sequence). Compile: Routines to compile 24bit-colour pictures into the specific size and color-number for that Front-End. The original ART/SOUND .mov files will have 640x480x24bit, this will need to be reduced to a machine specific .mov file. Sound: Playing midi files or mods (not sure yet) also sound efx, will have to work closely with the Art/Sound team in order to implement their ideas effectively. Control: Keyboard caching (grabbing multiple chars if multiple are pressed, ie turn+acc+fire), joystick control, mouse control etc. Timer: A function which will allow us to have a local variable passed to it updated every screen-redraw. Allows us to determine how far ships accelerate, etc. The sound is still in question for which file formats it will use, most likely midi's or mods to increase portability. If evolving music is developed by the Art/Sound team, then that will have to be implemented. The most likely 'general' function for the FE for sound will be a 'int Music(blah, blah:junk);' type thing, then the FE group would either call a routine written by the Art/Sound group or perhaps send a midi file etc... As for the '.mov' file. I envision this as a file with large x large x 24bit original pictures for the intro sequence, with embedded music and sfx. This way when a FE group is fine-tuning for their format, they can run a converter program on the .mov file to reduce the pictures down to the desired size for that FE. The pictures in the intro will likely be Ray-traced, 'cause drawing frame after frame of large x large x 24bit pictures by hand is a weighty task. The actual .mov files will be produced by the Art/Sound group, and the FE need only convert and display them. Other Front Ends may be formed if someone will direct a group to code them. The FE-PC/X will need to be developed first, this is because the PC is the most common computer within the development team, thus it would be most useful to test other group's routines. Other groups can either wait for the FE-PC/X to be reasonably finished and convert that code -or- code simultainiously. BTW for those who don't know, PC/X means DOS format (perhaps DOS4G...do we have enough Watcom C users out there? I'm one. Do I hear two?) with mode X VGA graphics (of some resolution). -------------- - Universe - -------------- Director : Adrian Tymes - uwingcat@mcl.mcl.ucsb.edu This portion of the game will be written in standard ANSI C. It contains the main() procedure and is basically the 'controller' of the game. It will call FE routines for it's user input and output, use Alife and Art/Sound routines for generating the aliens and their behaviour. Aside from it's control-center aspect, it also handles things like the physical aspects of the universe, acceleration, turning, etc. This text specifies the Universe part of the game. Anything that is not basic will have the word OPTION: in front of it. The Universe ------------ - is relatively independent of the actual front-end. - is flat; 2d. - has wrap around borders, and has thus no borders, but it's finite too. The Objects in the Universe --------------------------- - each have a speed (may be zero). - are inertial, so do not slow down without any force on it. (no friction) - each have a _objective direction_. The direction angle is 0-255. 0 is N, 128 is S, etc. This is the _objective direction_. - each have a _facing direction_, which is the direction the object is facing, usually the same as the _objective direction_. 0-255 deg as well. - can turn smoothly. 16 different rotations is probably enough. [though we might just send the _facing direction_ to the FE and let them decide how many rotations to implement..:)] Kinds of objects ---------------- The ships --------- - can turn left and right. - can add thrust. OPTION: Side and reverse thrust have been discussed... - have two types of energy: 'Armour' : How many 'hit points' the ship has left, before it dies. 'Usable' : Energy it has to fire, mate, move, etc. - decrease armour energy (and perhaps Usable as well) if hit by a weapon. - can gain energy by eating energy pods (perhaps the remains of killed enemies, eggs, and misc other sources). OPTION: this might be 'plant growth', or asteroids, or pods that come free when a ship is destroyed. This remains to be decided. - can fire their weapons (up to two weapons?). - can view the reletive direction that another object is facing (facing towards or away from the object, etc.) - can view the distance another obj is at. - can view the speed (relative speed?) another obj is flying with. The player ship --------------- - is controlled by the player, by a 'thrust' key, left and right rotation keys, a fire key. OPTION: a breed key, an eat key, a 'weapon option' key, etc. The aliens ships ---------------- - are controlled by alien pilots. A pilot is a piece of behaviour code. - have essentially the same control methods as the player, using 'virtual' keys. (they call the same functions as the ones that get called when a key is pressed by the human) Projectiles (missiles, bullets) ------------------------------- - can collide with ships. The ships loose a certain amount of energy when hit, dependent on the type of projectile. - may have very primitive behaviour code in them. Projectiles may evolve! OPTION: energy donation projectiles might also exist. Vampiristic projectiles can also exist. (they suck energy out of the ship that is hit, and transfer it to the ship that fired the projectile) - are always destroyed upon collision. (they explode) - are fired by ships. (of course :) Other objects ------------- Asteroids, obstacles, energy pods, plants, motherships, etc. ----------- - Alife - ----------- Director : Martijn Faassen - faassen@phil.ruu.nl This piece of code must be written in either C or C++, preferrably C, we'll let the Alife group decide (C++ is fairly non-standard right now, but ANSI C is a portable standard. I think there's a C++ standard too...hmmm). Anyway there will be a few types of routines that the Alife group will have to develop: A routine to decide an alien's bahaviour (this will be the -main- procedure that they'll write), which will obviously call probably several smaller, local procedures to decide upon a behaviour. The output will be in the same format as the human player's controls (ie left, right, thrust, begin mating, fire weapon A, fire weapon B etc). This procedure will have access to all of the global variables... - Aliens may access the map within a certain range, just like the human player's viewwindow. - Aliens may access a set of alien-only variables. These would be things like global distress calls, species group action calls, boss presence and other vars which an alien might respond to. This will be the alien equivilent to the player's radar. - Alien may access other aliens stats etc. (for mating purposes...) This section includes all of the Genetic Algorhythm stuff that will dictate alien behaviour etc. --------------- - Art/Sound - --------------- Art Director : Jeff Lait - jmlait@undergrad.math.waterloo.ca Sound Director : This group will be in charge of either producing the pictures and music/sfx or writing routines to produce it (the latter is obviously preferred). Their code will have to be a C/C++ standard (ANSI C or the C++ standard), as it will also have to be portable. Also the sound, music, sfx files should also be done in a format that is easily portable. Note that currently Jeff is the director for the whole group, but a co-director to manage the sound specifics is still being sought...any takers? ------------- - Summary - ------------- OK, it's time for everyone to split into sub-groups. Please send me a simple msg with all of the subgroups you'd like to join (try to keep it to two max). If a group is still lacking a director, I will be accepting volunteers for those too. If you'd like to start a new FE, tell me about it. That's it for now....-=GT=- Greg Taylor From ???@??? Wed Nov 16 21:00:38 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id UAA29914 for ; Wed, 16 Nov 1994 20:49:13 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA73772; Wed, 16 Nov 1994 17:51:51 -0800 Date: Wed, 16 Nov 1994 17:51:48 -0800 (PST) From: Gregory Glen Taylor Subject: Re: File site To: Michael Mitchener In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII GREAT! Could you start work on that? The major access levels might be... DIRECTOR - r/w privileges on all files. MEMBER - r privilages on all files. GENERAL - r privilages on info-only files. Perhaps we might use Charles' site for the GENERAL stuff and use yours for the MEMBER and DIRECTOR stuff. Sound reasonable? -=GT=- From ???@??? Wed Nov 16 21:22:55 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA03282 for ; Wed, 16 Nov 1994 21:14:13 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA23669; Wed, 16 Nov 1994 18:16:51 -0800 Date: Wed, 16 Nov 1994 18:16:51 -0800 (PST) From: Gregory Glen Taylor Subject: Re: File site To: Michael Mitchener In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK I'll mention it to the group in my next file.................. please add the name of the site when I send my next file to you... (should be sent to the directors tonite)...-=GT=- From ???@??? Wed Nov 16 21:22:56 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA03306 for ; Wed, 16 Nov 1994 21:14:23 -0500 Received: from iitbarr.iit.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7wJY-000fIuC; Wed, 16 Nov 94 18:11 PST Received: from iit.iit.com by iitbarr.iit.com (4.1/AI-4.10) id AA13636; Wed, 16 Nov 94 18:03:57 PST Received: from manila.iitengr by iit.iit.com (4.0/SMI-4.1) id AA01516; Wed, 16 Nov 94 18:08:03 PST Date: Wed, 16 Nov 94 18:08:03 PST From: brett@iit.com (Brett Coon) Message-Id: <9411170208.AA01516@iit.iit.com> To: alife-game@alnilam.krl.caltech.edu Subject: Re: Devils Advocate > Having read many of the papers on the project mentioned, I must point out > that we are using very different techniques from them. It all depends on > how complex the world is, and how plastic the creatures code is. I'm not sure I understand your use of the word "plastic". > If we > were going to start out with simply random creatures, the chance for them > to form something worthwhile is quite slim, and thus the genetic environment > is too difficult to navigate through; the fitness landscape is mostly flat > so mutations only cause a random walk across the landscape until something > useful is found - which may take an extremely long time. I think this is more a function of your fitness evaluation that the starting point you use. If you start with random creatures, you have to provide attainable rewards, such as giving greater fitness to creatures who move than to creatures who don't. If you only give credit to creatures who successfully shoot the player, then yes, you'd be doing a random search for a long time before you found an individual with nonzero fitness. > On the other hand, > since we seed the soup (sorry - term I keep using after working with tierra) > with initial creatures, we start them off in an interesting portion of the > landscape where they are capable of actually moving uphill. The problem with relying on seeding is that you are inherently biasing your creatures by specifying the initial genetic material in your population. > > Of course we'll keep the game simple at the start, and later extend it > > if it seems feasible. I don't think anybody ever said anything else. > > (though of course the graphics and the sounds may be complicated, that's > > another area though) > > I completely agree - as we add in new features one at a time, we will have > a chance to fully deal with how they impact the game. Well, unless the discussion of power-ups, mating behavior, etc is largely academic, I personally think it's still a bit too complex for a first pass. The way I would like to see the project approached is for the first pass to be completely non-evolutionary. That is, a normal shoot-em-up with simple human-written routines to control the aliens. Then, once that does something, we could take some small part of the alien control, such as left-right motion based on player position, and turn it over to evolution to see what hap- pens. If the first pass tries too much, and I think the propo- sals are definitely too much, it is far less likely to work. > Right - its not possible for us to know good numbers for this since its a > new kind of system of its own - certainly not a genetic algorithm. Creatures > in genetic algorithms are killed off each update, and then replicated if they > were successful. That's the classic GA approach, but it certainly doesn't apply to all GA's. One of the most common GA optimizations is "elitism", in which the best members of each generation are copied unchanged to the next generation. There has been work done in which popu- lation members live through several generations, possibly repro- ducing many times. > We don't need (or want!) the restriction of funneling it towards a specific > behavior. But any help you give to your evolutionary algorithm, such as seeding the population, is effectively funneling towards specific behavior! > > I'm sure someone else can manipulate the numbers such that it'll become > > totally impossible again. Be my guest. :) > > Sure, if you really wany me too. :-) Lets see... in an average avida run > we use about 1600 creatures in the soup, and it takes upwards of 800 updates > to learn a simple task like addition.... (yes I'm leaving out lots of facts > here... like creatures are not killed off during updates, and the system > processes updates in minimal time - 800 is under a half hour). Wait, 1600 creatures X 800 updates = 1,280,000 evaluations to come up with addition? I think that means we'll be blasting aliens for years before they come up with the idea of avoiding our shots. I have had a few ideas to possibly accelerate evolution. One idea is to evaluate each control program for each alien. The ac- tion actually taken by a given alien is the result of one specif- ic control program, but every control program that requested that same action would get partial credit for the alien's fitness. That is, suppose program A controls alien #2, for example. Let's say alien #2 dies after 100 steps. During those 100 steps, pro- gram B agreed with program A 25% of the time. Then when it's time to evaluate the fitness of program B, we sum all contribu- tions made by program B, which will include 25% of the fitness of alien #2. > > > There must be safeguards of some sort (either explicit or just > > > factors in the fitness evaluation) that prevent certain unwanted > > > behaviors from evolving. For example, we probably don't want > > > meek aliens that run or hide, and we also don't want large groups > > > that storm the player and are impossible to defeat. > > > > > I'd love to see aliens running and hiding, and then the human player > > hunting them down and killing them. I'd also love to see large groups > > of aliens storming the poor unsuspecting player. :) Yes, this would be cool from an ALife point-of-view, but it would make for a very boring or frustrating game. I guess my point is that I'd like to see "excitement of game play" as part of the fitness, to help evolve interesting opponents, not just effective ones. The two are NOT the same, as anyone who has found a trick to consistently defeat their opponent will tell you. For exam- ple, in a multi-player maze game I used to enjoy, we discovered the unbeatable strategy of waiting in a hallway and shooting any- one who wandered by. The lurker always won the battle, but it wasn't a _fun_ way to play for anyone. Unless the fitness func- tion somehow penalizes boring strategies like that, you'd end up with enemies with that type of behavior. > > Thanks for your input, I'm sure we did need some devil's advocates to > > restrain our ideas from getting too wild. It's all talking in the dark > > right now, we just don't know what the game will turn out to be. (though > > we will of course try to make it turn out to be as good as possible) > > *yawn* it is useful, but I think I'm getting a bit tired right now to reapond > to any more... Since the exciting part of this project is the evolutionary stuff, wouldn't it be more efficient to find an _existing_ game that's in the public domain, and add evolutionary control mechan- isms to it? That way we don't have to "waste" time working on the game concept, front-end programming, etc. I'm sure there are X-windows versions of Space Invaders, Asteroids, Battlezone, etc that could be used as a starting point. -Brett +------------------------------------------------------------+ | Brett Coon - brett@iit.com or brettc@leland.stanford.edu | | Integrated Information Technology Inc. (408) 654-0936 | +------> finger brettc@leland.stanford.edu for PGP key <-----+ From ???@??? Wed Nov 16 21:37:52 1994 Received: from undergrad.math.uwaterloo.ca (root@undergrad.math.uwaterloo.ca [129.97.204.13]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA05853 for ; Wed, 16 Nov 1994 21:31:21 -0500 Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57115-3>; Wed, 16 Nov 1994 21:32:47 -0500 Date: Wed, 16 Nov 1994 21:32:11 -0500 From: Jeff Lait Sender: Jeff Lait Reply-To: Jeff Lait Subject: Real copy of test program... To: Gregory Glen Taylor cc: charles@krl.caltech.edu, g-j@chameleon.alt.za, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Okay, most people failed to get the last version, and I don't wish to shove this to the FTP site as it would probably discourage most spectators :> Okay, before I show the source, I would like to mention I few things I realized in writing this which we need to figure out BEFORE we start coding the individual routines. The most important involves the AlienType structure, or more generally, the ObjectType structure. First of all, as we are going to be dealing with many aliens (Around 400 or so seems about right for the playfield size we are dealing with), and many additional objects (Such as eggs, asteroids, etc) we are going to need the objects to be stored in some format which allows us to easily and swiftly determine all other objects within a distance n of it. This distance will be defined as max(|dX|, |dY|), as we WANT it to be bounded with squares. (For bounding box collisions, etc). I'm contemplating the problem now, but I would really like your input. Remember we must also be able to traverse the list of objects easily - possible store the object as a linked list in addition to the other format to make this easier. The other thing is how we specify the format. As the Front End does not care about collisions, etc, we can get away with a straight traversal of linked list there, but for th universe/behavior we want to be able to look at the `closest' objects. Therefore, I propose we have the first n or so bytes of the objects all be identical, regardless of what sort of objects they are. Then, a later byte will determine the identity of successive fields. This means we have to playit a bit loose with pointer types, but there are no serious problems with that: typedef struct { long x, y; // Object's position. char *pic; // Current picture. void *next; // Cast into apporpriate type... char type; // What type of object it is? long velx, vely; // Velocity. ACTIONS move; // It's actions. int mass; // Weight... char ship_heading; // Which way the thing is heading. ... Object specific stuff ... } objecttypes; Where all object types have those first fields (Possibly energy as well) in the same order. (Not that order, however, the type should be promoted to int and moved down by mass. No sense totally screwing allignment on purpose :>) And the following is the actual code - feel free to clip it if you were one of the lucky people to get it successfully :> Don't bother sending it to the FTP site, however, as it is proof of concept only. UNIVERSE.H - I think I changed some names here... /* This is the header for the universe. * Defines all global procs, types, etc. */ typedef long FIXED; typedef struct Actions { unsigned int forwardthrust : 1; /* Accelerate forwads with thrust of 1. */ unsigned int backthrust : 1; unsigned int left : 1; /* Left by 4 deg (256 deg = 2pi rad) */ unsigned int right : 1; /* Right by 4 deg. */ }; typedef struct AlienType { /* Front end expects these to come first... */ FIXED x, y; char *current_pic; /* Should be compiled in Large at least on PC */ /* And then this - this allows changes to alientype to be made without too much bother in the front end... */ AlienType *next; /* I'll do a linked list implementation. Other * possibilities would probably be a LOT more * effective. But this is to just get the idea...*/ FIXED velx, vely; int mass; char ship_heading; /* Note: char's defined as unsigned over here! */ char *picdata[8]; /* 8 facing directions (Should, of course, be higer */ Actions move; /* What the aliens move is... */ /* Should also have behaviour code, and other goodies... */ }; /* Front End Functions... */ void FE_InitScreen(int *sx, int *sy); void FE_RedrawScreen(AlienType *Aliens, AlienType *You, int *Ticks); void FE_CloseScreen(); char *FE_CompileSprite(char *source); /* Universe Functions... */ void UN_InitTable(); /* Does any req'd table generation */ void UN_MoveAliens(AlienType *Aliens, int dt); /* This can't handle collisions in this incarnation - ideas? */ /* Behaviour Code... */ void AI_ChooseMove(AlienType *Aliens); /* Fills in the move field of each alien based upon it's stats and those * around it. Linked list implementation of aliens would make this a pain * more likely than not, it will be necessities of this routine which will * determine final data structure. Currently, aliens are designed to * accelerate in right-angles (+/- 4 deg) to their current direction. */ /* Don't bother changing AI to ALife, heck, it's just semantics and saying * you have `artififcial intelligence' might be good marketting :> */ Main.CPP - The main module... /* This is a barebones version of the game... Gives some idea of how the * interfaces will work. * I think the radar map is drawn upside down so don't be surprised if it * looks like you're accelerating in the wrong direction. * I coded this mostly to: * a) Get some idea what is required * b) Find any potential problems with the ideas we have... * From this, I have noticed that we definetly need to decide upon a way * to store the objects (Aliens, you, asteroids, eggs, etc) which will allow * them to be randomly accessed based upon closeness to another object. * Find All OBjects withing such a distance of this object is something * we'll need a lot of, not only with bounds checking, but with almost every * thing else. Profile: 55% - UN_MoveAliens 30% - FE_RedrawScreen 12% - AI_ChooseMoves That's for 400 aliens... UN_MoveAliens is probably so pathetic because I'm running 3.0 of BC which calls seperate procs for every LONG... Keep in mind when writing the Universe code that it could very well be a substantial part of the resulting time... :> Total speed wasn't great - 25.5 FPS on my 486dx33 w/ vlb. Again, this is just a demo to give us an idea of how the interface will work... */ #include #include #include #include #include #include #include "universe.h" char *LoadPic(char *fname); void main() { AlienType *temp, *Aliens, *you; int i1, i2; char *picdata[8]; /* Temp storage for pics... */ char c; char fname[30]; int time=0, otime = 0; for (i1 = 0; i1 < 8; i1++) { sprintf(fname, "alien%d.var", i1); picdata[i1] = LoadPic(fname); } /* There, all 8 pics loaded and compiled... */ Aliens = NULL; for (i1 = 0; i1 < 400; i1++) { /* Generate 400 aliens... */ temp = (AlienType *) malloc(sizeof(AlienType)); temp->next = Aliens; Aliens = temp; temp->ship_heading = 0; temp->mass = random(2) + 1; temp->vely = 0; temp->velx = 0; temp->x = ((long)random(256)<<16) + ((long) random(256)<<24); temp->y = ((long)random(256)<<16) + ((long) random(256)<<24); for (i2 = 0; i2 < 8; i2++) { temp->picdata[i2] = picdata[i2]; } } you = (AlienType *) malloc(sizeof(AlienType)); for (i2 = 0; i2 < 8; i2++) { you->picdata[i2] = picdata[i2]; } you->next = NULL; /* Only one of you! */ you->ship_heading = 0; you->mass = 1; you->velx = 0; you->vely = 0; you->x = 32768*65536; you->y = 32768*65536; /* Okay, stuff is now initialized...*/ FE_InitScreen(&i1, &i1); /* We really don't care about these :> */ UN_InitTable(); /* Initialize tables etc... */ do { you->move.forwardthrust = 0; you->move.backthrust = 0; you->move.left = 0; you->move.right = 0; while (kbhit()) { switch (c = getch()) { case 0: switch(getch()) { case 72: /* Up... */ you->move.forwardthrust = 1; break; case 80: you->move.backthrust = 1; break; case 75: you->move.left = 1; break; case 77: you->move.right = 1; break; } break; } } /* End while kbhit... */ /* Now, the aliens determine their moves... */ AI_ChooseMove(Aliens); /* Now, aliens do there moves according to physics... */ UN_MoveAliens(Aliens, time-otime); /* And you move... */ UN_MoveAliens(you, time-otime); /* Finally, we redraw the screen... */ otime = time; FE_RedrawScreen(Aliens, you, &time); } while (c != '~'); /* QUit... */ FE_CloseScreen(); free(you); temp = Aliens; while (temp != NULL) { Aliens = temp->next; free(temp); temp = Aliens; } printf("%d cycles completed\n", time); } char *LoadPic(char *fname) { char *temp1, *temp2; int f_id; f_id = open(fname, O_RDONLY | O_BINARY); temp1 = (char *) malloc(32*32); /* Hope you got enough memory... */ read(f_id, temp1, 32*32); close(f_id); temp2 = FE_CompileSprite(temp1); free(temp1); return(temp2); } UNIVERSE.CPP - Defining all the physics... /* The universe code... */ #include "universe.h" #include #include #define PI 3.1415 long sintable[255]; long costable[255]; /* Initializes the Sine and Cosine tables... */ void UN_InitTable() { int i1; /* We could store one table and shift, but I'm willing to waste 1k... */ for (i1 = 0; i1 < 255; i1++) { sintable[i1] = sin((float)i1/(2*PI))*65536; costable[i1] = cos((float)i1/(2*PI))*65536; } } /* This will update all alien positions. Need to include collision detection * here.... */ void UN_MoveAliens(AlienType *Aliens, int dt) { AlienType *cur; cur = Aliens; while (cur != NULL) { /* First, take care of all acceln/etc */ /* F is defined as 1. */ if (cur->move.forwardthrust) { /* vx += Fx/m*dt. */ cur->velx += ((costable[cur->ship_heading]>>8)*(256)/cur->mass)*dt; cur->vely += ((sintable[cur->ship_heading]>>8)*(256)/cur->mass)*dt; } if (cur->move.backthrust) { /* vx -= Fx/m*dt. */ cur->velx -= ((costable[cur->ship_heading]>>8)*(256)/cur->mass)*dt; cur->vely -= ((sintable[cur->ship_heading]>>8)*(256)/cur->mass)*dt; } if (cur->move.left) { cur->ship_heading+=4; } if (cur->move.right) { cur->ship_heading -= 4; } /* Set absolute maximum of velx/vely...*/ if (cur->velx > 10*65536) cur->velx = 10*65536; if (cur->vely < -10*65536) cur->vely = -10*65536; if (cur->velx < -10*65536) cur->velx = -10*65536; if (cur->vely > 10*65536) cur->vely = 10*65536; /* There, velx etc have their new values. Find new pic based on ship heading: */ cur->current_pic = cur->picdata[((cur->ship_heading+16)>>5) & 7]; /* Remember - Shipheading is unsigned! */ /* Now, update x coords...*/ cur->x += cur->velx*dt; cur->y += cur->vely*dt; /* Overflow handled automatically... */ cur = cur->next; } // Done! } BEHAVIOR.CPP - The dyslexic behaviour of these aliens is defined here: /* Behaviour code... */ #include #include #include "universe.h" /* The desired virtual key presses can be found in cur->move's bit pattern. * I personally am all for the virtual key press idea - no sense allowing * the computer to fine tune their thrust etc. when the user can't do so * reasonably.... */ void AI_ChooseMove(AlienType *Aliens) { AlienType *cur; cur = Aliens; while (cur != NULL) { /* Real silly movement pattern :< */ if (random(2)) { cur->move.forwardthrust = 1; cur->move.left = 1; cur->move.right = 0; cur->move.backthrust = 0; } else { cur->move.forwardthrust = 0; cur->move.left = 0; cur->move.right = 1; cur->move.backthrust = 1; } cur = cur->next; } } FRONTEND.CPP - The PC specific (13h, offscreen buffer, a VERY quick hack) is here... /* Being written entirely in C, and using a offscreen buffer with 13h, these * are far from efficient. But with any luck, they work :> */ #include "universe.h" #include #include #include #define VIRTUAL_SCREEN_WIDTH 1024 char *screen = (char *) MK_FP(0xa000, 0); char *buffer; unsigned int *xtbl, *ytbl; /* Initializes the screen - in this case create off screen buffer. Return * sprite size. */ void FE_InitScreen(int *sx, int *sy) { int i1; *sx = 32; *sy = 32; /* Desired width/height of sprites. */ buffer = (char *) malloc(64000); /* Off screen buffer */ asm { mov ax, 13h int 10h } /* Enter video mode.. */ /* Create tables... */ xtbl = (unsigned int *) malloc(VIRTUAL_SCREEN_WIDTH*2); ytbl = (unsigned int *) malloc(VIRTUAL_SCREEN_WIDTH*2); for (i1 = 0; i1 < 1024; i1++) { xtbl[i1] = (float)320*i1/VIRTUAL_SCREEN_WIDTH; ytbl[i1] = (float)200*i1/VIRTUAL_SCREEN_WIDTH; ytbl[i1] *= 320; } } /* Compiles a straight bitmap into internal format. Nothing substantial * is done in this version. */ char *FE_CompileSprite(char *source) { char *temp; temp = (char *) malloc(32*32); memcpy(temp, source, 32*32); // No processing req'd. return(temp); } /* Close screen, free buffer... */ void FE_CloseScreen() { free(buffer); asm { mov ax, 3 int 10h } } /* Redraws screen with radar etc. Enemy coordinates are in 1024x1024 and * are converted down to current res. Should have some form of background * tiling to give some illusion of speed - a blank screen is useless :> */ void FE_RedrawScreen(AlienType *Aliens, AlienType *you, int *time) { static int realtime = 0; unsigned int x, y, offset, bitoff; AlienType *cur; /* Reset time.. Normally would be pulled off clock... */ realtime++; *time = realtime; /* Clear buffer... */ memset(buffer, 0, 64000); /* Draw all aliens... No clipping... */ cur = Aliens; while (cur != NULL) { x = (cur->x - you->x)>>16; y = (cur->y - you->y)>>16; if ((x & ~(VIRTUAL_SCREEN_WIDTH-1)) || (y & ~(VIRTUAL_SCREEN_WIDTH-1))) { /* Not visible, don't draw... */ } else { /* Draw alien... */ offset = xtbl[x] + ytbl[y]; bitoff = 0; while ((offset+32 < 64000) && (bitoff < 32*32)) { memcpy(&buffer[offset], &cur->current_pic[bitoff], 32); bitoff += 32; offset += 320; } } x = ((unsigned int)(x+32768))>>10; y = ((unsigned int)(y+32768))>>10; buffer[x + y*320] = 5; /* Er.. Hud?? */ cur = cur->next; } bitoff = 0; for (offset = (100-16)*320+160-16; offset < (unsigned)(100+16)*320+160-16; offset += 320) { memcpy(&buffer[offset], &you->current_pic[bitoff], 32); bitoff += 32; } buffer[32*320+32] = 3; /* Buffer now contains picture, blit to screen! */ memcpy(screen, buffer, 64000); } Okay, knowing me I managed to forget something - hopefully it wasn't too important :> - Jeff Lait (SOL) From ???@??? Wed Nov 16 23:57:29 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id XAA25309 for ; Wed, 16 Nov 1994 23:51:05 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA66480; Wed, 16 Nov 1994 20:53:34 -0800 Date: Wed, 16 Nov 1994 20:53:34 -0800 (PST) From: Gregory Glen Taylor Subject: Re: ftp site & more ideas To: Charles Ofria Cc: g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: <9411170440.AA12943@altair.krl.caltech.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Charles' site will be used as the information site, Mike's as the File site. This way the info is globally acessable to everyone who wants to know about our project. And the files, with actualy game-info (code, pictures, sound files) will be stored on the File-site, where we can monitor access and preserve security.-=GT=- From ???@??? Thu Nov 17 01:16:54 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA04043 for ; Thu, 17 Nov 1994 01:09:13 -0500 Received: from mail.massey.ac.nz by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r7zzT-000fIvC; Wed, 16 Nov 94 22:06 PST Received: from gorgo.manawatu.planet.co.nz by mail.massey.ac.nz id <24410-0@mail.massey.ac.nz>; Thu, 17 Nov 1994 19:04:49 +1300 Received: (from uucp@localhost) by papaioea.manawatu.planet.co.nz (8.6.9/8.6.9) with UUCP id RAA24556 for alife-game@alnilam.krl.caltech.edu; Thu, 17 Nov 1994 17:30:57 +1300 Received: by gorgo.manawatu.planet.co.nz (1.65/waf) via UUCP; Thu, 17 Nov 94 17:23:36 +1200 for alife-game@alnilam.krl.caltech.edu From: belial@gorgo.manawatu.planet.co.nz (Turtle Dragon) To: alife-game@alnilam.krl.caltech.edu Subject: Re: Devils Advocate Date: Thu, 17 Nov 1994 17:13:00 +1200 Message-Id: <111794171351Rnf0.78@gorgo.manawatu.planet.co.nz> Organization: Razor Software/S.A.W. Design. Developers of GUI-BBS and GUI-Term. X-Mailer: Rnf 0.78 brett@iit.com (Brett Coon) writes: >The way I would like to see the project approached is for the >first pass to be completely non-evolutionary. That is, a normal >shoot-em-up with simple human-written routines to control the >aliens. Then, once that does something, we could take some small >part of the alien control, such as left-right motion based on >player position, and turn it over to evolution to see what hap- >pens. If the first pass tries too much, and I think the propo- >sals are definitely too much, it is far less likely to work. OK, well lets get a basic game engine running then. As I understand it we are looking at a top view, multi direction scrolling game on a set size of playfield, say 4 screens * 4 screens, which wraps. whats the general conclusion on aliens then?? are they going to move by some kind of movement language? >Yes, this would be cool from an ALife point-of-view, but it would >make for a very boring or frustrating game. I guess my point is >that I'd like to see "excitement of game play" as part of the >fitness, to help evolve interesting opponents, not just effective >ones. The two are NOT the same, as anyone who has found a trick >to consistently defeat their opponent will tell you. For exam- >ple, in a multi-player maze game I used to enjoy, we discovered >the unbeatable strategy of waiting in a hallway and shooting any- >one who wandered by. The lurker always won the battle, but it >wasn't a _fun_ way to play for anyone. Unless the fitness func- >tion somehow penalizes boring strategies like that, you'd end up >with enemies with that type of behavior. Yes, I would like to see an exciting game, rather than a exciting experimentin ALife which happened to let you shoot things. >Since the exciting part of this project is the evolutionary >stuff, wouldn't it be more efficient to find an _existing_ game >that's in the public domain, and add evolutionary control mechan- >isms to it? That way we don't have to "waste" time working on >the game concept, front-end programming, etc. I'm sure there are >X-windows versions of Space Invaders, Asteroids, Battlezone, etc >that could be used as a starting point. But the game engine is incredably simple as I've seen it described, and needs to be writen to allow very flexable aliens, and some kind of movement language. *-- --* C Warner, belial@gorgo.manawatu.planet.co.nz, Razor Software (NZ) *-- --* From ???@??? Thu Nov 17 08:07:08 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id BAA06495 for ; Thu, 17 Nov 1994 01:40:42 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA48735; Wed, 16 Nov 1994 22:43:06 -0800 Date: Wed, 16 Nov 1994 22:43:05 -0800 (PST) From: Gregory Glen Taylor Sender: Gregory Glen Taylor Reply-To: Gregory Glen Taylor Subject: That other file. To: AI Game Design Team , g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Below is the other half of the old IMPORTANT STUFF file. Please add and revise and send back...thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Alife Game - Current Discussion Topics = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* This section will be removed. To the 'DIRECTORS' of the Alife project: Please read, add, delete and revise this file, then mail your revisions to me, I'll patch them all together and post it to the group. NOTE - this is not yet for the group, it must be refined by us first! */ This file attempts several things. First it will list all of the major methods for certain portions of the project and summarize them. Second it will discuss the pro's and third the con's of each method. The aim of this file is to provide a way to both familiarize new people with the current methods, and to present them to the rest of us in a formatted fashion. This will hopefully facilitate better discussion which will more efficiently move the project forward. If you haven't signed up for a sub-group yet, do it soon, or you may be dropped from the project mailing list to the 'spectator list' (the spectator list will be those who don't actually want to -do- anything about the game, but would rather just hear reports about it and discuss it with the other spectators...). This project is going to begin moving -very- soon, and if you're not in a sub-group it will begin moving without you. Sign up! -------------------------- - Information Handling - -------------------------- Speaking of the new information handling, I'll take a moment to describe a few 'how-to's and where to go to find certain data etc... Sub-Groups ---------- To sign up for a sub-group, see the PROJECT STRUCTURE file, which is on the information FTP site (listed below), and it describes the structure of the sub-groups and how to join one. Mailing Lists ------------- The mailing-list will soon be mailing-listS...There will be several. // To Charles, I hope that this many lists won't cause any problems for you. // if so, tell me before I post this generally... also, change the names // of them as you deem them...I just assumed some good names... GENERAL - alife-game@alnilam.krl.caltech.edu This list will have the addresses of every person in the project. This will no longer be the preferred method of discussion, you are encouraged to post only within the relating sub-group...if you would like to discuss ideas for a sub-group that you are not a part of, send a msg to the -director- of that group, not the group itself, and not a general msg. In short, use this mailing list sparingly. DIRECTORS - alife-directors@alnilam.krl.caltech.edu This list has the addresses of all of the sub-group directors, plus a few other assistant directors and such. But it's for directors only, to be on it, you must be a director. FRONT ENDS - FE-PCX@alnilam.krl.caltech.edu FE-MAC@alnilam.krl.caltech.edu FE-AMIGA@alnilam.krl.caltech.edu These lists (others will be added as new front end groups form), will contain the addresses of everyone who is a part of that particular Front End group. UNIVERSE - Universe@alnilam.krl.caltech.edu This list will contain the addresses of the universe group. ALIFE - Alife@alnilam.krl.caltech.edu This list will contain the addresses of the Alife group. ART/SOUND - art-sound@alnilam.krl.caltech.edu This list will contain the addresses of the Art and Sound group. SPECTATORS - Spectators@alnilam.krl.caltech.edu This list is specifically for those people who either fail to join a sub-group, or just want to hear occational reports on the game project. This is the place for the people who just want to chat about the game endlessly and not actually -do- anything...we'll tell you what we're doing once in a while. People only concerned with game-testing will be put on this list. If you join a sub-group, your address will be added to the appropriate lists, if you wish to be on the spectator list only, follow the sub-group registration instructions, but request that list only. The mailing lists are thanks to Charles Odrin The FTP Sites ------------- There are two sites that are used for transfering files, concerning the project. THE INFORMATION SITE - ftp.krl.caltech.edu pub/users/charles/alife-game Information, such as this file, is available to the general public thru this site. If you would like to post on this site, upload it to the /imcoming directory within the alife-game directory. The alife-game directory is managed by Charles. THE FILE SITE - 144.118.44.96 This site will be accessable only with proper access privileges. There are two levels of access, 'DIRECTOR', which has full access to all of the files, and 'MEMBER', which had access to most of the files; except those marked for directors only. Directors will give member access to those who need it within their subgroups. To get access talk to your director. All of the code, and related files will be stored here. Please note that any data on this site is restricted, and you may not distribute it. This is for security reasons, in the case that this game may eventually be produced as Commercial or Shareware software. This site is managed by Mike Mitchener. To log into this site you must.... (explain it Mike...) ------------------- - Universe Talk - ------------------- First off let me mandate a few things... (1) No 3D graphics. (a) it's slow. (b) confusing for the player. (c) more work. (2) No Real-Time Raytracing. (a) it's -really- slow (b) it's an absurd idea, unless we're marketing it for Crays only. (3) Multi-player can wait. (a) let's keep the game reletively open so that it could handle it in the future, but. (b) it's too much work for the initial version, perhaps as an add-in later... (c) besides, that's a lot of data to be sent back and forth between screen redraws...lots! Think about the generated pictures? sending 128x128x24bit pictures thru the line every time a new species is created is a bit slow. (d) let's ignore multiplayer gaming for now, if you want that, go play moDOOM for a while. We are trying to focus on better computer enemies...you can play against humans in lots of other games. (4) No zooming. (a) it's fine for Star Control, but here...nay. (b) The aliens will have a set view-window, we have to restrict the player too. There, now that that's cleared up, lets discuss the other things. WAVES vs. CONTINUOUS. (the battle rages on) --------------------- WAVES - this method would send a huge batch of aliens against the player and bring back the longest survivor's children for the next wave. (sort of like all of the traditional Galactix sort of games...) PROS - It allows plenty of time for calculation of the new aliens. CONS - It hurts our Alife badly. CONTINUOUS - This method would start and end. No waves, no breaks. Aliens would breed in real time. More like a Simcity sort of environment. PROS - It allows for a great Alife simulation tank. CONS - Calculations must be done quickly, and/or split up large ones and have a calculation queue. SEMI-CONTINUOUS - This is my latest thoughts. This method would set the player up in a 'sector' of space. Each sector would take quite a while to clear of aliens. Some aliens would enter and leave the sector occationally. The ones who leave may be stored to disk for introduction when the player enters the sector they entered. (for those who've played it, sort of like a Dune 2 setup...) PROS - it allows a good ammount of time to do some Alife simulation. and still offers a new environment once in a while. CONS - Same as CONTINUOUS. // please insert some universe-based arguments, I can't remember any more. ----------------- - Alife Stuff - ----------------- Human Player vs. Alien Player. ------------------------------ HUMAN - The player is a human, attempting to wipe these vile aliens from the universe. The player's ship is improved via the standard method, power ups or purchasing new equipment either between stages or thru some base... PROS - ? CONS - "Haven't I played this game before?" ALIEN - The player is an alien too, and is randomly generated with the rest of the aliens at the start of the game. There are very many aliens who don't like the player very much. Improvements would be made by mating with aliens, these improvements would be a mis between the mated alien and the player's ship, and would be preserved in egg form until needed as 'lives'. The player would have to protect their offspring 'lives' or lose them before they could use them. There are two methods for player mating. 1. Occationally a gene will mutate in an alien and give it the urge to mate with the player, the alien would approach and do some mating dance...The player may choose to go mate (and press the breed key etc.) or they may choose to blast the sucker out of the sky... 2. The player may fertilize other alien eggs if they are unfertilized, this way the player would have to blast in on a mating couple and -in effect- steal the eggs. It is assumed that all aliens can both lay eggs and fertilize them. PROS - Offers a new twist on an old game. Also adds a -reason- not to blast away the best aliens first, 'cause what's left is the only supply of new lives. If you blast away all of the good ones, you're left with crappy new lives... Makes for interresting tactics on -who- to shoot and -when-. The player would also have to protect his new lives, or else the aliens might kill them before the player can use them. CONS - Ummm....Harder to write a plot for. You can't use the "The aliens are going to destroy humanity!!! Unless -you- can single-handedly stop them!" plot that is so often used... (can you tell I'm biased?...hmmmm...) // Directors, please fill in other arguments and other disputable topics... // These are all that have come to mind. // I'd like to get all of the opposing ideas addressed in this file, either // as a mandate "No, we aren't doing it that way" or as a "vs." sort of thing // with pro's and con's etc. -=GT=- From ???@??? Thu Nov 17 08:07:10 1994 Received: from tybalt.caltech.edu (root@tybalt.caltech.edu [131.215.139.100]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with ESMTP id CAA11962 for ; Thu, 17 Nov 1994 02:51:23 -0500 Received: from altair.krl.caltech.edu by tybalt.caltech.edu with SMTP (8.6.7/DEI:4.41) id XAA14306; Wed, 16 Nov 1994 23:50:31 -0800 Received: from rigel.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA13527; Wed, 16 Nov 1994 23:50:26 -0800 From: Charles Ofria Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/29Jun94-0757AM) id AA21966; Wed, 16 Nov 1994 23:50:11 -0800 Message-Id: <9411170750.AA21966@rigel.krl.caltech.edu> Subject: Re: That other file. To: gtaylor@violin.aix.calpoly.edu Date: Wed, 16 Nov 1994 23:50:10 -0800 (PST) Cc: charles@krl.caltech.edu, g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: from "Gregory Glen Taylor" at Nov 16, 94 10:43:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 11867 [munch] > -------------------------- > - Information Handling - > -------------------------- > Speaking of the new information handling, I'll take a moment to describe > a few 'how-to's and where to go to find certain data etc... > > > Sub-Groups > ---------- > To sign up for a sub-group, see the PROJECT STRUCTURE file, which is on > the information FTP site (listed below), and it describes the structure > of the sub-groups and how to join one. > > > Mailing Lists > ------------- > The mailing-list will soon be mailing-listS...There will be several. > > // To Charles, I hope that this many lists won't cause any problems for you. > // if so, tell me before I post this generally... also, change the names > // of them as you deem them...I just assumed some good names... I'm 95% certain their will be no problem with this. The only general change that I need to make is for all of the mailing lists to have a set prefix to set them apart from the other lists run at the site. For example, we already have an alife mailing list which is for discussion among the various southern california groups on what we are working (and colaborating) on. For all except the alife-game group, I'm going to tag the ag- prefix on. > GENERAL - alife-game@alnilam.krl.caltech.edu > This list will have the addresses of every person in the project. > This will no longer be the preferred method of discussion, you are > encouraged to post only within the relating sub-group...if you > would like to discuss ideas for a sub-group that you are not a part > of, send a msg to the -director- of that group, not the group itself, > and not a general msg. In short, use this mailing list sparingly. Perhaps a note should be put that if you are on multiple lists, you may (unless I figure out something clever) get two copies of each letter sent to this group. > DIRECTORS - alife-directors@alnilam.krl.caltech.edu I'm using ag-directors@alnilam... > This list has the addresses of all of the sub-group directors, > plus a few other assistant directors and such. But it's for > directors only, to be on it, you must be a director. > > FRONT ENDS - FE-PCX@alnilam.krl.caltech.edu > FE-MAC@alnilam.krl.caltech.edu > FE-AMIGA@alnilam.krl.caltech.edu ag-PC-X@alnilam... ag-MAC@alnilam... ag-AMIGA@alnilam... I don't think its necessary to put FE - it just makes the name longer. If you really want it, I'll put it back. Also, will these people be responcible for making sure the rest of the code stays portable? It's not a very easy thing to do... > These lists (others will be added as new front end groups form), will > contain the addresses of everyone who is a part of that particular > Front End group. > > UNIVERSE - Universe@alnilam.krl.caltech.edu > This list will contain the addresses of the universe group. ag-universe@alnilam... (the capital U will make people confused I think...) > ALIFE - Alife@alnilam.krl.caltech.edu > This list will contain the addresses of the Alife group. ag-alife@alnilam... > ART/SOUND - art-sound@alnilam.krl.caltech.edu ag-art-sound@alnilam... > This list will contain the addresses of the Art and Sound group. > > SPECTATORS - Spectators@alnilam.krl.caltech.edu ag-spectators@alnilam... perhaps ag-announce would be a better name? > This list is specifically for those people who either fail to join > a sub-group, or just want to hear occational reports on the game > project. This is the place for the people who just want to chat > about the game endlessly and not actually -do- anything...we'll > tell you what we're doing once in a while. People only concerned > with game-testing will be put on this list. > > If you join a sub-group, your address will be added to the appropriate lists, > if you wish to be on the spectator list only, follow the sub-group > registration instructions, but request that list only. > > The mailing lists are thanks to Charles Odrin ^^^^^ Ofria (interesting mangle) > > The FTP Sites > ------------- > There are two sites that are used for transfering files, concerning the > project. > > THE INFORMATION SITE - ftp.krl.caltech.edu pub/users/charles/alife-game > Information, such as this file, is available to the general public > thru this site. If you would like to post on this site, upload it > to the /imcoming directory within the alife-game directory. > > The alife-game directory is managed by Charles. currently I have it as the uploads directory, not incoming. I'll change it if you like. Also, as soon as root gets around to it, the directory will be pub/alife-game. It'll certainly be done by the time this gets out. > THE FILE SITE - 144.118.44.96 > This site will be accessable only with proper access privileges. > There are two levels of access, 'DIRECTOR', which has full access > to all of the files, and 'MEMBER', which had access to most of > the files; except those marked for directors only. Directors will > give member access to those who need it within their subgroups. To > get access talk to your director. > > All of the code, and related files will be stored here. Please note > that any data on this site is restricted, and you may not distribute > it. This is for security reasons, in the case that this game may > eventually be produced as Commercial or Shareware software. > > This site is managed by Mike Mitchener. > > To log into this site you must.... (explain it Mike...) > > > ------------------- > - Universe Talk - > ------------------- > > First off let me mandate a few things... > > (1) No 3D graphics. > (a) it's slow. > (b) confusing for the player. > (c) more work. > > (2) No Real-Time Raytracing. > (a) it's -really- slow > (b) it's an absurd idea, unless we're marketing it for Crays only. > > (3) Multi-player can wait. > (a) let's keep the game reletively open so that it could handle it > in the future, but. > (b) it's too much work for the initial version, perhaps as an add-in > later... > (c) besides, that's a lot of data to be sent back and forth between > screen redraws...lots! Think about the generated pictures? > sending 128x128x24bit pictures thru the line every time a new > species is created is a bit slow. > (d) let's ignore multiplayer gaming for now, if you want that, go > play moDOOM for a while. We are trying to focus on better > computer enemies...you can play against humans in lots of other > games. I think that it might be worth while to stress the fact that we will leave the option open for multi-players. The most beautiful thing about that is then we have twice as much CPU time to process the off- screen aliens which are evolving! I know (and hope) that this will be a long way off, but we should program around it eventuality. > (4) No zooming. > (a) it's fine for Star Control, but here...nay. > (b) The aliens will have a set view-window, we have to restrict the > player too. > > There, now that that's cleared up, lets discuss the other things. Perhaps we should put the 'no's after we explain the game? > WAVES vs. CONTINUOUS. > (the battle rages on) > --------------------- > WAVES - this method would send a huge batch of aliens against the player and > bring back the longest survivor's children for the next wave. > (sort of like all of the traditional Galactix sort of games...) > > PROS - It allows plenty of time for calculation of the new aliens. > > CONS - It hurts our Alife badly. > > CONTINUOUS - This method would start and end. No waves, no breaks. Aliens > would breed in real time. More like a Simcity sort of environment. > > PROS - It allows for a great Alife simulation tank. > > CONS - Calculations must be done quickly, and/or split up large ones > and have a calculation queue. > > SEMI-CONTINUOUS - This is my latest thoughts. This method would set the > player up in a 'sector' of space. Each sector would take quite a > while to clear of aliens. Some aliens would enter and leave the > sector occationally. The ones who leave may be stored to disk for > introduction when the player enters the sector they entered. (for > those who've played it, sort of like a Dune 2 setup...) > > PROS - it allows a good ammount of time to do some Alife simulation. > and still offers a new environment once in a while. > > CONS - Same as CONTINUOUS. I think the best way to resolve this is to just see what develops naturally. If they discover that it is beneficial if they all attack at once, they'll be coming in waves in no time! > // please insert some universe-based arguments, I can't remember any more. > > > ----------------- > - Alife Stuff - > ----------------- > > Human Player vs. Alien Player. > ------------------------------ > HUMAN - The player is a human, attempting to wipe these vile aliens from the > universe. The player's ship is improved via the standard method, > power ups or purchasing new equipment either between stages or thru > some base... > > PROS - ? > > CONS - "Haven't I played this game before?" > > ALIEN - The player is an alien too, and is randomly generated with the rest > of the aliens at the start of the game. There are very many aliens > who don't like the player very much. Improvements would be made > by mating with aliens, these improvements would be a mis between the > mated alien and the player's ship, and would be preserved in egg form > until needed as 'lives'. The player would have to protect their > offspring 'lives' or lose them before they could use them. There > are two methods for player mating. > > 1. Occationally a gene will mutate in an alien and give it the urge > to mate with the player, the alien would approach and do some mating > dance...The player may choose to go mate (and press the breed key > etc.) or they may choose to blast the sucker out of the sky... > > 2. The player may fertilize other alien eggs if they are > unfertilized, this way the player would have to blast in on a mating > couple and -in effect- steal the eggs. It is assumed that all aliens > can both lay eggs and fertilize them. > > PROS - Offers a new twist on an old game. Also adds a -reason- > not to blast away the best aliens first, 'cause what's left > is the only supply of new lives. If you blast away all of > the good ones, you're left with crappy new lives... Makes > for interresting tactics on -who- to shoot and -when-. The > player would also have to protect his new lives, or else > the aliens might kill them before the player can use them. > > CONS - Ummm....Harder to write a plot for. You can't use the "The > aliens are going to destroy humanity!!! Unless -you- can > single-handedly stop them!" plot that is so often used... > > (can you tell I'm biased?...hmmmm...) Harder to write a plot for? Hmmm... Perhaps the player is a genetically altered alien created by the "good guys". There is a special gene in him that allows the to control him in some way (perhaps by making him suseptible to their mind control powers?) Every time he mates, there is a 50% chance that that gene is passed on and the next generation will also be controlable. Thus not all of your attempts at getting an extra life will be successful. I can just see players sneeking up on boss monsters to mate with them before they can attack... > // Directors, please fill in other arguments and other disputable topics... > // These are all that have come to mind. > > // I'd like to get all of the opposing ideas addressed in this file, either > // as a mandate "No, we aren't doing it that way" or as a "vs." sort of thing > // with pro's and con's etc. > > -=GT=- That's about it for me for now... --- Charles From ???@??? Thu Nov 17 08:07:13 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id DAA12682 for ; Thu, 17 Nov 1994 03:06:40 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r81pL-000fIrC; Thu, 17 Nov 94 00:04 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r81W2-0004TaC; Thu, 17 Nov 94 09:44 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02475; 17 Nov 94 06:00:53 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 14:46:07 +0200 Subject: Re: Behaviour Message-ID: <508_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu On 15 Nov 94, 03:14, Christian Darkin wrote: >> How about adding a behaviour pattern to each alien's program, that gets >> triggered when a boss is in the vicinity? I.e. each alien has a few >> general movement patterns for acting solo, and a way of responding to >> being in a group. > I`ve been thinking a lot about group behaviour and I think I`ve got a really > neat solution. How about `enslavement`: > When two aliens meet, one can attempt to enslave the other. This means that > the `master` alien can allocate its` slave one or more of its` unused > movement patterns. That way, the slave is only acting under instructions. This is a very good idea... What if each alien has a code pattern specifically used for enslavement? When one alien enslaves enother, the "slave" is controlled by the "master's" slave code pattern. (e.g., the master lets the slave circle around him - not a code pattern the master will ever use; it's reserved for enslavement.) We'll probably have to add some standard override based on distance between the slave and master, so that they don't get seperated too much. > The only rule in enslavement is this: An alien can have as many slaves as > it wants AS LONG AS THE MASTER`S RATING IS HIGHER THAN THE SUM OF ALL ITS` > SLAVES. That way, a big, nasty alien can either enslave one alien almost > as powerful as itself, or many weaker ones. This also presents the possibility that the player could start enslaving aliens later in the game... But what would happen if the player is enslaved by an alien? We might have to add some random probability of the slave escaping his master. > There would also be the possibility that an alien could enslave another > which was in its` turn already controling a group of its` own. Complex > societies could be built up. You might also get species which developed to > be parasites. That is, they would evolve to stay small and weak, and hang > around with big aliens hoping to be enslaved, and protected by them! Cewl! The more multi-faceted the game is, the more entertaining it will be. So keep on churning out these ideas! CYa G-J --- Blue Wave/RA v2.12 [NR] | FidoNet: Gert-Jan van Rooyen 5:7102/129 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Thu Nov 17 08:07:14 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id DAA12691 for ; Thu, 17 Nov 1994 03:06:59 -0500 Received: from dingo.cc.uq.oz.au by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r81r3-000fIsC; Thu, 17 Nov 94 00:06 PST Received: from localhost by dingo.cc.uq.oz.au with SMTP id AA00814 (5.67a/IDA-1.5 for ); Thu, 17 Nov 1994 16:46:28 +1000 Date: Thu, 17 Nov 1994 16:46:21 +1000 (GMT+1000) From: symPli2daMnhyPed! Subject: Re: Devils Advocate To: Alife Game In-Reply-To: <9411170208.AA01516@iit.iit.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Nov 1994, Brett Coon wrote: > Since the exciting part of this project is the evolutionary > stuff, wouldn't it be more efficient to find an _existing_ game > that's in the public domain, and add evolutionary control mechan- > isms to it? That way we don't have to "waste" time working on > the game concept, front-end programming, etc. I'm sure there are > X-windows versions of Space Invaders, Asteroids, Battlezone, etc > that could be used as a starting point. > -Brett Hi Brett, Apart from the fact that this would be totally unoriginal, it would make things a *lot* harder. Each part of this game is going to have to work together in extremely specialised ways. We are trying to start from the bottom and work our way up, using portable code for all parts of the Universe, Alife, and Graphics engines. Hopefully only the front ends are going to be machine specific. The main idea of this project, as from Christian's first post, is to create an action game that provides more of a challenge and interest to the player because of evolving aliens. This is, of course, the special part of the game, but it needs to be supported by the game itself. The behaviour that evolves will have to interact with the environment, and I seriously doubt that "Space Invaders" would do it credit. Another thing to remember is that the evolving code is not just going to change the behaviour of the the aliens, but how they look. We have already discussed the difficulties behind evolving graphics....and it won't be too easy. Even if we just used another game to start off with, how would the Alife engine be tested? Anyway, enough from me. Andy. From ???@??? Thu Nov 17 08:07:15 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id DAA12828 for ; Thu, 17 Nov 1994 03:07:20 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r81rO-000fItC; Thu, 17 Nov 94 00:06 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r81W1-0004QvC; Thu, 17 Nov 94 09:44 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02472; 17 Nov 94 06:00:51 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 15:06:04 +0200 Subject: Game objects Message-ID: <505_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu On 15 Nov 94, 15:24 mbbad@seqnet.dl.ac.uk murmured: mb> i) Agree a certain number of basic classes (note I'm using c++ mb> terminology what language will we use ?) mb> examples of the basic classes of the game might be: mb> alien/ship/creature mb> projectile/beam/mine mb> resource (such as food pellet, rocks, natural phenomena) mb> ship component (such as a type of mb> gun/engine/launcher/detector/shield) mb> program component (e.g a module that can be 'plugged' into the mb> 'mind' of an alien when it inherits it) mb> As an example, consider this last class, it might be defined: mb> class moving_object { mb> etc etc mb> } An OOP approach will, IMHO, certainly be the best way to handle the universe we're planning. I don't think, however, that the classes/objects you mentioned should be distinct from each other. There are too many similarities between them, esp. if we're planning "intelligent" projectiles that are basically asexual, exploding alien robots. A possible class hierarchy could look like this: +---------------------------+ | BasicObj | | (co-ordinates, direction, | | velocity, mass, etc.) | +---+-------------------+---+ | | +--------------+ +----------+ | | +------------+------------+ +------------+------------+ | Various "dead" object | | IntelligentObj | | types, such as astroids | | (supports programs & | | & food pellets | | program interpreters) | +-------------------------+ +---+--------+------------+ | | +--------------------------+ | | | +------------+------------+ +------------+------------+ | Projectile | | Alien | | (data & methods for | | (alien data, pics & | | intelligent missiles) | | methods. Breeding) | +-------------------------+ +-------------------------+ The universe could then be a collection of BasicObj types, and a "timeslice" in the game could be handled by calling a virtual DoTimeSlice method for each object in the universe. (I'm using Turbo Pascal OOP terminology... I hope it's more or less the same in C++). Each object should know whether it is visible on screen, and be able to draw itself onto an off-screen buffer. That should make refreshing the screen as easy as calling Display for each object in the universe. I don't know if that's very speed-effective, though... Anyway, let me know whether my ideas are "implementable"! :) G-J --- Blue Wave/RA v2.12 [NR] | FidoNet: Gert-Jan van Rooyen 5:7102/129 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Thu Nov 17 08:07:16 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id DAA12844 for ; Thu, 17 Nov 1994 03:07:50 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r81re-000fIuC; Thu, 17 Nov 94 00:06 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r81W1-0004S1C; Thu, 17 Nov 94 09:44 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02474; 17 Nov 94 06:00:52 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 14:17:06 +0200 Subject: Re: universe Message-ID: <507_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu On 15 Nov 94, 03:42 Christian Darkin wrote: ch> Also, objects should have MASS. That'll be very religious of them... ;) ch> That way, a force (engine) used on a ch> small light ship will allow it to travel much faster than the same ch> force on a big, heavy ship (a boss ship, for example). Thus, bosses ch> don`t zip around like mad things, and there will be a nice kind of ch> payoff between speed and power (armourment, etc). Excellent idea. BTW, one nice thing in Star Control II was the effects of gravity: if you came close to a planet/asteroid, you experienced a gravitational force. This could also add a nice twist to our universe, if the calculations involved (three multiplies and a divide per object combination) won't eat too much time. ch> We`re out to produce a constantly shifting ecosystem which creates ch> strange and wonderful variations on subtle, elegant answers. Hmm, poetic! :] But I agree... More than that, I think we should remember that we want to create an ultra-playable, ultra-exciting, ultra-marketable GAME! The player should be intrigued by every moment of the game, there should always be something new, the plot should always be unfolding, etc. Making a game with some smart computer opponent isn't enough - the game should be intense fun! ch> Here`s a thought: What about releasing an `alien writer` allong with ch> the game so people can build their own (we`re going to have to write ch> one anyway) Then we can encourage people to swap their invented (or ch> evolved) beasties around. We could set up a kind of FTP site `gene ch> pool` where people dump and collect strange creatures! Good idea. ch> Why not make the projectiles just aliens written in a different way to ch> other aliens. (ie, they`d have no desire to mate or be mated with. ch> They wouldn`t be able to be shot - or maybe they would. They would ch> only have one movement pattern, etc.) That way, when two creature`s ch> mated, you could just mate their bullets in the same way. Excellent! Intelligent ammo would be ideal... Of course, then the player could also be able to obtain "intelligent ammo" in some way. ch> Why have aliens and pilots and ships? Why not just say the aliens are ch> part organic, part machine. They are advanced reproducing robots which ch> use nannocomputers and GA`s to evolve. That way our plot and what ch> we`re *really* doing become interwoven to make a sort of surreal point ch> about the future of *real* computer technology. (You can tell I`m a ch> writer!) Good idea. The aliens have, over thousands of years, "enhanced" themselves with electronic and mechanical equipment. This was not a mere superficial enhancement... the aliens altered their original genetic coding, so that their offspring would actually "grow" these bionic organs. It became part of their living bodies. Over many years of evolution, the inefficient organic parts of their bodies were naturally replaced by electronic and mechanical counterparts. The shape of their bodies adapted to be more efficient in space travel. When the player meets them for the first time, they are already a race of efficient semi-robotic killers, but still capable of reproducing... ch> How about alien/player crosses coming out as live young, not eggs. ch> They can be sort of jelly blobs which wander about. Their movement ch> patterns would mostly make them stay in groups, but occasionaly wander ch> about alone. That way, the player would have to try to keep his ch> clutch under control as they were attacked, and the player tried to ch> wipe out aliens. ch> We should have quite a high turnover of player embryos so the player ch> is in constant danger of loosing them all, and has to frantically seek ch> out mates to keep the numbers up. I still don't quite understand why on earth the player would want to breed with an alien... It's kinda sick... :) Can't we rather have him obtain new ships and technology in a more plausible way? "Stealing" alien technology, for example, and then having the on-board robots enhance his own ship. And an "escape pod" if his first ship is destroyed, so that he can get back to the mothership to fetch one of the other fighters or something. G-J --- Blue Wave/RA v2.12 [NR] | FidoNet: Gert-Jan van Rooyen 5:7102/129 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Thu Nov 17 08:45:45 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id IAA14535 for ; Thu, 17 Nov 1994 08:38:33 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r86zK-000fIrC; Thu, 17 Nov 94 05:34 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id IAA13605 for ; Thu, 17 Nov 1994 08:31:51 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Nov 1994 08:36:10 -0500 To: alife-game@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: FTP site > This site is managed by Mike Mitchener. > To log into this site you must.... (explain it Mike...) You must open a connection to 144.118.44.96, then enter 'director' (all lowercase)as your name if you are a director. If you are a member of a team, type 'member' (all lowercase) as the name. The passwords for this site will be given to those who need them. It will be entered next, then you will see a list of folders(directories). Each team has its own folder, but any member can go into any folder(directors-if you don't like this, let me know, I can change that). There currently are no files here. Michael Mitchener st944m5h@post.drexel.edu From ???@??? Thu Nov 17 10:15:41 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA29947 for ; Thu, 17 Nov 1994 10:11:03 -0500 Received: from yuma.ACNS.ColoState.EDU by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r88QA-000fIrC; Thu, 17 Nov 94 07:06 PST Received: from K12.ColoState.EDU by yuma.ACNS.ColoState.EDU (AIX 3.2/UCB 5.64/4.03) id AA30430; Thu, 17 Nov 1994 08:04:58 -0700 Received: by k12 (4.1/SMI-4.1) id AA24585; Thu, 17 Nov 94 08:10:27 MST Date: Thu, 17 Nov 1994 08:10:27 -0700 (MST) From: Robert Elsner X-Sender: relsner@k12 To: Gregory Glen Taylor Cc: Christian Darkin , alife-game@alnilam.krl.caltech.edu Subject: Re: Various... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Robert Elsner relsner@k12.colostate.edu Platte Canyon High School Bailey, Colorado 80421 Barney-Mania will be the future. For us to survive, we must adopt to Barney. He is our GOD!!!!! --Famous quote from: Will Box 2095 On Wed, 16 Nov 1994, Gregory Glen Taylor wrote: > Let's get a -game- somewhat close to production levels before we begin to > discuss the Shareware vs. Commercial aspects...We need a product to sell > before we can think about selling it. > -=GT=- How true!!! Just a few notes: I say we have 20 predifined aliens. About 1/4 are dumber than a nail, the next 1/4 dumb, but no as much 1/4 is deciently smart and the final 1/4 is ultra-smart. This way, the aliens can "choose" who they want to mate with. If a dumb, strong aliens breeds with a smart, weak aliens you could get a med-smart, med-strngth alien. As for how to play the game, a network link-up should be possible. Maybe that could also be capable of played UNIX-DOS, SUN-UNIX or whatever. It would not be to difficult, as I haved played with networks, and sending/receiving data. A simple tag game would suffice to do this, just for practice. All you would need to send is a structure like the following, one for the player(1/2/3/4) one for the aliens: player_me_struct { my_strength,my_energy_usable, my_weapon my_present_attack,my_egg_status am_i_a_parent, where_x, where_y, who_attack_me what_i_am_doing } alien_struct { alien_number, weapon_status, sheild_status, energy_usable my_attack_pattern, my_egg_status, am_i_a_parent, where_x, where_y who_attack_me, what_am_i_doing, gene_struct { my_present_genes,pattern_1,pattern_2,pattern_3,pattern_4 situation_pattern_5,situation_pattern_6,mate_preference } } This is just an idea. --RE See above for the footer, I ain't got none down here. From ???@??? Thu Nov 17 14:06:36 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA06401 for ; Thu, 17 Nov 1994 10:43:24 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r88pB-000fIrC; Thu, 17 Nov 94 07:32 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA14547; Thu, 17 Nov 1994 07:31:09 -0800 From: Charles Ofria Message-Id: <9411171531.AA14547@altair.krl.caltech.edu> Subject: Re: Devils Advocate To: brett@iit.com (Brett Coon) Date: Thu, 17 Nov 1994 07:30:36 -0800 (PST) In-Reply-To: <9411170208.AA01516@iit.iit.com> from "Brett Coon" at Nov 16, 94 06:08:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 10355 Sender: charles@altair.krl.caltech.edu -- From: Brett Coon > > Having read many of the papers on the project mentioned, I must point out > > that we are using very different techniques from them. It all depends on > > how complex the world is, and how plastic the creatures code is. > > I'm not sure I understand your use of the word "plastic". Plastic is flexable - If you mutate the creature, you want to minimize the probability that the mutation will kill off the creature, while maximizing the potential benefit of it. If you have a language, for example, where there is typically only one command that can work after another, then if you do any mutation chances are you'll destroy the creature. However if you have most combinations of commands capable of doing *something* it will still often kill the creature, but it does also give more working options. > > If we > > were going to start out with simply random creatures, the chance for them > > to form something worthwhile is quite slim, and thus the genetic environment > > is too difficult to navigate through; the fitness landscape is mostly flat > > so mutations only cause a random walk across the landscape until something > > useful is found - which may take an extremely long time. > > I think this is more a function of your fitness evaluation that > the starting point you use. If you start with random creatures, > you have to provide attainable rewards, such as giving greater > fitness to creatures who move than to creatures who don't. If > you only give credit to creatures who successfully shoot the > player, then yes, you'd be doing a random search for a long time > before you found an individual with nonzero fitness. This is completely true, but to cause more of the behaviors we want to see, we can't let this develop from the begining. For example we inherently *discourage* movement by making it cost energy. But, if by random chance, a creature did discover how to move to a nearby energy source and drain it, it would be far more successful than any of the other creatures. This would never happen in any reasonable time frame for the game, however. Also, the simple mechanizm for reproduction is something that we must start them off knowing how to do. Without that, everything must be a random walk, because bonuses are meaningless. A creature could be capable of running through a maze killing off everything in it, and then do a dance back through, but this would die with the creature if it did not have any offspring. It'll be an increadibly complex series off movements for males to find and know what to do with eggs. And there is no way to encourage its occourance! Again, if it did occur randomly it would stick, but we don't have that time. This is mostly what I was refering to by "an incredibly flat fitness landscape". Yes the fitness evaluation also comes into play, but not until you have more developed creatures. (If you are familiar with Tierra, it would be like starting that with random assembly programs and hoping self reproduction develops. If you could do that, you'd be famous!) > > On the other hand, > > since we seed the soup (sorry - term I keep using after working with tierra) > > with initial creatures, we start them off in an interesting portion of the > > landscape where they are capable of actually moving uphill. > > The problem with relying on seeding is that you are inherently > biasing your creatures by specifying the initial genetic material > in your population. Yes, we bias it initially, but thats why I still do want it to run for a while before we have a "soup" ready to introduce the player to. Other things will still develop. > Well, unless the discussion of power-ups, mating behavior, etc is > largely academic, I personally think it's still a bit too complex > for a first pass. > > The way I would like to see the project approached is for the > first pass to be completely non-evolutionary. That is, a normal > shoot-em-up with simple human-written routines to control the > aliens. I agree... > Then, once that does something, we could take some small > part of the alien control, such as left-right motion based on > player position, and turn it over to evolution to see what hap- > pens. If the first pass tries too much, and I think the propo- > sals are definitely too much, it is far less likely to work. The way the aliens write their own code (or evolve as the case may be) will be completely integrated. If you just took one aspect out, and tried to keep the creature still integrated regardless, it would fail miserably. Try playing any video game like this where you control only left-right movement and another player controls everything else. Oh, and the two of you are not allowed to communicate! You'd never be able to navigate anywhere! Sometimes you just need to have all the info at once. > > Right - its not possible for us to know good numbers for this since its a > > new kind of system of its own - certainly not a genetic algorithm. Creatures > > in genetic algorithms are killed off each update, and then replicated if they > > were successful. > > That's the classic GA approach, but it certainly doesn't apply to > all GA's. One of the most common GA optimizations is "elitism", > in which the best members of each generation are copied unchanged > to the next generation. There has been work done in which popu- > lation members live through several generations, possibly repro- > ducing many times. I think you missed the point of what I'm saying... Even in elitism (by the numbers which had been given) it assumes that creatures are replaced each update. I was refuting the number myself in a different way. We actually do agree here. (note: many genetic algorithms simply fail without elitism! Sometimes if there are *any* mutations, it will usually destroy everything. These creatures may even be a good example of that.) > > We don't need (or want!) the restriction of funneling it towards a specific > > behavior. > > But any help you give to your evolutionary algorithm, such as > seeding the population, is effectively funneling towards specific > behavior! Its an initial funneling, but the pressure is ended as soon as the soup begins to run. > Wait, 1600 creatures X 800 updates = 1,280,000 evaluations to > come up with addition? I think that means we'll be blasting > aliens for years before they come up with the idea of avoiding > our shots. Its not that bad - a single update in avida only gives each creature a little bit of CPU time. A creature is no where near evaluated after only one update! > I have had a few ideas to possibly accelerate evolution. One > idea is to evaluate each control program for each alien. The ac- > tion actually taken by a given alien is the result of one specif- > ic control program, but every control program that requested that > same action would get partial credit for the alien's fitness. > That is, suppose program A controls alien #2, for example. Let's > say alien #2 dies after 100 steps. During those 100 steps, pro- > gram B agreed with program A 25% of the time. Then when it's > time to evaluate the fitness of program B, we sum all contribu- > tions made by program B, which will include 25% of the fitness of > alien #2. While being nice in principle, I think this would take far too much CPU time to keep good, acurate track of. > > > > There must be safeguards of some sort (either explicit or just > > > > factors in the fitness evaluation) that prevent certain unwanted > > > > behaviors from evolving. For example, we probably don't want > > > > meek aliens that run or hide, and we also don't want large groups > > > > that storm the player and are impossible to defeat. > > > > > > > I'd love to see aliens running and hiding, and then the human player > > > hunting them down and killing them. I'd also love to see large groups > > > of aliens storming the poor unsuspecting player. :) > > Yes, this would be cool from an ALife point-of-view, but it would > make for a very boring or frustrating game. I guess my point is > that I'd like to see "excitement of game play" as part of the > fitness, to help evolve interesting opponents, not just effective > ones. The two are NOT the same, as anyone who has found a trick > to consistently defeat their opponent will tell you. For exam- > ple, in a multi-player maze game I used to enjoy, we discovered > the unbeatable strategy of waiting in a hallway and shooting any- > one who wandered by. The lurker always won the battle, but it > wasn't a _fun_ way to play for anyone. Unless the fitness func- > tion somehow penalizes boring strategies like that, you'd end up > with enemies with that type of behavior. I think that it would be a lot of fun to play in a detailed realistic world. Just because some of the aliens run and hide doesn't mean that there won't be another swarm coming at you around the next corner! Without this variation, we'd never get the eco-system effect we want. > > > Thanks for your input, I'm sure we did need some devil's advocates to > > > restrain our ideas from getting too wild. It's all talking in the dark > > > right now, we just don't know what the game will turn out to be. (though > > > we will of course try to make it turn out to be as good as possible) > > > > *yawn* it is useful, but I think I'm getting a bit tired right now to reapond > > to any more... > > Since the exciting part of this project is the evolutionary > stuff, wouldn't it be more efficient to find an _existing_ game > that's in the public domain, and add evolutionary control mechan- > isms to it? That way we don't have to "waste" time working on > the game concept, front-end programming, etc. I'm sure there are > X-windows versions of Space Invaders, Asteroids, Battlezone, etc > that could be used as a starting point. I think this would be a mistake - we don't want to start playing with other people's code, especially code that wasn't designed with this in mind. I think with current computers, it should be reletively simply to write the basis for a game like this. Besides, we already have teams of people anxiously awaiting working on front ends and sound and music! --- Charles From ???@??? Thu Nov 17 14:06:52 1994 Received: from undergrad.math.uwaterloo.ca (root@undergrad.math.uwaterloo.ca [129.97.204.13]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA25942 for ; Thu, 17 Nov 1994 12:19:40 -0500 Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56972-1>; Thu, 17 Nov 1994 12:21:00 -0500 Date: Thu, 17 Nov 1994 12:20:40 -0500 From: Jeff Lait Subject: Re: That other file. To: Gregory Glen Taylor cc: AI Game Design Team , g-j@chameleon.alt.za, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Nov 1994, Gregory Glen Taylor wrote: > Below is the other half of the old IMPORTANT STUFF file. Please add and > revise and send back...thanks. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > - Alife Game - Current Discussion Topics = > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > -------------------------- > - Information Handling - > -------------------------- > Speaking of the new information handling, I'll take a moment to describe > a few 'how-to's and where to go to find certain data etc... > > > Sub-Groups > ---------- > To sign up for a sub-group, see the PROJECT STRUCTURE file, which is on > the information FTP site (listed below), and it describes the structure > of the sub-groups and how to join one. > > If you join a sub-group, your address will be added to the appropriate lists, > if you wish to be on the spectator list only, follow the sub-group > registration instructions, but request that list only. > > The mailing lists are thanks to Charles Odrin Can I request to NOT be on the spectator list?? I'm deluged with mail as it its :> > The FTP Sites > ------------- > There are two sites that are used for transfering files, concerning the > project. > > THE INFORMATION SITE - ftp.krl.caltech.edu pub/users/charles/alife-game > Information, such as this file, is available to the general public > thru this site. If you would like to post on this site, upload it > to the /imcoming directory within the alife-game directory. > > The alife-game directory is managed by Charles. > > THE FILE SITE - 144.118.44.96 > This site will be accessable only with proper access privileges. > There are two levels of access, 'DIRECTOR', which has full access > to all of the files, and 'MEMBER', which had access to most of > the files; except those marked for directors only. Directors will > give member access to those who need it within their subgroups. To > get access talk to your director. > > All of the code, and related files will be stored here. Please note > that any data on this site is restricted, and you may not distribute > it. This is for security reasons, in the case that this game may > eventually be produced as Commercial or Shareware software. > > This site is managed by Mike Mitchener. > > To log into this site you must.... (explain it Mike...) > > > ------------------- > - Universe Talk - > ------------------- > > First off let me mandate a few things... > > (1) No 3D graphics. > (a) it's slow. > (b) confusing for the player. > (c) more work. > > (2) No Real-Time Raytracing. > (a) it's -really- slow > (b) it's an absurd idea, unless we're marketing it for Crays only. > > (3) Multi-player can wait. > (a) let's keep the game reletively open so that it could handle it > in the future, but. > (b) it's too much work for the initial version, perhaps as an add-in > later... > (c) besides, that's a lot of data to be sent back and forth between > screen redraws...lots! Think about the generated pictures? > sending 128x128x24bit pictures thru the line every time a new > species is created is a bit slow. > (d) let's ignore multiplayer gaming for now, if you want that, go > play moDOOM for a while. We are trying to focus on better > computer enemies...you can play against humans in lots of other > games. > > (4) No zooming. > (a) it's fine for Star Control, but here...nay. > (b) The aliens will have a set view-window, we have to restrict the > player too. > (5) It is an arcade game above all else. > There, now that that's cleared up, lets discuss the other things. > > > WAVES vs. CONTINUOUS. > (the battle rages on) > --------------------- > WAVES - this method would send a huge batch of aliens against the player and > bring back the longest survivor's children for the next wave. > (sort of like all of the traditional Galactix sort of games...) > > PROS - It allows plenty of time for calculation of the new aliens. > > CONS - It hurts our Alife badly. > > CONTINUOUS - This method would start and end. No waves, no breaks. Aliens > would breed in real time. More like a Simcity sort of environment. > > PROS - It allows for a great Alife simulation tank. > > CONS - Calculations must be done quickly, and/or split up large ones > and have a calculation queue. > > SEMI-CONTINUOUS - This is my latest thoughts. This method would set the > player up in a 'sector' of space. Each sector would take quite a > while to clear of aliens. Some aliens would enter and leave the > sector occationally. The ones who leave may be stored to disk for > introduction when the player enters the sector they entered. (for > those who've played it, sort of like a Dune 2 setup...) > > PROS - it allows a good ammount of time to do some Alife simulation. > and still offers a new environment once in a while. > > CONS - Same as CONTINUOUS. > I'd vote for semi continuous. After all, according to mandate 5 :>, we must consider the players feelings. I personally would not like to play a game where you just keep on beating on aliens non stop. There must be some sense of doing something, such as clearing a level. A good way to implement it might just to have the player blow away all the aliens in his sector. He has to do this relatively quickly, as they are constantly reproducing. Of course, different species have their own feuds so the player can use that to more swiftly rid that section of space of aliens (I see no problem justifying aliens fighting among themselves. Humans do it all the time :>) At the end of each wave, we add in a prebuilt species or two (To ensure the aliens never get WORSE than a certain amount) and take the most successful from the previous wave (By whatever system we use to judge this.) > ALIEN - The player is an alien too, and is randomly generated with the rest > of the aliens at the start of the game. There are very many aliens > who don't like the player very much. Improvements would be made > by mating with aliens, these improvements would be a mis between the > mated alien and the player's ship, and would be preserved in egg form > until needed as 'lives'. The player would have to protect their > offspring 'lives' or lose them before they could use them. There > are two methods for player mating. > I don't know... You might run into trouble with the moral police with this one :>... > PROS - Offers a new twist on an old game. Also adds a -reason- > not to blast away the best aliens first, 'cause what's left > is the only supply of new lives. If you blast away all of > the good ones, you're left with crappy new lives... Makes > for interresting tactics on -who- to shoot and -when-. The > player would also have to protect his new lives, or else > the aliens might kill them before the player can use them. Very true... > > CONS - Ummm....Harder to write a plot for. You can't use the "The > aliens are going to destroy humanity!!! Unless -you- can > single-handedly stop them!" plot that is so often used... > How 'bout you're attempting to overthrow the evil alien overlord? Language: C or C++? I just recently saw a flurry of posts which are already beginning to design the object hiarchary. As much as I'd like to agree that OOP could offer a fair bit to this game, I must disagree with their implementation. Just about every object IS the same. In other words, there is no need for objects, etc, as we can have one object_type structure, with possible object specific codes, which can be processed by the AI_ChooseMove, UN_MoveObjects, and FE_RedrawScreen things. Asteroids, for example, have mass, position, velocity, energy (That they can give up to the devourer), energydrain of zero, always do nothing on the AI_ChooseMove. - Jeff Lait (SOL) From ???@??? Thu Nov 17 14:06:54 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA04608 for ; Thu, 17 Nov 1994 12:58:56 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8Ays-000fIrC; Thu, 17 Nov 94 09:50 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56962-2>; Thu, 17 Nov 1994 12:49:07 -0500 Date: Thu, 17 Nov 1994 12:48:42 -0500 From: Jeff Lait Subject: Re: OOP? To: Gert-Jan van Rooyen cc: alife-game@alnilam.krl.caltech.edu In-Reply-To: <505_9411170600@chameleon.alt.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 16 Nov 1994, Gert-Jan van Rooyen wrote: > > On 15 Nov 94, 15:24 mbbad@seqnet.dl.ac.uk murmured: > > mb> i) Agree a certain number of basic classes (note I'm using c++ > mb> terminology what language will we use ?) > > mb> examples of the basic classes of the game might be: > mb> alien/ship/creature > mb> projectile/beam/mine > mb> resource (such as food pellet, rocks, natural phenomena) > mb> ship component (such as a type of > mb> gun/engine/launcher/detector/shield) > mb> program component (e.g a module that can be 'plugged' into the > mb> 'mind' of an alien when it inherits it) > > mb> As an example, consider this last class, it might be defined: > mb> class moving_object { > mb> etc etc > mb> } > > An OOP approach will, IMHO, certainly be the best way to handle the > universe we're planning. I don't think, however, that the classes/objects > you mentioned should be distinct from each other. There are too many > similarities between them, esp. if we're planning "intelligent" > projectiles that are basically asexual, exploding alien robots. > OOP is a good approach, yes. But that does not necessitate the use of C++. Basically, I am against implementing this in C++ because it can be done with about the same degree of effectiveness in C, and make the ASM interface easier to deal with... > A possible class hierarchy could look like this: > > +---------------------------+ > | BasicObj | > | (co-ordinates, direction, | > | velocity, mass, etc.) | > +---+-------------------+---+ > | | > +--------------+ +----------+ > | | > +------------+------------+ +------------+------------+ > | Various "dead" object | | IntelligentObj | > | types, such as astroids | | (supports programs & | > | & food pellets | | program interpreters) | > +-------------------------+ +---+--------+------------+ ^^ But asteroids, food, etc have behaviour patterns, no? > | | > +--------------------------+ | > | | > +------------+------------+ +------------+------------+ > | Projectile | | Alien | > | (data & methods for | | (alien data, pics & | > | intelligent missiles) | | methods. Breeding) | > +-------------------------+ +-------------------------+ Projectiles are aliens with very simple behavior patterns which are written when the alien fires them. For now, they all have identical behavior patterns, but they end up being equivalent to aliens. One thing about this though - all objects have almost the same move, display, and update code. As a result, we could just as easily implement it as one structure, containing the appropriate data for any object, (Remember, behaviour code is shared among aliens of the same species, so there is just a behaviour * which describes the behaviour). The advantage of this is that with our current division, we have seperate groups working on what would be seperate functions of your proposed object class. > The universe could then be a collection of BasicObj types, and a > "timeslice" in the game could be handled by calling a virtual DoTimeSlice > method for each object in the universe. (I'm using Turbo Pascal OOP > terminology... I hope it's more or less the same in C++). Looks like it. DoTimeSlice, would, of course, require the deltaT. Trouble with this again is that collision detection is required around or about here. This requires the global objects to be accessible. IMOO it would be easier to write one physics routine which updates everyone according to their moves (Remember, even Asteroids have a behaviour of sorts: Rotate Left 1 deg. :>) > > Each object should know whether it is visible on screen, and be able to > draw itself onto an off-screen buffer. That should make refreshing the > screen as easy as calling Display for each object in the universe. I > don't know if that's very speed-effective, though... > Current ideas for radar implementation etc only involve checking the bounds of aliens which are VISIBLE. Those off screen will be ignored.. (This is for 1kx1k boxes, as with Martijin (sp?) idea...) Also, as a note, visibility checking requires knowledge of where you (The space ship) is. This requires the opposite approach - redraw alien gets an address of all aliens, and works from there. > Anyway, let me know whether my ideas are "implementable"! :) > Yes, I'd think that they'd be implementable. It is basically a decision of how we wish to actually implement it. - Jeff Lait (SOL) From ???@??? Thu Nov 17 14:07:00 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA13507 for ; Thu, 17 Nov 1994 13:48:32 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8Bog-000fIrC; Thu, 17 Nov 94 10:44 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA88136; Thu, 17 Nov 1994 10:43:53 -0800 Date: Thu, 17 Nov 1994 10:43:51 -0800 (PST) From: Gregory Glen Taylor Subject: Re: OOP? To: alife-game@alnilam.krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK. (1) C++ is a language with a blurry standard. (2) Several people in the group only know C. (3) C has a very clear standard (ANSI C) thus... C is the language. You can devise a nice structure without all of the class-relation mumbo-jumbo of C++. Plus it will be easily portable/understandable by the other members who don't know C++. All of the portable code will be in C. Only front-end's are allowed to choose their language. Any arguments from the directors? Otherwise, C is it... -=GT=- From ???@??? Thu Nov 17 14:17:22 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA17031 for ; Thu, 17 Nov 1994 14:07:03 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA41935; Thu, 17 Nov 1994 11:09:41 -0800 Date: Thu, 17 Nov 1994 11:09:40 -0800 (PST) From: Gregory Glen Taylor Subject: FTP Stuff To: st944m5h@post.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just logged onto the File-Site and played around a bit. I posted two files.... FE-PCX/sample.c - Sample Mode X thing for Watcom C I also made a 'directors' directory and put... directors/poc.zip - Jeff's quick-and-dirty demo of the game. in it. How do I do the appropriate permissions etc. on these files? Currently they're ----rw---- I think... But if you would, tell me how to limit them for member-viewing, and dir director tinkering... etc. sample.c is ok for members to read, no writing (of course), and the poc.zip should be accessable by directors only for read/write. Also could you please limit access to the 'directors' directory to directors only? Currently it's set to the default...whatever that is. In short, I put played around, and you might need to inspect the permissions (and tell me how to change them in the future!) 'bye for now.....-=GT=- From ???@??? Thu Nov 17 14:47:19 1994 Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id OAA21302; Thu, 17 Nov 1994 14:30:58 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Nov 1994 14:36:00 -0500 To: Gregory Glen Taylor From: st944m5h@post.drexel.edu (Michael Mitchener) Subject: Re: That other file Cc: , g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu > 1. Occationally a gene will mutate in an alien and give it the urge > to mate with the player, the alien would approach and do some mating > dance...The player may choose to go mate (and press the breed key > etc.) or they may choose to blast the sucker out of the sky... This adds complexity: how does the alien decide that it wants to breed with a particular entity? How can it convey that desire? How can it make sure that it won't simply be inviting an attack? Obviously, we could set up another flag of some sort, so that when an alien looks around it, part of the information it gets would be whether or not anyone wants to mate, but this, in my view, is unnecessary. An easy way, that would allow these things to possibly develop, would be a simple drop-egg-and-go-away. Not necessarily in front of another alien, but anywhere the 'mother' wants to put it. The aliens could then evolve a decision of whether or not to gaurd their eggs, or to drop it near a member of the same race, or whatever. The egg would be infused with some energy(maybe variable) by the 'mother' and would simply sit there, losing energy. If another alien happens to wander along(or the player) he can decide what to do about it, ie- kill it or fertilize it by giving it some energy. Once the egg is fertilized, it has part(or all) of the 'mother's program and part(or all) of the 'father's program and both of the parents's icons during it's incubation period, it would get time-slices to process the morph and the mix of the two programs. If the egg is fertilized by the player, he gets it as an extra life once it hatches. How's this sound? It gives plenty of time for morphing/gene-splicing, and it should be easy to program. > 2. The player may fertilize other alien eggs if they are > unfertilized, this way the player would have to blast in on a mating > couple and -in effect- steal the eggs. It is assumed that all aliens > can both lay eggs and fertilize them. As mentioned, there should not be a direct mating process(unless derived by their genetic program). > PROS - Offers a new twist on an old game. Also adds a -reason- > not to blast away the best aliens first, 'cause what's left > is the only supply of new lives. If you blast away all of > the good ones, you're left with crappy new lives... Makes > for interresting tactics on -who- to shoot and -when-. The > player would also have to protect his new lives, or else > the aliens might kill them before the player can use them. > > CONS - Ummm....Harder to write a plot for. You can't use the "The > aliens are going to destroy humanity!!! Unless -you- can > single-handedly stop them!" plot that is so often used... plot: How about just the opposite? As someone detailed earlier, *we* are invading someone else's home planet. These aliens have been sent to stop us. Michael Mitchener st944m5h@post.drexel.edu From ???@??? Thu Nov 17 15:08:39 1994 Received: from groucho.phil.ruu.nl (groucho.phil.ruu.nl [131.211.142.32]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with ESMTP id PAA26708 for ; Thu, 17 Nov 1994 15:00:09 -0500 Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id VAA13268 for ; Thu, 17 Nov 1994 21:01:02 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id VAA13680 for st944m5h@dunx1.ocs.drexel.edu; Thu, 17 Nov 1994 21:00:58 +0100 From: Martijn Faassen Message-Id: <199411172000.VAA13680@laurel.stud.phil.ruu.nl> Subject: On mating To: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Date: Thu, 17 Nov 1994 21:00:58 +0100 (MET) In-Reply-To: from "Michael Mitchener" at Nov 17, 94 02:36:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 472 Hi Mike, You seem to be on the same line with us involving mating, Charles and I have also been discussing the egg laying/fertilize scheme. I've just sent a detailed text to Greg describing all this. Don't worry, I think all your ideas will be implemented. :) (it's surprising to see how much people are on one line in this group, all reaching the same ideas semi-independently!) Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Nov 17 16:37:57 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id PAA01262 for ; Thu, 17 Nov 1994 15:22:48 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8DHd-000fIrC; Thu, 17 Nov 94 12:18 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id VAA13562 for ; Thu, 17 Nov 1994 21:16:42 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id VAA13907 for alife-game@alnilam.krl.caltech.edu; Thu, 17 Nov 1994 21:16:36 +0100 From: Martijn Faassen Message-Id: <199411172016.VAA13907@laurel.stud.phil.ruu.nl> Subject: Some notes on the plot. To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Thu, 17 Nov 1994 21:16:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3504 Here's another attempt at a plot, focusing on the alife aspects of the game this time. Here it is, just the raw plot. Human kind has colonized a world (or maybe this is just Earth itself). Then, strange alien ships are sighted (or maybe this is just a human experiment with selfreplicating robotic ships - Von Neumann probes - gone wrong). These ships are destroying all kinds of things, and are therefore deemed dangerous. They're 'berserkers' (theme common in science fiction, self replicating ships out there in the universe to destroy all life..maybe sent off by some paranoid alien civilisation, or some experiment gone wrong, or maybe even *we* were the paranoid people and the results of our berserkers are coming back at us now). A human fleet is sent off to destroy them before it's too late and they're really all over the place, and unstoppable. Lots of this fleet gets destroyed, until only a few ships (perhaps a research ship and a few fighters) are left. The player can configure a fighter (with simple weapons, nowhere near to what the aliens might evolve) and goes out to do something about the aliens. The player knows it would be rather difficult to destroy all of them, when only having a few fighters left. So, he has to do research also. First, the player might be able to obtain scanners of a kind, to scan the amounts of armour or energy or the type of aliens he is encountering. Later, the player might discover how to capture alien 'eggs' (these are somekind of robotic machine constructs or whatever) before it hatches. Then, the player is able to discover how to 'fertilize' the egg for himself, giving some low chance that the born alien is actually controllable by the player himself (as an extra life). Later the player is able to increase the chance the born alien is controllable by the player (and won't be a new alien). The player might learn how to 'mate' his ship (if it's an alien ship he's controlling) with an egg, to get new types of configurations. The player might learn how to add more energy to an egg he mates with, to get better configured new aliens. (the more energy an egg has upon hatching the better the configuration is). Later he might learn how to add *a lot of* energy to create 'boss alien' he can control. The player might learn how to examine eggs (how much energy they have, what kind of configuration is in there). Finally the player might learn how to assemble new ships using alien weapons, and won't be dependent on mating alone anymore (though mating and capturing would still be useful to get new weapons). Another thing the player might do (we don't even have to hard code this in, it can just happen if the player is smart enough) is breeding aliens in such a way (by donating energy to some, and destroying the ones that don't do what the player wants) that they help him..either by attacking other aliens, or perhaps donating energy to the player after gathering it, or being aliens with a good configuration for eggs but 'meek' (not attacking the player), etc. The player flies through sectors of space (semi contineous scenerio, if you don't know what I mean yet, you'll get mail on it soon), destroying the aliens or rendering them nondangerous (though it might be hard to dertermine if an alien is not dangerous..) All this research flows quite naturally from the universe and alife aspects of the game. What do you people think? Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Thu Nov 17 18:51:39 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA04307 for ; Thu, 17 Nov 1994 18:42:37 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8GNX-000fIrC; Thu, 17 Nov 94 15:36 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA89445; Thu, 17 Nov 1994 15:36:06 -0800 Date: Thu, 17 Nov 1994 15:36:06 -0800 (PST) From: Gregory Glen Taylor Subject: the PROJECT STRUCTURE - ***READ THIS!*** To: Evolving Destruction In-Reply-To: <199411172016.VAA13907@laurel.stud.phil.ruu.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII =-=-=-=-=-=-=-=-=-=-=-= - Project Structure - =-=-=-=-=-=-=-=-=-=-=-= This file attempts to outline the structure of the project and how the various sub-groups will be split. It describes each of the sub-groups and what their main function/goal is. Once the sub-groups are set up, the director of each group will send a file detailing the group's aims and goals in greater detail. The discussion thus-far has been mostly on a group-level, with everyone throwing ideas out into the group. This has been a good method for generating a basic outline of what the game will entail. Now that we've gotten that and since the group has grown much larger, it is necisary that we split into sub-groups to discuss the game. Most of the discussion from this point on should be conducted within the sub-group that it pertains to. The directors of the groups will discuss compatibility issues between the groups. In most cases the director will discuss new functions that are needed or the like with other group directors, rather than an individual posting in another group. The directors are a form of middle-management. The will be a group's link to the rest of the project. Only on rare occations will there be group msgs, most things should be discussed in groups. Also, directors are the boss in the group. They will direct how and what will be coded. How a director sets up their sub-group is completely up to them. If you have complaints about how a director is handling things in a group, please post a msg to me (gtaylor) concerning it (but I doubt this will be necisary). This file outlines the various sub-groups and their basic design. It also lists the current directors for each sub-group. If you plan on remaining on the project you must join at least one sub-group. (it is preferred that you not join more than 2). The director will split the work load up amongst the various members according to their desires as well as the skills each member has. How to join a sub-group ----------------------- email : gtaylor@oboe.aix.calpoly.edu with the Subject as 'SUB-GROUPS' then the body of the message will contain a brief list of one or more groups you'd like to join. Please don't waste your time detailing the -exact- role in the group that you'd like to play, tell that to the group director, later. Soon, mailing lists will be set up for the various sub-groups and the directors will send a msg detailing their plan of attack. ---------------- - Universe.h - ---------------- Director : Greg Taylor - gtaylor@oboe.aix.calpoly.edu The header file for the game outlines the parameters and names of all of the global functions. This way all of the functions in the various sections of code will be able to call functions in other sections of code (ie the Universe can call Front-End routines). The code can then be worked on independently, and the other groups will know how to access and what data to send to the external routines. This will keep compatibility high and re-coding to a minimum. The key to a sucessful Universe.h is a -complete- function list which has all or nearly all of the global functions and variables that will need to be accessed by the other groups; because adding forgotten functions will mean work for -all- of the groups...which could possibly be avoided. *********** SUB-GROUPS ************ ---------------- - Front Ends - ---------------- FE-PC/X Director : Jeff Lait - jmlait@undergrad.math.waterloo.ca FE-Mac Director : Mike Mitchener - st944m5h@post.drexel.edu FE-Amiga Director: This section of the code is the only machine/compiler specific code. It may be coded in assembly, or whatever the FE team deems they'd like to do. The only restrictions is that it must be accessable by the C header file (universe.h), so the functions must be written so that they will be able to be accessed through those defines... It will include : Graphics: Setting the mode, sprite manipulation, fonts, and a 'movie' displayer that will display our standard intro and plot sequences (we'll develop a standard .mov file which will have various pictures and sounds/music in a sequence). Tmapping: The texturemapping routines will be written in the front-end, in order to be optimized for the machine being used. Compile: Routines to compile 24bit-colour pictures into the specific size and color-number for that Front-End. The original ART/SOUND .mov files will have 640x480x24bit, this will need to be reduced to a machine specific .mov file. Sound: Playing midi files or mods (not sure yet) also sound efx, will have to work closely with the Art/Sound team in order to implement their ideas effectively. Control: Keyboard caching (grabbing multiple chars if multiple are pressed, ie turn+acc+fire), joystick control, mouse control etc. Timer: A function which will allow us to have a local variable passed to it updated every screen-redraw. Allows us to determine how far ships accelerate, etc. The sound is still in question for which file formats it will use, most likely midi's or mods to increase portability. If evolving music is developed by the Art/Sound team, then that will have to be implemented. The most likely 'general' function for the FE for sound will be a 'int Music(blah, blah:junk);' type thing, then the FE group would either call a routine written by the Art/Sound group or perhaps send a midi file etc... As for the '.mov' file. I envision this as a file with large x large x 24bit original pictures for the intro sequence, with embedded music and sfx. This way when a FE group is fine-tuning for their format, they can run a converter program on the .mov file to reduce the pictures down to the desired size for that FE. The pictures in the intro will likely be Ray-traced, 'cause drawing frame after frame of large x large x 24bit pictures by hand is a weighty task. The actual .mov files will be produced by the Art/Sound group, and the FE need only convert and display them. Other Front Ends may be formed if someone will direct a group to code them. The FE-PC/X will need to be developed first, this is because the PC is the most common computer within the development team, thus it would be most useful to test other group's routines. Other groups can either wait for the FE-PC/X to be reasonably finished and convert that code -or- code simultainiously. BTW for those who don't know, PC/X means DOS format (perhaps DOS4G...do we have enough Watcom C users out there? I'm one. Do I hear two?) with mode X VGA graphics (of some resolution). -------------- - Universe - -------------- Director : Adrian Tymes - uwingcat@mcl.mcl.ucsb.edu This portion of the game will be written in standard ANSI C. It contains the main() procedure and is basically the 'controller' of the game. It will call FE routines for it's user input and output, use Alife and Art/Sound routines for generating the aliens and their behaviour. Aside from it's control-center aspect, it also handles things like the physical aspects of the universe, acceleration, turning, etc. This text specifies the Universe part of the game. Anything that is not basic will have the word OPTION: in front of it. The Universe ------------ - is relatively independent of the actual front-end. - is flat; 2d. - has wrap around borders, and has thus no borders, but it's finite too. The Objects in the Universe --------------------------- - each have a speed (may be zero). - are inertial, so do not slow down without any force on it. (no friction) - each have a _objective direction_. The direction angle is 0-255. 0 is N, 128 is S, etc. This is the _objective direction_. - each have a _facing direction_, which is the direction the object is facing, usually the same as the _objective direction_. 0-255 deg as well. - can turn smoothly. 16 different rotations is probably enough. [though we might just send the _facing direction_ to the FE and let them decide how many rotations to implement..:)] - As someonme mentioned, we should also include mass. Kinds of objects ---------------- The ships --------- - can turn left and right. - can add thrust. OPTION: Side and reverse thrust have been discussed... - have two types of energy: 'Armour' : How many 'hit points' the ship has left, before it dies. 'Usable' : Energy it has to fire, mate, move, etc. - decrease armour energy (and perhaps Usable as well) if hit by a weapon. - can gain energy by eating energy pods (perhaps the remains of killed enemies, eggs, and misc other sources). OPTION: this might be 'plant growth', or asteroids, or pods that come free when a ship is destroyed. This remains to be decided. - can fire their weapons (up to two weapons?). - can view the reletive direction that another object is facing (facing towards or away from the object, etc.) - can view the distance another obj is at. - can view the speed (relative speed?) another obj is flying with. The player ship --------------- - is controlled by the player, by a 'thrust' key, left and right rotation keys, a fire key. OPTION: a breed key, an eat key, a 'weapon option' key, etc. The aliens ships ---------------- - are controlled by alien pilots. A pilot is a piece of behaviour code. - have essentially the same control methods as the player, using 'virtual' keys. (they call the same functions as the ones that get called when a key is pressed by the human) Projectiles (missiles, bullets) ------------------------------- - can collide with ships. The ships loose a certain amount of energy when hit, dependent on the type of projectile. - may have very primitive behaviour code in them. Projectiles may evolve! OPTION: energy donation projectiles might also exist. Vampiristic projectiles can also exist. (they suck energy out of the ship that is hit, and transfer it to the ship that fired the projectile) - are always destroyed upon collision. (they explode) - are fired by ships. (of course :) Other objects ------------- Asteroids, obstacles, energy pods, plants, motherships, etc. ----------- - Alife - ----------- Director : Martijn Faassen - faassen@phil.ruu.nl Director : Charles Ofria - charles@krl.caltech.edu This piece of code must be written in either C or C++, preferrably C, we'll let the Alife group decide (C++ is fairly non-standard right now, but ANSI C is a portable standard. I think there's a C++ standard too...hmmm). Anyway there will be a few types of routines that the Alife group will have to develop: A routine to decide an alien's bahaviour (this will be the -main- procedure that they'll write), which will obviously call probably several smaller, local procedures to decide upon a behaviour. The output will be in the same format as the human player's controls (ie left, right, thrust, begin mating, fire weapon A, fire weapon B etc). This procedure will have access to all of the global variables... - Aliens may access the map within a certain range, just like the human player's viewwindow. - Aliens may access a set of alien-only variables. These would be things like global distress calls, species group action calls, boss presence and other vars which an alien might respond to. This will be the alien equivilent to the player's radar. - Alien may access other aliens stats etc. (for mating purposes...) This section includes all of the Genetic Algorhythm stuff that will dictate alien behaviour etc. --------------- - Art/Sound - --------------- Art Director : Jeff Lait - jmlait@undergrad.math.waterloo.ca Sound Director : This group will be in charge of either producing the pictures and music/sfx or writing routines to produce it (the latter is obviously preferred). Their code will have to be a C/C++ standard (ANSI C or the C++ standard), as it will also have to be portable. Also the sound, music, sfx files should also be done in a format that is easily portable. Note that currently Jeff is the director for the whole group, but a co-director to manage the sound specifics is still being sought...any takers? ------------- - Summary - ------------- OK, it's time for everyone to split into sub-groups. Please send me a simple msg with all of the subgroups you'd like to join (try to keep it to two max). If a group is still lacking a director, I will be accepting volunteers for those too. If you'd like to start a new FE, tell me about it. That's it for now....-=GT=- Greg Taylor From ???@??? Thu Nov 17 18:51:41 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA04342 for ; Thu, 17 Nov 1994 18:42:52 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA40532; Thu, 17 Nov 1994 15:45:30 -0800 Date: Thu, 17 Nov 1994 15:45:30 -0800 (PST) From: Gregory Glen Taylor Subject: Re: FTP Stuff To: Michael Mitchener In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I can't change individual file permissions from my end(I have to log in > first). So any file put into any of the folders other than the director > folder can be changed by any director, and can only be looked at by > members. In a few minutes, there will be an upload directory for members > to drop stuff here. I actually don't know how you could limit individual > file permissions, although I'm sure there's an ftp command. > > >sample.c is ok for members to read, no writing (of course), and the > >poc.zip should be accessable by directors only for read/write. > > right...but directors can change sample.c and poc.zip....this is okay, right? > Directors have full r/w privilages (except stuff that you want to limit us from doing...of course). Members may only write to the incoming directory. (when you add one). The directors directory should be marked as off-limits to all members, only director access. > >Also could you please limit access to the 'directors' directory to > >directors only? Currently it's set to the default...whatever that is. > > Only directors can create directories, and the permission for those is > defaulted to: owner:director has all privileges, nobody else has any > access. When you make a directory, if you want a different permission > set-up, let me know, and I'll take care of it. > > > I'll take a look at the doc's on my daemon, hopefully, they will explain. > I'll let you know what I come up with. > > > btw: the new mailing lists are not up yet....I tried to send to all > directors, but it seems I'll have to do it manually, or create my own temp > list. > Yep, I've got my own little list too :) He's working on them, I'm told. (but the group doesn't even know of their existance, or the File-FTP site too...it will be quite a shocker to unveil our 'system' to them....:) More later....-=GT=- From ???@??? Thu Nov 17 18:51:41 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id SAA04765 for ; Thu, 17 Nov 1994 18:46:46 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA41557; Thu, 17 Nov 1994 15:49:12 -0800 Date: Thu, 17 Nov 1994 15:49:12 -0800 (PST) From: Gregory Glen Taylor Subject: Re: That other file To: Michael Mitchener Cc: charles@krl.caltech.edu, g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is in regards to Mike's mating theory....I like it! I also like Martijn's plot...though I'm unclear as to whether they're aliens or robots or...both. Hmmmm.. I just got mail, I'll post again later....-=GT=- From ???@??? Thu Nov 17 20:13:35 1994 Received: from violin.aix.calpoly.edu (violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id UAA15664 for ; Thu, 17 Nov 1994 20:04:49 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA72218; Thu, 17 Nov 1994 17:07:23 -0800 Date: Thu, 17 Nov 1994 17:07:23 -0800 (PST) From: Gregory Glen Taylor Subject: The Important Stuff To: AI Game Design Team , g-j@chameleon.alt.za, jmlait@undergrad.math.uwaterloo.ca, Martijn.Faassen@phil.ruu.nl, st944m5h@post.drexel.edu, uwingcat@mcl.mcl.ucsb.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I posted the first part of the Important Stuff series. I'm still waiting on revisions/additions to the second one. If you haven't already sent me your addtions, please do so soon. I want to begin compiling a final draft tomorrow. I have a mid-term tomorrow, so I can't work on it tonight. But tomorrow and thru the weekend I'll have enough time to catch up. I'm taking another little vacation home starting Tuesday Afternoon (PST) for a holiday several of you may be familiar with...Thanksgiving, we get together with family and eat a lot :) That's about it really. Anyway I'll be getting back the next Sunday night. I'm trying to get many things all set up before I leave, but I have faith in you guys and know that you can handle things without me around. All of you should be beginning to write up your outline of your group. Please lay out a nice info file on the subjects you want to tackle in the group, you will then post this to your group when there is a reasonably sized group together. You should also be synthesizing the -order- you want to take stuff on, and -how- you want to split it up amongst your members. Place this file on the Info-Site (ftp.krl.caltech.edu). Charles, if you could, set up a directory for these? Thanks. Also the 'directors' directory is set up on the File-Site (144.118.44.96) where we can post stuff and keep it away from member access. Please use your director status on the site carefully, you have a lot of access... use it responsibly. 'poc.zip' (Jeff's quick-and-dirty demo of the game) is available there for those who didn't get a good copy thru his mail msg. Jeff : Gert-Jan is interrested in helping with the direction of the FE-PCX group. Please discuss it amongst yourselves and tell me the verdict. The schedule of events are as such... Next few days : 'limbo' while we wait for sub-groupers to sign up. Also we work out the kinks in the Q/A file thing. This Sunday or so : Set up the mailing lists. Send out the Q/A file. Next week sometime : send out your info-file on your group to your group and to the info site. That should cover things. 'bye for now...I've got a test to study for! -=GT=- From ???@??? Thu Nov 17 21:09:52 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id VAA23945 for ; Thu, 17 Nov 1994 21:03:50 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8IiL-000fIrC; Thu, 17 Nov 94 18:06 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA21761; Thu, 17 Nov 1994 18:04:44 -0800 From: Charles Ofria Message-Id: <9411180204.AA21761@altair.krl.caltech.edu> Subject: Testing... To: ag-directors@alnilam.krl.caltech.edu Date: Thu, 17 Nov 1994 18:04:43 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 216 Just a test of the ag-directors@alnilam... mailinglist. If you get this, it means the list is up. I'll link the list over to the admin subdirectory of alife-game so people can take a look at it. --- Charles From ???@??? Thu Nov 17 23:40:55 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id WAA08004 for ; Thu, 17 Nov 1994 22:38:02 -0500 Received: from iitbarr.iit.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8Jvy-000fIrC; Thu, 17 Nov 94 19:24 PST Received: from iit.iit.com by iitbarr.iit.com (4.1/AI-4.10) id AA09086; Thu, 17 Nov 94 19:15:59 PST Received: from manila.iitengr by iit.iit.com (4.0/SMI-4.1) id AA03396; Thu, 17 Nov 94 19:20:05 PST Date: Thu, 17 Nov 94 19:20:05 PST From: brett@iit.com (Brett Coon) Message-Id: <9411180320.AA03396@iit.iit.com> To: alife-game@alnilam.krl.caltech.edu Subject: Re: Devils Advocate Brett> Since the exciting part of this project is the evolutionary Brett> stuff, wouldn't it be more efficient to find an _existing_ game Brett> that's in the public domain, and add evolutionary control mechan- Brett> isms to it? Andy> Apart from the fact that this would be totally unoriginal, it would make Andy> things a *lot* harder. Each part of this game is going to have to work Andy> together in extremely specialised ways. For originality, I think the primary new idea here is having op- ponents who get smarter as you play. Once the learning engine is working, it could be applied to a variety of other (more origi- nal) games. As for making it harder, I think it depends on the original game and how far you want to deviate from it. Adding evolving graph- ics and sound, egg collection, and network play to xinvaders, for example, would certainly be more work than it's worth. Just modifying it to allow individual alien motion might be much easier. Andy> The main idea of this project, as from Christian's first post, is to Andy> create an action game that provides more of a challenge and interest to Andy> the player because of evolving aliens. This is, of course, the special Andy> part of the game, but it needs to be supported by the game itself. The Andy> behaviour that evolves will have to interact with the environment, and I Andy> seriously doubt that "Space Invaders" would do it credit. "Space Invaders" was just an example, of course. The point I tried to make is that the proposed game concept requires fairly complex control for the aliens, which will cause their evolution to proceed much more slowly than if they had fewer variables to control. Even controlling an alien in Space Invaders effectively is asking a lot from an evolved creature. Andy> Another thing to remember is that the evolving code is not just going to Andy> change the behaviour of the the aliens, but how they look. We have Andy> already discussed the difficulties behind evolving graphics....and it Andy> won't be too easy. My point exactly. It won't be easy, and _might_ not be feasible. Andy> Even if we just used another game to start off with, how would the Alife Andy> engine be tested? Anyway, enough from me. The same way it would be tested in original game code: let it control some aliens and see how it does. -Brett +------------------------------------------------------------+ | Brett Coon - brett@iit.com or brettc@leland.stanford.edu | | Integrated Information Technology Inc. (408) 654-0936 | +------> finger brettc@leland.stanford.edu for PGP key <-----+ From ???@??? Fri Nov 18 06:43:34 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id GAA15619 for ; Fri, 18 Nov 1994 06:34:24 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8QyN-000fIrC; Fri, 18 Nov 94 02:55 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id ab21680; 18 Nov 94 10:52 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA002ys; Fri, 18 Nov 94 10:35:33 GMT Date: Fri, 18 Nov 94 10:35:33 GMT Message-Id: <9411181035.AA002yr@darkin.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Reply-To: christian@darkin.demon.co.uk From: Christian Darkin To: alife-game@alnilam.krl.caltech.edu Subject: energy and food Here are a couple of ideas about energy and feeding: We`ve been having problems thinking just how energy should be managed, won, lost, etc. How about this: Each creature stores its energy in batteries. Each battery has a maximum amount of energy it can contain (that way a creature can`t just stuff itself to the point at which it is all powerful). Now, a creature has one power battery for each of its` abilities (one for life support, one for motion, one for shields, one for firing, etc) When ever it does anything, the energy required to perform the task comes out of the relevant battery. The creature can move energy about from one battery to another, but it takes *time*. This idea will force aliens to learn power management, and also give them a whole load of possibilities for their development (an alien can keep a lot of power in its` shields, or keep more in its firing battery or whatever). It will also mean that the creature can`t just (for instance) reel off a whole volley of massive missiles unless it has: a) evolved a big enough firing battery to keep that kind of power and b) had time to refil that battery from one of its other batteries since it last fired When either the shield battery or the life support battery is completely empty, the creature dies. It`s as simple as that. My second idea is about food. I vote that when one creature feeds off another, it does not simply drain energy from it. I suggest this: When feeding, an alien (somehow) compares the genetic structure of its food with itself. Using some kind of method based on that, it calculates a food value (which may even be negative) for its prey. It then reduces the energy level of the prey accordingly, and adds it to its own. Why so complecated? Well, with this system, different creatures will eat different foods, and different creatures will get different benefits from each food depending on their own genetic structure. Depending on who you are and how you`re put together, you`ll find some other creatures very palatable, and others will just make you ill (a negative food value, reducing your energy). We`ll also have the advantage that a creature will very rarely be able to extract all the energy from its kill, and will leave scraps for other species to feed on. Just like real life. This idea will give us a real advantage when it comes to bio-diversity. In the real world, there is room for both the elephant and the ant simply because they`re not in direct competition. They don`t eat each other and they don`t fight over the same scraps of food. -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Fri Nov 18 06:43:37 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id GAA15626 for ; Fri, 18 Nov 1994 06:34:35 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8RAa-000fIsC; Fri, 18 Nov 94 03:07 PST Received: from laurel.stud.phil.ruu.nl (faassen@laurel.stud.phil.ruu.nl [131.211.140.48]) by groucho.phil.ruu.nl (8.6.8.1/8.6.6) with ESMTP id MAA27598 for ; Fri, 18 Nov 1994 12:06:22 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id MAA27161 for alife-game@alnilam.krl.caltech.edu; Fri, 18 Nov 1994 12:06:20 +0100 From: Martijn Faassen Message-Id: <199411181106.MAA27161@laurel.stud.phil.ruu.nl> Subject: Re: Energy and such... To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Fri, 18 Nov 1994 12:06:19 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5808 Christian, everybody, Charles and I had a discussion on energy too, this is what it turned into. I forward it here to you people, though it'll be part of the universe design eventually. (which is being created, everybodies help is requested, I'll be working on it next week..mail me for more info) But since there's discussion on it. I hope it incorporates some of your ideas satisfactorily, Christian. Here's the version I wrote up (Charles might disagree with parts, I don't know :) > > Energy and reproduction > ----------------------- > > - Each creature has upon birth an amount of energy determined by how much > config money it invests in start energy. > > - When a creature lays an egg, it always costs a minimum amount of energy, > plus a certain amount of energy it puts into it. > > - As time goes on, the egg slowly loses energy. > > - If the egg runs out of energy before being fertilized, it dies. > > - If another creature comes along and fertilizes the egg, it also can add > energy to it if it chooses. > > - A set (short) amount of time after the egg is fertilized, it hatches. > > - The newborn alien will have an amount of config money dependent on the > energy left in the egg. > > NOTE: this might be a natural mechanism to get 'boss' aliens. Their parents > simply invested in them a lot. > > OPTION: how much energy is needed to lay an egg, how energy left it transferred > into config money (which ratio), etc, can all be determined by the player in > 'god' mode, and we'll also supply some standard scenarios. (In the semi > contineous scenario the ratios might change each 'level') > > - the aliens should be able to see how much energy is in the egg to make > their choice to fertlize it or not. > > NOTE: they may want to only fertilize eggs with a lot of energy so they > don't have to add their own. Then again, they may just want to eat eggs > with a lot of energy. :) > > OPTION: an alien might also be able to see the 'relatedness' of the egg > to itself. It might only want to to fertilize related eggs. > > OPTION: the egg might be able to see the 'relatedness' of the fertilizing > alien, and might choose not to get fertilized dependend on that. > > OPTION: the player might learn how to capture eggs, and how to 'fertilize' > them to get more 'lives'. Later the player might also be able to look > at the amount of energy in the egg, to look at the 'relatedness' of the > egg, and to choose the amount of energy he invests in it. Also he might > be able to increase the chance that the egg might be his instead of becoming > a new alien. (See my notes on the plot, coming soon) > > Ways to spend energy > -------------------- > > - doing nothing - energy drains (at a very slow rate) in time. > - using thrust - proportional to the amount of thrust used. > OPTION: the energy costs might increase exponentially for a linear increase > in thrust. This should be a settable option in 'god' mode. > - turning - minimal energy costs > - shooting - creatures control how much energy they put into each shot. One > big one might do more damage, but it's also more of a waste if it misses. Also > it's a waste if it overkills. Smaller ones might in these cases be better. The > alien should be able to work their own system for this. > - things like 'range' and 'size of onboard program' influence the energy cost > of the weapons. > - laying eggs (see previous section. > - investing in armour energy - the alien can transfer energy into its armour. > OPTION: the aliens might also be able to draw energy from its armour. > > Armour > ------ > > The armour decreases when > > - Getting shot > OPTION: when bumping into another object. > OPTION: the alien might also loose an amount energy when hit. > > When the armour reaches 0 the alien is destroyed. > > Ways to gain energy > ------------------- > > - hitting another creature > OPTION: this might be turned off completely too. > OPTION: this might be based on the 'relatedness' of the two aliens. The less > related, the more energy the aliens receives. The player is obviously the > least related. This might encourage collective behaviour. > OPTION: the player should be able to fiddle around with this (like everything > else) in god mode. > > NOTE: collective behaviour without the received energy dependend on the > relatedness of the hit object might also evolve, as long as aliens are > able to scan relatedness. > > - eating dead aliens > OPTION: this might be turned off completely too. > > - eating a power source or an egg. The environment should naturally grow > power sources for the creatures ('space plants'). Some creatures might > specialize in eating thoses, others might specialize in attacking other > aliens (or the playing). > > OPTION: getting hit by 'energy donation bullets' > OPTION: an alien might be able to fire 'vampiristic' bullets which drain > energy from the hit alien into the alien that shot the bullet. > > That's it. Hope you like it. :) > > I know this is all universe design, but Charles and I seem to be doing > this too at the moment. :) (close cooperation between alife and universe > is necessary anyway) > It seems to be the case that everybody is doing stuff not directly > in their group (Jeff for example is currently also doing universe stuff). > We shouldn't discourage this, otherwise people might be discouraged to do > anything at all anymore. The group structure is fine, but shouldn't limit > anybody. And, of course, the directors should be able to communicate > anyway. > > Good luck, and keep up the good work! > > Martijn > -- > Martijn Faassen email:faassen@phil.ruu.nl > > -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Fri Nov 18 10:47:56 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id KAA08428 for ; Fri, 18 Nov 1994 10:40:00 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8VF6-000fIrC; Fri, 18 Nov 94 07:28 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA25967; Fri, 18 Nov 1994 07:27:21 -0800 From: Charles Ofria Message-Id: <9411181527.AA25967@altair.krl.caltech.edu> Subject: Re: energy and food To: christian@darkin.demon.co.uk Date: Fri, 18 Nov 1994 07:26:50 -0800 (PST) In-Reply-To: <9411181035.AA002yr@darkin.demon.co.uk> from "Christian Darkin" at Nov 18, 94 10:35:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1318 Sender: charles@altair.krl.caltech.edu Christian, You have some good ideas with making aliens do energy management between the batteries, but that adds on a large complexity that I'm not sure how well they'll be able to handle. I think we should keep this idea, as a potential, but hold off on it until we have them evolving using only one battery. Energy management is not something that will evolve quickly. As for your second idea, this I do really like, but again its a complexity. I had suggested an idea in a similar vein where food vaule is simply determined by your hamming distance from the other creature. The more different you are, the more you get from killing them. This discourages creatures from killing their own kind, and encourages them to go after the player (who is maximally different). I would be interested to hear your ideas on what kind of detailed "diet" system we should have... The reason I'm hessitent on discussing all these complexities right now is because we honestly don't know what this soup is going to turn into! Once we have the first few steps done, we'll have a better idea of where its going. The only thing I can garentee is that there will be many aspects different from what we expect - I'm not sure good or bad, but there is no way we could predict everything in terms of Alife. --- Charles From ???@??? Fri Nov 18 12:13:20 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id LAA21456 for ; Fri, 18 Nov 1994 11:57:40 -0500 Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8WRX-000fIsC; Fri, 18 Nov 94 08:45 PST Received: from s-crim1 by mserv1.dl.ac.uk with SMTP id QAA10223 (8.6.9/5.3[ref pg@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Fri, 18 Nov 1994 16:39:49 GMT Precedence: first-class Received: by s-crim1 (920330.SGI/930817.MJE) for alife-game@alnilam.krl.caltech.edu id AA24376; Fri, 18 Nov 94 16:39:44 GMT Date: Fri, 18 Nov 94 16:39:44 GMT From: mbbad@s-crim1.dl.ac.uk Message-Id: <9411181639.AA24376@s-crim1> To: alife-game@alnilam.krl.caltech.edu Hi, I read everybodies messages and jotted down the points I wanted to reply to, so there's no quotes: (i) Somebody suggested an "alife-vs-simulated player" scenario for tuning aliens in the background. I don't think this is practical or necessary, a simulated player can't ever hope to approach the abilities of the real player *and* the alifes get enough examples of playing each other during the real game. (Which isn't to say it's not a clever idea.> (ii) People spoke about 'Modular design' let me second this, it's essential ! (iii) Somebody is keen on neural nets, I see a number of problems to this: (a) how do you implement the input ? If you have a neurone to space correspondance then that's quite a lot of neurones, but if you try to include the speed/heading and type of each visible object then surely it gets out of hand. (Has nobody ever produced a variation on a neural net to allow a more ready interface to other forms of data (such as a system where a whole slab of neurones can be 'cloned' to handle more examples of an object ?) (b) doesn't (number of neurones) * (number of ships) add up to quite a slab of processor power ? Which isn't to say that it shouldn't be tried, just not yet. (if we make the interface well enough then no problem) (iv) Somebody said (have you noticed that I can't tell you apart ? Sorry guys but all humans look the same to me ...) that we must not rely to much on the evolution of the bad-guys. I agree 100% with this, we let them evolve but we have to help them out in as many ways as possible, ideas are: (a) libraries of "known winning combinations" one of which 'wanders in' every now and then. These libraries could be updated during play, swapped with friends, edited by the player etc etc. (b) 'elitism' accross generations (and into the library of course) (c) construct the form of the control language as appropriately as possible (see (v) below) (d) construct the physics of the arena as amenably as possible (e) do cross-breading as intelligently as possible (shouldn't be too hard to reject any 'still-born' programs/bodies before they enter the game (re-roll them). (f) somebody mentioned fitness-functions, I don't like this, see below. (v) The representation of the control language must be done as carefully as possible. I still recomend an 'interrupt driven' system where each program would consist of a number of routines, each of which was called when an appropriate event occured (note the alien's ability to percieve those events could also be filtered through its hardware). To enable time-spanning strategies, some of the 'events' could be purely internal ones set up by other routines, e.g EVENT_SEE_ENEMY(x,y,speed,dir) { location dest; dest = _compute_intercept_(); _set_coursei_(dest); _enable_future_interrupt_(BEGIN_ATTACK,_location_reached_,dest); } where CAPITALS indicates the names of modules in the program, _surrounding_underscores_ indicates the games built-in functions The final line is the critical one. This sets up an event to call the routine "BEGIN_ATTACK" when the alien reaches the location "dest" (vi) Somebody suggested a 'gene-stealer' this is OK but don't we already have that if we use breeding ? I think this might be more fun if we just let the player use it to steel alien hardware (visions of desperately trying to find an alien with the new gun which isn't invincible). I have other thoughts on hardware, below. (vii) Eggs, I'm not sure how much I like these (well actually I like them a lot but I think some of the schemes suggested are a bit complex). Perhaps fertilisation should be taken as read (i.e assume it can be done over quite a distance) and the energy required in laying the egg should be a function of the size/complexity of the child. (viii) Energy, should we make the aliens search for every joule of energy ? I think not (because it makes the simplest program required for survival more complicated) rather I think that each alien should have (a) an energy source that provides energy at a fixed rate (b) a limited store where any excess energy can be banked for future use People have also suggest that aliens should use energy when doing nothing. I'd rather that wasn't the case (after all they might have to cross a large empty space) and that they could survive without 'winning' any energy but that were advantages if they did so. I think its a good idea to let the aliens allocate their own energy useage, this would (for example) permit the production of a "power only the shield and engine" type of creature (it could ram, or it could hang around the edges of battles and steal the booty). (ix) Plot: Like the question of money, lets decide this *after* we have a game. (x) Virtual Keys: Good but remember that the aliens are different from the player (aren't they ?) so perhaps their keys would be a bit different. Also, somebody said that this would enable the ready addition of different classes of weapon. This is true but it doesn't permit the addition of multiple weapons (or different firing options) very well. An approach to this (which just this instant came to me) would be a hardware_slot *_best_match_(hardware_type *z); function which enabled the software to do things like: "power up the hardware that best resembles a long-range scanner" "select the gun with the smallest energy cost" "load the missile with the widest blast" etc etc (xi) Collision: Is this dangerous ? Can we expect the evolved programs to navigate well enough to avoid it (can we even write a program to do that) ? Perhaps we should 'hard-code' this part (sort of like having the alien issue commands to its pilot-routine) and just let the evolution play with a couple of parameters such as default_speed navigation_care (xii) Hardware: Many people have mentioned hardware in passing but nobody has really approached the issue in detail. I think that the hardware should be evolving too. I think that to do this you have to make the hardware modular and then let the eggs plug it together in any order they like (well not *any* order but you get the idea) for example their would be a superstructure_ module with sockets into which the egg would plug weapons/detectors/ shields/cloaking devices (the engine would *have* to go in the engine_socket) etc etc. In addition to this I think that the devices should each consist of a small number of sub_modules (Isn't that needlessly complex ? Well no, it's just a neat way of producing a large variety of things and *ensuring* that the weight and cost are appropriate to the device created because the sub-module weights/costs are just summed). This has great advantages: (a) not all the sub-modules are present in the initial population but can be introduced later when things get dull (b) it fits very well with sexual evolution because a child can use a selection of the modules available to its parents (how it uses them is part of its control program) (c) the introduction of a single new sub-module leads to the production of many new forms of device As an example, a beam_weapon consists of: - an energy buffer (which determines how much power in the beam and how fast it can be charged) - a beam generator (which determines the type of beam) - a projector (which determines the shape of the beam, plain, conical, double, pulsed ...) (xiii) Morphing: I don't like this ('cos after a while all the ships look the same) but if we use the modular hardwar suggested above then the appearance of the ship is determined by simply pasting the appearance of the correct sub-modules onto the right places of the superstructure. (and the final image is then rotated to give each possible appearance) (xiv) Sex ? Do we need sex during game-play ? (Do you, personally :-) Or would it make more sense to let the aliens reproduce asexually during the game and do the recombination between rounds. This makes sense because: (a) no need to make provision for breeding in the aliens behaviour code (b) the child-generation procedures don't have to be done in real time (c) the player can get used to the inhabitants of each round but gets them rearranged in the next round (don't know why this is good but it *feeels* like a good thing) (d) this way we get to use a fitness function between the rounds (enabling us to boost the efficiency of evolution) but within the rounds the fitness is implicit in the actual achievements of the aliens (e) within a round all aliens of a given type have exactly the same program/hardware. This makes it much easier to breed in cooperation/slavery (because they can choose to trust messages from their own kind) (xv) Perception: I raised this as an objection to neural nets but it's a more general problem, how do aliens percieve each other ? If we do the sex between rounds then its easy ('cos there is only a finite number of 'types' in each round) otherwise we have to start doing thing like remembering who shot us or trying to decide who a given alien is descended from (in case they shot us). (xvi) Teams: Do we want to split the alife team into a software and hardware sub-teams ? How do you get into a team ? Is anybody in one yet ? That's it (long wasn't it) just wanted to say how impressed I was with the number of ideas flying around but that its a bit worrying 'cos there's obviously too many of them for the initial projects. Still, this always happens in these things and it should settle down soon (?). Badders From ???@??? Fri Nov 18 12:45:56 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA28053 for ; Fri, 18 Nov 1994 12:38:05 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8XBF-000fItC; Fri, 18 Nov 94 09:33 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r8X9P-0004UeC; Fri, 18 Nov 94 19:31 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02474; 17 Nov 94 06:00:52 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 14:17:06 +0200 Subject: Re: universe Message-ID: <507_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu On 15 Nov 94, 03:42 Christian Darkin wrote: ch> Also, objects should have MASS. That'll be very religious of them... ;) ch> That way, a force (engine) used on a ch> small light ship will allow it to travel much faster than the same ch> force on a big, heavy ship (a boss ship, for example). Thus, bosses ch> don`t zip around like mad things, and there will be a nice kind of ch> payoff between speed and power (armourment, etc). Excellent idea. BTW, one nice thing in Star Control II was the effects of gravity: if you came close to a planet/asteroid, you experienced a gravitational force. This could also add a nice twist to our universe, if the calculations involved (three multiplies and a divide per object combination) won't eat too much time. ch> We`re out to produce a constantly shifting ecosystem which creates ch> strange and wonderful variations on subtle, elegant answers. Hmm, poetic! :] But I agree... More than that, I think we should remember that we want to create an ultra-playable, ultra-exciting, ultra-marketable GAME! The player should be intrigued by every moment of the game, there should always be something new, the plot should always be unfolding, etc. Making a game with some smart computer opponent isn't enough - the game should be intense fun! ch> Here`s a thought: What about releasing an `alien writer` allong with ch> the game so people can build their own (we`re going to have to write ch> one anyway) Then we can encourage people to swap their invented (or ch> evolved) beasties around. We could set up a kind of FTP site `gene ch> pool` where people dump and collect strange creatures! Good idea. ch> Why not make the projectiles just aliens written in a different way to ch> other aliens. (ie, they`d have no desire to mate or be mated with. ch> They wouldn`t be able to be shot - or maybe they would. They would ch> only have one movement pattern, etc.) That way, when two creature`s ch> mated, you could just mate their bullets in the same way. Excellent! Intelligent ammo would be ideal... Of course, then the player could also be able to obtain "intelligent ammo" in some way. ch> Why have aliens and pilots and ships? Why not just say the aliens are ch> part organic, part machine. They are advanced reproducing robots which ch> use nannocomputers and GA`s to evolve. That way our plot and what ch> we`re *really* doing become interwoven to make a sort of surreal point ch> about the future of *real* computer technology. (You can tell I`m a ch> writer!) Good idea. The aliens have, over thousands of years, "enhanced" themselves with electronic and mechanical equipment. This was not a mere superficial enhancement... the aliens altered their original genetic coding, so that their offspring would actually "grow" these bionic organs. It became part of their living bodies. Over many years of evolution, the inefficient organic parts of their bodies were naturally replaced by electronic and mechanical counterparts. The shape of their bodies adapted to be more efficient in space travel. When the player meets them for the first time, they are already a race of efficient semi-robotic killers, but still capable of reproducing... ch> How about alien/player crosses coming out as live young, not eggs. ch> They can be sort of jelly blobs which wander about. Their movement ch> patterns would mostly make them stay in groups, but occasionaly wander ch> about alone. That way, the player would have to try to keep his ch> clutch under control as they were attacked, and the player tried to ch> wipe out aliens. ch> We should have qu From ???@??? Fri Nov 18 13:11:41 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA28842 for ; Fri, 18 Nov 1994 12:42:40 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8XHt-000fIvC; Fri, 18 Nov 94 09:39 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r8X9P-0004UdC; Fri, 18 Nov 94 19:31 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02473; 17 Nov 94 06:00:52 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 15:07:05 +0200 Subject: Re: Let the game begin! Message-ID: <506_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu On 15 Nov 94, 18:20 Robert Elsner sniggered: re> I think we should definitley have a seperate language for the aliens. re> If anybody has played games long enough, do you remember the old(old) re> Kings Quest 1-4? If so, they used a command parser. I think we need re> and AI command parser. If any command parsing is to be done, it should be done for custom code we've written for the aliens ourselves. The actual programs assigned to each alien should be in a short, efficient "machine code" that can be interpreted by the aliens' built in "interpreter" method. re> So far the vote (that I payed attention to is): re> Chrtitian: 2d top-down re> Robert :2d top-down Put me on for 2d top-down as well. CYa G-J --- Blue Wave/RA v2.12 [NR] | FidoNet: Gert-Jan van Rooyen 5:7102/129 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Fri Nov 18 13:11:42 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id MAA29163 for ; Fri, 18 Nov 1994 12:45:24 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8XHL-000fIuC; Fri, 18 Nov 94 09:39 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r8X9P-0004UcC; Fri, 18 Nov 94 19:31 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02470; 17 Nov 94 06:00:50 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 16 Nov 94 15:04:02 +0200 Subject: Re: Language Message-ID: <503_9411170600@chameleon.alt.za> Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu I guess the ideal language to use is C++ ... Problem is, my experience lies with Turbo Pascal (Yeah, so spit on me :) Well, perhaps now is the time for an upgrade...! My knowledge of C is somewhat limited, but I suppose (hope) it won't take long to adapt. Let me know which compiler & version we'll be working with. G-J --- Blue Wave/RA v2.12 [NR] | FidoNet: Gert-Jan van Rooyen 5:7102/129 | Internet: g-j@chameleon.alt.za | | Standard disclaimer: The views of this user are strictly his own. | From Chameleon BBS +27-21-462-4580 From ???@??? Fri Nov 18 13:29:24 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA03228 for ; Fri, 18 Nov 1994 13:08:27 -0500 Received: from sparkle by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8Xep-000fIzC; Fri, 18 Nov 94 10:03 PST From: Benjohn Barnes Message-Id: <10385.199411181802@sparkle> Subject: More on Nets To: alife-game@alnilam.krl.caltech.edu (ALife Game) Date: Fri, 18 Nov 1994 18:02:15 +0000 (GMT) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2911 He everyone, I was having a good rant about using a nueral net last night. People have come up with some good reasons why it sin't so hot... One was perseption, I was thinking that the aliens would maybe have one or more sensors that would return the angle and distance to the player (if they can seen) the angle and distance to the nearest objects, angle and distance to nearest badies, ect. The net could make sence of this quite easily, but working out some of the values may be a little tricky. Or sensors would have a baring and sensitivity arc. a few could be used to pin point a position. The main reason that I liked nets so much is that they are resonably easy to evolve. I don't know how you actually evolve a program, maybe you could tell everyone how it's done. After all it's quite important to the game! I was talking about the Karl Sims stuff, I wouldn't try using a physical model ANYTHING like as complex as that, but I think something like his consept is a good idea. The problem with giving any basic features to the aliens is you reduce the chance of them coming up with wierd solutions themselves. BUT they do need some sort of initial program or they will be thrashed. Maybe a program to let them evolve on there own to some fairly loose goals would be a good idea, before putting them out into the big wide world. Colecting Energy>>> Could have maybe 2 or three different food types. For Eg. call these Vegy and Carny. Aliens (and the player) would have a value for how much of both of these they were. Eg:- 90% Vegy 10% Carny --- 100% --- -: when they try to eat something they would multiply these values with the thing they are eating:- Ataker ====\/ \/========= Victim Vegy Bit 0.9 * 0.5 = 0.45 Carny Bit 0.1 * 0.5 = 0.05 ---- 0.50 ---- multiply this by the energy of the creature and this is what they would get:- 0.50 * 1000 = 500 So this one only gets half the energy in the creature. The rest could either just be lost or it could be left, presumably having the same parameters Something could be added so that after a long time left overs turn into a third type that only scavengers can eat. This could be poisonus to every one else. This should encorage some sort of diversity. Energy could be put into the "eco system" by plants that are 100% Vegy. Could also have it so that Carny energy is better than Vegy energy, encoraging thing to climb up the food chain. Problem would be that things may try to pray on animals related to them. This could be discoraged at other levels, or at the food level by if Vegy and Carny levels are too similar, energy is drained from the eater. Not sure about this though. Actually, should Canablism be discoraged? Could cooperation develop without eating each other being discoraged? Adavantage is that only 2 parameters need to be traked for each beasty. Benjohn From ???@??? Fri Nov 18 13:44:11 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA07263 for ; Fri, 18 Nov 1994 13:34:19 -0500 Received: from sparkle by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8Y3M-000fIwC; Fri, 18 Nov 94 10:28 PST From: Benjohn Barnes Message-Id: <10616.199411181827@sparkle> Subject: The Karl Sims work To: alife-game@alnilam.krl.caltech.edu (ALife Game) Date: Fri, 18 Nov 1994 18:27:34 +0000 (GMT) X-Mailer: ELM [version 2.4 PL20] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 915 If anyone wants to look at the Karl Sims work and can't reach the ftp site, (it way have gone down), then let me know and I'll send it to you. Should I post it to everyone. The paper in postscript isn't to big, but the mpeg is a huge 9.5 megs. I may be able to put it into the univerities FTP site. Anyone interested? Hang on, I've just had an idea, I'll check if the site is working. The genius of the human brain is astounding isn't it. (I wish there was some way to convey sarcasm in typed script !) Erm, doesn't seem to be working. Give it a little longer... Get the error ftp: connect: Connection timed out Give it another go... This isn't working... No, I think I have to report the deise of ftp.think.com . Hats off everyone. Nope, thats it, dead. It is an ex ftp site, it is no more. It has gawn to the great file store in the sky. etc What should I do now. Anyone want to see this stuff??? From ???@??? Fri Nov 18 13:49:13 1994 Received: from alnilam.krl.caltech.edu (alnilam.krl.caltech.edu [131.215.79.20]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA08315 for ; Fri, 18 Nov 1994 13:40:50 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8YGx-000fIxC; Fri, 18 Nov 94 10:42 PST Received: from [144.118.44.96] (sn203050.resnet.drexel.edu [144.118.44.96]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA08170 for ; Fri, 18 Nov 1994 13:39:48 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Nov 1994 13:44:08 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: >(iv) Somebody said (have you noticed that I can't tell you apart ? Sorry > guys but all humans look the same to me ...) that we must not rely to > much on the evolution of the bad-guys. I agree 100% with this, we > let them evolve but we have to help them out in as many ways as > possible, ideas are: > > (a) libraries of "known winning combinations" one of which 'wanders in' > every now and then. These libraries could be updated during play, > swapped with friends, edited by the player etc etc. That's a good idea. > (b) 'elitism' accross generations (and into the library of course) > > (c) construct the form of the control language as appropriately as > possible (see (v) below) > > (d) construct the physics of the arena as amenably as possible > > (e) do cross-breading as intelligently as possible (shouldn't be too > hard to reject any 'still-born' programs/bodies before they > enter the game (re-roll them). I leave this one up to Martijn and others :) > (f) somebody mentioned fitness-functions, I don't like this, see below. down below, you say you want to use them(I think) >(v) The representation of the control language must be done as carefully as > possible. I still recomend an 'interrupt driven' system where each > program would consist of a number of routines, each of which was > called when an appropriate event occured (note the alien's ability > to percieve those events could also be filtered through its hardware). > > To enable time-spanning strategies, some of the 'events' could be > purely internal ones set up by other routines, e.g > > EVENT_SEE_ENEMY(x,y,speed,dir) { > location dest; > > dest = _compute_intercept_(); > _set_coursei_(dest); > _enable_future_interrupt_(BEGIN_ATTACK,_location_reached_,dest); > } > > where CAPITALS indicates the names of modules in the program, > _surrounding_underscores_ indicates the games built-in functions > > The final line is the critical one. This sets up an event to call > the routine "BEGIN_ATTACK" when the alien reaches the location > "dest" I really like the idea of interupts, but will they limit strategy?? >(vii) Eggs, I'm not sure how much I like these (well actually I like them > a lot but I think some of the schemes suggested are a bit complex). > Perhaps fertilisation should be taken as read (i.e assume it can be > done over quite a distance) and the energy required in laying the > egg should be a function of the size/complexity of the child. The scheme we have decided on (I think we decided) isn't too complicated. The fertilization must take place locally ie- right next to the egg. Energy would be related to size. >(viii) Energy, should we make the aliens search for every joule of energy ? > I think not (because it makes the simplest program required for > survival more complicated) rather I think that each alien should > have > > (a) an energy source that provides energy at a fixed rate > > (b) a limited store where any excess energy can be banked for > future use > > People have also suggest that aliens should use energy when doing > nothing. I'd rather that wasn't the case (after all they might have > to cross a large empty space) and that they could survive without > 'winning' any energy but that were advantages if they did so. > > I think its a good idea to let the aliens allocate their own > energy useage, this would (for example) permit the production of a > "power only the shield and engine" type of creature (it could ram, > or it could hang around the edges of battles and steal the booty). This does not require a multi-battery setup at all. An alien could do the same thing with only one battery. Multiple batteries makes it much harder for an alien to check to see if it has a decent level of energy-it would have to check the energy in each individual battery, compare it to some standard, then use those figures to decide to allocate/get more/whatever. This adds too much complexity. If there is only one battery, then all the alien needs to do is compare that one against some standard it -may- have evolved, and use that to determine if attacking a strong alien is wise, etc. It seems that the energy setup has been decided already anyway. I am unclear on whether the armor is energy, or simply material(it should be material, though). If it is material, then there is a clear difference between usable energy and shields(but this is merely semantics). >(ix) Plot: Like the question of money, lets decide this *after* we have > a game. We should not be overly concerned with plot, but it does need to be considered as we go along. When ideas are thought of, they must fit in with everything else, or else it will be impossible to develop a coherent story. >(xi) Collision: > > Is this dangerous ? Can we expect the evolved programs to navigate > well enough to avoid it (can we even write a program to do that) ? > > Perhaps we should 'hard-code' this part (sort of like having the > alien issue commands to its pilot-routine) and just let the > evolution play with a couple of parameters such as > > default_speed > navigation_care There are two kinds of collisions that could occur: ship-ship, and ship-asteroid.(ignoring asteroid-asteroid) If an alien hits an asteroid, what happens would be determined by the size of the asteroid. If it is small enough, it will be gathered(no collision occurs then). If it is too big to pick up, then the ship would lose some shielding(depending on the speed of impact), and would be deflected in whatever direction the laws of physics dictate(this isn't very complicated actually, just force vector addition) [Asteroids should be shootable--they should break up when shot(maybe from collisions?] If an alien manages to collide with an alien, they would both be deflected, and lose some shielding(which allows a ramming strategy, of course though, the supplies would go flying away, and would be hard to pick up) For the alife aspect, an interupt would be invoked on all involved aliens, and they would have to deal with it. >(xiii) Morphing: > > I don't like this ('cos after a while all the ships look the same) > but if we use the modular hardwar suggested above then the appearance > of the ship is determined by simply pasting the appearance of the > correct sub-modules onto the right places of the superstructure. > > (and the final image is then rotated to give each possible appearance) The ships would not all look the same, as there is the fresh influx once each sector is cleared(semi-continuous) I'm not too sure I like the idea of modular hardware, as it allows too much diversity(!?!?)--the alien's strategy would never be able to keep up with the changing weapon type. >(xiv) Sex ? > > Do we need sex during game-play ? (Do you, personally :-) > > Or would it make more sense to let the aliens reproduce asexually > during the game and do the recombination between rounds. This makes > sense because: Sexual reproduction has been shown to be a more efficient proccess than asexual, plus it creates it's own kind of fitness function(so we don't have to worry about keeping stats on every alien's #kills, and whatever else would have to go into a fitness function) > (a) no need to make provision for breeding in the aliens behaviour > code the code for breeding would not need to be complicated at all, at the minimum, just a statement saying if energy exceeds some level, drop an egg with X amount of energy. > (b) the child-generation procedures don't have to be done in real > time You want the player to wait while the fitness functions of (400?) aliens are determined, then wait some more while they are being bred, and their structures being determined? It seems to me that this would take a while, (but obviously I don't know for sure.) > (c) the player can get used to the inhabitants of each round but > gets them rearranged in the next round (don't know why this is > good but it *feeels* like a good thing) Why not make him deal with several strategies on a level? Do you mean that all aliens on a given level should be identical? This would slow down evolution, and make the game less interesting. > (d) this way we get to use a fitness function between the rounds > (enabling us to boost the efficiency of evolution) but within > the rounds the fitness is implicit in the actual achievements > of the aliens I don't believe that this would increase the efficiency of evolution.(Am I wrong?) This also means that the aliens would be made to conform to *our* ideas of what a good, strong alien is, instead of letting evolution decide. > (e) within a round all aliens of a given type have exactly the > same program/hardware. This makes it much easier to breed in > cooperation/slavery (because they can choose to trust messages > from their own kind) define a small number of standard messages that the aliens > can send: "attack-x" "follow" "run" "ignore-x" (ever played > X-wing/tie-fighter ?)> I should have kept reading :) I don't think communication is a good idea either, as it would add more hard-coded material than necessary(or else an alien could be told to follow, and it would -obey- by running away) >(xv) Perception: > > I raised this as an objection to neural nets but it's a more general > problem, how do aliens percieve each other ? If we do the sex > between rounds then its easy ('cos there is only a finite number > of 'types' in each round) otherwise we have to start doing thing > like remembering who shot us or trying to decide who a given > alien is descended from (in case they shot us). Good point. Maybe they could just trust(ie not shoot on sight) aliens that are similar, but have a lesser degree of trust the more dissimilar an alien is. BUT, I think that this should be an evolved decision. >(xvi) Teams: > > Do we want to split the alife team into a software and hardware > sub-teams ? > > How do you get into a team ? > > Is anybody in one yet ? > >That's it (long wasn't it) just wanted to say how impressed I was with the >number of ideas flying around but that its a bit worrying 'cos there's >obviously too many of them for the initial projects. Still, this always >happens in these things and it should settle down soon (?). > >Badders To join a team, send a message with 'SUB-GROUPS' as the subject to Greg Taylor (gtaylor@violin.aix.calpoly.edu) and let him know which ones you want to join. He asks that you limit yourself to 2 groups, though. Thanks for the comments. (I apologize if I seem rude, or I wrote something completely wrong, but I'm really tired now, and I don't write well then :-) so someone please point out my errors(as I'm sure you will:-] )) Michael Mitchener st944m5h@post.drexel.edu