Skip to main content

Criterium: Particle Systems and Advanced Effects

Today, I was thinking about the "advanced" effects that would most benefit the realism of the game:
  • Motion blur, to give the illusion of speed.  Ogre compositors are most likely the best solution.
  • Dust particles, which would be thrown up occasionally when the bikes cross sandy portions of road.  Dust, IMO, is one of the easiest particle systems to implement well.  My Asteroids demo has some dust particle systems and textures.
  • Rain, which is also easy to implement, given Ogre's built-in particle scripts.
  • Bloom effect, one of my favorite effects, and definitely necessary for a setting sun.  I plan to use bloom to boost glare from specular highlights on the bike frame.  I used this affect in the Asteroids demo as well, and it looks quite good for highly reflective surfaces.  This can be easily done using HDR + high pass filter + Gaussian blur, and Ogre might have a compositor plugin for it.
  • Shadows, which are completely trivial with Ogre.  Awesome!

Comments

Popular posts from this blog

Sparse Voxel Octrees

Terrain implementation for games is a subject with a lot of depth. At the surface, it's very easy to get rudimentary terrain working via a noise function and fixed triangle grid. As you add more features, though, the complexity builds quickly. Overhangs, caves Multiple materials Destructive terrain Collision detection Persistence Dynamic loading Regions, biomes Very large scale Smooth features Sharp features Dynamic level of detail Extremely long view distances In isolation, each of these features can make terrain difficult to implement. Taken together, it takes a lot of care and attention to make it all work. Minecraft is probably the canonical example for terrain generation in the last generation of games. In fact, I'd say Minecraft's terrain is the killer feature that makes the game so great. Minecraft does an excellent job at 1-8, but for a recent planetary renderer project I was working on, I really wanted 9-12 too. In a series of articles, I'm planning to break do...

Lua-Style Coroutines in C++

Lua's implementation of coroutines is one of my all-time favorite features of the language. This (short) paper explains the whole reasoning behind the Lua's coroutine implementation and also a little about the history of coroutines. Sadly, coroutines are not supported out-of-the box by many modern languages, C++ included. Which brings me to the subject of this post: Lua-style coroutines in C++! For those who don't know (or were too lazy to read the paper!), Lua's coroutines support three basic operations: Create: Create a new coroutine object Resume: Run a coroutine until it yields or returns Yield: Suspend execution and return to the caller To implement these three operations, I'll use a great header file: ucontext.h. #include <vector> #include <ucontext.h> class Coroutine { public: typedef void (*Function)(void); Coroutine(Function function); void resume(); static void yield(); private: ucontext_t context_; std...

Entity / Component Systems

I've been writing a new game recently -- and this time, I decided to use an entity/component system . Boy, does that approach make things easier! In other games I've written, I've struggled to fit new gameplay features into the existing code base. With a entity-component based systems, it's easy to add new features: Need a way to track targetable objects in your game? Add a Targetable component that advertises the unit's position, name for display in the HUD, etc. Need to add some new AI behavior to a unit? Add a component! Update all the AI components once per frame and you're on your way. Does your game need networking? What should you do...? Add a component containing all the info for network serialization! Need to control a unit from user input? Add a joystick component that updates the unit's position component in response to user input. Basically, any new feature can be folded into a component. The best thing about components is that they are dy...