Jump to content

Erik

Vintarian
  • Posts

    263
  • Joined

  • Last visited

  • Days Won

    41

Everything posted by Erik

  1. I feel like I don't have to really go into the "why" of this suggestion, but to keep it short combat in Vintage Story currently is somewhat lackluster, yet a fundamental part of the game, it is present in hunting, fighting monsters and fighting players. This suggestion tries to improve combat to a much more fun state. I focus on PvE, as that is obviously the focus of the game, but try to throw in some interesting mechanics for PvP, where it doesn't hurt the PvE and isn't too complicated to implement. Furthermore, I will not have stamina as part of this combat system, but something very different to fill its place. The Attack: First, lets focus on the most basic combat action, an simple attack with a weapon. Right now, at best, attacking weapons with unique animations feel like chopping away at enemies, with a simple screen shake to make it feel like you hit something, even when you don't. The animation for the spear and flax is always the same and keeps repeating while holding down the button. Especially for the flax, this feels more like chopping wood than attacking an enemy, which is admittedly still better than the weapons without animations, like the clubs. There is also a weird animation mismatch between the first and third person animations for flax. The first simple change I will suggest is removing the repeating attacks on holding down the button. One click should equal one attack. Holding down will charge up a heavy attack, more about that later. One thing I will try to get out of the way first are weapons, which double as tools (i.e. can be used to break blocks) like the knife or non-weapons as well as your empty hands. They are primarily useful for breaking blocks by holding the left mouse button. They shouldn't be effective as a weapon and are thus simplified: No heavy attack. Clicking or holding down the mouse while looking at an attackable entity will cause a (repeating) attack animation, like the weapons currently possess. This animation can just be the basic chop animation, as it will be shared for all non-weapons. While mining a block, an attackable entity moving in front of the target reticle won't be instant hit by an attack, but the mining process will just be stopped. The animation for weapons should be split into three parts, separate phases of the attack: The chargeup. Here the weapon will be raised, but isn't on the way to its target yet. The attack can still be canceled. The swing. The attack is now rapidly moving towards the enemy, unable to be canceled. At the end of this animation, the hit check happens. The aftermath. The animation here is different depending on what happened during the collision check. On a hit on a blocking target, it will recoil On a hit on a parrying target, it will recoil more violently On a hit on a non-blocking target, it will stop and shake a bit On a killing blow, it will slow down a bit but keep on moving through the target On a miss, it will just keep on swinging through the air for a bit These animation stages have significant gameplay and user experience relevance, especially the aftermath stage. The different aftermath animations provide significant feedback for the user and should be matched with other effects, like unique sounds and screen shake only on hits instead of on all attacks. The miss animation should also be slightly longer, to punish the player a bit. It is obviously not possible to attack while the aftermath animation is still playing. Movement during attacks: During the attack chargeup, the attackers directional movement should be slowed down. The strength of the slowdown could vary by the weapon used, with heavier weapons slowing down the player more. This would make attacks feel more powerful and also makes running away a slightly more viable strategy. During the swing phase of the attack, the player should still be slowed down, but just not in the direction he was moving when starting the attack. This simulates the attack propelling the player slightly forward and makes the player feel change from chargup to swing. Directional Attacks: This is a small (gameplay, not asset wise) and not essential but nice feature. Instead of having only one animation (with varying aftermath animations) for each weapon type, each movement direction (forward, backward, left, right) should have a unique animation. The direction of the attack is determined by the direction of movement while the player started the attack. Left, right attack: Horizontal swing Back (and standing) attack: Forward stab Forward attack: Vertical overhead swing The different animations would mostly be visual, to not favor specific attacks causing weird player movement. Only the hit detection would be different, with horizontal swings using horizontal 2d cone based hit detection,overhead using vertical 2d cone based hit detection and stabs using ray (or thin 3d cone) based hit detection. This obviously depends on implementing those hit detection methods, which would make swinging melee weapons feel less like shooting extremely short range guns and more like actually swinging something, while not coming with the issues of real time collision simulation like performance or gameplay problems. Heavy Attacks: When holding down the mouse for a bit instead of just clicking, the player would perform a heavy attack. It has unique animations, with the chargeup animation being significantly longer. If the player continues to hold down the mouse button, the attack won't progress past the charge up animation and will just be hold at the climax until the player releases the mouse button. While holding the attack will not make the attack even stronger, it lets the user decide when to attack, which may be especially useful in PvP or when fighting alongside other players. Other than that, heavy attack also differ from regular ones in various ways: They do more damage. Their effect on movement speed is stronger, to make it feel even more powerful. They break blocks and aren't effected by blocking as much. They stagger targets they hit which aren't blocking or parrying Stagger: Most attackable entities including the player should be able to be staggered. While staggered, the staggered entity can't move (aside from being knocked back a bit), can't attack, but can still defend by blocking or parrying. Stagger comes in three strengths light, medium and strong stagger, which differ just in length of time and animation, each having a unique animation per entity. This would obviously mean a lot of new animations, but since hit animations can just be scaled in length for a start, unique ones for those can be introduced later. Stagger on players should also be shorter compared to stagger on non-player entities, to make being staggered not too punishing and unfun for the player. To prevent stagger locking from being a problem, stagger should be on a 5 second per entity cooldown. While under this cooldown, any stagger is just converted to a short interrupt, which cancels attacks. Stagger makes attacks feel much more impactful as well as providing an opening to attack for players. Attacks of opportunity: This is the "stamina replacement" system. The goal of stamina was to prevent the player from spamming certain behaviors like heavy attacks by incurring a resource cost. Attacks of opportunity also represents a cost, but a defensive one. Not just melee attacks, but any type of attack becomes an attacks of opportunity, when hitting a target that is currently venerable to attacks of opportunity. Any attackable entity including the player is venerable to attacks of opportunity when: When staggered When in the windup phase (including holding the attack) of a heavy attack While drawing a bow While running While under blocking cooldown An attack of opportunity does more damage and staggers the target, making them much more powerful. When a power attack, which would normally also stagger the target, is an attack of opportunity, the strength of the stagger will be higher. Blocking: Right now, defensive actions in Vintage Story are rather passive and somewhat clunky. Instead of blocking when the player is sneaking and blocking being chance based, blocking should not be chance based and only happen actively when the player presses the right mouse button. Equipping a shield would therefore override right click actions of weapons, like the throwing of a spear. Some weapon types, like swords, should also be able to block on their own, without a shield, at lower effectiveness. While blocking, damage received should be mitigated (based on shield used and attack received) and the blocking players movement speed should also slow by quite a bit. Being hit by a heavy attack while blocking will cause blocking to be stopped and a short blocking cooldown prevents being able to block right again. Attack cancellation and redirection: Pressing the right mouse button while attacking and still being in the windup phase and not under the block cooldown, the attack will be canceled and, if not a heavy attack, directly transition into a block. Pressing the attack button again on a light attack during the windup phase, while not under block cooldown, will cause the attack to restart (with the new attack direction the player is currently moving in), however also occurs a small block cooldown for the length of the windup phase. Parrying: When the player presses the left mouse button while blocking, he should perform a parry. While blocking during stagger is possible, parrying during stagger isn't. A parry has a short animation and if an attack hits during that animation, its damage will be completely blocked, some sparks fly and a satisfying metal-on-metal sound plays. After the parry, regardless if actually having defended against an attack, there is a small cooldown, until blocking is possible again. Since the player is venerable to attacks of opportunity during this block cooldown and unable to defend via blocking, missing a parry leaves the player in an especially bad position. Parrying primarily functions as a defense against heavy attacks, since normal blocking is somewhat venerable to those. Attack blocking: This small, mostly PvP focused mechanic, requires each weapon having four directional attack animations. When an attack hits another entity that is currently also attacking and still in the attack windup phase in and in the same direction as the attack, the attack deals no damage to the defender and a satisfying sound effect plays and some particles spray. While this defense is even harder to pull of than a parry, having a short time window and requiring matching directions of the incoming attack, it also doesn't stop the attack of the defender, making it a deadly tool. Thanks for reading and feel free to provide any constructive feedback, positive or negative in the comments.
  2. I personally really disagree with the notion that 1.18 is a letdown when it comes to world gen. For all that changed, a lot also stayed the same: The landforms, i.e. the general shapes of the landscape, barely changed, basically only adding 6 new landforms, just increasing the variety in world shapes. The real big change to world gen is also quite a simple one: Vertical upheaval, which is simply smoothly raising or lowering the terrain (in some areas), which mixes with the landforms to create a lot more vertical variety in the terrain (and there are optionally also oceans, basically doing the same thing but always lowering the terrain and in a much more limited area). These changes lead me to generally observe more varied, interesting and believable terrain. The best thing is how the vertical upheaval leads to a much grander scale of the world, as it is now less flat with giant vertical mountain walls in-between, but also but features some gradually rising huge mountains with real valleys. There are still a lot of areas that look exactly like 1.17 world gen, uneffected by vertical upheaval and oceans while using old landforms. It only adds to the variety, which is imo the most important thing for world gen.
  3. The devs are aware of this post, but this post is a bit outdated now that we got some updates to combat. A big thing the devs are generally against is a traditional stamina system. Their reasoning is that they want the players to focus on the enemy rather than status bars in combat, which is a understandable reason. So the whole blocking system would need to be rethought also including some insights into the current blocking system. I plan to make a post on that and the armor/damage systems/balance (since they are kinda related to it) sometime in the future, probably.
  4. I didn't propose getting rid of the sandbox gameplay in any way or form. I'm just suggesting adding environmental challenges and story based reasons to take them on. I also didn't say that these challenges would punish players for not pursuing solving them. I suggest you look at Subnautica. It is in many ways the best example of what I mean. It is even a survival sandbox game (with horror elements), so I don't see any reason why a comparable approach wouldn't work in Vintage Story. Something as simple as starting with a (player class specific) note, talking about an important place in the southern jungle, with some description of the challenges the player would face there and what preparations would be suitable. There would be a rough map marker on the minimap. The player can still chose to ignore the note. There is always the option to just make certain blocks indestructible until the player has "opened the lock", though that requires a lore explanation to not seem out of place, but it is definitely not something that is entirely unthinkable. Though, I rather thought of systematic locks, not actual locks. Think extreme weather like blizzards or sandstorms, areas of extremely high temporal instability. The keys would be things like proper clothing, bringing firewood, proper weapons to defend against enemies, special devices to combat the instability, etc. That the game is set in a randomly generated world posses some challenge for implementing such natural barriers without having every world feel the same, but I don't think it would be that hard to add a huge desert with a unique structure deep inside it somewhere randomly on the map. Your definition of open world is also very narrow. Is Skyrim not an open world game because you can't access Sovngarde from the start or after you have been there? The only games maybe somewhat included in your definition would be Breath of the Wild and maybe Morrowind (may be very hard to accidentally run into Baar Dau at the start of the game). But things like Minecraft? Arbitrarily closes of the nether and the end, definitely not open world. It would only be linear, if there is only a single lock with a single key (and a single lock behind that lock and only ever one lock behind "deeper" locks). Though that would just be linear progression (which is already a part of the game), the story pieces could just be out of order or even in random order, then it would still be non-linear storytelling. But the reality would most likely be that there are multiple locations the player can tackle in any order, finishing locations often revealing a couple other locations. I'll quote the roadmap: Procedural dungeons, Add story rich game content, About a dozen main story events, Improved combat, A number of high-stakes boss fights Such gatekeeping can only hurt sales. A lot of people really enjoy the game for the exploration, as it is undeniably a huge aspect of the game and already really fun. Survival, sandbox and horror aren't only pillars this game is build on. Furthermore "story" is featured prominently in the name of the game, although not much of it is currently implemented. So not expanding on exploration and story would also definitely "betray the expectations" of many players. Just expanding on another pillar doesn't betray the others.
  5. I think exploration challenges would be a good way to solve (or at least delay, eventually you'll get burned out on any game) the "player burnout": Currently the main challenge of the game is survival or more specifically surviving the winter. That can be divided into some sub-challenges, like food, shelter that can be divided into sub-challenges of their own like preservation, storage, protection, etc. So the player will start making basic tools, collect wood, build a house, get some farming going, do some pottery, create some charcoal, process some copper, etc. When the player gets to having a copper anvil, most of the games content is unlocked for him, as he can craft a saw. This is also the point when the survival challenge is basically solved. Wooden planks allow for really easy, cheap and quickly craftable storage solutions, leather working, efficient building blocks, animal farming and even some mechanical automation. The time freed up means having more time to focus on food, trivializing the food problem. Now the game really turns into a sandbox, as survival is trivial. There is stuff to do, but much less incentive to do so. Better materials and tools are more convenient in the long run, but not really necessary by any means. Things like bee keeping are cool mechanics, but strictly optional. Player motivation doesn't recede from a lack of content, but from a lack of challenges. New challenges to be exact. There is still the daily grind like tending to your fields, checking the bees, feeding the animals, etc. the trivial solving of the ongoing food challenge. Adding more challenges of this variety, i.e. ongoing challenges, like a thirst bar, building degradation or rusting tools would just further the grind, not adding more fun but more tedium. There need to be challenges the player can overcome without them coming back to haunt him. A goal the player can archive and then move to the next goal until there are no more goals and challenges and the game is effectively done, like a story the player can complete. There is no need to try to make any challenge indefinitely engaging, even sandbox games are allowed to have ends. It's not like the player can't continue playing in a sandbox style after "completing the game" if he can make up his own challenges. The type of challenge I personally want to see the most are exploration challenges. The general "loop" would be "Go place X find story piece with the next location". The game that had me engaged quite a bit with this was Subnautica. The games main motivation was exploration and story took a bit of a back seat. The areas to be explored where very varied and unique, coming with unique challenges like different sea monsters, difficult navigation, requiring better submarines or upgrades. Another great example of exploration driven gameplay is Hollow Knight, which although it is in a completely different genre still had me hooked mainly by exploration (really fun combat plus a great soundtrack). Exploration focused games like these often utilize the "locks and keys" design pattern, where locks represent challenges to get to new areas and keys the solution to them, often requiring solving other challenges to get them. A simple example would he a cave blocked by an alaskan bull worm you need distract with cake. It creates the challenge of having to bake a cake, which requires farming and other steps. The reward is being able to explore the cave and get whats in the cave, which would probably be some story content, some stuff and another lock or a key or a pointer to a new location. Traveling and exploring are already my favorite activities in Vintage Story and are currently only required in a limited fashion to get stuff like clay and ore, optionally things like tropic crops. Traveling in Vintage Story always requires some preparation, like stocking up food and food and requires the player to build shelter on the fly and deal with encounters. By providing story goals, the player could be heavily incentivized to travel to new unique locations. The preparations may include getting things like iron or steel, because they are keys to some lock at the location. Then there could also be unique obstacles: Having to cross the north pole, requiring warm clothes and bringing firewood for the nights. Polar bears being a huge threat and requiring adequate gear to defend against. Oceans requiring boats to cross. Jungles having to deal with disease. Deserts needing water at day to protect against the heat and warmth at night. Mountains you need either climbing gear to pass steel tools to tunnel through. Underground caves, dungeons and cities where you need to solve puzzles and fight enemies. These ideas however come with a challenge of their own: preventing frustration. Traveling for hours only to find that you need to return and create a steel pickaxe is definitely something the player should experience, challenges that require extensive prior preparation need to communicate this before the player even starts to solve it. Traveling for an hour and dying being reset is also not fun, nor is the player traveling back simply by dying, the respawn/spawn point system may need to be overhauled to be more manageable on huge journeys. The items dropped by dead players shouldn't be able to despawn, further preventing mayor setbacks. This type of exploration challenges of course provides less replayability, but I think there is enough other content in the game and the possibility for different starting areas and mods that this shouldn't be a cause of concern. The goal isn't to create a game that is endlessly playable, but a game that is fun, even if not endlessly.
  6. I strongly disagree. In a game where every single animal except chickens will try to kill you if you even dare as come to close, where the main threat of the night isn't the cold but drifters attacking you, there is a strong argument that combat is already a huge part of the game. If the intent was to create a realistic survival game, most animals would flee from the player, a simple fire could scare of wolves and drifters wouldn't be a thing you can actively attack yourself. And there wouldn't really be things like plate armor and most importantly swords if the games focus was purely survival. Even from a pure survival perspective, where fleeing wolves should be your only option, the current combat is broken. Hit detection is very unpredictable, the range and timing of attacks totally disconnected from the animations: Those problems need to be fixed or combat needs to be completely removed from the game. Then you at least have something that isn't broken. But combat still wouldn't be fun. The "strategy" players currently utilize is building three block high towers directly under your feet to get out of the range of the enemy and then stabbing till it parishes. This isn't clever or fun, this is just exploiting weak AI. In 1.16, drifters will at least be able to throw rocks at you which should mitigate the issue a bit, but wolves will still remain powerless to the might of three soil blocks. The AI is currently also a huge fan of walking into two block deep holes or trenches they can't get out of, which is an easy way to eliminate the need for walls. I don't think such AI issues can be entirely eliminated, but I think the need to use such exploits can be reduced. Having a more responsive and fun combat system would directly benefit hunting, defending against wolves and drifters, exploring caves, etc. Activities that players currently either don't engage with (caves) or exploit (hunting). Or to keep it short: There currently is a lot of combat in VS and it is not fun. Instead of relying on players using cheap exploits to get around combat the combat should be improved. How to improve the combat to be fun is still very much in the air, but I think adding more depth, providing defensive and better evasive options would definitely help.
  7. Erik

    Class survey

    I think the classes in the game should take a radically different approach. Rather than being balanced to roughly the same "usefulness" as the commoner, they should act more like additional challenges, radically changing the when chosen and always being generally inferior and harder to play than the commoner. Therefore the malus should not just be a small collection of some small percentage reductions, but a rather drastic disadvantages like: Not being able to eat meat (or another food category) Not being able to cut down trees Hunger damage when in sunlight Freezing at temperatures below 5°C Frightening animals in a large radius Double tool durability damage rate Inability to sleep etc. There would also need to appropriate advantages, to provide some reward for taking on the unique challenges, like: Night vision 100% faster mining/tree chopping/digging 25% slower hunger rate Ability to eat dry grass etc. Such classes are obviously much harder to design, since they should be uniquely challenging while not tedious, but they provide much more replayability, especially in a singleplayer environment, since the main draw for classes is not the advantage, but the unique challenge they offer. In multiplayer, their unique advantages still provide the ability for players to specialize, especially when their disadvantages can be covered by other players.
  8. I think rivers and oceans could add huge gameplay as well as aesthetic benefits to the game, when combined with reworked world gen and water mechanics. Rivers are imo the best examples of this, since they could offer the most in terms of gameplay: Generally better soil quality and more frequent clay near rivers Farmland near rivers will be moisturized, only river water should moisturize farmland Waterwheels powered by rivers enable more constant mechanical energy Small canals (8 blocks max length) build from rivers enable watering even bigger areas Canals or aqueducts powered using mechanical energy enabling even better farming or even transport of floating items Rivers could work without oceans, but then they would be limited to being flat like in Minecraft. Realistic rivers flowing downhill require terrain generation on a larger scale to be able to be implemented. River generation needs to be done in separate larger areas, where a river from one area can never interact with one from another area. The best way to do this would be by dividing the world into continents. Each continent would be surrounded by water, the ocean, seamlessly dividing the continents from one another. The ocean wouldn't be very wide, as the continents form a grid, so traveling from one continent to another shouldn't take very long, I think something like one to two kilometers of oceans between continents would fit the best. Here is a quick blender visualization of a few heightmaps I generated that demonstrates the general layout of continents (imagine the most left column was also offset): A benefit with this layout is that on each continent only has six neighbors instead of eight, meaning that when creating a new world, only seven instead of nine continent maps need to be generated and only three instead of five when entering a new continent. The continents are basically just heightmaps, where each pixel represents a chunk column. These values would not just have an effect on the generated terrain, they would offset the whole chunk column vertically. This allows far greater scale, greater heights and deeper depths, while not having to raise the world height or change the chunk or world generation system entirely. The ocean level would stay static and not be offset with the chunk columns, meaning that this system automatically creates oceans, when the heightmap is low enough to submerge the terrain. Rivers will be generated with the continent, meaning they will realistically flow downwards, towards the edge of the continent and therefore into the ocean. I'm currently experimenting a bit on implementing river based terrain generation to work for generating such heightmaps. Generating those continents with rivers doesn't need to be done often, but will probably take a few seconds, so there needs to be a bit of a compromise when it comes to their size. I think 512 by 512 pixel representing 512 by 512 chunks would be a good size, meaning the continents are a bit bigger than 16 times 16 kilometers. This means, traveling south the player needs to cross an ocean to get to the tropics, but as oceans between continents shouldn't be wider than two kilometers, it wouldn't take long with a boat, maybe 10 minutes. 1024 by 1024 chunks would also be an option, offering roughly 32 by 32 kilometer continents, making crossing the ocean almost match crossing the equator, but coming at the cost of requiring at least four times as much computation and therefore time. Other than continents using vertical chunk column offset giving more scale to the terrain and creating oceans, there are also several benefits to them: Oceans allowing for saltwater, salt harvesting, islands, beaches, marine life Continents having distinct flora and fauna (maybe even people/cultures) mimicking real life Temperature and rainfall changes taking advantage of the bigger scale, no more sudden shifts by a few blocks high hills More realistic rainfall and temperature distribution, depending on the heightmap Landform appearance dependent on chunk column offset, allowing for highlands landforms, ocean landforms, etc. Every continent connected by the same ocean, making travel by ship really useful Small inland oceans dynamically appearing, being natural barriers for traveling Enabling realistic rivers, always flowing downhill into an ocean and complex features of them, like river deltas
  9. I think these are part of a more general problem area: Multiplayer. For singleplayer or coop these are not really big issues imo. Some trees being a rare and importantly limited good is imo a good decision, as it makes them more into a treasure or luxury of sort, much like aged wood although less extreme. Making them indefinitely farmable would ruin that status. In multiplayer however they aren't just rare, they can quickly turn unobtainable because of other players, which is a issue. Though I'd rather have a wood trader be added that sells or buys medium quantities of these for high prices, also opening them up as a real trade good, than just making them infinitely farmable. This is also mostly a multiplayer issue. While I, as stated before, think a "forecast" system is necessary, the issue is only really exaggerated in multiplayer, when not playing "frequently enough" can see your crops dead quickly and your food rotten. Keep in mind that developing such a system takes time and just that 1.15 is now released doesn't mean that it won't be added in the next version nor that it will. The big issue with multiplayer is the time focused aspect of the game, that the world keeps progressing even when the player is not around. This can be a great thing if playing singleplayer and venturing out into the world will still have the unloaded chunks process, providing a real sense of time. In multiplayer however, even when your not playing, the time will likely resume as someone is likely playing. That means crops will grow and die, food will rot, seasons will pass. So you log in after a while, only to find that it's night, during a temporal storm, in winter, while all your crops are dead and your food is rotten. Then your option is only really to log out again, hoping next time you log in it will be summer, so you can actually play the game rather than just having to focus on finding scarce food in winter. I don't really have a solid idea of how to fix this. One small improvement might be to let the player decide where he wants to spawn when spawning as a new player. And by where I mean which hemisphere, as that will offer reversed seasons, maybe longitude could even provide different times of day. Though that would not fix the issue, just hide if from new players. Currently there is a compromise with the default setting between multiplayer and singleplayer, that arguably makes singleplayer too easy and multiplayer too hard. The year is really long in singleplayer and everything takes more time than it should maybe reasonable do, while food decay is also really slow. In multiplayer, a year is often really short, multiple months often having passed after a player logs in again after one or two days. Since the time only passes when there is at least one player on the server, the speed of time is also variable, making proper planning near impossible. Personally I recommend playing singleplayer or coop with tweaked settings if you don't want to experience the same required daily time investment as games like Rust or Ark. Or playing on a server which has seasons turned off and slow food decay. I think the idea is that you should water your plants regularly, which is not a bad idea, just has the multiplayer issue again. Personally I think the Minecraft-like "adjacent water providing moisture on farmland" mechanic should be completely removed. When rivers are a thing, they or canals build from them could provide the same but stronger effect. I also think the level of moisture having a direct influence on growth speed or maybe yield in the future is not really such a good idea, since it encourages constant micromanagement to keep your crops fully moist. Ideally it should be not be a linear system but a segmented system of sorts, where there are specific moisture ranges where any value within the range still returns the same boost. I don't think its a bad mechanic, just a bit to impactful currently. Like, the push effect should be reduced by quite a bit, maybe by something like two thirds. Currently walking on a windy day feels like fighting against a huge blizzard or hurricane, which is a bit silly.
  10. There are rough grow times already on the tooltips, but you are right that growth time can vary a lot from that, since all the mechanics around plant growth (nutrition, water) are influencing growth time. But I still think providing potentially lightly misleading information would be better than no giving information at all. Moreover, growth times are planned to be changed to be longer, more realistic in the future, iirc. So players would likely only get one harvest of grain in a year. Then faster growth times don't really make sense as the reward for fertilizing and watering, as the player would likely still only get one harvest per year, regardless if he "maxed out" on fertilizer and watering. The plants may grow a bit quicker, but since there is no time for another full cycle in that year, that doesn't translate to additional harvests, it has no real benefit at all. It would then make sense to move to a new balancing lever: Yield. With longer growth times, yield would need to be increased anyway, so it would make sense to then move the whole system over to a yield based system. Growth time would change to be static, unaffected by nutrition or water, so the tooltip on the seeds wouldn't even be misleading anymore, the plant would become harvestable after the fixed growth time. Nutrition and water would now determine how many yields (and maybe even seeds) the plants will drop upon harvest. Plants could potentially even be grown beyond being harvestable to increase yields further, rewarding trying to maximize growth times and the additional fertilizer and watering investment. I don't think areas with common rain are such a big issue. The problem probably is that rain can last rather long, I think shorter but more frequent rains would serve areas like rain forests in the tropics better. You have to understand that weather is intentionally a bit on the longer side, because the snowfall simulation needs it, for it to be accurate and performant enough, but since it never snows in the tropics, some tweaks could probably be made. I think this is a critique that can be applied to many areas of the game: Timed events (winter, night, temporal storms) locking away gameplay options. I don't think it in itself is a problem, but when there are no or too few gameplay options left, it leaves the player in a state where he isn't playing but waiting, which is a problem. Ideally, these events open up new gameplay options, like combat in temporal storms or nights or temperature management in winter, but these are currently not really enough, considering how much especially temporal storms and winter lock you out of huge gameplay chunks. Temporal storms currently only allow for either fighting (or waiting/fleeing, which I wouldn't consider a valid gameplay option) and winter doesn't allow for any agriculture, gathering or hunting (since animals have reduced drops), which are huge chunks of the game, agriculture is arguably the most fleshed out gameplay aspect of the game currently. I left out the night, since I think it is in a good state right now. The night limits options, since monsters will spawn, but there are tools to diminish its impact (building a house and setting up light sources) and nights, while frequent, are rather short. Vintage Story is first a survival game and a sandbox second, time management is a very important aspect of the survival side, on the day the player may travel and gather resources, hunt and care for crops, in the night they may cook meals, do pottery, work metal and craft. Winter however has two problems: First, the default winter is way too long in singleplayer or coop. A month has 9 days by default, which makes 108 days in a year. Roughly a quarter of that is winter, 27 days, which are each 48 minutes long, totaling at over 21 hours. I suggest turning the single player default down to 3 days a month, which makes the year "only" a third as long. Still rather long, but much more reasonable for singleplayer in my opinion, the player shouldn't have to play almost a hundred hours to experience a whole year. The second problem is that I think there is not enough to do. Agriculture, hunting and gathering are a huge chunk of the game that becomes impossible or significantly less rewarding in winter. I think at least hunting should be encouraged to to in winter, since it realistically makes the most sense. While I understand domestic animals dropping less meat in winter to encourage feeding, I feel non-domestic ones like wolves shouldn't have reduced drops and potential additions in this category like deer also shouldn't. When bears are introduced, they would likely sleep inside their den during winter, encouraging hunting in winter even more, since it would be less dangerous. A deeper, more involved hunting system could then help further.
  11. I will disagree here (I could be wrong in my assumptions, I'm not a developer of the game like you, but I have some knowledge of the code), it should be rather easy to implement. I wouldn't disagree without a specific reason, but the weather already gets forecast: For the snow-accumulation simulation. Admittedly, that whole implementation is rather complex. The thing I want is much simpler and easier to implement: Just getting the time when the temperature will be too low or high (or low or high enough) for a plant to grow without taking frost damage. It's not a telling the player if it would be wise to plant the crop, but it helps. The implementation would just be sampling the local temperature until the value gets too high/low or high/low enough for damage. This can be done rather fast, so it can be done on the fly. Since sampling is not entirely accurate (even with sampling each hour within the year), the value isn't either, but that is not really a big problem, since even the worst case scenario wouldn't have a lot of frost damage. Temperature sampling is already something that is technically in the code (https://github.com/anegostudios/vssurvivalmod/blob/master/Systems/Temperature.cs), but the current implementation is broken for some reason, probably not updated to recent changes. All of this is based on the assumption that forecasting frost damage would only require knowing the temperatures and that getting temperatures at specific times is rather trivial, which could be wrong, I'm not an expert, but even if it is wrong, I'm interested in what assumption is wrong.
  12. I do agree and disagree with a few points. I support the reasoning behind making rare trees hard/impossible to farm. They are supposed to be a limited resource, something truly rare. It's not like this has any gameplay implications, there are other trees to use. Thought the tiny cypress seed drop rate may be a bit too small indeed. For farming, I'd want some definite info on the tool tips when the temperatures will drop out of that plants range or when they will drop into the range. Something like "Growable here for 16 more days" or "Growable here in 4 days" when looking at the seeds or crops themself. It wouldn't be realistic, but it would allow proper planning, which I feel would be much more valuable from a gameplay perspective. The user still has to manually calculate or estimate if that is enough time to fully grow the crop. I don't think the bread "nerf" was too bad. Meals in crocks are the intended food for travel and they last for a long time, a cellar can also be build everywhere really quickly. While I don't think the update caused a lot of inventory problems, I'm generally for a bit of a rework in form of a weight based system, as it would solve all these problems and allow for more inventory management improvements.
  13. I heard a similar rift idea before, although a long time ago, before temporal storms existed, shortly after Drifters were first added to the game in 2017, from Saraty (VS Lead Modeling and Texturing Artist). It was originally planned for Drifters to eventually not spawn randomly based on lighting anymore, but appear out of warped portals that occasionally appear on the surface. Since the spawning mechanism still hasn't changed, it could be that this idea was scrapped.
  14. The problem with just that would be, that they would still be kinda forced to just wait for the whole duration of the storm. The aim of my idea was to give players something (repairing) to actively do during storms (that additionally rewards preparation and well designed bases) rather than combat. Also, something completely different I forgot to mention: I don't think players should be allowed to skip storms by simply sleeping, so they shouldn't be able to sleep during the storm and be awoken when sleeping when a storm starts. I'm not really a fan of sleeping generally, since it generally allows the player to just skip any danger and at least during temporal storms this shouldn't be possible imo.
  15. The problem with temporal storms right now is that they are just annoyances. Combat is not a fun activity in Vintage Story yet and even if it were, not everyone would be someone who enjoys combat gameplay alone. Since storms also have no rewards for surviving or engaging in them (other than higher temporal gear drop chances) and no real punishment for failing them, there is little incentive for the player hide or log of. The fail-state of a temporal storm is also not very fun: You died and now you are even more likely to die again, since the storm still persists, but you lost some of your gear. I think that if a player dies, the storm should end for him, i.e. he should not be in the "Rust World" anymore, not seeing any drifter anymore. That would require a slight rework and instancing of mobs between the normal and "rust" world, which I'm not sure already exists with the current temporal stability mechanic. This prevents storms from becoming a spiral of death and unfun. To make dying however less of a desirable way to skip storms, dying during a storm should have special penalties, like lower health for a few ingame days. There are two main ways players would probably want to engage with storms, either engaging in direct combat or otherwise avoiding direct combat. Better combat would make the engaging in direct combat more fun, but not the avoiding of combat. Players needing to avoid combat during temporal storms is not something that can be entirely prevented, since some players simply dislike combat gameplay altogether and players may not be properly equipped to be able to have a good chance in combat. Scaling difficulty could solve the second point, but that would potentially be hard to do without opening it up to easy exploits and would also undermine the different intensities of temporal storms. The best solution would be to significantly improve the non-combat way of surviving storms, making it more engaging, challenging and fun than the (what I'd personally rather consider as) exploits that are even outlined on the official wiki: Hiding in a box, pillaring, sleeping. This could be done in a number of ways, my personal idea would be to extend temporal stability mechanics and integrate them into the storms. During a storm, the temporal stability of players should be constantly sinking. The normal effect of temporal storms would also need to be changed, drifters would still spawn in high amounts on the surface, but they wouldn't spawn so close to the player, that would now only happen if the players drop into low temporal stability during the storm. This can obviously be avoided by raised temporal stability by successfully engaging in combat and using temporal gears. When failing to raise temporal stability, the player should instantly or really quickly die at zero temporal stability. This will prevent players from hiding inside holes. The alternative to direct combat would be "base defense": Drifters and potentially other mobs would slowly try to get to the player, even through their bases. They would slowly "shift" blocks between them and the player, slowly turning invisible. During this process the player can repair the blocks to stop the process. However, once a block has been successfully shifted, it can't be repaired anymore and mobs can move through it. After the temporal storm, shifted blocks are restored to normal, so one could think of this as mobs "temporarily destroying blocks". Repairing would give back some temporal stability, the goal of the player is not to completely fortify against drifters but to actively defend against them to stay temporally stable. Lastly, I think successfully surviving a temporal storm should be rewarded. I think something simple as giving the player three additional health points until they die would be appropriate, stacking up to three times, to a total of nine additional health points after surviving three temporal storms. Since they stack, players would be even more incentivized to survive additional storms to either keep their high additional health or gain it.
  16. FYI, it would not be hard to implement something like a parry, in fact it would be easier than a knock-back system. I don't think the current combat is fine, it is the least fun part of the whole game. And I feel like copying Minecraft won't help either, since that games combat system is also very controversial for a lot of people. Knock-back on the scale of Minecraft would make the game too goofy, too easy. Knock-back only ever really worked for Minecraft before sprinting, afterwards the game turned into a short range movement shooter where the player frantically runs around trying to hit things, since the running plus the knock-back would make it effortless to keep alive, which is definitely not a direction VS should take. The most important thing the game needs is an attack animation for the sword, like the spear currently already has. The combat range also needs to be tuned down imo. Everything currently hits a meter further than it should, making judging distances near impossible. Another huge problem is the enemy behavior: Best case they directly walk at you and attack. Worst case they either jump at you at 100km/h from a kilometer away and still hit you while they are two meters away from you (wolves) or they try to walk up to you and maybe decide to attack in rare cases, where they will then just wave at you, while you can get out of their range, because they don't move during attack, except turning around instantly when you are close enough to them, even though you were behind them (difters), also hitting you from a meter further than they should. Getting enemy AI and behaviors in a good state is certainly not an easy task, but a critical one. I feel like collision based attacks for animals and better (cone based) hit detection for drifters is a must, as well as improving enemy movement. Some behavior where enemies circle around the player instead of running directly at him is critical. Some basic enemy group coordination is also critical. Imagine instead of wolves directly running at the player, they would try to sneak up on him, preferably in groups, would fight by circling around the player, prefering attacking when behind them, maybe faking an attack from the front, so another wolf can safely attack from behind.
  17. I think a free-form attack system might be way too difficult to implement in a non-glitchy way that works for multiplayer. To make the third person animations for it work is not an easy feat and to make them readable for an opponent is really difficult. When the sword is simulated to have proper collisions there is also a severe performance and network impact. Games that focus on melee combat like Chivalry and Mordhau have struggled with animation glitches and readability, even though they are much less free-form than the proposed system might be. I think a much better way to implement it would be to make it limited to 4 different attack directions instead of having it free-form and instead of simulating the sword and having proper collisions, the collision should remain being calculated once for the attack at a fixed moment during the animation. Much easier to implement and much more readable to the player, less possible glitches. That would however possibly make locational damage too precise for the player to aim, although even with a free-form system it might be too unprecise. Or it might be too trivial to always hit the head or other targeted body part. I'd probably leave it chance dependent like it is now, but have the different attack directions have different chances for hitting different bodyparts, so players at least have some ability to aim at specific weak points, while that would as a positive side effect also make it easier to predict which way they will attack and thus easier to block. Instead of special effects for different body regions, the only difference should imo be armor. That prevents players from always focusing on a specific limb and makes it more adaptive based on the enemy armor.
  18. While this suggestion would make the game more realistic, I don't really see such a great gameplay benefit to to, in fact quite the opposite. It would make the already quite useless heavy hammer strikes even less appealing to use and make moving one voxel at a time, the most tedious way, the optimal way to play. Making the temperature also have an effect on durability will increase the tedium even more, as the player is encouraged to reheat the piece all the time. I'm quite indifferent to the material vs material system, I don't think it add much from a gameplay perspective other than encouraging players to upgrade their hammer sooner, but it also doesn't really take away anything Thought, I feel you might be onto something. Hammer durability could and should be used as a reward for more skillful smithing imo. Maybe some "perfect strike" timing based mechanic where the glow of the hot metal slowly and periodically pulses and hitting the metal when the brightest will make the hammer not lose any durability and produce a unique sound effect. It wouldn't be that realistic, but it would add a small element of skill to smithing.
  19. So you are saying people would still go for the "cracked" version from shady sites instead of (illegally) sharing a bought copy with friends if there was no authentication required for singleplayer? Then it means the lack of authentication doesn't even mean slightly more pirates as I suggested, but the situation would be no different from how it is now. One time authentication wouldn't effect latency and when there is already a authentication token it wouldn't even require a internet connection to play LAN, just like singleplayer is setup now. The actually important note to take away from this study is that it found no statistical evidence that video game piracy actually hurts sales, unlike other forms of media piracy. Even if less DRM on Vintage Story would cause more piracy (which is just speculation), that doesn't mean that the game would suffer lower sales. It's not really. Sure, the authentication doesn't expire, but you can't install VS from an USB-stick on a system which is not connected to the internet and play singleplayer. You need to login once to get your authentication token. And if you say that can be easily bypassed, then why is this needed in the first place? I just don't want singleplayer requiring authentication, mainly to future-proof Vintage Story. There may come a time when the authentication services are down (maybe permanently) and people can't play their game anymore. It is maybe unlikely for it to happen in the recent future, but not unthinkable. As for the risk of doing that, I think it is really low. Te change causing more piracy is somewhat unlikely and even if it did, more piracy doesn't equal less sales.
  20. But that is true for any pirated version, no matter the original protection or lack thereof. The only thing that becomes more likely with singleplayer needing no authentication would be people giving their friends copies, which already requires a genuine purchase and the friends would be likely to still buy the game to play together. DRM doesn't incentivize purchasing a game, I'd actually argue that the lack of DRM is more of an incentive to purchase a game (as shown by the success of GOG). There is also a study commissioned by the EU that claims that video game piracy may actually increase sales (https://arstechnica.com/gaming/2017/09/eu-study-finds-piracy-doesnt-hurt-game-sales-may-actually-help/), so saying that no DRM would hurt the games sales is an assumption with actual evidence against it. Authentication is absolutely needed for a functioning multiplayer experience (or else everybody could login as an admin), but for singleplayer I see little need. I'm not proposing turning Vintage Story essentially into a free to play game, I just think that singleplayer should work without authentication to make the game playable in an offline environment and in a case when the authentication servers might be down. Downloading the game would still require authentication as would multiplayer including lan.
  21. There are apparently already cracked versions of the game available, which means the protections have been successfully bypassed. That means that the protection will have no effect at all on the number on people who will pirate it, since the version they will download will have that protection disabled anyway.
  22. It's not like the current system has kept people from pirating the game though. I'm in no way supporting pirating, but these measures do little to prevent it. LAN is still multiplayer and should still require authentication. I'm strictly talking about singleplayer.
  23. I personally think the game should allow you to play singleplayer when not logged in, only multiplayer strictly requiring you to be logged in. Sure, it does make the game easier to pirate, but the current protection is probably also not really that secure. Most people want to play multiplayer anyway, so even when people would share their copy with their friends (which they arguably could already do when they both share one account), there would still be a strong incentive for them buying their own copy. Plainly said, Vintage Story would just be a better product if it were DRM free. Even if the authentication services went down one day, you could at least still play the game. GOG has shown that DRM-free doesn't lead to more piracy, so I don't really see why this DRM-lite we currently have is even necessary for singleplayer.
  24. A very recent and almost identical suggestion already exists on these forums: Personally, I think fixed classes fit the game better, it's a survival game after all and not a RPG. The aim with these classes will probably be to offer some variation and specialization opportunities while the main focus is on allowing for hand-crafted specialized challenges, like characters in many survival games or rogue lights allow for (Don't Starve and Isaac come to mind). A trait selection system would put more of a focus on min-maxing advantages, which is in my opinion simply not that interesting in the context of Vintage Story. Gaining specific feats through specific challenges, exploration or other ways as a player progression system however is something I would like to see.
  25. Having used the prospecting for quite a while now, I now also think it's ok. Personally I now think the ore distribution should be different per ore type, i.e. metal. Most ores should stay unchanged, so generating in large disks that are easily found by combining prospecting and vertical mining. Large thin disks may not sound the most appealing for ore generation, but the advantage of being easily found is just too good to ignore. Iron generation should however be completely changed imo. It shouldn't rely on the ore density map and should be readily available everywhere, like surface copper. Unlike surface copper, if should generate in absurdly long, thin veins. I mean thousands of blocks long, snaking through the underground. The point being that they are perfect for building long minecart tracks. Maybe there should still be some iron that generates in the default way, in disks, but it should overall probably be rarer. As iron is the metal that is probably used the most once leaving the bronze age, as even steel relies on it, it makes sense to setup permanent mining infrastructure for it. The main problem with such veins however remains being able to find them in the first place, so something to make that easier must also be added. I don't think the main problem with the current ore distribution and prospecting system is not being able to obtain ore. Sure, it's not intuitive for new players, but once you know the game there is no progression relevant resource that you will have a hard time finding. I'd say the main problem of the current ore distribution is, while encouraging exploration and travel, not encouraging possible mining infrastructure (minecart tracks, elevators, etc.). Not a big problem now, as there are no such things right now, but they would be something cool to have in the future, but require the ore distribution to be different to be useful. Another problem is that caves are kinda useless for finding ores, when they could offer a nice high risk, high reward way of obtaining them without prospecting. Ore veins that spawn on the walls of caves (not just randomly happen to intersect a cave, but actually spawn because of the cave) would be an amazing feature.
×
×
  • 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.