Conference hydra::amiga_v1

    Nice to meet you.  I've been working on a game.  I've got an Amiga
    1000 and 2.5meg and a Supra 20meg hard drive.  A great combination
    for development.  I have all the books, I find the SYBEX books
    particularly useful: "Programmers Guide to the Amiga" and "Amiga
    Programmers Guide" by Peck and Mortimore (I forget which is which).
    If I could only buy one of those books, I'd buy the Peck book. 
    It has more examples.  Even if you have both books, you still need
    the "Intuition Programmers Guide", "Rom Kernel Manual" and eventually
    "Hardware Reference".  I haven't seen the "auto doc's" yet (that's
    documentation on a disk for developers from Commodore-Amiga).
    
    My game is a space exploration game, the display resembles Atari
    800 Star Raiders or the Star Wars Arcade machine.  But I hope to
    make the game much more than a shoot 'em up.   In this game the
    player chooses his own goals.   The universe would resemble the
    role playing game Traveller.   So, it's sort of a combination role
    playing game and arcade game.  
    
    Anyways, I have alot of friends with Amiga's who are not programmers,
    but they do consider themselves artists.  I want to exploit their
    talents.  I'd like to have them working on the images for the alien
    ships, cities, astriods, the aliens... etc.  There is a PD program called
    BRUSH2C which can convert Deluxe Paint Brushes to C code.  (Hexidecimal
    Intuition Image structures).  This isn't quite the format needed to create
    bobs, I will eventually need to use bobs.   Once I stream line this
    process I will be able to create a game rich in it's variety of
    strange aliens, vessels and images.
    
    So far I've got the Double Buffered display running and the "flying
    through the stars".   Several attempts at a good way to convert
    DPaint brushes to bobs.
    
    I'd like to hear from anyone else who is working on a game, or has
    ideas. 

    re: .2  hiya
    
    I have ideas for games, but have given up on implementing them until
    I've learned enough Lattice C to be dangerous.  I'm still at the
    stage of trying to puzzle out how to get C to do what i want.  I
    know how to do it in Fortran, Basic, etc. but C arrrgh..
    
    I'd love to do a 3D version of Joust, but i think i'll try something
    a little easier first.  Maybe just convert to C and "Amigatize"
    some magazine basic games.  I tried converting a couple IBMPC
    BASIC games to AmigaBasic, got some to work, but got too frustrated
    with the AmigaBasic user interface to do much with it.
    
    Currently I've been trying to write a ST pic to IFF file converter.
    Got Neochrome to IFF working, now i'm trying to do Tiny to IFF.
    
    -dave

    
    I'm delayed until I get a hard disk...
    
    And until VAX Fortran is available on the Amiga!!!    C isn't on
    my list of enjoyable languages!
    
    -Ray
    
    ps the hard disk will have to wait at least several months or until
    my wife forgets several other purchases...
    

Re: .4

>    And until VAX Fortran is available on the Amiga!!!

The FORTRAN that is available for the Amiga claims to be ANSI conforming
and to support a large number of VAX FORTRAN extensions.

I've got the ABSOFT f77 compilier, and it seem's pretty neat.  I'll try and
asnwer questions on it if anyone is interested.

