Print

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

[DrPoo]

Sounds interesting. Posting to follow but i am going on vacation.

[SeriousConcentrate]

Also posting to watch.

[Armok]

The actions and force systems are GREAT ideas.
Idea: things like controlling hands and hearing sounds could be transferred actions, to enable things like remote controlled robots (the foundation has been known to use those for exploration I think? would be neat) or telephones, or security cameras, to mention mundane examples...

Do you mean stacking as in tracking many similar objects as one, or as in "rests on" connections between parts?

@bullets not hitting corpses: This should probably be handled by not hitting *prone* bodies, and a system for falling over when no mind is specifically sending balance signals, which implies a poseing system and a travel height for bullets...

Not sure if I like the idea of character classes in something like this, but it's not a *technical* objection, just taste. Same thing for "skills" as usualy implemented in RPGs with ridiculously fast learning granted mainly as a reward for killing things.

skill related idea: for each skill, have several components: theoretical, experience, and motor. Theoretical you get from reading and takes  very long time, experience you get from actually doing the thing, and you get more the closer you were to failing/succeeding but didn't. Motor skills you have with specific Parts. Your skill with your brain, your hand, and your tool (and the computer system and the robot if you are doing something remotely) multiplied is the motor skill for things like picking a lock or using a weapon, for a task like programming the software might be used instead, for social actions the person you are communicating with, and so on. It is gained by interacting in any way with the Part in question, and especially so by a specialized practice action. Of, and it can never be greater than 1 just approaching it with diminishing returns. For part of your body, it should probably not be presented to the player as distict from the properties like strength and precision that are also trained by use. To get success and failure you can just multiply everything relevant together, maybe with a constant added to a few that might otherwise be zero.
... ouch, another pile of ramblings from me, hope it's comprehensible.

As for name, I already suggested "world actor". "creature" is also a candidate although it's a bit strange to call doors and grenades creatures.

Sounds like you have the parts class under control.

@tracing oxygen dependence being to deep: Not so for a very simple version of it. Just have a tag on parts that have blood/require oxygen. Have the heart emit "circulation" and the lungs "oxygen", each turn parts get the average circulation of what all their connections, contained parts, and containers had last turns, subtract their size, and if they have enough circulation do the same thing with oxygen. The computing power is negligible, and coding it once for usage on al body parts is probably less work than tracking it on the creature level. And it doesn't change what are usual modes of player death, or how it needs to be presented, just how smoothly they are tracked and how well it handles unforeseen situations with them, which is always the most fun kind of situation.

[alfie275]

Hmm, it'd be cool if you could wield assemblies of objects, and be able to define the default action if there are multiple possible.

Eg if I attach two shotguns together (with their triggers attached to each other) the default actions are the same, being to "pull" the trigger. But if I attach a chainsaw a chainsaw to a shotgun, the default action may be to toggle power to the chainsaw for the chainsaw (I know that in this case, you can probably work it out based on the type of attack you're doing and the normal default action, but there may be more complex cases).

[Armok]

when faced with that kind of concept, the proper way of thinking is "why is this not done in real life?".

[Person]

The demo link throws up an invalid or deleted file error. Might wanna fix that.

[Armok]

Suddenly realized this was python so I could check the source code to help you out more, so I did that...

I'm not sure what to think. The mess is HORRIFYING in some places, and I'm not sure if it's salvageable. It's a feat of amazing heroism you've gotten so much done, but I worry you might have to scrap the majority of the code and start over almost from scratch. The tutorials made a lot of things in ways that just don't work for this type of project, and that seem to be the whole source of the problems, YOU didn't know anything wrong. You realy hd some bad luck in stubling over that thing.

Checking over the tutorials, there doesn't seem to be any of them that dosnt introduce something that, at least for this project, counts as a critical flaw. This is just my opinion thou, this is your project. Skimming your code, here is my advised coarse of action, based on what I know of what is usualy cosidered good coding practices:

Spoiler (click to show/hide)

Put some of the global variables in all-caps at the start into a class of some kind.

Throw out the tile and object classes, and redo them from scratch this time based of Parts from the very beginning. Maybe make an "Assembly" class, and use inheritance on it adding ONLY position (self.x and self.y, ONLY) to "LoseObject"s and ONLY blocked and block_sight to "Tile"s. All the other properties of the curent "object" class that are kept would be in the new Assembly class to be inherited by both. You could easily have a function to convert lose objects to tiles and vice versa as well, which might come in handy for a lot of things.

You're probably best of losing a LOT of the current creature functionality for the moment; health, stats, inventroy, pretty much everything combat related, even mass, gender, and age. Whats left is prety much the names and display tile, which are probably easier to re-code than try to salvage.

The AI code is a loss as well, and the movement code will nneed to be rewanped to work with the legs part being sent a direction wich they are to try to move and so on rather than the AI being alowed to change the position directly. Also, whoever made that tutorial was an ass to make you just through all those hoops with vectors when four if statements comparing X and Y coordinates and adding or subtracting 1 would do.

the bp_in front of Part properties confirmed redundant, you do have it in the names of all Part instances asready.

Item and Projectile classes need to be removed, they should just be LoseObjects

Prety much everything in the Entity class needs to go as well according to me, but that's more of a subjective taste. The whole thing with stats, levels, and XP is more an RPG thing than a survival horror thing. It, not the Lose Object, should also have any AI like functions such as moving or interacting, then once the parts system is implemented you can stop reading them as things done with telekinesis and instead reading them as intention for the responsible body part to respond to. The curent Attack function is sort of like this.

The Skill class is on of the few cases where *you* seem to have actually done something wrong. It' should probably just be a pert of Entity, with skills in a map so that custom and highly specific skills like "dealing with [specific person]" can be easily added just like any common one. Class systm I'd scrap, but if you want to keep it just have it give the skills directly from whaere the manue is rather than via this weird function.

Basic and Confused Monster obviusly need to be done away with.

The whole system of levels and their generation does not quite fit with a modern building style, as well as not being as scary as fearing to attract the entire 3d buildings worth of creepies, and theres no reason to not load the entire world at once on any remotely mmodern system wich will make it seem more alive (in fact, simulte it for a week of in game time before the game starts so stuff can happen!).

Modifying your level generation algorithm you be moree indors-y should be trivial; just chaneg the room making function to line the inside of each room with new walls rather than just flooring all the way to the edges, remove the check for colisions with previus rooms just leting them colide, and increase MAX_ROOMS to somehting like 300 or 1000 instead of 30.

The path map stuff is supringly well done, thats a keepers.

you should probably have some kind of master list of standard objects, parts, and tiles somewhere, wich some kind of hirarchy that lets you easily change lots of things at once towards higher complexity.

@bazilions of functions more: I'm stoping here for my sanitys sake.

My consonances.

... this is a lot of stuff and I'm starting to be involved a lot with it, do you have skype so we can chat about it and maybe I can help you out more directly?

[alfie275]

Looking through the code, I'd have to agree with Armok.

Generally a base class ought only to define properties that WILL be used, not that MIGHT be used. It is up to child classes to implement their own specific functionality (eg, not all Objects will have a gender).

Also don't be afraid to split the project into multiple files, so you'd have all your map stuff in one file, all the creature stuff in another etc.

Code refactoring is an inevitable thing, something that should be happening in an almost continuous cycle so that the code remains as good as you can make it.

[SethCreiyd]

demo .005 - http://www.mediafire.com/download.php?4f3w2kawudss6bs

Spoiler: changelog (click to show/hide)

- Implemented force application system for manipulating game objects
- Fixed display bugs with reloaded ammunition and thrown grenades
- Added item throwing and a quiver action to prepare items for throwing
- Added fuse/alarm system for triggered object actions throughout the game
- Reworked grenades and tied them to throwing, force and fuse systems
- Added general systems for filtering/sorting menu items
- (q)uaffing action added for drinkables
- Made certain player-only actions accessible to other entities
- Added external .txt config file
- Exported variables to bodyparts.py, constants.py and options.txt
- Changes to map, character and monster generation scripts
- Upgraded combat calculations

Fixed some things, added some other things.  I did start splitting the project up a bit, and throwing, grenades, force and fuses are all working as hoped for the moment.  Anything near an exploding frag grenade gets blown a fair distance in a random direction. 

It's crude, but it's drawn up by a measure of distance, force and object mass, and the throw/force functions are tied to one another - basically, enough force with make an object 'throw itself' and handle collisions as a projectile.  Didn't get to the locker yet, but I think next should be a simple door before reworking the construction and generation stuff, unless there's something specific anyone would suggest first.

Suddenly realized this was python so I could check the source code to help you out more, so I did that...

I'm not sure what to think. The mess is HORRIFYING in some places, and I'm not sure if it's salvageable. It's a feat of amazing heroism you've gotten so much done, but I worry you might have to scrap the majority of the code and start over almost from scratch. The tutorials made a lot of things in ways that just don't work for this type of project, and that seem to be the whole source of the problems, YOU didn't know anything wrong. You realy hd some bad luck in stubling over that thing.

Checking over the tutorials, there doesn't seem to be any of them that dosnt introduce something that, at least for this project, counts as a critical flaw. This is just my opinion thou, this is your project. Skimming your code, here is my advised coarse of action, based on what I know of what is usualy cosidered good coding practices:

Spoiler (click to show/hide)

Put some of the global variables in all-caps at the start into a class of some kind.

Throw out the tile and object classes, and redo them from scratch this time based of Parts from the very beginning. Maybe make an "Assembly" class, and use inheritance on it adding ONLY position (self.x and self.y, ONLY) to "LoseObject"s and ONLY blocked and block_sight to "Tile"s. All the other properties of the curent "object" class that are kept would be in the new Assembly class to be inherited by both. You could easily have a function to convert lose objects to tiles and vice versa as well, which might come in handy for a lot of things.

You're probably best of losing a LOT of the current creature functionality for the moment; health, stats, inventroy, pretty much everything combat related, even mass, gender, and age. Whats left is prety much the names and display tile, which are probably easier to re-code than try to salvage.

The AI code is a loss as well, and the movement code will nneed to be rewanped to work with the legs part being sent a direction wich they are to try to move and so on rather than the AI being alowed to change the position directly. Also, whoever made that tutorial was an ass to make you just through all those hoops with vectors when four if statements comparing X and Y coordinates and adding or subtracting 1 would do.

the bp_in front of Part properties confirmed redundant, you do have it in the names of all Part instances asready.

Item and Projectile classes need to be removed, they should just be LoseObjects

Prety much everything in the Entity class needs to go as well according to me, but that's more of a subjective taste. The whole thing with stats, levels, and XP is more an RPG thing than a survival horror thing. It, not the Lose Object, should also have any AI like functions such as moving or interacting, then once the parts system is implemented you can stop reading them as things done with telekinesis and instead reading them as intention for the responsible body part to respond to. The curent Attack function is sort of like this.

The Skill class is on of the few cases where *you* seem to have actually done something wrong. It' should probably just be a pert of Entity, with skills in a map so that custom and highly specific skills like "dealing with [specific person]" can be easily added just like any common one. Class systm I'd scrap, but if you want to keep it just have it give the skills directly from whaere the manue is rather than via this weird function.

Basic and Confused Monster obviusly need to be done away with.

The whole system of levels and their generation does not quite fit with a modern building style, as well as not being as scary as fearing to attract the entire 3d buildings worth of creepies, and theres no reason to not load the entire world at once on any remotely mmodern system wich will make it seem more alive (in fact, simulte it for a week of in game time before the game starts so stuff can happen!).

Modifying your level generation algorithm you be moree indors-y should be trivial; just chaneg the room making function to line the inside of each room with new walls rather than just flooring all the way to the edges, remove the check for colisions with previus rooms just leting them colide, and increase MAX_ROOMS to somehting like 300 or 1000 instead of 30.

The path map stuff is supringly well done, thats a keepers.

you should probably have some kind of master list of standard objects, parts, and tiles somewhere, wich some kind of hirarchy that lets you easily change lots of things at once towards higher complexity.

@bazilions of functions more: I'm stoping here for my sanitys sake.

My consonances.

... this is a lot of stuff and I'm starting to be involved a lot with it, do you have skype so we can chat about it and maybe I can help you out more directly?

Looking through the code, I'd have to agree with Armok.

Generally a base class ought only to define properties that WILL be used, not that MIGHT be used. It is up to child classes to implement their own specific functionality (eg, not all Objects will have a gender).

Also don't be afraid to split the project into multiple files, so you'd have all your map stuff in one file, all the creature stuff in another etc.

Code refactoring is an inevitable thing, something that should be happening in an almost continuous cycle so that the code remains as good as you can make it.

I figured it being a godawful mess, and I'm sure the inexperience shows.  I'm not afraid of re-working everything, since it seemed necessary as a matter of course, though I wouldn't doubt it's grown to a bit more horrifying a mess since this update  ^_^  But yeah, going into this I anticipated that it would have to be entirely reworked, probably more than once.  Stats, XP, levels are all but gone now.  ATM, Skills are incremented by practice alone, and they should raise slowly enough to warrant adopting different playstyles according to one's skillset (difference in physical combat effectiveness between a martial artist and most other classes is substantial).

A move to child classes (and changing all the current ones) seemed pretty necessary after learning what they were, and I agree on just about all the points made, though I'm not sure I get the level gen wall lining bit (although I did add a cheap wall-drawing function and allow room intersections before I saw the post, so it seems we're thinking on similar lines).  I'm very tired though, comprehension is duller than usual.

