About Multiple Endings

I’ve been trying to put together a post focusing on the time where I was less active on the blog/online, and as a bit of an overview for the past year…but writing it out in a way that fits the nature of this blog has been difficult. It’s a lot of material, so it’s a bit hard to decide how to organize it, and it’s a bit of a departure from game development. Meanwhile, the days keep ticking away, so I thought I’d give an update on the game just to get a post out.

I’ve been more active than ever in development, and things are moving along quite well. After taking a lot of time over the past several months to update visuals, add support for game options/configurations, and work on Rebirth, I’ve returned to filling out the game’s story. Over the past month I’ve added in all of the art, dialogue, and scripting for the game’s story, all the way up to the ending.

The ending is done?!

Well. One of them. As I’ve opted to have multiple endings for Why Am I Dead At Sea, I’ll have to finish the “ending” to the game several times before I can say that it’s actually been completed. However, what I have finished is the basic framework that the separate endings switch off from, which means that the remaining work is a bit simpler than what I’ve already done.

Given that all of this progress takes place at the game’s finale, it’s hard to show things I’ve worked on without immediately and blatantly giving away important details about the ending. Like its original, there are some revelations and plot twists at the final hour – and they can vary, depending on the ending you get.

But I can speak in generalities and talk about the structure of the endings without giving away details.

Lifeboat — An object used in one of the epilogues.

I can be a very compulsive person. As a result, I am all too familiar with player paranoia: when a player feels anxious about if they’re missing some content. If you’re walking through a maze and find the exit, only to turn around and check every last dead end so you know you didn’t miss anything – that’s player paranoia. When a game overwhelms the player with choices and gives them a clear right/wrong answer, it can be an unpleasant amount of pressure. I recall playing the acclaimed Metroid Prime for the first time. I was having a lot of fun with the game, until I learned from somewhere that there were multiple endings, and that they were determined in large by the amount of hidden upgrades you collected throughout the game.

…I never played it again. That knowledge turned the game, for me, from fun exploration into obsessive item-hunting. It’s exactly the kind of system I don’t want in my game – I don’t want to burden the player with the worry that they made the wrong choice or missed things early on and unwittingly doomed themselves.

Admittedly, there is a lot of story-telling potential to having the game remember the things that you do. And I plan for that to be an element in the game. However, the factors that influence the game’s ending will follow this pattern:

1) The more drastic a factor changes the story, the later in the story it occurs

2) Conversely, the earlier a factor occurs in the story, the less significant it is to the overall direction of the story

Some more objects used in the latter parts of the game

What this means is, essentially, there will be two types of variables that change the ending/epilogue that you see. Conversations that occurred in the early/middle parts of the game could change additional, flavor dialogue at the end. It would give a nod to some of the choices you made earlier on, but does not itself decide the direction of the story or the resolution of the mystery. On the other hand, there are larger revelations and clues you can find, which will be available all the way up to the end of the game, which will decide the ending you get.

To reference what has to be probably my (and many other peoples’) favorite alternate ending design to date, the Suicide Mission in Mass Effect 2 has lots of smaller factors that decide who amongst your crew lives or dies – but ultimately, that isn’t what decides the climax of the story. At the end, there is still a big choice you can make at the end regardless of what you’ve done beforehand, which means you don’t feel shoehorned. It’s a good blend between acknowledging the player’s previous choices and allowing them to make new ones, and the ending of Why Am I Dead At Sea attempts to achieve that effect.

Indie-cade and Eye-candy

If you’ve been following this blog for a while (specifically a year), you may remember when I set a goal for myself to submit my game to Indiecade. Well, you see, though I may have implied that I was aiming for Indiecade 2013, I was actually planning on submitting to Indiecade 2014 the entire time! That is to say, in roughly the next week I’ll be submitting my game to Indiecade, right on time, just as planned.

Hmm. Yes. That’s what we’re going with.

