Inactive Crafting

[ironchefpython]

But it is not going to be any harder to add steps and animations to the minion's process if those steps aren't used as part of the recipe.

Correct, you could take a recipe without physical steps, and add a sequence of physical steps that would be required to craft the item. But that's like saying you can make an ice cream cake by putting ice cream on a cake.

With MC you could make 64 or more items instantly (once you set up the recipe). If you can do a similar thing in TS, then the value of minion-crafting labor is much decreased. Presumably they work slowly enough to keep them busy, and can't turn a full chest/stockpile of raw materials into a completed product in seconds. So if it works as you describe, it will always be quicker (usually much, much quicker) for you to make stuff in quantity.

Actually, I would like to see player crafting take as much (game) time as minion crafting. When a player is crafting, it should take a second or two, but a significant amount of game time should elapse (minutes, hours, or even weeks for master craftsmanship). This would be similar to sleeping, where you speed up the game world, and 8 hours of sleep takes just a second or two.

This could vary based on the type of mod. For a multiplayer world, this might not make much sense, so player crafting times might be reduced from 1 to 60 seconds of realtime, or it might be that only minions can craft, and the player would never bother himself.

why go through the trouble of designing a complicated crafting/recipe system, if the player will probably use it only once per item

The crafting system I envisioned consisted of materials and transformations to produce a final output. A recipe would be used every time something was made, and require the same materials and transformation each time, but I'd like to eliminate the clicks required to do so for subsequent manufactures. The crafting area would display the recipe automatically, instead of the player needing to set it up manually.

 

[ironchefpython]

Also, I realized one of the positional elements earlier might be quirky - namely whether you use position to determine whether you'd cut a piece of wood by the x, y, or z axis - when any of those creates a product you could get from just cutting one way and rotating the block Might get trickier when you're making a flatter object rather than cutting it in half each time.

The over vs. under to determine whether consecutive cuts are made along the previous axis or a new axis is totally abstract, synthetic, and arbitrary. There isn't any 3d modeling going on, just a fixed set of recipes that allow cutting a square shape into a series of subshapes via a series of transformations that is more evocative of actual physics than accurate.

 

[eleazzaar]

Also, I realized one of the positional elements earlier might be quirky - namely whether you use position to determine whether you'd cut a piece of wood by the x, y, or z axis - when any of those creates a product you could get from just cutting one way and rotating the block Might get trickier when you're making a flatter object rather than cutting it in half each time.

The over vs. under to determine whether consecutive cuts are made along the previous axis or a new axis is totally abstract, synthetic, and arbitrary. There isn't any 3d modeling going on, just a fixed set of recipes that allow cutting a square shape into a series of subshapes via a series of transformations that is more evocative of actual physics than accurate.

That i agree with. If you try to make crafting mirror nearly too exactly the actual process of making something you'll get sucked down the rabbit-hole of endless complexity.

 

[Cervator]

As for recipes and their sensibility, I'd like to take inspiration from the blueprint process in EVE (there I go again) where a recipe is a physical component in manufacturing (not just conceptual instructions) and might be researched to improve material efficiency and processing speed. Mainly makes sense for minions, again - essentially you spend time on improving the instructions and techniques used for manufacturing and that lowers overall time taken and material waste.

You could even introduce the blueprint original + copy concept, where a copy has limited uses - so you create a copy and can give it away / sell it without giving away the "secret" to create whatever it is. There are actually two different classes of recipes here - putting blocks together and optionally shrinking the result (think structures and custom shape blocks like stairs here), then also non-block item recipes. I think of structure designs as blueprints, shrunk structure designs as schematics, and items recipes as, well, items recipes.

The simple structural block-based recipes you could probably replicate just by analyzing the design - which may be based on a design built in the world by blocks then shrunk down to a single metric cube (custom shaped blocks). Other recipes could still be based on a series of processes + materials + tools resulting in a non-block based item of a certain quality. Both would be subject to waste, so even if you could replicate a tower blueprint your un-researched version could take longer for minions to build with more material used

Efficiency and recipes like this may not make sense when considering the typical MC-style crafting setup where you put two sticks and three rocks in a crafting grid and get exactly one pickaxe. And maybe that sort of system itself may not make sense (using such exact low quantities of very specifically sized objects). We're already going to a mini-cube with waste approach for harvesting that might need additional processing to be useful (or big again), maybe we should break with other "standards" as well.

