A real conversation

Working my way toward the alpha release, one linear step at a time, I needed to first replace my skeletal dialog system with a real one, one that allows people to say different things based on, for example, how far along in the game the player has advanced. So I wrote the first part of that piece, which involved abstracting out a conversation manager, moving conversation storage to text files in the Content area, and allowing multi-person dialog. See the very first two-person conversation of the game, between the protagonist and the villain, below:

There’s a bonus camera control regression demoed at the end, there. Apparently, the last time I was in there mucking around, I inadvertently broke support for single-screen rooms, like there are a bunch of on the ship. Sigh. And here I was thinking I could get away with not touching the camera again until after the alpha.

Musical showcase

Calling this game a one-man indie metroidvania isn’t quite accurate, since I never intended to compose the music on my own. For that, I have a whole stable of talented musician friends who are eager to contribute their talents. I thought it might be a good time to showcase what they’ve offered up so far.

First up is “The Easy Room” by Roark Brewster. I’m not sure where this will get used in the game or if it will, but it was composed for that purpose. I think we originally intended this to be the background music for the ship. Who knows; it might find new life at some junction.

The Easy Room

Next we have “San Francisco” by my brother-in-law, Max Cheswick. A cleaned-up, looping version of this will the be background music whenever you’re on the ship.

San Francisco

Max also contributed this great atmospheric track (as yet untitled) for exploring the surface of the moon:

Exploration (working title)

Finally, Roark came through with a catchy guitar and synth tune he calls “Spur.” It’s a bit too lighthearted for most of the game, so right now I’m planning on using it for the title screen and final credits. Although, to be perfectly honest, I like this track enough that I’m considering coming up with an area of the game that would match its mood — music-first game design, I guess.

Spur

Which one do you like the most? Think one of them would work best in some particular game environment? Think you can do better? Let us know in the comments!

Time to quit dicking around

Alright. Time for a change of pace.

Up to this point I’ve been working on game features pretty haphazardly, pretty much following my joy from sub system to sub system as I saw fit. It’s all work that needs to be done (probably), so there’s no real issue here — except that I’m an engineer, and engineers sometimes need to be dragged away from a system they’re building and told to move along. On the game development subreddit, they frequently admonish newbies to “build games, not engines.” That proviso is necessary, since so many programmers (myself included) have such a great time building engines that we forget they’re for making games with, not the other way around.

I’ve updated my milestones page with updated statuses for the sub systems I’ve identified so far and how far they are along. I also added a new column to the table, which is what pre-release build of the game needs that feature. I’m officially re-gearing the project to get it to playable alpha as soon as possible, hopefully a little after the new year.

The milestones page should give you a vague idea of what the game will comprise up to the Alpha. I’m aiming for about 20 minutes of gameplay. This includes the opening sequence, which is the bit where you explore the ship and learn things about the plot, as well as the first part of exploring the surface of Enceladus, the first several powerups, and the first boss enemy. There won’t be a ton of “off-road” exploration you can do at this stage, but enough to give you a taste of what the finished product will hold in store.

I’m going to work on things basically in gameplay order, which is a stark departure from how I’ve been operating. To that end, next up is an event / cutscreen system to handle (for example) the ship landing after you’ve talked to everyone on board and then gone back to see the captain. Interleaved with that work will be a full fledged dialog system, to allow the protagonist to have conversations, not just hear what people say. Finally I’ll be moving on to drawing the tile set for the surface and immediate underground portion of the moon, as well as enemies to occupy it, then designing the layout of the levels and upgrade placement. Very, actually finally I’ll be working on the upgrade system itself and the UI elements, like equipment, map and title screens. Oh, and I might need to implement saving in there somewhere.

It’s a lot of work, and I think to stay on target I really need to be making noticeable, linear progress towards an Alpha, rather than just chipping away at all sides of the finished piece as I have been. I’m excited to try this new approach, so wish me luck!

Shut the door on your way out

Up until now it was kind of hard to jump up through a vertical doorway, since you would need to angle your jump to land on the solid ground on either side of the door itself. Now doors will sense when you’re no longer occupying their space and close automatically so that you can land on top of them. Take a look.

I’m a bit torn on how to best implement doors in general. As always, I ask myself “what would Super Metroid do?” Well, in Super Metroid the doors don’t really exist in the game world space, as such. When you enter one, you lose control as you are ushered through, and you appear on the opposite side with your beginning momentum preserved, just as if you had been teleported through the space the door occupies.

I kind of like having to actually walk through the doors in my game, but I am a bit concerned that players will become frustrated trying to jump up through vertical passageways, only to lack sufficient momentum and fall back through the doorway, as I do in the end of the above demo video. But I guess that’s a problem for alpha testing to reveal.

Furry landscape destruction service

I fixed the limitation in foreground scenery destruction that I talked about yesterday — you know, the one that I probably didn’t need to fix. This results in arbitrarily bedizened scenery being perfectly acceptable to the game’s destruction engine, as below.

I don’t plan to decorate the game world so tastelessly. Still, it feels good to have the option, you know?

A note on implementation: each tile in the tileset can declare itself to be “attached” to collision-layer scenery in one of the four cardinal directions. Then if a block in the right direction is destroyed, it is too. The only complication is adjusting this attachment direction to accommodate the tile being rotated or mirrored. I basically figured this out by brute forcing it, which was definitely the easiest way to go. Here’s what the algorithm looks like using the extensions to the XNA Tiled map reader library that I wrote:

private static string GetTileAttachment(Tile tile, Tileset.TilePropertyList tileProperties) {
    int index = ((int) tile.Position.Y * tile.GetLayer().Width) + (int) tile.Position.X;
    byte flipAndRotate = tile.GetLayer().FlipAndRotate[index];
    bool flipH = (flipAndRotate & Layer.HorizontalFlipDrawFlag) != 0;
    bool flipV = (flipAndRotate & Layer.VerticalFlipDrawFlag) != 0;
    bool flipR = (flipAndRotate & Layer.DiagonallyFlipDrawFlag) != 0;

    string attachment = tileProperties["attached"];
    switch ( attachment ) {
        case "up":
            if ( flipH && flipR ) {
                attachment = "right";
            } else if ( flipV && !flipR ) {
                attachment = "down";
            } else if ( flipR && !flipH ) {
                attachment = "left";
            }
            break;
        case "down":
            if ( flipH && flipR ) {
                attachment = "left";
            } else if ( flipV && !flipR ) {
                attachment = "up";
            } else if ( flipR && !flipH ) {
                attachment = "right";
            }
            break;
        case "left":
            if ( flipH && flipR ) {
                attachment = "up";
            } else if ( flipV && !flipR ) {
                attachment = "right";
            } else if ( flipR && !flipH ) {
                attachment = "down";
            }
            break;
        case "right":
            if ( flipH && flipR ) {
                attachment = "down";
            } else if ( flipV && !flipR ) {
                attachment = "left";
            } else if ( flipR && !flipH ) {
                attachment = "up";
            }
            break;
    }
    return attachment;
}

Being able to use strings as the case labels in switch statements is one of the many small things I appreciate about C# over Java. Having to use Java at work every day seems more like oppression than ever before.