psysal

I started this as a reply to increpare's question: How much do you plan on characterizing each of the playing areas?

I thought it would make a good dev blog post.

Define "Area"

For the purposes of this blog post, I should explain what I mean by "area".

Each "area" is a 50x50 block that you can think of as being closely analogous to a "screen" in non-scrolling games. That is, it normally fits within a greater geography but creates a very concrete sense of location. When the player leaves one area, they hit an edge and the next one loads. It's a somewhat abrupt and very deliberate transition. As a result, the player's sense of location in the game world is discrete: she knows she is on the area (screen) with the waterfall, not just "near to" the waterfall.

In that sense, each area is mainly characterized by it's shape, and it's contents: where are the exits, walls, and what buildings or set pieces are inside of it. I lay trees/rocks out in certain patterns or try to create distinctive points of interest on each area. By the same token, other areas are more anonymous in feel (e.g., somewhere in a forested area); they seem to just be a "forest square". Even so, landmarks such as bends in a river or particularly placed trees are helpful.

Greater Geography

Beyond this the game is broken down into a greater geography. There are "real world" and a "alternate reality" planes which have slightly different color sets and terrain types, as well as completely different trees/rocks/walls/etc. This creates a nice division between the two.

Within each plane, I try to create a sense of location by how I lay out objects and how areas flow into each other. So for instance, certain flowers may be very prominent on the southwest corner of a map, across several areas, but not at all existent on the southeast corner. Other, larger "places" help to define the areas such as a castle, graveyard, or town.

Certain elements also flow between areas; so farms have fields that cross across boundaries and walls which pass through several areas. We have to follow the walls (usually by walking on a path) to a nearby gate to get through (although in many cases there are crumbling sections which not only add interest but prevent you from having to walk all the way around).

Start With Setting

Lastly, or rather, firstly, I start off thinking of setting. The first thing I usually want to create is the setting, and that means mapping. So I draw maps on paper, changing and reorganizing, until they seem to have interest and look natural.

All this, without respect for the gameplay they will later have to support. For the most part, the entire game world was created before I had a good idea as to the specifics of locations, or other functional elements (e.g., crossing a bridge or getting through a certain cave to reach a more advanced area). I think this approach creates a better sense of place, so that you feel the game world is quite logically organized.

I also think this is a more authorly way to work. Do novelists start off by thinking of a story and then construct a setting to fit around it? Of course not. A setting inspires a story and if it's not based on a real place or time on planet earth, then typically requires a lot of imagining on the author's part.

Of course, you make modifications to your setting to fit your story, once you have it in place and realize what you need.

End Result: Believability

The purpose of this kind of organization is to allow the player to orient themselves within a believable world. We give them enough landmarks and subdivide the world into discrete blogs to give them a very good sense of where they are at all times. At the same time, we have a greater sense of geography that we constructed to be interesting in the first place, before we started to think about gameplay and story. What we end up with is a world that both feels natural and is easy to understand: and hopefully somewhere fun to be!

Persistence is Key, but...

Finishing a game requires a LOT of persistence and a lot of ability to just plough through small details and so forth.

But sometimes you need to recognize when something you're working on should be just dropped. I don't mean a whole game, I mean a feature or an idea. You've already decided to add a certain feature; how do you undecide?

When to Stick To It

You can't just undecide based on difficulty. Some features may be necessary but fairly painful to implement, for example hunting down memory leaks. This could take you a few days but you can't really avoid it. For these, I think you just have to stick to it.

Other features may not be necessary but seem like a good idea. I.e., if you could get this feature in it would fix certain gameplay-related problems. In this situation, I think you normally have to follow through as well. Reason being, if you don't pay attention to certain problems with gameplay, those problems are going to ruin the whole rest of your game.