It’s pretty exciting to send the game off for the first time to a real critical “audience” (if only of one or several people) – and it’s exciting that I feel the game is at a point where it’s really presentable and can speak for itself. Though aesthetics may or may not be critical for game competitions of this sort, I definitely took a lot of time recently implementing changes to the game’s visuals that I had been aching to for a while.

Let’s take a look, shall we? (NOTE: Below are some GIFs which wordpress resizes, and it kinda messes with the image. To see them in their proper resolution, simply click on them.)

1. Shadows!

Bonus included: The tiny "redesigns" that rooms go through over time — Bonus included: The tiny changes that rooms go through over time

Once upon a time, Why Am I Dead At Sea had no shadows. It existed in a world with purely ambient lighting; light was everywhere. It came from nothing and went nowhere, and therefore, no shadows! Someone pointed out to me that shadows were a relatively easy change that could make everything seem more grounded. It was obviously good advice, but at the time I wasn’t willing to go through every prop when I had a million other objectives, so I took a half-measure and added shadows to all of the characters.

Well now, all people and objects have shadows! And as expected, it didn’t take a huge amount of work, and definitely makes the game look better. Everything is less floaty and it’s much clearer where they’re positioned on the ground. It also just kind of breaks up the flat colors of the floors and adds some much needed detail.

2. Additional Backgrounds

I never thought I'd be making these graphics when beginning the project... — The middle one, the sunset, was finished a long while ago and seems to still be the best of the three.

As the content for the game continued to be made, there were points in the story where it is made clear that time is progressing, either from one day to the other or from morning to night – and yet when you go onto the ship’s outside deck, it was always the same time of day – sunset! That’s obviously because it was the only background I had made at that point. For some points in the game, though, it seemed really important that I get the alternate backgrounds which show different times up and running.

They help set the mood for the story in a big way, so once I got to a certain point it became a really high priority. But, that’s not all I did with regard to the outside-the-ship area!

3. Parallax Scrolling

I don't usually put GIFs directly onto the blog out of consideration for those with slow internets, but this just doesn't work in still image. — I don’t usually put GIFs directly onto the blog out of consideration for those with slow internets, but this just doesn’t work in still image.

If you’re not familiar with parallax scrolling, well, parallax is the effect of objects farther away not moving as much to us, thereby creating our perception of depth. Parallax scrolling is the simulation of parallax in media whereby different objects scroll at different speeds to signify depth.

After creating my lovely backgrounds for the outer deck, I brutally chopped them up and put them in separate images. I then created a special kind of Prop (ParallaxProp) that contains a set of images and has them scroll along with the game camera at different speeds. It was actually really simple to implement on the code-side; it probably took more time overall just cutting up the backgrounds and making sure the end visual result was what I was looking for.

Because the area is so relatively wide, if the scrolling is too extreme things don’t really match up or work out how I want them to. So, the scrolling difference is intentionally small, creating a subtle but still noticeable effect.

This one is particularly subtle, but the lowish FPS of the gif doesn't help. In game it's more apparent. — This one is particularly subtle, but the lowish FPS of the gif doesn’t help. In game it’s more apparent.

This was one of those features where it was “really cool if I could implement this, but I don’t know…” So, it feels really nice that I actually did end up getting it done! And it really didn’t take me a huge amount of time.

3. Water Animation

splashgif — I tried to keep Darryl inside the ship for this shot, but he directly disobeyed my orders!

I always knew that the boat’s lower outline and the ocean were going to need some kind of…change. A pure and unchanging blue rectangle didn’t quite cut it. What I have now is still imperfect in several ways, but at least communicates what is actually happening and isn’t as blindingly static.