Robb

    Robb,
      Does ABSOFT's F77 have the structure/record extensions that VMS
    FORTRAN does? How'bout run time Format?
    
    ... Rich

    Well it's good to see that there is some interest out there after
    all.  I am currently pursuing a group of programmers called Late
    Night Development who wrote the excellent implimentation of Space
    Invaders called Amoeba Invaders.  They wrote in C and used certain
    packages to do the graphics and animation all of which I am interested
    in.  So if any of you have any idea's on graphics and animation
    packages which would speed my development efforts I would be very
    grateful. 
         Also please feel free to suggest games you would like to see
    written for the amiga on this note.
            

    I'd like to see TEMPEST on the amiga.
    This should be a piece of cake for the Amiga,
    not too many sprites, 16 colors, 16 sided figures ...;
    a very base2 game.  This was a favorite when I did arcade games.

    Dave

    
    The talk about Air Warrior in another note reminded me of what I
    the game I *REALLY* want for the Amiga. A multi-player game where
    the Amiga is used as a frontend to the VAXs of the EASYnet! About
    2 years ago I looked at doing something like this with VAXtrek and
    Rainbows but just didn't get around to it. It doesn't have to be
    real-time but it would be nice, something like Empire for several
    players with the Amiga doing the displays would be great!
    
    Any subject from Air-to-air combat, land combat, naval combat, even
    a version of RISK! Anything would be fun!
    
    I'd be willing to work on the VAX side if someone else was able/willing
    to do the Amiga side! This would join together the best of two worlds!
    
    -Ray

    Speaking of games, I had an Intellivision about a zillion years
    ago, and the most incredible game was called Sea Battle.  I won't
    go into detail here, but suffice it to say that my friend and I
    once played for 18 hours straight.  Our thumbs looked like ripe
    zuccini after that session.  I'd love to see an Amiga version.
    
    I still vote for Raid on Bungling Bay as the best game of all time.
    It ran at warp speed on a C'64, and I still don't think there are
    any Amiga games that even come close to the heart pounding action.
    

    I'm glad to see that there are people interested in developing games
    (I was getting worried for a while).  
        
    WISH:
    I'd like to see Defender.  It was my favorite game on the ATARI
    800. 
    
    

    
    Are there any reference books that one would consider definitive
    regarding game design?  I don't think I've ever come across any.
    I'd be interested in seeing the source to a few existing games before
    I embarked on one of my own.  Maybe the folks who wrote the new asteroids
    will make it available in one way or another.
    
    - steve mcafee

    re:.13
    
    definitive?  I found one book - "Arcade game design on the Atari"
    or something like that.  I don't think it is currently in print,
    bought it about 2 years ago at Childworld.  It covers game design,
    basic algorithms for various types of games, even covers sprites
    and custom display lists if i remember correctly.
    
    Since the Amiga has similar hardware to the Atari 8-bit computers,
    this may be the closest thing to an Amiga specific book.
    
    -dave

I picked up  Computes! "Inside Amiga Graphics" last night. It covers
everything from screens and screen formats, to sprites and bobs to
animation. It includes numerous C and BASIC examples. I don't know how
good the content is since I only skimmed through it while reading the
"Rom Kernal Listing - Exec" But in the past, Compute books have been pretty
good.


John

    NOW YOU GUYS HAVE GONE AND DONE IT!!!!!!
    
     You have piqued my primal urges - to build the definitive computer
    game. I agree with some of you that the Amiga is the best available
    platform.
    
     I have been doing a lot of thinking on the subject of game mechanics,
    inter-computer communications, real time actions on games, and here
    is what I think a good game should be like:
    
     1) TIME PRESSURE - There should be time pressure on the players. But
    a good game mechanic would allow actions that take more than one clock 
    tick to occur. This means that the player must be able to think
    in the future, and coordinate moves so that the forces appear in
    the right place and at the right time.

     2) BLIND - the game must be blind. That is, a player should only
    be able to see those enemy forces that can be "sensed". For a game
    like Squad Leader, only those forces in the line of sight of any
    "friendly" piece should be viewed on the screen. A lot of games now
    give total intelligence which removes the "sweat factor", in games.
    For a space game, this can be accomplished by occluding obstacles.
    
    3) TRAINING - typically, in campaign games, survivors of combat
    get strengthed simply because they survived. This is a good concept
    but a bad mechanic (though a simple one to program). I would like
    to see (and this is a tough programming problem, I realize) a mechanic
    that allows the players a set of basic commands (such as move, shoot,
    etc), which can be compiled into routines or ORDERS that the player
    can issue to any or all of the pieces. This will lend an air of
    insanity into the game because you don't know how those routines
    will perform. But best of all, this mechanic allows you to "Boyd
    Cycle" your opponent - that is, analyze and act/react in a shorter
    period of time than your opponent, thereby gaining/maintaining the
    initiative. Routines can be cancelled, and the basic moves are always 
    available to the player. Though, with a time constraint it wouldn't
    be to your advantage to move every piece with low level commands.
    Routine calls can be grouped into higher level routines, allowing
    greater abstraction. All this amounts to is "training" your soldiers.
    One has to be careful that such parameters as Computer speed do
    not enter into the equation, so that faster machines have an advantage.
    This can be accomplished by letting the slower machine  handle the
    clocking. 
     An extension of this is to have a basic set pf primitives that
    is varied enough so that users could write programs, in the language
    and style of their choice, that represent orders for their pieces.
    It would be interesting to see a player's Prolog expert system against
    someone's C based strategy.
    
     I should mention that this concept does not remove the location
    of the intelligence - i.e. the player still does the thinking.
    
	This feature, along with feature #2, would generate the "fog
    of battle" - you would be receiving reports and know what the standing
    orders are to your units, and see the enemy units that can be sensed.
    But you may find your strategy needs revamping.
    
    OTHER WIERD IDEAS: It would be nice to dream up a game that gives
    players basic "tools" and "machines", and a variety of physical "Laws"
    which can be combined in millions of novel ways so that "fleets"
    have differing characteristics - strengths and weaknesses. Of course,
    no player would be able to afford ALL capabilities. This concept
    is much the same as the Technology tracks in Stellar Conquest, but
    infinitly more complex and varied, so that the players can dream
    up really far out weapons and tactics.
    
     It would be nice to have a mechanic that allows broader creativity.
    
     As to the game "Platform" itself, sometimes I would like to
    "computerize" Squad Leader, for a blind game. Other times, I would
    like to build the definitive Space War game with massive strategy
    and tactics. 
    
     I would like to share game building ideas with anybody who is
    interested, and work towards building a game. You can reply here,
    or send me mail via:
    
    		CTOAVX::GERMAIN
    
    		      or
    
    		MERIDN::GERMAIN
    
    
    		Let me know what you think!
    
    
    			Gregg

    I have had an idea for a game for the last two years that use a
    lot of the ideas that you have listed in the last reply.  It also
    uses several others.
    
    Mine is based on an adventure style game, but uses the Amiga's unique
    graphic and sound capabilities to simulate an environment with a
    very high degree of realism.
    
    It's a game that you can't 'win.'  You can accomplish many different
    things, at whatever pace you choose, because the events occur in
    realtime.  What it offers is a journey to someplace you have not
    been to before (and if you have, you can still take it again, trying
    different things.)  Because of the Amiga's windowing capabilities,
    you are able to obtain the tools you need to assist your journey,
    once you figure out how to obtain them.
    
    A lot of games have frustrated me because they were too fast.  You
    would get killed before you got a chance to see anything interesting
    happening.  This game would give you the option of being lazy...the
    chance to look around and see what there is to see.  However, being
    realtime, you have a schedule to meet too, so you will miss out
    on events if you aren't timely.
    
    Writing the game would not be difficult, as it is not much more
    than a graphic adventure.  Instead, the approach to the implementation
    is what would make the game unique, and interesting...appealing
    to a very broad audience...even those who do not like 'computer
    games.'
    
    Randy
    

    I've recently bought the MANX C compiler with Source Level Debugger.
    It's an excellent tool if you're going to be playing with the Amiga's
    graphics routines.  It's practically an interactive environment!
    And it saves you from the GURU.  Instead of getting a GURU message,
    you see your source code with the last line of your program that
    executed highlighted--  then you have to reset.
    
    Anyways .17 reminds me of my idea (.1).  A game that never ends.
    An infinite universe to explore.  Lot's of flexibility.
    
    My idea is that the player has a space ship.  He roams the universe
    meeting other creatures (randomly generated), exploring new planets,
    escaping space pirates (or escaping the authorities if you decide
    to be a pirate).  You would be able to make trades and steal from
    other ships ("I'll trade your feul for my not killing you.").  
    
    The motive will be to inhance the capabilities of your ship.  Scattered
    around the universe are devices that attach to your ship to provide
    a new capability.

    I like that idea! I had the same notion a few years ago, but didn't
    do anything about it. One of the features about a game design like
    that is the fact that the author of the game could play it and have
    fun!
    
     A couple of issues would have to be worked out, though. First,
    it would be nice if a set of "primitive" laws, and objects could
    be generated. This set would have to be large enough so that the
    number of possible combinations is enormous. Let me give an example
    of what I want to avoid by having these primitives:
    
    If I build a game that has5 or 6 different kinds of ships, 10-20
    different kinds of characters, 10-15 different kinds of planets,
    or cities, or whatever, I, as the game designer am going to know
    all about these items, and how they interact, and what their weaknesses
    are. It would be nice if we could drop one level of abstraction.
    By this, I mean, (and this is not a practical example), define the
    laws of the universe. then spin up a universe with random number
    generators - the starting seed giving you a different flavor of
    Big Bang. Then explore what you have got.
    
    Now this is impractical, but it conveys the idea. I want to get
    away from...a pirate is a pirate, a cop is a cop, etc. 
    
    I as the game designer, want to play the game too! Typically, this
    is accomplished by having a game mechanic, and two human players,
    so that the infinite combinations come from the players' minds.
    
    Another possibility is to build all you know about a spaceship into
    a program, then, at game time, randomly destroy parts of the ship
    to make it a near derelict. The player must jury rig the vessel,
    and get it down on the planet it is orbiting. The ship must be
    sufficiently complex to make figuring out the ships systems somewhat
    difficult (though a ships' engineer, which is what you are, would
    have a fair idea of how the craft was built).
    
    			Gregg

    I like these ideas.  I envision a system of rules for building 
    ships similar to those of the role playing game TRAVELLER.  The
    rules take into account hull size, cargo space, fuel tanks, engine
    size, manuever and jump drives, fire power.  
    
    New space ships could be designed by a seperate task that runs in
    the background.  This second task does nothing but randomly create
    new designs for spaceships during spare CPU cycles.  When it finishes
    the new design the new ship type is entered into the game.  
    
    The same type of background task could be used to create new worlds,
    life forms, objects,
    or to create long rangs plans/goals for computer control beings.
     Imagine that!  Non-player characters that think at a low-priority!
    
    I believe that if the priorities are set right, the background tasks
    could co-exist with a real-time video game-like main program.

    Why does it have to take place in space?  or a hunted cave?
    
    What's the matter with real life.  How about a foreign country?
    

    You might want to pick a better defined system than Traveller. 
    For example, Space Opera.  I've always thought of Traveller as more
    on the role playing side, and Space Opera more on the rule playing
    side of the world.
    
    Just for fun, try and design some of the larger ships in the Traveller
    ``Fighting Ship'' supplement (the dreadnaughts and heavy cruisers).
    We found that they cheated on the designs.
    
    Personally, I thought that it would be fun to resolve, in an arbitrary
    way, the paradoxes of time travel, and then allow the player to roam
    time as well as space, moving objects around and causing profound
    things to happen as a result.
    
    Steph
    

    Yeah... the paradox's of time.  Just imagine all the data you would
    have to retain.  All the events and their cause/effect relationships
    on events to follow.  Wait... what do you do when this leads the
    player to be in some past situation that he was never in?  Determine
    his action randomly?  Go back in time to that event (that could
    degrade the whole idea into "restore saved game").
    
    

    I would like to build a game where the player could put together
    two objects that never have been together before,and use the result
    in a novel way - which would be quite a suprise to the opposition.
    
    Does anyone have any feelings about the idea of a primary set of
    "universe laws" that would generate a complex and varying universe
    without bogging the system down? f=ma might be too low level, but
    it would be nice to come up with a system general enough to allow
    clever players to be really creative. IN principal, like a universe
    general enough to allow the player to take existing things like
    torpedoes, tv cameras, radios, and make a guided torpedo (just an
    example).
    
    as to the question "Why does it have to be space?" I don't think
    it does, I am open to any scenario. although my tastes take me away
    from role playing and mystical types of games. I am more interested
    in the game mechanic - the application of the mechanic to a scenario
    comes second, in my opinion.
    
    As a matter of fact, that brings up another half baked idea - I
    think it is possible to build a game shell that can be used for
    any scenario - same mechanics, different application. for example,
    in a space game you need movement, weapons, sensors, etc. The same
    is true for something like Squad leader, if you abstract the notion
    of sensors a little bit (squads eyes). 
    
    This might be possible if you used an object oriented design approach
    to building the shell - youcan change "sensors" from eyes, to radar
    in the object SENSORS, and perhaps the other code wouldn't know
    the difference (from a programming perspective - obviously the other
    code would change as well from tanks to starships, or to battleships,
    etc.)
    
     What do you think?
    
    
    			Gregg

