Monthly Archives: June 2009

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 50×50 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! Continue reading →

Woah, I just found out! Not one, but two games by Ludum Dare people have been re-released on new platforms:

Mind Wall for iPhone – Remember that really creative game that one the last full Ludum Dare competition with the theme “Advancing Wall of Doom?” It’s now on iPhone, with new … Continue reading →

Woah, I just found out! Not one, but two games by Ludum Dare people have been re-released on new platforms:

Mind Wall for iPhone – Remember that really creative game that one the last full Ludum Dare competition with the theme “Advancing Wall of Doom?” It’s now on iPhone, with new … Continue reading →

Over the last weekend, Mini-LD #10 was on over at the Ludum Dare website, this time with the theme of Domestic Violence. Mini-LD is like a regular Ludum Dare event, but without rating and voting and all that jazz – the creations are just made and shown. I didn’t participate … Continue reading →

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. Continue reading →

I gave myself half an hour to try something for Klick of the Month Klub #24.
It didn’t quite work out, but here it is anyway:
Windows (1.3MB)
Linux (1.3MB)
OSX (1.3MB)
Continue reading →

This will be on your Dumb Page. I mean, come on. That could be the entire website and it would rule.


By the way, I am sending this over my fabulous new wireless internet! No more satellite for me! Actually, this has its flaws to be sure. I’m getting massive lag spikes (5-10 seconds each) at random, quite often, and every so often, a web page will fail to load (I even got kicked out of WoW once!). But between those problems, it’s like a dream of a wispy cloud on a Summer’s day. I’ve gone from 2500ms ping to 25ms. A hundredfold improvement is alright (okay, usually it’s more like 100ms), when it’s not spiking me in the face. I’m not yet positive this is actually better, but a lot of the time, it sure feels nice. Continue reading →

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. Continue reading →

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! Continue reading →

Like I said yesterday, I am sick of the chat kicking people out! I think one of the major causes of the demise of our chat is that people can’t lurk in it for long without being unceremoniously dumped out. Incidentally, it’s not supposed to do that, but their tech support could offer no help that fixed it. But that’s okay, because Hamchat fixes that and a lot more!

Hamchat is the glue that holds the entire new site together. It’s a small chat window, which lives at the bottom of every page of the site! You don’t log into it, you’re always in it if you’re logged on. Guests can see it, but not chat themselves. So first off, there’s chat – a permanently functioning chatroom that won’t kick you out no matter how lazy you are. Second off, it’s always there – wanna chat, no matter where you are? Scroll down! Thirdly, everybody’s in it, so there’s never a shortage of chatters (well, maybe late at night there is).


Fourthistically, and this is where it becomes glue, it’s not just chat! The Hamchat is like the in-game chat in your favorite online game (okay, I’m thinking of WoW). When your guildie gets an achievement, the WoW chat says “[Zandero] has achieved [The Golden Amazingness]!”. Guess what happens at Hamumu when someone earns a trophy? Trophies are just part of that, though. There will be many other events chronicled going on. New member signups, maybe posts you’ve chosen to subscribe to (just thought of that, how intriguing! Maybe tough to code), webgame-related things, and things you don’t know about yet. Hamumu Clubhouse is an MMO. Continue reading →