Perhaps instead of visualizing "block objects" as one unit of resource that is placed in x cells (possibly over multiple processes) to create one output we can instead deal in numbers and types. Say you get a piece of leather from a cow - in MC maybe 2-3 individual units of leather drop and they're used in exact numbers & shapes in a crafting grid to create exactly one item. Maybe instead that one piece can have a variable amount in it, and processing it into usable leather can add waste. Then a process that simply requires an appropriate material (soft yet hardy) can be directed to use said leather in a specific process matched with other stuff and a quantity amount will be taken out of the leather by the recipe, again modified by assorted efficiencies, tools, etc.

Goes a bit with non-cell based inventory too.

 

[ironchefpython]

I'd like to take inspiration from the blueprint process in EVE

If you're asking if this should be possible to do in a mod, I would say yes.

If you're asking if this should be part of core single-player gameplay, I do not see it as something that would add more "fun" to the game than it lost due to increased micro-management. One of the most difficult parts of DF was trying to find and optimize usage of individual items such as masterwork weapons. Adding the same kind of complexity for crafting would be annoying, and automating it would remove it as a gameplay factor.

 

[Cervator]

I might still be prone to lapse into design ideas meant for the future state in which we do have full multiplayer support. While there might be some cases where I could see it make sense in a single player DF-style setup, I do acknowledge it would mainly shine in a multiplayer setting, and beyond that too...

 

[eleazzaar]

I might still be prone to lapse into design ideas meant for the future state in which we do have full multiplayer support. While there might be some cases where I could see it make sense in a single player DF-style setup, I do acknowledge it would mainly shine in a multiplayer setting, and beyond that too...

Wait, so is Multiplayer just something that hasn't been implemented yet, or something intended for a totally different game mode that may be added later?

 

[Cervator]

Implemented later for sure, for everything. We might try to aim for a viable single-player "simple" mode just to implement something viable in the near future.

 

[B!0HAX]

off·topic reply

can't wait to test some multiplayer PvP mechanics
:]
[0ff·t0pic reply....]

 

[eleazzaar]

Implemented later for sure, for everything. We might try to aim for a viable single-player "simple" mode just to implement something viable in the near future.

That's not what i'm getting at.
Good multiplayer design and good single-player design are often in conflict. Most obviously: the irregular time-speed that's so convenient in many single player games, but doesn't work for MP. If a game has both SP and MP, usually one or both modes is gimped a little to accommodate the other. Or the two modes diverge and are parts of different play experiences, which usually increases the development load.

At the top of the page ironchefpython lays some plans for mechanics that are fine for SP, but wouldn't work for MP. I'm not saying he's wrong-- just that how you include MP is a very significant choice. I'm trying to find out if it has been a conscious choice, or it the decision hasn't really been made. As i see it you have two basic options:

1) Design the game for the optimum SP experience. Later, try to add fit in an MP mode, quite possibly significantly revising the feel and mechanics of the game to accommodate MP realities.

2) Code the game now for SP-- but always consider MP compatability-- even when it hurts SP play a little, so that MP can be added with a minimum of alterations-- making it feel like the same game-- just with more real people.

 

[ironchefpython]

At the top of the page ironchefpython lays some plans for mechanics that are fine for SP, but wouldn't work for MP. I'm not saying he's wrong-- just that how you include MP is a very significant choice. I'm trying to find out if it has been a conscious choice, or it the decision hasn't really been made. As i see it you have two basic options:

In my opinion, the engine should be designed with multiplayer in mind from the beginning. In fact, I'm a little worried that we might fall into the same trap that Minecraft did, by building the single-player engine first, we are making decisions that may make multi-client communication more difficult.

In terms of mods (and this includes both crafting and inventory), I could not possibly care less if one gameplay mod had insanely complex crafting, and another mod has a wishing system where you just wish for items. I don't care if one mod lets you put a shipping crate inside a backpack and put that inside a teacup next to a whale and a piano, while another mod carefully tracks encumbrance and weight, and you can only carry what you can hold in your hands.

A single-player DF PvE mod is going to have very different gameplay than some fast-paced PvP capture the flag mod. The only thing I care about is that the engine supports all these modes.

The crafting system I proposed was to be a crafting system, not necessarily the crafting system.

Design the game...

This is the difference in viewpoint. I don't see us designing THE "game", I see us designing THE engine, and one ore more mods that provide gameplay on top of that engine.

 

[woodspeople]

Have not had time to keep up with this discussion other than a quick glance. Super quick notes:

1. The reason I don't like "craft" is that it links too closely with the medievalist-fantasy theme. When you are creating a futuristic space-time singularity vortex, crafting sounds just silly. If there was a word that worked better in many backstories it would be more universally useful.

