![[de]](/mwf/flags/de.png "Germany")
Related to the discussion in the liquid container things, and the discussion in the feature wish: http://bugs.openclonk.org/view.php?id=1148
I think a good option would be the format:
It has the following advantages:
- the original object does not have to know anything about the object that can substitute it, so it can be used by modders for their new content
- the user can decide if this object is a substitute in all products (e.g. bear skin can replace wipf skin), or in specific products (a smelter can produce metal from ore and coal. The ore may be substituted by a metal barrel in this specific case)
- the user has the option to set a different ratio for the substituted component (e.g. a monster egg can be substituted by 2 bird eggs in my omelette).
I think a good option would be the format:
IsSubstituteForComponent(id in_product){ return [id component, int amount];}It has the following advantages:
- the original object does not have to know anything about the object that can substitute it, so it can be used by modders for their new content
- the user can decide if this object is a substitute in all products (e.g. bear skin can replace wipf skin), or in specific products (a smelter can produce metal from ore and coal. The ore may be substituted by a metal barrel in this specific case)
- the user has the option to set a different ratio for the substituted component (e.g. a monster egg can be substituted by 2 bird eggs in my omelette).
It think it is a necessity to be able to show all possible components in the UI somewhere - similar to how components are currently shown.If the callback was non-parametric (func CanReplaceBla() {return [Earth, Sand];}), it would be easy to just create a mapping on scenario-startup which could be used in the UI. This would be a bit harder if the callback was so situational
This should be possible with my suggestion / pseudo-code ahead. Probably it is easier to have the function work like this:
The returned array would then be something like:
IsSubstituteForComponent(id component, id in_product){ return amount;}
func GetPossibleComponentCombinationsForProduct(id product)
{
// have some kind of map map_components that maps original components to substitutes with amount
var map_components = ...;
for (var component in product->GetComponents())
{
PushBack(map_components[component], [component, required_amount]);
for (var substitute in all_definitions)
{
var amount = substitute->IsSubstituteForComponent(component, product);
if (amount)
{
PushBack(map_components[component], [substitute, required_amount * amount]);
}
}
}
// make an array with all the combinations, which could be quite a lot. Thank god we don't have recursive substitutions!
var combinations = ...;
return combinations
}
The returned array would then be something like:
GetPossibleComponentCombinationsForProduct(Bread) =
[[[Wheat, 1], [Water, 50], [Yeast, 1]],
[[Rye, 1], [Water, 50], [Yeast, 1]],
[[Wheat, 1], [Water, 50], [BakingSoda, 1]],
[[Rye, 1], [Water, 50], [BakingSoda, 1]]]
Well, yeah, my point was not that it was impossible to program, but my point was that it might be very big
Maybe I did not get your suggestion then. Could you post an example as well?
An example for what? Just create your list from your example for every product at the beginning of the game and store it in a way so that it can be accessed without recalculation later and you are possibly already at "very big".
An example for the less complex mapping. I know that the all combinations are very complex, and I understood that you wanted to show all possible combinations in the UI. I prefer Sven2's solution in the end, because there would be less information to display.
![[us]](/mwf/flags/us.png "United States")
I think replacements should be done at the component level only and not calculate all possible combinations, because that can potentially be a lot. E.g. in the western pack I believe we had ~4 different sources of fur. If you also have ~4 sources of wood and then build something of fur and wood you're already at 16 entries.I would rather represent it like this: Components: 1xWheat (or 1xRye), 50xWater, 1xYeast (or 1xBakingSoda)
Otherwise, I think the suggestion is fine. We may want to do the component collection for each product individually only the first time it's queried and store that in a global cache.
KISSThis would make things only more complicated with very little gain. I oppose this.
Well, having some way to replace components would e.g. be needed for this
Well, thats very little gain. Also, why would you want to make loam out of sand? Apart from that it does not make sense, what is the gameplay value of that?
Maybe you only have sand in a desert scenario. Also using ice instead of water is useful because you can carry ice without a bucket.I could imagine other scenarios such as a new tree providing a different kind of wood that should be allowed as a replacement for regular wood. It could hack itself with SetGraphics, but then it's limited to the same shape as the regular wood. Or an OMGWTF object that is a replacement material for everything :-)
Having multiple possible components was a very common problem in Clonk Rage with the Western pack because each animal had a different type of skin but they could all be used e.g. to build tents. I think the solution then was to have them all be the same ID with hacks for the graphics, which caused trouble e.g. when you ChangeDef'ed stuff.
The way you are describing the problem actually sounds like a perfect fit for what in programming is polymorphism. It would not fit all the use cases described by marky above (eg different ratio) but be a much cleaner metaphor. A Tent needs Hide, CowHide is Hide.
>A Tent needs Hide, CowHide is Hide.
Well, that's basically what the callback "CanReplaceFoo()" would mean. Just not on an ID level but on slightly lower level. Instead of looking for components with
Find_ID(Foo), you'd have to use Find_Or(Find_ID(Foo), Find_Func("CanReplcae", Foo)). If we'd really want to go the all-clean approach, then we could also have a global func CanReplace(id def) {return def == GetID(); }. So you could just use the Find_Func part.I don't think we can get much cleaner with what C4Script has to offer. Inheritance would also mean inheriting attributes (and script) of the other objects. That's probably not what we want in most cases.
>Maybe you only have sand in a desert scenario.
That is a weak argument. It is up to the scenario designer to ensure that everything that is needed to complete the level is available in the level. I.e. with the same argumentation, I could argue that lava should substitute for firestone because "you may have only lava in a vulcano scenario". Imagine the other way around - perhaps the scenario designer wants water and earth to be scarce so that it actually turns into a valuable resource!
>I could imagine other scenarios such as a new tree providing a different kind of wood that should be allowed as a replacement for regular wood.
Why should it be different? There is no need for that. You can SetGraphics your custom wood pieces if you want i.e. the "mushroom tree" wood to look different, if you must.
But, again, my argument is: What is the added gameplay value for this? It just adds complexity in code, the engine and worst, the user interface. There is the potential to confuse the player so that he does not know what to do with these "sturdy mushroom pieces" and the best that can happen is that he ist just not confused.
Remember trade simulations, like Colonization? There are various sources you get hide (fur) from to ultimately make them into coats. But there was no distinction between the different types of hide, it was just hide. And the reason was not because the developers were too lazy to make graphics for deer hide, bear hide, bunny hide, etc... but because they wanted to make clear that it is one and the same resource with one and the same properties. KISS, it is about clarity and simplicity for the user.
You make some good points. We should not go overboard with alternate components unless there is concrete gameplay gain. So maybe we should avoid the different kinds of fur.I still think multiple components are a net gain when the source components are fundamentally different somehow. Particularly in the case of "use snow or ice for loam": Ice can be dug out and carried, while water needs a barrel. Using ice for loam is good because if you can find ice, you can create loam on a different production route in winter.
The case of sand for loam: It's probably expected because loam is mostly sand in real-life. It's also possible to have sand in the bucket because e.g. you happened to dig through sand when trying to fill it, but didn't think it would matter. Alternative solution: Change the bucket to create earth objects when you dig through sand or ashes. That solves the problem for the player without adding complexity.
So my suggestion: Allow the alternate components, but use them sparingly only if the source objects are actually very different.
Thank you. :-)Well, I think in real live glass is much more a product of sand than loam. And ice... did you ever try to build a sandcastle with sand+ice instead of sand+water? ;-)
Anyway, you brought up the ice. Your point is that ice is basically just solid water, so it should best be treated that way. That is the same line of argumentation as that sand is the same as earth. We rob ourselves (and scenario designers) of possibilities that way instead of doing us a favor here. If we make different materials equal, then it begs the question why we do have the different materials at all. Ice is already not "just another water" in that it is solid. I would rather build on the difference than on the equality. I.e. make it not diggable (ever tried digging through ice) to make it more of an obstacle and/or make ice a component in one of the more exotic items. Lava turns into a completely different material if it becomes solid. Ice could also be treated (more) differently to make it more interesting.
> I would rather build on the difference than on the equality. I.e. make it not diggable (ever tried digging through ice) to make it more of an obstacle and/or make ice a component in one of the more exotic items
Good one, I really like that suggestion. Also you won't be able to "hack water away" by digging in winter this way.
![[at]](/mwf/flags/at.png "Austria")
Sounds good. But then some kind of indicator that the water is going to freeze soon would be useful. Otherwise diving would become even more a deathtrap.
>It's probably expected because loam is mostly sand in real-life.
According to Wikipedia it's 40% sand and 40% silt (Schluff) and 20% clay (Ton). So loam is pretty much just earth (earth contains sand).
Without binding material, sand grains alone would not stick together.
I am with you and Sven here. I don't think things as different types of wood (like in Terraria) make any sense at this point. We can rethink that maybe in five years or so.However, I still believe that by allowing alternatives at certain key points in production chains (e.g. cloth from cotton or fur) we can increase the replay value and problem-solving-freedom of OC. And it would actually be very similar to how we treat fuel at the moment: you can use coal, wood, moss - and probably more stuff.
The argument of simplicity could then also apply to the fuel - it would be simpler for the player if the only fuel was coal. And to burn wood or anything else, you'd first have to produce coal from it. This would obviously make the components simpler, following the KISS principle: you wouldn't have to explain what "fuel" is and the weird fire symbol would go away from the production menu.
I wouldn't say it's necessarily better for gameplay, though.
Ok, I get the point and know one applicable example:Be able to create cloth / ropes from both cotton and from animals. That's nice cause it does not limit the level design but expands it - just like having the possibility to create coal plants if there is no sky for wind generators.
Yes! A very practical example where cloth from fur would fit in perfectly, would be an underground scenario without sky, where cotton plants would look weird. But products from cloth might still be required to solve a certain problem.Following the same line of though, a scenario could have sky islands with cotton and caves with wipfs and the player would have to decide which tools and things to produce first depending on what she wants to use for cloth (elevator and pickaxe vs. grappling hook and loam for example).
Since this was discussed as a feature wish at the beginning of the milestone:
In the milestone the basic idea was that the CR-like structures "Bamboo hut, wood hut, stone hut" all share the same blueprint. That would also apply to palisades and castle parts, and a gold and a stone idol. The idea was to avoid awkward moments in CR: where you had 4 wood and a stone for a wood hut, but accidently build a stone hut, and had to resign. Buildings gets a bit more flexible. OC doesn't have any of those at the moment.
However I could imagine some use, for example:
-high teer items needing either a emerald or a ruby (or diamond).
-Clothing parts (diving helmet, balloon) needing either cotton or animal fur.
-buildings in different strength modifiers, bridge segments out of wood and lets say segments out of metal
-the mentioned ice instead of water in a blueprint also sounds logical to me
In that regard OC would gain a bit more freedom something I would like to support.
However I agree with you, that things should be kept simple. So that should be a high priority in the code and the UI if the feature is created.
In the milestone the basic idea was that the CR-like structures "Bamboo hut, wood hut, stone hut" all share the same blueprint. That would also apply to palisades and castle parts, and a gold and a stone idol. The idea was to avoid awkward moments in CR: where you had 4 wood and a stone for a wood hut, but accidently build a stone hut, and had to resign. Buildings gets a bit more flexible. OC doesn't have any of those at the moment.
However I could imagine some use, for example:
-high teer items needing either a emerald or a ruby (or diamond).
-Clothing parts (diving helmet, balloon) needing either cotton or animal fur.
-buildings in different strength modifiers, bridge segments out of wood and lets say segments out of metal
-the mentioned ice instead of water in a blueprint also sounds logical to me
In that regard OC would gain a bit more freedom something I would like to support.
However I agree with you, that things should be kept simple. So that should be a high priority in the code and the UI if the feature is created.
That's actually a really good point. One weakness of OC is currently that you have a pretty fixed setup: you build the furnace first, then the windmill and sawmill, then a flag, etc...Allowing different components would be a first step to making the game feel more free - because you can decide whether you want to build A or B to achieve your goal C. Currently the processes to build/achieve things are pretty much carved in stone.
I think that is the true gain in gameplay value.
> pretty fixed setup: you build the furnace first, then the windmill and sawmill, then a flag, etc... [...] because you can decide whether you want to build A or B to achieve your goal C
Can you give a concrete example how you would break this fixed setup of furnace, sawmill, flag etc.? And how this would add gameplay value?
It would mainly add replay value, I guess, because it would allow players to solve situations in different ways.Of course there would not be a sudden explosion of possibilities if we'd allow sand as an alternative to earth. However, that might already be a different story if we'd add fur (from wipfs e.g.) as a replacement for cotton. I guess that would open us some new possibilities for items.
And I guess it would not hurt to try to push the replayability up a bit.
I wonder why we don't just leave substitutes a secret and not bother about display. For all products we'd decide on a 'main' way to produce them and just display that (Components=...).It was mentioned in the bugtracker entry that we don't have a wiki that would explain these hidden secrets. Why not? We do actually have a wiki and could explain the game content in it. I always found these wikis (like in Minecraft or Terraria) a cool thing to explore game content I didn't yet found ingame.
Of course, if a designer decides to just use sand in a scenario but you still need loam to solve it, the designer should leave a few hints!
>For all products we'd decide on a 'main' way to produce them and just display that (Components=...).
That's basically a relic from ten years ago. I don't think that "because we always did it like that" counts as a good argument.
Also, Clonk has always been a hard game to get into. With the interaction menu it's a lot easier now. I wouldn't really want to add more sources of possible frustration in the future but rather remove them.
Clonkonaut did not bring up that point, you did just now.Also, whether or not this is a relic or simply the most straightforward and simple way to realize this is the point of this discussion.
I think Zapper refers especially to the point of "keeping secret gameplay infomation in a wiki".
That's already a relic from the past? Geez and here I was sitting and thinking that that's the coolest, newest, hipest shit. The first game I played with a wiki was Minecraft and that's not 10 years old. :(
There's roughly zero modpacks for minecraft that don't ship NEI, and nobody plays vanilla (because it's boring), so that's not really relevant.
Well I'm not the best person to express his opinion (again), but I interpreted the "relic from the past" to address "just showing one way to build stuff" because that's how it has been since clonk planet, and the entire point being "just because we went with displaying one set of components when we had one set of components doesn't legitimate hiding the others in the wiki when we introduce more" which then is supported by the statement that the very concept of "hiding information" is not exactly what helps a new player to find into the game.
Yeah, okay. I thought this feature would turn out to be an easter egg anyway, so it's not crucial game information. But if it really is intended to be a major feature and used often, then, yeah, we should display it.
![[gb]](/mwf/flags/gb.png "United Kingdom")
For whatever it's worth, getting far in Nethack required research even before Wikis existed... But that has always been a crutch. A good game should explain itself. People's attention spans are so short that they will forget half of it anyway, and be delighted to re-discover it :)
I actually managed to survive up until some levels into the underworld without knowing some crucial stuff like leveling up your weapons or spells, altars and prayer and Elbereth.
Sure, but from my hazy memory ascending is basically impossible unless you know fairly arcane details such as how magic resistance and cancellation work. Say, a gray dragon scale mail is actually not your one stop against magic, because it lacks MC. That kind of stuff always struck me as unecessarily obfuscated.
> That's basically a relic from ten years ago. I don't think that "because we always did it like that" counts as a good argument.
I don't really understand what you mean, sorry. What is the relic? The "Components=" entry or having fixed production material for objects or what?
But as Newton said, I don't think either of that was my real point.
Yeah, I guess I misunderstood your point a bit.But still, I guess if we'd allow that, we should also show that in the UI - because I tend to hate bad interfaces and communication nowadays.
And I also think that forcing a "main" way to produce everything (like it currently is and has been for decades) might hold us back on some possibly interesting (as in "added gameplay value for players") features.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
