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 ???@??? 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: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 From ???@??? Fri Nov 18 14:57: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 OAA20074 for ; Fri, 18 Nov 1994 14:51:31 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8ZIR-000fIxC; Fri, 18 Nov 94 11:48 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56955-3>; Fri, 18 Nov 1994 14:45:27 -0500 Date: Fri, 18 Nov 1994 14:45:12 -0500 From: Jeff Lait Subject: Re: Language To: Gert-Jan van Rooyen cc: alife-game@alnilam.krl.caltech.edu In-Reply-To: <503_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: > > 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. Well, to keep it platform independent we can't really specify a compiler & version... Doing so would implicitly limit all our code to that particular computer. Besides, you said you're planning to be working on FE_PCX? Then ASM is the only real requirement :> (And IMOO, interfacing C-ASM is much easier than PASCAL-ASM, C has a much better calling convention...) - Jeff Lait (SOL) From ???@??? Fri Nov 18 15:51: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 PAA25655 for ; Fri, 18 Nov 1994 15:27:00 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8ZqW-000fIyC; Fri, 18 Nov 94 12:23 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id aa00736; 18 Nov 94 20:18 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA002z7; Fri, 18 Nov 94 18:43:18 GMT Date: Fri, 18 Nov 94 18:43:18 GMT Message-Id: <9411181843.AA002z6@darkin.demon.co.uk> In-Reply-To: <9411181527.AA25967@altair.krl.caltech.edu> (from Charles Ofria ) (at Fri, 18 Nov 1994 07:26:50 -0800 (PST)) 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: Re: energy and food Hi people, Charles says: > > 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. You may be right. But, if each alien is born with a certain survival level of energy in each battery (and it would be) and feeding filled up all the batteries at the same rate (which it would, probably) then an alien doesn`t really need to mess about swapping power around unless it feels like it. It would still be able to function quite well whether it did or not. Of course it would be unable to re-load its guns once it had emptied them unless it went and fed, but since it couldn`t repair its` shield battery either, it would probably be dead by then anyway. It`s no more useless in that case than your average `shoot-em-up` enemy. > 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). would that mean that if a quite powerful species arrived on the scene early on, it would discourage all evolution that was not in a similar vein (by eating it)? Another problem would be of course that when we started, our life forms would all be genetic primatives. They would all be alike (especially if we`re evolving them from scratch) so they can`t eat each other. > I would be interested > to hear your ideas on what kind of detailed "diet" system we should have... Tricky. What I`m trying to get to is a situation where the life forms can diverge. In order to do that, we need some way of making the environment more colourful (yes, I know that means more complecated, and => slower to evolve) What a more diverse set of food chains would do would be to encourage environmental niches to evlove around whatever the genetics threw up. Our new mutations and developments would be more likely (I think...) to find a successful place to live. It`s the `bumpy landscape` you were talking about. Anyway, since most things should still be able to get some kind of nutrition out of most other things (not much should be poisonous or sick making) all aliens right from the start would be relatively successful at least in that respect, and the evolution of the food chain ought to be more optimisation of diet rather than floundering about starving to death. You asked about a detailed diet system. Well, I think it would depend on how the genetics are going to work, but put simply, we should have a nutrient component (like a vitamin) which is calculated from the genetic program of the prey. Then we have a nutrient requirement which is calculated from the genetic profile of the feeder. These two numbers are compared, and the difference between them is noted. If the prey`s nutrient component is roughly the same as the requirement of the feeder, it can take some energy from the prey. If it`s wildly higher (food too rich) then it must loose some energy. If it`s much lower (food has no value) then it gains nothing. > 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. Yes. I think that`s true. Get a simple system up and running, and then develop from it. We`re going to have a lot of system testers to run the early versions until evolution gets a hold, so I think we should be ok on that front. We can have all (what is it 20 - 30) of us running simulations on our machines and then combine the best of the best at regular intervals (maybe we could have one dedicated machine which we just feed everyone elses evolved aliens into as we go along. Would that work? BTW, there seems to be a decision to be made about to what extent we create our starting creatures behavior to get them going, and to what extent we let them evolve from scratch. It`s a difficult one, I know. The problem seems to be that if we interfere, then the aliens are limited to an extent to what we think is a good evolution, and the results will be less surprising (and less scientificaly significant) and if we don`t, then the creatures will take so long to get going that the game won`t be any fun until the critters go sentient sometime in 2050. Would it help if we had many different populations running on many different machines, each having different combinations of set aliens and developments from scratch. Then, we only combine them into a central gene pool when they`d all reached a certain level of fittness? -------------------------------------------------------------------------. !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 16:12:22 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 QAA01813 for ; Fri, 18 Nov 1994 16:05:35 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8aIk-000fJ1C; Fri, 18 Nov 94 12:52 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA64730; Fri, 18 Nov 1994 12:52:29 -0800 Date: Fri, 18 Nov 1994 12:52:29 -0800 (PST) From: Gregory Glen Taylor Subject: Sub-groups! To: alife-game@alnilam.krl.caltech.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I've only gotten a small number of people registering for subgroups... Let me reiterate that if you do not sign up for a sub-group, you will eventually be put on the 'announcements only' list, which is vitually being dropped from the project. IF you'd like to stay on the project, you must join a group and be prepared to do -something-. If you missed the PROJECT STRUCTURE msg, it is available at our Info FTP Site... ftp.krl.caltech.edu pub/alife-game/admin/project_structure.1 Please read it if you haven't and join a group or two. Things are about to start happening, so you would be advised to join or be left behind. The people who ARE registered for sub-groups are following, if your address is not listed, either I never got your msg or you haven't sent one... These people -are- currently registered in sub-groups... -------------------------------------------------------- gtaylor@oboe.aix.calpoly.edu Martijn.Faassen@phil.ruu.nl charles@krl.caltech.edu st944m5h@post.drexel.edu uwingcat@mcl.mcl.ucsb.edu jmlait@undergrad.math.uwaterloo.ca B.Barnes@dcs.warwick.ac.uk mbbad@seqnet.dl.ac.uk gollum@spider.two-oo-one.fr hernande@cauchy.sosc.osshe.edu g-j@chameleon.alt.za Please register for groups soon. If you register before Tuesday Nov 22, send your msg to me directly. I'm going on vacation from the 22nd to the 28th, during that time, send the group register msg to 'charles@krl.caltech.edu' and he will add you directly. You are encouraged to register as soon as possible. Next week the groups will begin their individual discussions, do if you aren't registerred by then, you'll miss out on the initial discussion; which will likely set the course for the rest of the project. REGISTER FOR SUB-GROUPS SOON, IF YOU HAVE NOT ALREADY DONE SO! Thanks -=GT=- From ???@??? Fri Nov 18 18:26: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 SAA22030 for ; Fri, 18 Nov 1994 18:19:47 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8cTo-000fJ2C; Fri, 18 Nov 94 15:12 PST Received: from rigel.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA29074; Fri, 18 Nov 1994 15:10:59 -0800 From: Charles Ofria Received: by rigel.krl.caltech.edu; (5.65/1.1.8.2/29Jun94-0757AM) id AA23390; Fri, 18 Nov 1994 15:10:59 -0800 Message-Id: <9411182310.AA23390@rigel.krl.caltech.edu> Subject: re: comments... To: alife-game@alnilam.krl.caltech.edu Date: Fri, 18 Nov 1994 15:10:58 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 16607 -- By: mbbad@seqnet.dl.ac.uk > 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.> I agree with this - I had suggested the idea before we decided on having the creatures fighting each other. The more the competativeness is increased, the faster evolution will progress (unless we push it over the edge and everything dies out - so we have to be careful to keep it sitting perfectly on that edge). Another reason I had wanted the creatures to be fighting computer controled versions of the player in the background was so that they develop defenses specifically against the type of ship the player is using. This is no longer needed if we allow the aliens to mate with the player - some of the offspring will be the body of the player with an enemy alife mind. The player-type ships will get distributed through the soup quickly enough. > (ii) People spoke about 'Modular design' let me second this, it's > essential ! Of course - the project wouldn't get anywhere without it. > (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. Well, the idea I have for neural networks is not a pure net - the ship would directly be controled by a program, but the program has an interface with a NN. It can decide how and where to use the network. I can think of several ways to organize this to actually start with a creature that can do real time learning. > (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 ?) I'm actually looking into that. I'm planning on talking to one of the professors here (Dr. Christoph Koch) who studies animal vision and ways of implementing it in NN's. I'm considering even working in his lab for the spring semester. If I get anything useful out of talking to him, I'll be sure to bring it back here. Side Note: I'm a Computation and Neural Systems grad student who spend most of his time studying Alife - tying these togeather is something I'm planning on making a career out of. > (b) doesn't (number of neurones) * (number of ships) add up to quite > a slab of processor power ? All an individual neuron (deoending on the type of network) does is take a bunch of numbers, multiply them all their relative weights (depending on where they came from) and spit out the sum. Sometimes this is placed though a simple function. But in the long run its neglegible CPU time. Its something to keep an eye on, but won't be a limitation. If we use a fully connected Hopfield network on the other hand... > Which isn't to say that it shouldn't be tried, just not yet. > (if we make the interface well enough then no problem) Agreed completely - I don't plan on working on this until every other part is in working order. > (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: The point of the game is to have the evolution make a noticible difference. If it doesn't, then there is no point in writing this game - there would be a million others out there like it! We should make it fun without the evolution, yes, but in the end the evolution has to be a major feature. > (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. I have no problem with this as long as those known winning combination just wander in and are not forced in. It could theoretically have a problem with unbalancing eco-systems, but I'm not too worried about that. We'll see if the problem does crop up. > (b) 'elitism' accross generations (and into the library of course) Elitism is not needed. If a creature is good enough it will survive on its own and reproduce itself. Reproduction is, after all, the main source of determining how fit a species is. How many children can you have before you die? > (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 Of course to the last to. > (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). Actually it will be quite hard. If a program doesn't do anything then yes, we might be able to identify it. But if it simply weights its movement functions such that they can never be reached, its impossible to know that. One thing that may work is that while a creature is waiting to hatch, we could have it in a pseudo-arena and see what it does. If it just sits there and doesn't go after food or react to getting hit or anything, then perhaps we should reject it. > (f) somebody mentioned fitness-functions, I don't like this, see below. neither do we (well some of us anyway) > (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 like this VERY much. Thank you for the idea. (are you joining us fully, BTW? - you seem to have a lot of ideas on things) > (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. I don't think we're going with the gene-stealer idea. > (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 energy in the egg when it hatches (or is fertalized?) determines the size of the child. The genotypes of the patents detemine the complexity. The reason for using the egg-laying scheme is to acheive cross-over without artificially stepping in and doing it. > (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 Energy sources in the environment will be of a set size and leak rate (anyone have a better name?) when a creature goes up to it it can "eat" up to the leak rate in energy, until the energy is drained. > (a) an energy source that provides energy at a fixed rate Exactly, but it eventually runs out. > (b) a limited store where any excess energy can be banked for > future use banked? I'm not sure I understand... > 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. Ah, but if they didn't use energy while doing nothing, "still births" which were lucky enough to not be reachable by other aliens would never die. Then again, all of them could be reachable, and this could just be another energy source. :-) > 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. This sounds good to me actually. I'm begining to wonder why we *need* the space motif. As long as its going to be 2-D anyway, we could just as easily have it on the surface of a planet. Not that I'm saying we should, I'm just wondering why we've decided it *has* to be space. The advantage of a planet is that we can even vary the terrain that the creatures are on (and thus have distict local population of creatures) and neatest of all, we could have walls! Things to block the player and creatures from just going in any direction they wanted... > (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. We're actually debating whether or not the aliens are indeed different. The player may actually just be exactly like an alien (even able to mate with them) except controlled by a human. > 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 Nah, I think we should let them bumble around sometimes. We'll make sure its easy enough for them to detect impending collisions. > (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 ...) I'll leave this up to other people. After a hellish week, my brains too full to think about the ramifications (good or bad). > (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) This would be a nice thing I think. > (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 Well, we'd still want them to be able to bread somehow - the most productive kinds of evolution will be done real-time. > (b) the child-generation procedures don't have to be done in real > time I don't think this will take all that long. It should just be a handful of random numbers. Besides, its not perfect realtime - the eggs do take time to hatch remember. > (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) This I can agree with you on... > (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 Implicit fitness has always proven to be the most powerful. We want it driving our evolution. > (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 ?)> > > (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). I have some ideas about species, actually, which I'll make a seperate post about. > (xvi) Teams: > > Do we want to split the alife team into a software and hardware > sub-teams ? Are we really going to have a hardware side of things? > 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 --- Charles From ???@??? Fri Nov 18 22:52:32 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 WAA21600 for ; Fri, 18 Nov 1994 22:47:44 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8glt-000fJ3C; Fri, 18 Nov 94 19:47 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r8gkP-0004UhC; Sat, 19 Nov 94 05:45 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02495; 18 Nov 94 20:10:44 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 18 Nov 94 00:14:01 +0200 Subject: Re: ftp site & more ideas Message-ID: Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu ch> First of all, we need to constantly be processing all parts of the ch> board which the player is on, not just in his immediate vacinity. I ch> think this is a given. What is important to note, however, is that we ch> don't have to do this synchronously with what the player is doing. If ch> the player is currently walking around a deserted area (ie. not using ch> much CPU time), we can update parts away from him at a higher rate, ch> while if he's in the middle of a combat with 75 other ships, we can ch> likewise conserve CPU time to focus on the battle. This will take a ch> tricky bit of programing, but I think it will be needed if we want the ch> game to move smoothly for the player, yet we still want a noticible ch> evolution to occur. We'll need some simple form of multitasking for the alien behaviour and development anyway. If we do that, it'll also be easier to implement your idea: The program does the important stuff like displaying the ships and controlling the battle, and if some time is left to "delay" after all this has been done, an appropriate number of "timeslices" are allocated to the off-screen activities. 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 23:32: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 XAA25258 for ; Fri, 18 Nov 1994 23:20:12 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8hHn-000fJ4C; Fri, 18 Nov 94 20:20 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA38297; Fri, 18 Nov 1994 20:19:49 -0800 Date: Fri, 18 Nov 1994 20:19:49 -0800 (PST) From: Gregory Glen Taylor Subject: Re: ftp site & more ideas To: Gert-Jan van Rooyen Cc: alife-game@alnilam.krl.caltech.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > We'll need some simple form of multitasking for the alien behaviour and > development anyway. If we do that, it'll also be easier to implement your > idea: The program does the important stuff like displaying the ships and > controlling the battle, and if some time is left to "delay" after all this > has been done, an appropriate number of "timeslices" are allocated to the > off-screen activities. Set a specific ammount of time for 'stuff' between screen redraws. Do the vital stuff first: player input, local aliens (one's on the screen) and other essential functions. Then if there's any time left over (which there should be) do the off-screen aliens, and if there's any time after that, preform some of the morphing functions for new alien picture generation. Then if there's -still- more time, wait it out...(to keep the game at a fairly constant rate). Sound good? It's sort of a caching system, the stuff that doesn't get done, (like the morphing stuff) will wait in the queue until the CPU has time to do it...:) I'm not in the Universe group...but heck, there's my $0.02 -=GT=- From ???@??? Sat Nov 19 12:13:32 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 HAA19766 for ; Sat, 19 Nov 1994 07:10:47 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8odf-000fIrC; Sat, 19 Nov 94 04:11 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id aa12328; 19 Nov 94 12:06 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA002zh; Sat, 19 Nov 94 09:20:22 GMT Date: Sat, 19 Nov 94 09:20:22 GMT Message-Id: <9411190920.AA002zg@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: plot People have been throwing around plot ideas, and speculating on whether the game should be set in space, or on the ground, or in between. There have been discussions about the plot and the story behind the game. I`m beginning to think that what we`re *actually* doing here is far more interesting than any plot we could develop. If the development of a whole new ecosystem within a game, the use of evolution, morphing, an artificial intellegence for each of the enemies, and the biggest (in terms of users) experiment into artificial life ever isn`t enough to grab the player`s imagination, then I don`t know what will be! We`re devising a new universe here. Let`s just do everything we can to make it an interesting and working place, for evolution to happen in, and if it comes out fitting into a plot idea, fine, but if it doesn`t, some of the best games haven`t been tied to the `real` universe (Tetris, for example). -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Sat Nov 19 12:39: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 MAA06899 for ; Sat, 19 Nov 1994 12:35:10 -0500 Received: from mickey.iaccess.za by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8tgF-000fIrC; Sat, 19 Nov 94 09:34 PST Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r8tea-0004V0C; Sat, 19 Nov 94 19:32 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02497; 19 Nov 94 06:00:50 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 18 Nov 94 22:48:00 +0200 Subject: Re: Some notes on the plot. Message-ID: Organization: Chameleon BBS To: alife-game@alnilam.krl.caltech.edu Hi On 17 Nov 94, 22:16, Martijn wrote: Ma> Human kind has colonized a world (or maybe this is just Earth itself). Ma> Then, strange alien ships are sighted (or maybe this is just a human Ma> experiment with selfreplicating robotic ships - Von Neumann probes - Ma> gone wrong). I still prefer my initial plot... ;) Ma> maybe sent off by some paranoid alien civilisation, or some Ma> experiment gone wrong, or maybe even *we* were the paranoid people and Ma> the results of our berserkers are coming back at us now). Hmmm... I like this idea, though. Ma> The player can configure a fighter (with simple weapons, nowhere near Ma> to what the aliens might evolve) and goes out to do something about the Ma> aliens. The player knows it would be rather difficult to destroy all of Ma> them, when only having a few fighters left. So, he has to do research Ma> also. Excellent. This sounds very good - it adds more than plain skop-skiet-en-donder (= mindless action [S.A. Colloq.] :^), it gives some plot, some progress, and most importantly: it maintains suspense. Ma> First, the player might be able to obtain scanners of a kind, to Ma> scan the amounts of armour or energy or the type of aliens he is Ma> encountering. Later, the player might discover how to capture alien Ma> 'eggs' (these are somekind of robotic machine constructs or whatever) Ma> before it hatches. Then, the player is able to discover how to Ma> 'fertilize' the egg for himself, giving some low chance that the born Ma> alien is actually controllable by the player himself (as an extra Ma> life). At last, this aspect of the game starts to make sense. Yeah, *this* will fit into the plot. As for player copulating with an alien... well, your idea is infinitely better, IMHO. Ma> Another thing the player might do (we don't even have to hard code Ma> this in, it can just happen if the player is smart enough) is breeding Ma> aliens in such a way (by donating energy to some, and destroying the Ma> ones that don't do what the player wants) that they help him..either by Ma> attacking other aliens, or perhaps donating energy to the player after Ma> gathering it, or being aliens with a good configuration for eggs but Ma> 'meek' (not attacking the player), etc. This would certainly also help to make the game more strategic. I like it... A clearer vision of the game is starting to develop here... We'll just have to ensure that the game doesn't get _difficult_. What I mean is, the player shouldn't have to read a fifty page manual just to be able to play the game. The interface should be straightforward and allow the user to figure stuff out for himself, easily. Name for the game? Are we going to stick with "Evilution", or have there been some other worthwile suggestions? Somehow, "ALife-Game" doesn't inspire me to jump up and get the game... :) 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 ???@??? Sat Nov 19 14:21: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 OAA14629 for ; Sat, 19 Nov 1994 14:09:08 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8vAw-000fIrC; Sat, 19 Nov 94 11:10 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56990-3>; Sat, 19 Nov 1994 14:08:25 -0500 Date: Sat, 19 Nov 1994 14:08:19 -0500 From: Jeff Lait Subject: Re: ftp site & more ideas To: Gregory Glen Taylor cc: Gert-Jan van Rooyen , alife-game@alnilam.krl.caltech.edu In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > We'll need some simple form of multitasking for the alien behaviour and > > development anyway. If we do that, it'll also be easier to implement your > > idea: The program does the important stuff like displaying the ships and > > controlling the battle, and if some time is left to "delay" after all this > > has been done, an appropriate number of "timeslices" are allocated to the > > off-screen activities. > > Set a specific ammount of time for 'stuff' between screen redraws. Do > the vital stuff first: player input, local aliens (one's on the screen) > and other essential functions. Then if there's any time left over (which > there should be) do the off-screen aliens, and if there's any time after > that, preform some of the morphing functions for new alien picture > generation. Then if there's -still- more time, wait it out...(to keep > the game at a fairly constant rate). > > Sound good? It's sort of a caching system, the stuff that doesn't get > done, (like the morphing stuff) will wait in the queue until the CPU has > time to do it...:) I'm not in the Universe group...but heck, there's my Trouble with this is that you'll end up never moving aliens outside your view area on a slow computer. Also, morphing would never actually completed. The processing power required for doing battle with 2-3 ships is negligbly more than that required to do just the player flying around. Also, having the computer wait if everything is done is kind of annoying. IMHO, the FE_RedrawScreen should return the change in time (In game clicks) between this and the previous frame. Then, this delta t is passed to the UN_MoveObjects which can then update the world in accordance to the time span. This will keep the game running as fast as possible, and also changes the rate depending on the speed of the computer. - Jeff Lait (SOL) From ???@??? Sat Nov 19 16:27:06 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 QAA29766 for ; Sat, 19 Nov 1994 16:20:09 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r8xC0-000fIrC; Sat, 19 Nov 94 13:19 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA04536; Sat, 19 Nov 1994 13:17:45 -0800 From: Charles Ofria Message-Id: <9411192117.AA04536@altair.krl.caltech.edu> Subject: Re: plot To: alife-game@alnilam.krl.caltech.edu Date: Sat, 19 Nov 1994 13:17:44 -0800 (PST) In-Reply-To: <9411190920.AA002zg@darkin.demon.co.uk> from "Christian Darkin" at Nov 19, 94 09:20:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1427 Well, I must say that I have to completely agree with this... --- Charles -- From: Christian Darkin > People have been throwing around plot ideas, and speculating on whether the > game should be set in space, or on the ground, or in between. There have > been discussions about the plot and the story behind the game. > > I`m beginning to think that what we`re *actually* doing here is far more > interesting than any plot we could develop. If the development of a whole > new ecosystem within a game, the use of evolution, morphing, an artificial > intellegence for each of the enemies, and the biggest (in terms of users) > experiment into artificial life ever isn`t enough to grab the player`s > imagination, then I don`t know what will be! > > We`re devising a new universe here. Let`s just do everything we can to make > it an interesting and working place, for evolution to happen in, and if it > comes out fitting into a plot idea, fine, but if it doesn`t, some of the > best games haven`t been tied to the `real` universe (Tetris, for example). > > -------------------------------------------------------------------------. > !Email christian@darkin.demon.co.uk > !Mail Sent Via Demon Internet Services ! > !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! > `-------------------------------------------------------------------------' > From ???@??? Sat Nov 19 22:21: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 UAA27060 for ; Sat, 19 Nov 1994 20:53:51 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r91Tc-000fIrC; Sat, 19 Nov 94 17:54 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA05320; Sat, 19 Nov 1994 17:51:55 -0800 From: Charles Ofria Message-Id: <9411200151.AA05320@altair.krl.caltech.edu> Subject: Species To: alife-game@alnilam.krl.caltech.edu Date: Sat, 19 Nov 1994 17:51:54 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2668 Greetings, Here's some interesting ideas, mostly only for the alife group. Anyway, I've been playing with varying styles of constructing the bodies of the creatures, and what I see most is that if creatures are too different, than cross-over between wildly different creatures will invariably come up with a still-birth. Kinda like trying to mate a squirrel with a walrus. If they could mate, the results would be quite ugly. Nature came up with a wonderful solution to insure a lower mortality rate - creatures thus wildly different simply cannot mate. I think that something similar (having species) would work well. Creatures can also looks at the species of another creature to know if it instinctivly likes them (we may even come up with some interesting synergistic relationships). Some backgroud: In nature, whenever a mutation occurs in a creature, it is pushed slightly further away from others of its kind. It obviously has to be able to bread with the species which it came from because otherwise it wouldn't bread at all and would just die out. Well, as more mutations occur, it becomes less and less likely that a creature will be able to mate with a predessor species. The way this would typically manifest itself in nature is that a population would be split, and different mutations would occur and spread through each part. If the populations regroup, they would not be able to mate with one another anymore. There are two possible ways for this to be implimented depending on the internal structure of the creatures. If it is obvious that we can tell how different two creatures are (by hamming distance or whatever) then we could simply use this difference number to come up with a chance for the creatures to successfully mate (It would be useful in other places as well I'm sure, such as when one creature looks at another). The other way would be to assign each initial type (species) of creature a random 8-bytes (or maybe four is enough - we could just use an int [is int still only 2 bytes on dos machines?]). Anyway, when a creature gives birth, its offspring gets a combination of its parents bytes (in a similar method to how we combine the parents genes). If both of its parents were of the exact same species, then the child will have the parents bytes exactly. Anyway, whenever we do a mutation on a creature, we also do a bit flip in the byte. We could then compare these bytes and get a good idea of how similar the two creatures are. It won't be exact of course, but on the average it will work. This is just a musing I'm having on limiting the number of still- births. Tell me what you think. --- Charles From ???@??? Sat Nov 19 22:21: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 WAA03387 for ; Sat, 19 Nov 1994 22:11:53 -0500 Received: from dingo.cc.uq.oz.au by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r92iD-000fIrC; Sat, 19 Nov 94 19:13 PST Received: from localhost by dingo.cc.uq.oz.au with SMTP id AA15171 (5.67a/IDA-1.5 for ); Sun, 20 Nov 1994 13:11:29 +1000 Date: Sun, 20 Nov 1994 13:11:22 +1000 (GMT+1000) From: Andy Subject: Re: Some notes on the plot. To: Alife Game In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 18 Nov 1994, Gert-Jan van Rooyen wrote: > Name for the game? Are we going to stick with "Evilution", or have there > been some other worthwile suggestions? Somehow, "ALife-Game" doesn't > inspire me to jump up and get the game... :) I think this is an excellent name, but I think we should leave the decision till much later. Maybe once we have the game running and we can "see the light at the end of the tunnel" we should all put forward ideas and have a vote on it. andy. From ???@??? Sun Nov 20 13:59:38 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 MAA05588 for ; Sun, 20 Nov 1994 12:35:30 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9EYm-000fIrC; Sun, 20 Nov 94 07:52 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56998-1>; Sun, 20 Nov 1994 10:50:23 -0500 Date: Sun, 20 Nov 1994 10:50:20 -0500 From: Jeff Lait Subject: Re: Some notes on the plot. To: Andy cc: Alife Game In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 19 Nov 1994, Andy wrote: > On 18 Nov 1994, Gert-Jan van Rooyen wrote: > > > Name for the game? Are we going to stick with "Evilution", or have there > > been some other worthwile suggestions? Somehow, "ALife-Game" doesn't > > inspire me to jump up and get the game... :) > > > I think this is an excellent name, but I think we should leave the decision > till much later. Maybe once we have the game running and we can "see the > light at the end of the tunnel" we should all put forward ideas and have > a vote on it. One trouble with it is that it doesn't fit in 8 characters, as I found out when I made a temporary Evilution directory... - Jeff Lait (SOL) From ???@??? Sun Nov 20 14:14: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 OAA16580 for ; Sun, 20 Nov 1994 14:05:31 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9HA4-000fIsC; Sun, 20 Nov 94 10:38 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id aa15730; 20 Nov 94 18:35 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA00307; Sun, 20 Nov 94 13:41:54 GMT Date: Sun, 20 Nov 94 13:41:54 GMT Message-Id: <9411201341.AA00306@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: Eggs idea Why not have the egg layer keep her egg with her for a random period of its` development? This would mean we`d get species developing that would bear live young (because if you keep it with you, you can nurture it until it`s able to look after itself) and ones that would lay lots of low energy eggs and leave them (so as to spread the danger of loosing offspring) and those that would lay one high energy egg and guard it for a while. Lots of possibilities there out of one simple idea which wouldn`t really add to the complexity of the game, or the problems with stillbirth. We would then get (hopefully) many different attitudes to the rearing of young from different creatures. -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Sun Nov 20 14:44:35 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 OAA20483 for ; Sun, 20 Nov 1994 14:39:42 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9I9Z-000fIuC; Sun, 20 Nov 94 11: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 OAA20397 for ; Sun, 20 Nov 1994 14:39:02 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Nov 1994 14:43:28 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Eggs idea I don't know if my last message got out(I received a copy, but I also got a mail failed message--but that could have been for a single person--I don't know, so here it goes again) apologies to those who may have already gotten this... >Why not have the egg layer keep her egg with her for a random period of >its` development? > >This would mean we`d get species developing that would bear live young >(because if you keep it with you, you can nurture it until it`s able to >look after itself) and ones that would lay lots of low energy eggs and leave >them (so as to spread the danger of loosing offspring) and those that would >lay one high energy egg and guard it for a while. Lots of possibilities >there out of one simple idea which wouldn`t really add to the complexity >of the game, or the problems with stillbirth. > >We would then get (hopefully) many different attitudes to the rearing of >young from different creatures. > > > >-------------------------------------------------------------------------. >!Email christian@darkin.demon.co.uk >!Mail Sent Via Demon Internet Services ! >!Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! >`-------------------------------------------------------------------------' This is a good idea, but it needs one alteration: the alien that fertilizes it would pick it up, not the one that lays it. This way, the player would simply take it and return it to the research ship, where it would be altered into an extra life, which would go to the player once it hatches. (I think we must go with the research ship idea) Side Note: Are there any Mac programmers out there??? Even if there aren't, it shouldn't be too hard to find some on comp.sys.mac.programmers, but I was hoping there would be some here. :^) I'll be going on vacation Tuesday, and won't be able to answer/send any mail until Sunday/Monday, so Happy Thanksgiving to all! Michael Mitchener st944m5h@post.drexel.edu From ???@??? Sun Nov 20 14:59:31 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 OAA21746 for ; Sun, 20 Nov 1994 14:52:20 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9IJE-000fIvC; Sun, 20 Nov 94 11:52 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA00883; Sun, 20 Nov 1994 11:50:42 -0800 From: Charles Ofria Message-Id: <9411201950.AA00883@altair.krl.caltech.edu> Subject: New mailing lists set up... To: ag-announce@alnilam.krl.caltech.edu Date: Sun, 20 Nov 1994 11:50:42 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 918 Greetings all, This is a direct bounce to all of the mailing lists set up for the artificil life-game project. The lists created are: ag-alife@alnilam.krl.caltech.edu ag-universe@alnilam.krl.caltech.edu ag-PCX@alnilam.krl.caltech.edu ag-MAC@alnilam.krl.caltech.edu ag-general@alnilam.krl.caltech.edu ag-announce@alnilam.krl.caltech.edu You should receive this message once for each of the top four lists you are on. The general list will send to all of them, and the announcements will go to general + anyone else interested. List directors will send out information to members of each of the lists shortly. Additionally, I'll place a link to the lists at the ftp site so anyone can see who is on what list. --- Charles PS: I'll leave the alife-game list up for a little while, but people should no longer have a need for it - anything that would go there should now go to ag-general. From ???@??? Mon Nov 21 04:55: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 EAA16856 for ; Mon, 21 Nov 1994 04:48:10 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9VIo-000fIuC; Mon, 21 Nov 94 01:44 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id SAA00449 for alife-game@alnilam.krl.caltech.edu; Sun, 20 Nov 1994 18:24:46 -0800 Date: Sun, 20 Nov 1994 18:24:46 -0800 From: Adrian Tymes Message-Id: <199411210224.SAA00449@mcl.mcl.ucsb.edu> To: alife-game@alnilam.krl.caltech.edu Subject: Eggs and feeding How do you want the Universe to handle collisions between aliens and eggs? I presume that collisions between aliens and food would result in the aliens eating, but if aliens can eat other aliens' eggs, how should the universe code tell when an alien wants to eat an egg and when it wants to fertilize an egg? Or should we just drop the possiblility of alien omlettes and say that the first alien to an egg fertilizes it, and everyone else (except for bullets, of course) bounces off it harmlessly until the egg hatches. From ???@??? Mon Nov 21 07:25:26 1994 Received: from mickey.iaccess.za (root@mickey.iaccess.za [192.96.87.10]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id HAA21289 for ; Mon, 21 Nov 1994 07:16:53 -0500 Received: from lostlink by mickey.iaccess.za with uucp (Smail3.1.28.1 #5) id m0r9Xhn-0004VaC; Mon, 21 Nov 94 14:18 GMT+0200 Received: by chameleon.alt.za (0.99 pl3) id AA02537; 21 Nov 94 06:01:04 +0200 From: g-j@chameleon.alt.za (Gert-Jan van Rooyen) Date: 21 Nov 94 00:04:12 +0200 Subject: Re: plot Message-ID: <051_9411210601@chameleon.alt.za> Organization: Chameleon BBS To: st944m5h@post.drexel.edu On 19 Nov 94 Christian wrote: ch> I`m beginning to think that what we`re *actually* doing here is far ch> more interesting than any plot we could develop. If the development ch> of a whole new ecosystem within a game, the use of evolution, morphing, ch> an artificial intellegence for each of the enemies, and the biggest ch> (in terms of users) experiment into artificial life ever isn`t enough ch> to grab the player`s imagination, then I don`t know what will be! The game consumer is a fussy species... 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 ???@??? Mon Nov 21 07:55:22 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 HAA22571 for ; Mon, 21 Nov 1994 07:47:19 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9Y56-000fIvC; Mon, 21 Nov 94 04:42 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 NAA12497 for ; Mon, 21 Nov 1994 13:40:44 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id NAA03818 for alife-game@alnilam.krl.caltech.edu; Mon, 21 Nov 1994 13:40:41 +0100 From: Martijn Faassen Message-Id: <199411211240.NAA03818@laurel.stud.phil.ruu.nl> Subject: plot To: alife-game@alnilam.krl.caltech.edu (Evolving Destruction) Date: Mon, 21 Nov 1994 13:40:40 +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: 2080 > > People have been throwing around plot ideas, and speculating on whether the > game should be set in space, or on the ground, or in between. There have > been discussions about the plot and the story behind the game. Space vs ground is quite an important Universe distinction. (Like Charles said, ground allows for walls..though we might do 'space walls' or whatever :) > I`m beginning to think that what we`re *actually* doing here is far more > interesting than any plot we could develop. If the development of a whole > new ecosystem within a game, the use of evolution, morphing, an artificial > intellegence for each of the enemies, and the biggest (in terms of users) > experiment into artificial life ever isn`t enough to grab the player`s > imagination, then I don`t know what will be! True, that's why we (at least I) have been coming up with the story *behind* the game, which is relevant for discussions on Universe. Also, I've come up with a 'research' scheme for the player, slowly enabling the player to get better weapons (that evolved in the aliens), scanners, etc. This would be interesting, and not too hard to implement. I agree we should stop for now talking about plot though, but let's just keep this 'research' scheme in mind. :) > We`re devising a new universe here. Let`s just do everything we can to make > it an interesting and working place, for evolution to happen in, and if it > comes out fitting into a plot idea, fine, but if it doesn`t, some of the > best games haven`t been tied to the `real` universe (Tetris, for example). > > -------------------------------------------------------------------------. > !Email christian@darkin.demon.co.uk > !Mail Sent Via Demon Internet Services ! > !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! > `-------------------------------------------------------------------------' > True, plots shouldn't bog us down, but they might inspire us too! -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Nov 21 11:21:10 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 LAA17190 for ; Mon, 21 Nov 1994 11:16:12 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9bKB-000fIxC; Mon, 21 Nov 94 08:10 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id aa19224; 21 Nov 94 16:06 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA0030r; Mon, 21 Nov 94 14:11:46 GMT Date: Mon, 21 Nov 94 14:11:46 GMT Message-Id: <9411211411.AA0030q@darkin.demon.co.uk> In-Reply-To: <199411210224.SAA00449@mcl.mcl.ucsb.edu> (from Adrian Tymes ) (at Sun, 20 Nov 1994 18:24:46 -0800) 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: Re: Eggs and feeding Hi Adrian, > How do you want the Universe to handle collisions between aliens and eggs? > I presume that collisions between aliens and food would result in the aliens > eating, but if aliens can eat other aliens' eggs, how should the universe > code tell when an alien wants to eat an egg and when it wants to fertilize > an egg? Or should we just drop the possiblility of alien omlettes and say > that the first alien to an egg fertilizes it, and everyone else (except > for bullets, of course) bounces off it harmlessly until the egg hatches. > > How about saying that anything that hits anything else in the game imparts a certain momentum to what it hits, and does a certain damage depending on the momentum of the collision. That`s a universal law. Other things like feeding and fertilizing would be applied seperately, and the alien`s intention to mate or eat would be flagged so the universe would know how to treat it. We could either make the feed/fertilise flag override the universal law of collission damage (in which case you could eat or fertilize by flying through the egg at high speed) or we could have the rules work together so that in order to feed or fertilize you`d have to dock slowly with the egg to avoid damaging it or yourself. That would give a more realistic feel, and an opportunity to attack a creature while it`s doing its work. However, it would mean you`d have to be that much more advanced an alien before you`d get things to work for you. -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Mon Nov 21 12:41: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 MAA29029 for ; Mon, 21 Nov 1994 12:29:40 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9caz-000fIyC; Mon, 21 Nov 94 09:32 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 MAA28844 for ; Mon, 21 Nov 1994 12:28:29 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Nov 1994 12:33:05 -0500 To: ag-alife@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: plot >Space vs ground is quite an important Universe distinction. (Like Charles >said, ground allows for walls..though we might do 'space walls' or whatever :) If we implement walls, that will add a whole new level of complexity(course plotting) which is a sub-field in robotics, I believe, anyway, I think it's far too complicated to add at this point. >> I`m beginning to think that what we`re *actually* doing here is far more >> interesting than any plot we could develop. If the development of a whole >> new ecosystem within a game, the use of evolution, morphing, an artificial >> intellegence for each of the enemies, and the biggest (in terms of users) >> experiment into artificial life ever isn`t enough to grab the player`s >> imagination, then I don`t know what will be! Of course most of -us- will feel that way, but the people who play may not really care as much about how the aliens get smarter, just -if- they get smarter. Hopefully, this program will get more people interested in the field though. >True, that's why we (at least I) have been coming up with the story >*behind* the game, which is relevant for discussions on Universe. > >Also, I've come up with a 'research' scheme for the player, slowly enabling >the player to get better weapons (that evolved in the aliens), scanners, >etc. This would be interesting, and not too hard to implement. I agree >we should stop for now talking about plot though, but let's just keep >this 'research' scheme in mind. :) I think I've said this already, but I *love* this idea! It ties together the game, and allows for a good plot, plus adding believability to the whole thing. Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Nov 21 12:41: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 MAA29353 for ; Mon, 21 Nov 1994 12:31:31 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9cb6-000fIzC; Mon, 21 Nov 94 09:32 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 MAA28883 for ; Mon, 21 Nov 1994 12:28:44 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Nov 1994 12:33:13 -0500 To: ag-alife@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Re: Eggs and feeding >How about saying that anything that hits anything else in the game imparts >a certain momentum to what it hits, and does a certain damage depending >on the momentum of the collision. > >That`s a universal law. I agree with this; it is simple, and allows for more complex actions to develop. >Other things like feeding and fertilizing would be applied seperately, and >the alien`s intention to mate or eat would be flagged so the universe would >know how to treat it. > >We could either make the feed/fertilise flag override the universal law of >collission damage (in which case you could eat or fertilize by flying >through the egg at high speed) or we could have the rules work together so >that in order to feed or fertilize you`d have to dock slowly with the egg >to avoid damaging it or yourself. That would give a more realistic feel, >and an opportunity to attack a creature while it`s doing its work. However, >it would mean you`d have to be that much more advanced an alien before >you`d get things to work for you. As I said in another message, the fertilizer should pick up the egg(at whatever speed). If the alien is killed while holding the egg, it would simply eject it(as long as the fertilization had taken place). Michael Mitchener st944m5h@post.drexel.edu From ???@??? Mon Nov 21 18:56:31 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 QAA11905 for ; Mon, 21 Nov 1994 16:29:49 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9gCZ-000fItC; Mon, 21 Nov 94 13:23 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA66164; Mon, 21 Nov 1994 13:22:18 -0800 Date: Mon, 21 Nov 1994 13:22:17 -0800 (PST) From: Gregory Glen Taylor Subject: Re: Eggs and feeding To: alife-game@alnilam.krl.caltech.edu In-Reply-To: <199411210224.SAA00449@mcl.mcl.ucsb.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think what will decide this is a final decision on what style the game will be. Currently there are two general theories: HUMAN: The player is a human and must shoot the aliens. He gains new lives by his research team on the mothership who add new stuff periodically...improving his ship. ALIEN: The player is an alien like the rest, who has to protect his eggs, for they will become extra lives. This would involve the player fertilizing eggs laid by aliens. A less grotesque way to think about it is thru Martijn's self-replicating droids gone mad...Same stuff goes on, but the moral police like robots better than mating aliens. I'll write up a summary of the Alien/Robot method, would someone else like to write up a summary of the Human one? Then we can do a group vote on it. I'll post my summary of the Alien method later today...(hopefully). -=GT=- From ???@??? Mon Nov 21 18:56:33 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 QAA12054 for ; Mon, 21 Nov 1994 16:30:54 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9gI6-000fIuC; Mon, 21 Nov 94 13:28 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA93834; Mon, 21 Nov 1994 13:28:10 -0800 Date: Mon, 21 Nov 1994 13:28:09 -0800 (PST) From: Gregory Glen Taylor Subject: Space vs. Ground To: Evolving Destruction In-Reply-To: <199411211240.NAA03818@laurel.stud.phil.ruu.nl> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I see doing a ground backdrop as posing a bit of a problem. If we choose a space-backdrop we can do a star-scrolly (various levels of stars), which will produce a nice-looking output, but it will be faster and more memory conscious, than a bitmap for the ground. Plus if we manage it right, it may also assist in producing easy collision detection...but that's another story. Thoughts? -=GT=- From ???@??? Mon Nov 21 18:56: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 QAA12513 for ; Mon, 21 Nov 1994 16:34:09 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9fOc-000fIrC; Mon, 21 Nov 94 12:31 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA08370; Mon, 21 Nov 1994 12:29:45 -0800 From: Charles Ofria Message-Id: <9411212029.AA08370@altair.krl.caltech.edu> Subject: Re: Species To: christian@darkin.demon.co.uk Date: Mon, 21 Nov 1994 12:29:25 -0800 (PST) In-Reply-To: <9209021350.AA002zw@darkin.demon.co.uk> from "Christian Darkin" at Sep 2, 92 01:50:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4749 Sender: charles@altair.krl.caltech.edu -- From: Christian Darkin [munch on my species stuff...] > You know I suggested having different diets by giving each creature a > `nutrition index` and a `nutrition requirement` worked out from the genetic > make-up of the creature, and then having each creature get energy from its > prey acording to how closely the two numbers corrisponded? Well, it > strikes me that the same values could be used to determine species and > compatibility: > > If you take two potential mates and compare their nutrition indexes, the > closer they are to each other, the more likely they are to have similar > genetic make-ups. Compare the nutrition requirement, and you get a double > check. That way, you`d be more likely to mate with something that has a > similar `taste` to yourself and a similar diet. Thus, you`d be similar > creatures (or are more likely to be). Well, I think that there might not be even a reason to have these as two seperate numbers... We could just come up with some function to put this number through to get a nutritional index. At first I was thinking of some direct comparison on the number of 0's or 1's, but now I'm realizing that that would create gravities towards (or away from) all 0's and all 1's. We don't want two completely different creatures to be able to mate just because they have the same diet (I know this wasn't what you were saying Chris; I'm just busily shooting down my own argument here) But anyway, yes, this is reasonable. If we have a nutritional index, it can be used to tell how similar two creatures are. Similarly, any other 'indicies' we might have could also be used. > We should make it increasingly less likely that two creatures would mate > the further apart their nutrition variables were. Also, the spread we allow > in this calculation (ie. the amount of difference between the creatures that > would be acceptable) should be one of the things in the evolutionary melting > pot. That way, even if we don`t get the right balance between bio-diversity > and stillborn mutations, that balance will evolve in. This I think I really like - allowing each species to adjust how strict it is on its genetic code. Quite beautiful. I'll run some simulations on this to see how quickly they adjust this parameter, and just what happens with it. I'll get back to you guys in a few weeks on it. :-) This species stuff is something I want to investigate a lot more. Much of what I said in my original article are just my own theories which I am going to be trying to substantiate (which should be done before any serious coding of the ideas is started). > I had an idea for the original game before we started all this discussion > that there would be a stage between each wave of attack where the player > would be put into a smaller arena with a whole load of potential offspring > from each alien pairing that had mated during the preceeding wave. Each > creature would represent a possible new species, and the player would be > given a certain amount of time to go around and blast as many as possible. > > That way, only those that survived that would go on to form new species > (be cloned for the next stage). I realise that this method is a bit of > a blunt instrument, and not really in tune with the rest of our ideas, and > I know it doesn`t test for how the creature would react as a `real` species > but it would knock out the worst of the mutations. Maybe there`s some > way we could do a kind of theoretical gene battle between possible offspring > while they`re still in the egg? I'm not sure about doing this battle within an egg, but it might be useful to set something like this up to test the viability of any internal structure for the creatures... > Here`s another question: What about the fact that in nature some animals > become super-adept at fitting into a particular slot. Either they have a > very specialised diet, or a very specialised defense mechanism, > or their behaviour is utterly singular. These creatures somehow get more > out of their chosen environment than more general creatures, but they live > on an environmental knife edge. Are such creatures going to have a > chance in our world, or not? With evolution going so fast, I don`t know > if they`ll be able to get a foothold. I also don`t know if we`ve even got > the potential for the environmental nooks for them to fit into. The thing > is, they do provide some of the world`s most interesting behaviour and > evolutionary ideas. Just a thought. If we have any form of landscapes, then we will certainly have the potential for this. I don't know if they will show up, but I'm going to try my damndest to give them a fighting chance. --- Charles From ???@??? Mon Nov 21 18:56:35 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 QAA12709 for ; Mon, 21 Nov 1994 16:35:24 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9g5w-000fIsC; Mon, 21 Nov 94 13:16 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA08848; Mon, 21 Nov 1994 13:14:31 -0800 From: Charles Ofria Message-Id: <9411212114.AA08848@altair.krl.caltech.edu> Subject: Mailing List update. To: ag-general@alnilam.krl.caltech.edu Date: Mon, 21 Nov 1994 13:14:30 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 863 Greetings, All the mailing lists have been updated, and additionally two new ones have been created: ag-art-soundalnilam.krl.caltech.edu ag-AMIGA@alnilam.krl.caltech.edu I urge people to start using the new mailing lists. Also, I'd like to just make a couple of comments about the use of the lists. Depending on your news reader, if you hit reply it may only respond to the orignial sender, or else it will respond to the entire list; please take note of which it does and remember this. I think a number of people have been replying only to the original sender rather than to the list as a whole (which was their intent). In the past I have also noticed people (on other mailing lists) respond with private messages to the list. If you need help on how your mail-reader works, I'm familiar with most of the ones on unix systems... --- Charles From ???@??? Mon Nov 21 18:56: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 QAA16352 for ; Mon, 21 Nov 1994 16:56:25 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9gbf-000fIrC; Mon, 21 Nov 94 13:49 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57022-1>; Mon, 21 Nov 1994 16:47:02 -0500 Date: Mon, 21 Nov 1994 16:46:47 -0500 From: Jeff Lait Subject: Re: Space vs. Ground To: Gregory Glen Taylor cc: Evolving Destruction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Nov 1994, Gregory Glen Taylor wrote: > I see doing a ground backdrop as posing a bit of a problem. If we choose > a space-backdrop we can do a star-scrolly (various levels of stars), > which will produce a nice-looking output, but it will be faster and more > memory conscious, than a bitmap for the ground. Excellent idea. I was thinking about a tiled star back drop, which is adequate for ModeX, but in hirez would result in major pain. I always prefer algorithmic based methods to brute force (Ie: stars to tiles :>), besides, it will hopefully be noticibly faster on hi res. > Plus if we manage it right, it may also assist in producing easy > collision detection...but that's another story. Sorry... Don't follow you here - collision detection looks equally hard either way... - Jeff Lait (SOL) From ???@??? Mon Nov 21 18:56:38 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 RAA17296 for ; Mon, 21 Nov 1994 17:01:43 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9gpJ-000fIvC; Mon, 21 Nov 94 14:03 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id OAA19056 for ag-general@alnilam.krl.caltech.edu; Mon, 21 Nov 1994 14:01:24 -0800 Date: Mon, 21 Nov 1994 14:01:24 -0800 From: Adrian Tymes Message-Id: <199411212201.OAA19056@mcl.mcl.ucsb.edu> To: ag-general@alnilam.krl.caltech.edu Subject: Eggs and feeding SoSo, why not just ditch the "moral police" and go with breeding aliens? [1/2 :) ...this is also a serious question] From ???@??? Mon Nov 21 18:56: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 RAA21317 for ; Mon, 21 Nov 1994 17:24:40 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9h3w-000fIuC; Mon, 21 Nov 94 14:18 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA09314; Mon, 21 Nov 1994 14:16:30 -0800 From: Charles Ofria Message-Id: <9411212216.AA09314@altair.krl.caltech.edu> Subject: Re: Eggs and feeding To: alife-game@alnilam.krl.caltech.edu Date: Mon, 21 Nov 1994 14:16:29 -0800 (PST) In-Reply-To: from "Gregory Glen Taylor" at Nov 21, 94 01:22:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1468 -- By: Gregory Glen Taylor > > I think what will decide this is a final decision on what style the game > will be. Currently there are two general theories: > > HUMAN: The player is a human and must shoot the aliens. He > gains new lives by his research team on the mothership > who add new stuff periodically...improving his ship. > > ALIEN: The player is an alien like the rest, who has to protect > his eggs, for they will become extra lives. This would > involve the player fertilizing eggs laid by aliens. > > A less grotesque way to think about it is thru Martijn's > self-replicating droids gone mad...Same stuff goes on, but > the moral police like robots better than mating aliens. I still like the idea of the player simply controlling (through whatever means) a normal alien. The way I look at it, the humans inserted a new gene into the alien population. Any creature with this gene can be controlled by the player. At the start of the game, only the one creature has it, but as the player fertilized eggs, there is a chance with each one that it will pass on the proper gene (and thus give the player an "extra life") The means of control could either be psyonic or technilogical. > I'll write up a summary of the Alien/Robot method, would someone else > like to write up a summary of the Human one? Then we can do a group vote > on it. I'll post my summary of the Alien method later today...(hopefully). > > -=GT=- > From ???@??? Mon Nov 21 18:56: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 RAA23448 for ; Mon, 21 Nov 1994 17:38:29 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9gth-000fIsC; Mon, 21 Nov 94 14:07 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA09237; Mon, 21 Nov 1994 14:05:56 -0800 From: Charles Ofria Message-Id: <9411212205.AA09237@altair.krl.caltech.edu> Subject: Creature control structures... To: ag-alife@altair.krl.caltech.edu Date: Mon, 21 Nov 1994 14:05:11 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 7219 Sender: charles@altair.krl.caltech.edu Greetings, Well, I guess its time to discuss the big question; which control structure to use on the creatures. I don't have as much time to write this at the moment as I might like, so I'm only going to cover a couple of ideas, and not particularly completely. Please fill in details as you see fit (as well as adding on other methods). I'll try to write a bit more later tonight. Method 1: Pure assembly-based creatures. Details: This method would involve us desinging an assembly language similar to that of Tierra or Avida, and letting it just run. Anything special that the creatures want to develop, they can (it can be a very complete language); they'll have no pre-defined internal structure. Virtues: Creatures of this type will, in the end, be capable of doing anything. No limitations of any kind will be placed on them by confining them to a particular structure. The most complex of behaviors will theoretically be able to develop. Also, this should be fairly easy to code. Flaws: Evolution takes longer. We'll notice less of it during the course of the game. We will have long unweildy creatures which will more often than not break under cross-over. (We would definatly have to use the species scheme to have any chance of useful evolution during the course of a single gaming session) Comments: If we are going to use another scheme that requires us to develop an assembly language anyway, then I think that it would be fairly trivial to impliment this and try it out. I don't, however, think that we should count on this in anyway. Method 2: Segmented assembly-based creatures. Details: This would involve having a number of segments (genes) of code making up a creature. During reproduction the individual segments are compared and re-combined rather than the creature as a whole. This way segments can specialize in specific activities, and if done properly, only similar methods would be crossed. Virtues: Has all of the virtues of Method 1 (creatures can, after all, be only one segment), plus we can now re-combine in a much easier fassion. We don't have to worry as much about re-combining unrelated sections of code; only similar segments will be recombined. The rate of still-births should be about the same, but the variation in creatures will increase. Comment: I think this method has a lot more potential than Method 1, but I'm still unertain about it in the end. Creatures effectvely become function based having to call other segments of themselves... Method 3: Modualized assembly based creatures. Details: Again, this is an extension of Method 2. Effectively all we are doing is giving each segment more of a structure. Rather than relying on the various segments to call each other, we give a "priority function" on each module. Whenever one module finishes, the priority functions of all the modules are compared to determine which should go next. We should also have all the priority functions have a threshold; if ever a threshold is reached is passed, the creature drops whatever its doing an jumps to that module. The priority function would simply be the weighted sum of all the sesory inputs plus (perhaps) a couple of special registers so that the creature can manipulte the function sesativities while running. Finally, we could also have other kinds of flags attached to each module - I haven't thought about this yet. Virtues: Like Method 2, this can be reduced to Method 1 simply by having only one module (then it just doesn't matter what the priority is). It also provides a nice mix between an intrupt driven system and a purely function based system; at all times, individual genes are used as the current situation dictates. Flaws: This method may start providing too much structure on the creatures in limiting what they can do (over method 2 that is), but if we allow one module to simply call another without triggering its priority flag, then I think that it should be good. Another flaw is that this is starting to get complex; I'm uncertain of how much CPU time it will take to maintain such a creature. Comments: I think this will be our best bet... Method 4: Object-Oriented assembly based creatures. Details: This is one step beyond modularized which I'm still thinking about. In general, some modules would be objects which other modules interact with in various ways. If there is enough interest, I will try to come up with a more detailed structure for this. Virtues: Maximum flexibility with minimum constraints on creatures. Flaws: What the heck, the people at cray are always complaining that not enough people write games for their machines, right? Comments: I think this would be a bit much CPU power to have interpretors constantly running on all these object oriented creatures. (managing object can get intensive). Method 5: neural-network based creatues. Details: This would involve a simple network where input nodes recieve data from all of the creatues senses (we have to come up with how those work regardless of the internal model we use) and output nodes are just the virtual keypresses. I'm thinking in terms of either a relatively large feed-forward network, or a relatively small Hopfield network. Virtues: For the feed forward network, it should be quite fast and decently skilled (as a potential). For the Hopfield network it has an amazing potential that it will theoretically be able to easily rival the human players (when weighted right, these things are remarkable). Flaws: Neural networks are unfortunately difficult to evolve. Crossover invariably breaks it (since all the weights are in a delicate balance), and point mutations are too slow (since they can't wildly vary any weight without again throwing off the balance). Oh, and one really big flaw; it will be almost impossible to seed because humans have an exceedingly difficult time at manually programming a neural network. Comments: Like Method 1, I think this is something that we should try out if we are going to do something that involves a neural network anyway, but we shouldn't concentrate on this method. Method 6: Assembly based creature with access to a network. Details: This would be a combination of Method 5 with one of the others (I think 3 would work best). This makes the creature primarily controlled by the other method, but the assembly language is written such that it can write the inputs and read the outputs from the neural net. It gets to "decide" which aspects it wants to use the net for. It should also be able to manually adjust the weights, and thus allow for an easy method of lifetime- learning. Virtues: This is a very nice system combining the best aspects of the previous. Additionally, we can easily adjust the size of the network without any dire consequences. Flaws: This will be complex to program (perhaps) and the come up with a secure assembly language for. Comments: I want to do this one eventually regardless... I just don't think its a good ideas to start with. Well, I have a few more ideas, but I have to run now. I'll try and write more later. Tell me what you think of these. --- Charles From ???@??? Mon Nov 21 18:57:02 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 RAA25181 for ; Mon, 21 Nov 1994 17:48:24 -0500 Received: from spsgate.sps.mot.com by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9hTA-000fJ0C; Mon, 21 Nov 94 14:44 PST Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA28614 for alife-game@alnilam.krl.caltech.edu; Mon, 21 Nov 94 15:42:31 MST Received: from txbc.sps.mot.com ([192.88.171.200]) by mogate (4.1/SMI-4.1/Email-2.0) id AA25609; Mon, 21 Nov 94 15:42:30 MST Received: from wetware.sps.mot.com by txbc.sps.mot.com with SMTP (1.38.193.4/16.2) id AA29158; Mon, 21 Nov 94 16:42:28 -0600 Received: by wetware.sps.mot.com (4.1/SMI-4.1) id AA27504; Mon, 21 Nov 94 16:46:30 CST Date: Mon, 21 Nov 94 16:46:30 CST From: chance@wetware.sps.mot.com (Chance Harris) Message-Id: <9411212246.AA27504@wetware.sps.mot.com> To: alife-game@alnilam.krl.caltech.edu Subject: Re: Eggs and feeding > From gtaylor@violin.aix.calpoly.edu Mon Nov 21 15:41:14 1994 > Date: Mon, 21 Nov 1994 13:22:17 -0800 (PST) > From: Gregory Glen Taylor > Subject: Re: Eggs and feeding > To: alife-game@alnilam.krl.caltech.edu > Mime-Version: 1.0 > Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> > Content-Length: 888 > > I think what will decide this is a final decision on what style the game > will be. Currently there are two general theories: > > HUMAN: The player is a human and must shoot the aliens. He > gains new lives by his research team on the mothership > who add new stuff periodically...improving his ship. > > ALIEN: The player is an alien like the rest, who has to protect > his eggs, for they will become extra lives. This would > involve the player fertilizing eggs laid by aliens. > > A less grotesque way to think about it is thru Martijn's > self-replicating droids gone mad...Same stuff goes on, but > the moral police like robots better than mating aliens. > > I'll write up a summary of the Alien/Robot method, would someone else > like to write up a summary of the Human one? Then we can do a group vote > on it. I'll post my summary of the Alien method later today...(hopefully). > > -=GT=- > Hey everybody, I've been just lurking for a few days now. didn't check my mail all weekend -- quite a few messages. Has the egg-laying thing become pretty much the consensus? To me, it just seems too complicated, I think we should do the breeding off-line between levels. This doesn't seem to be a very popular opinion. It seems like just getting the little guys to fight effectively will be tough enough, and we should start without egg laying or energy reserves, and just make sure the universe code is written modularly enough to allow these kinds of things in the future. And maybe gradually phase in egg laying, i.e. for a while, still have breeding sessions between levels, but also make it possible for egg laying to occur, and then gradually increase the amount of time between levels. I'm getting kind of confused about how things are turning out. Here is how I originally pictured things happening: Genes are weights on a neural net, possibly pretty low precision, for speed (16 or maybe 8 bit weights ??). Inputs: (relative ?) position of 3 brother aliens (relative ?) position of human player, current heading current speed Outputs: turn left turn right thrust shoot *IF* , and its a big IF we could hack the right fitness function, I think off-line breeding of aliens like this would evolve a lot faster and into meaner pilots than egg-laying schemes. Now it is a big if, but I don't think its huge, keep track of how long an alien stays alive, and keep track of who gets the closest shots off at the human, and make up a formula that looks good. Also, in my opinion, we are going to have to do some kind of fitness function of some sorts at some time. If survival is all they have to do, it going to just become a predator prey relationship (IMHO), and if aliens don't get partial credit for getting a "close" shot off then I don't think they are ever going to ever learn how to shoot back. And by a "close" shot, I mean something that is based on how good the other aliens did at shooting at the human, suppose in our initial population, only one aliens shoots the whole time, regardless of how close he came to hitting the human, I think we *have* to reward his gene-line right there, or we are locked into sheep-alien breeding for quite a while. I think the first Neural input I have listed here - posistions of three brother aliens, could work really well. Instead of having all the aliens know about all the stuff on the screen, they could just know about a limited number of their sibling-aliens. I hoping we could eventually get flocking-type emergent behaviour out of this, for a pretty cheap CPU-time cost. The Universe: I think aliens shouldn't be able to collide with each other, and if aliens can't collide with asteroids either that frees up lots of compute time. These things just seem like extra CPU w/ respect to actual game play and w/ respect to how hard it is to evolve things that can play aorund it. Chance chance@wetware.sps.mot.com From ???@??? Mon Nov 21 18:57:04 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 SAA28970 for ; Mon, 21 Nov 1994 18:11:34 -0500 Received: from mcl.mcl.ucsb.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9huO-000fIrC; Mon, 21 Nov 94 15:12 PST Received: (uwingcat@localhost) by mcl.mcl.ucsb.edu (MCL.UCSB.EDU-HPUX-1.0-b) id OAA18486 for ag-general@alnilam.krl.caltech.edu; Mon, 21 Nov 1994 14:00:18 -0800 Date: Mon, 21 Nov 1994 14:00:18 -0800 From: Adrian Tymes Message-Id: <199411212200.OAA18486@mcl.mcl.ucsb.edu> To: ag-general@alnilam.krl.caltech.edu Subject: Space vs. Ground What advantages does ground have at all? From ???@??? Mon Nov 21 19:24: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 TAA07855 for ; Mon, 21 Nov 1994 19:07:51 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9inV-000fIrC; Mon, 21 Nov 94 16:09 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 BAA27923 for ; Tue, 22 Nov 1994 01:07:16 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id BAA14178 for ag-alife@alnilam.krl.caltech.edu; Tue, 22 Nov 1994 01:07:12 +0100 From: Martijn Faassen Message-Id: <199411220007.BAA14178@laurel.stud.phil.ruu.nl> Subject: Creature control structures... To: ag-alife@alnilam.krl.caltech.edu (ag alife) Date: Tue, 22 Nov 1994 01:07:11 +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: 13737 > Greetings, > > Well, I guess its time to discuss the big question; which control > structure to use on the creatures. I don't have as much time to write > this at the moment as I might like, so I'm only going to cover a couple of > ideas, and not particularly completely. Please fill in details as you > see fit (as well as adding on other methods). I'll try to write a bit more > later tonight. > > Method 1: Pure assembly-based creatures. > Details: This method would involve us desinging an assembly language similar > to that of Tierra or Avida, and letting it just run. Anything > special that the creatures want to develop, they can (it can be a > very complete language); they'll have no pre-defined internal > structure. > Virtues: Creatures of this type will, in the end, be capable of doing anything. > No limitations of any kind will be placed on them by confining them > to a particular structure. The most complex of behaviors will > theoretically be able to develop. Also, this should be fairly easy > to code. > Flaws: Evolution takes longer. We'll notice less of it during the course of > the game. We will have long unweildy creatures which will more often > than not break under cross-over. (We would definatly have to use > the species scheme to have any chance of useful evolution during the > course of a single gaming session) > Comments: If we are going to use another scheme that requires us to develop > an assembly language anyway, then I think that it would be fairly > trivial to impliment this and try it out. I don't, however, think > that we should count on this in anyway. Agreed, this would be simply a 'single gene' creature approach, then. > > Method 2: Segmented assembly-based creatures. > Details: This would involve having a number of segments (genes) of code > making up a creature. During reproduction the individual segments > are compared and re-combined rather than the creature as a whole. > This way segments can specialize in specific activities, and if done > properly, only similar methods would be crossed. > Virtues: Has all of the virtues of Method 1 (creatures can, after all, be > only one segment), plus we can now re-combine in a much easier > fassion. We don't have to worry as much about re-combining unrelated > sections of code; only similar segments will be recombined. Why do only similar segments get recombined? Ah..yes..I think I understand.. then..how to determine similarity? > The rate of still-births should be about the same, but the variation > in creatures will increase. > Comment: I think this method has a lot more potential than Method 1, but I'm > still unertain about it in the end. Creatures effectvely become > function based having to call other segments of themselves... > > > Method 3: Modualized assembly based creatures. > Details: Again, this is an extension of Method 2. Effectively all we are > doing is giving each segment more of a structure. Rather than > relying on the various segments to call each other, we give a > "priority function" on each module. Whenever one module finishes, > the priority functions of all the modules are compared to determine > which should go next. We should also have all the priority > functions have a threshold; if ever a threshold is reached is passed, > the creature drops whatever its doing an jumps to that module. I'm not sure if such a treshhold is strictly necessary. Might be confusing.. I wonder if it would be possible to evolve this easily from a set of priority increase/decrease instructions (which can increase or decrease the priority value of any module), and a 'jump to highest priority' instruction.. > The priority function would simply be the weighted sum of all the > sesory inputs plus (perhaps) a couple of special registers so that > the creature can manipulte the function sesativities while running. Why not let this be determined by the creature entirely by itself? See later when I describe my scheme. > > Finally, we could also have other kinds of flags attached to each > module - I haven't thought about this yet. > Virtues: Like Method 2, this can be reduced to Method 1 simply by having > only one module (then it just doesn't matter what the priority is). > It also provides a nice mix between an intrupt driven system and a > purely function based system; at all times, individual genes are > used as the current situation dictates. > Flaws: This method may start providing too much structure on the creatures > in limiting what they can do (over method 2 that is), but if we > allow one module to simply call another without triggering its > priority flag, then I think that it should be good. Another flaw is > that this is starting to get complex; I'm uncertain of how much CPU > time it will take to maintain such a creature. > Comments: I think this will be our best bet... If we can get somekind of simple, flexible basis for this scheme, I agree we should go for it. (see my brainstorming session coming up below again) > Method 4: Object-Oriented assembly based creatures. > Details: This is one step beyond modularized which I'm still thinking about. > In general, some modules would be objects which other modules interact > with in various ways. If there is enough interest, I will try to > come up with a more detailed structure for this. Yes, I'd like to hear more about this. > Virtues: Maximum flexibility with minimum constraints on creatures. > Flaws: What the heck, the people at cray are always complaining that not > enough people write games for their machines, right? *laugh*..such a scheme isn't necessarily much slower than any other scheme we might devise..if we do it smartly. :) > Comments: I think this would be a bit much CPU power to have interpretors > constantly running on all these object oriented creatures. (managing > object can get intensive). We'd need (simple) interpreters anyway, for the instructions, don't we? > Method 5: neural-network based creatues. > Details: This would involve a simple network where input nodes recieve data > from all of the creatues senses (we have to come up with how those > work regardless of the internal model we use) and output nodes are > just the virtual keypresses. I'm thinking in terms of either a > relatively large feed-forward network, or a relatively small > Hopfield network. > Virtues: For the feed forward network, it should be quite fast and decently > skilled (as a potential). For the Hopfield network it has an amazing > potential that it will theoretically be able to easily rival the > human players (when weighted right, these things are remarkable). > Flaws: Neural networks are unfortunately difficult to evolve. Crossover > invariably breaks it (since all the weights are in a delicate > balance), and point mutations are too slow (since they can't wildly > vary any weight without again throwing off the balance). Oh, and > one really big flaw; it will be almost impossible to seed because > humans have an exceedingly difficult time at manually programming > a neural network. > Comments: Like Method 1, I think this is something that we should try out > if we are going to do something that involves a neural network > anyway, but we shouldn't concentrate on this method. Agreed. > Method 6: Assembly based creature with access to a network. > Details: This would be a combination of Method 5 with one of the others > (I think 3 would work best). This makes the creature primarily > controlled by the other method, but the assembly language is > written such that it can write the inputs and read the outputs > from the neural net. It gets to "decide" which aspects it wants > to use the net for. It should also be able to manually adjust > the weights, and thus allow for an easy method of lifetime- > learning. > Virtues: This is a very nice system combining the best aspects of the > previous. Additionally, we can easily adjust the size of the > network without any dire consequences. Such a hybrid would be very interesting, if we manage to come up with an elegant mix. > Flaws: This will be complex to program (perhaps) and the come up with > a secure assembly language for. Agreed. > Comments: I want to do this one eventually regardless... I just don't think > its a good ideas to start with. Agreed again! > Well, I have a few more ideas, but I have to run now. I'll try and write > more later. Tell me what you think of these. > > --- Charles Okay, here's my idea, based on segmented/priority assembly code. (option 3 if I recall it well :) An alien mind is: - Controlled by modules (genes). A module is: - Assembly code instructions. The assembly code instructions can: - access directions, distances, energy levels, etc, etc, of itself and other objects. (accessing variables) - FIRE, LEFT, RIGHT, THRUST, and things like BREED, EAT, and WEAPON (to switch weapon). - access priorities of any module in the mind. - increase/decrease any priorities of any module of the mind. - jump to module with highest priority. Possibly (see below) - access, and increase/decrease any treshold of any module of the mind. Modules can possibly have - thresholds, if priority rises above this treshold, the instruction pointer jumps there automatically. Idea: Each creature has not one, but *two* (or possibly more?) instruction pointers. One constantly moves to the module which has the highest priority. It's can get interrupted. The other one simply follows a module and only jumps when a jump instruction occurs, i.e jump to highest priority. This might enable creatures looking somewhat like this: (note: no treshold included here, that's what the interrupt pointer is effectively doing..I hope) Module: perception the non interrupt pointer moves through this module or set of modules over and over again, and increases/decreases the priorities of the diffrent action modules depending on what it perceives, and keeps updating them. Module: action: point and fire if the interrupt pointer arrives here, it will start turning the creature toward the nearest object (for instance) and then fire its weapon. (if not interrupted by something that gets higher priority in the mean time!) Module: action: flee If the interrupt pointer arrives here, it will turn away from the nearest object (or whatever) and then engage thrust a couple of times. (if not interrupted by something else before this!) Module: action: fertilize If the interrupt pointer arrives here, it will turn to the object nearest to the creature, and try to fertilize it. (but it might get interrupted) etc.. This is just one of the possible creature structures that we (and hopefully evolution) might come up with. In this setup the creature keeps on looking for things, if it finds an egg it might increase the priority of fertilize, if it finds a dangerous looking alien near to it though it might increase the priority of flee too, and more. (depends on what it finds more important, be careful or try to fertilize) If the situation changes enough when the creature is doing its action, then the action will get interrupted. We should let all priority values slowly decay, and possibly we should let the priority of the module with the interrupt pointer in it decay faster. If the interrupt pointer doesn't get interrupted I assume it keeps executing whatever instruction comes next, in this way you could have something like 'try to fertilize.. if no interruption..try again..if still no interruption..just eat the thing (who knows?)'. The module might also simply roll into an infinite loop, so with no interruptions it might continue to do the same thing over and over again. More complex schemes become less strict about the action/perception seperation, the action modules might for example change priorities too, or the perception modules might do certain actions, etc. Maybe we should include flags too, like 'this module can interrupt' and 'this module can't interrupt, no matter what it's priority is', which can be turned on and off. (a 'can't be interrupted' flag is interesting too) I hope this story makes some sense to anybody, if not, I'll work on explaining it some more, just let me know. :) There's still a big question about how to recombine these genes? That is, if each gene has a number to designate it (and they have to be designated, because otherwise the priority changing and jump instructions wouldn't have any handle on them) and you just jumble all genes together you get modules calling for modules with numbers which aren't available, and modules with numbers that aren't called at all, etc. So, I imagine each module still has a number, but that calls work stochastically: the module with the number most similar to the call number will have a higher chance of getting called than the modules with numbers more different from the call number. In this scheme, all modules have chance to get called, and usually, but not always, the best fits will be called. Evolution might then for example work out that all modules with numbers around 100 involve 'fire actions' of some kind, and all modules around 23 involve 'flee actions'..It can also place more similar action types close together..It might perhaps be profitable to place the 'attack module' around 50, and the 'flee module' around 55..So, sometimes the creature would attack instead of flee, or flee instead of attacking. Anyway, this is all getting very complex, there's some unifying principle in my ideas somewhere though..I hope.. Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Nov 21 20:35: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 UAA16682 for ; Mon, 21 Nov 1994 20:11:34 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9jhp-000fIrC; Mon, 21 Nov 94 17:07 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <57008-2>; Mon, 21 Nov 1994 20:05:45 -0500 Date: Mon, 21 Nov 1994 20:05:34 -0500 From: Jeff Lait Subject: Re: Eggs and feeding To: Chance Harris cc: alife-game@alnilam.krl.caltech.edu In-Reply-To: <9411212246.AA27504@wetware.sps.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think the first Neural input I have listed here - posistions of three > brother aliens, could work really well. Instead of having all the aliens > know about all the stuff on the screen, they could just know about > a limited number of their sibling-aliens. I hoping we could eventually > get flocking-type emergent behaviour out of this, for a pretty cheap > CPU-time cost. > > The Universe: I think aliens shouldn't be able to collide with each other, > and if aliens can't collide with asteroids either that frees up lots > of compute time. These things just seem like extra CPU w/ respect > to actual game play and w/ respect to how hard it is to evolve > things that can play aorund it. > I think the player might get a bit upset when he watches aliens fly through asteroids that he'd bounce off :> It is probably a good idea to not make it hurt to much to hit them, however, as we don't want all of our aliens to self destruct. But if ramming alien ships works for them, I don't see why we should stop them :> Further, there is no reason I can see off hand why we don't have both neural nets and GA, Alife, or whatever else is being talked about. Implement any that are feasible and see what works. - Jeff Lait (SOL) From ???@??? Mon Nov 21 20:36:10 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 UAA18715 for ; Mon, 21 Nov 1994 20:26:26 -0500 Received: from rpiv.mc.duke.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9jsL-000fIrC; Mon, 21 Nov 94 17:18 PST Received: from localhost (djt@localhost) by rpiv.mc.duke.edu (8.6.4/8.6.4) id UAA06416; Mon, 21 Nov 1994 20:16:58 -0500 Date: Mon, 21 Nov 1994 19:55:19 -0500 (EST) From: Dan Tomso Subject: Re: Eggs and feeding To: alife-game@alnilam.krl.caltech.edu In-Reply-To: <9411212246.AA27504@wetware.sps.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Greetings. Well, I've been doing nothing but lurking here for a while, but I've finally have something to say, so here I go: On Mon, 21 Nov 1994, Chance Harris wrote: (quote of a quote) > > I think what will decide this is a final decision on what style the game > > will be. Currently there are two general theories: > > > > HUMAN: The player is a human and must shoot the aliens. He > > gains new lives by his research team on the mothership > > who add new stuff periodically...improving his ship. > > Seems complicated. In a 'game' (really simulation) that is very complicated already, why add the additional complexity of a mother ship, etc? > > ALIEN: The player is an alien like the rest, who has to protect > > his eggs, for they will become extra lives. This would > > involve the player fertilizing eggs laid by aliens. This is actually a very good plan for a couple of reasons, IMHO: First, it simplifies design--the human player is represented much like the simulated players are. Secondly, it allows for (what I consider) a fascinating twist on the game play--you fertilize eggs with your ship in order to acquire new lives, but you are getting a genetic mix with whatever alien layed the egg in the first place. Consequently, each ship you control will have different capabilities and a different playing style. Furthermore, you would be able to watch where the really kick-ass aliens layed eggs and then high-tail it over to fertilize THOSE eggs--in the next generation, you get a better ship! You can sort of select modifications 'on the fly' by observing other ships and tracking where they lay eggs. (Just imagine if some sort of 'egg defense' behavior evolves--then you have to kill that really nasty alien in order to get a better ship). Finally, having the human-controlled ship behave as an alien would allow us to plug in a robot player of some sort (simplest case--just another alien), and then let the simulation run for a few days without maintainence. This would let the critters evolve to a decently competitive level without someone having to play 100000 games with really dumb aliens. > It seems like just getting the little guys to fight effectively > will be tough enough, and we should start without egg laying > or energy reserves, and just make sure the universe code is > written modularly enough to allow these kinds of things in the > future. And maybe gradually phase in egg laying, i.e. for a while, > still have breeding sessions between levels, but also make it > possible for egg laying to occur, and then gradually increase > the amount of time between levels. I have assumed all along that this was going to be a modular construction, so that we could get the basics coded without adding a lot of fancy behavior. We should really start with the bare bones--the genetics of the system, for example. Here's a sample of the kind of construction I had envisioned: Begin Turn (BT) | Evaluate Fitness (EF) | Breed Next Generation (NG) | Repeat Process So, at the beginning we write a very bare framework that will let us do each of these things--at Begin Turn (BT), we update counters, count critters, etc. At EF, we can do all kinds of crazy things, including 99% of the game play. Finally, at NG we select the top performers based on rankings aquired during EF and breed them though the 'working' part of the genetics system. For purposes of programming, we can develop each of these as something very simple, but also modular. For example, BT could be just incrementing a turn counter. EF we could initially assign as some very simple assessment of fitness (e.g. select for all '1's in our genetic bit string). NG of course would be the most important element to get working from the get-go, since this is really what the game is all about. Then, once things were working, we could really get busy on EF--start representing the genomes more complexly, as aliens, and derive all kinds of cool fitness evaluation schemes (as many of you have already described). This approach allows a solid attack on the programming without biting off more than we can chew. So, whaddya think? Sorry I took so long to post this, but I was waiting until the flurry of activity settled down somewhat. Dan Tomso From ???@??? Mon Nov 21 20:50:21 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 UAA20918 for ; Mon, 21 Nov 1994 20:44:05 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9kJl-000fIrC; Mon, 21 Nov 94 17:46 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA10490; Mon, 21 Nov 1994 17:45:04 -0800 From: Charles Ofria Message-Id: <9411220145.AA10490@altair.krl.caltech.edu> Subject: Assembly languages To: ag-alife@alnilam.krl.caltech.edu Date: Mon, 21 Nov 1994 17:45:03 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3677 Greetings, In thinking about the assembly language, two things we should do is keep the number of instructions low, and make each instruction as well rounded as possible. As an example of an instruction set, here's the one I developed for avida (based off of the set from tierra). There are a total of 26 instructions (I think). The creatures involved have 3 registers (ax, bx, and cx), a stack, and an input and output buffer. 1) Templates (3): These do nothing in and of themselves, but modify other instructions. This occurs in two ways; most of the time it changes the register affected by a command. nop-A, for example, would cause the preceeding command to work on the ax register. From here on, whenever the the format ?ax? is used it implies that ax is the default register for that instruction unless a nop is to follow. The other way these templates can be used is as a reference point for a jump. If nop-A follows a jump-forward command, then it scans forward for the first nop-B and moves the instruction pointer there. This form of template can be more than one nop long. This works very well with three nops because all template have a 3-cycle. Thus for a function call, there would be a jump-forward using template-A which finds template-B. At the end of the function there is a jump-backward with a template-C which goes back to the end of template-A. There is none of the clumsyness which occurs when you only have two templates. nop-A nop-B nop-C 2) Flow control operations (4): if-not-0 : if the ?bx? register is not 0, execute the next instruction, otherwise skip it. (note that nop's are automatically skipped, thus this command causes one extra instruction to be skipped.) This is if-not-0 as opposed to if-0 becuase you typically want to go through a loop until the vairable is 0. Thus you have something like if-not-0; ; jump-backward, jump-forward : jump in to appropriate direction to the rotation of the template which follows. If there is no template, jump bx commands in that direction. if-bit-1 : Similar to if-not-0, only it looks only at the last bit of ?bx?. This is used to develop all kinds of bit-wise operations. 3) Single argument math operations: All of these effect the ?bx? register. (8) shift-right, shift-left : rotate the bits of the register in the appropriate direction. bit-0 : sets the last bit of ?bx? to a 0. set_num : sets bx to the trinary equivilent of the template which follows. If there is no template, set it to 0. This is a bit kludgy (working with trinary and all), but it come out nicely... Mostly its just used as a zero command. inc : ?bx? = ?bx? + 1 dec : ?bx? = ?bx? - 1 push : place ?bx? onto the stack. pop : place the top element on the stack into ?bx? 4) Double argument math operations (4): add : ?bx? = bx + cx sub : ?bx? = bx - cx nand : ?bx? = bx nand cx The all purpose logic operation. order : places bx and cx in the proper order. 5) Biological operations (3): allocate : allocate ?ax? worth of memory at own end. divide : Split at ?ax? into a new cell. copy : copy a command from cx to ax + cx. 6) I/O and sesory (4): get : place the next value from the input buffer into ?cx? put : place ?bx? into the output buffer and set ?bx? to 0 (so that it can't do a rapid put to keep placing the same number in the buffer) search-forward, search-backward : search in the appropriate direction for the compliment template and return its distance. I think that's about it - I might be missing some since I just did this off of the top of my head... --- Charles From ???@??? Mon Nov 21 21:10: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 VAA23168 for ; Mon, 21 Nov 1994 21:02:57 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9kXd-000fIsC; Mon, 21 Nov 94 18:01 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA64194; Mon, 21 Nov 1994 18:00:28 -0800 Date: Mon, 21 Nov 1994 18:00:28 -0800 (PST) From: Gregory Glen Taylor Subject: CURRENT DISCUSSION TOPICS, ***READ*** To: alife-game@alnilam.krl.caltech.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - Alife Game - Current Discussion Topics = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 'announcements only list' (the announce 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. The list that you are familiar with "alife-game@alnilam.krl.caltech.edu" will soon be removed, it will be replaced by the following lists. GENERAL - ag-general@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. Some people (directors especially) will get multiple copies of any general msg, therefore they are -strongly- discouraged. DIRECTORS - ag-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 - ag-PC-X@alnilam.krl.caltech.edu ag-MAC@alnilam.krl.caltech.edu ag-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 - ag-universe@alnilam.krl.caltech.edu This list will contain the addresses of the universe group. ALIFE - ag-alife@alnilam.krl.caltech.edu This list will contain the addresses of the Alife group. ART/SOUND - ag-art-sound@alnilam.krl.caltech.edu This list will contain the addresses of the Art and Sound group. ANNOUNCE - ag-announce@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 Ofria. The FTP Sites ------------- There are two sites that are used for transfering files, concerning the project. THE INFORMATION SITE - ftp.krl.caltech.edu pub/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 /uploads directory within the alife-game directory. The alife-game directory is managed by Charles Ofria. THE FILE SITE - 144.118.44.96 To log on to this site, you must have a password. These will be given to the sub-group members by the directors of each sub-group as needed. To log in, use the user name of 'member' and then input the password. There will be a number of directories, each sub-group has it's own directory on the File Site. This site devoted solely to the Alife-Game and thus it is where source code and other related files will be kept. 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. ------------------- - Universe Talk - ------------------- 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. The current consensus is for a SEMI-CONTINUOUS method. ----------------- - 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 mix 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 is assuming that there is no sex difference between aliens, both can lay and fertilize eggs. -- this is the current 'general consensus' right now... 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...) OTHER STUFF Martijn Faassen is beginning to assemble a FAQ for the group. Additions to this FAQ are to be made from sub-groups. It will be released soon-ish. Please, if you haven't already...JOIN A SUBGROUP!!! Instead of mailing the SUB-GROUP msg to me, mail it straight to : charles@krl.caltech.edu I'm going on vacation for a week, and Martijn Faassen will be handling the 'project director' spot while I'm away. Have a good'un. More later. -=GT=- From ???@??? Mon Nov 21 21:10: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 VAA23399 for ; Mon, 21 Nov 1994 21:04:58 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9kW7-000fIrC; Mon, 21 Nov 94 17:59 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA73817; Mon, 21 Nov 1994 17:58:54 -0800 Date: Mon, 21 Nov 1994 17:58:54 -0800 (PST) From: Gregory Glen Taylor Subject: PROJECT STRUCTURE 2, those in sub-groups may ignore... To: alife-game@alnilam.krl.caltech.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Project Structure - ver 2 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 : charles@krl.caltech.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. Mailing list names for each sub-group are listed in the file 'Current_Discussion.1' which will be available at the Information FTP site (ftp.krl.caltech.edu pub/alife-game/admin). ---------------- - 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 Assistant : Gert-Jan Roojen - g-t@ FE-Mac Director : Mike Mitchener - st944m5h@post.drexel.edu FE-Amiga Director: Turtle Dragon - 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 - ------------- SUB-GROUP activity has already begun, please sign up or be left --behind. That's it for now....-=GT=- Greg Taylor From ???@??? Mon Nov 21 22:07:07 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 VAA24792 for ; Mon, 21 Nov 1994 21:15:43 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9ko5-000fItC; Mon, 21 Nov 94 18: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 DAA00714 for ; Tue, 22 Nov 1994 03:16:21 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id DAA16447 for ag-directors@alnilam.krl.caltech.edu; Tue, 22 Nov 1994 03:16:19 +0100 From: Martijn Faassen Message-Id: <199411220216.DAA16447@laurel.stud.phil.ruu.nl> Subject: FAQ: Call for entries To: ag-directors@alnilam.krl.caltech.edu (AG Directors) Date: Tue, 22 Nov 1994 03:16:18 +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: 2690 FAQ - Call for Entries ---------------------- Directors, This week I'll be assembling the Development & Design FAQ of the game, which will hopefully have many entries in it. The FAQ will serve the following purposes: - As a guideline: what's in the FAQ, is generally 'accepted' to be the way we do it. (although of course we should keep things, if possible, as open to new developments as possible) - As an update: the FAQ can be read by anyone participating, and will keep them informed about what the other groups are doing. I'm thinking about bringing out a frequent 'FAQ-changes' post which will consist of any new FAQ entries, and entries which have changed. I'm planning several sections for the FAQ: - General - Universe - Alife - Art/Sound - General front end - Machine dependent front end - PCX - MAC - AMIGA - etc. Important --------- So, directors, please ask your groups for entries, and feel free of course to come up with entries yourself too! How you exactly get them doesn't matter, as long as they're sent to me. (faassen@phil.ruu.nl) (I suggest you discuss proposed entries with your group and possibly the other directors first before sending them to me) To make life easier for me, please make the subject of any FAQ entries mail to me: FAQ ENTRIES: Each group director has the final word for his group, so determines which entries in what form will make it into the FAQ. The final final word will be reserved for Greg (and while he's not available this week; me). He'll do the final consistency and feasability check, but don't let this be a reason not to think about this yourself! A seperate text is also needed (who will maintain this?): The Function Description List. This list will contain all the functions which are accessible from the outside. So, internal universe fuctions, internal front end functions, internal alife functions, etc, won't be listed, unless they can be used somehow from the outside by another module. The list will consist of the following categories: - Universe function descriptions - Alife function descriptions - Art/Sound descriptions - Front end function descriptions (machine dependent front end functions have no place here, they would never be called by the Universe anyway) This list shouldn't stop any particular director from keeping a list of his own, for his subgroup. This list would then *include* the functions which aren't used by outside modules. I hope to hear from everybody soon! Martijn -- Martijn Faassen email:faassen@phil.ruu.nl -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Mon Nov 21 23:47: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 XAA11939 for ; Mon, 21 Nov 1994 23:31:07 -0500 Received: from atlantis.actrix.gen.nz by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9mk0-000fIrC; Mon, 21 Nov 94 20:22 PST Received: from papaioea.manawatu.planet.co.nz ([202.36.148.65]) by atlantis.actrix.gen.nz (8.6.5/8.6.5) with ESMTP id RAA27680 for ; Tue, 22 Nov 1994 17:19:51 +1300 Received: (from uucp@localhost) by papaioea.manawatu.planet.co.nz (8.6.9/8.6.9) with UUCP id QAA07473 for alife-game@alnilam.krl.caltech.edu; Tue, 22 Nov 1994 16:19:37 +1300 Received: by gorgo.manawatu.planet.co.nz (1.65/waf) via UUCP; Tue, 22 Nov 94 16:12:40 +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: Space vs. Ground Date: Tue, 22 Nov 1994 16:09:00 +1200 Message-Id: <112294160924Rnf0.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 Gregory Glen Taylor writes: >I see doing a ground backdrop as posing a bit of a problem. If we choose >a space-backdrop we can do a star-scrolly (various levels of stars), >which will produce a nice-looking output, but it will be faster and more >memory conscious, than a bitmap for the ground. I don't see the problem... it would take something like 10 scanlines of time (irrelevant) and look a lot better than stars surely??? Then again! There are definate speed increases... don't have to deal with wrapping the scrolling background etc.. I just think it would look nicer above a surface, the "Eggs" would fit in nicely over some kind of organic ground and... how much life exists in space??? On a planet it seems more suitable. *-- --* C Warner, belial@gorgo.manawatu.planet.co.nz, Razor Software (NZ) *-- --* From ???@??? Mon Nov 21 23:57:23 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 XAA13967 for ; Mon, 21 Nov 1994 23:50:57 -0500 Received: from violin.aix.calpoly.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9nEg-000fIsC; Mon, 21 Nov 94 20:53 PST Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA80473; Mon, 21 Nov 1994 20:53:05 -0800 Date: Mon, 21 Nov 1994 20:53:04 -0800 (PST) From: Gregory Glen Taylor Subject: Stuff!!! To: ag-directors@alnilam.krl.caltech.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = Isn't it funny how much more important a title looks with a neat border? - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vacations & Food ---------------- I'm going home for the week for a wonderful holiday that us American's have called Thanksgiving. I hope those of you guys of other nationalities have a similar holiday...nothing beats it. We all get together and eat as much as we possibly can, then lay around and moan while watching American Football games. But I digress. During my absence, Martijn Faassen will be handling all of the Project Coordinator mumbo-jumbo. Directing direction ------------------- Ok. I've heard indirectly that the mailing lists are up (correct me if I'm wrong, Charles). You you may begin organizing your sub-groups. How you organize your groups is up to you...you are in control. I'll be handling complaints, so don't go too power crazy. The directors group is where we'll handle compatibility issues, and I am the director there ;). But as you've seen I'm not a dictator by anyone's standards. Within the week I'd like all of the directors to write up a file where they describe the sub-group, it's goals/aims, what topics need to be discussed right away, your plan of attack (what -order- you want the code sections to be completed in), and the general structure of the group (what positions will be needed, etc.). This will surve as a welcome msg to all of your group members, as well as an outline of what you plan on doing with the group. When you've sent it out, post it on the Information FTP Site for future members to look up. Then just go for it. The first week (this week) of discussions should be mostly conceptual, getting the idea of the project fleshed out, and then adding them to the FAQ (which Martijn has volunteered to assemble :). Then the next week I hope to administer the formation of the Universe.h (or perhaps change the name to ag-game.h or something...). This will consist of the directors assembling a list of functions that their groups need/will write, that are global. We will also need to come up with the variable type structures for our major global variables (object stats, other things). So you might begin assembling ideas for the global defines etc. Once we get the global stuff and function declarations down, we can actually begin coding! For now, just begin discussion in your groups and begin assembling ideas for the header file. That's all I can think of for now --------------------------------- Well it's up to you guys for now, get your groups organized (and if you're directing a group of two people, this will be an easy task), and get movin' on the project. I'll be back next week. Have fun...-=GT=- The Mailing Lists ----------------- These may be missing a few addresses that Charles has added, but they should give you an idea of how the groups are laid out thus far.... all groups are laid out like this... @alnilam.krl.caltech.edu GENERAL : ag-general ag-universe@... ag-alife@... (ag-art-sound@... If we ever get people on art/sound only, for now, those who are in the group are in others as well). ag-PCX@... ag-MAC@... (ag-AMIGA@... If we ever get people on that group only, for now...they're on other lists as well...) DIRECTORS : ag-directors gtaylor@oboe.aix.calpoly.edu Martijn.Faassen@phil.ruu.nl charles@krl.caltech.edu st944m5h@post.drexel.edu uwingcat@mcl.mcl.ucsb.edu g-j@chameleon.alt.za jmlait@undergrad.math.uwaterloo.ca belial@gorgo.manawatu.planet.co.nz UNIVERSE : ag-universe uwingcat@mcl.mcl.ucsb.edu Martijn.Faassen@phil.ruu.nl charles@krl.caltech.edu B.Barnes@dcs.warwick.ac.uk mbbad@seqnet.dl.ac.uk ALIFE : ag-alife Martijn.Faassen@phil.ruu.nl charles@krl.caltech.edu B.Barnes@dcs.warwick.ac.uk st944m5h@post.drexel.edu gollum@spider.two-oo-one.fr mbbad@seqnet.dl.ac.uk hernande@cauchy.sosc.osshe.edu simon.raik@sd.monash.edu.au christian@darkin.demon.co.uk rg@risc.upol.cz chance@wetware.sps.mot.com ART/SOUND : ag-art-sound jmlait@undergrad.math.uwaterloo.ca gtaylor@oboe.aix.calpoly.edu christian@darkin.demon.co.uk FE-PC/X : ag-PCX jmlait@undergrad.math.uwaterloo.ca g-j@chameleon.alt.za gtaylor@oboe.aix.calpoly.edu hernande@cauchy.sosc.osshe.edu cs323093@mailbox.uq.oz.au belial@gorgo.manawatu.planet.co.nz relsner@k12.colostate.edu FE-MAC : ag-MAC st944m5h@post.drexel.edu chance@wetware.sps.mot.com FE-AMIGA : ag-AMIGA belial@gorgo.manawatu.planet.co.nz ANNOUNCE : ag-announce a.fraser@eee.salford.ac.uk adamsch1@student.msu.edu brett@iit.com chris@aql.gatech.edu djt@rpiv.mc.duke.edu don@robots.ox.ac.uk ematteso@icogsci1.ucsd.edu haralkar@plusplus.is jmerelo@kal-el.ugr.es kim@cs.city.ac.uk vonjoshi@ocf.berkeley.edu wsteele@efn.org From ???@??? Tue Nov 22 07:46:07 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 HAA13031 for ; Tue, 22 Nov 1994 07:40:55 -0500 Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9uUu-000fIrC; Tue, 22 Nov 94 04:39 PST Received: from s-crim1 by mserv1.dl.ac.uk with SMTP id MAA02824 (8.6.9/5.3[ref pg@dl.ac.uk] for dl.ac.uk from mbbad@dl.ac.uk); Tue, 22 Nov 1994 12:36:10 GMT Precedence: first-class Received: by s-crim1 (931110.SGI/930817.MJE) for alife-game@alnilam.krl.caltech.edu id AA23292; Tue, 22 Nov 94 12:35:53 GMT Date: Tue, 22 Nov 94 12:35:53 GMT From: mbbad@s-crim1.dl.ac.uk Message-Id: <9411221235.AA23292@s-crim1> To: alife-game@alnilam.krl.caltech.edu Subject: Lists ? Just a general query (and something that no-bodies mentioned). Now I'm on the mailing list for a sub-group, should I remove myself from this general one ? Or is this one expected to slowly wind-down anyway ? Badders From ???@??? Tue Nov 22 10:51: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 JAA24951 for ; Tue, 22 Nov 1994 09:38:51 -0500 Received: from yuma.ACNS.ColoState.EDU by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9wLZ-000fIrC; Tue, 22 Nov 94 06:37 PST Received: from K12.ColoState.EDU by yuma.ACNS.ColoState.EDU (AIX 3.2/UCB 5.64/4.03) id AA35551; Tue, 22 Nov 1994 07:35:37 -0700 Received: by k12 (4.1/SMI-4.1) id AA20397; Tue, 22 Nov 94 07:41:10 MST Date: Tue, 22 Nov 1994 07:41:06 -0700 (MST) From: Robert Elsner X-Sender: relsner@k12 To: Turtle Dragon Cc: alife-game@alnilam.krl.caltech.edu Subject: Re: Space vs. Ground In-Reply-To: <112294160924Rnf0.78@gorgo.manawatu.planet.co.nz> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Well, forgive me if I am outta it, butK12 was down most of last week Anyway, I jumped to the last messages, and I don't think I am to outta it. I do have an idea after reading some info on what you were talking about recently: What if The first part is set in space, and the player has to beat some mongo-bosses to get to the actual planet, so he can destroy the center control portion of the aliens, thusly allowing him to start hackin off the heads of others? If player beats 4 bosses, he goes to the planet, which has even more aliens to defeat, and 4 more bosses. But he has to give some of the strongest alies a chance to live, otherwise he can't get bosses. Maybe if he kills all of the strongest aliens first, a message popsup on the screen saying: Game forefeited!!! You Lose!!! And the player could just keep wandering around, but not actually getting anywhere. Well, I hope I dont sound to stupid or outta it, but just an idea. And i am not sniggering! 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 ???@??? Tue Nov 22 13:33:44 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 LAA14265 for ; Tue, 22 Nov 1994 11:31:38 -0500 Received: from fred.cs.city.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9y5J-000fIrC; Tue, 22 Nov 94 08:28 PST Received: from merrydown.cs.city.ac.uk by fred.cs.city.ac.uk with smtp (Smail3.1.28.1 #14) id m0r9y3D-00064DC; Tue, 22 Nov 94 16:26 GMT Date: Tue, 22 Nov 1994 16:26:35 +0000 (GMT) From: HARRIES K A To: alife-game@alnilam.krl.caltech.edu Subject: Eggs etc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree with Chance that the laying eggs and then fertilising them is gonna make things more difficult for them poor aliens to develop. I do think this should be a long term aim (especially after reading everyones fascinating ideas concerning them :) but I think we should definately start off making evolution as easy as possible for the poor critters and see whether we get anywhere. Whilst open-ended evolution is the most powerful in the sense of being able to produce the most novel and surprising affects it is certainly very weak in terms of the time it takes for it to produce efficient solutions. Thus we may even wish to start with the much-loathed fitness function of some kind, since this allows more control of the creatures development, quicker development, and an easier analysis of the behaviour that does arise. While I'm here I noticed my gene-stealing idea did not go down well (where it was noticed :), but seems to have been missunderstood so I'll give it one more plug before dropping it. The point of the gene-stealer idea was mainly to provide another helping hand to the aliens. The players behaviour (his phenotype) is, of course, directly controlled by himself not determined by his genetic code. The idea was to have a reversal of the process which turns an aliens genetic code into their behaviour used to infer the _players_ genetic code from his behaviour (this is very tricky, but need not necessarily be totally accurate). This genetic material can then potentially be stolen by aliens when they kill/devour/copulate with etc. the player, thus incorporating some of the players (presumably clever) behaviour patterns into their genetic code. This is the kind of 'cheat' that I think could be productive in the game by allowing the opposition to (a) make great leaps of progress that might otherwise be impossible (in the available time) and (b) copy the players cunning tactics. Even if the players genetic code only captures very rough/general features of his behaviour it could still be of great use in producing novel alien behaviour. Of course the player might try to manipulate this to his advantage by e.g. spending all his time shooting eggs and then getting himself eaten, but this would be of dubious benefit since under crossover the behaviour might be transformed to e.g. spending all your time shooting or some such. Oh well, seeing as I've got nothing left but a handle on my axe now I'll move on to something else: Concerning the issue of whether the player is human or alien and thus how they develop their weaponry etc. here is another (not necessarily brilliant :) alternative: The player is human and is provided with initially random combinations of weapons, armour, engine etc. by the military research team back home on earth. Periodically (between waves, when he reaches the next communications pod, whatever) he has to send reports home on the effectiveness of each piece of equipment. This 'fitness rating' for the equipment is then used by the research team (in a genetic algorithm type way of course :) to determine the next set of equipment to send on up to him. This keeps with the evolving equipment theme without the business of being an alien (to which some people seem to object). It also means the player must choose well when assessing his equipment otherwise he'll get a load of junk next time, and gives him *some* but not total control of what he gets. I must admit however that I do quite like the idea of being an alien, but that may just be a personal thing :) Chin-chin, Kim. ------------------------------------------------------------------------------- Kim A. Harries | "Keep in a cool place, out of reach of Computer Science Department | children" City University | - Medical Advice Northampton Square | London EC1V 0HB | ------------------------------------------------------------------------------- From ???@??? Tue Nov 22 13:33: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 MAA21455 for ; Tue, 22 Nov 1994 12:08:32 -0500 Received: from undergrad.math.uwaterloo.ca by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9ycj-000fIrC; Tue, 22 Nov 94 09:03 PST Received: from cayley.uwaterloo.ca by undergrad.math.uwaterloo.ca id <56946-3>; Tue, 22 Nov 1994 11:58:54 -0500 Date: Tue, 22 Nov 1994 11:58:45 -0500 From: Jeff Lait Subject: Re: Space vs. Ground To: Turtle Dragon cc: alife-game@alnilam.krl.caltech.edu In-Reply-To: <112294160924Rnf0.78@gorgo.manawatu.planet.co.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 21 Nov 1994, Turtle Dragon wrote: > Gregory Glen Taylor writes: > > >I see doing a ground backdrop as posing a bit of a problem. If we choose > >a space-backdrop we can do a star-scrolly (various levels of stars), > >which will produce a nice-looking output, but it will be faster and more > >memory conscious, than a bitmap for the ground. > > I don't see the problem... it would take something like 10 scanlines of > time (irrelevant) and look a lot better than stars surely??? Er... In 640x480x24bit it takes considerably more than ten scanlines - 6 retraces if you are lucky... > Then again! There are definate speed increases... don't have to deal with > wrapping the scrolling background etc.. Yes, also as far as memory is concerned, we are dealing with a rather large playfield (That's another thing that needs to be determined precisely...) We'd have to have a lot of repetition, not necessarily in the tiles, but in the map itself. Oh well, what I consider best about this is it's applicability to high res. where scrolling backrounds are not too feasible on the IBM... > I just think it would look nicer above a surface, the "Eggs" would fit in > nicely over some kind of organic ground and... how much life exists in > space??? On a planet it seems more suitable. I really couldn't comment on that as we don't even know if life exists of this planet. For all we know, space may be the most common place for life to develop, with gravity well dependent life being an anomaly :> But anyways, both are equally valid ... perhaps we could try both and see which plays better? Just that I've preferred space oriented games to the ground based ones of this genre... - Jeff Lait (SOL) From ???@??? Tue Nov 22 13:33:47 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 NAA03546 for ; Tue, 22 Nov 1994 13:23:24 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0r9zu7-000fIrC; Tue, 22 Nov 94 10:25 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA17922; Tue, 22 Nov 1994 10:23:35 -0800 From: Charles Ofria Message-Id: <9411221823.AA17922@altair.krl.caltech.edu> Subject: Re: Creature control structures... To: ag-alife@alnilam.krl.caltech.edu Date: Tue, 22 Nov 1994 10:23:34 -0800 (PST) In-Reply-To: <199411220007.BAA14178@laurel.stud.phil.ruu.nl> from "Martijn Faassen" at Nov 22, 94 01:07:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 10817 -- From: Martijn Faassen > Why do only similar segments get recombined? Ah..yes..I think I understand.. > then..how to determine similarity? Fancy you should ask that question.... A project which I spent a few weeks on just last summer :-). Basically its quite similar to Hamming distance, but takes into account that instructions can be inserted and removed without radically changing things. I'll send a seperate letter explaining these. Speaking of all these explainations, I think I'm going to create an alife directory at the ftp site where I'll keep everyones explanitory posts. I should probably also try to figure out how to archive all the groups, huh? > I'm not sure if such a treshhold is strictly necessary. Might be confusing.. > I wonder if it would be possible to evolve this easily from a set of > priority increase/decrease instructions (which can increase or decrease > the priority value of any module), and a 'jump to highest priority' > instruction.. The thresholds would simply work on the same basis as interupts. They should be set high enough so that they rarely happen. The reason I don't want increase/decrease instructions is because that means the creature will have to keep checking whats going on and responding to it. I want it to be able to get the info immediately. Besides, in general, actions would only be based on the senses anyway, so why do we need something more complex? I do want to put a pair of registers in that the creature can control to tune the sesitivity. > > The priority function would simply be the weighted sum of all the > > sesory inputs plus (perhaps) a couple of special registers so that > > the creature can manipulte the function sesativities while running. > Why not let this be determined by the creature entirely by itself? See > later when I describe my scheme. That would be ideal, but with only an inc and a dec command, it would have to go crazy (and waste far to much CPU time) to get it to look like what it wants. > If we can get somekind of simple, flexible basis for this scheme, I > agree we should go for it. (see my brainstorming session coming up > below again) Good. > > Method 4: Object-Oriented assembly based creatures. > Yes, I'd like to hear more about this. *sigh* okay - I'll put something togeather. > *laugh*..such a scheme isn't necessarily much slower than any other > scheme we might devise..if we do it smartly. :) The way I was picturing it working it would. See responce to next part. > We'd need (simple) interpreters anyway, for the instructions, don't we? Of course we do, but we don't have a number of objects in memory for each creature at once, all of which may be constantly interacting. Although now that you have me thinking about it more, I might actually come up with something worth thinking about... > > Method 6: Assembly based creature with access to a network. > Such a hybrid would be very interesting, if we manage to come up > with an elegant mix. Definately - thats where all the fun lies! > > Comments: I want to do this one eventually regardless... I just don't think > > its a good ideas to start with. > > Agreed again! Great! > Okay, here's my idea, based on segmented/priority assembly code. (option > 3 if I recall it well :) > > An alien mind is: > > - Controlled by modules (genes). Agreed. > A module is: > > - Assembly code instructions. Plus at least certain flags... > The assembly code instructions can: > - access directions, distances, energy levels, etc, etc, of > itself and other objects. (accessing variables) > - FIRE, LEFT, RIGHT, THRUST, and things like BREED, EAT, and WEAPON (to > switch weapon). > - access priorities of any module in the mind. > - increase/decrease any priorities of any module of the mind. > - jump to module with highest priority. Some of these its going to be quite dificult to do slickly! But I'm sure we'll come up with something (we have to...) > Possibly (see below) > - access, and increase/decrease any treshold of any module of the mind. > > Modules can possibly have > > - thresholds, if priority rises above this treshold, the instruction > pointer jumps there automatically. > > Idea: > > Each creature has not one, but *two* (or possibly more?) instruction > pointers. One constantly moves to the module which has the highest > priority. It's can get interrupted. > The other one simply follows a module and only jumps when a > jump instruction occurs, i.e jump to highest priority. This sounds interesting; I'm just concerned about keeping a careful track of priorities which I think the creature might have trouble with if left completely on its own. I do see your point, and its very valid - we'd be "interfering" with the creature a bit too much by setting up this priority system for it - it should be able to come up with any kind it wants. I keep getting sucked into the trap of thinking "this is a game" rather then my normal mode of thinking which is "this is an experiment - how can we keep everything as pure as possible?" Your idea certainly keeps this aspect true (and if we want to keep this project valid in the sceintific community, we have to show that we influenced their development as minimally as possible.) However, I still have reservations about its upward potential. > This might enable creatures looking somewhat like this: > (note: no treshold included here, that's what the interrupt pointer > is effectively doing..I hope) > > Module: perception > Module: action: point and fire > Module: action: flee > Module: action: fertilize > > This is just one of the possible creature structures that we (and > hopefully evolution) might come up with. We. There is no way evolution would ever come up with something that looks so clean. [munch on excellent explaination of what could happen] > Maybe we should include flags too, like 'this module can interrupt' > and 'this module can't interrupt, no matter what it's priority is', > which can be turned on and off. (a 'can't be interrupted' flag is > interesting too) I like the idea of flags, but in my current abstracting frame of mind, perhaps we could just put flags on modules and let the creatures figure out what to do with them. > I hope this story makes some sense to anybody, if not, I'll work on > explaining it some more, just let me know. :) Makes good sense to me... > There's still a big question about how to recombine these genes? Hehehehe.... I'm getting a number of ideas on this. In general, remember, we want to only re-combine genes which are very similar, or else the creature will inevitably break. Here are 3 ideas: 1) We assume that all creatures will have similar genes in the same order (and by assuming this, we make it likely!) We simply pair up the genes in order such that the distances between pairs are minimized (this might mean skipping a gene here or there.) For example, we might have two creatures ABCDEFG and abcqdef, where A is similar (or the same as) a, etc. We would pair these up as: ABC DEFG abcqdef since that provides the maximum matches with the minimum differences. we then check to see if any of the pairs recombine. If they do, we simply take the begining of one gene and the end of the other, and place it in the offspring. If we don't, then we take it randomly from one creature or the other. Note that since both q and G are paired with a blank, they have a 50% chance each of being in the child. Thus the child of this mix might look like: aBCde*G where * is the recombination of F and f. Again, for this scheme, the degree of matching between genes should determine the "mate-ability" between creatures. If they are two different then there is a good chance the child won't function. (heck, if there are no reasonable gene matches, then the child could end up with no genes!) If we don't want lots of still births, we should have creatures mating chance be based off of this difference (probably using the function C^-D where C is a low constant (close to one) and D is the number of differences. Assume C is 1.1. If we had 0 differences, then the creatures would automatically be able to mate. If there is 1 difference, then there would be a 1/1.1 chance to mate (~91%). 2) Gee... I'm already forgetting the other options... Ah yes. This one I think is the most open, and the one which idealy we should use... I'm just wondering on practicalities... Anyway, when a creature lays and egg, it copies some code into the egg to be run, as well as leaving behind its own genes. The egg than waits to be fertailized during which time the "hatch" command (or somesuch) will not work. Once it gets the other parents genes, it gets energy donated proportional to how much of the gene it uses! It'll have to decide if and how to recombine or whatnot. We can design the seed creatures however we like... if it works better than what they can come up with immidiately, it'll stick. 3) We can study more how nature does it... have effectively two copies of each gene. I'm not sure how the number of genes could change in nature. > That is, if each gene has a number to designate it (and they have to > be designated, because otherwise the priority changing and jump > instructions wouldn't have any handle on them) and you just jumble > all genes together you get modules calling for modules with numbers > which aren't available, and modules with numbers that aren't called > at all, etc. > > So, I imagine each module still has a number, but that calls work > stochastically: the module with the number most similar to the call > number will have a higher chance of getting called than the modules > with numbers more different from the call number. I'd like to try and find a cleaner way of doing this than with numbers, but I don't have any better ideas yet myself. > In this scheme, all modules have chance to get called, and usually, > but not always, the best fits will be called. > > Evolution might then for example work out that all modules with > numbers around 100 involve 'fire actions' of some kind, and all > modules around 23 involve 'flee actions'..It can also place more similar > action types close together..It might perhaps be profitable to place > the 'attack module' around 50, and the 'flee module' around 55..So, > sometimes the creature would attack instead of flee, or flee instead of > attacking. This works out reasonably - I think we'll stick with it. > Anyway, this is all getting very complex, there's some unifying principle > in my ideas somewhere though..I hope.. Hehe. It's always most beautiful when everything falls togeather in the end. Let us hope... --- Charles From ???@??? Sun Nov 27 10:31: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 NAA05192 for ; Tue, 22 Nov 1994 13:35:01 -0500 Received: from dunx1.ocs.drexel.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rA05z-000fIrC; Tue, 22 Nov 94 10:37 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 NAA05033 for ; Tue, 22 Nov 1994 13:34:04 -0500 X-Sender: st944m5h@dunx1.ocs.drexel.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Nov 1994 13:38:32 -0500 To: ag-directors@alnilam.krl.caltech.edu From: st944m5h@dunx1.ocs.drexel.edu (Michael Mitchener) Subject: Going away For some reason, Drexel has decided that they will shut down our system for three days during this vacation. :( Any mail sent to me will fail, just so you know...If someone is keeping a backlog of all this mail, I would appreciate greatly if they would send me the mail that is distributed on Thursday-Saturday of this week, as that would be the only way I could get it. Thanks and Happy Thanksgiving, Michael Mitchener st944m5h@post.drexel.edu From ???@??? Sun Nov 27 10:31:58 1994 Received: from violin.aix.calpoly.edu (gtaylor@violin.aix.calpoly.edu [129.65.63.7]) by dunx1.ocs.drexel.edu (8.6.9/8.6.4) with SMTP id NAA07105 for ; Tue, 22 Nov 1994 13:47:52 -0500 Received: by violin.aix.calpoly.edu (AIX 3.2/UCB 5.64/4.03) id AA76752; Tue, 22 Nov 1994 10:50:29 -0800 Date: Tue, 22 Nov 1994 10:50:29 -0800 (PST) From: Gregory Glen Taylor Subject: Re: Going away To: Michael Mitchener In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'll send you all of the msgs I get concerning the prj. But I can't say much for the sub-group msgs. Perhaps you ought to ask the directors of your groups (aside from Mac of course) to keep track of the msgs. I'll forward what I get though. -=GT=- From ???@??? Sun Nov 27 10:31:58 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 NAA07352 for ; Tue, 22 Nov 1994 13:49:31 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rA0GX-000fIrC; Tue, 22 Nov 94 10:48 PST Received: by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA18134; Tue, 22 Nov 1994 10:46:45 -0800 From: Charles Ofria Message-Id: <9411221846.AA18134@altair.krl.caltech.edu> Subject: Re: Going away To: alife-game@alnilam.krl.caltech.edu Date: Tue, 22 Nov 1994 10:46:44 -0800 (PST) In-Reply-To: from "Michael Mitchener" at Nov 22, 94 01:38:32 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 122 No promises, but I'm going to try to set up an archive at the ftp site... It should be up by tomorrow. --- Charles From ???@??? Sun Nov 27 10:31: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 TAA23531 for ; Tue, 22 Nov 1994 19:36:33 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rA5ht-000fIrC; Tue, 22 Nov 94 16:37 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 BAA25054 for ; Wed, 23 Nov 1994 01:35:17 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id BAA07035 for ag-alife@alnilam.krl.caltech.edu; Wed, 23 Nov 1994 01:35:14 +0100 From: Martijn Faassen Message-Id: <199411230035.BAA07035@laurel.stud.phil.ruu.nl> Subject: Re: Eggs etc. To: ag-alife@alnilam.krl.caltech.edu (ag alife) Date: Wed, 23 Nov 1994 01:35:13 +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: 8077 > > I agree with Chance that the laying eggs and then fertilising them is > gonna make things more difficult for them poor aliens to develop. I do > think this should be a long term aim (especially after reading everyones > fascinating ideas concerning them :) but I think we should definately > start off making evolution as easy as possible for the poor critters and > see whether we get anywhere. I think we should move into the direction of eggs, but, we might use *anything* from fitness functions to handcoding the aliens to seed the population from the start (and perhaps also during the game). Just whatever will make the game more enjoyable. > Whilst open-ended evolution is the most powerful in the sense of being > able to produce the most novel and surprising affects it is certainly > very weak in terms of the time it takes for it to produce efficient > solutions. Thus we may even wish to start with the much-loathed fitness > function of some kind, since this allows more control of the creatures > development, quicker development, and an easier analysis of the behaviour > that does arise. We'll be pragmatic about this, we'll just use anything that works, and we should keep the system open enough to allow both for open endedness and fitness functions alike. But: - if there's two approaches that both work about as well (using some criteria we'll need to develop..or maybe just 'playability') We'll include the most elegant, open ended, least hacky solution in the final version, and not the other one. :) If, however, it turns out that our elegant open ended stuff sounds nice, but doesn't do anything as well as for example a fitness function, we'll go for fitness function. Besides, I don't see why we can't have (after we get some alien behaviour code representation ready) two teams, one going for open ended evolution, the other going for fitness functions, if there is such a need. > While I'm here I noticed my gene-stealing idea did not go down well > (where it was noticed :), but seems to have been missunderstood so I'll > give it one more plug before dropping it. > > The point of the gene-stealer idea was mainly to provide another helping > hand to the aliens. The players behaviour (his phenotype) is, of course, > directly controlled by himself not determined by his genetic code. The > idea was to have a reversal of the process which turns an aliens genetic > code into their behaviour used to infer the _players_ genetic code from > his behaviour (this is very tricky, but need not necessarily be totally > accurate). If you can devise a plausible idea on how to translate human behaviour reasonably accurately into assembly code (or whatever control structure we'll be using for the aliens), this would be great.. But I'm currently rather clueless on how to do this..I'll have to think about this. I don't think this should be a primary goal for the alife group though, let's first get the basics running, though that shouldn't keep anyone from thinking about this, and keeping this in the back of their minds. > This genetic material can then potentially be stolen by aliens > when they kill/devour/copulate with etc. the player, thus incorporating > some of the players (presumably clever) behaviour patterns into their > genetic code. This is the kind of 'cheat' that I think could be > productive in the game by allowing the opposition to (a) make great leaps > of progress that might otherwise be impossible (in the available time) > and (b) copy the players cunning tactics. If, again, we can actually devise a way to represent human behaviour in the alien control structure. > Even if the players genetic code only captures very rough/general > features of his behaviour it could still be of great use in producing > novel alien behaviour. Of course the player might try to manipulate this > to his advantage by e.g. spending all his time shooting eggs and then > getting himself eaten, but this would be of dubious benefit since under > crossover the behaviour might be transformed to e.g. spending all your > time shooting or some such. > Oh well, seeing as I've got nothing left but a handle on my axe now I'll > move on to something else: > > Concerning the issue of whether the player is human or alien and thus how > they develop their weaponry etc. here is another (not necessarily > brilliant :) alternative: > > The player is human and is provided with initially random combinations of > weapons, armour, engine etc. by the military research team back home on > earth. Periodically (between waves, when he reaches the next > communications pod, whatever) he has to send reports home on the > effectiveness of each piece of equipment. This 'fitness rating' for the > equipment is then used by the research team (in a genetic algorithm type > way of course :) to determine the next set of equipment to send on up to him. > > This keeps with the evolving equipment theme without the business of > being an alien (to which some people seem to object). It also means the > player must choose well when assessing his equipment otherwise he'll get > a load of junk next time, and gives him *some* but not total control of > what he gets. > > I must admit however that I do quite like the idea of being an alien, but > that may just be a personal thing :) Currently my research idea goes someone like this: The first few 'lives' of the player will simply be basic 'military equipment', human made. Of course the evolved equipment is *much* better (note: we'll probably design most of the 'evolved' equipment ourselves for a large part, so that's why it's so much better). The attacking 'berserker' style robotic ships therefore outclass the human ship in the beginning. But, the human player has a 'research vessel' or a home base of a kind, with a research team in it. If the human player can capture alien artifacts (for instance, eggs, or dead ships), the science team might be able to distill new weapons, shields, scanners, etc from them. (for example an energy scanner, or whatever). Later, the science team discovers how to make an egg 'hatch' (actually this is simply taking over the 'robotic machinery' in the egg, or whatever), and this gives the player a certain chance to obtain new lives with new configurations. Of course the 'egg stealing' might go wrong, but the science team works hard to perfect the way they steal eggs. Eventually the science team also discovers how to 'fertilize' (actually just somekind of information transfer between egg and robotic ship) eggs themselves, so how to mate the players ship's config with the config in the egg. This way the player can direct the configuration of his new ship even more. And so on. :) This research scheme needs some thinking, but I'm not sure if this should be part of the alife group. Actually, woudln't it be better to put the entire configuration issue (as opposed to the behaviour issue) to the Universe group? That is, the Universe group determines exactly which weapons are possible, how ship configuration works (i.e. something like my 'money' scheme..investing percentages of your total money in different categories), etc. Then, they come to us (or communicate with us while designing it) for two things: - projectiles that are controlled by an evolving code. (simplication of the alien control code). - how to 'breed' configurations, i.e., what will happen if I have configuration 1 and configuration 2, and they mate. Mutations, cross over, etc. This will probably be a very simple system, compared to the behaviour code. Then again..we might instead couple certain parts of the configuration to the different genetic modules..for example, a module dealing mostly with thrust behaviour also has some 'thruster configuration' stuff in it.. this is however a vague idea..If anyone wants to think about this? > Chin-chin, > > Kim. > Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Nov 27 10:32:01 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 UAA29149 for ; Tue, 22 Nov 1994 20:29:23 -0500 Received: from groucho.phil.ruu.nl by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rA6YB-000fIrC; Tue, 22 Nov 94 17:31 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 CAA26113 for ; Wed, 23 Nov 1994 02:29:19 +0100 Received: (from faassen@localhost) by laurel.stud.phil.ruu.nl (8.6.8.1/8.6.6) id CAA07820 for ag-alife@alnilam.krl.caltech.edu; Wed, 23 Nov 1994 02:29:13 +0100 From: Martijn Faassen Message-Id: <199411230129.CAA07820@laurel.stud.phil.ruu.nl> Subject: Relatedness & breeding To: ag-alife@alnilam.krl.caltech.edu (ag alife) Date: Wed, 23 Nov 1994 02:29:12 +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: 5920 Hi everybody, A problem we came up with: How to prevent still-births? That is, if we allow each alien to breed with each other alien, and we have diverging aliens, we have problems combining each gene module to the right other gene module, and deciding if we let two aliens breed at all. If we would let two rather different aliens breed, and we apply cross over, the chance is very high the resulting cross overed code is not very functional. To put it lightly. :) Now, here are my ideas/brainstorm on these and related problems: - Each gene module in all aliens has a number. (I'll talk about numbers for now, they might be coordinates too, or something else altogether, numbers are just easy to think about) - these numbers can mutate slowly, so, if a gene module had number 55 first, it might mutate into 56 in some eggs. (perhaps this mutation will only occur when gene doubling takes place - see below) - The numbers are used by special instructions in the assembly code in the gene modules. For example, there are instructions which do something like this: increase priority of number 55..or..jump to number 12. So, the numbers are basically 'handles' on the gene modules. The number calling however works stochastically, there's a chance that when you call 55 you actually call 54 (if that gene is there). Also if you call 55 and there isn't any gene 55, it'll automatically be the highest chance that 54 is called. This all to make it easier to mix genes together and have the resulting alien actually doing something. Breeding two aliens together works as follows: In both aliens all genes will be 'paired'. This is based on the numbers on their genes. For example, alien A has gene 12, gene 55, gene 11, gene 53, gene 17, and gene 19. It would pair like this: 12 - 11 55 - 53 17 - 19 Then, it would split the genes into two packets (meiosis): 12, 55, 17 and 11, 53, 19. (which half of the pair gets into which packet is randomly determined) Then, assuming alien B has done the same, one packet of alien A will be merged with one packet in alien B, and the resulting alien might look like this: 12, 55, 17 (all from alien A), and 14, 60, 15 (all from alien B). Doing it like this has some advantages: - it's easy for an egg to 'reject' fertilisation, if the gene numbers of the fertilizing packet are too different from the gene numbers in the packet already in the egg. If two packets come from different aliens, the chances are quite high that the numbers just don't compare well enough. - gene duplication is possible: sometimes a gene might accidentally be twice in a packet, maybe one of them is slightly mutated. The egg might still accept this packet, and the resulting alien will have an odd amount of genes. If its amount of genes was 7, it would be able to create both 3 size and 4 size packets. So, the number of genes in a creature might increase. Those extra genes would also be pretty guaranteed to be used, because they have the exact same number as the gene they 'compete' with, at least initially. (or not, if we let numbers mutate..) - accidental gene removal is also possible: sometimes a packet lacks a gene. This would also result in an alien with an odd amount of genes, so aliens with a smaller amount of genes might evolve. Note that the first generation would still work, since it has (probably) a gene similar to the lacking gene, from the other parent. - 'relatedness' might be determined more easily. Simply compare the gene module numbers of yourself with those of the alien you are examining (or the egg you're examining, determining if you should fertilize it or not). Perhaps we should devise a way to somehow put those gene numbers in a formula to come up with a resulting 'relatedness number', so it'll cost less time to compare. Also note that appearance of the aliens might be based on these gene numbers in some way. - even if a gene was completely ruined by a mutation, there would always be a 'backup gene' in the other parent's packet that might do the work. So, corrupt genes are less devastating. (and sometimes might do something completely novel, if we give them some slack this way first) Can we expect equal gene numbers (let's say, 54 and 55) to have code that does the same thing, though? (and therefore would be recombinable etc) I'm not sure, but I would expect that if we use this scheme, the chances are that they would.. This is just a vague intuition however, if someone can back me up on this? I'll have to think about this some more. :) Of course then there's always the option to actually distill the gene number from the actual code, so then 54 and 55 would have probably similar code. What if 2 (or more) genes in the alien have the same number? We might do several things (perhaps these should be flags in the genes): - make a dominant/recessive flag, or number. (almost) always call the most dominant gene. - just randomly determine which gene to pick at each call. In effect the phenotypic effect would be a mix of the two genes this way. - predetermine randomly at birth which gene will always be picked, and which one will be ignored (mostly). So one young with the same genotype would turn out differently than another young with that genotype. I'm sure people can come up with disadvantages for this scheme, and hopefully with more advantages too. It's rather complex now, but it all has the underlying 'gene number' idea, which is rather essential if we want genes calling each other, or changing each others priorities anyway. If we can link this to the stillbirths problem, and fix some brittleness with it too, and create some interesting genetics at the same time, why not? Good luck ripping this apart, or building on it! Martijn -- Martijn Faassen email:faassen@phil.ruu.nl From ???@??? Sun Nov 27 10:32:02 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 FAA13844 for ; Wed, 23 Nov 1994 05:04:18 -0500 Received: from relay1.oleane.net by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rAEZc-000fIrC; Wed, 23 Nov 94 02:05 PST Received: from squirrel.UUCP (uu2001@localhost) by relay1.oleane.net (8.6.9/8.6.9) with UUCP id LAA18027; Wed, 23 Nov 1994 11:03:11 +0100 Received: from o2001.two-oo-one.fr by squirrel.two-oo-one.fr with smtp (Smail3.1.28.1 #52) id m0rADys-0007PwC; Wed, 23 Nov 94 10:27 MET Received: from tom.two-oo-one.fr by o2001.two-oo-one.fr; (5.65/1.1.8.2/19Jul94-0316PM) id AA14572; Wed, 23 Nov 1994 10:30:04 +0100 Received: from localhost by tom; (5.65/1.1.8.2/21Apr94-0551PM) id AA04216; Wed, 23 Nov 1994 10:26:24 +0100 Message-Id: <9411230926.AA04216@tom> To: Martijn Faassen Cc: ag-alife@alnilam.krl.caltech.edu (ag alife), gollum@two-oo-one.fr Subject: Re: Eggs etc. In-Reply-To: Your message of "Wed, 23 Nov 94 01:35:13 +0100." <199411230035.BAA07035@laurel.stud.phil.ruu.nl> X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 23 Nov 94 10:26:23 +0100 From: gollum@two-oo-one.fr X-Mts: smtp > > While I'm here I noticed my gene-stealing idea did not go down well > > (where it was noticed :), but seems to have been missunderstood so I'll > > give it one more plug before dropping it. > > > > The point of the gene-stealer idea was mainly to provide another helping > > hand to the aliens. The players behaviour (his phenotype) is, of course, > > directly controlled by himself not determined by his genetic code. The > > idea was to have a reversal of the process which turns an aliens genetic > > code into their behaviour used to infer the _players_ genetic code from > > his behaviour (this is very tricky, but need not necessarily be totally > > accurate). > > If you can devise a plausible idea on how to translate human behaviour > reasonably accurately into assembly code (or whatever control structure > we'll be using for the aliens), this would be great.. But I'm currently > rather clueless on how to do this..I'll have to think about this. I don't > think this should be a primary goal for the alife group though, let's first > get the basics running, though that shouldn't keep anyone from thinking > about this, and keeping this in the back of their minds. > > > This genetic material can then potentially be stolen by aliens > > when they kill/devour/copulate with etc. the player, thus incorporating > > some of the players (presumably clever) behaviour patterns into their > > genetic code. This is the kind of 'cheat' that I think could be > > productive in the game by allowing the opposition to (a) make great leaps > > of progress that might otherwise be impossible (in the available time) > > and (b) copy the players cunning tactics. > > If, again, we can actually devise a way to represent human behaviour > in the alien control structure. > What about just storing the keys the player pressed, that kept trace of how he acted and could be a significant hint for the alien of which ( and in what proportion) action the player took, as:he shot a lot and moved fast.... sounds childish??? By the way is it interesting for the aliens to steal genes from a player they killed...I mean if they killed him ,he's just not as good as the are, so why mix with a less clever org. ? Hope this helps. Olivier. +--------------------------+------------------------------------+ | Olivier ARNAUD | "All that glitters 's not gold..." | | | | | tel:(1)46.66.54.54 | E-mail : gollum@two-oo-one.fr | +--------------------------+------------------------------------+ From ???@??? Sun Nov 27 10:32:03 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 LAA05449 for ; Wed, 23 Nov 1994 11:00:51 -0500 From: mbbad@s-crim1.dl.ac.uk Received: from mserv1.dl.ac.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rAK0A-000fIrC; Wed, 23 Nov 94 07:52 PST Received: from s-crim1.dl.ac.uk by mserv1.dl.ac.uk with SMTP id PAA26441 (8.6.9/5.3[ref pg@dl.ac.uk] for dl.ac.uk from mbbad@s-crim1.dl.ac.uk); Wed, 23 Nov 1994 15:43:50 GMT Precedence: first-class Received: by s-crim1 (931110.SGI/930817.MJE) id AA27288; Wed, 23 Nov 94 12:43:38 GMT Date: Wed, 23 Nov 94 12:43:38 GMT Message-Id: <9411231243.AA27288@s-crim1> To: ag-alife@alnilam.krl.caltech.edu Hi, I would hack all your messages around and comment on each bit in turn but they're so mixed up together I think I'll start afresh: Assembler-like-Control: I don't like it. It seems to me that it's far too low a level to be run at any speed on (for example) my 40Mhz 386. I see why its the method many of you favour because of the obvious precedents in tierra et al. Bear in mind, however, that the classes of problem set in tierra (no I don't have direct experience but I've read descriptions on several occaisions) are far (far, far ...) simpler than the ones we are discussing here. Also, (and possibly more important) the generation time in tierra is far less (in virtual machine cycles) than ours could be (and I expect the environment tends to favour those in which it is a short as possible). A tierra entity (I believe) has only to replicate itself (in an asm-like fashion) to reproduce. Our scheme, on the other hand has a far higher cpu overhead before we can even consider breeding. (In fact it's horribly heirarchic: (1) Find Food (1a) Detect Food ? (1ai) Move towards food. (1aii) Eat Food (1b) Don't Detect Food ? (1bi) Begin (random) search (2) Defend self (2a) ... ) So my initial opinion is that if we write that in a stack-based add/mult/div/jmp type of language it will take years to run, let alone evolve. I think we should base the language at a higher level, one where many of the basic commands have direct relevance to the universe, things like (I've said this before): FOR_EACH_ALIEN_IN_LIST(list l, statement s) SCANNER_MAKE_LIST(hardware scanner, object_selector which, list l) etc etc This has the advantage that each of the arguments of the statements has a data type and this can be made use of during mutation (e.g 'list l' might be mutated to 'list m' but not to 'hardware q'). ((Of course, what I *really* like is my original interrupt driven scheme. If you want to add priorities then they come in the form of which interrupts the creature chooses to set: _set_hardware_interupt_(hardware scanner, int range, routine CALL_ME) _set_hardware_interupt_(hardware gun, int charge, routine CALL_ME_2) Mate-Selection: For mate-selection I suggest leaving it until we can actually see whether we need it. If we do then what is needed are some 'measures' by which the alien can assess a potential mate, possibilities might be: Prestige (assume that they all know how many kills the others have) Energy Level (provide a scanner that measures it) Relatedness (easily done, we just keep track of who is who's child; children/siblings are 50% related, grandchildren/ cousins are 25% related, aliens brought in from outside are 0% related) Similarity (don't like this 'cos *we* have to define similarity so we automatically build in some preconceptions about what is similar; + it is potentially very expensive Still-Births If we have data typing (as above) then that provides a simple mechanism for avoiding (some) dud instructions. Otherwise perhaps this should be left until we know whether we need it. Cross-Over As I said above, I don't think deciding which genes are equivalent based on similarity is the answer. Personally I'd suggest fixing the number of *basic* genes in the genome (naming each one for our convenience) and only swapping them with the same gene from a different organism. Some of these genes would be 'locked' as having the same 'purpose' (e.g the ones associated with definite interupts) whereas others would merely be 'defined' as equivalent (if they were suitably defined in the 'seed' organisms then there would be initial consistency and the process of evolution would produce compatibility (at least amongst interbreeding sub-populations)). (Oh I almost forgot) it would still be possible to swap a gene with the wrong one but we'd make it much less likely (1 event in 10% of new individuals, say). Thresholds/Multiple Instruction Pointers I think these are over complex. Hamming Distance If there's a (short) explanation can we have it through the list ? And now some quotes: >3) We can study more how nature does it... have effectively two copies > of each gene. I'm not sure how the number of genes could change in > nature. By copying an entire chromasome or mismatching the two chromasomes during cross-over (so one copy looses a bit and the other gains one) but don't fall into the trap of assuming that there is something 'right and proper' about the way nature does it (actually nature devotes a lot of energy to trying not to do it at all). >> So, I imagine each module still has a number, but that calls work >> stochastically: the module with the number most similar to the call >> number will have a higher chance of getting called than the modules >> with numbers more different from the call number. This is clever, but has the obvious (to me :-) problem that it can lead to extremely large numbers of genes (this actually happens in real organisms ). Also it builds random behaviour into the systemi, I'd rather just provide a RND function (ideally one that just does a 50/50 1/0 selection) and let them use it *if* it is an advantage. >> I agree with Chance that the laying eggs and then fertilising them is >> gonna make things more difficult for them poor aliens to develop. I do >> think this should be a long term aim (especially after reading everyones >> fascinating ideas concerning them :) but I think we should definately >> start off making evolution as easy as possible for the poor critters and >> see whether we get anywhere. I think we should: First: get a 'mutateable' control language Second: invent cross over between organisms Third: get the game going with *only* combat (no feeding, no breeding, no player, no asteriods, no collision) Fourth: Only when we've seen some evolution in that 'simple arena' should we start worrying about the more complex bits >I think we should move into the direction of eggs, but, we might use >*anything* from fitness functions to handcoding the aliens to seed >the population from the start (and perhaps also during the game). >Just whatever will make the game more enjoyable. Well lets use 'implicit fitness' to begin with (e.g let them fight for 5 minute then breed the survivors and iterate) and only add extras if we need them. >> Whilst open-ended evolution is the most powerful in the sense of being >> able to produce the most novel and surprising affects it is certainly >> very weak in terms of the time it takes for it to produce efficient >> solutions. Thus we may even wish to start with the much-loathed fitness >> function of some kind, since this allows more control of the creatures >> development, quicker development, and an easier analysis of the behaviour >> that does arise. > >We'll be pragmatic about this, we'll just use anything that works, and >we should keep the system open enough to allow both for open endedness >and fitness functions alike. >But: > >- if there's two approaches that both work about as well (using > some criteria we'll need to develop..or maybe just 'playability') >We'll include the most elegant, open ended, least hacky solution in >the final version, and not the other one. :) If, however, it turns out >that our elegant open ended stuff sounds nice, but doesn't do anything >as well as for example a fitness function, we'll go for fitness function. I agree. >Besides, I don't see why we can't have (after we get some alien >behaviour code representation ready) two teams, one going for open >ended evolution, the other going for fitness functions, if there is >such a need. Or four teams (or seven (or fourty eight))) :-> Or to put it another way, no two people have *ever* entirely agreed about evolution. >If you can devise a plausible idea on how to translate human behaviour >reasonably accurately into assembly code (or whatever control structure >we'll be using for the aliens), this would be great.. But I'm currently >rather clueless on how to do this..I'll have to think about this. I don't >think this should be a primary goal for the alife group though, let's first >get the basics running, though that shouldn't keep anyone from thinking >about this, and keeping this in the back of their minds. In theory a neural net could be trained to make the same decisions as the player but this is getting and bit advanced, lets think about it later. >> Concerning the issue of whether the player is human or alien and thus how >> they develop their weaponry etc. here is another (not necessarily >> brilliant :) alternative: >> >> The player is human and is provided with initially random combinations of >> weapons, armour, engine etc. by the military research team back home on >> earth. Periodically (between waves, when he reaches the next >> communications pod, whatever) he has to send reports home on the >> effectiveness of each piece of equipment. This 'fitness rating' for the >> equipment is then used by the research team (in a genetic algorithm type >> way of course :) to determine the next set of equipment to send on up to him. *But* if the properties of the equipment are just determined by a set of numbers then it will be 'obvious' which direction is better. On the other hand if we used my 'combinatorial' hardware approach, the player could simply 'salvage' some sub-modules and incorporate them into his ship. This also has the advantage of providing game progress (not all the types of sub-module are available in the initial population and we occaisionally add a new one (mutation or the arrival of a new alien). >> This keeps with the evolving equipment theme without the business of >> being an alien (to which some people seem to object). It also means the >> player must choose well when assessing his equipment otherwise he'll get >> a load of junk next time, and gives him *some* but not total control of >> what he gets. Who objected ? I thought somebody just said that they thought other people would object. >> I must admit however that I do quite like the idea of being an alien, but >> that may just be a personal thing :) I like it, but to keep some (erm...) 'directionality' of play it might be better to have the player 'inherently opposed' to the aliens in some way. Personally I'd rather have a human pilot but let him gradually incorporate alien technology into his ship. >Currently my research idea goes someone like this: >Then again..we might instead couple certain parts of the configuration >to the different genetic modules..for example, a module dealing mostly >with thrust behaviour also has some 'thruster configuration' stuff in it.. >this is however a vague idea..If anyone wants to think about this? I'd rather that hardware was hardware and software was software. Badders From ???@??? Sun Nov 27 10:32:05 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 QAA17222 for ; Wed, 23 Nov 1994 16:06:49 -0500 Received: from altair.krl.caltech.edu by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rAOvV-000fIrC; Wed, 23 Nov 94 13:08 PST Received: from deneb.krl.caltech.edu by altair.krl.caltech.edu; (5.65/1.1.8.2/25Jul94-1054AM) id AA05852; Wed, 23 Nov 1994 13:06:35 -0800 From: Charles Ofria Received: by deneb.krl.caltech.edu; (5.65/1.1.8.2/20Jun94-0947AM) id AA28446; Wed, 23 Nov 1994 13:06:35 -0800 Message-Id: <9411232106.AA28446@deneb.krl.caltech.edu> Subject: Another try at control structure... To: ag-alife@alnilam.krl.caltech.edu Date: Wed, 23 Nov 1994 13:06:35 -0800 (PST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 6289 Greetings all, After being prompted by Martijn to think more about an object oriented control structure for the creatures, I think I've come up with something quite nice (which also releives a good number of problems various people have brought up.) Here goes... (remember the exact numbers of things *can* be changed) First of all, the creature has a global stack which is usable by all of the genes. The creature is composed of a number of modules or objects (depending on which terminology you want to use - I think module is more appropriate since they are not quite objects... plus we refer to other things in the environment as objects, and the terminology will get confusing). Each module contains: 3 registers an instruction pointer a local stack (?) a local object list (?) assenbly language code Now a bit about how all of this works. There will be one master module which controls all of the others (kind of like a nervous system maybe?) Any module has the power to start or stop any other, but typically (I imagine) the creatures will use them in a heirchy. When a new module is started, this does *not* imply that the current one is stopped. One possible way I could see a creature designed is that it has its central module call three sub-modules. The first could be combat module which the central module automatically activates whenever the creature takes damage. The second might be an find-energy module where the creature does some kind of search pattern for food (or maybe for a weak creature, and then it calles the combat module). The final one could be a repro- module which finds a good spot to lay an egg (or finds an egg) and guards it. There would be lots of lower level modules which each of these call in turn. For example there might be a goto-object module. The find-energy module would call this if it senses space plants or dead aliens to go and eat them. The repro-module would call this when it senses an egg. Otherwise both of these might alternate between calling a random-search and a sense-object module. A key thing here is that the central module can come up with any scheme it likes to manage the others. It could give them all priorities constantly recalculating all of them, or else it could use simple increment and decrement of priorities. Remember that we are going to start the soup with a number of well written creatures and a large variety of genes. These genes will certainly optimize themselves quickly (which is what the game will be best at doing). After that they will stick around and mix-and-match for the most part. Only occasionally will new genes crop up, but when they do, player beware! A bit more about the individual parts of each module (gene I guess we can call them). Three registers might be a bit much for each one to have; I think we can do it in only 2, but I wanted to be sure. We can adjust this after we come up with the language. Each module obviously needs its own instruction pointer because after it finishes calling another module, it wants to come back to the exact point where it left off. Ideally I want to have multiple modules be running at once within a creature (I'll get back to that later in the letter). A local stack would be for internal storage of information. I think it might be fine to just use the global stack, and clear everything out when you are done with it, but it might be easier to give each creature their own - we'll have to discuss this more if we decide to adopt this creature structure. A local object list - this is where things get very interesting. This list (and associated commands) would give a creature a good sensory system. One command could be fill_list. This looks at (for example) the first register. If it has a 0 in it, it places all of the objects the creature can see into the list. A 1 represents only other aliens, a 2 plants, etc. We can then have other commands to read through the list, or sort it or whatever. I think using this system gives the creatures a lot more potential. My only concern is that it might take up a large number of instructions. Finally we have the assembly language code. Probably this is a bad way to refer to it - its the assmebly language for the creature, but it doesn't have to resemble a real assembly language in any way. To make it possible to mutate we have to limit the number of commands and how arguments work, but thats it. There is no other inherent limitations to it. We could have a single command which makes the alien do figure-eights and fire to the beat of jingle-bells. We just want to keep it as simple as possible to allow the aliens to build the most off of it. Ah yes, let me give a sample of how a gene (module) might work. I'll use the control-module. Remember - this is entirely in pseudo-code and in no way necessrily represents the assembly language we are going to end up using. Also I'm assuming that each module can only start one other. If a module tries to start another one while on is still going, the first one is automatically stopped. Here it is: template-1 start repro-module template-1.1 if energy < min_energy, jump to template-2 if damage has been taken, jump to template-3 jump to template-1.1 template-2 start find-energy-module template-2.1 if energy > energy_to_restore_to, jump to template-1 if damage has been taken, jump to template-3 jump to template-2.1 template-3 start combat-module template-3.1 if combat-module is finished, jump to template-1 jump to template-3.1 And thats it! Simple, yet it should be effective. Artificial creature will, of course, come up with something a lot more effective (and complicated) than this, but it should be an easy way of doing things. Lots of other gene-management systems can be used (and we should start with a number of each). I guess that's all I have to say right now... tell me what you think... --- Charles PS: Hamming distance is when you line two strings (or in our case genomes) up next to each other and count the number of difference. Really simple. There are more comlpex methods, however, if the strings are not the same size (or worse if they can have things added or removed from their middles). From ???@??? Sun Nov 27 10:32:07 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 FAA07239 for ; Thu, 24 Nov 1994 05:47:52 -0500 Received: from gate.demon.co.uk by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rAbiZ-000fIrC; Thu, 24 Nov 94 02:47 PST Received: from darkin.demon.co.uk by gate.demon.co.uk id aa10572; 24 Nov 94 10:39 GMT Received: by darkin.demon.co.uk (V1.16/Amiga) id AA0031i; Thu, 24 Nov 94 10:21:05 GMT Date: Thu, 24 Nov 94 10:21:05 GMT Message-Id: <9411241021.AA0031h@darkin.demon.co.uk> X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Reply-To: christian@darkin.demon.co.uk From: Christian Darkin To: ag-alife@alnilam.krl.caltech.edu Subject: Global senses & Memory Squashing Hi, Here`s two more wild and wacky ideas: 1) Global senses At the moment, the amount of CPU time we`re going to spend working out who sees, hears and tastes what is quite worrying. The real problem is that we`re going to have to do it all for each and every creature. How about some kind of global perception system. A level of decoding that goes on between the universe and the creature`s brain. In our world, we can`t sense atoms and molecules, we don`t instinctively know about electromagnetic energy. If we did see things like that, it would probably make the world a lot tougher to live in than it is now! So I`m wondering (quite vaguely at the moment) how we could put in a sort of sensory interpreter to feed our creature`s brains with a `processed` idea of what their world`s like which they could deal with. That way, we`d only have to do it once, and then each creature could take an information feed from that VIRTUAL virtual universe........ what the hell am I talking about???? I don`t know. 2) Memory Squashing Are we giving our creatures a memory? I realise that this is an increadibly difficult thing to even think about: How would it work? What would it do? Who needs it anyway, and how would the creature use it? Well, if a creature stored up a list of all its` actions and everything that happend to it during a battle, it could (if it surrvived the fight) go back over the information, and try to work out what it did right and what it did wrong. That would be good, but then we get into how long the memory should be, and how it decides what`s important. Here`s an idea: When I remember things, it`s not just a store of all the events that happen to me. Say I`m remembering last thursday. I don`t recall everything that happened to me last thursday, I have a memory of what a `normal` thursday is (when I get up, the hours I work, etc) , and then I remember the things that made last thursday different (what I had for lunch. what the weather was, etc). By summing the two, I can give quite a good assessment of what last thursday was all about. Now it strikes me that this is exactly the way that data compression works. First you scan through the data and look for patterns, then you take them out and replace them with key numbers to say where they were, then you take another look. Then you do the compression again to find further patterns in the condensed data. And again. And again. And again.... Slowly, you`re reducing the data to general formulae. Eventually, even the surprising incidents fall into patterns (I may not have sandwiches every thursday, but because I am who I am, there will be recurring patterns if I keep compressing the data). Give that kind of a memory to our aliens, and you`re giving them a way of making sense out of their universe (and even the potential to analise their own genetic make-up). By feeding all their actions and all their responses into a memory, and then constantly compressing it down, they can use the patterns they come up with as a basis for planning the future. There is probably no reason why *all* aliens can`t be feeding into the same gia-like group wisdom if it`s not practical to give each their own memory. Of course, maybe, what I`m describing is a neural net. I don`t know. Sorry if this is garbled nonsense. It probably is! -------------------------------------------------------------------------. !Email christian@darkin.demon.co.uk !Mail Sent Via Demon Internet Services ! !Full Internet Conection For 10/Month Fixed. Tel: 081 349 0063 ! `-------------------------------------------------------------------------' From ???@??? Mon Nov 28 11:49:10 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 LAA10585 for ; Mon, 28 Nov 1994 11:41:47 -0500 Received: from yuma.ACNS.ColoState.EDU by alnilam.krl.caltech.edu with smtp (Smail3.1.28.1 #1) id m0rC90h-000fIrC; Mon, 28 Nov 94 08:33 PST Received: from K12.ColoState.EDU by yuma.ACNS.ColoState.EDU (AIX 3.2/UCB 5.64/4.03) id AA50473; Mon, 28 Nov 1994 09:30:43 -0700 Received: by k12 (4.1/SMI-4.1) id AA10100; Mon, 28 Nov 94 09:36:17 MST Date: Mon, 28 Nov 1994 09:36:16 -0700 (MST) From: Robert Elsner X-Sender: relsner@k12 To: Gregory Glen Taylor Cc: Evolving Destruction Subject: Re: Space vs. Ground 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 Mon, 21 Nov 1994, Gregory Glen Taylor wrote: > I see doing a ground backdrop as posing a bit of a problem. If we choose > a space-backdrop we can do a star-scrolly (various levels of stars), > which will produce a nice-looking output, but it will be faster and more > memory conscious, than a bitmap for the ground. > > Plus if we manage it right, it may also assist in producing easy > collision detection...but that's another story. > > Thoughts? -=GT=- What about having stars(planets) on the player level, so if the player is careless, they could get trapped in the gravity of the star/planet, and get smashed. Also, What if we may raytraced movies for die/other events, a whole race being destoyed( for die, we show a 3D view of the player, and a smash or whatever)? So we could combine raytracing and 2D universe. Best o' both worlds. Se above/\