Figuring out how I wanted to do this and implementing it were surprisingly tricky. For one thing, the water was originally a part of the map itself and I’d never made an animated object as large as this before, so there were a lot of possible ways I could implement the small waves in the water. I could animate them tile by tile, in which case it might make more sense to make it an extension of the map itself, or I could make one huge animated object, in which case I would probably make it a prop. The latter would most likely put much less strain on processing time, but would result in a really unwieldy and humongous bitmap. I ended up taking the middle-ground and made some 7-8 animated props, each of which was a small but wide “strip” of the full thing. The image files are small and simple, and there still isn’t a lot of labor that the game has to do to animate them.

I also had to decide how I could get animated water to agree with depth, since the part of the background above the horizon has objects (ie the sun and moon) that are far in the distance, while the animated water is completely flat. Most ways of trying to actually get the water animation to obey depth seemed either ugly or way too hard, so I compromised again and simply had the opacity of the waves fade as they get closer to the horizon. This was only possible because of the approach I took in cutting up the animation into small little strips, so it’s nice how the two issues fit together!

Actually this is not all of the visual changes I made, but they’re probably the most apparent ones, and they’re the ones I’m proudest of. None of the changes I have made are huge, as I’m not looking to give the game a full make-over, of course…but they add up to a much prettier game nonetheless. While there are still some things I really want to fix or renovate, the game is actually really close to how I expect it will look as a final product.

Now then…fingers crossed on the whole Indie-Cade business!

Stem to Stern #2 : Artificial Intelligence (part 1)

When it comes to programming Why Am I Dead At Sea, there is one feature that sticks out above all the others in terms of time investment and difficulty. It has ruined many a day with debugging. It has at times leeched me of all enthusiasm to get work done. It haunts my very dreams (well okay, maybe it’s not that bad).

It is, of course, AI.

It’s not that I regret including it – I still think it’s almost a necessity for the game, and despite how much time it has wasted I’m sure it’s been a worthwhile investment. However, I can confidently say that I would have designed other things in the game differently if I had been able to predict how much they would complicate the AI.

But those concerns are buried deep in the game’s systems. Let’s start with a bird’s eye view of the game’s AI, and work our way down.

As you might imagine, one object being inside another symbolizes encapsulation – that is, they are literally an instance of that class contained within the other class. The lines next to Behavior symbolize the classes that inherit from it (Behavior being an abstract class).

Not surprisingly, the Character class is at the top – it is one of the game’s linchpin classes. It contains a CharacterAI class, which contains and handles everything pertaining to that given character’s AI. In turn, CharacterAI contains a Behavior object and a CharacterCommand object. The former deals with the higher level concerns of getting the character to move around – this generally means interpreting and/or setting waypoints, and then using those to create CharacterCommands. The latter goes deeper into exactly how to get the character to move – it takes in waypoints and generates a path with the Pathfinder class, then interprets that information to figure out when the character should move, and in which direction.

To hit everything I’d like to talk about will take a lot of time and space, so I’ve decided to split this subject into multiple blog posts, possibly as many as three. We’ll begin with an overview of the CharacterBehavior class and its children.

The Behaviors

With the main aim of creating human-ish walk patterns, I have three overall behaviors that are used in the game, ranging from simpler to more complex.

Random Behavior

Click to see an animated GIF version of this.

Quite simply, under this behavior the character moves from tile to tile completely randomly. Aside from allowing the option to set boundaries that will stop the character from wandering too far, there isn’t any other higher level of thought outside of the path-finding.

Probably 90% of the RPGs that I’ve seen or played , especially of the 2D variety, seemed to exclusively have randomly meandering NPCs. It’s simple, but effective in breathing a bit of life into the background.

Pacing Behavior

Again, click to see a GIF version of this.

Sometimes I want the character to have a bit more direction, but I still don’t need a particularly detailed behavior; in this case, there is the pacing behavior, which creates paths based on whether to go horizontal or vertical, and how far in each direction. It is also good at demonstrating when a character is brooding, thinking or panicking, based on frequency and distance.

It might be worth noting that the behavior simply thinks of reaching the end-points in the pacing path, rather than explicitly in walking in a straight line. This means that if there is a pacing behavior in a room with obstacles in the way, the character will still move around them rather than exclusively walk in a straight line.

Routine Behavior

And lastly is the most versatile and communicative behavior, which is used (as the name implies) for when a character has a routine of some sort. The behavior takes in an arbitrary number of way-points and information about them, and the character is then made to move through them in a certain order.

This has been the most commonly used mode since it can get a lot of meanings across. On the smaller side, it could simply be getting across the idea of a single action: for instance, the cook has a routine where he walks from one kitchen appliance to the other. On the larger side, it could mean a daily routine that takes quite a long time to complete: for instance, the first mate has a large circuit across most of the ship in which you can see him checking up on everyone.

This is only a rough idea of all the waypoints. Click for animation! — This is only a rough idea of all the waypoints. It’s a bit outdated. Click for animation!

All of these behaviors are created before the game actually runs, and are stored in a separate place called the BehaviorLibrary. This is generally done simply with Tiled; I put an AI object right on the map where I want the waypoint to be, then give it properties. When the game loads the map file it also parses these AI waypoints and creates Behavior instances based on them.

When they are required in game, the CharacterAI sets its current behavior to one of them. Every tick in the game, CharacterAI queries Behavior to see if the character needs to go somewhere new – if it does, a new CharacterCommand is created with information about the new destination.

There isn’t a huge amount of gritty detail in this post, since the Behavior classes themselves don’t care too much about the details. When we get into CharacterCommand and Pathfinder, that will be different!

Stem to Stern #1: Narrative/Gameplay Structure

I had originally planned on opening up my series of more informative posts with a big post on AI, but since I’ve been mostly doing dialogue and cinematic writing, I’ve been inspired to make a post about the game’s overall structure instead.

Let’s start by describing the game in the simplest and most basic way possible. The gameplay involves me throwing a huge amount of writing and text at the player, and having them search for the important bits of information in there. Unlike other adventure/mystery games, there aren’t many puzzles or problems that if you can’t solve, you’re stuck. In WAID you always had access to everything you need. If you felt up to it, you could always brute-force through the challenges of the game by triggering every single dialogue and dialogue branch.

The challenge is to find the hints I’ve scattered in order to figure out which character interactions will get you on the right track. Of course, the non-vital dialogues are both an obstacle in that they obscure what you need, as well as a bonus in that they can flesh out the story and give further insight to the characters.

Let’s take a look at the structure of the previous “Why Am I Dead”. There is a wide body of what I refer to as ambient dialogue: the sum of dialogue which obscures the way forward. There are also smaller pieces of story dialogue which are actually needed to trigger the ending of the game. The way the game was structured, it could take you hours to finish it, or two minutes.

How does this structure look for a longer game, though? I would certainly like “Why Am I Dead At Sea” to last longer than that, whether “that” is two minutes or two hours. So how do we make that happen?

There were two challenges that I saw going into this project. Firstly, it seemed to me that a longer/larger game would run into the problem of overwhelming the player with far too much ambient dialogue far too quickly. As it was, the original WAID wasn’t extremely navigable and could bring the player down time-consuming dead-ends. Some people enjoyed this, but some did not!

And secondly, for a larger story I would want time to pass as the plot moves forward – that is, things would have to be a bit more sequential in order to make sure there was some plot. In the previous WAID nothing happens without player input except at the beginning and end, which was fine…but in this game that severely limits the kind of story I can tell!

So I decided I wanted to taper the beginning of the game, bringing the player into the ambient dialogue slowly. I also wanted to cut up certain parts of the game into self-contained ‘chapters’, in which there was only one entrance and one exit, so that some modicum of stage-setting could be done. The resulting structure for Why Am I Dead At Sea looks like this:

