-
Posts
686 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Blogs
News
Store
Everything posted by MKMoose
-
The problem you seem to be running into is that you're talking about multiple mechanics as if they were one: Entity speed is an almost entirely separate concern. Tweaking this has multiple other issues that I'll touch on below. Seeking distance as it is currently implemented is the distance relative to the entity's current position within which it notices the player. Tweaking this wouldn't change all that much. Leash range in a strict sense is the range relative to a fixed point beyond which entities do not notice the player. This applies primarily to MMOs, RPGs and similar games where mobs have fixed spawn points that they return to when not engaged, so it's not exactly a fitting concept for VS. A more relaxed implementation of leash range or some alternative mechanics like stamina that don't require a fixed spawn point could work and in fact have been suggested a number of times, also under this topic by multiple people including myself, but they're clearly not in the game currently so they would more likely fall under a larger revision to animal behavior and not a couple simple number tweaks. An animal which is slower than the player is essentially a free kill in any half-decent terrain. Black bears are largely a triviality once you notice that you can just outrun them. On flat terrain, I can even kill polar bears with no armor and weak weapons, because while they are faster than the player, they are incapable of properly attacking a player running backwards. Animals which are faster than the player can feel frustrating to fight if the player isn't given sufficient means to retreat or scare off the animal, but simply making them slower is no solution - it would just make them even easier to exploit than they already are.
-
The short answer seems to be no. Story structures use a separate system which tracks exactly which structures are generated and which are missing as well as guarantees that only one of each structures is generated in a single world under normal circumstances, and allows other game systems to access the data about those structures. Generating a village using World Edit or the /wgen structure spawn command does not register the story structure and still allows the original story structure to generate, so the locator maps still target the original locations. The intended way to change the location of a story structure with all the surrounding systems working correctly is to use /wgen story stepos (which is the same as /setstorystrucpos).
-
This is quite self-evident in many cases, but trivial to disagree with when it comes to core mechanics that the player is expected to engage with regularly, which is what I was menitoning in that case. A mechanic that is purely a detriment do the player and serves no other purpose simply doesn't work in that context. Thing is, though, if it's supposed to be purely detrimental, then it becomes more pointless the less common it is. If the mechanic is only relevant when the player is playing "incorrectly", then it doesn't seem to me that it warrants any significant development time. I hear people talk about making starvation mechanics more immersive, but as of late I don't even interact with them on new survival worlds - I practically never fall to zero satiety, at least on roughly standard settings. If the diseases are supposed to be purely something that can be avoided by not making somewhat obvious mistakes like eating spoiled meat or eating too much of one food item, then I just don't see the point for the most part, because the current approach of making raw meat inedible and reducing the satiety of spoiled meat as well as incentivizing some variety through nutrition is quite functional already - if anything, I would like to see nutrition mechanics expanded to be more fun to play with, because that's at least a mechanic which I engage with regularly. That is why I'm saying that disease could also be something that the player is expected to encounter specifically in association with certain biomes, points of interest or items. The disease can be designed as an integral balancing lever for whatever it's found alongside, and not something which makes the game less fun or more difficult for newer players while being entirely irrelevant for experienced players. I don't know if I can imagine particularly fun gameplay coming out of this. The best premodern methods (out of those that undeniably actually worked) of dealing with malaria and some similar diseases often boiled down to just avoiding high-risk areas or other known sources of disease. If someone contracted the disease, there was often little that could be done besides giving them ample rest, food and water, and hoping for the best (and often isolating them from others to prevent the spread of disease). Some herbal or other more unusual treatments could help, especially for example certain herbs as dewormers, though in many cases there was no actually reliable and effective treatments. There's a chance that it would work well, but I can't help but think of diseases getting in the way to the point of having to avoid all water while in hot climates or having to fill out a checklist of the same specific countermeasures in every playthrough in those climates (mosquito nets are at least a relatively realistic thing, said to have been used prehistorically). Unless the risk is localized and clearly defined as well as ideally associated with some kind of reward, most likely in the form of resources that can be obtained in its vicinity, then it would easily just become a frustrating restriction instead of facilitating any sort of engaging gameplay. And if you contract a disease, then what? Keep running around with debuffs? Sit about doing nothing in particular to make it go away faster? Hardly sounds like fun. I would point to two ideas here: Making diseases have no meaningful effects while at low strength could be borderline necessary to allow doing other things for a while when sick and while taking treatments, because otherwise it would feel awful to get debuffed and having to take a huge detour to deal with a disease and get back to whatever you actually wanted to do. Sleeping is the best thing that I can think of as a treatment method which greatly accelerates disease recovery - it would be a pretty flexible, immersive and realistic treatment in most cases, and it could be designed with a lot of secondary factors and progression in mind. And crucially, it would be fast, advancing time in the in-game world without forcing the player to just wait things out. Multiplayer servers would be a bit of a problem, where sleeping would likely have to be reworked in some ways, or some other form of resting or napping could be added to circumvent the issue of requiring everyone to sleep at the same time. Some diseases and especially parasites could have some more dedicated treatment methods, but sleep could still be helpful to at least reduce the symptoms for a while.
-
It's not like directly modifying maximum health can't do that, though. Eating a bowl or two of soup would recover just a bit of maximum health, but getting back to full could take many days. Overall, it's rare to see this kind of thing in games. Even many realistic survival games don't bother, and for good reason. While I can't predict what the devs may want to do with it, the main problem of sorts I see with diseases is that I have yet to see a single suggestion that brings any meaningful detail to the table besides listing off the colorful variety of diseases that could be added, the means to contract them, and the consequences when untreated. You'd be lucky to see someone even mention possible treatments. While a lot can be done with interesting mechanics, diseases by themselves don't really have much of interest about them, and they don't strike me as something that contributes positively to fun gameplay. I've thought about diseases, and my conclusion was that there are two possible ways to make them actually work: Make them into an important component of the game that interacts with other systems at a fundamental level, which the player engages with regularly and ideally also benefits from in some ways - from a realistic perspective it would basically no longer be a disease system. Temporal stability could move into that direction whenever if ever it gets revised, involving rust as a disease-like factor. Make them into a distinct threat associated with certain items, points of interest, biomes or whatnot, ideally as a counterbalance to something valuable which can also be found alongside it. Peat, food and other resources in swamps and bogs, guarded by a swarm of disease-bearing insects. Maybe something that can be contracted when mining specific ores - I'd need to look up what could realistically work for this. Many poisonous plants could be used for a lot of different purposes - medicine, hunting, fishing, insecticide, and other stuff. Perhaps something like stinging nettle which could also be used for its fibers (not really a poison or disease, but kind of close). Technically that kind of applies to things like spoiled meat as well, but I don't think I can come up with any sort of benefit to match up with it. Keep in mind that the easier the disease is to avoid, the more pointless it becomes. I'm curious if you're thinking of anything more specific.
-
It's not about balance. It's about the fundamental frustration of dying in spite of eating perfectly well, just because of the accumuated negative delta from a couple days back, with little to nothing that can be done about it. Or literally just take your suggested system, but instead of changing the rate of change, directly modify maximum health. Reduce it while satiety is at zero, and increase it while at above 50% satiety. In the current vanilla game, health already lags behind your satiety, and directly modifying maximum health would mean that it in turn would lag behind satiety. Both achieve or at least are capable of achieving everything you're saying your system would achieve, just with one fewer layer of integration.
-
I do like this idea quite a lot, overall. Reminds me of PEAK's stamina bar: which is a simple but pretty brilliant implementation of something akin to status effects. Barotrauma also uses a much more complex status effect system which ends up having a similar end effect in many cases, albeit without clear UI indicators to facilitate a deeper medical system. In the case of VS, the factors that reduce maximum health in the same way besides hunger could also easily include internal damage or long-term injuries, hypothermia and hyperthermia, poison, diseases (which I frankly don't get the point of, but Tyron has said he was interested in implementing something of the sort), and possibly a bunch of other things. I find that this could end up quite annoying to play with. With your provided numbers, assuming starting from neutral rate of change and staying at zero satiety, your health would be getting reduced, for example after four days, at a pretty pathetic rate of 1 HP/day for a total of 2 HP over those four days. But afterwards, keeping your satiety very high would still allow your maximum health to keep decreasing, by a total of 5 HP over 10 days, which could end up easily killing you in spite of perfect nutrition over that time period. It would seem rather questionable to die because you'd been starving two weeks earlier and didn't start recovering fast enough. As much as I think I get the underlying idea behind this, I'm not sure that the numbers make any sense to me, unless maybe you make the delta rise and fall much faster and max out after at most ~1 day. Why not just make the rate of change directly dependent on the current satiety?
-
It's most likely not a ghost item. An exact match for the issue is tracked on GitHub in #9858.
-
The main problem I see with their current speed is that it is nearly constant while chasing the player (the impact of uphill terrain or water or whatnot can occasionally be exploited but is not always reliable), which often creates an annoying binary that is difficult to design around. If the animal is slower than the player, then it basically isn't a threat at all with a bit of experience, at least as long as there is enough space to run around. It often becomes quite trivial to kill with pretty simplistic and boring strategies. If the animal is faster than the player, then it becomes difficult and often frustrating to avoid once it notices you. This can be especially dangerous for newer players, who might easily end up feeling like there's literally nothing that they can do once the animal aggroes. There is naturally some middle-ground where the animal is right about as fast as the player, which can sometimes be nice because it rewards familiarity with ways to slow down the animal, but it can also be extraordinarily frustrating to run on roughly flat terrain with the animal right behind for an extended period of time with no clear way to shake it off. This is not as much of a problem for drifters and other monsters, because they are usually found in more confined spaces and in larger numbers, and also have some ranged attacks. Wolves also aren't too bad because they spawn in groups, though I would be interested to see some nice long-distance stalking behaviors for them. But for bears which are predominantly encountered individually in relatively open spaces, I think it becomes a significant issue. As a side note, this also combines with omnidirectional sprint uninterrupted by attacks, which is almost never a good idea for a combat system because it generally lacks weight, intentionality and tradeoffs. It can work in some fast-paced games that emphasize player expression in combat, but VS clearly doesn't fall under that category. If I can run at the exact same speed regardless of whether I'm attacking, then I don't have to choose between fighting and fleeing - it is often effectively optimal to do both at the same time, and you end up with the player and the animal both running at roughly constant speed. So, purely in terms of speed changes and disregarding other suggestions for the moment, the solution to the above problem is to make animal speed more varied and significantly higher in bursts than in sustained pursuit. One of the main things which drives real animal behaviors is threat avoidance, and aggressiveness specifically is closely tied to threat neutralization. Animals almost never attack for the sake of it, and they rarely attack for food if they're predators but even that really isn't common because most predators also tend to prefer to avoid humans due to how dangerous humans are. Some animals like moose are actually in many cases more dangerous than wolves or bears or whatnot, just because they are massive and will readily kick or sometimes charge when agitated or harassed. When any animals do attack, it's often just because they see the human as a threat - to themselves, to their young, to their food, to their territory - and are strong enough to attempt neutralizing that threat instead of just avoiding it. And since a human that is running away is no longer really a threat, then I see no reason to make animals chase the player over long distances - animals should be dangerous, but not oppressive. Their initial burst of speed can be threatening, and it needs to actually be pretty fast to be properly dangerous. Because if it doesn't more or less force combat, then what's the point of attacking? Anything prior would be more nicely implemented as threat display, warnings, bluff charges and so on. At the same time, the player should be allowed to dodge the attack, to keep the animal away with a torch or something of the sort, or to hit the animal before it hits them (different methods would probably work differently for different animals). A kind of threat display made by the player (i.e. make noise, make a fire, wave a torch, run around or even straight towards the animal) could serve kind of the exact same purpose (at least when faced with smaller potentially-aggressive animals like wolves) that large animals' threat display would ideally serve on the player. If the player stays in place and keeps fighting, then the animal can also keep fighting, provided that it's built for it (e.g. for a brown bear or moose it would be more reasonable than for a wolf or a goat). But, the fight needs to be confined within some intuitive boundaries (within an area or time, with a rough maximum amount of damage that the player can reasonably take before they escape or the animal lets off). If the player retreats quickly or quietly enough, then the animal should generally go back to whatever it was doing beforehand without chasing the player. Basically just respond to and respect the player - if they don't want to fight, let them back out of a fight in a simple and intuitive way, provided that they manage to avoid the initial attack.
-
The coordinates in log files are absolute coordinates, whereas the ones you normally see and use are relative to world center. To use the absolute coordinates in /tp or some other commands, you need to put an "=" sign in front of each coordinate that you want to interpret as an absolute coordinate, e.g.: /tp =512123 120 =512456 As a side note, it may also be an option to just subtract half the world size from X and Z, but that then requires you to check the world size and do a tiny bit of math, so using the "=" sign is more straightforward. And also, I'm not certain whether the (0, 0) point is always actually half the size or can be slightly offset, and I'm not aware of an option to check it aside from experimentally by subtracting the result of two /tp commands.
-
As a general rule, grains drop any items besides seeds only on the last growth stage, while vegetables can drop some (~25-40%, usually) on the second-to-last growth stage. There might be some exceptions. Crop damage is somewhat inconsistent, but it cannot reduce average drops to zero - there is always at least a chance. It is also a bit bugged (#9841), though the bug tends to give more drops rather than less.
-
I've been completely unable to reproduce it over multiple attempts (besides cabbage, which has the other bug), so I'm not sure if there's anything specific I would need to do to trigger it. It especially shouldn't happen for dead plants, because that's a different block which should have its own drops. If it's not a mod issue, then I could probably make a few guesses like a client-server desync (maybe related to randomized update intervals, or maybe incorrectly saved damage accumulation, or something else), but ultimately I've been unable to find anything. If you can reproduce it in vanilla then it seems like it's worth reporting on the issue tracker.
-
Saving a proper custom playstyle in-game has been suggested a few times. I have no idea why it's still not implemented given that there is a customPlaystyles property in clientsettings.json which just doesn't seem to work. But if all you need is save it to a file, then you can do just that. Paste the playstyle to a text file. Then whenever you want to create a world with it, just open the file, Ctrl + A, Ctrl + C, focus on VS playstyle configuration, Ctrl + V.
-
I was able to get out by just sitting down with G, or in some cases just crouching, and moving off the bed. Whether that works may be dependent on which specific trader structure it happens in. I've been able to sleep with no issues, just like pre-1.22. It's always only been guarded by world.Claims.TryAccess(byPlayer, blockSel.Position, EnumBlockAccessFlags.Use), but it doesn't seem like it has much of an effect, just like for a couple other things like firepits. Some items being interactable does conflict with information returned by /land info: Though admittedly I think it's kind of better this way. Maybe beds could be debatable, but it's nice being able to use firepits at least. But, interestingly, BlockOpenableContainer is correctly unopenable, despite seemingly checking for the same access permissions. My best (somewhat uneducated) guess is that the issue could be related to ILandClaimAPI.TryAccess() apparently always returning true on the client? I'm not really sure how this system works exactly, though.
-
There are multiple problems with this: The "Ambush" tapestry is the only place where anything of the sort is mentioned as far as I know, and the chance for the average player to stumble upon it themselves is very minuscule. There is no actual, concrete explanation or justification for animal behavior being unusual. The tapestry just states that they are unusually aggressive and mentions that they might be able to sense something that the player can't, but it is extremely vague. Even though the most likely explanation for the increased aggression are all the temporal shenanigans and the rust world, the animals are actually completely unaffected by any of the temporal mechanics, not even temporal storms, and don't react to the presence of nearby monsters in any way. You might have heard of the term "ludonarrative dissonance". Sure, it would probably make Homo Sapiens a bit easier. But is that a problem? As long as the bears remain a potential threat when carelessly or deliberately approached, especially when they're protecting cubs (which are still unimplemented, by the way), after hibernation (also not implemented in any way) and perhaps in some other situations, then I see no current reason why making their behavior less pathologically aggressive should be seen as undesirable. What I personally kind of hate about the bears is that black and hot-climate bears aren't actually dangerous if you know what you're doing, and they're a very reliable source of leather, bushmeat and fat. Everything depends on their speed and black bears are actually slower than a running player, which means that as long as you have some space to run around, the bear will become practically a free kill. If you have a speed boost (clockmaker's or hunter's +10%), then even brown bears can be killed somewhat reliably at low risk as well. And that's the "dangerous creature" for you - farmed for resources because it just insists upon itself. Within the first two standard months of my 1.22 survival world I killed ~40 wolves, 3 black bears, ~5 pigs, and ~5 mouflons (they are actually arguably more dangerous than wolves and black bears, because they're faster than a running player). But trying to kill non-aggressive prey animals like goats or deer? Waste of time, in most cases. What I would like is not to have bears be passive or scared of the player - it's to have them feel like fair threats. Threatening, but not immediately aggressive. Will absolutely maul you in seconds, but only if you're sufficiently careless or don't respect their space in spite of clearly audible noises, warnings and perhaps a bluff charge. They could even be significantly faster than they are now, as long as their seeking behavior gets any sort of brakes instead of being allowed to chase a player for potentially upwards of a minute as long as they remain within range.
-
Granted, it wouldn't be exactly realistic, but "no sense at all" is a bit excessive in that the current mechanics can easily be argued to make no sense at all either, if not less. The point of the idea of replanting whole vegetables is to add more interesting farming complexity with minimal busywork, no item clutter, and fewer potential design issues, not to make the process as accurate as possible. But it's easy enough to also implement the option to harvest some of the crop and leave part of it in place, which could correspond both to partially harvesting biennial crops and to implied replanting of cut-off greens. I wonder if it would be better to create a more realistic yet lenient growth system where, instead of basing everything on arbitrary growth times and growth speed, each crop could have a few growth phases determined primarily just by time of year and have its yield depend on how much time it spends in each phase and in what conditions. There's several ways to do this, but a basic example could use four growth phases, for simplicity let's say each of them lasts roughly three months, possibly adjusted depending on climate: Planting season. Newly planted seeds do little to nothing yet. During all phases, if the conditions are unfavorable, plants will gradually lose health, but seeds that haven't started growing yet should have increased resistance to cold weather and some other effects. Growth phase. The plant accumulates resources, at a greater rate if the environmental conditions are right and more resources are available. It may lose health depending on the weather, but can also use some of the accumulated resources to regain lost health if necessary. Harvest season. The plant becomes ready for harvest, with yield depending on the amount of resources it managed to accumulate during the growth phase, and stays ripe until the end of the harvest season. Dormant phase. When an unharvested plant reaches the dormant phase, it will decay into seeds that will grow next year, and might even retain some of the accumulated resources. This kind of system (if balanced well, of course) could greatly reduce the pressure to plant at the right time, because you'd have clear and predictable planting and harvesting seasons (varied for different plants, naturally) without having to calculate growth times and predict tight planting or harvest windows. Even being too early or too late in spite of having this large margin of error would still usually allow you to get a harvest, just probably a smaller one. A big advantage of this system is that it is also flexible. Changes to individual parts of the system like the duration of a growth phase could be done directly, instead of having to adjust low-level parameters like temperature margins which could have unpredictable second-order effects. Well-designed seasonal growth like this would be straightforward to adapt to biennial crops, overwintering, continuously-producing vegetables, fruiting bushes and trees, wild forageables, or essentially any and all crops or plant growth including very nonstandard stuff. And as far as I know, the devs have expressed that they would like to implement some sort of seasonal growth system eventually, though at this point there is basically no telling when that might happen, if ever. Side note, there is currently a bug with incorrect calculation of drops from plants affected by temperature that primarily affects cabbage (#9841) - might be the reason why you're getting full harvests sometimes.
-
If it's already smelted, then you don't need to smelt it again. Just bring it up to the temperature and pour.
-
It's a UI issue, the actual temperature to melt the metal should work fine for the specific metal. Heat it to 1010 °C, in the case of electrum.
-
Higher cropGrowthRateMul reduces the growth time, lower cropGrowthRateMul increases the growth time - it's accurate to the wording in this case. It affects crops as well as fruiting bushes.
-
This would be a very cool tradeoff, though given that most grains currently drop ~6 items, it would have a pretty minimal effect on what is left for the player to eat. I think it could be interesting to change each grain crop to drop ~3 grains, or even closer to 2. This may naturally need to be counterbalanced with some other changes. It's one of the most common suggestions in regards to farming, probably, next to closely related changes for other crops (e.g. giving crops an additional seeding phase). Overall a fine change, and certainly immersive, and there is one potential issue to account for: grain spoils, so in the event that someone is absent on a server for a long time or for some other reason loses all of their grains, they would need to get it back from elsewhere. I would solve it with at least one of two changes: add renewable, forageable sources of wild grains (this would likely need to be part of a broader plant growth rework and could be integrated with a hay meadow mechanic), adjust grains to spoil at an unfavorable ratio into a non-edible variant which can still be planted and lasts forever (this would benefit from a proper composting mechanic as well). Seems like an excellent solution to the problem of losing edible crops and getting an excess of seeds after a period of absence on a server. For simplicity, it's not even necessary to cut the greens or create two types of plants - just put the regular vegetable or whatnot in the soil, acting like a seed for a different crop which then produces seeds for the main crop. Some way of converting the plant in-place could be good as well.
-
First, calculating the survival chance of a tool only requires that you multiply the survival chance (1 - shatter chance) for each iteration. In your case, assuming you've tried quenching each of your tools 3 times, with a temper after each one (besides the last which doesn't matter), the overall survival chance is approximately 0.95 * 0.92 * 0.895 = ~0.78. For 12 tools, that gives you on average 12 * 0.78 = ~9.4 surviving tools. Using a binomial distribution (for example with the Desmos Graphing Calculator - you can try something like this document to see different configurations yourself) for 12 tools with a 78% survival chance, we can calculate an ~10% chance that 5 or more out of 12 tools break (i.e. up to 7 favorable outcomes). Low but not terribly unusual, as far as probabilities go - it's twice the chance of breaking a tool on the first quenching.
-
An inversion in monster distribution philosphy
MKMoose replied to Rainbow Fresh's topic in Discussion
As long as palisades and spikes are a new option rather than the only option, and are not strongly optimal or outright necessary, I do not get this point. I think they look great - perhaps not something I would want in front of my house in real life, but they are quite fitting for the themes of the game. In fact, the whole reason why many people have suggested adding craftable palisades is specifically for aesthetic purposes. But if you don't think they look good, then it should be easy enough to come up with a solution that you find more aesthetically pleasing - if the devs do provide those, which I naturally cannot guarantee. Fences would still provide plenty of protection, and double fences could be equivalent to palisades if not better. An exact alternative to palisades in the form of something like a "tall fence" made of boards could be added. There's been several suggestions around these forums in favor of new and better means of preventing monster spawns and repelling monsters, for example with fire or some temporal trinkets and devices. Personally, I kind of hate that berry bushes have to be planted in regular soil and not farmland (or possibly something like dedicated "garden soil"), as it just doesn't really make sense, and I don't like seeing the bushes grow straight on grass. One of the developers even explicitly said at one point that the actual reason for it is that farmland is ugly, if I recall correctly, which was quite baffling to me because I would equally say that bushes planted on grass look ugly - beauty is in the eye of the beholder, as they say. The problem that I have with it is that I don't have an alternative in the vanilla game - I can only plant bushes on regular soil and nowhere else. As long as palisades and spikes have reasonable alternatives or are just optional, I don't see any problem. Tower defense is a fundamentally different type of game, and having palisades or spikes which are possibly better at keeping enemies away doesn't meaningfully inch the game closer to being a tower defense. Besides that, the devs have been quite consistent about their theming, so palisades and spikes are there simply to reinforce a large portion of lore and theming that has already been there - if you've seen the Chapter 2 story locations, then you could have anticipated many details about the aesthetics of trader huts, and especially the palisades or other improvised protection. But in terms of gameplay, there is currently essentially zero evidence besides lore (which often doesn't mean anything for gameplay anyways) that the devs may intend to use palisades or spikes in any way other than as decoration, and the new trader huts haven't made that significantly more likely either, given that and palisades and stakes have been in the game since at least 1.20 as purely decorative blocks. Not even a recent mention of improving temporal storms suggests that the devs intend to make the player defend during them - I would much sooner expect them to incentivize the player to go out during storms. We can say quite confidently that anything resembling a style of gameplay similar to tower defense games is nowhere to be seen in the announced and expected future of the game. Saraty's words on temporal storms from the interview with Mahjong Blonky from March, for context: Personally, I was thinking that something of the sort could work well in a story location, largely courtesy of the claim system. But at the same time, the current combat system and enemy AI absolutely is not up to the task, and at this point I'm not expecting that to change significantly even with a combat update. -
There's recently been a related discussion in another thread as well, largely echoing your sentiments. Personally, I think that this penalty should just be thrown out the window, and instead a benefit for using some specific tools and other items with two hands (i.e. with an empty off-hand) should be implemented. And possibly some items could only be used with two hands. Buffing two-handed items instead of penalizing using items in the off-hand has a whole number of advantages, as I see it: It actually benefits what the player is currently doing which keeps its scope within the short-term gameplay loop together with switching items into and out of the off-hand. It encourages keeping the off-hand empty for specific, targeted actions instead of at all times whenever possible. It gives the player arguably much more interesting agency - instead of only putting anything in the off-hand when necessary and treating an empty off-hand as the default, it actually would make an empty off-hand into a choice that the player makes when focusing on specific activities. It's only active when the player is actually using a relevant item, whereas the current debuff is applied regardless of whether the player is using the item in the off-hand, and its severity is not correlated with the benefit or use of that item and the player's current activity. You could be sprinting with a shield mid-combat, chiseling intricate decorations, or sitting around and cooking food with an item in the off-hand just because you forgot to take it out - all of them apply the same nagging penalty. Some items like the shield or a lantern could retain a debuff, because the player can benefit from them in sudden situations or passively. Even in this case, though, simply adding an opportunity cost through more items that can be used in the off-hand (e.g. knife or other weapons, bag or basket, walking stick) could also be sufficient to make the player think twice about which item they want to use, making the penalty completely unnecessary and even detrimental to gameplay variety. Only tangentially related, I just had a thought that it could be really cool to make the bow only usable in the off-hand, with an arrow in the main hand. Would be much more sensible and immersive than using the bow in the main hand with the off-hand free to do whatever it pleases.
-
The main potential problem that I see with this is that it completely shifts the design function of classes, from an initial horizontal choice that serves as the basis for the character's identity as well as the player's social identity in a multiplayer context, to a vertical progression system comparable with RPG skill trees that focuses on a sense of progression and character ownership as well as enables optimization. Not unlike described by @LadyWYT above, this new system could easily lead to existing classes losing a lot of their identity, and the initial choice being much less meaningful - while it's not necessarily a wholly bad thing and it can be in some ways mitigated, it's still more difficult to justify doing so than it is to justify changes that purely build off of what's there. Personally, I would argue for largely the opposite - that the initial choice should have greater impact on the game by altering the available and optimal playstyles more heavily than just through minor buffs and debuffs. Because as it stands, class selection still largely boils down to just making some things a tiny bit easier or more difficult, a tiny bit more convenient or time-consuming, but without significantly affecting the way that the player makes decisions or progresses through the ages - especially in singleplayer where the player has to do everything themselves either way. Why tie skills to high-tech or magical items? Since you're already suggesting memories, why not tie new skills to temporal events, lore discoveries (including those made as part of the main story), and allow unlocking recipes from written formulas and schematics? Why give players penalties for progressing? The primary purpose of negative traits, beyond establishing character identity, is balancing against the traitless commoner, which just isn't necessary in a vertical system. Debuffs may make progression much less satisfying or even discourage the player from seeking out new skills. Allowing to specifically select drawbacks would also risk enabling greatly excessive optimization. If anything, I would expect to be able to choose thematically matching pairs of positive and negative effects rather than select them separately. Spawning in with items in hand sounds to me like a great way to break immersion and place the player's focus in the wrong place, at least as long as the game is supposed to be a wilderness survival and not an RPG or adventure game. If the items are random, then it could also inadvertently encourage rerolling until the player gets good starting skills. Finding them in ruins or elsewhere is generally fine, but if you want starting skills then retaining the existing traits pretty much as they are now would be quite fine. The primary way to address this issue, albeit certainly not the lightest in terms of development time, is to give each class their own specific skill tree of sorts. Don't Starve Together has been doing pretty much just that - started in 2023, and they still have 6 of 18 characters to update, which they have been doing interspersed with other content releases. This is a problem that so many class or skill systems fall into, and I genuinely don't know if there's any reason for it besides bandwagoning onto what's popular without actually understanding how to make it good. They're supposed to increase player expression and allow meaningful choice, but actually end up leaning into hyperoptimization and reducing variety as a result. The current class system is simple to the point of arguably being simplistic, but it's quite serviceable and from what I've seen, contrary to some opinions, no class seems to be dominant or significantly underpicked on multiplayer servers. See a recent TOPS class poll for an example.
-
They should be able to spawn everywhere, albeit most commonly in cold and temperate climates. In warm and hot climates rivulets spawn less frequently on the whole, and in icy climates they might also not spawn quite as often due to a large portion of the world being covered with ice. Source: source code. If they are actually unable to spawn in some climates for you, that would more likely be a mod issue or a bug.