Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of Gear #1763

Open
longtomjr opened this issue Jan 21, 2017 · 7 comments
Open

Implementation of Gear #1763

longtomjr opened this issue Jan 21, 2017 · 7 comments

Comments

@longtomjr
Copy link
Contributor

longtomjr commented Jan 21, 2017

This is open for discussion and will be edited. See original discussion #268

Functionality:

  • Need to be separate from the Character's inventory
  • Separate Class
    • Most traits defined in XML(/JSON) and LUA (LUA for funtionality)
  • Spacesuit: How do we do this?

What needs discussion:

  • Handling Spacesuits.
  • An object for Gear (the actual item) and an object for the gear slot, or have that built into the character object?
  • How to handle non equipped items?
  • How to implement "slots" for gear?
  • Multiple functionality for gear? (one item doing more than one thing)
@longtomjr
Copy link
Contributor Author

Notable Points

I think wearables should be special items to allow them to be placed in a stockpile or carried around (without being worn). - @NogginBops

  • We can implement this in a way similar to how gear work in rimworld.

This post might be edited to allow easier access to ease discussion

@koosemose
Copy link
Collaborator

One possible route to handle the "placeable in stockpile" aspect is similar to what I did for installable furniture, which is rather than having a near duplicate definition for the gear as inventory and as gear (or defining gear as sort of a subclass of inventory, or however else one might do it) is creating the inventory prototype in code, based off of the gear data. That way the "concept" of a spacesuit, for example, isn't split between two files.

@dusho
Copy link
Contributor

dusho commented Jan 22, 2017

Would propose to use component system again (what we have for furniture now). So Inventory with list of components and then implement WearableComponent class with properties needed to identify required slot for gear and then also gear stats and abilities. Dynamic attributes (e.g. damage) would be handled by Params (as is in Furniture as well). Probably code duplication can be saved if we would introduce class that can have components and Params and Furniture and Inventory would inherit from it.

Gear slots I would maybe place inside Species/Body what was discussed here #1528 .
So e.g. for space suit, in Species/Body identify body parts (with tag?) that need to be covered by spacesuit in order to survive open space. Then character state would be dependent on those parts (slots) having proper gear there (having space helm but no space pants -> still get killed in open space).

@koosemose
Copy link
Collaborator

koosemose commented Jan 22, 2017

Components

I think for some stuff at least components would be appropriate, but I also think there should be a baseline of things that can be affected by gear, because, while not all gear may affect the same things, there are also some things that require just a single number (like maybe damage resistance, or cooling, or some such) for which an entire component is perhaps overkill (for example having to cycle through all components to find the one that gives damage resistance).

Params and Common stats

And for common stats I would also prefer having an actual variable, simply because, as much as I like Params, for core code accessing things via a string keyed object is, of course, vulnerable to issues resulting from name changes and not catching all the instances (since you can't just use the rename function of your IDE).

Species/Bodypart

As far as involving the Species/Body part thing, I personally am not a fan of nonhumanoid crew, and aside from that think that, at least initially, gear should be developed preset to work for humanoids, simply because trying to implement it to cover multiple body shapes initially will lead to excess complication in creating it.

@dusho
Copy link
Contributor

dusho commented Jan 22, 2017

Not sure what you mean by multiple components.. Inventory would have just one component (if it's suppose to be gear) - WearableComponent and it would contain definition for BaseStats which will contain those resistances and stuff listed.

<Component type="Wearable">
 <Effects>
  <BaseStatModifier type="Strength" bonusInPerc="30" />
  <ResistanceModifier type="Cold" value="100" />
 </Effects>
</Component>

As I understand Params, it was made so it's fully supporting modding and mods changing params on the fly. If you want to keep things flexible for modding (adding new stats, use them and have effect and so on) I don't see other way than having is as Params - so accessible through strings.

If the game will be humans only, then Species/Body is indeed not needed, but if there is some super-human or robot variation (with extra arm or something), then I think Species/Body is a way to go. I don't think it's overkill to use for human and if you start coding in generic way, it may be just applied for anything you will throw in later on.

@koosemose
Copy link
Collaborator

koosemose commented Jan 22, 2017

Components

I thought you were proposing having gear use components in such a way that, for example, Cold Resistance would be a component on the gear itself, and Strength boost would be another component.

Params vs C# variables

Params were made to support modding, but mostly because Lua can't have variables specific to an instance of a furniture (or whatever else), having actual C# variables will be just as accessible from modding, and allow cleaner code on our side. It should work equally as well using either params or c# variables, but with Params there's the string access issue. We could have the core effects of gear as variables and that doesn't prevent modders from rigging up their own via params, but if we can at least have the most common stuff as variables that would at least save us constantly having to convert from string to int or bool or whatever else, which, while I haven't done any profiling, I find it hard to imagine doesn't incur a fair bit of overhead.

Body forms

It's just with multiple body forms or even coding with the assumption that they will be a thing will mean at least a basic system for handling species (even if just humanoid) will need to be in place, and then gear will need the more complex coding required for basically unknown body forms. And of course either things like a space suit will have to, either be actually multiple gear for each slot, or have multiple versions for each body form. It drastically increases the workload required by a single developer to get a single system in place.

@GamerGeeked
Copy link

GamerGeeked commented Mar 31, 2017

I was actually dissapointed when this wasn't about cogs...
If our character is a space squid, amputee, or cybernetics enthusiast,, we'll want to add or remove slots.
For humanoids, a structure like this would work

Heads

"Head"

Limbs

Arms

"Left"
"Right"

Legs

"Left"
"Right"`

And assume all creatures can wear chestplates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants