Concept 1:1 - Weather Effect System (Effect Management)

[DimensionWarped]

This seems like a good starting point to rain theming to me. Lot's of us have played with creating weather in our projects, and many of us have run into some problems while doing it. For this concept, we are going to discuss the implementation of precipitation effects. We'll discuss methods and problems associated with those methods as well as how to resolve them.

To start the discussion, I'm going to introduce a couple deliberately bad ways to control preciptation:

Emit precipitation from the top of the playing field randomly all over the playing field.

Problem - Too much precipitation has to be made to create a reasonable effect.

Emit precipitation above the frame focus (camera)

Problem - As you move away from the focus, the rain becomes visibly sparse. You don't want the player to think the rain is only falling because he is there.

Create scrolling parallax fields for rain

This is actually a pretty efficient way to make the effect, and it's not too hard to implement. But it does incur a cost

Problem - It's limited. The precipitation objects are bound to each-other and are incapable of acting on their own when they do something like hit the ground. In other words, it will only be raining in the background while the foreground basically remains dry.

Come up with methods for controlling precipitation (and other weather systems) for maximum efficiency and authenticity. I'll be positing a method of weather control later on.

[Rawr]

I'm not good with the programming mumbo jumbo, but wouldn't the parallax field's problem be fixed say...if you had a foreground object that would follow the player that had the rain effect going down in front of him? It would follow you within certain boundaries, so if you set up say some sort of sensors or whatever you use to determine how far an object goes, that would send it to a layer behind your backdrop object so it moves behind it...and then once you exit the indoors area it would move to the front again? I can already visualize some problems with that method but it would kind of help alleviate the foreground looking unnafected.

Thats just my kick at the can because I have no clue how to program whatsoever so I don't know what a good method of doing it would be.

[DimensionWarped]

Having a front and a rear parallax rain layer would definitely improve the effect, but it still wouldn't allow for dynamic rainfall that could produce drips upon hitting surfaces. Your front rain layer would also have the added nuisance of showing up in covered areas (indoors, in a cave, etc).

One way you could retain the benefit of parallax though is to use it as an obfuscater to the problem presented by the second proposed precipitation method. Players would lose track of the foreground rain in the background layer and so they'd be less apt to notice the lack of foreground rain in a forward section.

[shadowgoten]

How about a combination of the paralax method along with a lesser amount of those dynamic drops coming from the top at random spots? You'd need a lot less resources to pull that off than attempting that method by itself, and you've got the ability to have some dynamic raindrops around the player without having to bombard the engine with a ton of them.

I'm not sure how resource intensive this would actually be, but it seems like a best of both worlds kind of answer. Though it does seem like there could be something better.

[hRook]

It would probably be more efficient if you treated the rain more like a particle effect. I'm assuming this implementation would be for a 2D platformer game, this being SFGHQ and all. Here's what I suggest:

• Maintain a version of each collision mask that is calculated in relation to the screen, not the level. Ideally, this would be true for all objects and the background. Optimize by only calculating these derived masks for objects that are onscreen. Also, they really only need to be rectangular masks in most cases.
  
• Draw/emit the raindrops at the top of the screen (sY = 0). Calculate their physics separate from the main game objects. The physics for the drops would be in relation to the screen, not in relation to the game. This way, the drops only have to be accounted for from sY = 0 to sY = sHeight.
  
• Now, you can use the derived screen-relative collision masks to create a single aggregated mask that the rain responds to. Poll objects to see what's onscreen (Maybe even maintain a vector or list that contains references to all onscreen objects at all times), then combine all those collision masks into a single polygon to create the new mask.
  
• Now you effectively have a separate physics environment running in relation to the screen, and a collision mask positioned relative to the screen. At this point, you can tell your rain particles to disappear, splash or whatever once they collide with the mask.
  
• If you want the rain to appear more linked with what's going on in the game physics, you can have the rain change its velocity as an inverse function of the player's. If the player is running to the right, drift the rain to the left a little. If the player is falling down quickly, have the rain fall slower.
  

How bout them apples?

[Ironrind]

I'm working on a weather system as we speak. I haven't gotten to rain, but I'm thinking of doing it like this:

Using a weather control object, I create various alarms. Depending on how hard the rainfall is, the alarm will trigger a rain drop nearby and above the player. To give the effect of actual rain, I would use at least three different rain drop sprites. The closer to the foreground, the larger the sprite and the faster it falls. The biggest being half the size of Sonic or so. The further rain sprites could be possibly be done in clusters. While all overlapped, it could create the illusion.

Just an idea; If exaggerated, the water could be super-sized(Think "Honey, I Shrunk the Kids") making one rare drop quake when hitting the ground, stun the player, ect.

The alarm times, could be tweaked to go from light rain to down pour based on time or progression through the level. For e.g: Little or no rain at first, but based on the Player's x coordinate, the rain will increase. That way, a drizzle stage could provide a stormy boss fight or a flood.

As for drips hitting the ground, you could fake it by animating flowers to 'cry' out drips. Water to look unstable and spray a bit. Have Sonic throw water behind his feet while running.

[DimensionWarped]

It would probably be more efficient if you treated the rain more like a particle effect. I'm assuming this implementation would be for a 2D platformer game, this being SFGHQ and all. Here's what I suggest:

• Maintain a version of each collision mask that is calculated in relation to the screen, not the level. Ideally, this would be true for all objects and the background. Optimize by only calculating these derived masks for objects that are onscreen. Also, they really only need to be rectangular masks in most cases.
  
• Draw/emit the raindrops at the top of the screen (sY = 0). Calculate their physics separate from the main game objects. The physics for the drops would be in relation to the screen, not in relation to the game. This way, the drops only have to be accounted for from sY = 0 to sY = sHeight.
  
• Now, you can use the derived screen-relative collision masks to create a single aggregated mask that the rain responds to. Poll objects to see what's onscreen (Maybe even maintain a vector or list that contains references to all onscreen objects at all times), then combine all those collision masks into a single polygon to create the new mask.
  
• Now you effectively have a separate physics environment running in relation to the screen, and a collision mask positioned relative to the screen. At this point, you can tell your rain particles to disappear, splash or whatever once they collide with the mask.
  
• If you want the rain to appear more linked with what's going on in the game physics, you can have the rain change its velocity as an inverse function of the player's. If the player is running to the right, drift the rain to the left a little. If the player is falling down quickly, have the rain fall slower.
  

How bout them apples?

This seems like it would be a pretty damn good start, especially thinking from the angle of efficiency. And it helped to inspire this little idea...

• At the beginning of the level (or simply stored in the level's data), we are going to generate a level-wide height map which accounts for all tangible tiles. It'll be subdivided into some number of groups of around 64 or 128 pixel sections. points will always go to the highest possible collision spot in the frame. Droplets will monitor the height map to know when to be active as well as when to do their collision events and when to manually check for collisions.
  
• In order to make droplets not simply dissolve when they hit open air below an overhang, x-movement of rain drops would be stored separate to the x-position used for calculation against the height-map.
  
• As rain exits the visible area, it gets recycled by wrapping it around. If then it is below the height map, it doesn't get rendered or processed (but once it wraps around again, it might.
  
• Any time a change in slope is detected for a subdivision, rain drops will start manually checking for collisions when they fall get below the highest position in that subdivision of the height map.
  

As an added bonus, the proposed enemy from concept 1:2 could then query this height-map for data on when to fill up instead of needing to check for collisions.