I don't understand why the Projectile / Item classes need to go, since they seem pretty useful in controlling specific behaviors - couldn't they be well-suited as a child of the 'object' class? (which ended up renamed to 'WorldObject').  Skill class does seem like a dud even to my newbie eyes, it's been a pain to work with (though I was pleased to get it sorted by skill level in the menu).  I do like character classes though, and the SCP world is ready with ranked positions and occupational titles, but the flaws and merits therin are worth discussing.

Thank you both for checking it out and all the advice, I appreciate it.  I don't have Skype, but I can PM my email if that works.  I have some further ideas/questions but I need some sleep before I can finish forming them.  If you happen to look at the updated code, I'd like to know about anything else I've done wrong - seems good to learn what not to do.  I'll try and split the code further too, though I've really just begun to learn to do that (really, all this) properly.

I do find this comforting though:

Code refactoring is an inevitable thing, something that should be happening in an almost continuous cycle so that the code remains as good as you can make it.

I've tried to keep a similar mindset, so it's a happy thing to see it posted by someone more knowledgeable than I.

The demo link throws up an invalid or deleted file error. Might wanna fix that.

Thanks, I'd forgotten to update it in the OP.

[Armok]

Havn't checked out the new version yet, probably will tomorrow, but from your descriptions it sounds like you've gotten pretty much everything right, and are doing FAR better than almost anyone in a similar situation. I foresee you becoming a True Hacker quickly at this rate.

