![[de]](/mwf/flags/de.png "Germany")
While I'm waiting for the the great idea regarding OpenClonk to come in my mind (and spending our after our to get familiar with the current state of development & ideas), I'm reading through various scripts right now to see how everything works. So, to be not completely passive, I would see what I can do to implement such a framework (however this would be quite limited due to the current lack of environment objects. So I'd try to get some ideas or even implementations for some behaviour of animals(or even entire animal implementations - e.g. some Torchbug using particles, as my models would look silly) without gameplay impact), if there is noone who would say "Eleuth., don't do it, your implementation won't fit/would have various design issues/...!"
>if there is noone who would say "Eleuth., don't do it, your implementation won't fit/would have various design issues/...!"
That still depends on what you actually imagine how it should work :)
Is anything speaking against that?
>Is anything speaking against that?
If you mean this interface: "CreateEnvObjs(int region, int type, int x, int y, int wdt, int hgt)", there would be nothing speaking against that from my point of view.
But please not this: "CreateEnvironmentalObjects(ENV_Birds | ENV_Cicadas)". This is equivalent to Bird->Place and Cicadas->Place.
So, this: "CreateEnvObjs(int region, int type, int x, int y, int wdt, int hgt)" or this "CreateEnvObjs(int region, int x, int y, int wdt, int hgt)". But I think the latter one has not enough flexibility, so if you don't want Birds for example, you would, have to write a whole bunch like that:
Tree->Place();
Cicadas->Place();
SomeBush->Place();
SomeAnimal->Place();
etc.
Using "CreateEnvObjs(int region, int type, int x, int y, int wdt, int hgt)", you could specify "EOT_All & ~EOT_Air" as type parameter, create any air objects you might want to have anyway, but don't create the Birds.
As I already mentioned, I would let the object specify which type it is and in which climate it normally would exist. So the Library would not have a database about every object, but would look for any definition that has specified the parameters given. Any env. object would then specify something like this:
func IsEnvObject() { return true; }
func GetClimateRegion() { return ENV_Temperate; }
func Place() { /* do it!*/ }
This here is a fast mockup of how I imagine the "framework" to work:http://wiki.nosebud.de/wiki/Spezial:Pastebin/show/AP6NEUaL I did not test it but it should work.
If you wanted to have something like "I want Temperate but no Zicadas at all!",
you could do something like Environment_Attributes["Zicadas"] = nil, which would disable Zicadas for every call of CreateEnvObjs() in your scenario.
That could of course also be wrapped in a helper functions, if it is needed: DisableEnvObj("Zicadas");
Other than that, I think it provides enough flexibility and ease of use to try it that way.
![[ie]](/mwf/flags/ie.png "Ireland")
> Objs
That a very uncommon abbreviation. Better use "Objects" or similar more common abbrevs when writing a function that's meant for public use.
I used "Objs" in my forum posts here too, just because it's faster to write on a mobile phone keyboard but has the same value for the discussion.I used "Objects" in my implementation. :)
huh, tried some quick implementation of fireflies today.
Just wondering: Do fireflies make sounds?
I heard some play the banjo[they probably make a buzzing noise like a fly? but that would be less atmospheric :( ]
Probably only the very thin buzzing sound every flying bug makes. They use light to attract partners, so no sounds is necessary.
![[ua]](/mwf/flags/ua.png "Ukraine")
They do not. But the sound of crickets will perfectly enrich the (night-time) atmosphere.P.S. Distant wolf howlings would also be very good.
Frogs eat everything small and moving, as far as I could observe it ;)
Finally the Fireflies are finished.
I hereby contribute the following patch to the OpenClonk project under the terms of this file
The patch file: http://www.file-upload.net/download-4427095/4755.patch.html (with --git)
I hope I did it the right way. What it changes:
+ adds Fireflies to Environment.ocd
+ adds the firefly to Animals.ocd
* modifies VisualEnvironment.ocd/Script.c to include fireflies in "Temperate")
+ adds Environment.ocs to Tests.ocf (a little scenario meant for environment object testing
I hereby contribute the following patch to the OpenClonk project under the terms of this file
The patch file: http://www.file-upload.net/download-4427095/4755.patch.html (with --git)
I hope I did it the right way. What it changes:
+ adds Fireflies to Environment.ocd
+ adds the firefly to Animals.ocd
* modifies VisualEnvironment.ocd/Script.c to include fireflies in "Temperate")
+ adds Environment.ocs to Tests.ocf (a little scenario meant for environment object testing
I would suggest to add fireflies to animals. We might want to categorize animals later but fireflies are just animals for now.
And I really do not see a point why everything has to be put in a folder with a rather strange name "VisualEnvironment".
And I really do not see a point why everything has to be put in a folder with a rather strange name "VisualEnvironment".
>I would suggest to add fireflies to animals. We might want to categorize animals later but fireflies are just animals for now.
I'd suggest putting them into VisualEnvironment.ocd.
>And I really do not see a point why everything has to be put in a folder with a rather strange name "VisualEnvironment".
This should point out that everything inside only has visual purposes.
That the whole system is forward and backward compatible is the point of having it.
If someone later comes and finds that fireflies should interact with the landscape in any way (or that you can eat frogs), he would possibly break every scenario that was made before and after the introduction of fireflies and uses CreateEnvObj("Temperate") - just because he relied on the promise from our side, that CreateEnvObj would never do anything except visuals.
>This should point out that everything inside only has visual purposes.
>Zicadas
>Zicada sounds.
But this is somewhat confusing then ;)
That's why I am probably against the whole thing anyway. In the end the scenario designer has to do nothing to make a good looking scenario, but also cannot do anything, cause he is completely confined by our system. It is way too rigorous, completely inconsistent with other environment objects. We should never make people rely on such things. If you feel that is the way to go I would strongly suggest that you develop that completely outside of Objects.ocd, which is easily possible in our repos. Scenario designers can then include the backwards compatible VisualEnvironment.ocd and content designers do not have to worry about breaking things.
In any case: Animals are animals.
In any case: Animals are animals.
>In the end the scenario designer has to do nothing to make a good looking scenario
If that is true, I don't see a problem - then the scenario designer could spend his/her time to actually develop the gameplay of the scenario :)
> but also cannot do anything, cause he is completely confined by our system.
That is false.
If you want to use any of the parts in VisualEnvironment.ocg without going through the CreateEnvObj()-interface, you are free to do so.
Everything inside there has a Place()-method like any other object. You are not more or less restricted than when you are creating trees or gold.
>completely inconsistent with other environment objects
Which ones?
Meteors, yes. They have a huge impact on the game and the scenario designer should not be strapped off the decision whether to include them or not.
Stars and Clouds? Maybe - I should probably include them into the VisualEnvironment framework and do the adjustments.
Why? Because if you want to use them seperately, you can still do that like you did before (CreateObject(Cloud)..). Currently they are only visual and I guess we have them activated in every scenario, that features night(?)
Another point of the framework is to actually make the interface consistent.
If I asked you how to add clouds into my scenario - would you know it? I wouldn't. Do I have to create them or create one or call a certain function after creation?
Adding a Place() function there protects you from having to copy&paste everything from another scenario when you create a new one. And if you are unsure how many clouds a scenario usually has, you could still do CreateEnvObj("Clouds") - because someone else has already thought about that before. If you are unhappy with the results, you can adjust that manually, after the first try.
Let us then hope that you will manage to keep it consistent, I have my doubts.
Well, I'd still say that having a Place(amount, area, ..) function for all environment objects is a good idea.My ominous "framework" just calls Place().
The only thing to keep consistent is that objects placed there should not influence gameplay - but if they change and do so, they can be removed from the placed objects without breaking anything!
You want that the player can catch fire flies in a jar? Cool! Move them to animals, remove them from VisualEnvironment and nothing breaks
I see, and will see, I guess.
The name visual environment is horrible btw, almost all environment objects are visible, so it does differentiate as you suggest.
The name visual environment is horrible btw, almost all environment objects are visible, so it does differentiate as you suggest.
>The name visual environment is horrible btw, almost all environment objects are visible, so it does differentiate as you suggest.
I admit that the name is not good.
I guess I will change that into boni's suggestion "Atmospheric(al)"(?)
![[at]](/mwf/flags/at.png "Austria")
By the way, what about passive interaction? Like dieing when blown up or drowned?I'm not asking because I'd like to shatter your non-interaction concept because I agree with that, just to ask if that stuff is covered by the current implementation.
I am fine with everything as long as it does not influence the player/landscape - anything that makes the game more lively is great!That means, they can die or burst when blown up - frogs can even chase fireflies etc, grass can grow higher when it rains and turn yellow when there is no water around. But for example, they should not explode(10) when they die and frogs should not catch your arrows etc.
That reminds me, we totally need something like dandelions (http://www.janko.at/Fotos/Flora/Loewenzahn.jpg). When a clonk walks over them, they lose their seeds in a windy effect!
>>I would suggest to add fireflies to animals. We might want to categorize animals later but fireflies are just animals for now.
>I'd suggest putting them into VisualEnvironment.ocd.
> that post with it's not only visual
EnvironmentalEffects.ocd or Environment.ocd/Effects.ocd (there would also be Environment/Animals for example, then).
Alternatively, how about Atmospheric.ocd?
>EnvironmentalEffects.ocd or Environment.ocd/Effects.ocd (there would also be Environment/Animals for example, then).
"Effects" is not clear enough in the context of Clonk, imo.
Atmospheric.ocg instead of VisualEnvironment.ocg would be fine with me - feel free to rename it :)
![[fr]](/mwf/flags/fr.png "France")
Also, don't forget the license.
I hope this is the right topic to post stuff about things in Effects.ocdThere's an object Cloud.ocd in Effects.ocd, id is CloudEffect. These are purely visible floating particles. As far as I can see, no existing scenario uses these.
And there is a cloud in Environment.ocd, id is Cloud. These produce rain and move and so on. And they are used by the scenarios.
Any reasons to keep CloudEffect?
Mh.Would it be a good idea to maybe separate the Cloud from the rain (aka "make rain optional for the clouds")? I can imagine that there could be scenarios that want to have nice clouds but no rain etc.
The rain is separated. You have to call SetPrecipitation() if you want it.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
