View Full Version : Event rain

20-03-2007, 05:10 PM
The idea: to create an ambience, you cast an event rain around the player (2d or 3d - depends on your implementation of game world).

When a drop of the "event rain" event hits something, it creates a short-lived decorative object. For example, on the lava it will be a bubble or gurgling sound, on the grass it would be a cicade chirip or a butterfly flying away, on a tree it would be a leaves rustling or a bird warble... And so on.

The thing is, you have one, centralized and easily controlled, source of all your ambient events. You can easily control the resource consumption, since all the events happen only around the player, and you are the one who controls this zone's radius! 8)

Plus, this could create a great, non-repetitive, dynamic ambience without the need to create a huge, complex "athmospheric" MP3s. :D

What do you think about this idea of mine? :)

20-03-2007, 10:36 PM
The idea itself is pretty good. And it might even be fun to make. You'll be needing a database with sounds, that much is sure. I wonder though, is your output one mp3 with all kinds of sounds mixed together, or are you offering a complete environment with variable inputs, so I can add that to my engine?

21-03-2007, 04:28 AM
I wonder though, is your output one mp3 with all kinds of sounds mixed together,
Why premix? Any decent engine could mix sounds (and you need something to fill up that 32-sound limit of OpenAL, right?). The idea was that the ambience is generated on the fly, from a bunch of short sound and visual effects scattered around randomly.

or are you offering a complete environment with variable inputs, so I can add that to my engine?
It's just a general idea, to implement by yourself (it's more effective that way).

And no, I didn't mean "sounds only". The "decorative object" is more general thing, including such things as particle fountains (could be seen over lava in Quake2), smoke puffs (for dirt/desert), etc. I think, implementing a library of these should be very simple -- much simpler than trying to put these details into your levels manually, on a fixed basis.

Also, the sound library, IMO, is better stored as a set of WAVs, not MP3s -- because the sounds would be short (generally), and there would be a whole lot of them.

21-03-2007, 09:29 AM
sounds almost like a particle engine...

22-03-2007, 03:58 AM
It sounds like:
AudioEngine.GetSoundByIndex(Random(TotalSounds)).P lay;

Did you already patended it? :wink:

22-03-2007, 08:00 AM
I don't understand the "idea"...

What is so special in this?

22-03-2007, 10:56 AM
The more I think of this the more I like it as a game design tool to control where ambient events occur and the resources you choose to allocate to ambient events.

The area around the player could of course just be defined as the current visible screen instead of a radius.

22-03-2007, 12:57 PM
I'm sort of on the same side of this concept as Dirk...

Can you perhaps draw us a picture? :)

22-03-2007, 01:41 PM
The idea is (as I understand it) to try and remove the need for say lengthy atmospheric soundtracks and other such stuff, by having the system piece together the effect from small inconsequential elements.

As NecroDome points out, it is kind of like a particle engine, but more.

Lets say you want rain... you have this engine and you tell it to spawn rain particles... when that particle hits an object, it becomes something else... lets say it hits water... the particle becomes a ripple type effect and a sound. When it hits grass, it becomes something else (maybe as Chebmaster suggested, a butterfly that flys up out of the grass and off) and a different sound.

So instead of recording an atmospheric sound track that probably loops your program makes one on the fly based on these particles... where they are, what they hit and the events linked to them when that happens. Since this is likely to be random, the effect would be a continuously changing ambience.

Basically, an ambience engine... a particle engine on steroids with the ability to add atmosphere as well as particle effects.

Thats my take on it and I quite like the sound of it.

22-03-2007, 02:50 PM
well, the cars in grand theft auto where particles. It was just a particle engine... a particle isn't a billboard, its a bunch of thing that do something the same, like rain is falling down and cars are driving. However it's a more advanced particle engine.

22-03-2007, 03:28 PM
Hmm... well it's interesting.

Though I think that you'd have to push OpenAL to it's max to make it work properly...

Heavy rain might be hard to do...

Though... just had a :!: moment...

What if instead of relying on OpenAL to do all the mixing, you had another layer which separated these 'sound emitters' into slices of pie around the listener...

Lets say, oh 32 slices. :) (or less if you want to have music playing as well.) You'd then only have to software mix those sounds together that fit into a single slice of pie segment. Pump those into OpenAL and let the API and hardware take over...

Trouble now would be creating a demo. :P

22-03-2007, 03:44 PM
Isn't that for much particles usable ? Play up instantly lot of sounds wasn't nice for ears. E.g. Rain = 1000 drops in game scene = 100 sounds of flating drops on land + 900 sounds of drops flying in the air. But certainly would went do any sensible rate.

perhaps would it go do more simply:

we have 3 rain loops according to intensity * material type

if rain then begin
if water in player_area then playsound(drops2water[rain_intensity]);
if glass in player_area then playsound(drops2glass[rain_intensity]);


for bubbles in lava it is ok :)

22-03-2007, 05:46 PM
The idea os not to make rain but as a way of controlling ambient events in a game.

So instead of coding something that does a random event somewhere on a map where the player might not see it, the rain event makes it happen close to the player. This allows the contol of how many ambient events and their effect on the game environment without impacting the world as heavily.

22-03-2007, 05:58 PM
When a drop of the "event rain" event hits something, it creates a short-lived decorative object. For example, on the lava it will be a bubble or gurgling sound, on the grass it would be a cicade chirip or a butterfly flying away, on a tree it would be a leaves rustling or a bird warble... And so on.

The "Rain" is not visible - its just a trigger for an ambient effect.

Think of Tetris, every 1 second randomly choose a block and make it sparkle - pretty easy as all the blocks are visible to the player, but it adds a certain level of polish to the game.

On an RTS map, it doesn't make sense to randomly choose a tile throughout the map, rather create an event rain that falls around the player character, when it touches the ground create an ambient event. For example Define the falling speed of the event as 1m/frame, and events start at 10m above the ground. (So every 10 frames you'll get an ambient event happening somewhere close to the player). But if the player moves, each event rain particle gets lifted 0.5m/freme into the air so that the events will only happen when the player is still - resulting in no events when the player is moving as he wont see them anyway.

So by creating event rain for ambient effects the players experience is improved but the performance of the game is not imacted as much as it would be by just creating random ambient events accross the screen.

Out of Interest I have read that some RTS games use a similar system for units not on the screen. Instead of updating their movement/AI every frame as they do with units on the screen they only get updated every 1second or so - resulting in lower performance impact while still letting the player's experience be consistent.

22-03-2007, 08:15 PM
I have smaller problem with translation, be likely lose point :roll:

How it difference from standard work with objects ? Simply activate or create objects (events) if is player in some zone/screen or when is to reason (e.g. at with explosion creates flying shreds of ground). There's no point in draw it outside of screen, anyway we dont draw tiles on map which are out of the screen.

For times/timer, e.g. because power of physical engine i cann't always calculate kinematics but update it every 1/80 seconds. As well would determined priority draw of particle effect (rian, bubbles, sparkle..) and their movement, something like: draw_rain(100); update_(100); - in (..) is time of udpate in ms.

Or is here something more what i miss ? :)

22-03-2007, 09:25 PM
Or is here something more what i miss ?
This is the matter of from which end you approach the problem

A.) You may make each of your world's element responsible for generating ambient events. *Even* if only the potentially visible objects can generate the ambient events, you don't have much control in this scenario, because your event generators form a decentralised system. To fine-tune your ambience you need to tune each of the objects that generate the ambient events. Maybe even edit your maps.
*And* it's very hard to balance the processor load.

B.) The EventRain (tm:lol:) "particle engine" that controls the density and other parameters of ambient events from *one* source.
It's may not be as important for a 2d with limited screen area, but for 3d it's critical.

For example, you can add the ambience zone radius slider to the render quality controls.

As I see it (theoretically) there souldn't be more than a half-dozen ambient events running at the same time (more likely 2..3), and the events must be pretty short.

A good example (not of this approach but of event-generated ambience) is a situation where the passive monsters on the arena occasionally emit a short sound (grunt/screech/breath). Such a simple mechanism but allows to feel what is around :)