Lurker!

It's been a couple weeks since my last substantial blog post, so I'd like to share what I've been working on during the last week: a new monster I've tentatively dubbed the Lurker, but I plan on giving it a more original name in the future. Note that enemy development isn't normally going to take a week per enemy--I was busy with some personal things. On top of that, this enemy is more complex than my first enemy, the Blob, and required a few engine infrastructure changes to implement. I'll go over those in detail, too!

I wanted to add a new enemy which will appear in the first area of the game, Gloomstone Cave. The idea is that you'll be facing this enemy in a few spots, but initially you won't have a permanent weapon to defeat it with. So, you must come up with more creative ways to pass the first few of them, whether it be total avoidance or using an alternate means of damaging them. Later on, when you have a weapon, they won't be quite as menacing, but the initial encounters should definitely impart fear into the player.

The Lurker waits underground in a certain spot and emerges if the player gets too close, bursting out of a hole in the ground, blowing debris everywhere. Here is my temp MSPaint art that I used as a placeholder for the enemy sprites so I could start working on the programming immediately:

This is why I'm working with an artist. Body/front/side/back views.

I took a series of videos as I developed the Lurker, so you can see how it's evolved. At the end, I'll share the source code so you can see what the latest programming model against my engine looks like!

Part 1: The Lurker Emerges
This video shows the lurker enemy popping out and swaying in a sinusoidal motion. It doesn't do anything interactive yet.

Part 2: Moving around, basic attack

The lurker moves around to avoid the player, and randomly attacks him if he gets close. Then it gets stuck in the ground, and that's it.

Part 3: Real art, attacking, taking damage

At this point, Allison, the artist, started working on the graphics. The initial design was a cool and creepy monster with a sideways mouth, with plans to animate it chomping the player. You can see the down-facing graphic in this video. Also, I made it so you can hit the head with weapons, and a very basic 'death' animation for the enemy.

Part 4: Better art, cool hit colors, refined movement. Better death animation.

I make various (subtle) changes to the movement behavior of the enemy. Allisonchanged the head design of the monster to a more traditional shape, drew the other angles of the head, and animated the arms on the body segments. So now it's like a creepy dragon caterpillar. I added a more satisfying death explosion animation.

Part 5: Bigger, badder, more explosive
We increased the size of monster. A way better death animation with a bunch of explosions for the head, and a prettier hue shift during hits.

Part 6: Snapping animations, cave shards. Job's done!

I put the monster in its natural habitat, the cave. Allison added animation frames for the head so I can control its mouth--when it pulls back, it opens its mouth, and clamps shut as it attacks. Also, it opens its mouth in pain when I hit it. Allison also made better looking shards that explode out of the ground when the lurker emerges, and I added a rumbling sound (and a temporary hit sound) for the emerging stage.  Check out the final product!

Source Code

Disclaimer: I don't typically comment code except for explanations of 'why' (not 'how'--see this article) but I've marked this example up extensively for clarity. I also don't typically have classes that are anywhere near this large; my average class size is quite small, generally following the Single Responsibility Principle. I would probably consider breaking each enemy state into its own class. But, for the purposes of this example, I'm keeping this all in one class (for now).

Anyway, the full source code can be found on this pastebin, right here.

That's all for now. Next I'm going to be fleshing out a bit more of the first cave area.

A Few Quick Development Videos

I don't really have time to write a blog post, but here are a few development videos!

Major Area introduction:

Experimental enemy 'Lurker' dev video part 1:

And part 2:

Frame Interpolation

Doing things a bit out of order this week: a video first! Keep in mind, this is a tech video about framerates:

The first part of the video shows the game running at a rate of 20 physical frames per second. That is, the game updates its world model 20 times per second. Although the real rate will probably be 60 updates per second (as is common), the very small limit of 20 serves to illustrate the new feature better.

In this first part of the video, the game loop is running rather naively. Although the game only pushing out 20 physical frames per second, it's actually rendering hundreds of frames per second (on my 5 year old desktop, it's something like 750-850 FPS for the demo scene). But the game is still choppy, because it's still only updating the world model 20 times per second! With 750 rendered frames per second, it's actually rendering the same frame over and over about 37 times before the next physical update. What a waste!

The second part of the video is much smoother. You might think that I pumped up the physical frames per second to a much more reasonable number, like 60 or 200 (or maybe not--I think YouTube caps the framerate at something fairly low). But I didn't--the game is actually still running at 20 frames a second. Except now, I've introduced frame interpolation.

Frame interpolation is exactly what it sounds like--in between any two frames (namely, the last update and the update before that one), I am able to calculate an interpolated position. For example, let's say a monster was at position (30, 40) at frame #53, and at position (40, 50) at frame #54. The sequence of events is as follows:

1. The game update loop begins frame #54 (that is, the physical world updates--this has nothing to do with rendering!)
2. All entities (actually, just entities that need to be updated--more on this later) have their transformation stamped/saved. This occurs before anything else, so the stamped values represent the position, rotation, scale, etc. of the entity as it was at the end of frame #53.
3. The update loop runs as normal for frame #54. Entities might move around via controllers, scripts, collisions, or whatever.
4. At this point, the monster has a stamped position of (30, 40) and a current position of (40, 50).

Now that the update is complete, the rendering process begins. Let's say we're running at 20 physical frames per second--that's a whopping 50 milliseconds before the next update must occur, and we'll use the time to draw as many frames as possible. Let's say that rendering a frame takes 5 milliseconds.

1. The game loop needs to accumulate 50 ms before the next physical update. We set the counter to 0.
2. The interpolation value is calculated as 0/50, or 0
3. The game renders with an interpolation value of 0, which means the monster is drawn at (30, 40).
4. The counter is incremented to 5, so the interpolation value is now 5/50, or 0.1
5. The game renders with an interpolation value of 0.1, which means the monster is drawn at (31, 41).
6. This process continues until the interpolation value exceeds 1, at which point the monster will be drawn near (40, 50) and the next update will occur.

This exact process is what you're seeing in the second part of the video. Of course, it's still a little messed up--you can see a noticeable lag in when the sword swings and the enemies are hit. No matter how smooth the rendering is, a game updated at 20 frames per second is going to play weird and have lag.

Other than the points below, that's all for this week. I've also implemented a shield, but I'd rather wait until I have real graphics instead of the hideous temp art before showing off that one. Until next week!

Some points of interest / objections:

Why not just run at a variable timestep, updating as often as possible?

A lot of games do this. Sometimes it's a good solution, sometimes it isn't; I've read both sides of the argument. In the end, I've chosen for a fixed timestep because it yields repeatable and reliable physics results. Variable timesteps can lead to quirky behavior, such as giving those with a lower (or higher) framerate an 'advantage' in certain situations.

If the interpolation is linear and the object is moving non-linearly (e.g. sinusoidal or accelerated movement), won't that look weird?

No, not really. It's almost totally unnoticeable at 60 FPS.

So why bother at all?

On some machines, I was getting a very noticeable stutter when the timestep was capped at 60 FPS. The very popular "Fix Your Timestep" article illustrates why this happens (near the end). This stutter was a result of 'temporal aliasing.'

Dash, Kick, Stamina

I'm a bit busy and don't have time for a proper blog post, but I still had some time to do some fun things recently. So, I'll just leave this video here, which shows a kicking (the lights), dashing, and a stamina system.

Until next time!

Gloomstone Cave: Texture Splatting and Sets, Music Fades

The best way to make an engine is to make a game with it. That's why pretty much all of my updates include some sort of practical 'demo room' scenario. Building out engine infrastructure in a vacuum is going to leave you with a worthless engine, so each update includes some sort of practical and realistic gameplay situation to help me discover gaps in the engine features.

