Erik

I edited the poll, to reflect the feedback.

I don't think the frequency and direct detection go well with each other, as direct detection would only be useful with much rarer veins and frequency detection with much more common clusters. If you can dig down everywhere and expect to find ores 70% of the time, there is no real purpose in using direct prospecting. If you won't find more than two veins in an area, there is no real use in frequency prospecting. The methods of ore generation have different problems for the player to solve. With larger rare veins, the player needs to find the vein. With common small clusters, the player can easily find clusters, but might wan't to know where the most clusters for what metal are. You're right. But I wouldn't say they are separate issues, I think that they are tied together, where only one option of prospecting makes sense for one option of ore generation.

I'm really unsatisfied with the current mining experience. It's basically like minecraft, where there's little patches of ore everywhere and mining infrastructure is useless. Prospecting only tells you, if a chunk has many ores or few, which isn't overly useful, since the most useful ores are also the most common. I would rather prefer a Terrafirmacraft like approach, with better prospecting (Prospecting in TFC is very difficult to get into). Veins would ideally be generated like the Reasonable Realism mod (very long, thin veins). Prospecting should tell you if there are ores beneath in a certain radius (like 6 block diameter). If there is a ore block somewhere directly beneath the prospected block, the player should be notified. So prospecting would be a search on the surface, with clear results. I added a poll to this post, I would be very happy, if you could fill in your opinion.

I didn't mean the player wouldn't be able to understand the concept, I just think it would add a lot of tedium to the inventory management. Players would have to constantly move items around their inventory, to make everything fit although the idea behind the weight mechanic was to make inventory management less relevant. Tools have durability is mainly implemented to slow the players progression, to keep him from cutting down whole forests and mining mountains. It also serves as a way to balance the amount of resources the player has, so the player has actually some reason go mine ores throughout the whole game. Replacing tools is also very easy, you even can carry multiple tools with you. I don't expect the player to carry multiple backpacks in your system. When your backpack breaks it just drops to the ground? What happens to your items inside it? How can you repair it if you can't pick it up? I also imagine the breaking of a backpack taking a lot of the players time, as he is severely limited without one. If I understand you correctly, there is a weight limit for containers, but it doesn't limit you from exceeding the limit, instead durability is used when the limit is exceeded. I would suggest the weight limit to be limiting the items that you can carry, instead of having durability involved. That would also be easier for players to understand.

Well, this system would probably also work well with weight, but it's more of a framework for the gui than for gameplay. Introducing weight may be a good idea, because it helps to keep inventory management very simple, but it requires different controls for the gui and the quickbar would require to only be virtual, with no items actually being stored there. Only introduce weight or volume, as introducing both would make inventory management really difficult again. Bag durability is a bad idea, only serves being tedious.

Well, I guess I learned something new. The current system, as far as I know, is not moddable in any way, which really is a shame. Color coding would indeed be something nice. I thought of action slots, because I thought, the inventory system needed some standardization to be moddable. Action slots are an easy way for modders to expand the functionality of the inventory, like adding new types if armor. The moddability using action slots could be so easy, as modders could remove the option for multiple backpacks by just editing the json files. Implementing the system wouldn't be 'as hard', as the game already has some form of a html/css-like GUI system (It's only mentioned in one of the first news posts), it would "only" require some major refactoring.

The problem with the current system is the implementation on the four pouch slots: Other than carrying four backpacks being absurd, the player doesn't know, which item is stored inside which pouch. Having the pouches placed next to the quickbar is an odd design decision, as it ruins symmetry and has no real practical use, other than obstructing the players view. What the modding api currently lacks is the ability to create GUIs with inventory slots. The proposed system wouldn't only allow for easy creation of new GUIs, it would also allow for easy modification of existing GUIs. For example: A mod that adds capes could simply add a new type and add an action slot of that type to the players inventory via coding or json patching. Multiple mods can add multiple things to the same GUI without compatibility issues.

