Game Design Kitchen

Geography: Where It's At

Tue, 30 Jun 2009 01:25:42 GMT

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!

When to Cut Your Losses

Mon, 29 Jun 2009 03:35:04 GMT

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.

At last.. IT IS TIME TO DIE!

Thu, 18 Jun 2009 02:10:03 GMT

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.

Sleepiness Status Effect

Thu, 18 Jun 2009 02:04:05 GMT

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!

Progress, NPC Doors

Sat, 13 Jun 2009 12:02:05 GMT

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!

Models, Water

Mon, 08 Jun 2009 06:29:02 GMT

Success from Yesterday

So it turns out my idea for the sticklike property was indeed quite awesome, and turned out well. I ignored the issue with "dips" entirely, it's an edge case and I'll wait until I get some legitimate in-game situations that look disturbingly bad before I address it.

This one shows sticklike containment:

What you see here:

- Player is carrying a mop (sticklike)
- Another mop is contained in a giant yellow vase (you see the handle)
- Smaller vases on the ground
- Each smaller vase contains a smaller flower (sticklike)
- Another smaller flower is on the ground between the vases, automatically laid on it's side (sticklike)
- Player has his underpants on the outside.

Systems vs. Models

There is a real difference, to my mind, between a "system" and "model" in game design; though it's something of a continuum between the two.

A system is like a set of rules that you envision for the player to exist within. So for instance you have HP for life, MP for magic; if you run out of HP you die, and MP you can't cast spells. Within these basic sets of rules you introduce new rules: if you have the Cure spell, then you can cast Cure and recover 25 HP for a 5 MP cost. And so on.

A model is just a system whose set of rules that fit together naturally. Since our definition of "naturally" is going to vary a lot, so does the definition of model. But let's examine it.

MP and HP

In the above example, you might introduce rules for bodily and mental sleepiness. When you sleep, you recover MP (your mind rests) as well as HP (your body rests). You might also sit down and rest for awhile, e.g., if you were reading a book to study a skill in an RPG, but this won't recover MP, only HP. Now we're leaning towards model; the rules are starting to fit together naturally.

As we add rules to a model, we should think about ways that they would naturally fit together or interact. If we add a rule for poisoning, we should think about what that poisoning will do to not just HP, but MP. Maybe while you are poisoned, your maximum MP is cut in half to simultae adverse confusion effects due to feeling sick. Or, perhaps, your magic skill reduces temporarily for the same reason.

A Better MP

The trick is, some sets of rules might fit together better than others. In the above example, we aren't sure how to represent the mental effects of being sick in our given set of rules. Perhaps MP isn't the best model for mental energy, then? A better model might be mental strain. As you stay awake, this increases bit by bit, and when we cast a spell, study something, etc. our mental strain increases greatly; up to a point. If our mental strain is too high, casting a spell is less likely to work, or work well. Resting might reduce our mental strain somewhat, but only to a point; we eventually need to sleep. Lastly, as our mental strain increases a lot (e.g., if we were forced awake for 48 hours) we could start to hallucinate. Being sick with poison would increase our mental strain by a set number of points as long as we are poisoned, since we're constantly thinking about and feeling sick.

This illustrates the difference between a "system" and a "model". Mental strain is a model; things fit together more naturally. You could say it's a set of very simple rules that do a better job of capturing real life than the simple MP system does. As long as we're at all trying to mimic reality, we'll find it easier to work with the mental strain model than the MP system.

Sticklike is a Model

This brings us to the aforementioned sticklike properties. The reason I implemented it, and the reason it works so well, is not because it's a good "system" for storing things. It works well because it's a good model for reality. It's based on euclidean geometry in a way that is mathematically sound.

It's not a full physics simulation. A full physics simulation can be very fun; the trick is to make sure that a) it can can capture the variety of effects we want to capture and b) it's not too difficult to structure gameplay around it. But by this theory, physics is a better model for reality, and so works more naturally in a game design sense, too.

Water Containment

What I realized this morning, was that I could fairly easily handle water containment, now that I have this model. The basic idea is that, we add a tiny bit of extra information to our model. First, for pointlike objects, are they a liquid (maybe in the future, how much). Also, for liquids, a liquid color would be useful (future? opacity).

For planelike objects (really, should be boxlike) we just need to flag if they will hold water or not.

With this information, we can make very slight modifications to the existing model in only a few places to allow jugs, etc. to contain liquids. Moreover, and more amazing, we can actually quite consistently show the liquid being contained.

Too Much Detail

I really shouldn't go into this much detail, but I do need to make notes for myself to read over tomorrow (the primary purpose of this dev blog, after all =)

We have already something called an areafiller. When we are creating the renderable object, we pass in an areafiller. This filler just takes two parameters, W and H, and returns a renderable object. The generator that uses the areafiller doesn't need to know anything about it, which is what is nice.

What we do is create a special areafiller generator which returns an areafiller that shows the contents of an object (items inside) and also calculates liquids. This already exists, and works marvellously; we just have to extend it to show liquids.

Net result is that for instance, if we open up a box we can see what is inside, no matter what we put in. So simple but it's very satisfying as a player. This will just be extended to show liquids, if we're containing any.

Net result, if you put flowers and water into a jug, it will figure out based on the volume of water and the dimensions of the jug, how high the water should come, and render it. It will also show the flowers in the jug.