Sometimes you can comprimise. For instance, a blog post or so ago I talked about NPCs opening doors. "Properly", the NPC should determine that they are in front of a door, stop, open the door, walk through, stop, and close the door. This is a ton of game logic. Instead, I took the middle ground and had them detect when they were already on top of a door, open it (so that technically it opens late) and then once they are off of it, close it. They don't stop, and they technically pass through the door before opening it. But it's a good comprimise. Without this, the game have a rather large gaping "hole": NPCs would pass miraculously through doors. I can't really get away without fixing that.

When to Cut Your Losses

So when do you actually decide to cut your losses and drop a feature altogether?

I would say, you "undecide" when you realize that you made bad decision, and why.

Recently, I decided to clean up the side-to-side area transitions. When you move from areas on the world map, there was a "wiping" transition that sort of wipes the screen to black, then unwipes it. Not really terrible but as someone pointed out, quite jarring. I had stopped seeing it as jarring, but after reading a comment on a video I realized, in fact, it was.

This is probably something I need to fix, one way or another. It breaks continuity in a fairly major way.

But I made a bad decision. I wanted to make the screens "slide". If you've played the original Legend of Zelda, or the SNES version Link to the Past, you know what I mean. I thought this would be a nice retro effect, and provide good transition.

But there were problems with decision:

Problem One: * vs. 1

First, the game engine was built from the very start to assume there is only one "area" live at a time. This was in order to simplify implementing many things and to remove many design decisions that would otherwise have to be made. As well, it gives the player a nice sense of "concreteness"; the game is divided into discrete areas, so they have a good sense of where they are.

Allowing for a slide transition meant I had to jerry rig the engine to have more than one area open or "live" at once. This was problematic, though I eventually did actually get it working. Not a total hack, but far from elegant. And it had (as you may expect) some unforseen consequences that would have required perhaps some painful fixing, for example there were lighting and "noise" seams between areas.

Framerate also dropped off significantly during the slide transition, because we're rendering more than one area at once. This sort of negates the benefits of sliding, since the framerate becomes chop-city.

Problem Two: Coordinates

The other problem had to do with the camera, and coordinate systems. Again, stemming from the fact that I only wanted one area open, everything is coordinated relative to the current area. Changing areas means recoordinating: the camera now needs an offset, we need to know where the player should be relative to each screen, etc. etc. Ugly!

Solution

The first part of the solution was to dump this idea, which I happily did. I needed to recognize why I had made a bad decision, and cut my losses. It's not just that it was difficult. It was difficult BECAUSE it conflicted with other core design decisions made for the game.

The second part is to come up with a replacement that will not be so disrupting. In this case, I need some element to create a sense of continuity. That element, it turns out, will be the sky.

The sky right now during the daytime shows just blue (at nighttime it shows stars, which is good). My plan, not yet implemented, is to have clouds going back and forth on the sky. I will then have a nice faux-reflective effect on water surfaces which shows this sky. The effect is overall somewhat trippy, since the sky is visually "below" you (rendered underneath the terrain, along the edges) but in reality represents something "above" you. It was a cute idea when I had it and a great one.

What I'm going to do is put animated clouds on the sky. These clouds will blow back and forth peacefully creating a nice sense of place. When I transition between areas, I will wipe not the entire screen but just the terrain/area etc, so that the sky shows beneath it. This way, we get a greater feeling of continuity without violating the core mechanic.

Later, I can update it to also show the player (a bit tricky, but it should be possible), and the effect should be complete.

Conclusion

Don't give up on solving problems that need to be solved, but cut your losses when you realize you've made a bad decision.

Games are funny. Or at least it's funny how my game development tends to go. I tend to get some core mechanics in very, very late. In fact, usually I get death itself in very late. Hmn.

Anyhow, I need to implement dying, since I've now got a slime burning status effect. This is what happens if you pick up something that is slimy or maybe if you step in slime, I don't know.

If you stay slimed for too long, you'll die from sliminess. I don't know exactly what causes the death but it's sort of an acid-burn type thing.

Death Mode

This leads me to my next observation. I need a separate play mode for death. A play mode is basically a very broad level control. Title screen is a play mode. Explore is a play mode. That's about it. Everything in the game takes place in "explore" mode, which shows the map, lets you walk around, etc. etc.

Title shows the title screen and helps you with menu options.

Death shows your death screen. I could maybe re-use title playmode for it but, somehow I don't want to. I'm not sure why.

Rather than call it, Death, however, I decided I would like it to be more generic. So I'm calling it "story" playmode. I will structure it more around telling a story with text and pictures than navigating a menu and saving/loading games.

Other than that, I'm not sure yet. First iteration I guess will just show some text about your death.

I need to implement the sleepiness status effect. This will cause you to doze off periodically, if you don't take a proper nap. What it falls to me now, to do, is implement some kind of appropriate visual analogue for being sleepy.

What I want is to have sort-of an "eyelid" over the whole screen. As you get sleepy, the eyelid should start to close, eventually blinking periodically until it closes completely and you get a "you fell asleep" message.

Not too hard, but what's the appropriate way to model the eyelid effect?

We could just use a sum of sine curves of different phases/rates, and use that to determine how open or closed it should be. We could use a bit of a function on top of this to make it tend to fully open or fully closed, or to a few levels of open-or-closedness. Or some kind of holdness counter, where we hold our eyelids for X seconds at the current sine level, then change them and reset the holdness counter.

Hmn, I thought this was going to be a long post about some kind of model for fighting to keep your eyes open, but I think this may just be simpler than I thought.

Update

Hmn, this LJ post didn't go through the first time. Anyhow, sleepiness now works splendidly. Your eyelids droop and eventually you just nod off. You can also sleep in beds (much better). Voila!

Here's a quick update. I've been blazing ahead full-tilt for the past couple of weeks, making excellent progress.

Chief thing I've been working on most recently is fleshing out the castle. This has been great fun. I've fixed bugs, reworked and generally just added a humungous-chinese-vaseload of detail. Good fun!

Opening Doors for NPCs

One of the more interesting problems I tackled, something from my TO DO list, was to make NPCs open doors. There were two obvious solutions:

Solution 1. Make it part of the NPC control code. When an NPC is going to walk through a door, make him stop, open it, walk through, close it, and then continue.

- Pro: Fairly lifelike, this is how we interact with doors.
- Pro: Same rules that player plays by, thereby bringing the player further into the world.
- Con: Requires managing the NPC control code, which is already fairly complex.
- Con: Requires adding additional code relating to pathfinding, to detect beforehand if we're about to go through a door.

Solution 2. Make it so that the NPC has a sort of sensor, that when they are on top of a door, open it automatically, and once they pass through, close it.

- Pro: Better than having the NPC go through the door magically, like they do now.
- Pro: Requires no prediction, which is a help
- Pro: Can implement it as a simple "add on" to the NPC control code, doesn't have to modify existing code. I.e., it can function orthogonally to the rest of the NPC code, for the most part.
- Con: Not very lifelike, as the NPC will not stop either before the door or after. Gives more of an effect of an automatic door than of the NPC opening it themselves.
- Con: Different rules than the player. The player will definitely notice that NPCs don't interact with doors in quite the same way.
- Thought: Maybe that doesn't matter too much; there are other ways that NPCs don't really interact with the environment, e.g., they don't pick up and carry items, solve problems, or whatnot.

I chose Solution 2.

Solution

Funny, but Solution 2 has more pros, so I guess in some ways it's not too surprising that I chose it. I guess it's partly surprising because I have been fairly dedicated to taking the highest *quality* solution for the past little while, not always the cheapest. This is I guess because Texas is well-enough designed that I can afford to, and it's been enjoyable.

That's where we're at! I'm adding status effects for the player, as they have been on my TO DO list for a long time, and they are pretty high priority (they are a core gameplay mechanic, that so far is completely absent). Hoorah!