Erik

Generating a world with ocean borders is actually rather easy to implement, but there are some problems with the heightmap part. Having the heightmap either greatly limits the landfroms elevation changes or makes the heightmap useless, as 255 blocks world height don't allow for great variation. I think a much larger overhaul would be needed, involving changing the way chunks and chunk-loading works, which would be certainly be incompatible with the current worlds or at least require a decent effort to fix: Have chunk heights vary. Not just the blocks in the chunks, but the actual chunks, or chunk columns to be exact. This would allow for highlands, kilometers above sea-level, and oceans, kilometers below sea level, without needing to change the landform system, the 3d-noise system, in any way. To make the system work one additional feature is required: Infinite depth and height. Chunks below or above the chunk column would not need to be generated with the columns, since they are not dependent on the landforms. They are just empty chunks above and stone/ore/cave filled chunks below and are generated when the player is close enough to them. Infinite world height/depth would also sound cool for the marketing and is really something people expect with cubic chunks.

I think the way it's done right now, with repeating a north-south pattern covers both variants if the width of the climate bands and the world were configurable and also allowing for more than two poles. Oceans are something currently not possible in VS (without exploiting the system by creating hundreds of ocean landforms), because all landforms have the same size and changing that seems to be really complicated. I have an idea on how to allow oceans without it and a whole bunch more things, but it's most probably even more complicated.

Couldn't the sun/days just work normally on the eyeball planet just for the sake of gameplay? It just wouldn't be realistic, but so is turning the earth into an eyeball planet I also don't really see the gameplay benefit of the eyeball earth compared to the current repeating climates, other than that it's more finite. A finite world could also archived by just lowering the world size and widening the climate ring, the map would only visibly cut off at the poles and the sides. Other than that, I enjoy the idea of a wrapping donut-shaped world a bit more, it doesn't suffer from the corner problem and just needs tileable noise, like any wrapping world would.

While that's true, I think this concept is a bit harder to develop as a mod for me, because I need to create art assets for the different types of armor and their combinations, which I'm not good at. I also don't really see huge benefits of making a mod for this suggestion, as balancing can't be done in a representative way and the concept is not as hard to grasp as many of my other suggestions.

The most straight forward option would be to remove the whole rot mechanic and replace it with a proper composting mechanic, where you have to put your unwanted food in a composting bin or something, but implementing this new mechanic would probably require a lot of work.