The inventory in VS is very unfinished, so I got a small idea on how to expand it. First, I'll introduce a new property for blocks and items: The type. Types are just categories for items and blocks, a type can be attached to any item or block via json. Custom types can only added by code mods, using an IType interface. Some types can also require additional data in the json file to fully work. Possible types: Backfit (for backpacks and the like), Helmet, Chestplate, Tool, Weapon, Pouch, Ore, Ground, Flower, Food,... Now, I'll introduce the item slot types: Normal slot: A absolutely normal slot, every item fits in. Filtered slots: These slots only fit items and blocks of a specific type. They render as a black slot with the type image in it. The type image is defined in the types code. Action slots: Action slots are type slots with the ability to utilize the item inside the slot. The handling of the item is described in the onEquip, onEquipped and onUnequip functions of the corresponding type (in the class that implemented IType), using properties defined in the items json file. Action slots look like filtered slots, but have a bar next to them and are surrounded by an inventory box. Custom slots: Can be added using mods to add special functionality to inventories, like the inventory of a furnace. They can be created by inheriting from the abstract CustomSlot class. Their appearance can also be defined using coding. Technically speaking, all slots implement the IInventoryElement interface and all inherit form the CustomSlot class An example for an action slot: Backfit type action slot. Used for backpacks and barrels: When the player puts a backpack in the slot, the action slot "expands" and adds new slots to the inventory, some of them even being action slots: When the backpack is pulled out of the action slot, it keeps the items stored inside the item, making swapping out backpacks easy. Armor is also using the action slots to be equipped. Now that we have covered slots, we will quickly cover my vision for a moddable inventory system. An inventory is defined via json. The inventory has a size (width, height in % of screen). There are multiple elements that can be fit inside an inventory, notably slots, filtered slots, action slots, custom slots, other inventories and other inventory elements. There are three types of inventories: static, floating and custom inventories. Inside static inventories the elements are statically fit using coordinates in percentages of the inventory. Floating inventories have the elements inside positioning oneself by order, like floating in css. Floating inventories also have a scrollbar, when the elements inside would not fit the width and height of the inventory. Custom inventories are often dynamically inserted into inventories, using action slots. They can also be defined in json or generated by code, the coded approach being more common, like in the case of the backpack. Custom inventories are also either static or floating. An inventory that is not inside another inventory is the window object. Custom inventory elements, like progress bar or buttons can be defined by implementing the IInventoryElement interface. The coding of inventory handling should be very reminiscent of Javascript DOM scripting, having to append objects, getting objects by class or id and so forth. Inventories in the survival mod should be stored in json files as mach as possible, to warrant maximum modding compatibility. I know there is some html/css like system in place for GUIs right now, but right now it isn't moddable, and I thought of this as one way to solve this. Implementing these changes would obviously be a massive, but worthwhile, undertaking, as it is basically a rewrite of most of the GUI system, things like shift-click behavior on items have to be entirely rewritten etc. This was a very technical description of a easily moddable system, and while my "how to design it code-wise"-suggestions might not work so well, the basic premise of a floating player inventory with action slots is what should definitely be implemented somehow.

I think the game has a long way to go to be called "finished", I would judge the current content to be 30% of the way. The main problem now is, that a lot of systems feel unfinished: Smithing needs a big rework, hopefully promoting player skill. Iron production needs to be finished, there needs to be an iron bloom that is worked. Knapping/pottery is a very annoying task, I would like the recipes to have a smaller grid with bigger tiles. Farming could use more diverse crops, maybe fruit trees (see Growthcraft). Food and health balancing needed, maybe introduction of stamina. Underground/cave rework (cave biomes, deeper = dangerous) The bag/inventory system needs to be reworked/rebalanced. Animals and mobs need an AI and behavior rework, right now everything is a monster that wants to kill you. Combat is the worst, I will probably post a more streamlined overhaul suggestion soon. The current ore/prospecting system feels kinda useless, finding tin is really hard. Would love to see something like in Reasonable Realism. Connected textures are desperately needed, I can't stand the look of redwood trees anymore. Now to missing/needed features for release: Steel age. Leather working. Animal husbandry. Mechanical power system. Mechanical computing system. Minecart/railroad system. Mechanical automation tools. Alchemy and herbology systems. Cooking and nutrition systems. Armor system. Seasons and weathers. Oceans and drowning. A tutorial and an TMI/NEI/JEI of some sort. And this was just the survival mode content I think the game needs. Some things that you also planned: More story content, maybe dungeons, should only be released at 1.0, to contemplate spoiling the story before release. Villages and npcs. I feel like a basic system like in minecraft would be very disappointing, so I would push this behind the release in a big update. And here are some things the game may not need imo: Player stats/attributes, they usually promote grinding and systems that require no player skill. More streamlining, the audience for this game isn't stupid and wants something that is more than a pretty minecraft clone.

There will be NPC's and Monsters in the game, and the game has Multiplayer. Combat is an essential part of the game, so weapons are too. The sword has historically been one of the most useful weapons and should therefore stay included in the game. At least in multiplayer, a sword is required.

A small mod that adds one new block with special properties to the game: The scaffolding! Features: -Climbable -Vertical deployment -Breaking the bottom scaffolding will result in all scaffoldings above breaking too! ScaffoldingMod.zip

My opinion on death punishment: Gravestone, no item despawning. Makes death dangerous, but not frustrating.