Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SethCreiyd]

Demo .006 download - http://www.mediafire.com/?98p3xbfezbppok7

Spoiler: changes (click to show/hide)

.006

- Fixed assorted display issues
- Enabled default player name, looser syntax in options.txt
- Made the .txt file loading function more flexible
- Moved more player/item-only methods and attributes to more general focus
- Replaced AI classes with state-controlled AI base class (still entity component)
- General take_turn function added to entities
- Exported some map-related objects to maps.py
- - render functions to render.py
- - various functions / base classes to slib.py
- - projectile oriented stuff to projectile.py
- Removed Skill class, skills are now stored as an entity-level dictionary
- Item components removed, Item class altered
- Lots of other internal changes to code

Mission Briefing:  Coming Soon

Spoiler: Screenshots (click to show/hide)

Spoiler: OP text (click to show/hide)

Greetings Bay 12, and well wishes to all.  I figured on announcing this project here earlier rather than later, since I'd like an informal place to store links and thoughts for it, and though it's just in it's infancy, I hope and think it can grow quickly.

Site 17 is a survival horror roguelike-in-progress inspired by Nethack and DF, set in the SCP Universe.  You play the role of the last surviving member of Mobile Task Force Rho-8, sent in to investigate Foundation Site 17 after [REDACTED] caused the site to [REDACTED] which of course is likely to result in an XK-Class end-of-the-world scenario.  Details like how to save the world from [REDACTED] and why this is happening will be exposited in the briefing.