2. Don't get rid of nesting storage!! But I agree that having it go beyond like three levels is too much. To some people inventory management is tedium, to others it's the funnest part of the game, shuffling your stuff around, and the more complex ways to shuffle it the funner the game. Getting "sucked down the rabbit-hole of endless complexity" is some people's idea of fun. Of course that could mean it should be a mod. The better the modding system the less you have to address all definitions of fun in the main game. But be careful of saying "nobody wants a game to do x" because you might not be the prototype for all human beings.

3. Agree about the need to think about prioritization of single and multi player up front. Like eleazzar's option two best. Actually if I was coding TS I'd stop right now and make it work in multiplayer, so as to avoid any messes later on from having to bolt on MP things. Easy to say though when you are not the one doing the work

4. As to what ironchefpython wrote last, agree with every single word of it.

 

[ironchefpython]

2. Don't get rid of nesting storage!! But I agree that having it go beyond like three levels is too much. To some people inventory management is tedium, to others it's the funnest part of the game, shuffling your stuff around, and the more complex ways to shuffle it the funner the game. Getting "sucked down the rabbit-hole of endless complexity" is some people's idea of fun. Of course that could mean it should be a mod. The better the modding system the less you have to address all definitions of fun in the main game. But be careful of saying "nobody wants a game to do x" because you might not be the prototype for all human beings.

Indeed, there are multiple types of games.

A CTF game might have zero inventory management, and this is good, because the focus should be on killing people and capturing flags.

A dwarf-fortress style should have minimal inventory management and moderate crafting complexity, so you can focus on minon management fun.

A hack/slash style PvE game can go WAY down the rabbit hole of inventory management with each item having size, shape and weight, putting containers in containers or whatever. Games like Diablo are all about collecting shiny objects and making inventory tradeoffs, and some people enjoy that style of game.

I want all kinds of fun to be possible.

 

[eleazzaar]

Indeed, there are multiple types of games.

A CTF game might have zero inventory management, and this is good, because the focus should be on killing people and capturing flags.

A dwarf-fortress style should have minimal inventory management and moderate crafting complexity, so you can focus on minon management fun.

A hack/slash style PvE game can go WAY down the rabbit hole of inventory management with each item having size, shape and weight, putting containers in containers or whatever. Games like Diablo are all about collecting shiny objects and making inventory tradeoffs, and some people enjoy that style of game.

I want all kinds of fun to be possible.

I'm not a coder, but i have been an observer and closely involved in a number of game projects. (see my brief bio) I don't know everything, but both from the inside and outside, i've seen projects succeed, and seen some die, and some very slowly plod on. For a number of years i've been very interested in what made the difference.

Setting out to make an all-purpose Voxel game engine is one way to go, but in my experience, thats a path generally associated with failed/stalled FOSS projects. The grander, the more all-encompassing and non-specific the vision the greater the probability that the community will shrivel up, or the code will collapse under the weight of it's own complexity before anything playable and fun is produced. While proclaiming: "this game can be modded to do anything and everything" may make for a harmonious forum in the beginning, trying to please everyone often leads to delighting no-one, with unfocused development that wanders back and forth.

Reaching the point where the game is fun to play, even if incomplete, is IMHO very important. That's where a project can start to really attract a community and gain a life of it's own. That's why i think it's very important to at the start design a game, and make it lean and to the point. In as much as possible-- without creating too much of a mess for later on-- skip what's unnecessary, and focus on what adds the most fun in the shortest time.

Modding is great, and wherever it is reasonable, making the engine flexible is great. But if these are actually the goals of the project, and you want the best chance of achieving them -- trying to make the ultimate, assumption-less generic voxel engine should not be the path.

 

[ironchefpython]

Modding is great, and wherever it is reasonable, making the engine flexible is great. But if these are actually the goals of the project, and you want the best chance of achieving them -- trying to make the ultimate, assumption-less generic voxel engine should not be the path.

I understand what you're saying, and while you might be right, I have no interest in creating a game where the ease of creating content isn't the #1 priority. It's just a personal preference, and I completely understand the point you're making.

 

[Cervator]

I think ironchefpython sums it up well in the multiplayer-centric engine with some mods possibly turning the focus back on single-player. So I'd say that we should put MP first - easier to add time-warping in a mod while simultaneously disabling multiplayer to avoid having to take considerations into effect.

At the same time I also see the point about implementing something rather than go pure engine. I think that's where we're getting to by throwing big milestones out there like Genesis, Untrue Tao, etc. We're not going to perfect the engine first, then start making every game under the sun, that almost sounds similar to the language discussion we had earlier about the modding system: less is more.

So I definitely want to see a focused goal we can coalesce around on the way to making a super flexible platform.

 

