Jump to content

Erik

Very Important Vintarian
  • Content Count

    167
  • Joined

  • Last visited

  • Days Won

    21

Erik last won the day on June 18

Erik had the most liked content!

Community Reputation

37 Excellent

About Erik

  • Rank
    Ironsmith

Recent Profile Visitors

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

  1. There way never a tree felling animation, you must have confused it with some Minecraft mod (Dynamic Trees maybe?). Or you come from the far future. Or you remember a bug that caused the log items to fall in a straight line, because the random number generator was broken.
  2. I generally really like the idea of a more even playing field, where player skill is more important than the tier of equipment, but I'm opposed to adding a sharpening system that encourages constant babysitting of the weapon. I don't think the durability cost is enough to discourage people from doing it, but balancing it to avoid tedium may be possible, with very significant durability costs. But then you're at a point where sharpening it pointless, because sharpening is not worth the cost. The sharpening topic has also been discussed twice before, so you can get some players opinions and ideas: I'd rather see a system with minor damage differences (the best sword doing twice as much damage as the worst) and significant durability differences, as it would also make player skill more significant while not adding more tedium and a tool repairing system where you trade maximum durability for durability (as suggested by Luk).
  3. I agree with this, hunting is too dangerous and tedious and not rewarding enough on top. Animals should drop a lot more meat since it spoils so quickly and animals should take fewer hits to kill. To make hunting not too easy, I think some simple stealth mechanic and animals trying to run from the player would be enough and incorporate throwing spears and bows better in the early game. Farming is supposed to be the only reliable source of food, which I think is a good design decision. As it takes long for crops to grow, it's however not really viable early game. Picking berries and hunting chickens seems to be the best early game way of getting food, but to be effective you aren't allowed to settle down, you must be on the move to find new berries. Like Stroam stated, cooking also helps significantly. The normad playstyle has the additional advantage that you will be gathering copper nuggets the whole time, which eliminates a lot of grind. Don't waste your copper on axes, they break far too quickly to be worth it, in fact, only use your copper for a pickaxe and an hammer, which allow you to mine and process ores from the underground. I personally think having to use two tools only to use ore is a bit too grindy, ore chunks should be smeltable without hammering them at lesser yield. Never mine in VS like in Minecraft with the hope to hit an ore out of pure luck, or you will waste a lot of pickaxes. Stick to caves, maybe use a propick to get a sense of the resource density in the area. Getting to copper tools can be done in less than an hour, but finding the minerals for bronze, which only spawn underground can be quite time consuming and is very dependent on luck. I think the game could use an overhaul of the ore generation and the propick to make it less dependent on luck and more dependent on mechanical knowledge. This is actually quite a common and valid critique. As the early game can take a long time, knapping should be faster, which could be rather easily archived with less but bigger voxels in the knapping process, maybe a 7 by 7 of voxels. For clay forming there are already "tool modes" which allow you to form a bit faster by selecting different tool modes by pressing 'F'. It's still very fiddly and many shapes don't benefit from them, I think a being able to draw a square by holding the mouse down would be a far better option.
  4. Instead of iron ingots, the bloomery should give you one piece of iron bloom. The piece is unstackable and has a "ingots contained" value, indicating how much iron is contained in the bloom. When it comes out of the bloomery, it is very hot, but cools down if not taken out of it immediately after the bloomery has finished (Instead of destroying the bloomery, tongs could be used to get it out). The bloom can be reheated with a forge. The hot bloom now needs to be taken to an anvil, to be turned into iron ingots. Placing it on an anvil is just like placing an iron ingot on the anvil, however no recipe needs to be selected. The recipe outline of a ingot will appear on the anvil and the iron bloom voxels will take a random circular shape. The player then needs to reduce the shape to the ingot outline, with the default smithing mechanics as they are present in the game right now. Taking the bloom form the anvil to reheat it will give the player a worked bloom item, which can be place on the forge. The forge only accepts one worked bloom or iron bloom item at a time, with no place for (worked) ingots. When finished, a stack of hot ingots will drop, the size of the stack is dependent on the ""ingots contained" value of the iron bloom. The mechanic could also be extended to work with a quality system, resulting in fewer/more ingots dropped and it would work flawlessly with my other smithing rework suggestion. Crafting ore with a hammer seems like a very lame way of processing ore for me, so I offer a alternative solution: Ore chunks can be smelted directly without having to crush it, but it only returns half the metal value. This makes creating the first anvil, required to get all the metal value from ores, much less grindy. Placing a ore chunk on an anvil will result in some ore voxels on the anvil, in a random small circular shape. Hitting any voxel with a hammer will result the removal of the voxel and dropping of nuggets. The total nuggets from one ore chunk should have a total metal value equal to the its metal value. Taking an unfinished ore from the anvil will result in an unstackable worked ore item. This makes the anvil a much greater achievement, as it effectively enables ore doubling and smooths out the progression as the player doesn't need to craft a hammer from surface ore to make ore chunks usable. A doubling of the metal value of ore chunks would however be recommended, to make poor ore chunks usable. Both the bloom and ore processing are rather work intensive (especially the ore processing) this way, so they are perfect candidates for automation. A mechanical hammer powered by mechanical energy could be implemented with the mechanical energy system that crushes the ores and bloom automatically, giving further incentive for progression.
  5. A lot of good ideas here, but I see one problem with some of them: Their focus on time as a balance factor. I don't think any crop should take one year or more to yield, that would be ludicrous imo. Neither should the year be 144 days long, that's 96 real world hours with the current day length. These things may work in multiplayer but for singleplayer they are simply not feasible. Crop growth times should remain to be only be a few ingame days, as even that is a relatively long time. It's not even that servers would greatly benefit from longer growth times, it would just make replanting rarer and put less focus on the nutrient system. I would like to perennials implemented similar to how Stardew Valley did it, with them being harvestable multiple times a year. There are a lot of ways to balance them other than massively longer growth times (although their initial growth time should be a bit longer but the regrowth times a lot shorter), like greater nutrient consumption, smaller temperature tolerance, less seeds, less nutrients or faster decay for the food, etc. These things pose actual gameplay challanges for balance and help to differentiate the crops further instead of just adding larger wait times.
  6. Erik

    Food decay

    Yes, I'm wrong here, you're right, assuming the DC increase rate is still linear (which still means a non-linear DC increase) your system would work without any stacking issues. But the system has still the issue of of there being no place for the rot to go when eating with a full inventory, which a deterministic version of the system wouldn't have. However the deterministic version needs a constant decay (i.e. DC increase) rate or eating will cause food to spoil faster, which is clearly not wanted. So it's a choice between a more realistic chance based system with a minor gameplay issue or a less realistic deterministic system without gameplay issues.
  7. Erik

    Food decay

    While I really like the general idea of your system, this last piece ruins it from a gameplay perspective. It does not only not fix the issue with a linear decay rate, but amplify it: 64 stacks of one potato still decay much faster than one stack of 64 potatoes AND combining/mixing stacks with a high DC with stacks with a lower ones (but not too low ones, because that would waste some decay rate) is vital because the lower weighted average DC lowers the decay rate. It's micromanagement hell and exploiting the system correctly is hard, which leads to more micromanagement. With a half-life decay rate this system would work however and would be the best system yet, having no gameplay issues. I especially like how it avoids the rot problematic, by giving you the rot when you find it (failing the DC check when eating). The issue is minimized (so not fully eliminated) to the rot having nowhere to go only when the player eats with a full inventory. The issue could be fully eliminated however, by making the system not based on probabilities, but having the bar represent the actual rotten potatoes in the stack. So when the player eats the last non-rotten potato in the stack, or it decays, the stack turns into a stack of rot. I.e. the half-life system, but decay doesn't decrease the stack size, but adds to the "rot bar". BY THE NINE DIVINES, A SYSTEM WITH SEEMINGLY NO ISSUES (apart from it not being fully realistic).
  8. 50 blocks seems like an acceptable range, if the landforms get updated to it. But some things, like the big open caverns created by landforms below the surface wouldn't be possible, as landforms would only be possible to edit the upper fifty blocks. Landforms being able to fill out all the remaining area would ofc make the whole system irrelevant, because it would make oceans impossible again. Probably. The terrain generation would require minimal changes, but a whole new terrain generator for the stuff below the column would need to be added. Chunk loading would require an extension or replacement to have 3D chunk loading. The terrain saving structure may also be needed to be overhauled. And the lightning engine would need some changes. The good thing is that chunks are already cubic, so it wouldn't be a total redesign, but it would probably still take a month.
  9. Erik

    Food decay

    It would fix the issue. It would just put the rot/compost into a very different position, as a resource the player has to actively produce if he wants it and not something he gets if he screws up his food storage. Think of it more as a removal of rot and addition of compost. Doing this, not keeping the rot mechanic and replacing it, would imo be better than trying to keep the rot system and making it work in some weird hacky way like the extra slot you suggested.
  10. Erik

    Unique armors

    I think splitting the three reduction types is actually less confusing, helping a player to distinguish the types of reduction and remembering them easier, because they associate them with a type of armor. That is what makes the system consistent, because the player can see from the type of armor the enemy is wearing, which type of damage reduction he gets. As for 'tier vs tier', this is like the polar opposite of it, going completely against a linear progression. Instead this system offers a lot of different options to the player, all with their own distinct advantages and disadvantages. The thing I personally dislike about a 'tier vs tier' system is that it's not the players choices that would win a battle, but how long the player played and thus progressed in armor tiers.
  11. Generating a world with ocean borders is actually rather easy to implement, but there are some problems with the heightmap part. Having the heightmap either greatly limits the landfroms elevation changes or makes the heightmap useless, as 255 blocks world height don't allow for great variation. I think a much larger overhaul would be needed, involving changing the way chunks and chunk-loading works, which would be certainly be incompatible with the current worlds or at least require a decent effort to fix: Have chunk heights vary. Not just the blocks in the chunks, but the actual chunks, or chunk columns to be exact. This would allow for highlands, kilometers above sea-level, and oceans, kilometers below sea level, without needing to change the landform system, the 3d-noise system, in any way. To make the system work one additional feature is required: Infinite depth and height. Chunks below or above the chunk column would not need to be generated with the columns, since they are not dependent on the landforms. They are just empty chunks above and stone/ore/cave filled chunks below and are generated when the player is close enough to them. Infinite world height/depth would also sound cool for the marketing and is really something people expect with cubic chunks.
  12. I think the way it's done right now, with repeating a north-south pattern covers both variants if the width of the climate bands and the world were configurable and also allowing for more than two poles. Oceans are something currently not possible in VS (without exploiting the system by creating hundreds of ocean landforms), because all landforms have the same size and changing that seems to be really complicated. I have an idea on how to allow oceans without it and a whole bunch more things, but it's most probably even more complicated.
  13. Couldn't the sun/days just work normally on the eyeball planet just for the sake of gameplay? It just wouldn't be realistic, but so is turning the earth into an eyeball planet I also don't really see the gameplay benefit of the eyeball earth compared to the current repeating climates, other than that it's more finite. A finite world could also archived by just lowering the world size and widening the climate ring, the map would only visibly cut off at the poles and the sides. Other than that, I enjoy the idea of a wrapping donut-shaped world a bit more, it doesn't suffer from the corner problem and just needs tileable noise, like any wrapping world would.
  14. Erik

    Unique armors

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

    Food decay

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