1. First up is a Rain Effect. This actually required very new little new engine infrastructure to create. I had to implement Texture Offset to actually animate the rain. Instead of using particles for the individual falling drops, it's just a big rain texture repeated over and over and shifted every frame to create the illusion of falling rain. The video at the end of this post shows the evolution of the rain effect.
It's rainy
2. The return of the Fade Transition. You might remember from previous videos that this had existed at one point, but I lost it in the infrastructure conversion (Lua --> C#). You can see the fade transition in the video about halfway through, when I enter the temple.
3. A Blob Enemy. I don't have a name for this thing yet, so let's just call it Blob. Look at it. Look at that thing chomp.
Okay, so the source material is pretty cool. But this enemy represents a key development milestone: this is a real enemy with real behaviors.
Generally my engine development pattern is to attempt to make realistic game scenarios and use them to discover what the engine still needs to make them work. There's a popular saying in game development circles: make games, not engines. This doesn't really mean that you shouldn't make an engine, but it does mean that you shouldn't make an engine in a vacuum--that is, an engine without test cases to drive it will probably end up being useless when it comes to practical application.
So, anyway, back to the blob. The blob has a more complex state machine than the previous demo enemies (spike, ghost) I've created. This led to some issues where state management was difficult when states were interrupted and various animations hadn't completed yet. For example, when you get near a blob, it compresses before jumping at you. If you hit it during this animation, it gets sent into another state (knockback) before the animation completes. These effects are achieved with entity controllers, as shown in a previous blog post. After the compression effect of the blob, it has a command that sends it into an 'jumping' state. We don't want this to run anymore if the blob was interrupted by an attack (and sent into the knockback state). To solve this, I introduced state-local controllers. That is, they are controllers that are discarded if the state changes, since they're 'owned' by the current state. This makes for a much cleaner programming model.
This is sort of hard to explain without code examples, so look for a post later in the week which shows the blob source code with an explanation of how it works.
4. Hue Shift
In the video, you'll see the blob flash colors when it's hit. This is actually done with a pixel shader that shifts the hue of the entity, rather than attempted to just change the color of the vertices (which doesn't work--a green image with red vertices appears black).
Hue shifting the blob
Anyway, here's the video. Enjoy! Recommended HD/fullscreen/annotations on.
No comments:
Post a Comment