The game uses the libtcod library and is built from the tutorial engine seen here at Roguebasin, which provided a fun way to learn Python and develop a functional little roguelike at the same time.  This is hardly a game yet (if you try combat you'll see what I mean), and no actual SCPs are in there yet. 

Hordes of maddened SCP staff will be easier to wade through when firearms are in, at least until they carry guns too.  I'd like to try and include an actual SCP before the next demo release.  Tonight saw persistent dungeon levels implemented, but it currently needs skill tracking, equipment, repopulate methods, combat formulas and a speed/timing system.  I'll be working on these in whichever order I figure them out.

Jotaf's engine is pretty flexible and it's easy to switch around object components, which is good for all the SCPs that mutate people.  Setting up a system for player equipment seems to me like the next proper step, but I'm not a very experienced programmer and would appreciate the counsel of my betters if I suggest or do something dull or half-witted.

Anyway, I recently figured out how to neatly compile the scripts, so please feel free to check out the demo posted up top!  The source is included, the program is totally open-source and everyone here is welcome to it, though I would like to reserve the position of Editor-Tyrant for Life over the official build.  Also, there are a couple BSD licenses involved in the source, so please keep the license files along with any redistributions you make.

Thanks for reading, and watch out for 173.

[Deon]

Fun thing is that I use the same tutorial right now (if only to learn how to properly build a roguelike, I plan to write it on C#).

Good luck with your project!

[penguinofhonor]

SCP-788 is a mandatory inclusion.

[SethCreiyd]

Fun thing is that I use the same tutorial right now (if only to learn how to properly build a roguelike, I plan to write it on C#).

Good luck with your project!

Thanks Deon, and good luck with yours too!  It's a great tutorial, maybe a little incomplete but more than enough to get one started.

It's funny, RL-development seems like a natural next step from DF modding, doesn't it? 

SCP-788 is a mandatory inclusion.

Yep, magma carp could be done, if for no other reason than it being a good excuse to implement molten lead.  It would probably need a unique level, however.  788 and its offspring should probably still be in containment, at least when you get to it.  It might make an interesting 'water' monster like the Kraken of Nethack, or as some other sort of obstacle to overcome.

Anyway, here's the download link for demo .002 - http://www.mediafire.com/?wdw52xxwm7ynp30

Spoiler: changelog (click to show/hide)

- added proper splash / loading screen with character generation
- implemented random stat generation
- implemented base for character stat checking (press 'c' in game)
- implemented system for equipping and unequipping weapons
- implemented projectile firing system (paths with libtcod bresenham's algorithm)
- updated combat calculations (rolls to hit, rolls to dodge, rolls to dodge bullets)
- changed console info display and made combat logs more interesting
- added basic system for tracking damage types, weaknesses and resistances
- shifted global inventory variable to object class, so NPCs can have inventory
- improved monster pathfinding using A*
- improved grenade functionality
- put first status effect (confusion) into the game
- added player genders
- SCP-732 added

Message text is improved, and there's a real pathfinding system in place now (using libtcod's A* method).  The system is very clunky and needs fine-tuning, but it's an improvement over the previous version.

Character stats (and NPC stats) are now randomly generated.   The character attribute set is similar to Nethack, though the way HP is calculated is still rudimentary.
I wanted to take a lot of the flat numbers out of the player experience - the numbers are there for calculations, but they're printed in-game as strings.
Health shows up as 'Excellent' for full HP and 'Awful' or 'Terrible' when near death.

The player also starts with a random inventory, this is pretty limited for the moment since there are so few items.  Like Nethack, any item can be wielded as a weapon, though for most items this is less effective than unarmed combat (weapon skills are not yet implemented).  Guns can be fired and reloaded properly, and there's a test system in place for equipping clothing/armor, but no appropriate items are in yet.

The game now properly accepts close window requests.  The command window (it shows up only when you run the .py script, not the .exe) is there to print debug info and can be safely ignored if it's not of interest.

Also, as promised, I added the first SCP to the game.  See if you can spot it in the code.  Or you could look in the changelog, but that's cheating.

Combat is still very unbalanced, but there are still pieces yet to be added to the mechanics.  Suggestions are more than welcome!

[Armok]

Add a system that tracks body parts individually, as well as souls, and abilities, for usage with all those scp that modifies those things. A "body" object doesn't store the stats, it's just a container for the body parts which have stats or abilities plus a soul to control them. Most equipment would be to body parts again, wich a few exeptions of large whole body clothing.

To test this add in scp-291.

[SethCreiyd]

This seems a wise course, mighty Armok.  The earlier that stuff gets added the easier it'll be to add.  There's 217 and 212 to consider too, which could test different aspects of the system.  I've a few ideas on how to proceed.

Right now, the Player is itself an instance of the Object class, serving as the 'body,' containing display character, color and map coordinates, and other physical properties of game objects.  Animate beings have an Entity component class that currently contains attributes, hp and other traits subjective to living creatures, but this early on it should be easy to split the Mind and Body attributes more accordingly.

Some current properties like HP should probably get shifted to the Object itself (that way, in the example of HP, doors, chests, computers and the like could be easily damaged and destroyed, items could use the values as durability, etc).

As for individual body parts, I'm thinking about a dictionary attached to the Object.  The default would be a simple indeterminate 'body' value, for items and basic objects, but for creatures, each key in the dictionary could hold a list of lists corresponding to various parts.

Each spawned creature object should have a default body_type variable corresponding to a key from the body dictionary.  The creature's body parts would then be assembled accordingly.  To transform a body part's shape, material, or other qualities, you could modify the data in the appropriate index.  Mind switching with 291 or even 963 might be done by dumping the transferred entities into temporary 'spirit' objects, and then writing those to their respective destination bodies.  This may allow for disembodied minds and mindless bodies, should the transfer be somehow interrupted.

There's a rudimentary material system already in place, which was intended for the Clockworks, but it's limited to a few metals right now.  Making the SCP will involve separate dungeon branches, security doors and unique dungeon levels, which are murkier waters for me.  Drawing the unique level in ASCII and loading it from that seems like the common practice for it.  Much of this will be a marked step out of the comfort zone, but that's probably half the reason I'm doing this in the first place, so I appreciate the encouragement.


Edit:  Here's what a level for 291 might look like:

Code: [Select]

# S=player start, R=rubble, #=wall, .=floor, 0=coffin, |=security door, [=card reader,
# :=lockers, ?=door control tiles, A=aperture, \=lever, C=computer, B=button panel,
# &=impassable door, +=regular door, n=container spawn location, $=sign, W=window
    map_291=[
        '################################################################################',
        '################################################################################',
        '################################################################################',
        '####RRR#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '####...#########################################################################',
        '###[...#########################################################################',
        '####|||#########################################################################',
        '###[...+.................................................................SAR####',
        '####...###############+#######################################+#################',
        '####...###############R##################################R.................R####',
        '####...#########################################################################',
        '####...+.................................................................#######',
        '####...+.................................................................#######',
        '####...#............########################################.............#######',
        '####...W............########################################.............#######',
        '####...#............+....:##################################.............#######',
        '####...#............########################################.............#######',
        '####...#............##B0####################################.............#######',
        '####...#............|?..D#####################::::::::::::##.............#######',
        '####...#............|?..D#####################.............|.............#######',
        '####...#............|?..D#####################.............|.............#######',
        '####...#............|?..D#####################.............|.............#######',
        '####...#............|?..D#####################::::::::::::##.............#######',
        '####...#............##::####################################.............#######',
        '####...#............##################################:....+.............#######',
        '####...#............########################################.............#######',
        '####...W............########################################.............#######',
        '####...#............########################################.............#######',
        '####...#.................................................................#######',
        '####...#.................................................................#######',
        '####...+.................................................................#######',
        '####...+.................................................................#######',
        '####...########+#####################+#################################..#######',
        '####...####n.......n.n#############.....###############################..#######',
        '####RRR####.n.n.n.n.n.#############/....###############################..#######',
        '#######################################################################..#######',
        '#######################################################################..#######',
        '#######################################################################..#######',
        '#######################################################################..#######',
        '#######################################################################..#######',
        '#######################################################################..#######',
        '#######################################################################RR#######',
        '################################################################################',
        ]
What I'm wondering at the moment is how you're supposed to get living things inside the coffin to begin with.  Maybe allowing creatures to get knocked unconscious, and letting the body get carried as an item until it wakes up?  Aside from nefarious purposes, that could be used to drag wounded allies out of harm's way or something like that.

[Dariush]

Nifty game. Please make scrolling begin faster and make walls stay in 'memory' after they leave the line of sight.

Also, I died, pressed something, restarted at the title screen, pressed any key, typed in a name (but didn't select a gender) and ended with N/A health back where I died.

Also, cancelling a firing action still triggers a firing animation.

[Armok]

surface behaviour looks good as you describe, but it can probably be implemented more flexibly and deeply by having a simple "parts" class, and the "object" class (with should probably have a more descriptive name, like "World Feature") is simply a list of parts, with pointers to specific objects designating them responsibility for attributes rather than directly containing the attributes, and an "agent" flag for things that can move in any gaol directed way with a pointer to a "mind" class member in one of the parts. For internal organs, as well as for containers, you may simply have parts have a list of other parts contained, recursively.

For example, a human would be a "world feature" containing upper body, lower body, arms, legs, head, hands, feet, facial features, etc. each with a chain of "attached to" relation pointers from every body part to the upper body, clothes items with the "equipped on" relation to the relevant body part, the backpack contain objects the same way body parts contains various organs, including a brain organ which is attached to a soul. The world feature has the agent flag turned on, links "locomotion" to the legs, "mind" to the soul linked from the brain, and "attack" to relevant weapon or limbs, but has otherwise no recognition of being human, which is instead determined on a case by case basis by looking at the body parts.

A bed would be a much simpler world feature, with maybe just "bed"(actually just from and legs), "mattress", "pillow" and "blanket", with simple "rests on" relations. If you walk on top of the same time there are still two separate world feature objects, but if you lay down in the bed they are merged, the upper body gains a "rests on" relation to the mattress, and the "locomotion" link is linked to the bed part instead of the legs to render you immobile. If you were to lay on the floor, the only change would be to move that link to the upper body, wich'd presumably have low locomotion stats. If you were to pick up the bed instead of laying down on it, the only change is how the merging is done: the arms gain a grapple relation to the bed, and nothing else is changed.

a desk and chair with a computer on it may also be a single world feature. it'd have parts such as "monitor", "computer tower" and "keyboard". In this setup most objects would have "rests on" relations with the desk and "wired connection" with the tower and power outlet. The computer would also have a "mind" link, but it'd be to the OS instead of to a "soul", wich makes things act intuitively if something mind get overwrite with the contents of the computer or (wich has much more precedednt in the SCP verse, a lot in fact) somones soul gets stuck in the computer.

A door might be tracked down to doorframe, door, handle, lock, and key, all of which fill functions in changing it's condition between open and closed and which may take damage.

Got a bit caried away there. It should be easeier to implementthan my ramblings make it sound thou, since I suck at comunicating and resort to bad examples. If it isnt easeier than it sound I've misjuged somehting or you're doiing it differently than I meant.

[SethCreiyd]

Demo .003 download - http://www.mediafire.com/?pigv496fx2ij2j3

Spoiler: changelog (click to show/hide)

.003
- fixed combat string display error when attacked while wielding weapon
- save removal system set up for dead characters
- raised brightness of walls hidden by fog of war
- added basic system for tracking individual body parts
- cancelling a target for guns no longer causes the gun to fire
- changed default font from TCOD format to standard ASCII
- fixed fullscreen toggle for menus and non-main gameplay modes

Nifty game. Please make scrolling begin faster and make walls stay in 'memory' after they leave the line of sight.

Also, I died, pressed something, restarted at the title screen, pressed any key, typed in a name (but didn't select a gender) and ended with N/A health back where I died.

Also, cancelling a firing action still triggers a firing animation.

Thanks for trying it out!  I addressed most of those issues.  There wasn't a method for save cleanup after you died, so it would load dead characters if the name was the same, but that's fixed now.

By scrolling beginning faster, you mean text scrolling, right?  I know what you mean, but I had a bit of trouble getting the console to work intelligently without crashing after a few dozen lines.  Once I figure it out, I'll touch back it.

-snip-

This is delicious food for thought, thank you (I think I understood all that).  I ended up going with a Parts class after all, since without it there would be a lot more trouble referencing specific parts.  Right now, individual bodies are assembled with a list of parts and attached to any spawning instance to which it is defined.

Objects (or World Features, if you prefer) are already kind of set up for the kind of conversions you suggest, since it is such a huge part of SCP business.  An early implementation of this was the act of turning monsters into corpses - instead of removing the monster and generating a corpse item, it just switches the creature itself, by clearing the Entity/Soul class, slapping on an Item component, and changing a few base attributes like the name and display character.

The Parts of bodies are set up in the same sense in that they're totally mutable and yet unique to every instance.  The Parts are stored in essentially the same manner as items are stored in an inventory.  The current loose 'inventory' attribute shouldn't be difficult to shift into actual container instances, and AI/player control can be swapped to various instances with little trouble because they all have the same base Class.  If I'm missing something or not getting what you meant, please let me know.

Here's how the Part system works for now:

Code: (The Part class itself:) [Select]

class Part:
    def __init__(self, bp_name, bp_token, bp_connector, bp_container, bp_position, bp_type, bp_outer_matlayer, bp_inner_matlayer, bp_senses, bp_size, bp_side, bp_number, bp_bone=None):
        self.bp_name = bp_name    # Display name of the body part
        self.bp_token = bp_token    # Used to identify homologous body parts for connection
        self.bp_connector = bp_connector    # Token of the part that this part is connected to
        self.bp_container = bp_container    # This part is placed inside every present part with this type
        self.bp_position = bp_position    # Internal or External.  True is Internal, False is External
        self.bp_type = bp_type    # List of strings with various properties, also used for container placing
        self.bp_outer_matlayer = bp_outer_matlayer    # Surface tissue material of the part
        self.bp_inner_matlayer = bp_inner_matlayer    # Interior tissue material
        self.bp_size = bp_size    # relative size of body part, nominally in cm^3
        self.bp_side = bp_side    # constant UP, DOWN, LEFT or RIGHT, or None
        self.bp_number = bp_number    # The number of body parts to generate (will be numbered)
        self.bp_bone = bp_bone    # List containing [(bone_name),(broken_status),(bone_material)], or None

Code: (Example body part definition) [Select]

BP_TORSO = Part('torso','UB',None,None,BP_EXTERNAL,['BODY'],'skin','muscle',40,None,1,None)

Code: (Normal humanoid body set) [Select]

BPS_HUMANOID_NORMAL = [BP_TORSO, BP_HEAD, BP_SKULL, BP_BRAIN, BP_ARM_LEFT, BP_HAND_LEFT, BP_ARM_RIGHT, BP_HAND_RIGHT, BP_LEG_LEFT, BP_FOOT_LEFT, BP_LEG_RIGHT, BP_FOOT_RIGHT]
It's still pretty limited -- there are just enough body parts added to test the system out before going further with it.  Simple material definitions will eventually replace the strings, which are really for show at the moment.  Here's how it looks in debugging:

Spoiler (click to show/hide)

It isn't much for now and it's pretty clunky, but it's got room to grow.  I'm not sure if I should finish more body part definitions first, or some other related stuff like clothing/equipment and weapon wielding.  Parts will probably need a few more attributes to determine their condition - it only checks bone breaks for now, but it should probably keep track of local damage and destroy/sever a part that gets too mangled.


Edit: If it's alright, I'd like to place the following in the OP:

Credits and Special Thanks:

Armok - body parts tracking ideas and suggestions
Dariush - early playtesting

[Springare]

Download: ... Completed.
Executing Site17.exe: ... Completed.
Char-Gen: ... Completed.

Mind-log of Player:
"Oh nice, a blue ! I will take that. Ah, a bottle of water, thats nice, you never know when you need some cool, fresh water.
Hm, a white @ walking in my direction, let's check him: 'Researcher'. Hey buddy, whats u...
Level 1 Researcher bites You!
You die...
Nice "

That's the spirit. I am currently working on a Ninja RL based on the pyhton+libtcod-tutorial you are using, so I'm very interested on the development of your work. You know, to see how other people using the "engine" to create some magic.

Will try to survive longer than posting some more feedback.

Here are somethings:
- After I died I press [Esc] and the game closes, maybe return to mainmenu?
- I survived the first attack of a researcher, but missed all my attacks. (Next encounter kills the researcher fairly quick)
- Trying to go upstairs on the first level, warning appears, random-button-smash brings me to a new level.
- Did an extra test on melee, after 'training' up 3 researchers they took like 60 turns to kill me

[Armok]

Wow, it looks like you actually *DID* understand what I were trying to say. Nobody ever understand what I mean by anything. You must be some kind of world elite incoherent-ramblings decryption expert! ^_^

Working fast to, and in general extending expectations. This looks like it might be truely great.

few random nitpicks/questions/clarifications/things to remmeber:
- I were mainly sigesting any name other than object since it's easy to confuse with the standard name for an instance of any class, it also being object.
- Why is "bp_token"s not just another tag in bp-type
- It's a good idea to keep in mind that the system is supposed to support things that are not bodies in the conventional sense, such as furniture and devices, so it's better to use very general solutions than ones to specific to creatures.
- bp_connector should probably be a list, to allow parts to be connected to multiple other ones, and it may also be a good idea to have most types of connections be two-way so they can easily be folloed both "downstream" and "upstream".
- prefixing all the properties with _bp seems redundant. But you may have a reason for it I haven't though of.
- any reason  bp_container uses "every present part with this type", rather than the ID of a specific one? Seems like it may easily make bugfixing hell in the long run.
- bp_position: what'd an eye count as here? Might be a good idea to have an intermediate "embedded" value as well here like DF, or even make it a continuum.
- bp_side: not sure what this is usead fgor, but it seems strange it's missing "FORWARDS" and "BACK" values
- bp_number: seems like a much better idea just to have many separate Parts represented individualy. The preformance gain dosnt matter, and this is another thing thatd make bugs from hell.
- bp_bone: any specific reason not to do the same for all bones as with the skull?
- remember that computing power is cheap, especially for something graphics-light and turn based like this. You can easily have hundreds of parts per humanoids each with temperature and blood presure and all sorts of calculations on each every turn, and still have the path-finding be much more performance limiting.


@what to do next: maybe get doors and storage containers to work with the parts system? A crate that needs smashing open, a locker with boxes on the shelves with their own lids that can be taken of withote picking them up out of the locker, a locked door requiring a key, a voice activated bulkhead that will open more slowly and then not at all if you damage the actuator... that should get you started on a whole bunch of systems.

EDIT:

One thing you could and should do eventualy is to not have "death" be a binary state change, but statistical have varius tissues and organs lose functionality from oxygen deprivation. The game wouldnt differentiate beten a dead body and an unconscious one with necrosis. Game Over message would presumably be linked to some  more complex conditional about a certain time passing without regaining conciousness after brain damage has reached a certain level.

It might be a good idea to have a standard "press F1 to get list of hotkeys/help file" functionality.

[Person]

How do you actually use grenades?

[alfie275]

It'd be cool to have parts attachable with generic "actions", eg:


A "string" item that when moved propgates a "pull" action to the other end.
Also a grenade which when the pin receives a "pull" action and the handle is NOT receiving a "push" action becomes armed.
With this you could tie one end to a door handle, and have the other end tied to the pin of a grenade to make a trap.

Using a generic action system any newly defined interactions (eg using "push" on button to activate it) is compatible with previously defined interactions (eg, a thrown object sends "push" to an object it hits).

[SethCreiyd]

Demo .004 d/l - http://www.mediafire.com/?lgbif771noba1uf

Spoiler: changes (click to show/hide)

- added system for stacking appropriate items
- migrated physical character attributes away from Entity component
- upgraded reload function, no longer wastes ammo
- clip size is now attached to guns, persist when gun is dropped
- added "loud noise" system where certain actions (like gun play) can generate sound
- basic monsters will investigate sources of sound
- bullets no longer hit corpses they aren't aimed at
- added character classes to character generation
- added Skill class for entities and skill generation for players
- updated/fixed various combat calculations and tied entity combat actions to skills

Most of these changes should be self-identifying.  I'm starting to see how feature creep works:  At first I'd intended to create a locker object with a lock, door and container parts, but to test it out required a lockpick, which required a lockpicking skill, which required skills in general, and after making skills it seemed like a good thing to apply them to combat, so that was done.  Haven't even started making the locker yet. 

Item stacking and gun changes both needed doing, and doing them earlier makes things a bit smoother.  To check your skills you can press Tab, and skills will increase with use ala DF and TES.  If an item lacks an associated weapon skill, it defaults to the 'Improvised' weapon skill.  The skills are attached to the Entity class, so they'll carry over if you end up switching bodies with something.

It'd be cool to have parts attachable with generic "actions", eg:


A "string" item that when moved propgates a "pull" action to the other end.
Also a grenade which when the pin receives a "pull" action and the handle is NOT receiving a "push" action becomes armed.
With this you could tie one end to a door handle, and have the other end tied to the pin of a grenade to make a trap.

Using a generic action system any newly defined interactions (eg using "push" on button to activate it) is compatible with previously defined interactions (eg, a thrown object sends "push" to an object it hits).

Interesting idea.  A 'strand' attribute would help with this.  Say there's a basic #tie action in the game, in theory you could #tie a knot on any part of an object, using a 'strand' part of an item object.  There's already a 'size' attribute for parts, which could be used to keep track of the length of a given strand - you could feasibly cut strands in half with the appropriate tool - get two new objects with the same properties as the old, with half the length.

The Push/Pull actions could be achieved by a very generic 'force' measuring system I was musing as a way to determine damage to parts from attacks and other impacts.  The force would be a value, negative or positive (negative would be pull, positive push), which gets passed to various forms of interaction.

Take a pressure plate on the floor - with every step, a player/monster applies an amount of force equal to its mass to the tile below it.  If the force applied >= force required to fire the plate, it goes off.  Propelling objects away would be done by applying force and comparing it to the mass of the object, away from the source of the force - or towards it, with negative force, like if a black hole opens or something.

How do you actually use grenades?

Right now, you select them from your inventory and click the spot you want to throw to.  Eventually there will be a dedicated system for throwing items, but I'm holding off until the parts system is further along (the way glass objects break in Nethack, there should be a way of checking for delicate parts in thrown objects and applying damage to them).  Ideally, in the end you'll throw them with (t), and then they'll sit on the tile where they land for a moment before they blow up.

Wow, it looks like you actually *DID* understand what I were trying to say. Nobody ever understand what I mean by anything. You must be some kind of world elite incoherent-ramblings decryption expert! ^_^

Working fast to, and in general extending expectations. This looks like it might be truely great.

few random nitpicks/questions/clarifications/things to remmeber:
- I were mainly sigesting any name other than object since it's easy to confuse with the standard name for an instance of any class, it also being object.
- Why is "bp_token"s not just another tag in bp-type
- It's a good idea to keep in mind that the system is supposed to support things that are not bodies in the conventional sense, such as furniture and devices, so it's better to use very general solutions than ones to specific to creatures.
- bp_connector should probably be a list, to allow parts to be connected to multiple other ones, and it may also be a good idea to have most types of connections be two-way so they can easily be folloed both "downstream" and "upstream".
- prefixing all the properties with _bp seems redundant. But you may have a reason for it I haven't though of.
- any reason  bp_container uses "every present part with this type", rather than the ID of a specific one? Seems like it may easily make bugfixing hell in the long run.
- bp_position: what'd an eye count as here? Might be a good idea to have an intermediate "embedded" value as well here like DF, or even make it a continuum.
- bp_side: not sure what this is usead fgor, but it seems strange it's missing "FORWARDS" and "BACK" values
- bp_number: seems like a much better idea just to have many separate Parts represented individualy. The preformance gain dosnt matter, and this is another thing thatd make bugs from hell.
- bp_bone: any specific reason not to do the same for all bones as with the skull?
- remember that computing power is cheap, especially for something graphics-light and turn based like this. You can easily have hundreds of parts per humanoids each with temperature and blood presure and all sorts of calculations on each every turn, and still have the path-finding be much more performance limiting.

Thanks Armok.  It wouldn't be too hard to rename since there isn't that much that calls on the Class by name, I just don't know what I'd prefer to call it.

About the Part class:

Spoiler (click to show/hide)

- bp_token is separate by preference more than necessity.  I like them separate.
- I'll try to keep them as general as possible at their base, the multitude of creature specific values is in consequence to the large number of creature parts.  'BP' is just a way to remember that the value is associated with the Parts system, but yeah, it's probably redundant in function.
- _connector could work as a list, but it's easy for now to track the mutual connection with one token value.  The first 'Shift-v' window showed all the parts connecting and connected by switching which part was looking at which connection (if that makes sense - basically, torso displayed 'head, left arm, right arm, left leg...' without any trouble.  It's set up to accommodate things like fingers and part hierarchies - each finger would read as connected to the hand.
- _container does that so that something like a two headed giant would get two skulls and two brains, one for each head.  It would be linked to a function that generates a new Part for the number required to fill every container.  Since different heads would have different tokens, it seems the easiest way to achieve this.
- Position would be external for eyes, since they can be hit from the outside.  Mouth is external, but tongue would be internal, contained by the mouth.  An 'embedded' value sounds like a good idea.
- side may or may not be very useful.  Really it takes any integer, not just LEFT or RIGHT.  There are constants for other directions too, so it could be UP, DOWN, FRONT or BACK too.  Might use this for head hair.
- _number is becoming less and less necessary as the system takes form, so I completely agree here.  The index could probably better serve as a damage counter for the part.  A damage handling system could analyze the part and inflict various state changes on it based on what kind of part it is.

@what to do next: maybe get doors and storage containers to work with the parts system? A crate that needs smashing open, a locker with boxes on the shelves with their own lids that can be taken of withote picking them up out of the locker, a locked door requiring a key, a voice activated bulkhead that will open more slowly and then not at all if you damage the actuator... that should get you started on a whole bunch of systems.

EDIT:

One thing you could and should do eventualy is to not have "death" be a binary state change, but statistical have varius tissues and organs lose functionality from oxygen deprivation. The game wouldnt differentiate beten a dead body and an unconscious one with necrosis. Game Over message would presumably be linked to some  more complex conditional about a certain time passing without regaining conciousness after brain damage has reached a certain level.

It might be a good idea to have a standard "press F1 to get list of hotkeys/help file" functionality.

I'm going to work on the locker next, throwing, kicking, and the force system I mentioned earlier.  Then it can all be tested by finding a locker and kicking, shooting and throwing grenades at it until it breaks.

I'm all for blurring the line between life and death a little, but tracking oxygen dependence for individual organs is probably a bit beyond the scope.  I'd rather blood loss/suffocation/decapitation be the usual modes of player death, not counting instances of blowing apart or getting crushed/vaporized/eaten or whathave you.

Actually, if you get eaten alive, you should probably linger a while in Nethack-style engulfing, with a chance to blast or cut your way out, Tommy Lee Jones style.  But that's for later.

Download: ... Completed.
Executing Site17.exe: ... Completed.
Char-Gen: ... Completed.

Mind-log of Player:
"Oh nice, a blue ! I will take that. Ah, a bottle of water, thats nice, you never know when you need some cool, fresh water.
Hm, a white @ walking in my direction, let's check him: 'Researcher'. Hey buddy, whats u...
Level 1 Researcher bites You!
You die...
Nice "

That's the spirit. I am currently working on a Ninja RL based on the pyhton+libtcod-tutorial you are using, so I'm very interested on the development of your work. You know, to see how other people using the "engine" to create some magic.

Will try to survive longer than posting some more feedback.

Here are somethings:
- After I died I press [Esc] and the game closes, maybe return to mainmenu?
- I survived the first attack of a researcher, but missed all my attacks. (Next encounter kills the researcher fairly quick)
- Trying to go upstairs on the first level, warning appears, random-button-smash brings me to a new level.
- Did an extra test on melee, after 'training' up 3 researchers they took like 60 turns to kill me

Thanks for trying it out, and for the feedback - good luck with the Ninja game.    I didn't get around to adding a game exit for retreating upstairs, so it's basically a Minus World.  Eventually it should give a Game Over and a High Score screen.  Combat is still taking shape, but it's more balanced now that skills are involved and a few errors are fixed.

[penguinofhonor]

Getting eaten? SCP-835 incoming.