This is accomplished, admittedly with some awkwardness, by restraining who you can possess and where you can go at the beginning of the game. For the first two major parts of the game there is a substantial amount of optional dialogue accessible, but not so much that the player is drowning in it. Objectives are hopefully much more clear. As each new character becomes available to possess, however, the amount of ambient dialogue also increases.

This also allows for that oldest of design tropes seen so often in LoZ dungeons – if there’s a new character you just unlocked, you can be confident you will have to use them pretty soon. I wasn’t allowed to guide the player in this way before!

And just as importantly, having certain choke-points for the story allows me to do things such as have small periods of time pass, or move characters move around, and so on. This isn’t trivial. A weird thing about the last game was that, to preserve an interesting pace, characters had to spill their guts to each other very quickly, without knowing anything about each other! It was possible to suspend disbelief, but definitely felt off. This time around I want dialogue to feel more organic, which means at least the illusion of some time passing.

So that is, in a nutshell, the layout of the game.

We’re ready for Beta testing! Right on time!

Why Now?

Except, extremely not right on time. Although game development is always subject to delay (especially by indies), I think this large a time gap between when I said I was “just around the corner” for a demo, and today, still warrants some explanation.

A great deal of it is simply perfectionism – the constant feeling that the game isn’t ready for minor reasons that would certainly not disqualify it from play testing. This is aided by the fact that while I think of my goals in a linear way, I am often not able to accomplish them in that way. After working on a certain aspect of the game for so long, I begin to shut down and have to work on something else to maintain my sanity. Generally I’ll make a check-list with my main objectives at the top, but with lots of smaller issues that I’d like to get done at some point on the bottom. When I need a break, I tackle the smaller goals in whatever order I feel like. So while a main development goal may not appear so far away, this is a bit deceptive.

I also can’t ignore that my transition to China and my new job has slowed me down. Even though in the long run I think it will help my discipline and motivation to see the game through, it has in the short term taken a lot of my time and energy to get used to!

What Now?

Back to matters at hand, I will now be taking applications for beta testers. For the first time, (some) people will be able to play Why Am I Dead At Sea, and I’ll be able to receive vital feedback whilst developing. If you would like to help me and receive early access to the game, please fill out the following (short!) application and email it to pmcgrath@peltastdesign.com : Beta tester application

Of course, I know that as a tester you are providing me a valuable service, for free! Although hopefully early access to the game is some recompense in itself, beta testers will also have the following incentives:

– Free copy of the game when it is released, along with whatever key codes are relevant, based on how it is distributed (this is an obvious one)

– Recognition: All testers who contribute will be shown in the credits (also pretty obvious). Those who contribute substantially more will get extra recognition.

– I would also like to have monthly best-bug-find competitions, the payoff for which could possibly involve leveraging my art assets/scripting to give the tester a little memento in the form of a screenshot/GIF made with the game engine (the contents of which being up to the tester).

At the moment, the version that testers can play will take them through the game’s introduction and first chapter (of which there will be five). It isn’t a huge amount of content to explore as of yet and mainly serves to introduce the player to the story and the patterns/concepts of the game, but is almost entirely content complete! And of course, later chapters will follow.

At this point, development will overwhelmingly mean writing dialogue and cinematics, as well as responding to bugs and player feedback. As a result, updates will probably be sparse in new shiny art or features. So, I’ll be taking the time to go into greater detail at some features I’ve brought up before, how they are implemented, et cetera.

The Grind

There’s been a grab bag of progress since the last update.

1. Character AI / Behavior

Perhaps the most substantial accomplishment has been what I can only hope is the final slaying of multiple bugs in character AI and behavior — getting characters to move around the ship on their own, handle transitions between areas elegantly, and react to obstacles (including the player). I definitely anticipated that this feature would cause me some trouble, but I have to say that this has been extraordinarily tedious to implement. It has become something I dread working on by this point and definitely sucks on my energy to work on the project.

And I’m sure there are still several bugs that will only show themselves after play-testing. Hooray!