Armor is something many players are wishing right now and I have some unique ideas for the armor system, so here they are: Most games handle armor in a very simple way, with every piece of armor having some arbitrary "armor value" and all "armor values" of every piece of armor the player wears get added up and damage gets reduced in some magical way dependent on the total armor value. While this system works, it only allows for linear progression and provides no choices for the player, higher armor value always equals better. Because the armor value is arbitrary, the amount of protection the armor provides is not clearly presented to the player. So my idea is to throw that all out of the window and provide three different types of armor, which all function differently, allowing the player to choose how he wants to protect himself. Three different armor types with unique systems for each may sound daunting at first, but it's actually really simple: Padding: Padding is the first type of armor the player is likely to acquire. Leather, wool, gamberson all are early game materials this type of armor can be created from. Padding armor subtracts a percentage value of the damage. That means a piece of leather armor may give 30% damage reduction, resulting in attacks only damaging the player by 70% of their damage value. Mail: Mail, unlike padding, requires metals to craft. Crafting a iron chainmail armor piece is also significantly more time intensive than a piece of gambeson. It may also provide much more protection, especially against weaker attacks. Mail armor simply subtracts its damage reduction value from the damage. A piece of mail with 12 damage reduction will reduce the damage the player takes from attack that does 15 damage to 3 damage, or a 10 damage attack to 0 damage. Plate: Plate also requires metal to craft, but in greater amounts that mail armor. While being the most expensive type of armor, it also arguably provides the most defense, most of the time. It is really an all or nothing type of armor. Plate armor has a deflection value which determines the chance to simply reduce the damage to zero. A piece of plate armor with a deflection value of 60% reduces any amount of damage the player takes to zero, 60% of the time, while 40% of damage don't get reduced at all. All types of armor have their purpose, unique advantages and disadvantages. The player should be able to equip two types of these armors on the same armor slot, effectively combining their defense. The damage reduction by padding is calculated after mail, to prevent it from being overpowered. Armor weight: To make armor even more interesting, pieces of armor should have a weight, which slows the player down a bit. Padding is generally lighter than mail and mail is generally lighter than plate, which is the heaviest. Different armor materials may also have a different weight, steel being lighter than bronze. This also makes using single armor types more viable, as they now have a speed advantage against using two types. Armor slots: A thing this system doesn't really allow is adding all armor values together to form a total armor value which determines damage reduction. Instead, attacks must always hit one armor slot, which could be determined by chance, like in TFC, or by detecting where the attack landed on the player. For PvP combat the latter makes more sense, it however requires there to be few armor slots. For PvE chance based makes a lot more sense, as for mobs aiming at specific body parts is no challenge. Implementing both ways is most likely the best way to go, as it allows for more exciting PvP, by placers having to target specific, lesser armored body parts for maximum effect and mobs don't always hit the unarmored spots. For mobs, mob specific hit chances make a lot of sense: Wolves should be way more likely to hit the legs than the head of a player. Ideally the system would also take the position of the attacker and target into count, if the wolf is at head height, it's most likely to bite the head and least likely to bite the legs. The armor slots that should be provides are imo: Head, body and legs. The head should have the smallest hitbox, the body the largest. Ducking should also lower the heads hitbox, so dodging attacks this way is possible. Being only limited to three armor slots however significantly lowers cosmetic player customization. To remedy this, different cosmetic variants of armors may be able to be crafted, like plate body armor with or without pauldrons. (Technical implementation stuff) Significance of arbitrary armor values: While not shown to the player, the armors should have arbitrary armor values in the code/json, instead of the flat reduction values or percentages the player gets to see. This has one important reason: Armor scaling. While a 90% damage reduction armor seems only 10% better than a 80% damage reduction armor, it's actually twice as good, letting half as much damage to the player. I.e. it has twice the survivability. And that is the problem, the survivability scales hyperbolic with linear scaling of the armor value. To fix this, arbitrary armor values need to be used in the code/json, which get calculated into the displayed armor value to scale linearly with the survivability. So 10 arbitrary value is exactly twice as good (twice the survivability) as 5 arbitrary armor value, which may account to 90% damage reduction and 80% damage reduction in the game for the player. Why is linear armor survivability so important? While the armor values can be balanced correctly to have a linear survivability curve, modifiers to the armor value that may be added in the future, like smithing quality, would still scale wrongly. While this can also be solved by programming the smithing quality system in a way that improvements increase the survivability linear, mods may not do this correctly, as the may not know of the problem. Armor penetration: While this system makes armors more unique, it doesn't really make certain armors much less effective against certain weapons. This can be easily archived by having armor reduction modifiers on specific weapons. These modifiers reduce the armor value of their type by their percentage: 50% padding armor penetration reduces a 80% damage reduction armor piece to 40% damage reduction for the damage calculation. The survivability scaling here is not linear on purpose, to make armor penetration more impactful than just having a weapon that does that percent more damage. Although, that is debatable and maybe having it lower the survivability (the arbitrary value) would be a better choice.

I don't think that the space requirement is such a huge issue. Especially with tongs, when rotating the working metal is possible, it would only require two accessible sides to rotate it in all directions. So slapping your anvil in the corner would be possible, but having it worked into the wall (only one accessible side, why would anyone even want that?) not. On another topic, I updated the prototype, no new features, but the timing is much more consistent, making it feel much better.

