Erik

I think a system with fixed classes is actually better than a trait based system, as it allows to more carefully design interesting characters for the player to play with their own unique challenges and advantages. A trait system would require balancing the traits against each other and other perk combinations , which is not impossible to do but not easy either. It would probably lead to a situation where some traits would just never be picked and the traits would be picked in such a way that players play optimal build, that cover their weaknesses with their strengths. Having specific weaknesses tied to specific advantages like in the system right now just forces more nuanced and interesting experiences and not has players go down the route of optimizing character classes for the most powerful or useful combination. Sure, it provides less freedom and such combinations could still technically be possible in a trait system, but most players might never enjoy those fun and unique combination if you don't force them to and the community can be more focused around them and their unique gameplay. Anyhow, modding the classes right now to create new ones using the same traits is really easy, so there is technically still that freedom to mix and match. As for a player character progression system, I think it would probably be something in the line of Skyrim/Valheim/Stardew Valley/etc. where skills just passively advance by using them, making your character better at doing those things. Not a bad system, if done so to lower the grind rather than cause it. If certain skill levels where to be required for certain things though, like forging the best sword or crafting certain things, players would grind just to get these skills, which I strongly oppose, the game doesn't need more unneccessary grinding. I could also imagine more unique takes on character progression, that reward exploration or overcoming certain challenges and give more unique bonuses.

The idea of a "round" world isn't as complicated as it may seem at first. It would be a lot of work though. This thread has some info on how to archive it, especially in the video in last post: A torus (i.e. donut) would be chosen for the shape of the world. The world would need to be big enough so the same chunk (or even region) can only be loaded once at max viewing distance, as there may be strange bugs when it is loaded multiple times. World generation would need some tweaks, so the world generation does connect at the former borders, which for terrain shape just requires some tweaks to the noise to make tileable. However, making the other worldgen stuff tileable, like especially the landform mapping could prove to be rather difficult, the code as it is right now is already kinda daunting. Though, to be honest, I don't see it happening ever. It is the kind of feature that needs to be build in from the start or very early, because with every new thing added to world generation it becomes more difficult to add and as the feature is not in right now and not even in the roadmap, I'm certain it isn't coming. It would just take months to develop something with minimal gameplay impact, there are more important features that deserve that time. As for modders taking this idea, I highly doubt it. Modifying the chunk loading could would be required and that is part of the engine, so not easily accessible by modders. The maintenance for such a mod would also be kinda high, as updates are much more likely to break it.

Well, you can just carry the tool heads and craft the tools on the fly, since tool heads can't be damaged they would be able to be remelted for full metal return, so I see no problem there. I also don't see a problem with undamaged tools being able to be resmelted. Currently really everything needs some amount of full ingots. I also don't see how blocking a single mold would be such a big problem, you can still not melt the metal stuff and keep it in a chest if you really cared about it. Overall, I'm not against the concept of some generalist form of a small unit of metal, what would essentially be a nugget in Minecraft, call it metal shavings or metal scrap. However, I don't really see the need for it. Most items that should be resmeltable would in fact logically resmelt into full metal ingots, like tool heads (with plates, chain, etc. already being able to resmelt). Only exception would be arrow heads, which would require multiple (9) to resmelt. The ability to remelt damaged tools is however something that is up to debate from a gameplay perspective, but here some scrap metal mechanic is required. I think adding metal scrap/shavings from splitting voxels on an anvil is a bad idea, as it adds nothing really of value imo. Sure, some tools would require less metal when made with the anvil, but balancing metal cost around metal used in the recipe is not always a good idea and the shavings also add a lot of micromanagement, as you would obviously not be able to resmelt your toolhead for a full ingots worth with it, but have to also add the correct count of shavings and you would therefore not be able to regain the full material when the toolhead was made with a mold, which is very annoying. A better way to make the anvil more desirable would be to just give tool heads crafted with the anvil a slight durability boost.

You can't do anything with just one metal shaving, can you? You can however save up, till you have enough metal to fully fill a mold. That is why I prefer a metal scrap system here more. However, getting back 50% of the metal is still much better than getting back nothing, also why would someone have unused tools anyway?

Armor damage and therefore repair would be frequent, when having the system I proposed, where armor damage also means lower protection. For such a system resolving around "destroying" armor, the armor wouldn't last for a few hundred hits, but probably 20 or so hits when against a monster that would after the old system be in the same tier. And even when this wasn't the case, armor damage meaning lower protection means, people would be encouraged to always have their armor at full durability. As for a repair system that allows quick repairs without huge resource investments: Just whack your armor with your trusty hammer, converting durability of the hammer to armor durability. There just has to be some limitation, so this can't be done in combat, like having to place the armor somewhere to repair it or something.

Exactly, no one crafts early metal armor right now. Making early metal armor even more useless, by having its frequent repair also be a resource sink is therefore a bad idea. But having early metal armors last without huge resource investments and them having relatively good stats may actually still not be enough to have people use them, as people can shoot through the metal ages very quickly, like you describe, but it would at least give some more incentive.

It doesn't, that is not the point of the system. I mean, with your system of metal shavings from voxels, the metal cost used for casting could still be adjusted to match the cost of smithing. Likewise, I could adjust the metal cost required for casting to be higher, to make smithing better without touching itemstats. It isn't something that is uniquely tied to the shaving system. Personally I think giving forged items a stat boost like more durability would be a better thing than a lower material cost, since such a system is bound to be introduced anyway, when quenching and tempering are introduced. Metal value stored in a crucible is very usable. And while there are no partial iron/steel, since it can't be molten in a crucible with any of the currently available fuels. But you could still put them in a bloomery, if they added up to at least a ingot. Broken toolheads, two of which resmelt into an ingot, could theoretically be implemented. But for this I think an metal shavings (though I like the name metal scrap more) system would be better thing, to represent some generic metal parts. Though I still thing it's a bad idea to integrate them as shavings for smithing, they would be best to just be for breaking metal stuff down for remelting.

I don't even see why such a metal shavings system is even needed, we can already have "partial ingots" via metal value in crucibles or in a bloomery. Having voxels represent actual metal value doesn't seem so fun to me, as it introduces a bit of micromanagement, when I feel like a plate or chain being worth (and able to be remelted into) two ingots is simple and effective. The only thing that's missing is smelting recipes for iron/steel that produce iron bloom and for the tool heads. There is only one slight limitation that should be removed: When I want to remelt my arrow heads, I can't just use one arrowhead and a few nuggets that add up to a full ingot, it must be enough arrowheads to make one ingot. Not the end of the world, but something that can probably be solved.

Refitting tier to just durability damage is an option, but I don't think it is the best one. Taking the quotient of the tiers would mean that differences of lower tiers are making more durability damage than differences of higher tier. Tier 5 to tier 4 is just a durability damage multiplier of 1.2, while tier 2 to tier 1 is a multiplier of 2. That would mean that higher tier armor would last significantly longer in general, especially when the better materials also have higher durability, as the system still lacks some form of anti-armor. I don't think tying the armor balance to the crafting recipe is a good idea at all, from a design perspective (as the system loses a lot of flexibility, it is generally a really bad idea to tie a specific balance to a system) and from a gameplay perspective. It would shift balance too much in favor of full plate armor. There is also the problem of balancing the different armor pieces durability with this system, as doing so would be completely dependent on the crafting recipes. There can be reason for the different pieces to have not the same durability, but maybe scaling with hit chance, so less frequently hit pieces like the head would also have appropriately less durability. Having differing durability damage on weapons also seems like a bad idea, since I see no gameplay reason to do so other than being a bit more consistent when having tiers. I have thought about adding some buffer before the downward spiral, but there is already a kind of buffer: The maximum damage reduction. When the maximum damage reduction is really high, it may take very long, before the weapon actually does more damage. A higher damage weapon would however be allowed to bypass this buffer sooner, which I think is good as it helps to further distinguish weapon types, in case material has little to no impact on the damage of a weapon. As the maximum damage reduction is also a stat on the armor, it is far more flexible than a static buffer. Having repairing be a resource sink is a bad idea, when the armors are balanced to break rather quickly in combat, as is the case with my system, where armor durability is actually a dynamic stat in combat. Crafting the armor is already quite the huge resource sink, I think punishing the player for crafting a lower durability armor which quickly broke against a high armor damage mob more than having a big disadvantage in combat with having to use a lot of material to repair it is just unfair. It also devalues armors made out of early game metals, as they would be a very quick way to lose a lot of resources, so people are just better of waiting to craft armor until they have steel, like is the case now.

It's certainly an idea that has been discussed a lot of times already: For me, my general opinion on this hasn't really changed, constantly having to sharpen weapons seems like a huge tedium. Furthermore, the whole idea of a weapon becoming dull is kinda hurting combat, as fights will drag on over time, rather than getting more deadly the longer they go (which is something that could be archived with armor effectiveness scaling with durability, which while potentially having the same tedium problem, would actually be an improvement to combat gameplay). I'm all for a repair system, but the one proposed seems to be a bit too much effort required imo, especially since the smithing system is already used so extensively, some people are getting annoyed by it. A system with a grindstone where the player exchanges max durability for more durability would be a better fit imo, as it would be a lot more convenient, while making tools not last forever, just significantly longer.

Well, your right. But it could easily be fixed by adding an armor bar on the hud like in Minecraft. The bar would need to be split into three sections, representing the different armor pieces, but generally it would be something easy to implement and for the players to understand that practically fixes the issue. This is also a valid concern. After all, I think having tools and weapons effectiveness scale with durability is a terrible idea. But I think armor getting this doesn't have to cause other things to get this treatment too, I mean clothing already kinda has this very feature right now and it doesn't cause people to demand it for tools and weapons. The armor repairing shouldn't act as a resource sink, crafting the armor is already quite the resource sink anyway. Repairing needs to be there so armor durability can be a short term resource, something that can be significantly damaged in combat without it causing the player to loose a whole lot of resources trying to repair it. The reason for the durability is not to provide a resource sink, but to have armor be a temporary defense in a combat scenario and not a permanent as well as not have armor defense be a binary on/off.

I feel like the current armor system needs some work, currently it is very convoluted: We have different damage types, flat damage protection, percentage protection and damage/defense tiers, high damage tier resistance. What do damage types do? Currently nothing other than effect how much durability clothing loses when hit. What does tier do? A lot of things, effecting durability loss, being an important factor in the damage equation, etc. Is flat damage protection subtracted before or after percentage protection? Before percentage protection. So flat damage protection doesn't really have much impact, based on the tiny amount on armor? Yes. Is there something akin to armor penetration? Well yes, tier, but is is not utilized as such, as there is strictly tied to material. How much damage will I roughly do with my tier 4, 4 attack damage iron sword against tier 2 black bronze chain mail with 1.25 flat, 83% percentage reduction? Em, I have no idea, can't even come up with a rough estimate because the tier calculation is so mythical it is contained in a for-loop. As one can see, the system raises a lot of questions to the user while not offering any depth in return. So, instead of trying to insert new complexity, we will try to streamline while offering more depth/variation in armor choice. First, let's cut damage types, sorta. While some basic damage types are required, like physical, flame, poison, suffocation, starvation, armor should only protect against physical damage, with there being no such thing as cutting, piercing or blunt damage anymore. The main reason for different physical damage types would be to basically have different weaknesses and strengths for different armors and while sounding like a good idea, it generally only archives players carrying multiple weapons to cover every weakness, wearing the armor that is the all-round best instead of diversifying. That is not to say that some anti-armor system isn't required. Next, let us also cut tier. Tier just has too much influence on too many different things, making its impact hard to describe in words other than "bigger number better". This means the damage calculation is drastically simpler and easier to understand, as the obfuscation introduced by tier difference is removed entirely. With tier removed from the damage calculation, it can also get some tweaks to make it simpler to calculate and offer more depth. Percentage reduction gets renamed to damage reduction but stays the same as a stat, as it is simple to understand and effective. Flat damage reduction gets completely reworked into a new thing called maximum damage reduction. Instead of the percentage reduction scaling into infinity, it is only allowed to reduce damage up to this maximum. The new damage calculation therefore is as follows: damage_taken = damage_received - Min(damage_received * damage_reduction, maximum_damage_reduction). This allows differentiating armors more than the flat damage reduction, as low percentage damage reduction high maximum reduction armors will be generally better against strong, high damage, attacks like the swing of an axe than high percentage damage reduction low maximum reduction armors, which will generally be better against weak, low damage, attacks like strikes from daggers. It also doesn't suffer from the issue of high flat damage reduction completely reducing an attack. Now let us deal with durability loss, which previously relied on tier difference and the damage of an attack. With tier gone, we will need a new thing to implement its effects, albeit in a much cleaner way: durability damage. Durability damage is a new stat for weapons that determines how much loss of durability they will cause to armor. Better materials will have higher durability on armor and higher durability damage on weapons, emulating the tier system in a way, while being much more focused and less confusing. This also means that the attack damage of an attack will no longer have impact on the durability loss, allowing things like a war hammer that does a lot of durability damage, while still having generally low damage. The last significant tweak to bring the whole system together and add anti-armor of sort is scaling the maximum with durability. Lower durability of your armor means it will be potentially less defensive, as the maximum amount of damage it can defend gets lower. Armor repairing and armor not being completely broken when durability reaches zero is obviously required to make this not unfair, but as far as I know that is already planned and needed anyway. Breaking, or at least damaging, armor becomes a core combat gameplay element rather than just some tedium. Because higher maximum damage reduction doesn't block more damage than the percentage reduction, armors having higher maximum damage reduction would be resilient for longer against durability loss, while not necessarily being more defensive overall as a side effect. Naturally, with tier being gone, there need to be some adjustments to monsters and animals, who have previously relied on the tier system. The simple solution is to give their attack durability damage and have them actually "wear" armor, with their own durability, damage reduction and maximum damage reduction. Overall these changes will lead to a lot more dynamic combat, as durability is now actually important to keep track of, like a second health bar, that can also be manipulated by opponents. Naturally the removal of the tier system is probably a bit controversial, but the durability damage system and defense scaling with durability basically fulfill its purpose of preventing damage and defense inflation while keeping new materials useful and additionally does a whole bunch of other nice stuff. For making the system even more accessible for the player, displaying health and armor bars of enemies may be a good idea, as well as signifying if a weapons attack is strong enough to exceed the maximum damage reduction. What do you think about these ideas? How would you like the armor system be? Any feedback is welcome.

When combat will be improved there will definitely be some sort of blocking/parrying implemented. This however poses a problem: How to prevent the player from hiding behind his shield forever? The answer would be something I abstractly call a combat endurance system. The most straight forward solution may just be to have blocks not block all the damage, but to only reduce it. This however either makes blocking useless when the health cost is to high or makes it overpowered when it is too low, letting the player still hide behind the shield forever. This balancing problem is especially mostly impossible to solve when armor gets involved. So I will rule out health as a good solution for the problem. The next possible solution would be a stamina system. Blocking costs stamina, when the player is out of stamina he can't block. Simple and effective, as well as allowing to limit evasive actions (i.e. running away, dodging). This new player character stat could also be integrated into other gameplay systems, like the nutrient system (certain nutrient groups increasing stamina instead of health) and the armor system (stamina penalty instead of somewhat annoying lowering of movement speed for heavier armors). The stamina system would generally be useful in preventing/discouraging spam of certain actions, like possibly attack cancellation in combat, allowing to balance the gameplay systems more carefully. So what are problems of stamina? Stamina would obviously regenerate over time, which could lead to players abusing the system in combat against mobs, being able to quickly hide behind some blocks to regenerate stamina and be able to block again. Waiting for stamina to regenerate is also not the most exciting thing, but may be something that commonly occurs when stamina is a thing. And as most people have gathered there is a third possible solution: Durability. I think this is the solution the devs will most likely adapt, based on their current implementation of armor durability. Blocking costs shield (or weapon if blocking with a weapon) durability, if the shield/weapon is broken it can't block. This very effectively limits the length of fights and puts a big focus on gear progression, which some may like, others may dislike. The obvious problem with this system is that it would really need a repair system, as otherwise combat will just be a way to burn through work and resources and be not just pointless, but strongly discouraged, making evasion the only proper way to play. Swapping armor or shield in the middle of combat also needs to be disallowed in some form, or players could just swap the shield to instantly regain all lost "combat endurance", but that isn't exactly a hard thing to implement either. The real problem with this system is that it can't be as universally applied as the stamina system, evasion (running, dodging) and attacking (specifically canceling attacks, missing attacks) can't be balanced by it in the same was as defense, as they are not tied to gear in a logical way. I personally still think the stamina system is the better way to go, as it is more flexible and the durability system putting too big a focus on gear progression rather than player skill for my personal taste. So, what is your opinion on the matter? I'm be very interested to hear about other views and solutions/problems I didn't think of.