I think we're talking a Life Simulator here, not a game!!

John

    
    
    
    			could be!
    
    
    			Gregg

    A life simulator is good.  Look at Conway's game of Life.  Those
    rules are really too simple for an interactive game, but that certainly
    is a mimimum bound on a set of ``physical laws''.
    
    Anybody got a favorite set of rules?
    
    Steph

    That's true - I hadn't thought of that!
    
    The first step is to try to define the realm the rules set would
    address.
    
    Certainly the molecular level is too small, Newtonian physics would
    have to be included.
    
    Or do you not abstract that far?
    
    			What are your thoughts?
    
    			Gregg

    I don't think you can afford (computationally) to model down to
    the Newtonian level, other than implicitly.
    
    From my perspective, games like this are fun when interesting and
    unexpected things happen--things like matter transportation, or
    time travel, or energy beams--things that can't happen (at the moment)
    in the real world.  If you're modeling at the newtonian level,
    there's not much chance extraordinary occurences.
    
    But this assumes an ``anthropomorphic'' central character.  If your
    central character were, say, an atomic particle, interesting things
    could happen at the newtonian level.  It might be interesting to
    randomize a set of physical rules and attempt to work towards a
    goal within that framework.  In otherwords, on one run of the game,
    entropy might not increase, or the speed of light might be attainable
    (and perhaps something profound happens when it is reached).
    
    If the character is a ``human'' however, I think that the models
    must be more ``macro'' scale.  Some form of coarse energy book keeping,
    perhaps, or even a set of socio-economic principles.
    
    The representation of a universe could be a set of objects which
    some subset of all existing properties associated with each object,
    and then a large matrix which describes the interation of those
    properties.
    
    I'll have to think more about the specifics.
    
    
    Steph