I don't think it would be too hard, it doesn't require perfect timing to get things done, maybe just to do them the best way. And even then, the timings are something anybody can learn with enough practice. Having different values for different metals would keep the system from being too simple. It doesn't really make different metals harder, just different and makes each a new learning challenge. Varying heat however would make things harder, maybe too hard, but that remains to be seen. To get the timing right would be the main challenge of the system so rewards should be based on that. How exactly the times needed to reheat and the hits needed influence the system is however very variable, it could even be different per metal, which would make each metal a unique and different challenge to master. To get some of the randomness from TFC, having to relearn smithing on every new world, the timings and quality variables could be randomized for each metal per savegame. That would make it a lot more replayable and a journey of discovery each time, but would also allow for less direct and purposeful design and make the game harder for beginners, as they can't rely on the wiki. As the system is not hard to implement, I have made a mod implementing the basics, so people can test out the idea. The mod is only a very basic implementation, it doesn't have a lot of features I suggest, but it has: Replacement of hammer tool modes with timing strikes The three described smithing techniques: Upset, cross and flat Stronger punches cool the metal a lot more, too weak punches also have a heat penalty What it lacks: Metal based timings Heat based timings A quality system Tongs Still has the pixel system in place Nice animations (They look stupid, but they work) My current implementation however has a big problem: The timing value is determined server-side. There is a rather significant, and most problematically varying, delay. It's not a problem of the system in general, just a problem of my implementation. I'm sure there is a way to fix it (making synchronization based on the client), however I'm not the most experienced modder. (Attention: Prototype updated and now on main post)

Smithing overhaul Attention: Prototype mod of suggestion attached Vanilla smithing, while visually great, is very shallow and quickly gets dull. This overhaul aims to fix that while also allowing for it to be more skill based and the crafted items having quality levels based on the skill of the player. No annoying tool modes anymore One button to rule them all Based on player skill Simplistic and minimalistic Actually also very realistic Master each metal separately No huge changes required No frustration by randomness The changes in this overhaul don't really effect the anvil or the recipe, it only really affects the "tool modes" or smithing techniques. First, we need to reduce the techniques to make this work, the only techniques required are: Upset Using upset on a pixel will make a pixel appear above that pixel. Only one type of upset now, the other directions are removed. The player has to move around the anvil now to perform upsets in different directions. If using upset on a pixel with an pixel above but none below, the pixel will be removed. Cross Using cross on a pixel will make 4 pixels appear adjacent to the pixel. Flat Using flat on a pixel will make 8 pixels appear around the pixel Now about how I plan to implement them without tool modes: Holding right click down on the hammer will charge up the power of the strike. Very low to low power strikes will do nothing at all to the hot metal. Low to medium power strikes will perform an upset. Medium to high power strikes will perform a cross. High or higher power strikes will perform a flat. In other words, the hammer progresses through the techniques, the longer the player holds the button. The player also can't tap the button to definitely perform a upset. With this simple mechanic change, the smithing can be easily made a lot more engaging. The player should not be able to see which technique he is currently on, the player should have to develop a feeling for the timing of each technique by himself. To spice up this, the power required and therefore the timing for every technique should be different for each metal. So players have to learn and master smithing each metal individually. (The progression of the techniques should however remain the same for each type of metal) Item quality can now be calculated from the number of strikes the player required to finish the smithing and the number of times the player had to reheat the metal. The heating system should also be tweaked a little: Cooling down should happen a lot faster, currently it's so slow that the player has to never reheat the working metal. Strikes should also cool down the metal, depending how powerful they are. This encourages players to make strikes only as powerful as they need to be, only holding down the button as short as possibly required for the needed technique. Instead of becoming suddenly unworkable at a certain point, the power requirements of techniques could begin to increase at a certain (metal dependent) temperature point. This lets experienced smiths still work colder metal and allows for some much harder to work metals with much more heat dependent smiting required. Further extensions of the system: Tongs. Hot metal should no longer be movable by hand, but require tongs. The tongs also let the players grab the worked metal on the anvil and place it somewhere different on the anvil or with a different rotation (No tool modes for rotating, the player has to move around the anvil with the tongs having picked up the metal). There should also be a preview of where the tongs would place the metal on the anvil. Instead of the working metal being finished automatically, the player would have to grab it with tongs and quench it in water or other liquids to finish it. The type of liquid could have an effect on the tool (quality or durability). To make the moving around of the metal actually useful, only metal on the anvil body should be workable, like RedRam suggested in his original proposal for the system. Changing up the anvils surface to be more interesting would also be a good addition for higher tier anvils. The player could use this to save himself doing some strikes. Finishing notes: A removal of the "metal pixels left" system would be appreciated, as it only makes things more complicated, while not really adding anything interesting. Prototype info: The prototype works, but it does only have the minimum features of the suggestion: Replacement of hammer tool modes with timing strikes The three described smithing techniques: Upset, cross and flat Stronger punches cool the metal a lot more, too weak punches also have a heat penalty What it lacks: Metal based timings Heat based timings A quality system Tongs Still has the pixel system in place Nice animations (They look stupid, but they work) smithing_v1.1.0.zip smithing_v1.1.1_for_1.10pre10.zip