Honestly, I'd be happy with any update, but find it sad that there is no worldgen update listed. I suppose the ocean update would be kind of a worldgen update, but it probably won't include such important parts as rivers (which I suppose would be somewhat needed for waterwheels), ridged noise, deeper underground, maybe chunk column offsets and new kinds of flora. It would make sense to put all the big worldgen features into one big update to not potentially break (seamless) world compatibility in multiple updates. The Lovecraftian update seems like a really cool story update and I'm very excited for a mechanically interesting alchemy system, but I feel like that would probably need to build upon brewing and alcohol, if it aims to be somewhat realistic. I feel like I don't have to explain how much I crave for a combat update, but I have to advice not trying to be too simplistic for the sake of simplicity. Adding shields alone won't make combat better and can create some issues of it's own, it's important to first improve on what already is there: Attacks. Decent readable animations, maybe different attack types and most importantly cone based hit detection, swords aren't short range guns. Blocking should realisitically also be able without a shield, though that requires some form of a stamina system. I suppose when blocking is only possible with shields, the durability bar of shields could be the stamina, but that opens up exploiting the system by having multiple shields in the inventory, which seems a bit stange imo. The Homesteading update is improving on what the game already does the best, which is farming and food. I mean, it would be a nice update, but I feel the focus of the next update should be on improving systems that are not quite on the level of farming to bring them up to the same standart. Though bringing fruit trees could be used to overhaul trees as a whole, since fruit trees require progressive growth anyway, which would be something very nice. More mechanical stuff is always nice, I'm also very pleased to hear that a firepit overhaul is planned as that is also an excellent chance to improve on the survival side of things even more since we now have a body temperature system. Only thing I worry about is that there might not be enough incentives to use mechanical power other than the obvious automation of some crafting processes. What would be the reason to build an elevator for example? Other than being fancy there is no reason right now. Some changes to the ore system though could make building long mineshafts with minecarts useful and minecarts would obviously need an elevator like in real life, not behaving like the ones in some other cube building game.

The ore and prospecting system is certainly the hardest part of the game for new players to understand and I think that is down to the presentation of the data provided by the propick. The propick has two modes like Streetwind mentioned, a node search mode which searches for actual ore blocks and a density search modes which searches for the concentration of ores in the general area. The node search mode is rather useless, it is only partially useful when you already are in a area you know to contain a lot of ores, helping you to track these down a little easier. Copper is the easiest metal to obtain, but a lot of new players don't realize how easy it is to obtain: Directly under surface copper nuggets there is always a copper vein, which can be mined and processed if the player has acquired a copper pickaxe and hammer. Tin and iron however require prospecting. The density mode will give you values of how much ore of certain types there is in the area, if there is no tin, move 100 blocks and prospect again, until you find tin. When you found if, there are usually higher concentrations nearby if you prospect around the area where you detected it. This is not really obvious to the player, but the concentrations are distributed among the world like a landscape with hills of high concentration and large areas of no concentration. It would be a way better representation if these concentrations were actually added as a map overlay that is revealed around the player in a certain radius when he prospects, so the player also gets a sense at which distance the values change and doesn't have to manage a lot of waypoints for documenting ore. Once you have found a high or medium concentration of the ore you are looking for, actually finding the ore blocks in the ground is rather easy, thanks to the way ore generates: in thin flat disks. You will just have to dig a lot of vertical shafts down and you will eventually hit a disk, often even on the first try. This also means that strip mining is useless, as the chance of hitting the flat side of the disk is rather small. Tin disks can be rather small, but thankfully you don't need much tin, as only tiny amounts are needed to make bronze. Iron can appear in quite huge disks, which is also nice. I personally think the ore system is not that bad, it just needs some tweaks in the presentation, like the ones I mentioned. I would also like to see alternate ways to reliably obtain ores like tin by exploring caves. Some ore geodes on the wall of caves that can be crushed down to nuggets would be a nice way to get quick access to small quantities of these resources, especially to smoothen out the progression into the bronze age.

Good combat alone won't attract or lead to a toxic community. Competitive PvP however could. Competitive multiplayer games, especially team based ones (Counter-Strike, Rocket League, League of Legends, etc.), have always been a breeding ground for toxic behavior. For survival games there are also a few examples of particularly PvP focused ones like Ark Survival Evolved and especially Rust, where the core enjoyment revolves around raiding other peoples bases and trying to conquer whole servers. When the core gameplay motivation is griefing other peoples bases, you can bet that it will get toxic very quickly, especially in unmoderated environments that official game servers offer. However both of those games have arguably bad combat systems, where player skill is a very low factor and gear is decisive, so I don't think adding some improvements to PvP combat while focusing mostly on PvE combat would do much harm if any at all. The combat system won't be the biggest factor that leads to the emergence of a potentially toxic competitive or PvP survival community, Minecraft evolved both things without ever having a good combat system for example. The forming of toxic subcultures are a thing that can't really be prevented, when anyone can host their own server, but as long as Vintage Story will stay primarily a survival sandbox game, the larger community is gonna stay nice.

