Re: [Alephmodular-devel] General status overview

[Br'fin <br...@ma...>]

On Friday, January 3, 2003, at 12:22  AM, Joe Auricchio wrote:

>> 'Bios' is definitely there, but it's much harder to determine where 
>> the barrier is between Bios and other functions. For instance, 
>> monster definitions are unquestionably within the Bios, but is 
>> monster AI within the Bios? Is Monster pathfinding? where's the 
>> extent of monster behavior flags?
>
> I'd suggest that a Bio have information describing the physics of the 
> world and its various inhabitants, and their behavior, but no actual 
> code, just definitions in, say, MML or another dialect of XML. So, AI 
> code stays outside the Bio (but may be a module in its own right). In 
> fact I suppose this is a pretty good definition of a Bio - only data, 
> no code.
>
> (The way I've been imagining a Bio is you take a whole bunch of 
> defintions (monster definitions, player definitions, a default physics 
> model, etc) and you throw it all into a big, say, .bio file, and then 
> in the Environment preferences you select that Bio. If I've got it 
> wrong please enlighten me =)

Well, the hardest part of saying 'no code' on the Bios is in the areas 
where current code links definitions to external resources. The second 
hardest part involves 'How do we set up one copy of AlephModular to 
handle M2 files versus Minf files versus M1 files?' Each one is a 
mildly different Bios. So even if the specific map loader isn't coded 
right into the Bios file, there still needs to be a way to specify 
which Map Loading object to apply. Similar details surround terminal 
rendering.

>> What else do we want here guys? Conceptually? Actually? Game Core? 
>> Animation? Rendering?
>
> Rendering:
> -Viewport (takes abstract information about the viewport (x/y/z, 
> theta/phi/psi, fov) and destination (resolution, color depth) and 
> figures out things like what polys are visible, then passes that down 
> to World Rendering and Inhabitant Rendering)
> -World Rendering (take the map and visible polys info and draw a 
> picture of the map - walls, floors & ceilings, liquids...)
> -Inhabitant Rendering (deals with any and all inhabitants of the map. 
> Anything that isn't a wall (or a bridge, balcony, or ramp?) goes 
> through here. May be physically subdivided (function names, different 
> source files) into sections for monsters, player, objects, scenery, 
> projectiles...)
> -Effects (fades, warps, other things applied to the whole screen at 
> once)
>
> Main Game:
> -Game Core (take the state of the world, add in what happened this 
> tick, figure out the new state of the world. Basically just calls a 
> lot of sub-modules.)
> -Physics (NOT definitions of player, monsters, weapons, etc. This 
> module actually deals with *physics* - an object is at point A and it 
> wants to move in vector V, make it happen. Includes projectiles, 
> monsters, player, anything else.)
> -Input (What does the player want to do? Also get info from networked 
> players via networking. This all gets handed to game core which 
> figures out what to do. Has sub-modules for platforms and input 
> devices (e.g., what's the difference between a joystick and a mouse in 
> gameplay? You should be able to drastically change one's behavior but 
> not the other by modules, if not by GUI.))
> -Networking (gathering, joining, synchronizing, exchanging information 
> about what each player does)
> -Player management stuff (handles player GUI, health, oxy, powerups, 
> inventory...damage?)
> -Weapons (projectile handling, ammunition management; damage?)
> -Monster AI
> -Monsters (catch whatever's left that affects monsters. "owner" of all 
> monster objects, activation, damage?)
>
> (Note that not all of these need be full replaceable modules; some of 
> them only appear here to indicate they should *NOT* be part of other, 
> related modules.)
>
> I've probably missed a few ;)
>
> Joe Auricchio ~ av...@fm...

But you have the most thorough rundown so far. And for that I certainly 
thank you. :)

-Jeremy Parsons