The half-life system is not realistic, but not illogical either. I understand what you're getting at and Tyrons system is better in that regard, but it still has the stacking problems. There is a difference between losing a tiny amount of food and having the inventory full because of food stacks with different harvest dates. The player might not have a lot of food, but he certainly has a lot of different food types with different harvest dates. Yes, I though you were talking about a half-life system with time stamps, which would be the worst. Well, it can punish the player if he combines his small stack of very fresh food with the big stack of food, close to spoiling. The then would have lost the freshness of the small stack only to have the big stack last a tiny bit longer. So combining stacks still requires thought, so while it is a solution, it is not ideal. I wouldn't say that the half-life system is harder to balance. The relations between the half-life of different food would still be the same, double half-life means lasting double.

There is nothing illogical about a half-life system. Then radioactive decay would be illogical... Does the player need to know exactly how long his food will last? That would be pointless with this system, it doesn't help the player to know when he will have no apples, because he will have almost no apples long before that. He already has a good indication for the near future: Half the stack is gone in X days. It's not that hard to understand, as the player can see that it is ticking down in real time. The system is not scaling deeply unfair. In Tyrons system, no matter how many apples you farm, they would all be gone after 6 days. In my system many of them will be gone by then, but not all of them. Tyrons system punishes players for overproducing, making every apple overproduced a waste. In my system, every apple overproduced practically makes all the other apples last longer. Disguising the system with adding a constantly changing rate to the tooltip of stacks would confuse the player a lot more and give him false assumptions. The simple "Half the stack is gone in X days" is a much less confusing way to introduce the system. And if the person first thinks the system is a cliff system, he will shortly after see that A: The tooltip never changes, because it is always accurate. B: Food is going down over time. It will be least problematic to player in the early game: They don't store food, because they eat it all within a short timeframe. The system penalizes players for storing food for long times, that is correct and also what a decay system should archive. I think it's valid critique to say that it penalizes the player regardless of him having done a wrong thing and storing food for a long time, because the system constantly and actively takes food away from the player, while Tyrons system only punishes the player when he has been storing the food for a long time. Non-indefinite preserving obviously doesn't make the penalty go away, it just lowers it by having a longer half-life and therefore the penalty. The cliff system doesn't work. There would have to be a time stamp on stacks to keep track of when the stack will half. That would not allow combining stacks without issues. There are several ways of handling combining stacks here: A: Average the date between the two, weighted on stacksize. Works, but lets player safe food about to be halved by throwing it into a bigger stack in time. The whole system then also becomes much more confusing, because the time when the stack will be halved changes whenever the player combines stacks or even when new items get added to the stack. The player will have no idea when the stack will half, because that changes with every apple they pick up. This is obviously therefore a very bad idea and would make the system seem very illogical to players. B: Spoil what would be spoiled when combining stacks. Also works, but punishes players for combining stacks or picking up new items that would go into the stack, because then it would be updated and some food be lost prematurely. This obviously is highly problematic and hides the constant food loss by only making it appear when players do edit the stacks. This is also properly illogical: Why should combining stacks cause food to be lost? C They don't stack. This would work, no exploits possible, easy for player to understand. But it spams your inventory. It would be Tyrons system, a bit more complicated because food doesn't completely spoil, but gets halved when the timer runs out and then the timer would reset. So it would be worse than Tyrons system, because there is no huge gain from the half-life mechanic, other than making it a bit more complicated, because the timer resets.

Both. You can calculate in real time or with just a timestamp of the last update in an event based way when trying to minimize performance impact. Yes the infinity-problem is a thing with using a half-life. It can however easily be fixed: Just have the stack disappear if it only has 0.1 apples in it. The more food the player has, the more is going to rot. This is not a penalty for larger stacks, if the player would split all his stacks into smaller ones, the resulting loss in apples would still be the same: Half the apples after four days. For clarity, this is not tracking the start time in any way. The only thing that can be tracked is the last time the stack was updated to reflect the amount after rotting. From that point the size of the stack can be calculated. This will be useful for long term storage, where the stack doesn't get updated for a long time. 40 apples (It doesn't matter how they are stacked) will be 20 apples after 4 days, because apples have a half-life of 4 days. Half the apples will however not suddenly disappear at the 4th day, but they will get less at all times and they will be exactly 20 apples after 4 days. And after yet another four days they will be 10 apples, then 5, then 2.5, then 1.5, then 0.75, then 0.375. then 0.1875 and then they will finally be gone.

I mentioned Tyrons method of automatically combining stacks in the tolerance frame. Obviously making it possible to combine stuff with very different dates leads to all kinds of issues and the player will need to worry about these if he wants to combine stacks. And that's the problem, the player shouldn't worry about potentially wasting freshness of food when combining stacks. So yes, they can theoretically be combined, but that makes the whole method very prone to exploits and hard for players to predict behavior. No, the half-life would be handled constantly in real time. Half the stack of apples isn't removed every 4 days, but the stack gets smaller in real time. It doesn't even have to be constantly tracked, you can just calculate the state of an stack with the time of the last time the stack was updated, so there is not even a performance loss compared to Tyrons method. So to get back to the apples: A stack of 40 apples with a half-life of 4 days will be a stack of roughly 28,3 apples after 2 days. Any yes, it looks a lot like the ark system, because it is a lot like the ark system, there is a constant food loss. It is a problem, at least in ark. When storing multiple larger stacks in a chest in ark, they all decay into smaller stacks. The rate of decay is constant for each stack, so two stacks decay twice as fast as one stack. So when some time passes and the 40 full stacks turn into half full stacks, the rate of decay will still be the same. But if the player were to constantly restack the stacks, so there would only be full stacks and be less stacks, the rate of decay would lower. This encourages micromanagement on the players side, which is a problem. It may not be as realistic as Tyrons approach, but it is much more usable and I value usability over realism in this case. I don't think adding food poisoning is a good idea. Spoiled food is useless enough in Tyrons system, having lower saturation and nutrition. Making them potentially harmful will just cause players to get rid of them as soon as they become spoiled. In that case, it wouldn't make a difference if they were just removed from the inventory if the timer expired, with no stages of spoiling.

Added "The Hunted" update, focusing on a potential stealth mechanic

Previous threads relevant to the dicussion: For those who don't know, the next major update will introduce a new feature: Food decay. Food will rot and become less effective or turn into compost after a certain amount of time. Don't worry though, there will be methods of preservation introduced, so you can keep your food fresh for longer or even indefinitely at the price of more work and probably also lower nutrition. This feature is planned to be introduced alongside season, where the winter makes farming impossible. The players will have to household and plan food usage and conservation to make it through winter. Players will also be able to deactivate the spoilage mechanic, so don't worry if you are not a fan of the general concept. However this new decay system has some problems that I want to outline and how they could potentially be fixed. I'll first introduce the system as it is currently planned/started to be implemented: Food items/stacks each get a timestamp when they have been created. As time goes by, they will eventually start to spoil. When spoilage reaches 100% they will turn into a pile of rot an be uneatable. Eating items with a spoilage value will reduce the saturation and nutrition gained by that percentage, so you ideally want to eat your food when it still is fresh. The spoilage of a stack represents the spoilage of each item in the stack, and they will all turn into compost at the same time. Items with different timestamps don't stack, there will however be a certain tolerance for value differences, so stacks only a few seconds/minutes apart will still stack, probably gaining the average spoilage/timestamp of all items in the two stacks. The problem: The real problem with this system is the stacking limitation. It can easily result in the players having different stack of the same food, but with different timestamps, cluttering their inventory. This is a huge issue, because inventory space is already very limited in VS and micromanaging the different food stacks can quickly turn into a huge pain for players. This will be most exaggerated in the early game, because players have almost no inventory space then already and no option of storage either, as well as living from several types of berries they usually pick up some time apart from each other. As the early game is the most important part to get right from a marketing perspective, this is unacceptable. Possible solutions: TonyLiberatto suggested having the timestamp only record the day of harvest. This will lead to all food being harvested on the same day stacking and while not fixing the problem, makes it much less noticeable. But this workaround comes with its own problem: Players are rewarded for harvesting their food at the beginning of a day and are punished for harvesting them at the end of the day. This may not sound dramatic, as food harvested at the beginning of the day will only last a maximum of a day longer compared to food harvested at the end of a day. But as a day is 40 minutes in VS, that is a quite considerable amount. A real solution to this problem would be to implement decay in the same way as Ark Survival Evolved did it: Food stacks have a spoilage meter constantly ticking down and when it reaches zero, the stacksize is reduced by one. Combining stacks would also combine the values of the spoilage bar. This system of decay works very differently and constantly spoils some food into compost rather to spoiling it all at once. Stacks can now be combined without limitations, so that problem is eliminated. The system however also has a huge problem: Splitting your food into two stacks makes it spoil faster than having it as one stack. This forces the player to micromanage his stacks again. This is because the rate of decay in constant and not relative to the size of the stack. There is however a way to fix this: Rather than having a constant decay rate, stacks would just need to have a half-life. The half-life of the stack describes the time it takes for a stack to loose half its food. This half life would be the same on each stack of the same type of food. Example: Apples have a half-life of 4 days. A stack of 40 apples will a stack of 20 apples after 4 days. Two stacks of 20 apples will be two stacks of 10 apples after 4 days, so still 40 apples turning into 20 apples. With a half-life, the sizes and number of stacks don't matter, the same amount of food will always decay after any time. This completely removes the need for micromanaging your stacks and makes combining them possible at all times. There is however a small problem: That if you have 40 stacks of 1 apple? Won't they just all be gone after 4 days? This problem stems from stack sizes being whole numbers and not having any decimal or lower values. This can however also be easily fixed by emulating the decimal point with a durability bar: Decay will slowly lower the bar over time, until it is empty: Then the stacksize gets reduced by one and the bar is filled up again. Eating half an apple will obviously also only give half the saturation and nutrition of an apple. This would also have other benefits, such as showing the decay in real time, having players be able to eat half an apple if they are almost saturated or crops dropping not 1 or 2 food items, but any number of items between 1 and 2 items, like 1.6 carrots (representing a carrot and a smaller one). Problems with a half-life system: While the player only needs to understand one thing (Half your apples will be gone in 4 days), the system is definitively harder to explain and understand. Confusing the player is never good and this system might also potentially confuse players. The bigger problem however is, that the compost resulting form the rotting food has no way to go. In Tyrons system, it just takes the place of the food, as the food gets turned into compost at the same time. This flaw in my design will also lead to cluttering of inventory space by compost. This however isn't the big problem, as all the compost from all food stacks, but when there is no inventory space, the compost has nowhere to go. It would probably need spill on the floor, which isn't good. Fixing all problems of both systems with one change: Making inventories weight based would solve all problems, as there wouldn't be a competition anymore over inventory slots and better inventory management features could be implemented.

I also feel the game could use a bit less micromanaging, especially when it comes to the inventory management. Constantly having to eat food is a nuisance and I think it could be fixed by having a bigger focus on the nutrients: Food saturation lasting longer, but the player can only eat when he is hungry and most food don't give much nutrients, so to max out nutrients, the player would not need more food, but better quality food. There could be less of a danger of starvation, but less nutrients weakening the player more. Regarding the RPG aspects, I'm entirely against them. While such aspects are an easy way to make systems feel more rewarding, it also often leads to the player having to grind. Mastery of the games systems doesn't come from playing well, but from playing long enough to have a leveled up character in character skill based game systems. I rather support a focus towards player skill, where not the time playing and the amount of grind done is the deciding factor in success, but the players skill and knowledge. Instead of the characters farming skill leveling, the player should have to learn how to effectively breed plants. Instead of the character smithing skill determining the quality of the sword crafted, the players skill at forging and knowledge of creating good steel should determine the quality of the sword. This obviously requires to design game systems with a lot more depth, but that is also the point of it. Game systems shouldn't be reduced to skill checks and level-ups, but systems with a learning curve and a high player skill cap.

Höhlen nach dem Erz zu durchsuchen ist generell die beste Idee. Wenn das auch nicht hilft kann man mit etwas Geduld auch Kasserite mit einer Schürfschüssel schürfen (Pan, panning, weiß noch nicht ob das schon in der aktuellen Version übersetzt ist), Kasserite ist Zinnerz also kann man damit Zinnbronze herstellen.

