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).
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
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]]]
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.
This would make things only more complicated with very little gain. I oppose this.
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.
>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.
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.
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.
>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.
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.
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.
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).
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.
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?
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.
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.
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.
> 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.
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