Ever since adding layer-over-layer functionality and minor changes to the behavior structure, I knew I was just about ready to start building real levels. A delay in asset creation due to Comic-Con meant I had about a week to do something else, so that's where the distortion effects update came into play.

So, armed with some fresh cave tiles, I started making a game by designing one of the first accessible areas of the game, Gloomstone Cave. Two missing engine features quickly became apparent after I made a few interconnected rooms:

1. Randomized texture sets

Check out this level editor screenshot from a (fairly empty) cave room:

Design time...

Now check out that very same spot, in-game:

...and run time.

Notice anything? It's subtle, but there are actually two separate floor tiles--one is 'plain' and one has a slight pebble decoration to it. But if you look at the level editor, you'll see that it's all just one tile.

I'm not claiming this is some kind of technical wonder. It's not--it actually only took me a few minutes to add random texture set metadata to the texture editor, seen below.

A screenshot of the texture editor for a single texture, cave_floor

So, if two textures are tagged with the same 'random set' property, it means at run-time, when the level loads, a random texture from that set will be selected. The reason for this? There's absolutely no point in wasting design time picking out from a set of tiles when the goal is to just randomize them anyway. The minute I caught myself alternating between the pebbled and regular floor tile, I realized that adding this little feature would save me hours of time later.

2. Texture Splatting

Another thing I noticed when designing the cave floor is that it was boring with the same tile (well, two similar tiles) everywhere. I had a temporary 'path' tile to use, which looks like this:

A temporary path tile, straight from Google Image Search

Problem is, this looks pretty mixed in with the cave floor:

Bad

The naive solution to this issue is to make nice 'edge' versions of the tile so that it blends in. I might need one for each side--I can't just rotate them, since that would throw off the tiling of the rest of the image. Oh, and wait, I need 4 more for the corners. Oh, that's just the convex corners, I'll need 4 more for concave corners. Now we're talking about 12 tiles.

That's doable, but a pain in the ass to maintain. If I want another path--or grass growing on the cave floor, or water--do I have to create 12 more tiles for each one? When I make a change to one of those tiles, do I have to update all 12? Yes. That sucks.

What if I could just dynamically apply an alpha map to the single tile, and do it at run-time instead of design time? That's sort of the idea behind Texture Splatting. So, I added that to the engine. Here's how it works.

1. Create a custom splat map

I still have to create those 12 'edge tiles', but I create it as a re-usable alpha map. Here's what it looks like currently. I will probably add a lot more of these, including some more rugged ones. I call it my 'splat map.'

That's actually 12 square textures, even though it kind of looks like 6.

2. Pass in the splat map texture along with texture coordinates to the fragment shader.

A few of my shaders now have a segment of code like this:

   if (fragSplatUV.x >= 0)

   {

     result.a *= texture(splatTexture, fragSplatUV).r;

   }

So, entities (which includes tiles) have optional 'splat coordinates' that get passed in. I use -1 for the x value to indicate 'no splat', which saves me from having to do an extra texture lookup (which is probably true for about 95% of the entities). Note that I only use the red component of the splat map; maybe in the future I could use the same texture for other metadata, and only store splats in the red channel.

3. Apply splats in the level editor

Pressing 'b' in the level editor launches the splat picker:

The splat selector

4. Make things a bit prettier

Here's a result of me adding a bunch of splats to that ugly segment:

Looks better than before

And here it is with an old grass texture:

It's grassy now

So, even with minimal extra textures, it looks much better! Of course, it still isn't perfect--it still looks slightly artificial instead of organic. But that's just a matter of updating the splat maps to have more rugged and randomized edges instead of the straight lines and perfect curves that are there now.

That's all for the texture updates.

3. Music Fading

Just a quick little feature, I made it music transitions smoothly from one area to another. Here is a little video that shows that, as well as demonstrating a basic walk-around through various empty sections (I'll be making them more interesting really soon). Also, check out the cool light shaft effect at the cave entrance!

Note that I'm using palace textures outside since I don't have the proper outdoor cave textures yet.

Enjoy the video and see you time!