[woodspeople]

1. I find TS fun to play with already especially the options for blowing things up

2. Since we have no minions here and are all volunteers, we need to draw on our varied interests to sustain the work involved. One thing I think we can all agree on based on the discussions so far is that we all want to play a great game, but we don't want to play the same game. So making that possible seems like it is the thing that unifies us, more than any one game vision. The vision is variety, you could say. If TS is only about killing monsters, I'm outta here, because that's not the game I want to play. If TS is only about not killing monsters, some other people are outta here. So the best way to keep everyone interested is to keep things open. When ironchefpython said "I have no interest in creating a game where the ease of creating content isn't the #1 priority", all I can say is "ditto for me"

3. My experience has been that open systems can be paradoxically more efficient than closed systems. They seem like you are spending loads of time building nothing but infrastructure, but then when there is a platform to build on, people suddenly start generating content. If you look at MC, for example, people have built amazing mods for it even though you have to fight the thing tooth and nail both to build mods and to use them. Imagine what it could have been like if they had made a non-stupid modding system from the get-go.

4. I've also seen FOSS projects live and die (most of mine have died, due to my having to abandon them to make money . In my experience what has made the difference is (a) whether a core group forms at all, (b) whether the core group communicates in ways that maximize productive conflict (respectful disagreements like this one here) and minimize unproductive conflict (insults, put-downs, etc), (c) whether the core group can come to an agreement on something they want to build that they all feel is worth their time and energy, and (d) whether power is shared in positive ways and nobody appoints themselves bosses and the others minions. These factors have a lot to do with the core-core group, usually just one or two people who power the whole thing, at least at the start. For this group we are doing great on (a) and (b) so far; (c) is getting there but not quite complete; (d) is too soon to say.

All my humble opinions. (The mom part of woodspeople only; the child says simply (and this is a direct quote) "I agree with ironchefpython".)

 

[overdhose]

there are 2 ways to go about things if you ask me.

1 is to debate a lot about it, decide whats best and start making that.
another is to actually create something working and see if people like it. If they don't, you can still use it as a mod yourself, and maintain it. The way that works is that one party will acknowledge the other systems superiority and decide to join it, or both will be available, its a win win situation. Add a toggle in the options menu and voila, which crafting system would you like?

No time for a menu? Use a console command. Issue solved.

 

[woodspeople]

If they don't, you can still use it as a mod yourself, and maintain it.

You can only do that if you build some sort of modding system, even if you only use it yourself!

Having said that, I do think eleazzaar has a point in saying that extremely vague intentions go nowhere. There is a balance to be sought between flexibility and focus. Having said that, I think a very easily moddable game engine is a great focus. Besides, smart infrastructure doesn't have to take forever. Sounds like things are already coming along on the JSON front.

I again evoke the rule of open source: those who know how the work should be done must always give way to those who actually do the work. Bonafide contribution trumps opinion every time. Said with respect towards all :ugeek:

 

[Immortius]

There are three levels of things being talked about here:

1. Terasology's engine/foundation. This should be reasonably flexible, extendable, moddable, etc, to a point. It won't do everything, otherwise it would be no different from any of the other available engines - it is specialized to handle a certain type of voxel world, being interacted with from a first or third person view, and so forth. I think we're making reasonable strides towards this goal - textures, mesh, materials, sounds and prefabs can all be added in mods right now. Blocks and block shapes can be added to, although only to the main engine at the moment. While not yet possible, components, events and systems all primed for future modability. And there's what ironchefpython is working on too.

Basically I think this is thoroughly covered at this point? Probably too covered, because we really need to actually do some work on:

2. Terasology's primary game type(s). They themselves will support modding in via the core modding framework (all game types will, really). You can think of them as example mods, or tech demos, or reference implementations - to an extent they will exist to test and demonstrate the capabilities of the engine, and show by example how to create mods. And to provide a base for more complex mods.

These game types do not need to be everything to everyone, and I feel they would benefit from a much more focused goals.

And to be clear, things like how the inventory works, how crafting works, how combat works, whether the character has a health bar or damage regions - these are game type/mod decisions, not hard-coded engine behavior.

3. Other mods, whether built on top of one of the primary game types, or as total conversions. Anyone can create and maintain one of these. The one exception is where they require some new capability in the engine to support them, in which case the core team may look into it, or integrate a supplied change. But the core team is not required to add the features of these mods - they just need to provide the potential to add them.

Anyway, we really need to split the forums up on these three things, because it can be kind of confusing. When someone says "Terasology should have a weight-based inventory" it isn't clear whether they mean the engine or the primary game type.