I think a key here is to separate the animate from the inanimate objects.

In-animate objects follow (closely enough for our purposes) classical 
mechanics, where F (really does) = MA. As long as you incorporate, to
some extent, frictional and gravatational "constants". (I think Einstien just
rolled over!)

However, to simulate animate objects (i.e. Living Entities) requires some
element of independance. (over simplified -> )  People can make *decisions*.
And these decisions are most often based upon instantaneous relative
surrounding situations. These decisions will be the driving force of the
"game". Add to that emotional termoil and you have the beginnings of Life
simulation. Plants and the like (immobile) are rather simple in that they can
be regarded as having fixed behaviour (i.e you feed it, it grows. You yell at
it it still grows (Plant lovers,  ratholes here please!) ) So the immobile
life would be constantly changing, but in a predictable way.

What is needed is a set of both physical and (social+emotional) laws which at
first only approximate Humans (and animals). Continuously add to that
experience gained from the results and we have a *usefull* game (ala Game of
Life).

I think it could be done (on 68020 machines :-) ). The key is formulating
the rule base. I'd venture to say this is a job for AI, not "standard" C.

John

Re .30:

I've left out a crucial piece - Memory! Call it the Persistance of Existance.

>  element of independance. (over simplified -> )  People can make *decisions*.
>  And these decisions are most often based upon instantaneous relative
>  surrounding situations. These decisions will be the driving force of the
>  "game". Add to that emotional termoil and you have the beginnings of Life

The motives and manifolds for these decisions are built upon past experiences.
Without some form of memory, everything would appear as an action/reaction
play, without regard for reason. There could be no coherent story line. 

Clearly, we must limit the elements of this memory to that which is defineable
under our set of rules. This most certainly leaves out creativity, imagination
and dreams (for the other participants of the game. Obviously the human player
still has this capacity!) since these things are usually some meaningfull
alteration of the rules.

Also, the concept of awareness must be accounted for. Traditionally the
*program* was the part that detected collisions or sensed the presense
of other objects, simply because it was written to do so. Now we need a
seperate 'entity' for each animate being in this universe (perhaps separate
processes for each). These entities would be responsible for knowing
thier immediate environment. And from that, each must *continually* be
operative. Even if something is not visible on the screen, it must continue
to "live" since it's actions may eventually affect other pieces of the
universe.


RE .31:   Insane?   Perhaps.  But searching for the unknown is what makes it
known...

John 

    I agree that there might be a place for AI, but NOT written in things
    like LISP - too slow.
    
    I was talking with a friend about a game mechanic, and we brainstormed
    the following:
    
    Suppose, just for the sake of discussion, that you were in command
    of a Squad of soldiers. in most board games, you have to execute
    every move for them. You move each piece every game turn.
    
    What if you were given a set of primitives commands, which could
    be assembled into "subroutines"? Think of this as "Training" your
    troops. The intelligence stayes with you (you have to do the thinking),
    it's just that you can consolidate a series of moves into "orders".
    the more orders you have, the less typing you do. In a real time
    game this can be important.
    
    Now, if you take it one step further, suppose, instead of a set
    of "primitives", we agreed on a database that represented the state
    of the game, and you were allowed to write programs in the language
    of your choice, that operated your units. you would have to take
    care that different machine speeds were nullified, but programming
    skills, language choice, and the amount of smarts you integrated
    into your routines have a bearing on the efficiency of your units.
    
    
    
    Re the Newtonian mechanics: I didn't suggest that as a practical
    level of simulation. It was just as an example of "universal laws" that
    are low level enough to help build a universe full of suprises.
    At this stage of the "game" (no pun intended!) I am in brainstorming
    mode - throwing out ideas half baked or not.
    
    But it seems like there is agreement on the issue of universe
    complexity - that the universe (and I don't mean, necessarily SPACE)
    should be varied and complex enough to make the stuff you run into
    unpredictable (BUT NOT UNFATHOMABLE).
    
    			Gregg

    re: .31
    
    
    
    			Insane?
    
    
         Would you care to be more specific?
    
    
     I mean, just because I am paranoid, schizofrenic, with massive
    Napoleonic complexes...........
    
    
    
    			Gregg

    I like the idea of classing animate and inanimate separately.
    
    Personally, I prefer a first person (``individual player against
    the world'') scenario, to a third person (``the commander's army
    against whatever'') one.  You can still have allies, but none overwhich
    you have absolute sway.
    
    I wrote a game called ``Robot Wars'' once which was similar in
    mechanics to Gregg's (?) ``command by programming language'' system,
    except that it ran in a wind-and-release, so there was no interaction
    after the game started.  The players created some number of robots,
    each with its own algorithm for behavoir.  The last surviving robot
    won.  A simple example of a robot algorithm was ``BEGIN Move forward
    until you hit a wall, turn 180 degrees REPEAT.  BEGIN Fire, turn
    the turret 90 degress REPEAT.''  They got much more complicated.
    
    I thought that it would be fun to apply this kind of algorithm to
    some computer controlled characters in a first-person game.  Define
    a motive, and a means by which to get it.
    
    For example:
      Joe Blow;  Motive: To find the lost X11 widget.
      Behavior:
             1) Defend yourself
             2) If cooperating, defend your party.
             3) Search reachable space for the amulet.
             4) If the amulet is not found, then cooperate with the
                next character to arrive.
    
    Something like that seems like it could make for some interesting
    situations.
    
    Steph

    What about a game where people are allowed to create their own
    character. Not from a standard set of characteristics, like role
    playing, but their own character, using their own descriptions.
    It might be interesting to see if they could interact AT ALL! So
    we would create a universe for the characters to tool around in,
    and when they bump into each other, they interact. What has to be
    in common are things like:
    
    1) you shot at me
    
    2) you have _________  fill in the blank. If I have a concept of
    what it is you have,then I can make decisions about it.
    
    3) the universe.
    
    etc.
    
    Perhaps our characters will be so different that they couldn't interact
    at all. You would be free to creat a very paranoid person, for example,
    who shoots on sight,and asks questions later!
    
    There was an article in Scientific American a few years ago, about
    a computer game where people were allowed to write a subroutine
    that represented behavior under a given set of circumstances. The
    subroutines were allowed to interact, and then the "success" of
    the routines were displayed.
    
    The basic mechanic was:
    
    we meet.
    
    we have coins.
    
    we can either give a coin, or not.
    
    So the subroutine called TIT-FOR-TAT, would give you a coin if you
    gave it a coin, and wouldn't if you didn't. It would always start
    out by giving a coin. Other subroutines had different algorithms.
    For example, one NEVER gave a coin. One would not give a coin TWICE,
    for every time it didn't get one.
    
    The interesting thing was that the routine that had the largest
    number of coins after a long interaction was TIT-FOR-TAT!
    
    
    			Gregg

    I think that the last time anyone actually pulled off the endeavor
    that you're trying to describe, it was recorded in this book I read.
    As I recall, it started: "In the beginning, God created the heavens
    and the earth."
    
    I'll stick with Amoeba Invaders.

    Well, keep in mind that when I say "universe", I don't mean billions
    of stars in billions of galaxies.
    
    Conway's life game can consist of a universe that is nothing more
    than a 24x80 array.
    
    We're just looking for a mechanic that does not make you fully map
    out the game board, but builds it for you in novel formats.
    
    			Gregg

    I'm gonna try an code up a quick something like what you (and I)
    am describing, since we seem to be thinking along the same lines.
    Don't hold your breath however.
    
    Some people don't believe it until they comprehend it, at which
    point you have probably used a great deal of your time explaining
    it.
    
    Steph

