Prototyping the holocube

True story: I had plans for a power-up that lets you place a tile anywhere you want in the game world, hardly an original idea, before I bought and played Antichamber, a game that explores this mechanic to it fullest. And now I feel like a hack.

Nevertheless, I whipped up a quick prototype of how this tool will project from the player’s weapon to place itself in the game world. Have a look:

As Antichamber explored, being able to alter the landscape in this simple way introduces a huge number of possibilities for puzzle-like lock-and-key mechanics, especially when combined with other tools or weapons or other dynamic game elements. But the simplest use of this thing, which I will be working on first, is just as a stepping stool to let you jump one tile higher, or to allow you to scoot your way into a one-tile-high tunnel that isn’t on the ground — there’s no equivalent of a bomb jump planned, so this will be an important skill to use.

No more pixel counting for a while

I finally finished manually correcting the shot placement for every possible player animation, so that the beam weapon bobs along with the player as he moves. It was a lot of work, but on the whole I’m convinced it was worthwhile. The weapon’s beam now follows the character’s movements in a way that looks convincingly organic. Have a look!

Near the end, you can also see a debug mode I created just for this purpose, where the frame number of the character’s current animation is drawn on top of his base image. Then I just had to manually tweak the shot placement for each frame of each animation, note the appropriate offset on a legal pad, and repeat until done. Certainly it’s tedious, but less error prone than trying to count the pixels in the raw animation images and quite a bit faster. And I’m now done!

That means I get to move on to the next secret feature of the game, which we will discuss more tomorrow.

My lord that was tedious

Maybe it’s a part of game development in general, or maybe it’s just something I do, but I can’t seem to stop myself chasing off down rabbit holes in a project like this. Like today, I got the new beam weapon hurting enemies and opening doors, then decided that it looked really crappy when the character runs, because the shot is always placed in the same position, not bobbing up and down like the character’s gun does when he runs. So then I spent the next many hours counting pixels and hard-coding manual offsets. I just couldn’t help myself — it makes an enormous difference in how the weapon feels. See for yourself: in the video below I have hard-coded offsets for the running animation, but not walking or jogging. Notice how it starts looking a lot better when the character hits full running speed.

The upside of this work is that (in my opinion) it’s the difference between a decent-looking game and a really hokey looking one, but the downside is that it’s tedious manual labor. It makes me want an intern.

Nonetheless, I finally got things looking pretty decent with standing, walking, jogging, and running animations.

More conversions to do tomorrow, but I got the really frustrating ones out of the way.

I’m not totally clear about how the damage from the gun works yet, but my current implementation is basically a damage per second model. If you shoot something with the beam continuously for one second, you do the same amount of damage you would have with 10 normal shots. Seems pretty generous, but it will need some tweaking as I create more enemies to kill with it.

100 posts!

According to Word Press, I now have over 100 posts on this development blog! It’s been a privilege and an honor to be able to share my work with the world in this way. I hope you have enjoyed it as much as I have! And I hope it doesn’t take another 100 posts before the game is done…

Apparently there are 12 or so posts without accompanying videos, but you can relive the magic of the 88 video updates so far, over a year’s development, in less than an hour via my YouTube playlist. Have fun!

Prototyping a beam energy weapon

At some point over this summer, I decided that having one type of projectile weapon was plenty, and to forego a missile, ice missile, super poison missile, and so on. Instead, I have been slowly coming up with a solid idea for a beam weapon to collect, rather than a boring missile. Unlike the missile, this weapon travels instantaneously, stays on as long as you hold the button down, does great damage, and can go through multiple enemies if they’re in a line. Here’s my first attempt at prototyping it:

Feels pretty good, so far! My feeling is that, because of its high damage and instantaneous nature, you’re going to want to use this thing all the time. However! Every frame it’s active it uses energy, which is somewhat limited. To start, you’re only going to have a few seconds’ worth of energy, which you will have to ration in short bursts for it to be effective. Players will need to explore the game world to find more power packs to extend the time they can fire it continuously.

Further upgrades will enable you to widen the beam to make it a more concentrated burst of power. I want to eventually implement shadowing, where the landscape cuts off parts of the beam, but that’s a little ambitious for today.

Also eventually, I would love to implement this effect using a post-processing shader, but that is trickier than what I’m doing now. The best way I found of simply achieving this effect is to have a small image that you stretch into the length of the beam. If the beam image varied much along its length this would look wonky, but for my solid bar of white it’s just fine.

Vector2 displayPosition = ConvertUnits.ToDisplayUnits(_start);
Vector2 origin = new Vector2(0, ImageHeight / 2);
float unitLegth = ConvertUnits.ToSimUnits(ImageWidth);
float lengthRatio = (_end - _start).Length() / unitLegth;

spriteBatch.Draw(_image, displayPosition, null, Color.White,
    GetSpriteRotation(_direction), origin, new Vector2(lengthRatio, 1.0f),
    SpriteEffects.None, 1.0f);

