Jump to content

sleeves

Very supportive Vintarian
  • Posts

    62
  • Joined

  • Days Won

    1

Everything posted by sleeves

  1. It is helpful, but perhaps better left in wiki territory, lest newer players bounce off the handbook thinking it's too complicated. (I say, as if this doesn't happen already...)
  2. Were a simpler version desired, the debuff could apply when health drops below a threshold.
  3. I think the problem is moreso how randomness factors in. Sometimes you find everything you need immediately, but in other worlds you go upwards of fifty hours without finding that one resource you need to progress. I don't think there's any great solution to be had, although bad luck has become much more tolerable with the addition of elks.
  4. I would argue otherwise, because that assumes the system is following the xdg standard. The best practice for optional support like this is generally an option when installing, or a separate package, e.g. chimera's *-<shell>comp for shell completion or artix's *-<service manager> for service files.
  5. Thanks for the welcome! I'll admit that I just want the feature like the developers wanted butterflies. It's not exactly a game-changer, but it tickles my brain in just the right way. To be specific, I meant something like [A Township Tale](https://www.youtube.com/watch?v=Uo9N1jHGb7Q) had, where the pouches are physical attachments to a single backpack. I'd definitely settle for a 2D interface for it, though- I'd be shocked if an in-world implementation were anything but a mountain of work.
  6. I agree with OP; I turn storms off because they're really just a mild annoyance as of now. My solution would be to spawn a special sort of rift during the storms which can be destroyed by physical attacks, though preferably with a large health pool. This would encourage players to interact with the mechanic, lest their base be enveloped by an exponentially growing mob of rust creatures. The rifts would need to be "stunned" when attacked so that a shiver doesn't spawn on you from the very thing you're destroying.
  7. I rewrote it that way after realizing I had been using the same terms to mean multiple things, which arguably made it even more confusing. The idea is just to have slots in a backpack which themselves hold pouches, holsters, etc. and give customizable traits to both.
  8. Preface The current backpack system is a bit silly. We wear four containers, which makes managing them less intuitive. There is, however, a benefit to the current approach: it allows mixing typed containers, e.g. mining bags and regular bags. I propose a replacement for this system which is more intuitive but keeps the same benefit, and even elevates it: modular backpacks. Concept Backpack slots are reduced to one. Modules each have a number of slots and a type restriction. Compartments have a slot multiplier and a maximum capacity. Each compartment can hold one module whose slot count does not exceed capacity. For instance, a compartment with a maximum of 8 can't contain a 10 slot module. Once equipped, the module's slot number is multiplied as defined by the compartment; an 8 item slot module in a 2x compartment grants 16 item slots. Backpacks contain a number of these compartments corresponding to logical storage units on them. A leather backpack might have a large main compartment and several smaller compartments, whereas a basket likely has just one very large compartment. In this way, player choice and tiered progression co-exist. By pulling the quality and type of modules away from the backpacks themselves, the player is made to consider about what they want out of a backpack. Should I aim for few large compartments so that I can use a bigger herb pouch, or many small compartments so I can carry various types of items? Modules could even have their own 3D visuals, just to be fancy.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.