Behaviourally, we also have nice effects. For instance, how do we fill a jug with water from another source? We just put it in that source, and then take it out again. A bigger jug will contain a smaller one.

We could also envision an object-to-object move mechanic, but that isn't implemented and might be overkill (though it might be more intuitive, and hence worthwhile).

The other thing we could do, is when you drag a jug to another jug, if the first jug has a liquid in it, it will pour the liquid in.

We also need some way to account for volumes. I think the most consistent, model-like way of doing it would be to specify the volume of the water in liters. That would work but I have to think whether I really want to. First step would be to have a liquid object have a fixed number of liters.

We need also to handle mixing. This itself shouldn't be too hard, as long as you can end up with swampwater at the end (if you e.g., mix things that we don't know what it should produce). I'll have to think about it, but this would be a worthwhile model/system to have in place.

Enough! Lots to think of, and we shouldn't implement this right away. These things should be mulled over for a day or two before we start to implement. But containing liquids is going to go in, one way or another.

StickLike Property

Fri, 05 Jun 2009 04:47:34 GMT

Most things in a game can be thought of standing up, with a base dimension and a height. For example a treasure box, it might have a 2x1 and be 1.5 high. These things are essentially "block like", they have effectively a 2-dimensional base. Since they have a 2-dimensional base, they can stand on their own.

Imagine putting a box inside another box. If the base of the smaller box is bigger than the outer box, it won't fit. Objects in Texas only turn in 1/4 turn increments, so we could try reorienting it one way but generally, it's an easy check.

Other things are small, for instance a coin. This is more like an object with a 0-dimensional base. We could think of putting infinitely many of these things into a containing box. They take up such a small amount of space, they can fit in any shape as long as it's 2-dimensional; it will never "not fit" and never fill it up.

Of course, you might notice we've skipped a dimension. And in fact, that's right! Some things can be thought of as having a 1-dimensional base. These are "stick like" objects.

The trick with stick-like objects is their unique topology when it comes to fitting into other things. Imagine a flower in a vase. The vase has a 2D base, and the flower has a 1D base. We can fit infinitely many flowers into the vase, as long as we tilt it up. Once it's tilted up, it has effectively a point or 0D base and so it will fit. But if it's on it's side, it has a 1D base and we can't even fit one in.

Now imagine a sword. We can put a sword into the vase, as well, as long as we stand it up. So a sword might be most interesting if we model it as a 1D object.

1D objects are also special in how they interact with the terrain and building surfaces. Mainly, sometimes they might lay down and sometimes they might lean on things. A sword looks quite natural leaning against a wall, as does a shovel, pitchfork. It depends on how long it is, how close it is to a wall, etc., as to whether it should lean against the wall or just lay flat on the ground.

We want to implement sticklike mechanics, for now. Boxes and containers with 2D bases will, for now, only contain 0D and 1D things. 1D things will stand up, and only fit if they aren't too tall for the container (i.e., they would tip out: imagine putting a really tall pitchfork into a vase-- it would tip it over)

This is the easiest part. The harder part is when they drop on the ground. What we want to do is calculate an appropriate "leaning" slope for each dropping direction. So they will have a position where they are dropped, but they will lean in one of four directions depending on the slope of the terrain/building.

Imagine a pitchfork. Call the fork end the top, and the other end the bottom. The bottom point, end of the handle, corresponds to where the pitchfork is dropped. Since it has a 0D base (as it's a 2D object) it will fall one of four directions. The algorithm for placing it could therefore look like:

1. Pick a random direction to fall.
2. Calculate the fall mechanic.

Step 2, to calculate the fall mechanic, will depend on how long it is. But basically, we would start with a slope = 0 (i.e., laying flat) and iterate per-block over the length of the pitchfork. Each block we encounter that we'd be intersecting (i.e., if it fell in the direction of a wall or a table) we would re-calculate a larger slope, and start over. We start over because the slope will affect how many blocks we need to iterate; when the slope is 0, we iterate the most number of blocks; if it were possible to be standing perfectly straight (slope inf) then we would not iterate any.

Once we can iterate the whole length of the pitchfork, we have the final slope. This doesn't take into account center-of-gravity issues, but for now, let's ignore that. We'll just assume there is a lot of friction at the bottom end of the pitchfork, so that if it leans against even a short box, it will still have the bottom end touching the ground (versus tipping over the box). We could, however, probably take that into account without *too* much difficulty, by changing the initial Z position that we iterate from.

Once we have this algorithm, we can choose a "resting slope" for the pitchfork, and it will appear to rest on the ground naturally where we dropped it.

One more thing remains, which is we can make Step 1. a bit smarter. Instead of choosing randomly, calculate the resting slopes for all four possible fall directions. Let's assume the player is a bit smart. He knows in advance how the pitchfork will rest, just as you or I would, before he sets it down. By default, he wants it to be standing up, since it's tidier and easier to reach in the future. So if there is a resting angle that is "standing up", i.e., high enough slope, then choose it.

Otherwise, he doesn't want it to be resting in a way that, as per our final note on Step 1, would result in in with a weird center of gravity issue (e.g., he's not going to lean it against a short box since he knows it will slide off). So if that's the situation, choose whatever direction has the flattest slope.

One final note. What if we drop it while standing on a short box, or something? Well in this case, it's fine, the slope will be negative but the general rules still apply, more or less. In this case, there won't be a way to "stand it up" at all; so choose the flattest (minimum of absolute value of slope) slope to place it. We just end up with a negative resting slope.

In fact, a negative resting slope will cause us to appear to poke through whatever we're resting on, but we can fix that by incrementing our position artificially by whatever direction we chose to fall in, * 0.5 blocks.

VOILA! This is kind of complicated, but something I've been wrestling with for awhile, and today it sort of came to me how to solve it. So I wanted to write it up before it was lost.

Set Pieces, Backstory

Wed, 03 Jun 2009 06:32:07 GMT

I've started to add some backstory, and some set pieces to the game.

Also on YouTube

Since the castle is a tourist destination, it makes sense to have informational signs in each room explaining what the historic role of the room was and supplying some interesting facts. These facts are purely made-up and fake, tee hee.

Moreover, these signs are setting-space for inserting important backstory details later on. For instance, the castle may or may not have been once occupied by a mad wizard. If that's the case, then we can make allusions to it on certain signs, the game design equivalent to literary foreshadowing.

Other signs just serve the purpose of making the setting more consistent, and adding humorous details for the player to chuckle at. If we do a really good job, we can create the effect of causing for the player the "I wonder what *that* sign says".

A set piece is some visual resource that exists in only one place. These seem a bit expensive to make: for instance, the set piece I most recently created was a suit of armour. It took around two mornings to put together.

What a set piece does I think is help to create a bell curve for uniqueness of game visuals. Graphics in a game will usually repeat many times, and the player will notice this (of course).

Now imagine, for each graphical object of type T, it appears N times somewhere in the game. We look at all objects of type T and count their N instances, and create a graph using it.

If every object appeared 50 times, we would have a flat curve. My theory is that this is unnatural. I think in the real world, objects occur according to a bell curve. So for instance, some objects are relatively plentiful (these exist at the center of the curve) and some are quite rare (these exist at the ends of the curve).

If we tailor the repetition of objects to a bell curve, this will more closely match yours and my day-to-day experience with discrete objects in the real world. Laptops are more rare than leaves, but not so rare as an ancient ruin or as Ankor Wat (which is more like a real-world set piece). Houses are fairly common, but again not as common as leaves.

When you get to grains of sand, you could say they are so common that they break the bell curve, but we don't normally perceive them as discrete objects. Instead, we group them into beaches or maybe conceive them as handful-sized-lumps, in which case they probably fit somewhere in the same realm as leaves, rocks, blades of grass, and that sort of thing.

Let's Talk: Episode 1

Mon, 01 Jun 2009 07:19:33 GMT

Aha, here it is! Episode 1 of my video blog:

Let's Talk Ep 1: Bouncing Deer on Vimeo.

This is a bit of an experiment, a bit of a promotional thing, and a bit just for the hell of it. I want people to know about my game, obviously, but I want to have some fun with it too.

Lessons learned:

- Camera footage looks kinda very bad, better find a way to fix it
- Need to come up with a more homogeneous way to record my voice
- It takes a long time to make but not too long
- A simple script and some planning helps things along wonderfully
- A little music, even used without permission, can make a big difference
- Microsoft Movie Maker is actually totally awesome, but use simple (read: no) transitions for the best effect and just plan out your scenes/sync your audio cuts a bit.

Inspiration:

Behind the Dumb by Hamumu and the Wolfire blog.

Website, Video, Hamumu, Objects

Wed, 27 May 2009 00:08:11 GMT

First off, I've made a first gameplay video and finished revamping my website. You can see both of them here:

http://www.kittylambda.com

I think that I can't continue to separate game development from game promotion. I think I'm going to do some kind of video blog, because I've really enjoyed Hamumu's Behind the Dumb:

http://hamumu.com/behindthedumb.php

However, I've spent most of the past week working on this stuff, and I think it's now time to move on to other things; namely actual game development. I'm going to start off by changing the deer animation and then start adding some more game objects, like a suit of armour for the east hallway and maybe a chandelier or two.

BeautifulTimer

Mon, 18 May 2009 01:50:09 GMT

Now let me tell you about BeautifulTimer; this is (close to) the best way I've found for doing game loop timing.

First, you (of course) split your game logic into update (T) and render () sections. update (T) controls all game logic and animation state, and T is an input variable representing elapsed time since the last frame. render () just draws things to the screen, based on the current game logic and animation state.

Timer Type 0: Type 0 game loop timers are those that ignore or don't have the T-parameter in update (), and don't have any special waiting cycles. This can be effective I'd imagine on very specific hardware, but it's problematic for two reasons. i) if the hardware is too fast, the game will run too fast, and ii) if the hardware is too slow, the game will run too slow.

Timer Type 1: Type 1 game loop timers are where you have an additional wait () method in between frames. The idea is simply to figure out how long it's been since the last frame, and wait long enough. Think of this as a fixed frame rate timer. Given that ii) above isn't a problem, then using this the game will run at a constant framerate. In this situation the update (T) does not need the T parameter; each time it's called, you can call update with the same value for T since the same amount of time (ignoring ii) has elapsed.

Timer Type 2: Type 2 game loop timers are where you now call update (T) with a T value containing how long has elapsed since the last frame, and where you have a wait () method as in type 1. This takes care (ostensibly) of i) because you wait () to make sure that the game doesn't run too quickly, and ii) because you're updating game logic with larger timesteps: the player's brain will fill in the details.

Most game developers will be familiar with all of these types of timers.

There are some problems with Timer Type 2, that cause many developers to revert to using Timer Type 1 and trying to optimize their code enough to avoid ii).

Problem 1: Physics and other game code becomes unstable/unreliable with large timesteps. As the game takes longer to process each frame, the gameplay can completely go off the rails: stuff can fly through walls, oscillating relationships can explode, and so forth. You don't want a game where on a slow enough machine, the player can just walk through walls or past the final boss, or where the player can't swing his sword because it causes a floating point error. Eew!

Problem 2: Coding everything to relate to parameter T can be a chore. This might be true, but I actually don't think so. When you code logic updates without T, you are thinking in terms of frames. This is an additional calculation for your brain to make to create a very good intuitive guess as to what game behaviour should be. For example, do you want the NPC to stand and look at the wall for 1.5 seconds, or 90 frames?

Parameter T is always present, it's just that if absent then it's implied to be the time for one frame. And, well, you can teach yourself to think in frames, but I think seconds might be a bit more intuitive. And coding relative to a floating-point time value might make some code easier to tweak.

This bring us to BeautifulTimer.

First, we observe that if we just clamp T to a certain range, say to a maximum of 1/10th of a second, we can avoid many "exploding" or gameplay logic errors. How big MAX_T can be is a bit of an exercise, but you can always implement a debug mode with the largest-possible T and do your testing that way.

Second, we observe that often the render () code is why things run slowly. When the camera pans out, there usually isn't more game logic to calculate, there is just more to draw to the screen. Likewise, situations that cause the game logic to suddenly grind to a halt are probably things that have to be avoided or optimized away (e.g., a flock of enemies replicating exponentially will cause your game logic to stutter, but probably indicates a bug somewhere).

Further, the update (T) game logic code can often be optimized more easily than render (). You've always got to show a complete screenful of plants, buildings, people, monsters and items. You just can't normally leave any of them out (assuming they are supposed to be visible). But, you could tweak your spaceship AI code to only run half as often, when you discover using a profiler that it's a bottleneck. Easy.

What we do then, is allow to run update (T) more than once per call to render (), if T exceeds MAX_T. We still probably want to clamp this, i.e., only allow at maximum 3 or 4 calls to update (T) per one call to render (), and there might be more sophisticated ways to figure out where the bottleneck is, but that's the core idea.

So the final game loop using BeautifulTimer looks like this:

MinT = (1/60)
MaxT = (1/10)
MaxCycles = 5 

LastFrameTime = TimeNow ()
loop:
   
   -- handle the waiting; make sure the game never runs faster thna 1/MinT FPS
   CurFrameTime = TimeNow ()
   T = CurFrameTime - LastFrameTime
   if (Elapsed < MinT) then:
      WaitFor (MinT - T)
   LastFrameTime = CurFrameTime
   
   -- compute the number of update cycles so that we never call update with T > MaxT
   NumCycles = 1 + floor (T / MaxT)
   CycleT = T / (NumCycles)
   if (NumCycles > MaxCycles) then: 
      NumCycles = MaxCycles

   -- call update T the appropriate number of times
   for NumCycles times do:
      Update (CycleT)

   -- now, render to screen
   Render ()

That, my friends, is BeautifulTimer

Chiang Mai

Wed, 13 May 2009 02:25:39 GMT

Well, we've arrived in Chiang Mai, Thailand. So far, so good: this is an incredible city. Bangkok is the city of many tuk-tuk drivers and (unfortunately) many scammers. Chiang Mai is beautiful. Fortunately we were in Bangkok for only 3 days and we are in Chiang Mai for maybe as long as 7 weeks.

People here know how to cook. Anything. All food here is good. Incredible, actually. Michelle and I tried, but could not really like Hong Kong food (with a few exceptions; Chinese desserts are really fun, if a bit odd). But I don't think we've had bad food since we got to Thailand. Even the airplane food was good.

In Bangkok we saw the new Star Trek movie at a mall called MBK, which is a big shopping mall the kids like to hang out at. It was a wonderful experience! People in Thailand know how to have a lot of fun, and as a tourist if you can somehow avoid some of the traps it's a great experience all-around.

Now I'm set up and going to dive back into Texas a bit this AM. We'll see where I get!

Back in the Saddle, Yaa hoo!

Sun, 03 May 2009 09:53:26 GMT

So today is the first day working on The Real Texas since Ludum Dare 48H. Truth is, it drained my creativity a bit but also allowed my paid job to pile up (and I had a ton of work to do there), so I got a bit swamped between the paid job and doing touristy things in Hong Kong.

HK is really fun, and you should go here. The best part of Hong Kong is getting around, it's so easy! Buses go everywhere and are very affordable. It can be confusing and scary but it's effective. Anyhow.

I've mostly finished moving the sound engine over to C++. Still to do:

- Implement soundable_union
- Finish implementing soundable_sway

I think this might be the fifth or sixth time in some fashion or another that I've coded the sway engine.

Moving the soundable engine to C++ really actually did make sense; I guess it's just something that should be in C++. Should give me really nice framerate gains (unless the profiler was lying, which I don't think).

Premature Optimization? A great question. In some sense, you might imagine creating an entire game and only then doing your optimization. But I find in practice what works better is to optimize in cycles; otherwise your game may not "feel" right as you are developing it. Sounds kind of weak but, I generally develop until the framerate seems stuttery, and the optimize until I get rid of whatever issues have cropped up.

THATS ALL FOR NOW, FOLKS!

Going With Option 1

Wed, 15 Apr 2009 05:12:03 GMT

Well this is a revision from two posts back. I implemented the simulation code the way I planned, and the glue, etc.; but the trouble is there are tens of thousands of calls to the code that links the simulation to the lua code. It's messy.

I don't know if the simulation code itself is, after all, going to be useful. But I have decided to take the soundable () class out of lua; the basis for putting it in lua instead of C++ was that it was simple enough and wouldn't suck up any CPU. Well, the profiler is telling me that no matter how I try and slice this one, it's sucking up a lot of CPU. So out it goes!

Save Points, Zelda 1

Wed, 15 Apr 2009 01:21:31 GMT

Here's a trick for you. You've got a large world that can be explored in a nonlinear fashion, and you don't want the player to have to walk that same stretch of ground over and over.

In Zelda 1, you always started the game on a certain screen in the overworld, or on the first screen of a dungeon in the underworld. This had the effect of making the overworld like a giant, "loose" level: when you were in death mountain area, you were a long ways from that first home screen and so you didn't want to die. This made sense because Zelda 1 had lots of enemies roaming the overworld, which got more difficult the further from "home" you went.

In the dungeons it made even more sense because they played out even more linearly: by the time you got to the final boss you had braved many dangers and wouldn't want to have to go back to the start.

*** Digression! ***

You remember how you'd always start out with three hearts? At the start of the game, you'd only have three hearts in total anyhow, so no big deal. However by the time you got to the middle section of the game, three hearts wasn't very much. The first thing you'd always do was walk to the fairy so you could get refilled. When you were tackling dungeons, you had much the same problem. You'd die, and warp to the start of the dungeon, but good luck tackling it with only three hearts! So you'd have to go to a nearby fairy spring. And maybe even buy healing potions, a lot of preparation!

Zelda 3: LTTP (the SNES one) fixed this dungeon-hearts issue by putting fairy springs in the dungeons themselves. A nice twist!

What's interesting to me is how similar this problem (situation? mechanic?) is to what we see in a shooter like gradius, where your weapons power up as you play. When you die you start back at the last checkpoint, but good luck making it last without your weapons. In some shooters this becomes a crippling problem for the player, so that the game almost operates in such a way that you have to play certain large sections without dying, or else you're stuck.

In the case of Zelda, it isn't so severe and so it's OK. I still think it's a little bit arduous, visiting fairies and collecting heal potions, but it has the upside of creating a higher level of anticipation for your dungeon-dive or boss-fight or whatnot. For shooters though, it's really a gameplay design bug similar to a game where you can save at such a place/etc. that you can't beat the game and have to start over from the start.

*** End Digression ***

In Texas, I need to prevent the player from walking overland too much because there isn't supposed to be any particular challenge to the overworld, at least most sections. So if you quit or die, where should you re-start?

I think there are sections of overworld that will play out like in Zelda 1. There is a bridge that you cross and on the other side are monsters. But for the peaceful areas, I think you should restart at whatever screen you last entered. Since there is no special challenge or obstacle in moving from area to area here, you should just start where you left off.

This is fairly easy to implement, which is a nice side-effect. So in most areas it will auto-save when you enter the area, but if you're north of the bridge or if you're in a dungeon/etc. it will save only at designated checkpoints.

There are some other design choices to make there but they probably aren't too hard!

LuaProfiler, Simulation

Mon, 13 Apr 2009 00:56:33 GMT

Hello! So I'm working from HK which means using the wife's laptop. What I discovered once getting Texas to compile for windows is that it doesn't run as quickly on her machine. Naturally, thought I, It's a graphics card related problem. Reason being, my Sempron 2800 CPU can't be faster than Core2 Duo, right?

Always remember that laptops are underpowered, flaky, and stupid.

I ran the profiler and it turned out that a lot of time was being spent in lua_pcall and the like, which meant that the lua code was sucking all the time. So it's not a graphics related slowdown, it has to do with the CPU. I downloaded LuaProfiler and figured out how to get it to work.

The trick with LuaProfiler is that a) it only gives you function names, which is a pity e.g., when you have a class heirarchy like classname:update (T) it will lump all the update () functions together and b) it doesn't give you a call graph. The call graph you can work around by searching your code and cross-referencing but separating out the lumped-together function names is a hassle. What I do is for each class's update (T) method, I peel it out into classname_update (T) and have classname:update(T) call self:classname_update (T). This is sort of labor intensive, adds a certain inefficiency on top of what's already there, but it works.

Anyhow what I've learned is that a great deal of time is spent in my lovely "sway" simulation code, for sound effects. Yeargh! This is a bummer, and I think the only real way to get it to work efficiently is to peel the code into C++. There is probably a workable hack but it doesn't feel right.

The question then, is what code should I peel into C++? I actually run sway simulations in a couple of places. Once for renderables (visible elements) and once for soundables (audible elements). However, the renderables are all in C++ and have appropriate glue to link them with lua. For soundables, I put them into straight lua and this it turns out is much nicer to work with because it lacks the glue. Only in the case of this sway simulation has it caused a problem, because whereas with the renderable the sway code is all C++ and runs instantly the lua equivalent is sucking up a lot of CPU time.

Option 1 would be to rip out the entirely soundable stuff from lua and make it C++. This is kind of an ugly option because of the amount of code it probably will end up touching. As well, it would be a lot of code to convert from lua to C++. The nice part is that it would solve the efficiency problem quite neatly, and probably give a meaningful efficiency gain for other parts of the code, as well.

Option 2 is to take an create a special "simulation" class hierarchy. So what I would have is an abstract "simulation" class where you'd be able to create different simulations (right now, I'd just have a swaying one) and then glue them into lua, e.g. with an abstract push_lua_state (L) function that creates a lua table on the stack to return. The sway soundable would then create a sway simulation and just read the appropriate parameters to determine if it needs to play a sound.

Option 2 on the surface seems clunky, but I think I will go with it. There are a couple of reasons. First, there are the problems inherent with Option 1 above. But second, Option 2 is actually more forward-looking.

What I'd like to have in the future is actually less C++ code with more general glue. That will probably necessitate some way to take code from lua and put it into C++ when there are real efficiency problems. Pursuing this pathway might help me to see what a good way to do this is, for future projects. There is the added benefit that I might need to move other lua code into C++ later on, and I'd then have a framework in place to do it.

Hong Konging it With Windows Vista

Tue, 07 Apr 2009 22:51:06 GMT

Hey everybody!

I'm in Hong Kong now, in Sai Kung district. Staying with some friends here, what an amazing place. This is the greatest city I've ever seen, and I've seen 4 or 5 cities! Even if I see more, however, I have a hunch this will stay as the greatest. It's a wonderland.

Anyhow, while I'm here I'm working on my wife's laptop. So naturally, I've loaded the poor beast up with about a zillion different developer applications and indie games and have just yesterday set to getting Texas to compile on Vista.

Hooray for Mingw32, I have it working. There are a few issues, but they seem to be graphics-card related (It's Intel 945G, which is the same card that Venture the Void never seemed to want to run on.) This is a great opportunity for me to increase the compatability of Texas and also maybe make it run a bit faster.

My plan is to keep working while in HK, both on Texas and also my real paying job. This vacation will last 3 months, 1 month here and 2 in Thailand. Here is a picture I took of the village where we are staying:

Replays

Fri, 13 Mar 2009 15:16:19 GMT

One of things I am wanting to do with Texas is allow for replays. This is purely for testing purposes, or rather, for evaluating how people are playing the game. I want to be able to see in beta test where people might be getting stuck, what might be confusing, etc.

To that end I'm putting in a replay capability. The idea is just to record all the keyboard and mouse input as well as frame timings, etc., and then save to a file. When the game is loaded, you can indicate a replay and watch what the player did. I'll have to make sure that the random number seeding happens in sync as well, i.e., it's recorded in the replay or it's determined at game start so that everything makes sense.

I guess the place to start is to ask what needs to be recorded? Right now I'm thinking that initial save game state, frame timings, keybord presses and releases, as well as mouse clicks and releases. When I replay, I will have to populate somehow the mouse position and keyboard state array as well as send the events that are read from the file.

It's a pretty involved feature but I think in the end it will be more than worth it, to watch people play the game and see how it's unfolding for them.

Success with cutscenes!

Fri, 13 Feb 2009 00:02:09 GMT

Here's the final solution:

- A cutscene class (in lua) that includes some handy methods and mostly automates cutscenes
- Derived classes for each cutscene, or each type of cutscene
- Don't think "cutscene", neccessarily, think "event"
- There is also a cutscene manager that handles adding cutscenes to areas, etc.

This leaves a fairly lightweight footprint for implementing cutscenes. For instance, I have implemented a "cutscene_forgothat" type but this could actually be a generic one that takes three parameters: the place name to trigger, the text to say, and where to walk the player to. Then I can create these in the cutscene manager as much as I want and have the inserted and triggered into the game.

The actual cutscene drone works much like the spellcasting sequences, with an additional tweak for the "event" dialog, which in the end was just a simple thing that pops along the bottom to show the text, with a "more" and "OK" button.

Here is the sequence for forgetting your hat:


Seq = {

"@Something's not quite right.<p>England's bright, orange sun glowers itself hotly upon your brow.<p>...<p>Your hat! How could you have forgotten your hat?<p>It strikes you that it would be foolhardy to attempt serious tourism without your travelling companion. Your hat must be in the car.<p>If you searched the back seat, you might find it.",

drone_wait_event_dlg (drone_faceplayer ()),

drone_moveplayer_to_place ("cutscene_forgothat_backoff_parkade"),

function () self:retrigger () end

}

Cutscenes. Argh!

Mon, 09 Feb 2009 23:25:49 GMT

For games that are strongly story-driven, the cutscene can be nearly ultimate. For me, to implement, they are ultimately annoying. I've never had much success implementing them; it always feels awkward.

In VtV the cutscenes were just pages of white text on a black screen, not too interesting but probably fit the game.

To me the essence of the cutscene is that the player isn't in control anymore; they are a passive participant. If a game were all cutscenes, well then it wouldn't really be a game. But if you are desperately avoiding them, then the game may seem awkward at times, because you aren't using a tool that should be available to you and is sometimes (to me) the most obvious way to tell a story.

So I've got the initial tutorial area and one of the things I'm trying to teach the player is how to equip clothing. To that end, they are going to want to put on their hat. My idea is that when the player (Sam) goes outside, he will remark that he feels naked to be outside without his cowboy hat. This is a bit artificial, to be sure, but I think it's acceptable.

The best way, it seems to me, to accomplish this is a cutscene that is triggered when the player first steps on a certain area. But immediately there are so many problems! For instance:

1- How do we detect that this cutscene should be activated? Of course there will have to be some code. My best idea is to have a global drone (AI module) which scans some kind of cutscene database and activates them as needed. I can use the existing place system, so that I can do some in-game editing to create a place (or places) where the cutscene happens, and then walk the player around using the cutscene itself. And that's my simplest idea.
2- How do we show the character (who is a silent protagonist) talking to himself? I don't have a system in place to really address this. For instance, the UIs are all centered around talking to other people, and interacting with other objects. There is no UI for just simple talking. I need to create a UI for the tutorial hints, so maybe I will be able to re-use this one?
3- How do I easily test them? For the most part they are going to play only once, and set a flag so they know not to load. I guess I can add some kind of "debug" flag to the cutscene database that will make them happen over and over again. But this seems tedious.

There are more problems, to be sure. But I guess I have a starting place. I'll need an AI module to detect and activate them, some kind of generic dialog box that can just describe your thoughts or what's happening without necessarily allowing you to interact (as the normal dialog boxes do), and I'll have to keep in mind to create a system that makes them not too painful to test.

Planning for the Parking Garage

Tue, 27 Jan 2009 15:47:05 GMT

Probably the biggest lesson learned from Venture the Void is to make a game accessible. The gameplay itself can be complex and varied but the player needs to feel they can interact with the game in a natural way. I guess you can think of it in terms of the "third wall"; you want the player to mentally be in front of the third wall, i.e., on the stage. For that to happen the third wall itself (game controls and interface) should be as transparent as possible.

So I'm creating a tutorial area! A bit artificial in some ways, but by doing this I can be certain that the player understands and is aware of the main game controls.

This fits naturally into the scheme of things, as I had a parking garage laid out in maps and in the story but not in the game. It's the first area you encounter and you can't return to it once you leave so it's a natural place to start. First I design the area:

Once I've implemented the area visually and put some of the more obvious objects in, so that I can see how it will "feel", how do I plan the gameplay for it?

I make a dotfile, which is input for GraphViz. I start by laying out some of the things I want the player to learn, without connecting them:

learn_walk [shape=invtriangle color=red]; // learn about walking
learn_click_objects [shape=invtriangle color=red]; // learn to click things to interact with them
learn_click_keyword [shape=invtriangle color=red]; // learn to click on a keyword
...

The shape=invtriangle is visual language for "motivation" which is the most abstract sort of node. In this case I've used it for what I want the player to learn.

Next I put And I put lines for objects you can interact with, that I know will be in the parkade:

explore_parkade [color=red];
interact_samscar [color=red];
interact_glovebox [color=red];
interact_vendor [color=red];
pay_vendor [color=red];

In brief, you can explore your surroundings, interact with Sam's car, check his glove box, and interact with a ticket vendor. These are just unconnected ideas I have surrounding the parkade and is a natural enough place to start.

Next, though, I can start to connect them. For instance, you'll see Sam's car quite conspicuously as you explore the parkade, and in order to interact with it you'll need to learn to click objects:

interact_samscar -> { learn_click_objects; explore_parkade };

Later on, I introduce elements in order to fulfill a purpose: for instance I need the player to learn that in addition to clickable keywords, they can try stuff by typing. My idea then is after you insert change (found in the glovebox) into the vendor, it refuses your ticket. A window pops up suggesting you "kick" it, which you do by typing kick while you're interacting with it. At that point, it gives you a ticket (item_ticket):

pay_vendor -> learn_insert_item;
kick_vendor -> learn_type_keyword;
learn_type_keyword -> pay_vendor;
item_ticket -> { kick_vendor; pay_vendor }

In short, to pay the vendor you have to learn to insert an item into it (there is a drag-and-drop interface for this). To get your ticket, you have to kick it, which involves learning to type a keyword in. The arrow from learn_type_keyword to pay_vendor may seem mysterious, but all that it means is once you pay the vendor, I trigger the tutorial window explaining that you can "try sum'm" by typing a keyword in.

Finally, if you've paid the vendor and you've kicked it, you get your ticket.

The final dependency graph looks like this:

Can you hear the Wind in the Willows?

Tue, 13 Jan 2009 18:57:11 GMT

I've implemented the sway algorithm, and visually it looks about right. I ended up encoding a sway force with the object's physical representation (each game object can be attached to a particle, with position, velocity, and now sway force information). The sway force dissipates over time, rather than being reset each frame (which would also work).

However getting a matching sound effect to work is a bit more difficult! At first I had it set up so that when you walk into the bush, it triggers a sound effect (as long as one isn't already playing). This is ok, but the sound stops playing when you leave the bush even though it continues to sway. This is an event-oriented approach, basically; when you walk into the bush, play the bush rustling sound effect. One can imagine a moderately complex algorithm to let the sway sound effect play on repeat (fading out as it does so) after you leave the bush, but it feels complex and weird.

The next idea I had, was to tie the sound effect to the renderable. This turns out to be right idea, sort of. The model I adopted for sound effects in Texas was the idea of "soundable"; an object has a renderable, something that is drawn to the screen, so why not also a soundable, something that is played into the sound engine?

The secret is to create a new soundable type, called "sway", which bases it's behaviour on the same data that the sway algorithm is based on. Imagine the sway algorithm as a pendulum that moves across an axis; every time it moves across the axis, we want to trigger the sound effect. If we use, in effect, the same algorithm (this time in just one dimension) and trigger the sound effect for each time the pendulum crosses the zero line, with the velocity relating to the amplitude of the sample, it should create a good effect; moreover, when we add wind (which will, essentially just apply a "windy" sway force vector to all objects) it should create a natural sound environment that is tied to the gameplay objects.

Nice!

Now let's see if it works...

Sway, continued

Mon, 12 Jan 2009 17:56:03 GMT

The sway algorithm I had in mind seems like it will work well, but I'm faced with two problems:

1. How to communicate the sway values to the animator.

The sway occurs at a fairly low level, basically at the "rendering" stage. This is fairly opaque to the game engine itself, which just says "draw this". The rendering engine takes as a parameter a particle, which is supposed to be the physical representation.

I think the answer therefore might be to add a sway acceleration parameter to the particle. This makes sense because it's part of the physical simulation, even though it won't actually affect the position of the object.

2. How to introduce randomness into the animator.

Each swayable object has a few parameters that can be easily set at the start, but right now everything sways "together", since initial conditions are the same. What I think is that there is probably room for two sources of randomness.

First in the "snapback" factor which for each swayable object roughly indicates how stiff or rigid it is. This would naturally vary and for instance, with a tree, the trunk or lower level branches would have much higher snapback factor since they are more rigid.

The second place to randomize woulds be the input velocities themselves. If you walk through a bush, you maybe overall create a sway in the direction of your motion, but the shape of your body and the branches you are interacting with will be somewhat varied, so we can characterize this by just randomizing the sway variable slightly.

Polishing, bushes, longscreen!

Sat, 10 Jan 2009 20:39:38 GMT

For Christmas I got a stand that lets me turn my widescreen monitor to a vertical orientation. I have just one thing to say, that is, longscreen is long. It's pretty weird but you better believe it's awesome for reading the internet. Never could adjust to coding/internetting on widescreen, but longscreen I think I can get used to.

Seriously, it's ridiculously long.

How to polish a game? As you play you have to notice what's missing. For example, "there's no sound effect when I step on this", "the bush seems... dead", "I wish there were a bit of fauna around, birds and bunnies etc.", and so on including of course bugs. If you tackle these things as you run across them, you'll never get anywhere though because by the time you fix one thing you'll have forgotten everything else. So you need a TO DO list system. I use TADA List which is from a great internet company 37signals. It's just so darn simple.

Then you just relentlessly tackle things on your TO DO list, without fearing to add to it. It will get gargantuan, because polishing a game is about fixing a million tiny things. But that's how it gets done, as far as I can see. Don't think, just fix!

So yes, "bushes seem... dead". I want to make so that when you walk into a bush, it shakes a bit. There are other related features that could go with this, like a tree could sway in the wind, etc., but I'm not sure the best way to implement it yet.

My current idea is to add a method to the object interface that takes a motion vector. This could be used for a lot of things. Most objects wouldn't pay attention, but for trees it could be used to create sway by a simple wind simulation, and for bushes could be used as the player walks through them.

This approach seems a logical place to start, it seems a bit too "physics simulation-y" for my liking but it's not extremely complex. I guess the complexity is not so much in the interface but in the resulting animation/etc., which needn't be too bad.

Game Design Kitchen

Geography: Where It's At

Define "Area"

Greater Geography

Start With Setting

End Result: Believability

When to Cut Your Losses

Persistence is Key, but...

When to Stick To It

When to Cut Your Losses

Problem One: * vs. 1

Problem Two: Coordinates

Solution

Conclusion

At last.. IT IS TIME TO DIE!

Death Mode

Sleepiness Status Effect

Update

Progress, NPC Doors

Opening Doors for NPCs

Solution

Models, Water

Success from Yesterday

Systems vs. Models

MP and HP

A Better MP

Sticklike is a Model

Water Containment

Too Much Detail

StickLike Property

Set Pieces, Backstory

Let's Talk: Episode 1

Website, Video, Hamumu, Objects

BeautifulTimer

Chiang Mai

Back in the Saddle, Yaa hoo!

Going With Option 1

Save Points, Zelda 1

LuaProfiler, Simulation

Hong Konging it With Windows Vista

Replays

More Tutorial Nonsense...

Success with cutscenes!

Cutscenes. Argh!

Planning for the Parking Garage

Can you hear the Wind in the Willows?

Sway, continued

Polishing, bushes, longscreen!