![[de]](/mwf/flags/de.png "Germany")
As someone pointed out here, the average scenario lacks environmental decoration.I already started working on some plants/animals, but we also need some purely visual stuff!
Be it birds in the background, small frogs, flies, fire flies, gras/flowers, sparkling material, stalactites etc.
Ideally using those in any scenario would be a no-brainer.
Not good:
for(var i = 0; i < 10; ++i) PlaceVegetation(Tree, 0, 0, LandscapeWidth(), LandscapeHeight());good:
CreateEnvironmentalObjects(ENV_Birds | ENV_Cicadas) or CreateEnvironmentalObjects(ENV_All) or CreateEnvironemtalObjects(ENV_Temperate | ENV_Air);This is a task ideal for newcomers or people who already know CR scripting and want to start helping at the OC project, since it mainly consists of very small and easy scripts [but still needs a lot of creativity :)] - and it needs no prior preparation (like understanding libraries etc.)!
Any suggestions/ideas?
What about:
Tree->Place(int cnt) with some optional parameters?
the same can be implemented for animals and other stuff.
Tree->Place(int cnt) with some optional parameters?
the same can be implemented for animals and other stuff.
That is what I am using for the plants etc.But for the purely visual stuff I can not really imagine how the standard case would be that someone would want to specify anything precisely.
For example if the player wants cicada sounds, frogs, and basically everything that is related to moderate climate, he could use
Cicadas->PLace();
Frogs->Place();
Grass->Place();
Flowers->Place();
...
or
CreateEnvironmentalObjects(ENV_Temperate); which would include anything that is related to temperate climate.I would even think that
CreateEnvironmentalObjects(ENV_All); could become the standard case. Especially if there are new features introduced at a later point: every scenario using CreateEnvironmentalObjects(ENV_Cave); would get any visualy features for cave environments that are created later.And I think that is a big plus.
Animals and plants that the player can interact with (trees e.g.) are a different case because that's usually not just "I want those" but "The player should have X trees to produce wood from the start"
But then every scenario has the same amount of objects (or density), and they all look generic?
I agree that one object controlling placement of these objects is useful, but personally I will always use more precise methods.
I agree that one object controlling placement of these objects is useful, but personally I will always use more precise methods.
>But then every scenario has the same amount of objects (or density), and they all look generic?
Well, every scenario currently has one moon too and the same density of stars.
But yes, it could be changed in a way that calling CreateEnvironmentalObjects(ENV_Frogs); twice would place twice the amount or that you could specify the amount by something like CreateEnvironmentalObjects(ENV_Frogs, 200);
But I still think that the ease of use and the flexibility (for later extensions) outweight that here
![[at]](/mwf/flags/at.png "Austria")
>But then every scenario has the same amount of objects (or density), and they all look generic?
I think the landscapes might actually lessen this problem. About every environmental object like trees, plants,... has some constraints where it's placed. Usually defined through the landscape materials or shape. :)
Guess we can simply try it and if it really looks boring -> change it.
You don't. Methods don't know if they're static; the static call is just a regular call with this==0.In fact, sometimes methods were designed such that they can be called either as regular or as static calls. Things like
local foo; func GetFoo() { if (this) return foo; else return DefaultFoo; }(Unless things have changed from CR)
>(Unless things have changed from CR)
They have, "this" would now refer to the definition instead of the object afaik
They have. "Definition Calls" now use the Definition as the "this" value, and local variables can be read normally and return the value of their static initialization. (Writing to them is disabled just like elsewhere.)
I feel reminded of that old, old project of mine I worked on with ck and newton. It was a jungle scenario and we had lots of environmental stuff going on there, bird swarms in the background, small frogs and flies in the swamp, fireflies at night, lots of sounds and region-dependent "gamma" for each player. I think it added greatly to the atmosphere.
Most of the wildlife consisted only of sounds (invisible objects moving around spawning sounds). It is incredible how only that can already create such a great athmosphere.I think the easiest way to make this happen in OC is bind the athmospheric sound effects to (deco) objects in the landscape. F.e. Grass near water can spawn continuous cricket or frog sounds, trees can spawn birds chirping or rustling noises, the grave Ringwaul made would spawn an eerie but very subtile background noise, the generator of wind generators sirr a bit etc. You get the idea.
Same could be done for large masses of material: lava, water, acid, caves,...
This is something anybody who wants to contribute to the OC project could dive into. freesound.org and similar platforms offer huge amounts of free sound effects and ambient noises that can be used and remixed.
Not quite convinced on the animal sounds from vegetation. Scenario designers might want to have more control over the sound - Maybe I want to do a swamp, but a "dead" one, with only a few eerie sounds instead of frogs and crickets. Maybe there's a transition in my landscape where suddenly all sounds in the forest stop, because there is danger ahead. So I would still want to have seperate "sound objects". Of course: For "standard atmosphere" we could still generate them in an almost intelligent way, so that standard scenarios with lots of grass get lots of cricket sounds, and such. But we shouldn't force animal sounds on everyone who uses grass. Different story for buildings, I guess, as those directly produce the sound.
I see where you are getting at, but no. Playing a sound here and there sometimes could be implemented to work asynchronously if we had this possibility but it is not at all necessary.The thing that needs more lead time anyway is the acquisition of all the sound effects (and artwork) of good quality, variation and with the right license. You can see how many athmospheric sound effects/music has been collected so far (none, that is), scripting it and/or converting it to work asynchronously is the minor task of the two.
![[ca]](/mwf/flags/ca.png "Canada")
One thing I thought of that should be fairly easy to make; bubbling lava.Randomly create 'lava bubble' particles at the surface of lava which make a deep 'bloop' sound. How frequently they appear could be ascertained from how many lava pixels exist in the scenario.
PS: Is it possible to create a sound at x,y without a parent object to tie it to? :o
>PS: Is it possible to create a sound at x,y without a parent object to tie it to? :o
That's possible but not from Script (would be easy to expose). It's probably not exposed because it ignores movements of the reference point.
![[gb]](/mwf/flags/gb.png "United Kingdom")
As I said in another thread, I'll now post some thoughts on this.
First, for such a framework, I would clearly prefer sth. like CreateEnvironmentalObjects(ENV_All) over CreateEnvironmentalObjects(ENV_Birds | ENV_Cicadas). This: CreateEnvironemtalObjects(ENV_Temperate | ENV_Air) would, imho, not be a good idea: Let's say, we have ENV_Temperate, ENV_Desert, ENV_Tundra etc and ENV_Air, ENV_Surface, ENV_Underground. If it were like this, one could think: ah, let's do CreateEnvironemtalObjects(ENV_Temperate | ENV_Tundra), what does not make much sense I think. If one would want both, he should call CreateEnvironemtalObjects(ENV_Temperate) and CreateEnvironemtalObjects(ENV_Tundra), which would clearly seperate the climate regions. To make the function more usable, I would give it some more Parameters. Let's think about a
"func CreateEvironmentObjects(int envType, int bitmaskWhichSubregion, int x, int y, int width, int height)" with
envType: Environment type / Climate region. Maybe ENVC_Temperate etc.
bitmaskWhichSubregion: Objects of which subregion should be created? Think of ENVR_Air, ENVR_Surface, ENVR_Cave, ENVR_Liquid...
x, y, width, height: rectangle in which to place the objects. Would give a little bit more control about where to place the objects for advanced use; x, y would default to 0, width to LandsaceWidth(), height to LandscapeHeight()
Then, any env. object would, like it yet has, have a 'Place' function as definition call: The plant/animal does know itself where it likes to live. Wipfs may like "earthy" environments, fish of course prefer to live in water etc. But, to make this function more usable, I would extend the definition to "func Place(int x, int y, int width, int height)". There would be no parameter on density, because the object itself would know if it likes to have many objects around it or not, thus implement the behaviour in it's Place function. Maybe there could even be more parameters added for further advanced use, to allow other developers to override some placement logic, if it's needed.
EDIT: As I see now, there is only the Sprout Berry Bush that implements the 'Place'. However, the sense of my post should be the same.
First, for such a framework, I would clearly prefer sth. like CreateEnvironmentalObjects(ENV_All) over CreateEnvironmentalObjects(ENV_Birds | ENV_Cicadas). This: CreateEnvironemtalObjects(ENV_Temperate | ENV_Air) would, imho, not be a good idea: Let's say, we have ENV_Temperate, ENV_Desert, ENV_Tundra etc and ENV_Air, ENV_Surface, ENV_Underground. If it were like this, one could think: ah, let's do CreateEnvironemtalObjects(ENV_Temperate | ENV_Tundra), what does not make much sense I think. If one would want both, he should call CreateEnvironemtalObjects(ENV_Temperate) and CreateEnvironemtalObjects(ENV_Tundra), which would clearly seperate the climate regions. To make the function more usable, I would give it some more Parameters. Let's think about a
"func CreateEvironmentObjects(int envType, int bitmaskWhichSubregion, int x, int y, int width, int height)" with
envType: Environment type / Climate region. Maybe ENVC_Temperate etc.
bitmaskWhichSubregion: Objects of which subregion should be created? Think of ENVR_Air, ENVR_Surface, ENVR_Cave, ENVR_Liquid...
x, y, width, height: rectangle in which to place the objects. Would give a little bit more control about where to place the objects for advanced use; x, y would default to 0, width to LandsaceWidth(), height to LandscapeHeight()
Then, any env. object would, like it yet has, have a 'Place' function as definition call: The plant/animal does know itself where it likes to live. Wipfs may like "earthy" environments, fish of course prefer to live in water etc. But, to make this function more usable, I would extend the definition to "func Place(int x, int y, int width, int height)". There would be no parameter on density, because the object itself would know if it likes to have many objects around it or not, thus implement the behaviour in it's Place function. Maybe there could even be more parameters added for further advanced use, to allow other developers to override some placement logic, if it's needed.
EDIT: As I see now, there is only the Sprout Berry Bush that implements the 'Place'. However, the sense of my post should be the same.
>which would clearly seperate the climate regions.
Yes, but what if ENV_Cave and ENV_Temperate would both include for example zicada-sounds? Would they be placed twice when you call the function twice?
The idea behind the categories (Cave, Temperate etc) is that certain features can overlap and be in more than one category - and it's easier to take care of that when it's all in one call.
Also to the more special parameters: You are right, more control can be a good thing sometimes - but not always. Just because it makes it harder for a scenario designer to specify what he actually wants.
I believe the CreateEnvObjs() should have as few parameters as possible and call the PLace()-methods of the other objects with some standard parameters (for example: whole map).
If a scenario designer wants better control about that, he should use the Place()-methods directly then. (instead of CreateEnvObjs(Zicadas): Zicadas->Place(0, 0, 200, 200)).
>The plant/animal does know itself where it likes to live. Wipfs may like "earthy" environments, fish of course prefer to live in water etc
You are right. But don't forget that this here is just about aesthetic stuff and landscape effects! I think that Wipfs and animals should always use their PLace()-methods with more fine grained control (f.e. the amount: Wipf->Place(10)) - just because it has an impact on the game!
But another example: "I want the material in my scenario to sparkle" - that would be an example for a CreateEnvObjs-candidate where you do not usually want to say where your material sparkles. You just want the effect in your scenario!
>Yes, but what if ENV_Cave and ENV_Temperate would both include for example zicada-sounds
They wouldn't. You are mixing up the constant to specify the climate region (ENV_Temperate or whatever) and the constant specifying the type of objects you want actually to be created. Imho, there is a huge difference between the two.
(CreateEnvObjs(ENVC_Temperate) would actually either do nothing or let the second parameter default to ENVR_All. Even CreateEnvObjs() could default to CreateEnvObjs(ENVC_Temperate, ENVR_All))
>Also to the more special parameters: You are right, more control can be a good thing sometimes - but not always. Just because it makes it harder for a scenario designer to specify what he actually wants.
>I believe the CreateEnvObjs() should have as few parameters as possible and call the PLace()-methods of the other objects with some standard parameters (for example: whole map).
As I said, the advanced parameters for positioning would default to the whole Landscape. So, it would not increase complexity for beginners.
A beginner would write "CreateEnvObjs(ENVC_Temperate, ENVR_All)". That's it. It would create all objects assossiated with temperate climate regions.
>If a scenario designer wants better control about that, he should use the Place()-methods directly then
If you do that, the scenario designer would have to more or less hardcode the whole environment only because he doesn't want cave sounds in the caves in the upper third of the map for example. So, newly added objects would not be in the scenario automatically, what it would be, if the scen could use the CreateEnvObjs function for advanced positioning (which even could search all definitions for environment objects to have minimal maintainance work to do).
One could even do sth. like 'func CreateEnvObjs(int climateRegion, int bitmaskObjectTypes, proplist advancedOptions)'. Advanced options would, if nil, of course be defaulted.
>But don't forget that this here is just about aesthetic stuff and landscape effects! I think that Wipfs and animals should always use their PLace()-methods with more fine grained control (f.e. the amount: Wipf->Place(10)) - just because it has an impact on the game!
That, however, is some other problem. Maybe some sort of Environment_Manager->Configure? Well, C4Script moves to more object oriented programming, so why not?
However, I would not like to have functionality not added only because it is complex/not easy. You can hide advanced functionalities if needed (default parameters!). I say, if the framework is done, it should be as useful for advanced developers as for beginners. Of course you could use the Place methods directly if you want advanced options. But what if you have, say, 20, 30 env. objects? You would even have to call all those Place methods directly if you only want to specify to have no trees. Imo, you would then specify the advancedOoptions proplist, set all members of it you don't need to nil, specify the advancedOptions.ExcludeIds array as [Tree] and you have the dafault environment without trees. Simple enough imho. Then if you want to place the Trees with some really advanced option, you could simply do Tree->Place(<some really advanced option>).
EDIT:
>"I want the material in my scenario to sparkle" - that would be an example for a CreateEnvObjs-candidate where you do not usually want to say where your material sparkles
Yes, you're right. Thats a problem too. But however, one could say: The parameters x,y, wdt, hgt don't apply for bjects with inherent global effect. (Even if I do not really like this)
>If you do that, the scenario designer would have to more or less hardcode the whole environment only because he doesn't want cave sounds in the caves in the upper third of the map
This is not true - same for the tree-example.
If a scenario designer wants everything except for trees, he can just remove trees specificially after the creation.
Also I don't understand the difference between CreateEnvObjs(ENVC_Temperate, ENVR_Zicadas) and CreateEnvObjs(ENVC_Desert, ENVR_Zicadas)
>Maybe some sort of Environment_Manager->Configure?
The point of this whole thread was to make creation of standard setting easier and not more difficult ;)
The thing I agree with so far is an optional rectangle-parameter
>If a scenario designer wants everything except for trees, he can just remove trees specificially after the creation.
Trees could affect the placement of other objects, what, if a scen developer does not want this? (Imagine bushes that don't grow under trees due to lack of sunlight...)
EDIT:
>CreateEnvObjs(ENVC_Temperate, ENVR_Zicadas) and CreateEnvObjs(ENVC_Desert, ENVR_Zicadas)
eh? You mean CreateEnvObjs(ENVC_Temperate, ENVR_Zicadas) against CreateEnvObjs(ENVC_Temperate | ENVR_Zicadas)? Because ENVC_Temperate | ENVR_Zicadas would assume that both are the same type of data - are climate regions and env object types the same type of data? imho they aren't.
EDIT2:
(Many people say to me that I always want to make things difficult hehe - however, for me, it is just a try to make things fitting together logically, and well, I hate it if things are "easy" and not quite usable)
>eh? You mean CreateEnvObjs(ENVC_Temperate, ENVR_Zicadas) against CreateEnvObjs(ENVC_Temperate | ENVR_Zicadas)?
No, I mean what I said. I could have Zicadas in both temperate and desert scenarios. What's the difference and why can't I just use CreateEnvObj(Env_Zicadas) but have to use Desert or Temperate?
Oops, I missed the ENVC_Desert...sry. I thought it would have been ENVC_Temperate, too.
Well, if you only want Cicadas, you would use Cicadas->Place. Wasn't the thread's topic about providing an easy way to create whole environment settings? Let me try to make more clear what I wanted to say:
To make the whole thing work, each env object (lpossibly there is more control needed about animal placement etc...) would have to specify the climate region in which it likes to grow/live/exist and a Place function. Then it specifies some kind of type. This would, in my first idea, specify some subregion. However, I now do realise myself that this makes no sense - if every env object does exacty know how to be placed, such region specifiers are obsolete and add unneeded complexity.
But it would make sense imo to let this type specify actually a type (erm..). So, what would make sense there?
EOT_Plant
EOT_Living
EOT_Sound
etc.
(as a bitmask of course)
So, you would not use CreateEnvObj here, because it is for creating one or more types of object that are meant to exist in a specified climate region. In your case it would then be a simple call to Cicadas->Place.
Well, if you only want Cicadas, you would use Cicadas->Place. Wasn't the thread's topic about providing an easy way to create whole environment settings? Let me try to make more clear what I wanted to say:
To make the whole thing work, each env object (lpossibly there is more control needed about animal placement etc...) would have to specify the climate region in which it likes to grow/live/exist and a Place function. Then it specifies some kind of type. This would, in my first idea, specify some subregion. However, I now do realise myself that this makes no sense - if every env object does exacty know how to be placed, such region specifiers are obsolete and add unneeded complexity.
But it would make sense imo to let this type specify actually a type (erm..). So, what would make sense there?
EOT_Plant
EOT_Living
EOT_Sound
etc.
(as a bitmask of course)
>What's the difference and why can't I just use CreateEnvObj(Env_Zicadas) but have to use Desert or Temperate
So, you would not use CreateEnvObj here, because it is for creating one or more types of object that are meant to exist in a specified climate region. In your case it would then be a simple call to Cicadas->Place.
In my opinion the interface to the scenario/level designer should be as simple as possible. I wouldn't want to initialize the same environment objects for every scenario anew again. I think I mentioned this at another place too already:Why not attach all the sound effects and athmosphere sounds to objects in the landscape?
Just to give some more examples: Frogs, and/or tiny fish swarms could just spawn in seaweed. Cicadas (or just the sound) and butterflies would spawn in grass and bushes, etc. This inherent placement of sound effects and athmospheric deco would mean 0 work for the level designer while the right visual and audio stuff is where it belongs. No "why am I hearing cave sounds on this tower?"-bugs.
Whether this logic is actually implemented in the various vegetation objects in the landscape or in some global environment manager that just puts sound effects and visuals in the right places is then not so important.
Seaweed currently is purely visual. Who spawns seaweed? Same for grass.The whole idea behind that concept here is that the scenario designer does not need to care in detail about the placement etc.
He would use CreateEnvObjs(ENV_Temperate) and have grass and seaweed and sounds. - or even
ENV_All and the placement functions would place everything applicable (no seaweed without water).
Then all non-automatically placed vegetation wouldn't have the right sound and visual effects.
In my opinion, "0 work for the level designer" is a very, very bad thing, because obviously: Without any work spent on level design, a level is not designed. Also, even worse: Doing so will disencourage specific design of level sounds and visuals. Please see my doubts on this. I'd rather place some "sound-boxes" or "frog spawns" or whatever via hand than to have cicarda sounds in the tundra because I decided to add a few patches of grass in my snow. Also, I might want to have frog sounds in some dark cave with water where there is no grass. If I can't do that, I can't create outstanding settings.
EDIT:
As I mentioned above: There is no reason not to include some smart standard way to initialize sounds from existing environment objects. However, this should be optional.
In case you are also arguing against the creation interface and not just the link-sound-to-stuff :)>In my opinion, "0 work for the level designer" is a very, very bad thing
>I'd rather place some "sound-boxes" or "frog spawns" or whatever via hand than to have cicarda sounds in the tundra because I decided to add a few patches of grass in my snow
Nothing speaks against this - especially for manually designed scenarios.
Completely or mostly "random" scenarios (landscape.txt) are a different story. A standard way to handle those scenarios (especially for developers who are fairly inexperienced) is imo a good thing. I don't want to see the same for-loop with some PlaceVevetation in every scenario again - mainly for the reasons I already explained above.
If you have a manually designed scenario, you will always be able to place certain feautures manually (grass on snow etc).
As I mentioned in my edit: I'm not against any smart functionality that tries to place all the environmental stuff on the map automatically. That feature could be used for dynamic scenarios or as a starting base for editing my own adeventure scenario. I'm only strictly against forcing any kind of behavior by linking different things together, thus removing control from the designer.
This is why I want this framework to have more advanced options. And, possibly, it is really only usable for vegetation because of that you mentioned.
So true, the last we want is these thirteen to a dozen scenarios.
I'm not sure why, but you are being sarcastic, right? If so please read my answer to zapper to clear things up ;)
No then I would have used the sarcasm dot. <-- this actually is sarcasm ;)
I agree with basically anything you state in this thread, honest to god.
I think it's better to have something flexible, clean and consistent, rather than something that is easy to use.
Also if it is easy, you do not challenge people enough to create interesting stuff. For example I think the Sb*Klotz
clones are a result of just activating a lot of object packs (including the one they created themselves (the only
achievement), and putting the scenario sliders to max. Not something I would consider a creative miracle, and
even less fun to play actually, for me at least.
I agree with basically anything you state in this thread, honest to god.
I think it's better to have something flexible, clean and consistent, rather than something that is easy to use.
Also if it is easy, you do not challenge people enough to create interesting stuff. For example I think the Sb*Klotz
clones are a result of just activating a lot of object packs (including the one they created themselves (the only
achievement), and putting the scenario sliders to max. Not something I would consider a creative miracle, and
even less fun to play actually, for me at least.
>and even less fun to play actually.
Not that I ever played it - but that is obviously subjective. There must have been a lot of people who liked to play it :)
Yes, I changed that. Still I think we should consider to inspire people to try to make more creative content.
Nothing against that.But there is a line where that changes from being a good idea to being overly complicated.
Just as an extreme example: We could also decide not to provide any tree models in the Objects.ocg, because it would be a lot cooler if every scenario had its own set of trees and vegetation.
While that is true, it surely does not add to the rate of the creation of fun scenarios :)
That's object design, as opposed to scenario design. So yes there is indeed a very clear line, but you are right, it might even lie further towards scenario design.
>That's object design, as opposed to scenario design
Well, we could provide a Library_Corniferus, if anyone wants to use it ;)
But yeah, that's exaggerated of course. I'd say we try the simple interface like suggested (plus area parameter) and that interface uses standard parameters for the various Place()-methods.
If anyone feels that his creativity is restricted by the simple interface he/she could always use the Place()-methods for a better control.
But I still believe that especially for new coders, having a standard way to do those things is a great relief which - in the end - leads to better scenarios on average
>Why not attach all the sound effects and athmosphere sounds to objects in the landscape?
Would be nice. That would even more encapsulate the playement functionality into the objects that need to be placed.
>Just to give some more examples: Frogs, and/or tiny fish swarms could just spawn in seaweed
They could. But if they ever do, if I were a scen developer, I would hate that kind of seaweed.
>Whether this logic is actually implemented in the various vegetation objects in the landscape or in some global environment manager that just puts sound effects and visuals in the right places is then not so important.
I don't agree with that. Imo, every object should take care of it's placement on its own. This improves flexibility if objects are added or removed. For example, why should there be a structure manager with a big big database of where to place every structure? Would be strange.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