The reason the stagger is split into multiple types is to give combat a better flow and never leave the combatants out of options. Block staggered? Well then it might be a good idea to attack. Attack staggered? The enemy will then probably launch his attack and I can prepare to block. If properly balanced, it should provide a good back and forth. Sure, when stagger is more powerful (like combining all three types into one), it will feel better to stagger enemies, but being on the receiving end will feel much worse. This is why the player can't be staggered in Skyrim, but as Vintage Story has a multiplayer mode, allowing the player not to be staggered would essentially rule out the whole system from PvP, making PvP feel much less satisfying. I thought a lot about punishing the player more for having no stamina, but I think it should only effect defensive and evasive options. The player is already very disadvantaged when out of stamina, being unable to block, dodge or run away. The only way for the player to defend then is to either evade attacks without dodging or attack block attacks, which should be difficult to do. Attacking is still an option, but it comes at the drawback of not regenerating stamina, so overaggressive play on low stamina is very risky, which is why I don't think it needs to be punished even further by dealing lower damage. The problem with "fast", "normal" and "strong attacks" is that it's hard to balance, so there isn't a "best" attack against all or a certain type of enemies. I kinda went that way with the directional attacks anyway, the stab essentially being the fast attack, swing the normal and overhead the strong and hope that the drawbacks of each attack balance out the advantages, so there is not superior option. That they are kinda standardized is that that is required to make attack blocking work, as it is essentially directional timed blocking which means that the defender has to be able to read direction of the enemy attack very quickly, which is why having types of attacks that are different based on the weapon is very problematic, making an already pretty hidden mechanic even more hard to get into. I like the idea of attack blocking "chaining", escalating the damage and thus creating more tension the longer the attack blocking "duel" goes on. It may be good to not only increase the damage, but also slowly increase the attack speed, so making a mistake gets more likely as the "duel" continues. It's a very risk vs reward situation, as players could opt out of it by blocking at any time if they feel they are outmatched, but doing so will be a big hit to stamina. Or they continue, while slowly loosing stamina with each new attack until they either overpower the enemy or are overpowered themselves, getting a huge chunk of damage. Having parrying stagger the enemy could make it into a powerful offensive maneuver, like bashing in Skyrim. It would also take the risk out of parrying, as the player can't parry too early, because the parry would always cause the enemy to stagger and thus cancel his attack. The classical "shield bash" is just to powerful and versatile in my opinion, which is why I decided to have the parry be a kinda weakened purely defensive version of it. I could however see a small attack stagger after a successful parry, if you mean that. I purposefully left out such details, as I feel especially stagger needs to be finely balanced to provide a good pace to combat, which requires playtesting anyway. The idea raising your block in the last moment, of "timed blocking" is also something I thought about a lot, because it is such a prevalent feature in Skyrim mods. I decided against it for two reasons: Parrying and especially attack blocking already kinda is timed blocking mechanically and as there is a constant stamina draw while blocking, the player is already encouraged to block as short as possible. Furthermore, timed blocking is a somewhat "hidden" feature you specifically have to inform the player about, as it is very conditional, while a parry is very self explanatory to perform, as it is just hitting attack while blocking. Attack blocking also suffers from being kinda hidden, but I think it's less of a problem as it is intended to be a very difficult and thus generally less useful move anyway, mainly for PvP. I think dodging is especially hard to balance and fit into the system. I feel like there must be some balance between defensive and evasive playstyles. One thing to note is that dodging is more of a evasive counterpart to the defensive parry, while walking is the counterpart to blocking. Dodging and parrying are both timed, but for parrying it is only really important to not parry too early, while for dodging it is potentially the other way around. The dodging distance should be just great enough to evade a swing attack, it shouldn't replace player movement, just enhance it. Having the player be fully staggered after dodging would not only leave the player venerable, but also disallow any offensive actions and I think this would make dodging almost useless. The greatest potential difference of parrying and dodging is that dodging can be used offensively, first evading the enemies attack by walking and then dodging into the player and attacking, which would make for a potentially very fun and interesting playstyle I wouldn't want to lose. Don't worry about this getting buried, you can bet I will annoy Tyron with this once he plans making a combat update Anyway, thanks for the comprehensive feedback!

While not every attack makes as much sense on every weapon, for attack blocking to function, every weapon has to have every attack. War axes frequently have pointed metal tips, so a stab makes some sense. Having the swing and overhead of the spear be sideways and overhead stabs could work, but the animation might be too similar to the stab and may not cover enough area in case of the sideways stab. I think some suspension of disbelieve is possible, as whacking someone with a spear would still hurt, as would poking someone with an axe. In the worst case, the attack damage of those attacks could be lowered, which would however have a strong impact of the usefulness of different weapons, especially spears.

The problem with an "auto mode" is just that it turns a visually appealing repetitive task with low player engagement into a visually appealing repetitive task with even less player engagement. It turns knapping into holding down a button and watching a glorified progress bar. Furthermore, everyone would use this feature if it was faster or equally fast, making manual knapping redundant or when it would be slower, people would complain about how annoying it is to having to hold down your mouse for so long. For it please everyone, both manual and automatic have to be equally tedious, which ends up pleasing no one. I only support the "auto mode" as a optional accessibility feature that has to be configured in the world settings or enabled via command on a server, which replaces manual knapping (and other voxel minigames) completely and once turned on can't be turned off. It shouldn't be a convenience feature or a solution to the problems of the system, but a way to allow more people to play the game. I've outlined real solutions to reduce the tedium of the crafting systems a bit further up, the easiest solution is just to increase the default weapon and armor durability.

I can see the problem with the grindy voxel mechanics, though I think they are part of the games identity, so removing them completely is out of question. For an accessibility mode, I recommend Skru's suggestion: Minus the skills that is. The idea is simple, just hold right click and the voxels will be placed/removed automatically. This perserves the visual identity of the crafting, as well as the balancing for material, tools and time. This should however not be the default mode but as I said just an accessibility mode for those players who need it. I think it belongs in the world configuration screen, but as this feature would work seamlessly in Multiplayer, the option could maybe be in the options menu instead, but then I fear the majority of the playerbase using it because it being slightly more comfortable. Maybe some chat command to enable it in multiplayer instead? While this accessibility option would "fix" the voxel crafting for those who need it, the mechanic in general could also use some upgrades to make it less tedious, because especially the clay working can get tedious. Knapping, personally, I don't find that tedious, since it is only early game anyway and is really quick compared to the other processes. Did you know that when you disconnect a piece of voxels from the recipe, that piece gets automatically removed so you don't have to knap every voxel, just the ones around the tool? This small change has made knapping even more comfortable, but not everybody may know it exists. The clayforming can be unbelievably annoying when the player doesn't know about tool modes. Just press 'F' and you can select 2 by 2 or 3 by 3 placement or an option to automatically copy the previous layer. I personally have a grudge against tool modes, because they are hidden to newer players, are unimmersive and annoying to switch. The 2 by 2 placement has the additional problem of only being centered on one of the 4 voxels it covers, could be "fixed" by 3 additional tool modes for every other corner, but that would probably make it even more confusing and hard to use than it already is. I feel like the tool modes for kapping could be easily replaced by a more powerful and slightly more intuitive mechanic: Click and drag. The player clicks on a voxel and drags a rectangle to another voxel and all voxels within that drawn rectangle get a preview while dragging and will be removed/placed upon stopping draggin. The size of the rectangle could be limited to make it not too simple, I think 9 voxels of content as a maximum would probably feel right. This especially makes drawing lines easier, as the player can easily place a long line of 9 voxels with just one click and drag. As some players don't can or like holding down their mouse to click and drag, an accessibility more could be implemented to make it two clicks, one to start dragging one to end it. The accessibility mode may be considerable as a default option, as it prevents the player from missing the feature, like tool modes, as he can't simply place a voxel by just right clicking once. For the mid game I could very well see a turntable for automated clayworking being implemented, like how there is a mechanical hammer for smithing right now. I feel for smithing it is kinda harder to make it less tedious and get rid of the tool modes. Since there is a way to partially automate it (mechanical hammer), I don't view it as such a huge problem. Especially forming ingots from bloom is kinda meant to be tedious, to make the mechanical hammer a more worthwile upgrade. I imagine steel, which will be added in 1.14, will be somewhat easier to produce in larger quantities, as it doesn't require working a bloom, so it would eliviate the problem even more. An additional tool mode to upset (the one voxel move) a line of three voxels (so it'd be like moving each of the three voxels individually one voxel forward) would be helpful in many recipes, making smithing a bit less tedious. I personally tested (modded) this mode as a replacement for the normal upset, which would also work fine and make smithing require a bit more thinking. For selecting tool modes I have some ideas, but they would generally make smithing a bit harder/skillful and thus may not fix the problem of being tedious and are not something for this thread. A simple way to make a lot of smithing less tedious is allowing starting a recipe from a plate, additionally to starting from an ingot. I have also easily modded this into the game. As the plate can be automated with a mechanical hammer, smithing things like chainmail becomes a lot easier. Additionally to changes to single voxel crafting processes, there are also two general solutions to make any/all of them less tedious. One thing that could be done would be to lower the resolution of the voxel grid, essentially meaning both fewer voxels to manipulate and bigger voxels that are easier to interact with. The drawback of this is needing to redo the recipes and losing detail and thus making it slightly less visually appealing. I feel like this could make especially knapping easier, but for clayforming I feel it would disconnect the finished models from the ones created in the recipe too much and for smithing I feel setting the voxel resolution any lower would produce some gameplay issues (3 wide/2 high ingots is already present and I feel like it is already the smallest the ingot should be). Another easy option to make knapping and smithing less tedious is increasing the tool/armor durability, meaning the player would just have to engage with the systems far less. There is already a world configuration setting for this, but I feel like setting the default higher would be a good decision.

Vintage Story's combat has some fundamental flaws, that need to eliminated before any new combat mechanics are introduced: This small clip highlights the two main problems: Disconnected attacks and wrong timing Wrong timing: This is the smaller issue of the two and is relatively easy to fix. The issue is that attacks hit after the animation has been completed instead of during the animation. This makes timed dodging or blocking of attacks much harder, as the visuals deceive the player. In gamedesign, attacks can be seperated into three phases: The windup that is used to notify the player of the attack and the type of attack, giving him some time to to react, the actual actual attack during at the end of which hit detection will detect if the player has been hit or not and the recovery, when the attack has either hit or missed the target, giving the player some time to act. The drifter attack animation has a short recocery, when the hit frame is seen is the swing at 90 degree angle to the starting position, having being the closest point to the player if the player would stand directly in front of the drifter. But the hit frame is, as seen in the clip, after the recovery, when it should be in fact before it. The drifter is not the only example of this, the problems described here apply to all NPCs in Vintage Story. Disconnected attacks: The second issue is that although the animation indicates that the attack clearly missed, the attack still hits. This is a huge issue for gameplay, as it makes dodging attacks sideways or into the enemy impossible, leading to the common technique in many games with bad combat system: backpaddeling. Getting distance from the attack is the only way to escape it, so players constantly walk backwards in combat, while trying to outreach the enemy. One extra thing to note in the clip is that the animated attack should not only miss the player because of the rotation, but the reach of the drifters attack is exagurated, hitting more than range the animation actually has. The animation reach at the hit frame and the actual reach of an attack must match not only for NPCs, but also for the players, which attacks have even more additional range, to ensure attack readability in PvP and PvE situations. The attacks of the drifter seem to simply check if the player is in range of the attack and are completely disjointed from the animation and orientation of the drifter. While actual weapon swing simulation with real time detection if a weapon hits a target is not required, proper hit detection, checking if the player is in the attack cone of the enemies attack, is. For the player, cone based hit detection would also make sense, making hitting targets easier and differentiating the sword from a short range gun. The design of many, if not all attacks in the game should also be fundamentally reworked: The enemies should generally not rotate during the attacks, so dodging sideways or into the enemy is possible, attacks like the bighorn sheeps charge should not be like a homing missile, but like an actual animal charge, first getting some distance to then charge at the player, either hitting on a collision or continuing for a while past the player on a miss. Drifters could use a forward lundge attack in addition to the swing, to close distance and force the player to force the player to dodge sideways rather than backpeddeling.

Brewing alcohol is something that is planned for the game, specifically update 1.14, and without there being a hydration system, there would be very little gameplay reason for it. However the inclusion of alcohol brewing as a mechanic opens the game up a very interesting and fun idea: An alchemy system, in other words a potion and poison brewing system. The goal of the system is not only to allow players to temporally buff oneself for certain tasks, but also reward players for exploration and experimentation, offering them an amount freedom. The alchemy system should therefore also act as a puzzle, to offer enough depth that experimentation and mastering the system is actually useful, rather than there being an easy way to always produce a perfect potion. An alchemy system obviously starts at potion/poison effects with the status effect system. A status effect should have a variable duration and a variable magnitude. After the duration has expired, the status effect is removed from the player. The magnitude determines how big the impact of the effect is, what it actually does is dependent on the type of status effect, for a healing effect it would improve the amount of health restored per second. Instant effects are possible by having a very low duration. Some examples for status effects: Healing: The player regenerates X health every second for T seconds. Harming: The player loses X health every second for T seconds. Exploding: The player explodes with a strength of X after T seconds. Haste: The player breaks blocks X times faster for T seconds. Status effects obviously aren't limited to the player, they work on any living entity. The same status effect can exist multiple times on one entity, meaning that the player can drink two potions to heal faster. There needs to be a menu players can access that lists all active status effects, with their description, magnitude and remaining duration. So what has this to do with alcohol brewing? Alcohol acts as a solvent and base for tinctures, which carry these effects. To create a tincture, an alcoholic beverage must be aged inside an aging barrel together with any number ingredients of ingredients. Alcoholic beverages can be made in several ways, producing different types of wine, beer and booze. By oneself, they don't do much, they maybe provide some nutrients or saturation and certainly make you drunk. As the base for a tincture they have three stats that vary depending on the type of alcoholic beverage: Duration, magnitude modifier and base toxicity. The duration determines the duration of the effects of tinctures made with this beverage as base. The magnitude modifier modifies the magnitude of the effects of tinctures. The base toxicity determines how drunk you'll get from drinking this beverage or tinctures made from it. Toxicity is actually an important gameplay system rather than just a bit of fun. Consuming beverages and tinctures will raise the drunkenness of the player. A bit of drunkenness will just give the player a slightly blurred vision (a depth of field effect, never the nausea effect Minecraft has, because only the player character should get nausea, not the actual player). It will get more blurred as the drunkenness increases. Next thing would be slight camera movement without player input, making the player character harder to control as drunkenness increases. At some point player input will be delayed and then the player characters will move about a bit without player input. As vision gets so blurry that it's almost as if the player character was blind, at 100% drunkenness the player instantly dies. Drunkenness thus acts as a limiter to tincture consumption, so players can't just drink ten healing potions at once and be invincible for a minute. (And I admit, it's probably a little funny too, looking at Deep Rock Galactic) Drunkenness on the player constantly decreases over time, so if you don't become addicted to tinctures, it should be easy to manage. But how do you actually craft a tincture? Well it starts with the ingredients. Ingredients are a type of item that doesn't carry effects, but contain alchemical elements. There can be multiple elements on any ingredient and multiple of any element too. So horsetail as an ingredient may contain 3 aqua, 2 terra and 5 umbra. You can see the elements represented by icons with numbers representing the quantity on the tooltip of the ingredient. When you add ingredients to an aging barrel, they will be dissolved and the elements they contained get added to the beverage. You can dissolve as many ingredients as you want into a beverage, even dissolve multiple of the same ingredient, and all the elements get added up. So when dissolving two horsetail, the beverage will contain 6 aqua, 4 terra and 10 umbra. Adding sulfur (4 ignis, 1 umbra) to it, it will contain 6 aqua, 4 terra, 11 umbra and 4 ignis. If a beverage in an aging barrel contains the same amount of different elements, like the 4 terra and 4 ignis here, the tincture created after aging the beverage will get the combinatory effect of that combination. Any combination of two elements will yield an effect, so as long as there are two elements of the same quantity in your aging barrel, the created tincture will have an effect. This allows the player to experiment and discover the effects different combinations. Some effects may appear in multiple combinations, meaning it is possible to get tinctures that apply the same effect twice, which would make for a tincture twice as powerful. While you can add as many ingredients as you like to your beverage, the lower the amount of elements in a combination, the stronger that combination will be, or in other words, the higher the magnitude of the resulting effect will be. So a combination of 1 terra and 1 ignis will produce a more powerful effect than a combination of 4 terra and 4 ignis. Each effect on a tincture will also increase the toxicity it by 25% of the base toxicity. All elements that aren't included any combination also decrease the magnitude of the tincture by a small bit. This means that you want go get close to no unnecessary elements in your beverage for it to be most effective. Only when the aging barrel is sealed up the combinations are locked and after a set amount of time you will have your tincture. The tincture can be filled into bottles, flasks or water skins and consumed by the player by simply drinking from those. Alternatively the tincture can also be applied to weapons and will apply the effects of the tincture to enemies upon hitting them. Applying 10 portions of a tincture to a weapon will yield 10 hits applying it. For the earlygame there should also be ways to utilize the alchemy system before brewing: Paste Instead of an aging barrel a player can use a pestle and mortar and instead of alcoholic beverages he can use animal fat or honey as a base. Pastes are created with the same system as tinctures, but their big advantage is they don't possess any toxicity. However they can only be applied to wounds and are generally much weaker than tinctures, but last longer. To apply a tincture you don't eat it, you apply it to a bandage and wear that bandage on an armor slot. While the wearer doesn't have full health, the effects of the bandage are applied. Bandages decay over time, like food. After it is decayed, the effects will no longer be applied. When toxicity is the trade off for tinctures, bandages using an armor slot is the trade off for pastes. Good ingredients are hard to come by and they almost always have more than one type of element, however there is an endgame way of extracting certain elements in their purest form: The alembic. The alembic operates very similar to an aging barrel, in the sense that you need to supply alcohol to it and can dissolve ingredient into it. Instead of sealing the barrel, you light a fire under the alembic and instead of being able to use any alcoholic beverage as base, it needs pure alcohol, which is only obtainable by repeated distillation of beverages in a small distillation tower. The alembic, while similar to the aging barrel, turns the alchemy system on it's head. Upon lighting the fire, types of elements are of the same amount, and therefore would combine into effects, get evaporated with the alcohol. What remains is a fine powder only containing the remaining elements. This powder is an ingredient itself and can be used for creation of tinctures or further refinement in the alembic. Encouraging experimentation and exploration While the system would work, a quick look on the wiki could make finding the right combinations and ingredients trivial. To make this impossible, the effects that appear on combination of elements should be randomized per world, only the elements on the ingredients should not be randomized. Upon creating a tincture or paste, the discovered effects from used combinations should be added to a searchable list in the survival handbook, so players can easily look them up. Alchemical recipes, outlining the effects of element combinations should also be able to be found in ruins as loot, which are also added directly into the handbook upon reading. Pure alcohol, alembics and powerful ingredients could also be ruin loot. Eating an ingredient containing two different elements of the same amount should also discover the combination of those elements. Implementation discussion While I think the system is quite elegant and easy to understand (only the less equals better aspect may be a bit counterintuitive), there is a problem regarding the implementation: How many elements do there need to be? The number of possible combinations and thus possible different effects can be very simply calculated with this formular: nC = n! / (2 * (n - 2)!) nC ... Number of possible Combinations n ... Number of different Elements As the number of combinations would probably not always exactly match the number of effects, there would need to be duplicate effects, which is a good thing, as it makes more useful and general effects like healing more accessible. I'd argue each effect should at least have two combinations that produce it, many effects may even have more. 16 elements would yield 120 possible combinations, which would allow for 60 effects, if every effect would have exactly two combinations. As there likely won't ever be more than 60 effects in the vanilla game, I think this number is fine. Effects would have a weight value assigned to them that determines how often they appear in combinations compared to other effects, so the randomization process can assign the effects to combinations properly. Each effect is however at least assigned to one combination. This would make the effect system easily moddable, allowing the creation of new effects. However as there is the hard limit of 120 combinations with 16 elements, it should be possible to add new elements. Elements are assigned manually to ingredients, so this would also require new ingredients or edits to existing ones, which shouldn't be hard to do. What do you think about this system after you got to the end of this wall of text? Any feedback is welcome!

