Jump to content

Erik

Very Important Vintarian
  • Content Count

    208
  • Joined

  • Last visited

  • Days Won

    33

Erik last won the day on September 10

Erik had the most liked content!

Community Reputation

72 Excellent

About Erik

  • Rank
    Ironsmith

Recent Profile Visitors

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

  1. For most mod creators such a tool wouldn't make creating mods easier, having a GUI based approach is simply just often slower than editing a JSON file. Furthermore, editing JSON files isn't really coding but more like editing a configuration file, it's a data format and not a programming language. So a "VSCreator" wouldn't really be that helpful in my opinion, as it would only be a differently formatted text editior opening the right json files for the things you want to add/change, just another json viewer/editor, something that already exists. Also, MCreator wasn't a great success or useful tool for existing modders either, as there wasn't any mildly successful or unique mod created with it. The resources that would need to be allocated to creating such a program would be much better spend on creating more content for the game. So, if you want to mod, learn the JSON format and experiment by editing the games json files, consult the wiki and ask for help on the Discord if needed.
  2. Exploration is at the heart of Vintage Story and calling it "punishing" is straight up wrong in my opinion. There is always something you can find, even if you not find what you're looking for, even if it is just a nice looking scenery. Berries alone make exploration non-punishing, as they practically eliminate all food problems while exploring. Not to say exploration couldn't be improved, some of the loot from vessels is not really worthwile at all, like flint tools, and should be replaced by some more useful stuff, like tin nuggets or lime. Caves are also not really worth exploring other than to maybe find ore veins, but that happens far too rarely to incentivice the player, maybe "ore geodes" on the walls of caves could fix that.
  3. A huge curse and blessing of the game is the way resources are spread out and have to be found by exploration. It can often be frustrating to find the resource, but once you found it you'll have a practically unlimited supply of it in always all cases. Finding tin or iron has this problem, as well as finding limestone or chalk. But this is also an intentional decision to reward exploration. The grind is also a huge part of Vintage Story, though I think it is much more of a curse. Many systems are balance for a multiplayer enviroment rather than a singleplayer enviroment. The best example of this is the default year length of 12 days per month, being 115.2 real life hours. Even the smallest setting (3 days per month) is still almost 30 hours. While I never found charcoal to be a problem when being conservative with it, leatherworking especially feels like a huge grind: For hide to process to leather it takes multiple real life hours. This makes creating armor expecially painful, as it not only requires a lot of leather but also a huge amount of metalware, which take a really long time to smith. So for your copper plate armor you could look at five real hours of work, when it will realistically only last half as long or may even be destroyed in a couple of hits by a nightmare drifter (and this is no joke, they will practically eat the armor). So only iron armor is worth creating, but that takes even more time as you have to process the iron and work the bloom. So yeah, I think grinding is a huge problem in VS that needs to be tackled sometime soon.
  4. Vintage Story's combat has some fundamental flaws, that need to eliminated before any new combat mechanics are introduced: This small clip highlights the two main problems: Disconnected attacks and wrong timing Wrong timing: This is the smaller issue of the two and is relatively easy to fix. The issue is that attacks hit after the animation has been completed instead of during the animation. This makes timed dodging or blocking of attacks much harder, as the visuals deceive the player. In gamedesign, attacks can be seperated into three phases: The windup that is used to notify the player of the attack and the type of attack, giving him some time to to react, the actual actual attack during at the end of which hit detection will detect if the player has been hit or not and the recovery, when the attack has either hit or missed the target, giving the player some time to act. The drifter attack animation has a short recocery, when the hit frame is seen is the swing at 90 degree angle to the starting position, having being the closest point to the player if the player would stand directly in front of the drifter. But the hit frame is, as seen in the clip, after the recovery, when it should be in fact before it. The drifter is not the only example of this, the problems described here apply to all NPCs in Vintage Story. Disconnected attacks: The second issue is that although the animation indicates that the attack clearly missed, the attack still hits. This is a huge issue for gameplay, as it makes dodging attacks sideways or into the enemy impossible, leading to the common technique in many games with bad combat system: backpaddeling. Getting distance from the attack is the only way to escape it, so players constantly walk backwards in combat, while trying to outreach the enemy. One extra thing to note in the clip is that the animated attack should not only miss the player because of the rotation, but the reach of the drifters attack is exagurated, hitting more than range the animation actually has. The animation reach at the hit frame and the actual reach of an attack must match not only for NPCs, but also for the players, which attacks have even more additional range, to ensure attack readability in PvP and PvE situations. The attacks of the drifter seem to simply check if the player is in range of the attack and are completely disjointed from the animation and orientation of the drifter. While actual weapon swing simulation with real time detection if a weapon hits a target is not required, proper hit detection, checking if the player is in the attack cone of the enemies attack, is. For the player, cone based hit detection would also make sense, making hitting targets easier and differentiating the sword from a short range gun. The design of many, if not all attacks in the game should also be fundamentally reworked: The enemies should generally not rotate during the attacks, so dodging sideways or into the enemy is possible, attacks like the bighorn sheeps charge should not be like a homing missile, but like an actual animal charge, first getting some distance to then charge at the player, either hitting on a collision or continuing for a while past the player on a miss. Drifters could use a forward lundge attack in addition to the swing, to close distance and force the player to force the player to dodge sideways rather than backpeddeling.
  5. I think the town center/guide post is not really required, as it also strikes thematically with the game. Not every player would want to be major of a town, most probably want a simple farmhand to help with managing the crops or a mercenary to explore some caves or raid some villages. So I'd lean more on a room based system like in Terraria, which is already kinda supported as there are already cellars and greenhouses as rooms in the game. So you just have to build a small room with a door and a bed and you could hire an NPC and it would be assigned to that room, either automatically or maybe by some management menu. Recruiting NPCs to work for you should however not be without cost. I imagine there would be people you can hire wandering around in the world, at traders or in villages. Hiring should cost money, i.e. gears, and only last for a limited time. Maybe, if you hired somebody for long enough, they may be willing to work permanently at your place as a follower. Then he wouldn't cost any gears, but needs to be feed with food, or else he will leave again. Once you have an empty room, there could also occasionally some traveler coming by, asking for a nights stay and paying some gears or labor for it. This could also be a way to meet NPCs you could hire or just make some extra cash by also selling them some food or equipment.
  6. Some of the hunting mechanics described are possibly a little too complex for a game that isn't a hunting simulator. I personally would like the animals being faster and more elusive, running away if having spotted the player. Sneak mechanics are definitively a must have. Bleeding should definitively be a thing. A bleeding animal should leave a blood trail and slowly loose health. This should make hunting a bit easier, most animals only needing one hit with a spear to get bleeding damage for long enough that they will die, but the player has to track down the animal after hitting it by following the blood trail. So hunting would ultimately come down to sneaking up on prey, successfully hitting it (probably by throwing spear), following blood trail to corpse. Simple but immersive.
  7. Seasonal limitations on crops, however that would be exactly accomplished, would be awesome, probably some min-max temperature system. I feel like the player needs to get exact data about the time of year a plant can be grown in the current location provided on the tooltip. A "can't be grown here right now" when it is too cold/hot and an indication how long (days) it can be grown till it is too cold/hot if not. Since the temperature curve is deterministic, this should be easily possible. Obviously the whole system needs to be tied in closely with the food preservation mechanic, which seems to be already made with it in mind. Spring to autumn, food should be somewhat easily and very regularly obtainable by farming. Some food should be harvestable often and some less often or even only yearly. It should generally be balanced, so that the longer a food takes to grow, the longer it can be preserved. The player preparing for winter is of course rewarded with him getting the nutritional benefits of eating from multiple food sources rather than just one. While even an unprepared player can survive the winter by hunting, only those who farmed and preserved food will be able to eat meals that provide every nutrient. The foods are already balanced that they are harder or easier to preserve depending on the nutrient type. Meat, while also freshly obtainable in any season, can be cured with a bit of salt and will last for years. Grains, while already lasting longer than most preserved food, can be turned into flour simply by grinding it, making it last for over a year. Vegetables can be pickled when having access to salt, but even then won't last too long. Fruits, while easily obtainable during fertile seasons, decay extremely quickly and are hard to preserve by creating jam, requiring hard to obtain honey, but lasts for years if stored in sealed crocks. So with this in mind, looking at growth times and other factors, grain should take the most time to grow, probably a full season. The other foods like vegetables and fruits should however be much faster to obtain. Something I would like to see with fruits are the plants taking longer to grow, but the fruits growing rather quickly once the plant is mature, allowing harvesting the plant multiple times for the rest of the season, example plants being tomatoes. Some unique farming I would also like to see are hops and grapes, which are slowly grown on crop sticks and ropes, dying down to just a root in autumn but automatically regrowing from it in spring.
  8. I'm sure team is aware of this and the system will still allow things like that. There will probably be different types of water: Flowing river water that will be location locked to rivers only, but allow operating water wheels and probably irrigate crops. Maybe you could also pump it with mechanically powered pumps and aqueducts to irrigate fields further away from the river and allow it to act for limited transport of for example logs. Ocean/salt water might be added probably acting a lot like Minecraft classic water, filling up any air spot lower than ocean level. So you could build channels for ships and harbors with ease, the water filling itself in by itself. Maybe on the ocean there could also be water currents, which would make for pretty interesting boat gameplay when wind simulation would also be a thing. Lake water may actually have volume simulation, as it would be available in much smaller quantities than ocean or river water. So any water you pick up in a bucket (maybe except for salt water) would default to lake water when placed. Lake water would distribute its volume equally over the available terrain, making it easy to work with for building you own ponds, baths, etc. It would probably be much less useful for irrigation than river water, maybe farm land would even consume it over time. These are just some ideas I could come up with and not things that are definitively planned, aside from river water for waterwheels, which actually is planned.
  9. The dev team is not against automation to my knowledge, but wants automation to be hard to archive and make automatic systems like chicken farms not as simple as some water and a hopper. I'm sure there will be more complex automation further down the line, but currently the development priorities are on getting feature parity with TFC and installing general gameplay systems, like seasons or crafting systems.
  10. Brewing alcohol is something that is planned for the game, specifically update 1.14, and without there being a hydration system, there would be very little gameplay reason for it. However the inclusion of alcohol brewing as a mechanic opens the game up a very interesting and fun idea: An alchemy system, in other words a potion and poison brewing system. The goal of the system is not only to allow players to temporally buff oneself for certain tasks, but also reward players for exploration and experimentation, offering them an amount freedom. The alchemy system should therefore also act as a puzzle, to offer enough depth that experimentation and mastering the system is actually useful, rather than there being an easy way to always produce a perfect potion. An alchemy system obviously starts at potion/poison effects with the status effect system. A status effect should have a variable duration and a variable magnitude. After the duration has expired, the status effect is removed from the player. The magnitude determines how big the impact of the effect is, what it actually does is dependent on the type of status effect, for a healing effect it would improve the amount of health restored per second. Instant effects are possible by having a very low duration. Some examples for status effects: Healing: The player regenerates X health every second for T seconds. Harming: The player loses X health every second for T seconds. Exploding: The player explodes with a strength of X after T seconds. Haste: The player breaks blocks X times faster for T seconds. Status effects obviously aren't limited to the player, they work on any living entity. The same status effect can exist multiple times on one entity, meaning that the player can drink two potions to heal faster. There needs to be a menu players can access that lists all active status effects, with their description, magnitude and remaining duration. So what has this to do with alcohol brewing? Alcohol acts as a solvent and base for tinctures, which carry these effects. To create a tincture, an alcoholic beverage must be aged inside an aging barrel together with any number ingredients of ingredients. Alcoholic beverages can be made in several ways, producing different types of wine, beer and booze. By oneself, they don't do much, they maybe provide some nutrients or saturation and certainly make you drunk. As the base for a tincture they have three stats that vary depending on the type of alcoholic beverage: Duration, magnitude modifier and base toxicity. The duration determines the duration of the effects of tinctures made with this beverage as base. The magnitude modifier modifies the magnitude of the effects of tinctures. The base toxicity determines how drunk you'll get from drinking this beverage or tinctures made from it. Toxicity is actually an important gameplay system rather than just a bit of fun. Consuming beverages and tinctures will raise the drunkenness of the player. A bit of drunkenness will just give the player a slightly blurred vision (a depth of field effect, never the nausea effect Minecraft has, because only the player character should get nausea, not the actual player). It will get more blurred as the drunkenness increases. Next thing would be slight camera movement without player input, making the player character harder to control as drunkenness increases. At some point player input will be delayed and then the player characters will move about a bit without player input. As vision gets so blurry that it's almost as if the player character was blind, at 100% drunkenness the player instantly dies. Drunkenness thus acts as a limiter to tincture consumption, so players can't just drink ten healing potions at once and be invincible for a minute. (And I admit, it's probably a little funny too, looking at Deep Rock Galactic) Drunkenness on the player constantly decreases over time, so if you don't become addicted to tinctures, it should be easy to manage. But how do you actually craft a tincture? Well it starts with the ingredients. Ingredients are a type of item that doesn't carry effects, but contain alchemical elements. There can be multiple elements on any ingredient and multiple of any element too. So horsetail as an ingredient may contain 3 aqua, 2 terra and 5 umbra. You can see the elements represented by icons with numbers representing the quantity on the tooltip of the ingredient. When you add ingredients to an aging barrel, they will be dissolved and the elements they contained get added to the beverage. You can dissolve as many ingredients as you want into a beverage, even dissolve multiple of the same ingredient, and all the elements get added up. So when dissolving two horsetail, the beverage will contain 6 aqua, 4 terra and 10 umbra. Adding sulfur (4 ignis, 1 umbra) to it, it will contain 6 aqua, 4 terra, 11 umbra and 4 ignis. If a beverage in an aging barrel contains the same amount of different elements, like the 4 terra and 4 ignis here, the tincture created after aging the beverage will get the combinatory effect of that combination. Any combination of two elements will yield an effect, so as long as there are two elements of the same quantity in your aging barrel, the created tincture will have an effect. This allows the player to experiment and discover the effects different combinations. Some effects may appear in multiple combinations, meaning it is possible to get tinctures that apply the same effect twice, which would make for a tincture twice as powerful. While you can add as many ingredients as you like to your beverage, the lower the amount of elements in a combination, the stronger that combination will be, or in other words, the higher the magnitude of the resulting effect will be. So a combination of 1 terra and 1 ignis will produce a more powerful effect than a combination of 4 terra and 4 ignis. Each effect on a tincture will also increase the toxicity it by 25% of the base toxicity. All elements that aren't included any combination also decrease the magnitude of the tincture by a small bit. This means that you want go get close to no unnecessary elements in your beverage for it to be most effective. Only when the aging barrel is sealed up the combinations are locked and after a set amount of time you will have your tincture. The tincture can be filled into bottles, flasks or water skins and consumed by the player by simply drinking from those. Alternatively the tincture can also be applied to weapons and will apply the effects of the tincture to enemies upon hitting them. Applying 10 portions of a tincture to a weapon will yield 10 hits applying it. For the earlygame there should also be ways to utilize the alchemy system before brewing: Paste Instead of an aging barrel a player can use a pestle and mortar and instead of alcoholic beverages he can use animal fat or honey as a base. Pastes are created with the same system as tinctures, but their big advantage is they don't possess any toxicity. However they can only be applied to wounds and are generally much weaker than tinctures, but last longer. To apply a tincture you don't eat it, you apply it to a bandage and wear that bandage on an armor slot. While the wearer doesn't have full health, the effects of the bandage are applied. Bandages decay over time, like food. After it is decayed, the effects will no longer be applied. When toxicity is the trade off for tinctures, bandages using an armor slot is the trade off for pastes. Good ingredients are hard to come by and they almost always have more than one type of element, however there is an endgame way of extracting certain elements in their purest form: The alembic. The alembic operates very similar to an aging barrel, in the sense that you need to supply alcohol to it and can dissolve ingredient into it. Instead of sealing the barrel, you light a fire under the alembic and instead of being able to use any alcoholic beverage as base, it needs pure alcohol, which is only obtainable by repeated distillation of beverages in a small distillation tower. The alembic, while similar to the aging barrel, turns the alchemy system on it's head. Upon lighting the fire, types of elements are of the same amount, and therefore would combine into effects, get evaporated with the alcohol. What remains is a fine powder only containing the remaining elements. This powder is an ingredient itself and can be used for creation of tinctures or further refinement in the alembic. Encouraging experimentation and exploration While the system would work, a quick look on the wiki could make finding the right combinations and ingredients trivial. To make this impossible, the effects that appear on combination of elements should be randomized per world, only the elements on the ingredients should not be randomized. Upon creating a tincture or paste, the discovered effects from used combinations should be added to a searchable list in the survival handbook, so players can easily look them up. Alchemical recipes, outlining the effects of element combinations should also be able to be found in ruins as loot, which are also added directly into the handbook upon reading. Pure alcohol, alembics and powerful ingredients could also be ruin loot. Eating an ingredient containing two different elements of the same amount should also discover the combination of those elements. Implementation discussion While I think the system is quite elegant and easy to understand (only the less equals better aspect may be a bit counterintuitive), there is a problem regarding the implementation: How many elements do there need to be? The number of possible combinations and thus possible different effects can be very simply calculated with this formular: nC = n! / (2 * (n - 2)!) nC ... Number of possible Combinations n ... Number of different Elements As the number of combinations would probably not always exactly match the number of effects, there would need to be duplicate effects, which is a good thing, as it makes more useful and general effects like healing more accessible. I'd argue each effect should at least have two combinations that produce it, many effects may even have more. 16 elements would yield 120 possible combinations, which would allow for 60 effects, if every effect would have exactly two combinations. As there likely won't ever be more than 60 effects in the vanilla game, I think this number is fine. Effects would have a weight value assigned to them that determines how often they appear in combinations compared to other effects, so the randomization process can assign the effects to combinations properly. Each effect is however at least assigned to one combination. This would make the effect system easily moddable, allowing the creation of new effects. However as there is the hard limit of 120 combinations with 16 elements, it should be possible to add new elements. Elements are assigned manually to ingredients, so this would also require new ingredients or edits to existing ones, which shouldn't be hard to do. What do you think about this system after you got to the end of this wall of text? Any feedback is welcome!
  11. No, they wouldn't. Getting enough rocks or ore is not the problem, but building tunnels either for aesthetic purposes or to even get to said ore. I also don't see any gameplay reason for the chisel style mining, it doesn't offer any interesting challanges nor enables other interesting interactions in both Omegas original suggestion or AlteOgre's more refined one. I however like the "rubble" idea, think breaking stone would create gravel (which is effected by gravity) instead of dropping stone, which can be picked up with a shovel or destroyed by hand for stones. There would be a real gameplay effect with it which would balance the added grind and I feel it would be very fitting for the Wilderness Survival playstyle, however probably not the default one. I really, really like the "weak spot" idea. It doesn't make mining any more grindy, but even lets you mine faster (less grind) if you don't just blindly break blocks but pay some attention to where you are mining (more engaging). There could even be different types of weak spots to offer some diversity and player decision making: Break the block faster by hitting the crack or slower but have a chance to get a gem or nugget by hitting the glittering spot?
  12. While the breaking of the block may be solvable in the same time as before, the rubble and getting rid of it makes the whole process take a lot more time. Things that are already really grindy in the game, like quarrying for smooth stone, would become unbearable for most players. Mining efficiently for ore in Vintage Story is significantly different from what you describe, as prospecting above ground and looking for caves in or rich areas or digging straight down is the best way to mine, not building endlessly long tunnels underground.
  13. It is a sandbox survival game, not just a sandbox game. It should force you to do things. The default survival game mode should not have a completely skipable night imo, as it defeats a lot of the purpose of the night. Being just able to skip the night defeats the purpose of building up defenses, a simple fence and permanent light. It degrades the purpose of crafting armor. The bed is what ruined the Minecraft survival experience for a lot of people, as the game became too easy with it. And players can do things at night time, it's the best time to do the crafting and smelting, prepare food, decorate the interior of your base. Once a player crafted some basic wooden laminar armor, the night isn't even that scary anymore as drifters are not even a threat anymore. Quality of life features are generally a good thing, but this wouldn't be a quality of life thing, it would be a major gameplay change, that would also only effect single player. I'm however not against some world creation setting or mods that allow you to sleep through the night, this is just about the default survival mode.
  14. If you play hard mode, you get hard mode You can however tweak the difficulty settings at world creation to fit your liking, player health and damage can be individually modified in the customize world screen. As Streetwind pointed out, wolves in the normal mode are pretty well balanced. I still remember a time when wolves would be much more dangerous then they are now, a few major updates ago: Wolves wouldn't sleep/rest, they would be on the lookout night and day, they would spawn everywhere, hunt you down for hours and two hit kill you, for the entire game, because there wasn't any kind of armor. Now the only problem I have with them, is them making no step sounds, which can make them quite sneaky, but if you craft a set of wooden armor and a weapon, you are able to easily kill a wolf, if you dodge some of its attacks.
  15. Assuming trees generated by the world don't grow and there is no natural reforestation (i.e. trees planting saplings without player input), the performance hit would be limited to world generation only. Only player planted trees would cause a performance hit, but that should also be fairly manageable, as the trees would grow quite slowly, probably taking a few ingame years come close to the size of "naturally" generated trees. The difficult question is how to efficiently handle a tree as a entity. Having one "tree entity" assigned to every tree seems to be the most straightforward option. Trees generated by the worldgen don't have a tree entity, because they don't need it, they don't grow. The tree entity itself would be stored inside the block that was originally the sapling. The entity would store the positions of all blocks belonging to it and would only update those the tick before a growth tick or the tick when part of the tree or part of the tree is unloaded. Tree destruction should still be done by an algorithm on the axe and should not utilize the data structure on the tree entity, as that would require the data-structure to store the coordinates of the tree blocks in a tree data structure instead of a simple list and the tree entity belonging to the chopped tree would still need to be tracked down by an algorithm on the axe, as well as trees without a tree entity still having to utilize the old search algorithm on the axe, so the whole endeavor would not be worth it. The one tree entity per tree approach however comes with some negatives, like having to check the tree positions every now and then, at least before the growth of the tree, as any of them could be destroyed/removed. Finding and updating the tree entity whenever a tree block is destroyed is also a possibility, however there may be ways to exploit this, such as possibly just moving blocks with pistons in the future or using save game editing tools. Then there are always the problems that could arise with trees lying in more than one chunk, being partially unloaded. Another way to handle tree growth would be to have multiple moving tree entities on one tree. These "tree runner entities" would only simulate growth at their position (and maybe surrounding blocks for leave generation). On a growth tick they grow the branch and move to the next further from the root until they hit reach the end of the branch and then either extend/grow the branch or grow branching. A runner also deletes itself when it reaches the and of a branch or a branching, however at a branching it also spawns new runners for each of the child branches. A new runner entity would be periodically spawned at the root/origin of the tree. They would essentially allow running the tree growth algorithm over multiple ticks, preventing stutters at growth ticks that would maybe be possible with a "one tree entity" model, when it has to check the positions of all blocks. It also has the added benefit of having a lower memory impact, as the tree block positions don't need to be stored on the entities. The downside of this approach being that there is some additional overhead, as there are a lot more block entities that need to be taken care of. Block entity visualization would also be needed to allow efficient debugging, but this also allows for much better debugging of the growth algorithm and modding of custom trees as they would visualize the growth algorithm itself. Problems with multi chunk trees and unloaded chunks can also be handled quite efficiently, as loaded runners can run as usual until they are either destroyed by reaching the end of their branch or hit the border of an unloaded chunk, when they would, instead of deleting themselves, just wait until the chunk becomes loaded, potentially stacking many runners at the chunk border to be released and quickly running in a single tick when the chunk gets loaded. I personally prefer the second approach, for its more intuitive solution for issues with partially unloaded trees and being less prone to lag spikes.
×
×
  • 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.