Jump to content

Erik

Very Important Vintarian
  • Content Count

    125
  • Joined

  • Last visited

  • Days Won

    16

Erik last won the day on November 11

Erik had the most liked content!

Community Reputation

30 Excellent

About Erik

  • Rank
    Bronze Caster

Recent Profile Visitors

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

  1. Erik

    Metal progress branching

    We both want the same thing, crushing ores being a process the player does in Vintage Story, we just want to archive it in different ways. I just don't want crushing to be a useless pain the player has to go through without reason, just to make the crafting chain longer and metal tools more difficult to get. I want to make crushing ores logical, not on a realism perspective, but on a gameplay perspective: When not crushing you ores gives you less metal, then there is a gameplay incentive to crush ores. And because players would be worse of not crushing ores, when they finally have build a metal hammer, they will crush ores, because it will give them huge benefits. And because they couldn't crush ores before they had a metal hammer, they know what it means not to crush ores, how much ore they "wasted". Crushing ores therefore, while being optional, can be used as a soft requirement, with higher tier stuff requiring more metal. The mechanical hammer would still be very relevant, as it makes the progress of crushing ores faster, more efficient and not eating your hammers durability, while also being able to be automated. This alone is inventive enough to make the mechanical hammer very viable for most players, but it can be further enhanced: Some ores may only be crush-able by the mechanical hammer, for example iron. The mechanical hammer could even be required for processing some things, like geodes, which could make it a required part of the tech tree later on. To clean up one last thing: Crushing wouldn't cause a higher ore output, but not crushing would cause a lower ore output. It's just a change of wording, meaning the same thing as "crushing causes higher ore output", but maybe it helps this discussion. The ore output is of course only relative and not further discussed in any of my posts. I fell like I repeated myself a lot in the last few posts and that probably means that this discussion isn't really going anywhere, without some outside opinions.
  2. Erik

    The 3 basic mechanical power

    Do not forget steam engines. While they were invented much later than the other methods you mention, they were often used to provide mechanical and only much later to generate electricity.
  3. Erik

    Metal progress branching

    There isn't a definitive line. My point is just to design interesting gameplay and not depictions of the real world. Could butchering be an interesting piece of gameplay? Hell yeah! There are many interesting things that butchering could enable gameplay wise and it will add a lot of immersion. Why smelting? Maybe to gate the player to do pottery and charcoal? Maybe because the game would be boring and pointless without smelting? True, but we can make the player feel like it isn't required, but his decision, because it is fun and/or rewarding. And that is why we shouldn't design gameplay to be realistic and hardcore, but to be fun and rewarding (that doesn't mean hardcore and realistic can't be fun, just that it isn't always).
  4. Erik

    Metal progress branching

    The reward should be doubled ore output, which makes the optional effort really worth it and makes crushing ores something that players want to do and not something they are forced to do. For this to apply, ore crushing needs to be optional. Well, ore crushing is a case of metal progression and the main question is, if it should be optional. Most suggestions on this thread seem to be designed to be realistic, not to provide rewarding, and easy to understand, streamlined and most notably fun gameplay. "Hardcore" does not translate into "better".
  5. Erik

    Metal progress branching

    We may have very different opinions on how to do meaningful, rewarding progression: If I understand correctly, you seem to want a "wide progression", where most of the mechanics of the game are available at the start (i.e. stone age) in some way or form, with all mechanics being effectively required to progress. The later stages of the game just "upgrade" these mechanics and make them faster or more efficient. My way of doing progression would be more akin to an inverted pyramid, starting with very few mechanics and adding new mechanics with each stage of progression, with "upgrades" being very rare and many mechanics being introduced as optional first to become required later in the progression. Both ways of doing progression have their advantages and disadvantages and further discussion of this would probably be fit better on another thread. I was just referring to my previous post about post about ore crushing being optional at first, then requiring a mechanical hammer for higher tier ores and then being required for highest tier ores. Sorry for the confusing term. This is realism, not gameplay oriented. I get that people used water powered hammers and horse powered mills, but that doesn't mean they should be in the game. We will have a mechanical power network with hopefully interesting design problems and that network should be put to use, as it would be the most mechanically interesting (balancing torque and speed) and easiest way to add a mechanical hammer to the game, with multiple options of powering it. The act of crushing ores should imo be rewarding, even with a hammer and not something boring or even annoying just to make using the powered crusher feel more rewarding.
  6. Erik

    Metal progress branching

    I meant gameplay reasons, how it would benefit gameplay, not realism. While stone hammers did exist, they aren't very useful or safe for crushing ores and they would also go against the staged progression I outlined, making crushing ores less rewarding.
  7. Erik

    Metal progress branching

    Extra durability compared to what? Sure, making things harder also makes them more rewarding, but rewards are measured in relations. Only when there is a way to get fewer rewards, the rewards will truly feel more rewarding. When the player things it was his decision that have him better rewards, the rewards will feel even more rewarding.
  8. Erik

    Metal progress branching

    Why should there be a large number of hammery machines? It doesn't exactly have to be that animal mill, just some form of animal mill (just for energy generation, not for milling). Progression should come in small steps, not all at once. The player can only craft a hammer when he has metal, so it is essentially needed to skip the crushing on the first batch of ore. The ability to get more out of ore is something very desirable, so most players will make use of it when they have ore, it will feel like they archived something, because they progressed. When the player would need to crush the ores in the first place with some stone hammer, it wouldn't be a rewarding progression step, the player wouldn't get more ore for his work, because there is no way to get less ore. What remains is doing a lot of things to archive a simple task. This can overwhelm or confuse some players, because they wonder why they can't smelt their ores, which is bad.
  9. Erik

    Metal progress branching

    @redram Game design > Historical accuracy/realism Why should there be a water mill hammer, when there is already a waterwheel? When there is a power system, ideally machines would use the power system and not going for a combined machine-generator approach. That would also make the machine way more flexible and realistic in a sense, as it didn't matter what exactly powered the mechanical hammer, as long as it would get enough power. On the larger question: I think crushing ores for extra returns should be optional. As it is in modded minecraft, most players like to put in that extra effort, even if optional (There is a reason almost every tech mod has some form of ore duplication). Some things however, like iron blooms, should require that extra effort of either smacking it with a hammer (a lot) or building a mechanical hammer that smashes it. This is both good on a game design and realism part, as it forces the player to progress, without overwhelming him. Some things could even require a strictly mechanical hammer, supplied by a very high torque, like rare endgame geodes containing endgame metals for endgame steels or alloys (This would be an interesting and somewhat believable way to introduce metals like aluminum or titanium). If a machine isn't useful it shouldn't be in the game. The players will build useful machines even when they are optional, as long as progression renders them not obsolete. Making machines optional at first and later required for progression helps smooth out the progression curve. In most cases it isn't (or better shouldn't) even that hard to build the machines, but they shouldn't be the easy solution to all problems (looks angrily at EnderIO conduits), but pose their own problems that the player can either live with or fix via (hopefully interesting) automation. This should obviously encourage automation, but I don't think automation should be required for progression, just highly encouraged.
  10. Erik

    Metal progress branching

    @redram While I generally like the idea of more involved metal/ore processing, I think your way of essentially having three machines that accomplish the the same thing needs some streamlining. Since there will be a mechanical power system, I think the "crushing device" should utilize it, requiring a lot of torque (maybe based on ore type), the speed reflecting in the speed of the crushing operation. I think a powered hammer (like the monjolo, but not water driven) would be the best representation of a crushing device, as it would look more spectacular than the stamp mill. Maybe have different material hammer heads for some additional progression gating or alternative uses (axe head to turn it into a early game wood processing device, before a mechanical saw which would require iron or steel). Keeping the powered hammer GUI-less would also be something easily possible, as the hammerhead could always smash on a block in the world, so any block (or item) at that location would be crushed, which could make for some interesting automation solutions involving pistons and perfect timing. On another topic, the horse mill shouldn't be a device, but an early game producer of mechanical power.
  11. Erik

    Mod/Feature Request: Growing Trees

    @copygirl The base mod adds wider trees! To be fair, it just added it six days ago and is still considered alpha state (while being very stable).
  12. Erik

    Mod/Feature Request: Growing Trees

    @copygirl had started a mod like that: https://github.com/copygirl/GrowingTree Since the repo hasn't been updated in ten months and the currently implemented features are just branch-blocks and their placement, I suspect the mod won't release anytime soon, but there is still hope that it might come someday.
  13. Engineering in Vintage Story Split of the mechanical energy system and the mechanical computing system. This is one of the most important things, because both systems try to archive very different things which would benefit from very different mechanics. The energy system cares about rotation speed, torque and maybe inertia, which are useless in a computational system, which that needs binary states, like the direction of rotation. Other than that, splitting the two would also make performance optimization easier, allowing for bigger and better machines. Furthermore the split is also helpful on a game design side, as it emphasizes the split of functionality very well. Material split for mechanical energy and computing system. To make the split more evident for the player, I suggest using different materials for the energy and the computing system: Wood for energy and brass for computing. The energy system should pose interesting problems for the player. It is very important that using mechanical energy needs to pose engineering problems for the player to solve. Otherwise, mechanical energy would be a pretty dull cosmetic addition. As mechanical energy is compromised of at least two variables, being speed and torque, converting and balancing these could present an interesting engineering challenge. Fluctuating energy output on certain generators could make automatic gearbox-adjusting a new and interesting engineering challenge, when certain energy consumers need a specific minimum or maximum value of one of the two variables to function or change behaviour when receiving different values. Mechanical computing should be based around the geneva drive. The geneva drive is a gear mechanism that turns constant rotation into intermittent rotary motion. It is used in mechanical clocks and therefore allows for the very cool name of "clockwork engineering" to be used for mechanical computing. As mechanical computing is driven by a clock, it further emulates real electrical computing. Geneva drive could be operated at different speeds using different speed of mechanical energy to provide different clockwork tick speeds. The torque provided to the geneva drive could limit the number of components driven by it, not working at all when the torque provided is too low. Gear rotation direction as a binary unit for clockwork engineering. Unlike redstone, clockwork engineering shouldn't violate the conservation of energy completely, so the on-off state can't be efficiently used for binary computing, without making clockwork computers huge. Therefore gear rotation should be used as the primary binary unit, as inverting it is as easy as placing two gears next to each other. Mechanical sensors should be present to provide single clockwork ticks. As clockwork circuits only operate when ticking, they would need to check constantly for changes at sensors. This would add a lot of unnecessary computation efforts, which could result in bad performance, as well as making simple tasks much more complex. To oppose this, mechanical sensors should be able to provide single clockwork ticks. The sensors shouldn't produce power out of nothing, so there should always be some mechanical explanation for a tick, like an entity detector being a piston that pushes down and therefore produces a mechanical signal turned into a clockwork tick. Torque as a variable sensor output. The sensors could also output different values of torque, depending on the measured thing, i.e. a heavy entity, item or block would provide a higher torque for the tick. This would play further into the realisms side and could also have some practical uses, like clockwork circuits being so large, that they only activate when the sensor provides a certain torque. To make systems like this possible, a clockwork resistor block, which adds addition torque requirements to the clockwork circuit, would be useful. Furthermore, to make sensors actually useful for processing weak signals, geneva drives may have a mode to activate for a tick, when they get ticked. This allows having a weak signal with a weak torque triggering a geneva drive to provide a single tick with a torque based on the torque input by mechanical energy. Any mechanical (automation) block should have a very general and simple functionality. General means is that a block should always have more than one application. Simple means that single blocks should only be able to solve very small and simple problems, bigger more specialized problems should be solved by combining simple functionalities of the single blocks in interesting ways. After all, engineering should always be a puzzle for players to solve and not a solution they get after grinding materials. This should apply to all aspects of engineering (automation, mechanical computing, mechanical power) in Vintage Story, never providing players with a simple "Automatic farm"-block. Simple functionality also has the side effect of making blocks easier to understand.
  14. Erik

    Survival mode chisel

    To turn them into actual stairs and slabs you have to recognize the shape in any rotation. This would require as much work as to turn chiseled blocks into stackable, rotated variants. This would also solve the stacking problem. You can chisel chiseled blocks after placing them. Chiseled blocks are also very optimized memory wise and rendering them isn't any more expansive than rendering slabs or stairs.
  15. Erik

    Survival mode chisel

    Are there any right now? And if there where, Tyron could fix them. But then the block can't be chiseled further. Slabs/stairs aren't chisel-able and this is the main reason against them. The change you suggest would therefore actively hurt gameplay. As I said in my previous post, slabs and stairs could still be crafted with my changes, but they would technically be chiseled blocks.
×

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.