Probably the most interesting thing about this new weapon, from a design perspective, is that there are lots of potential lock-and-key dynamics it could be used for. For example: a door that needs a continuous beam of energy for a certain time period before opening. Or blocks that slowly burn through when hit with the beam. Or a sensor that closes itself up when it hears gunfire. I’m sure I’ll come up with many more ideas before I’m done.

All new sound effects!

I finally got around to integrating the game’s sound effects into the audio engine XNA provides so that they’ll mix well with the background music. XNA also makes it pretty straightforward to do interesting things like make 3D sound sources, so that the stereo (left-right) mix of a particular effect will depend on where it happens relative to the character. But that’s for another day. Today, I just focused on getting sound effects for all the in-game events I knew I wanted covered. See how many you can count!

I made all the effects using a nifty tool called SFXR, created for rapid prototyping during a Ludum Dare contest. I don’t know if these will be the final sound effects, but its nice that I can get unique ones whipped up so quickly.

You might also notice bullets bouncing off of things quite a bit — that’s also new. I might make them fade away quite a bit faster in the final game, but I like the effect overall. The simplicity of adding something like that, this late in the engine’s development, is one of the reasons that I’m glad (on the whole) that I used a physics engine instead of ginning something up myself. Although it has caused many frustrations, realistic physics is a really nice bit of polish to be able to slap onto somewhat prosaic gunplay.

New enemy with bonus blooper reel

Kyle Johnson sent me another great sprite, of an enemy I’m calling a skull beetle. It’s actually about the size of a pig, and looks just the right amount of cute and menacing. It kind of gallops along in an enthusiastic manner. I might eventually make it charge a bit faster when it sees the player. See it in action below:

Like a lot of things about this project, it was much more complicated to get right than I thought it would be. My first attempt was just to swap out the graphics for an existing enemy, which was kind of hilarious:

The reason they seem to multiply when they die is that the source image is a sprite sheet, rather than one texture per frame as I’ve been using for other enemies, and therefore the entire sheet (with all 8 frames of animation) was getting “shattered” whenever one died. Oops!

Closing the loop on the first mini-boss

I spent the day tying up loose ends with the first mini-boss encounter, the stuff that wasn’t super sexy but essential to game progression. The biggest issue was that I had no facility for monitoring when enemies died, which means I couldn’t trigger a cutscene and unlock the doors when the last one was gone. I also needed to only place the turrets if they hadn’t already been defeated. That’s all taken care of now:

I also made the enemy projectiles shatter when you manage to shoot them out of the air, which feels really satisfying. The turrets still don’t seem to always want to shoot when they should, so I suspect I’ll have to track that down tomorrow before I can do anything else. I’ll also be converting the game’s sound effects to use the XNA audio engine, which the music tracks already do — should make it easier to balance out the volume levels of effects coming from different sources.

Probably need to up the difficulty a bit

I got the turret enemies basically fully working, then tried to take them on in the first mini-boss scene. Here’s the whole fight:

Not super challenging, but it is the very first major encounter of the game. The first time I played it through, it was actually super challenging, owing to two factors. First, there was no limit to how fast the turrets could fire, as long as they didn’t have another bullet in the air; second, there was no invulnerability period for the player in between taking hits. These two factors combined to just shred the entire energy meter when the player got into a difficult spot, and I had to fix both these issues before I could consistently beat the first mini-boss of my own game. It feels much nicer this way.

I quite like how the turrets turned out. They won’t try to shoot you until they have a clear line of sight to you, and the speed with which they track you makes it just dangerous enough to be interesting. Later iterations on this enemy will feature much more powerful and difficult to avoid projectiles to keep things challenging when you have a ton of energy.

I also have plans to make these turrets invulnerable except when they open an access hatch to reveal their glowing weak point. Honestly, I think these first enemies are probably challenging enough the way they are at the moment, but it will be a nice upgrade for future turret-type foes.

Evolution of robot sentry turrets

I finally took an honest crack at the robot sentry mini-boss today, and got it mostly done. The art is terrible, but I’m hopeful a donor will fix that. I thought it might be interesting to detail how the enemy evolved throughout the day.

I started just by getting all their parts drawn on the screen in roughly the correct place, as well as a physics model for their body:

Not bad for a first attempt

Not bad for a first attempt

Next I added some basic player-tracking, so that each turret is always aimed exactly at the player (as much as possible):

Instantaneous tracking looks neat, but it’s not super fun to play, since humans are no match for machine reflexes. To make it a fairer fight, I had to add in a maximum turning speed for each turret:

I got it mostly working right away, but then spent way longer than I would have liked working out the kinks. Here it is fully working in another test area:

The guns aren’t quite done: they need to actually shoot, of course, and to cause damage when you touch them and their projectiles. They’ll also be impervious to attack at times, then open a hatch and expose their giant glowing weak point. People seem to like it when video game enemies do that. Hopefully most of the brain-heating trigonometry is out of the way, though. I had to lay on my carpet, moaning softly, at one point.