One feature that I lump into “character AI” is something I haven’t shown yet: the ability to have characters follow you around, caterpillar-style! This will be used at a couple points in the game when the plot demands it.

As with last time, click on the image to see a GIF of this!

Getting the follower to work correctly was quite tricky. The normal pathfinding for characters moving on their own was too clunky and not responsive enough to follow the player around closely. So, I had to write a simpler sort of AI that beelines towards the point the player was in about 30 frames ago. However, this can be exploited by the player as well to get the follower stuck on obstacles, in which case the follower will walk in place for eternity.

Each approach had its faults, so I created a hybrid of these two behaviors. The follower now uses the simpler behavior until it finds itself stuck on an obstacle, at which point it shifts to the more complicated path-finding behavior in order to get around the obstacle. As soon as it reaches the player, it then shifts back to the simpler behavior. You can see this in action in the GIF when I get the follower stuck on a wall-corner, and she moves around it after about a half-second pause.

At some point I think I’d like to make a huge post about all of the small idiosyncrasies, bugs, hangups and annoyances of character behavior. It would be cathartic.

2. 100% More Kitty!

I don’t think I’ve mentioned this on my blog yet. There is in fact another possessable character, up until now never spoken of! Who could it be!?

Yes, you get to possess a cat. It may not be the most useful for getting other characters to open up about their dark and troubled histories, given that it can only say “meow” or “hiss”. But, it makes up for that by being the most agile and lithe of your potential hosts. Observe:

The cat has the ability to jump, a feat that no human in the game seems capable of (or at least interested in). And combined with its small size, this allows the cat to go through crawl spaces and open up new areas that you couldn’t access with your human hosts.

3. The Introduction

One of the final things standing in my way for a complete demo is a proper introduction that pushes the game off. This was something I could have pushed back; I could have released a demo without it. However, I’ve heard that feedback is a bit of a finite resource, and I’d really like my first ‘wave’ of feedback to include the introduction to the game.

In the previous “Why Am I Dead”, you are simply thrown into the game. Instructions are given as black text on the ground, and you are given a short conversation that explains the premise of the game. This time around, the introduction will still be short and sweet, but much more involved. This is partially because of a difference in premise — the last time around, you start hovering over your fresh corpse. Combined with the title, it really spoke for itself. In this game, things aren’t quite as simple, and it really warrants the extra effort to explain things.

A little peek at the introduction outlining the protagonist’s end.

This meant creating original art for the introduction and scripting things to get the timing just right. It’s been pretty easy to implement, but surprisingly time-consuming.

I know I’ve taken way longer to get to a closed demo than I had predicted, but I really am getting close now. I promise! For real this time!

Really Piling it on Here

Hello from Xi’an, China! Things have been a bit hectic; I’m just getting over jet-lag now, and I start teaching English classes tomorrow.

Lots of new stuff to adjust to. New country, new apartment, new school, new students (lots of them). It might be a while before I get comfortable with all of it! So, what better a time than now to make clear my goal to submit Why Am I Dead At Sea to IGF 2014?

The deadline is October 19, which gives me about a month and a half to get my current build to competition-readiness. That really isn’t much time at all! But more importantly, this gives me a solid deadline and a great reason to get back into full-time development. To be honest, even though I completely failed to reach my goal of submitting to Indiecade, that was by far the most productive time for me. I never really was able to match that pace afterwards. And now that I’m in China and teaching English and all that crazy and awesome stuff, it’s more important than ever that I have a clear goal that I’m working towards. It would be very easy to lose sight of development in the midst of everything else, and I am determined not to let that happen!

Most of the work left is writing and polishing. Prioritization is going to be key here — there are lots of side-features that I’d like to implement but which are by all means optional. If I want to even have a chance at submitting my game I’ll have to be much better at leaving that stuff to finish later.

So….here goes!

One More State-side Update

