Jump to content


Very Important Vintarian
  • Content Count

  • Joined

  • Last visited

  • Days Won


Erik last won the day on June 18

Erik had the most liked content!

Community Reputation

37 Excellent

About Erik

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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)
  3. 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
  4. Erik

    Food decay

    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.
  5. Erik

    Food decay

    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.
  6. Erik

    Food decay

    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.
  7. Erik

    Food decay

    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.
  8. Erik

    Future updates

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

    Food decay

    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.
  10. 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.
  11. Erik

    Erze finden

    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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?
  • Create New...

Important Information

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