It is a sandbox survival game, not just a sandbox game. It should force you to do things. The default survival game mode should not have a completely skipable night imo, as it defeats a lot of the purpose of the night. Being just able to skip the night defeats the purpose of building up defenses, a simple fence and permanent light. It degrades the purpose of crafting armor. The bed is what ruined the Minecraft survival experience for a lot of people, as the game became too easy with it. And players can do things at night time, it's the best time to do the crafting and smelting, prepare food, decorate the interior of your base. Once a player crafted some basic wooden laminar armor, the night isn't even that scary anymore as drifters are not even a threat anymore. Quality of life features are generally a good thing, but this wouldn't be a quality of life thing, it would be a major gameplay change, that would also only effect single player. I'm however not against some world creation setting or mods that allow you to sleep through the night, this is just about the default survival mode.

Assuming trees generated by the world don't grow and there is no natural reforestation (i.e. trees planting saplings without player input), the performance hit would be limited to world generation only. Only player planted trees would cause a performance hit, but that should also be fairly manageable, as the trees would grow quite slowly, probably taking a few ingame years come close to the size of "naturally" generated trees. The difficult question is how to efficiently handle a tree as a entity. Having one "tree entity" assigned to every tree seems to be the most straightforward option. Trees generated by the worldgen don't have a tree entity, because they don't need it, they don't grow. The tree entity itself would be stored inside the block that was originally the sapling. The entity would store the positions of all blocks belonging to it and would only update those the tick before a growth tick or the tick when part of the tree or part of the tree is unloaded. Tree destruction should still be done by an algorithm on the axe and should not utilize the data structure on the tree entity, as that would require the data-structure to store the coordinates of the tree blocks in a tree data structure instead of a simple list and the tree entity belonging to the chopped tree would still need to be tracked down by an algorithm on the axe, as well as trees without a tree entity still having to utilize the old search algorithm on the axe, so the whole endeavor would not be worth it. The one tree entity per tree approach however comes with some negatives, like having to check the tree positions every now and then, at least before the growth of the tree, as any of them could be destroyed/removed. Finding and updating the tree entity whenever a tree block is destroyed is also a possibility, however there may be ways to exploit this, such as possibly just moving blocks with pistons in the future or using save game editing tools. Then there are always the problems that could arise with trees lying in more than one chunk, being partially unloaded. Another way to handle tree growth would be to have multiple moving tree entities on one tree. These "tree runner entities" would only simulate growth at their position (and maybe surrounding blocks for leave generation). On a growth tick they grow the branch and move to the next further from the root until they hit reach the end of the branch and then either extend/grow the branch or grow branching. A runner also deletes itself when it reaches the and of a branch or a branching, however at a branching it also spawns new runners for each of the child branches. A new runner entity would be periodically spawned at the root/origin of the tree. They would essentially allow running the tree growth algorithm over multiple ticks, preventing stutters at growth ticks that would maybe be possible with a "one tree entity" model, when it has to check the positions of all blocks. It also has the added benefit of having a lower memory impact, as the tree block positions don't need to be stored on the entities. The downside of this approach being that there is some additional overhead, as there are a lot more block entities that need to be taken care of. Block entity visualization would also be needed to allow efficient debugging, but this also allows for much better debugging of the growth algorithm and modding of custom trees as they would visualize the growth algorithm itself. Problems with multi chunk trees and unloaded chunks can also be handled quite efficiently, as loaded runners can run as usual until they are either destroyed by reaching the end of their branch or hit the border of an unloaded chunk, when they would, instead of deleting themselves, just wait until the chunk becomes loaded, potentially stacking many runners at the chunk border to be released and quickly running in a single tick when the chunk gets loaded. I personally prefer the second approach, for its more intuitive solution for issues with partially unloaded trees and being less prone to lag spikes.

Make a pickaxe and a hammer. When there are copper rocks on the surface, there is always copper ore underneath. With a bed, you can sleep half the night.