Creating very simple "universes", and then "discovering" them is a real
appeal of computer games for me. (Unlike board games, with the same ol'
board.) A few years ago I got interested in the EMPIRE world generator.
EMPIRE, if you haven't seen it, is played on a "flat" world which has
continents and oceans. The continents have no features (rivers, mts.)
other than cities, and tend to have bland round or oval shapes.

So I tried writing some code which would generate a random, but plausable,
world. That is, it would look as if formed by plate tectonics, and have
features whose existence could be explained by normal geologic processes,
climate and weather could be explained by normal cyclonic flows over the
geology, and vegetation would respond in kind. Once this code was done,
then alternate conditions could be coded into the various generating
subroutines. (e.g., a younger world would have smaller plates, because
the thermal circulation is faster. This results in more mountain chains,
smaller continents, more fractured coastlines, etc. On a lower-gravity
world, rivers would meander more, but older mountains would be higher,
and so on.

Such a map generator would be useful for all sorts of games, particularly
those which require exploration or conquest (such as EMPIRE). But
creating a world which is neither predictable nor implausable is a non-
trivial task, I suspect. One Amiga game I know of, Conquitador, can
generate a "random" world, and claims to use fractal geometry for the
coastlines, but the random worlds it generated seemed to have a depressing
regularity and lack of imagination.

John O.

	Actually, some recent investigations (i.e. the last 20 yrs) 
	in nonlinear dynamic systems seems to indicate that very simple
	equations can be used to generate rather complicated (and unpre-
	dictable) results.  Fractal geometries are just one aspect of
	this stuff; take a look some of the articles on "chaos" that
	have  appeared in Sci American in the last couple years.  There's
	also a really good popular treatment of the subject in a book
	called "CHAOS" by a guy named Gleick.

>There's also a really good popular treatment of the subject in a book
>called "CHAOS" by a guy named Gleick.

Yeah, I know. Unfortunately a friend of mine borrowed my copy before I
got a chance to read it. Talk about chaos!

JO

    World/Universe generation is an interesting problem, but the question
    I have after that, as the game's designer/player, is: "Now what?", or,
    "What's the point?", or, "Where's the meat?", or, "What's the plot?",
    or simply "Why?".

    In other words, the thing that keeps me going back to play what I would
    call a "world" game, like the one's being talked about here, is the
    fact that there is a plot driving the action.  Something is somewhere
    or someone does something for some known or unknown reason.  It's the
    plot, and the goals that the plot gives me, that keep me intrigued and
    involved.

    So I would consider adding the dimension of "movtivations/reaons/plot"
    to the universe generator, just to make it ... umm ... more realistic.
    :-) (I just love talking about *realism* where games are concerned.)

    I'll admit that I don't know how to do that.  I do view the overall
    plot of a game like this to be something like a hierarchy of directed
    graphs with nodes being {individuals|groups} of {objects|people} and
    arcs being {movtivations|reaons|goals|plot}.
    
    Taking this view, some questions which then arise are:

	What are the necessary attributes that nodes and arcs must have to
	express an overall plot?

	What are the different kinds of plots that are interesting?

	What metrics are used to decide when a 'good' hierarchy of plot graphs
	has been generated?

	Is plot generation done top down or bottom up?
	Do levels in the plot hierarchy interact?
	If they do, how does this affect plot generation?

	When has 'enough' plot been generated?

	How does the plot graph interact with or influence/control the playing
	of the game?

	Given that I wrote the game, how do I make plots sufficiently complex
	and interesting so that I will not have a mechanical way of figuring
	them out and solving them trivially? 

    This is the point where I stop and say "I don't know how to do that". 

    -jim

    Jim,
    
    I'm not sure I understand what a ``heirarchy'' of directed graphs
    is.  Can you give a simple example?
    
    On the more general subject of plot, I find that there are fun games
    which are virtually plotless.  Many of them have only simple,
    superficial goals, e.g. ``get a high score'', and the fun comes
    from beating upon a novel universe.  Most arcade games seem to fall
    into this category.
    
    What I think would be fun is to be able to randomly generate novel
    universes.
    
    Steph

    re: .43
    
    	I've done alot of thinking about generating plots randomly.
    My idea is to generate the sketchiest details of a world, create
    a conflict and assign the player the task of resolving the conflict.
    
    The only details you generate are those concerning the beginning
    and the end of the game;  Spread around some clues (in a way so there
    is a good chance that they will be discovered);  Create some non-player
    characters that have some association with the conflict.  Everything
    else is generated on the fly, as needed, included the creation of
    people and places that are not associated with the goal.
    
    When the conflict has been resolved.  The player is rewarded, but
    the game doesn't end because during the game play other conflicts
    have come up.  The player chooses a new goal, with new rewards.
    Of course the player could have abondoned his original goal to go
    after a new, more rewarding one.  
    

    BTW:
    
    In all of your considered opinions, has the definitive Submarine
    game been created?
    
    				Gregg

re: .-1

 >has the definitive Submarine game been created?

Silent Service is good, but I would hesitate to say "definitive". The
problem is mostly that it isn't properly "Amigized". It has various
play levels, ranging from very easy to very tough, it has mostly good
graphics, the exception being the view from the periscope or conning
tower. The research and "authenticity" seem quite good, though I have
no experience on WW2 subs to verify it against. The graphics are very
clear (the control panel much more readable than Flight Simulator 2,
e.g.) and it has a nice "accelerated time" feature, so tedious waiting
or chasing can be shortened. I'd recommend this for any wargame where
there is waiting, chasing, repairing, sieging, etc.

On the down side, it seems to be engineered for a smaller, slower
machine than the Amy. The several different graphics screens load over
and over from disk, and to get a clear picture of what's going on,
you need to switch screens frequently. The user interface (keyboard
and mouse) is clumsy and inconsistent. (For example, rotating the 
periscope takes an inordinate amount of time. This may be because the
periscope's view is slow to generate.) 

Overall, it is interesting for a while, but the tedium of waiting for
screen switches gets you, particularly in combat situations.