Event rain

[WILL]

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.

[JC_]

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

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

..

for bubbles in lava it is ok

[cairnswm]

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.

[cairnswm]

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.

[JC_]

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 ?

[Chebmaster]

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