Sadly this past month hasn’t been as productive as I might have liked. The main culprit is probably the fact that tomorrow I’ll be flying to the other side of the planet, where I’ll be spending the next year. Aside from the time I’ve had to spend preparing for the trip, it’s a bit hard for me to focus on development with something like that looming over me! I guess you could say the move has stolen the game’s thunder for the time being.

For the next week or so I’m guessing I’ll be swamped with getting situated. After the initial craziness though, I’m hoping that I will actually be more productive overall with Why Am I Dead At Sea than I have been this summer. Though I’ll have less potential waking hours to contribute to the project, I think that my day job will keep me from burning out and will force me to value my development time more. When all of my day-to-day structure is self-imposed, it is so much harder to stay on task!

With all that said, there has still been a good deal of progress that I can share, so let’s get into that! Note: Every picture is linked to a GIF that shows the same thing but with animation. If you want to see the animation, just click on the picture!

1. Scenery Layering

One thing I did since my last blog update was rewrite a lot of my collision detection code, mainly because it was legacy code from the first “Why Am I Dead” that was needlessly complicated and honestly just done very badly. To make my life easier in adding other stuff to the game, I decided to just bite the bullet and tear it all out.

One thing that I then proceeded to do with the help of an improved collision detection system was to include support for layered props. Previously, only characters could be layered to give an illusion of depth, while props were completely static and could not be moved in front of or behind, but simply around. Now, they operate in the same way:

So that’s neat.

2. ‘Spectral’ Effects and Unlocks

I’ve known that I wanted to have a different visual style in the game for the ghostly/supernatural things that happen in the game — something that seems to be separate from the pixel art of the rest of the game. After flirting with particle effects, I decided on a…motif of sorts, involving relatively simple vector art combined with lots of different animation effects.

The screenshot below, actually, is a pretty bad example of that, but it also demonstrates one of the big applications that this motif will be seen in.

This is still really rough, but gets the idea across. So…what are we looking at here?

Currently the ghost is using an ability to sense what things it can interact with. As you might guess, green means that it can, and red that it can’t.

In most cases, both characters and new areas must be unlocked before the ghost can successfully enter them. In the case of possessing characters, you generally have to be able to understand the motives of that character before you can steer them. And in the case of different areas, you need to have explored the place behind a door before you can ghost-magic your way through it. This means that you have to possess someone who has access to that area before you have the ability to visit it as a ghost.

This may strike some as rather un-ghostly; generally ghosts can pass through anything, without question! However, you will very quickly be able to unlock most areas and will spend the majority of the game floating through everything. This is simply a way to give some more structure to the early parts of the games, and allow for a few surprises.

3. Mind-reading

You have yet another ability in your ghostly arsenal: mind-reading! This can be done on anyone at any time, and satisfies two functions:

– Additional, optional background and development for those who are interested in seeking it out

– Hints and cues for those who are stuck

It’s as simple as going next to a character while in ghost form and hitting a button. You will then be brought to a screen that generally has an animated pattern in the style that I outlined before. On top of that, the thoughts of the character fade in and out.

Each character will obviously have different text that corresponds to what’s going on in their heads at that time in the story (and it will change over the course of the game). But more importantly, each character’s mind-reading-screen will have radically different animations and visual effects that correspond to their personality and emotional state.

Given how eccentric some of the characters are, I’m going to have a lot of fun with it.

Well, that’s it for now. The next update that I make will be from the city of Xi’an!

Anchors Aweigh

Quite a bit to cover this time.

New title. I’ve decided to change the name of “Why Am I Dead 2” to “Why Am I Dead At Sea”. It’s not a huge change, but a lot of thought was put into it. I came to this decision primarily because this project really isn’t a direct sequel in many ways, and I wanted the title to reflect this. In addition my hope is that this game will be able to reach a much wider audience than its predecessor did, and I don’t want anyone to think they will need to play another game to understand it. It really is a project that I hope will stand on its own…so tacking on a number at the end didn’t seem to fit!