The problem is that most people today have a very short attention span, so they will watch three minutes and then form their opinion of the game. These players don't get to see most differences from Minecraft, but all the similarities. And most people also mod QoL things into MC, so they are no huge benefit to them. That is certainly something I want to see, but as it is more of a midgame thing, it won't be visible in the first impression of the game for many players. It is not a pressing matter, so it may be better to implement it later. For me the grid crafting feels rather out of place compared to the other crafting mechanics, it's just there to remind people it is in fact a Minecraft clone. Other than that, having to look up the recipes for it is also a drawback. Maybe not, but it at least should try. I imagine the reason why so many youtubers haven't made videos about it, is because it is too similar to Minecraft and there are little mayor improvements, just different features and graphics. I think we need at least on "WOW-feature" that VS has against the competition and I think that would be utilizing cubic chunks to generate impressive world gen, like huge mountains. Sure, Hytale has a different focus, being more of a fantasy RPG. But Hytale succeeds to set itself apart from Minecraft and is a direct competitor for parts of the playerbase of VS. In the absolute worst case, Hytale is vastly better on the core features of a voxel game and people mod VS's features into it, making VS redundant. Details are nice, but Minecraft also has many details. Details just don't sell the game, as marketing 1 big feature/improvement is much more effective than marketing 100 small details.

While it would certainly help, it would still not prevent comments like "This can be done in Minecraft with mods" or "This is just a Terrafirmacraft ripoff". Especially with Hytale coming closer to release, there need to be some unique stand out features, so it can compete against it. Hytale is going to have a standard world height of over 256 blocks, probably 512 and while VS has a configurable world height, anything above the standard height takes ages to generate and is unplayable to the way world generation only scales vertically. I really want VS to succeed, but the current situation worries me, as the length time it took to release the last update and the lack of some essential features in it (world configuration screen, configurable climate, oceans/landform size) shows, that VS needs more coders and thus more money to hire them.

The "big marketing push" happened and while it probably doubled the player count, it wasn't hugely successful, only animating four moderately big youtube channels to create videos. I suspect the increase in sales is only temporary and will drop of after a while. But why is this the case? Why didn't more channels make videos of the game? The comment sections of the new videos provide a clear answer: "This is just a Minecraft clone/copy, I can do this with mods" While it is quite harsh critique, it holds some truth. The first impression of this game is far to similar to Minecraft: Similar artstyle Similar stack/slot based inventory system, even with offhand Similar 256 block height world gen Similar trees and plants Similar stats: health and hunger Similar crafting: 3 by 3 grid Similar bad combat Similar crafting stations: Campfire = Furnace Similar premise: Monsters appear at night It's not like there aren't things that make VS different from Minecraft, but they are often overlooked and overshadowed by the first impression. Even when considering the new things the vast majority have been done or are doable in a similar fashion with mods for Minecraft. The reason why it is so similar is because Vintage Story is a Minecraft mod turned standalone. What has had most people interested were the unique crafting mechanics, because they truly were something new and original. But the mechanics are admittedly, while visually impressing, very shallow and repetitive, which has also been often brought up in the comments of the new videos. So how can we fix all this? Changing the artstyle is something way too time consuming with no gameplay benefits for existing player, so that is out of question, however the other points are things that can be done: Making the inventory system weight based, rather than stack/slot based Utilizing cubic chunks, having a nearly infinite world height and impressive terrain Making trees less blocky, more dynamic Adding thirst and stamina Replacing the crafting grid Improving combat, adding depth Reworking the campfire to be more unique and GUI-less Focusing on GUI-less blocks, removing GUI from exiting blocks Making existing unique crafting less repetitive and adding more depth The problem is that all these changes take a lot of time to implement, some aren't even designed yet, and we only have Tyron who can code those things. I imagine the most effective changes would be the infinite world height, weight based inventory and GUI-less blocks as they are something that is not really possible in Minecraft, even with mods. Even then, these changes would sadly take a lot of time, which could be spend on new features, but having these changes implemented later makes their implementation even more difficult.

I simply don't see a need to add some maintenance that is not automatable. Most players would probably chose not to fully automate everything, because it would be a huge and difficult task. So most players would therefore have to do some maintenance, but not because they have to, but because they chose to, because they found it easier to once in a while add fertilizer themselves than to automate it. And why should players not be able to chose to fully automate it?

Yes, as well as localized weather. But it might takes some time till it is implemented, but it'll definitely come

Machine maintenance is something that is still in somewhat active discussion. I personally am very against it. The game is a sandbox survival game not a pure survival game, if everything would decay and require maintenance, the players freedom would be heavily limited. Why should machines decay when a player build house doesn't? They both serve a purpose, protection or production, and thus generate some rewards. Decaying every achievement of a player is just frustrating and maintenance tasks are often extremely repetitive and boring. People want to build machines, because they want to remove or lessen some repetitive and boring gameplay loops. I'm however not fully against maintenance, however all maintenance should be able to be automated. Maintenance like supplying your boiler with fuel and your mill with grain. Full automation of even a single system, like an automated farm, should be difficult, coming with many engineering problems to overcome, while partial automation is comparatively easy. This signals a shift in gameplay, as the old struggle of manually doing things is replaced by the struggle to solve new problems with machines. Having to run around with a cleaning rag, polishing every gear of every machine simply doesn't fit here from a gameplay perspective, apart from being probably hugely annoying. Not to imagine how frustrating it will be for people on servers, who may log in after a week, only to find all of their machines broken. There will come a point in every game where the player will have reached the end of the progression and there is nothing new left to do or archive. Repetitive, hollow routine tasks will not keep the player invested, it might just drive him away from the game. The things he should be doing now is what he wants, it's a sandbox, he can finally build something without being limited by the survival aspects of the game, the game needs no arbitrary gameplay loop to keep him invested now.

Some thoughts: Decay and the resulting need for maintenance is of course something very prevalent in survival games. It's basically what hunger, thirst and tool durability are. They are the struggle, a force directly fighting against progression. Only when the player can overcome the struggle can he progress and when he falls victim to it his progress will slowly diminish. In an ideal survival game the player always overcomes the struggle and moves forward at a constant speed archiving a good pacing and constant motivation. But games usually aren't ideal and players are different. The player may overcome the struggles and progression may make maintenance too easy, removing the struggle and ruining the pacing. The player may not overcome the struggle, losing progress and motivation. Player punishment is very important, because a struggle without failure and the resulting learning and improvement of the player is just a grind. As punishment, the player needs to lose some progress. However punishing the player to much is demotivating, punishment should only be small setbacks to progression. Punishment also needs to be relative. If the punishment for not having eaten in a long time is bigger than the punishment for death, players will chose death. This is for example often the case in Minecraft, where being hungry limits your ability to run, which leads to players often killing themselves and afterwards just picking up their stuff, as it is far less punishing than having to get food without being able to run. When combat inflicts lasting wounds, slowing you down, death and having to pick your stuff up afterwards seems like the better option. Adding more decay also adds more struggle, which adds more maintenance and more punishment, which makes progression slower adds more progression setbacks, which are in turn even more significant. This can very quickly spiral out of control and ruin the fun. As player progress directly counteracts the maintenance, this can also go the other way, where players who have progressed very far experience no struggle at all. They will probably get bored to death, also diminishing the fun. So what is the solution to all this? A good way to avoid this problem would be to introduce new struggles with progression. When the player has build a farm, the struggle for food and the system of hunger is largely eliminated, however food decay becomes a new struggle. Old problems can be solved, providing a sense of progression, but new problems arise. Of course, the game can't constantly introduce new problems, because progression can't be endless. The question now is if the player should be able to solve the last problems or not. Not being able to solve the last problems obviously leaves the player with something to do, but nothing to archive. Being able to solve the last problems leaves the player to archive, but nothing to do afterwards. A pure survival game would now either become repetitive, boring or end. But Vintage Story is also a sandbox game, where the player can set his own goals, like building a huge castle. It therefore makes sense to make the last problems solvable, so the player is able to archive his own goals for once, having him finally beaten the game.

While electricity makes for a simple control system, it still doesn't really fit the setting of VS. It also has been done many times before, in Factorio or Oxygen Not Included. Gear driven computing however fits more nicely with the setting, while also being much more unique and fancy looking. "Clockwork engineering" sound much cooler than "Electrical engineering" and also has some gameplay benefits: Gears have clearly defined constraints and make for a more interesting puzzle, as their placement is naturally more limited.