And yea you're right about the item and projectile classes.

Seeing this has actually inspired me to start my own, similar project.

[Person]

Started as an Agent/Soldier and got to b-9. Eventually died from being overwhelmed with no ammo, and no space to throw grenades without hitting myself. Are emp grenades supposed to do damage to organics? It's not a significant amount, but it helps, especially with how common they are. Anyway, found a small bug. I was at low health, and threw a grenade a couple tiles too close, because I didn't know the range of the blast at the time. This brought me down to None health. I could still move, shoot, and melee, but shooting did nothing (or I was extremely unlucky and missed 14 times or so with no message). I eventually died to melee spam, but it took awhile because I could still dodge and block apparently. It's probably just a health display issue.

[SethCreiyd]

I uploaded .005b here to fix an embarrassingly bad way of removing a temp file created by a bad way of importing the options.txt.

Havn't checked out the new version yet, probably will tomorrow, but from your descriptions it sounds like you've gotten pretty much everything right, and are doing FAR better than almost anyone in a similar situation. I foresee you becoming a True Hacker quickly at this rate.

And yea you're right about the item and projectile classes.

Seeing this has actually inspired me to start my own, similar project.

Well, the actual move to class inheritance isn't there yet, so things are probably just as messy as before and the issues you pointed out are still applicable. I'm going to try moving the current classes into a new hierarchy and attach game objects to an assembler parent class like you described.  I think I can really start remodeling after getting a better handle on the way inheritance works.

Thanks again for the advice and encouragement.  Good luck with your project, throw me a link when you post it.

Started as an Agent/Soldier and got to b-9. Eventually died from being overwhelmed with no ammo, and no space to throw grenades without hitting myself. Are emp grenades supposed to do damage to organics? It's not a significant amount, but it helps, especially with how common they are. Anyway, found a small bug. I was at low health, and threw a grenade a couple tiles too close, because I didn't know the range of the blast at the time. This brought me down to None health. I could still move, shoot, and melee, but shooting did nothing (or I was extremely unlucky and missed 14 times or so with no message). I eventually died to melee spam, but it took awhile because I could still dodge and block apparently. It's probably just a health display issue.

Thanks for trying it out - the health bit's indeed a display issue.  I'll fix that for the next upload.  The emp grenades deal electric type damage, but nothing has weakness/resistances assigned yet.  Even so, it's much less forceful and damaging than a frag explosion.



edit:  Hope I'm doing this right.  I'm trying to get a Creature subclass to inherit from a WorldObject and declare its own unique attributes (such as gender, like alfie said), but if the unique attributes get passed to the __init__ of the parent class it doesn't know what to do with them, which made it hard to use * and ** arguments.  I didn't want to type out all the shared arguments over again like this tutorial shows, so I tried this out.

Code: [Select]

       
class Creature(WorldObject):
    def __init__(self, *args, **kwargs):
        kwd = kwargs

        # catch the arguments that superclass can't handle
        ilist = ['gender', 'profession1', 'profession2']
        for i in ilist:
            try:
                del kwargs[i]
            except KeyError:
                print 'No "'+i+'" in Creature keyword arguments'
        WorldObject.__init__(self, *args, **kwargs)
        self.gender = kwd.get('gender')    # defaults to none
        self.profession1 = kwd.get('profession1')
        self.profession2 = kwd.get('profession2')
It runs well, at least - the Character instances are created with the attributes, which are removed from the keywords before the superclass WorldObject is initialized, since they aren't recognized by it.  It's nicer on the eyes than re-typing the dozen or so shared arguments would be.

[Armok]

I'd suggest not having a creature class based of WorldObject, putting all those properties either in the Entity (for things like professions) or specific Parts (gender, if you dare, otherwise at least be consistent to really have it purely mental).

[alfie275]

I'd agree with Armok about the "aliveness" of an entity, particularly in the SCP world, is not binary or always fixed you probably should handle the distinction in a non-hardcoded way.

[SethCreiyd]

Demo .006 is here - 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

I'm too drained to get into this at the moment.  The code's in a state of flux, and there aren't very many visible changes in the game from last version, but the internal code is shifted around.  It'll be nice to finish this groundwork stuff so more content can go in.