Though I feel it’s a bit on the wordy side, I went through innumerable potential titles and could find nothing else that more accurately described the spirit of this project than “Why Am I Dead At Sea”.

Beta testing. Though development time has exceeded even my wider estimates, I can happily say that I will soon be ready for closed beta testing / play-testing.

Given that the weakest area of my last project was the amount of bugs it had on launch, this is something I’m taking very seriously. The last time, the only play-testing that my game had was from fellow developers on FGL.com, a website for other free browser-based games. This was a big mistake! While I’m eternally grateful to everyone there who helped me out, I should have really used it in conjunction with other sources, as I didn’t get enough feedback on the game to smooth everything out.

For instance, the reason there were game-breaking bugs at the end of the game is very simple: out of all the people who played my game before it was released, I think only one person who gave me feedback actually reached the end! And then when the game was launched and I was scrambling to push out new fixed versions, I didn’t have anyone but myself test those, either…so they sometimes ended up creating new bugs. It was a mess!

This time I’m going to be much more proactive in getting feedback, gathering a wider pool of testers, and putting the game through play-testing longer. My plan is currently to find volunteers who would be interested in the type of game I’m making, and offering incentives for their help (obviously a place in the credits being one of them, but ideally other things as well).

Marketing. Around the same time that I start beta-testing, I will have enough assets to feel comfortable in making a serious effort to publicize my game. This will mean a teaser trailer, a website launch, a Greenlight page, and loads of other stuff.

My plan for publicizing the game is a two-parter, since I feel the game is in a bit of a grey area. It has a lot of elements that I think would appeal to a smaller, but more dedicated audience — which means that the sooner I start talking about my game, the more likely I am to reach that audience. But my game will also be very cheap and on the smaller side — which says to me that most people will only give it their attention once, and if it isn’t available then, they won’t pursue it later.

So my compromise is to release everything I can to publicize the game as early as I feel comfortable, with the sole exception of a free demo, which I will reserve for the day that the completed game launches.

There’s still a lot of work to be done, but I’m definitely reaching an exciting stage now where the game is taking shape. Hopefully by my next post I’ll be able to show a teaser and the game’s dedicated website.

Menus and Screenshots for WAID2

Happy Fourth of July for any state-side readers!

Progress on Why Am I Dead II could be fairly characterized as slow but steady. After giving up the ghost (ha) on the Indiecade deadline, I have to find something else to latch onto so that I can push myself harder.

But that’s not to say that I’ve slacked off! I decided to take a break from art and return to programming. Much like how pulling a thread can unravel an entire garment, a small change to how I displayed things on screen turned into a pretty thorough upheaval of the whole game engine. It was a long time coming, since a lot of the original code was 1) written a year ago and 2) written with a much smaller project in mind.

The benefit of all that work is invisible, but present. The code is just overall a lot better and less stupid. It’s still pretty stupid in some places, but a lot less so. And that’s always good.

I then returned to the initial reason I made the change that started all of that, which was menus! I wanted overlapping flexible menus, and now I have them. This will be used for the starting menu and the pause menu, and will be responsible for loading your game and changing your game options.

A rough version of the screen housing your Save files.

The biggest challenge for this was mostly getting the controls to work for both the mouse and keyboard smoothly and intuitively.

I was then able to return to working on the game art feeling a bit refreshed. I’ve now expanded the scenery assets to a point where I’d rather not even list them, as it’d take up too much space! I’ve also filled in the majority of the game maps, to the point where the end is in sight. You can probably infer this, but there is a lot more space, and a lot more scenery, and a lot more everything in this game than the last. A big reason this is taking longer than I estimated is what I guess could be called art creep, wherein I compulsively add this or that art asset on the fly to fill things in more.

So, for the first time, I’d like to share completed mockups of the game in action. But as tradition goes, let’s start by revisiting screenshots of the original game: