Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / The Aesthetic Game World task force
1 2 3 Previous Next
Parent - - By Eleutherotes [de] Date 2012-06-04 23:17
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/...!"
Reply
Parent - - By Zapper [de] Date 2012-06-05 09:02

>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?
Parent - - By Eleutherotes [de] Date 2012-06-05 11:19

>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!*/ }
Reply
Parent - By Zapper [de] Date 2012-06-05 11:26 Edited 2012-06-05 11:30
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.
Parent - - By Clonkonaut [ie] Date 2012-06-05 13:30

> Objs


That a very uncommon abbreviation. Better use  "Objects" or similar more common abbrevs when writing a function that's meant for public use.
Reply
Parent - - By Zapper [de] Date 2012-06-05 13:53
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. :)
Parent - By Clonkonaut [ie] Date 2012-06-05 13:58
Okay. Wasn't sure if that's really crystal-clear.
Reply
Parent - - By Eleutherotes [de] Date 2012-06-07 16:04
huh, tried some quick implementation of fireflies today.

Reply
Parent - By Zapper [de] Date 2012-06-07 16:17
Cool!
Parent - - By Newton [de] Date 2012-06-07 17:08
Just wondering: Do fireflies make sounds?
Parent - By Zapper [de] Date 2012-06-07 17:25
I heard some play the banjo

[they probably make a buzzing noise like a fly? but that would be less atmospheric :(  ]
Parent - By Clonkonaut [ie] Date 2012-06-07 17:27
Probably only the very thin buzzing sound every flying bug makes. They use light to attract partners, so no sounds is necessary.
Reply
Parent - - By AlteredARMOR [ua] Date 2012-06-07 17:59
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.
Reply
Parent - - By Eleutherotes [de] Date 2012-06-07 18:02
Do frogs eat fireflies?
Reply
Parent - By Matthias [de] Date 2012-06-08 01:28
Frogs eat everything small and moving, as far as I could observe it ;)
Reply
Parent - - By Eleutherotes [de] Date 2012-06-08 00:19 Edited 2012-06-08 13:53
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
Reply
Parent - - By Maikel Date 2012-06-08 07:56
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".
Parent - - By Zapper [de] Date 2012-06-08 15:44

>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.
Parent - - By Eleutherotes [de] Date 2012-06-08 15:49

>This should point out that everything inside only has visual purposes.


>Zicadas
>Zicada sounds.


But this is somewhat confusing then ;)
Reply
Parent - By Zapper [de] Date 2012-06-08 15:58
True, but I couldn't think of a better name to stress that the objects should have only aesthethic impact on the game
Parent - - By Maikel Date 2012-06-08 15:50
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.
Parent - - By Zapper [de] Date 2012-06-08 15:56 Edited 2012-06-08 16:01

>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.
Parent - - By Clonkonaut [ie] Date 2012-06-08 16:00
Clouds rain, so they're not entirely visual.
Reply
Parent - By Zapper [de] Date 2012-06-08 16:02
Oh, sorry - wasn't aware of that.
Then they belong into the meteor-category.
Parent - - By Maikel Date 2012-06-08 17:20
Let us then hope that you will manage to keep it consistent, I have my doubts.
Parent - - By Zapper [de] Date 2012-06-08 17:27
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
Parent - - By Maikel Date 2012-06-08 17:32
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.
Parent - - By Zapper [de] Date 2012-06-08 17:36

>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)"(?)
Parent - - By Maikel Date 2012-06-08 17:39
Better, or just Atmosphere?
Parent - - By boni [at] Date 2012-06-08 20:08
Parent - By Maikel Date 2012-06-08 21:15
Thank you for eluding that, point being?
Parent - By Clonkonaut [ie] Date 2012-06-08 17:29
And the next day Maikel broke the consistency...
Reply
Parent - - By Clonkonaut [ie] Date 2012-06-08 16:05
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.
Reply
Parent - - By Zapper [de] Date 2012-06-08 16:12
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.
Parent - - By boni [at] Date 2012-06-08 16:46
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!
Parent - - By Caesar [de] Date 2012-06-08 16:47
I want them huuuuge!
Parent - By Newton [de] Date 2012-06-09 18:07
:-O me too!
Parent - - By boni [at] Date 2012-06-08 16:45

>>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?
Parent - - By Zapper [de] Date 2012-06-08 16:48

>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 :)
Parent - By boni [at] Date 2012-06-08 16:49
Personally I like "Atmospheric(al)" better too, now that I came up with it. ;)
Kinda describes is better.
Parent - - By Matthias [de] Date 2012-06-08 21:33
To add to the disaccord I suggest "Ambience.ocg" :P
Reply
Parent - By Zapper [de] Date 2012-06-09 00:06
As another word for "environment"? :)
Parent - By Newton [de] Date 2012-06-09 18:09
+1
Parent - By Zapper [de] Date 2012-07-02 20:34
done!
Parent - By Caesar [de] Date 2012-06-08 11:39
Patches can contain binary, try --git.
Parent - By B_E [fr] Date 2012-06-08 12:15
Also, don't forget the license.
Parent - By Eleutherotes [de] Date 2012-06-08 13:54
Edited the above post.
Reply
- - By Clonkonaut [ie] Date 2012-06-08 23:35
I hope this is the right topic to post stuff about things in Effects.ocd

There'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?
Reply
Parent - - By Zapper [de] Date 2012-06-09 00:07
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.
Parent - - By Clonkonaut [ie] Date 2012-06-09 00:22
The rain is separated. You have to call SetPrecipitation() if you want it.
Reply
Up Topic Development / Scenario & Object Development / The Aesthetic Game World task force
1 2 3 Previous Next

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill