Game Design Kitchen

Happy 2010 from KITTY*LAMBDA!!!

Fri, 01 Jan 2010 02:28:55 GMT

This Year:

This year was a great year for me, I spent three months in Hong Kong and Thailand, made excellent progress with The Real Texas and made a few different games: YOU GOT A DEMONWALL, Harry's Questival, and Hunters of the Northwest Passage.

Next Year...?

Next year I'm looking forward to more progress on Texas, playing some more great games and making new friends.

Happy Boxing Week

Sat, 26 Dec 2009 18:43:55 GMT

Ah, the holidays! Well I've been up to different things lately, took some time to work on Hunters of the Northwest Passage.

I've had some ideas about generating dialogue/stories in games ever since I finished Venture the Void and am taking some time to experiment with that in the context of my Ludum Dare game. I'm basing this on a system of context-transformations. What the heck does that mean?

How Do You Write Software That Can Write a Story?

What makes stories so interesting is the that we relate to them on a human level. Having a computer do this is daunting.

A good story draws on our emotional responses, understanding of human relationships, knowledge of both the world at large and everyday objects; everything already in place before a single word has been written. This is external context and it is shared between the teller and listener.

Then there are elements within the story: players with their motivations, actions, information. There are "internal external events", things that happen within the story to create interest such as a snowstorm. A good storyteller weaves events together believably to draw us into her world.

For a computer program to do this seems an impossible task. It needs to somehow be able to synthesize external context, together with the internal context of the story itself, and produce a result.

Chopping it Down

First, let's chop down the context as far as possible. Create a comparatively tiny external world that our computer program needs to know about. In the case of Hunters, that world is the sea; but even narrower than that, since we're only going to tell it from the point of view of the captain.

Imagine Star Trek if it were ONLY the little "captains log" narratives. Much simpler, but now maybe we have a problem that can be attacked.

"Internal external events" are actually the simplest things to handle in a computer program. Computers are good at simulating physical things, perhaps not realistically but convincingly.

So for instance we can put together a simple weather simulation with variables like the storminess of the seas. We can then simulate events such as the boat being swamped, men overboard, or freezing to death, based on this. We won't manipulate these like a master storyteller, instead we put the player adrift among them; the real power of a game world.

The Story Events and Context

So what's left is the external and internal context of the story.

We're going to get to external context through heuristics. These will amount to tons of tons of little rules determining things that can happen. I imagine hundreds of these, if not thousands.

So for instance, "if there are no apples, and crew member X really likes apples, he complains". Or, "if crew members X and Y are enemies, they get into a fight". And on and on.

As these events happen, we record them into the story context.

Describing Events

Internal context is the final layer, and it's the most artful. As we describe different events, we need to reference the story context. For instance, if we are describing that crew members X and Y got into a fight today, we need to reference back to what they have done in the past. The captain (our narrator) might then write:

"Jones and McVale have been bickering for weeks, it seems like. Today, maybe due in part to yesterday's apple-stealing incident (Jones loves his apples, damn him) it finally came to a head. Jones threw the first punch, and caught McVale in the gut. But the hardy Scot was not one to go down so easily, and countered with a solid kick to the groin. Jones may not have children, though it's doubtful any woman would take him anyhow. And well, that would have ended it, except Jones' brother Marcus then decided to have a go. He managed to wind the Scot and was about to kick his face in when I pulled pistol and told him to stand down. I won't have any more chaos on this ship than is strictly necessary. For now, Jones and Marcus are in shackles until they can cool it. But I need all hands I can muster, and can't be carting around dead weight in the North Atlantic."

We need to somehow get from an event like "Jones fights McVale" to the above.

A lofty goal.

And Now Back to our Regular Scheduled Programming

Today I'm back at work on Texas, though, which is really coming along quite well. I have a few more things to finish and then will do another playtest alpha version.

Happy Boxing Week everybody!

Adobe FlexBuilder Linux (Alpha 5) + Eclipse 3.4 Ganemede on Linux

Thu, 17 Dec 2009 17:14:32 GMT

I do all my game dev (almost) on Linux, using only free tools. Sometimes it's hard to get things working; as a Linux game dev you are in the minority so prepare to feel marginalized!

The result is well worth it though, since Linux is invincible and incredibly responsive compared to Windows. Windows feels so clunky after using Linux!

Today I installed Adobe FlexBuilder for Linux, so I could do Flash development with Flixel without resorting to my Windows Box. I'ts not fully tested yet but it does seem I managed to get it installed.

Here is how I did it:

(note: Eclipse 3.4 is installed for me to /usr/lib/eclipse)

Download FlexBuilder

You can get it at:

http://labs.adobe.com/downloads/flexbuilder_linux.html

And click Download Alpha 5 -> Download for Linux

Downloading from Adobe...

Run the Installer

It will ask you where you want to install FlexBuilder. Choose /usr/local/FlexBuilder as the installation folder.

Next, it will ask you where eclipse is installed. Choose /usr/lib/eclipse or wherever you have it.

You will get some warning that it doesn't know what it's doing, click the button that says "proceed with caution" (amazing!)

It should then try to install.

I didn't break my eclipse, but of course it didn't install properly either.

The Installer...

What it Does

Oh, adobe, with your ever lovin' propietary software and ridiculous installers. Anyhow almost every browser has flash and at least you aren't Microsoft, so we play your ridiculous game: but don't think that we like it.

The point is the installer OF COURSE fails; if Adobe really wanted this to work properly they would just have a normal repository like every other eclipse plugin.

It seems to copy some kind of configuration to /usr/lib/eclipse/configuration. Just delete the adobe stuff in there.

It also creates something called /usr/lib/eclipse/links; also delete the adobe stuff in there.

How to Really Install It

You should now have nothing actually installed to eclipse (i.e., you've undone the broken installation attempt that the installer made) but what you DO have is a FlexBuilder repository site installed to /usr/local/FlexBuilder.

So just start up Eclipse, choose Help -> Software Updates -> Available Software -> Add Site...

Then choose /usr/local/FlexBuilder/com.adobe.flexbuilder.update.site/

You should now be able to select the FlexBuilder components, which will then install! Hooray!

Installing from Eclipse...

Test It

Well I haven't tested actually building anything yet, I plan to set this up with SCons, but at any rate you can click:

Help -> About Adobe Flex Builder Linux

And see some kind of screen relating your trial period, etc.

Hunters of the Northwest Passage

Mon, 14 Dec 2009 16:50:15 GMT

This weekend I entered the Ludum Dare 48 hour game development competition.

These are a healthy break from my main line game development, since they give me a fresh canvas and let me try things out. I don't worry too much about winning although I do always try to produce a complete game.

Click here to Play

Flixel Hooray

This is my first completed flash game, made with Flixel. You can check out the source code if you want, the most interesting thing is the file CrewRules.as.

Flixel is a library for making games with flash. If you pair it with FlashDevelop and the free Adobe Flex SDK (not to be confused with Flex Builder, which is their IDE) you get to make flash games just like you would any other game.

Game Conceptualization

Something that I've realized lately is that I don't think hard enough about what goes into my games. I put so much energy into project management and technical things that I don't take any time to imagine.

Sounds cheezy, I know, but it's true! One day, all you can do is imagine all these types of amazing games you want to make, and the next day, BAM! Game Dev Myopia.

Fermata

I'm learning to pause. In music the silence is as important as the music, maybe more so. In game development, you chomp away at one million things to implement your ideas. But from time to time, you need to stop and really think about what you're doing, and what you'll do next.

This is much different than stalling or procrastinating, where you surf YouTube or Wikipedia and otherwise don't work. What it looks like for me is to go and sit down, take a cup of tea, and just close my eyes.

Really! I do this!

Thinking about Hunters

For Hunters, when I heard about the theme (exploration) I immediately envisioned it as a game mechanic; exploring caves or forests or whatnot. But what if instead I created a story-game based on historical exploration at sea?

The first night I didn't code at all, instead I just wrote a little design document outlining my ideas. I also had some time to let the ideas percolate before even starting that, because I was at a hockey game with my dad for the first few hours.

What I ended up with was a game mechanic based around managing your crew and ship.

The outcome is a game that is at least a little bit humorous, and should at least give you the feeling of being stranded in the Arctic Ocean.

Let's Talk Episode 2: TNT

Sat, 05 Dec 2009 02:14:51 GMT

I made another video blog. These are fun to make but a lot of work:

This one talks about TNT and making things explode.

I read something recently that sort of suggested you're better off spending one hour talking about your game, than one hour working on it. I can see that. Game dev is kind of arduous and time consuming. On the one hand, there is always so much work to be done that it's hard to imagine setting aside time for a blog post, etc.

On the other hand, you kind of have to make noise to get noticed. And getting encouraging comments is such a warm fuzzy, to use my 6th grade teacher's terminology.

Hiatus? No!

Sun, 22 Nov 2009 18:31:02 GMT

Wow. Three whole weeks have passed since my last blog post. Have I been on Hiatus? Resting on my laurels, p'raps?

No!

In fact the game itself is coming together quite nicely. I don't want to talk too much about what I've been up to, just that I'm blazing through this sucker at this point. Next task: implement CHICKENS.

Musing: Meaning in Games

Lately the question in games is how do we elevate beyond the status of "toy" to that of respect in the eyes of the culture. I don't have an answer, but it's certainly something I've been pondering on.

Movies, novels, etc. are all respected as being able to teach us something as humans, or to provide us in some sense with a spiritual experience. I think some games can provide us with a spiritual experience. Don't smack me, but sections of Mario 64 and Chrono Trigger were really amazing.

However, games don't do as well at reflecting the human experience. Why?

Musing: Novelists have it EASY!

A novel or movie can twist together a plot that, when we engage it, can be very revealing of human nature. Even "fun adventure" books such as Treasure Island can teach us something about ourselves.

They do this, I would argue, because they have the ability to trace through time a specific chain of events. The control of the novelist isn't absolute (if the actions of characters are not well-justified, we won't engage) but it's still very great. A writer can string together events ingeniously so that, just at the right time, we go: aha!

A game developer has a much harder time of this. Games so far have managed to attach stories, or broader context, sometimes with great results. But it rarely feels closely harmonized with what we'd call the "gameplay" of the game. Mainly it serves to make us want to keep playing.

So what makes the "gameplay" part of the game?

Musing: Cause and Effect

We talk about interaction but in fact, it's the ability to change things in the game world that really make games what they are. We are brought into a game because our own actions control it, and this fascinates us.

But this doesn't really hold for stories in games. Even if we are given choices that affect the outcomes and direction of the game, that usually still isn't what we consider to be the game itself.

For example, even if you play an RPG with extensive dialogue, the most interactive or "affectable" part of the game is still not the story. It's probably the combat system, where you get to really mess around with things and see the monsters go pop as a result.

But this is our whole problem!

What I realized is that the cause and effect part of games, which is truly what differentiates them from other art forms, has really so far just been limited to physics.

Physics?

Yes, physics. The basics of hitting things, moving around, bouncing, that sort of physical interaction, is as far as we have really taken it. For the most part we haven't yet elevated our sense of cause and effect in games to the higher, "human" level.

And until we do manage it, we're just creating toys with context tacked on. The argument that the meaningful part of our creation could as well have been a movie is sometimes accurate.

I don't know how to elevate cause and effect to a higher level. For example, how does one create a game whose primary purpose is to experiment with relationships, and to experience "cheating" or "betrayal" the way a movie or a book can?

Well I do intend to try to figure this out.

More Graph-viz-ing!

Fri, 30 Oct 2009 23:18:17 GMT

I've posted about graphviz in an earlier post. Basically, I find it immensely useful to sketch out gameplay ideas in terms of dependencies.

Flower Power Example

Suppose you have an idea for your game, a "flower boss". To defeat this boss, you imagine the player attacking it with a fertilizer bomb. In Graphviz:

flower_boss [shape=octagon]; // we want bosses as octagons flower_boss -> fertilizer_bomb; // beating the flower boss depends on the f-bomb fertilizer_bomb [shape=box]; // items will be squares

Graphviz will draw this as a octagon of the flower boss with an arrow pointing down to the fertilizer bomb:

It might not seem like much. But the important thing is you've encoded something specific about your game. Later on, you're going to have to figure out how the player will get this fertilizer bomb.

Organize Ideas As-U-Go!

By doing this iteratively, you can organize your ideas. You will start to see how the different pieces of your game fit together. You can even see if things are getting ugly, like I did in the following diagram:

Here the problem is it's highly horizontal. A lot of players will say they value nonlinearity but too much of it is just overwhelming and confusing. As well, too much nonlinearity will destroy any sense of flow or progression within the story.

If you just have to complete 100 tasks in any order, that interrelate in unpredictable ways, you're going to feel less than compelled beforehand and less than satisfied afterwards.

Then, Reorganize Them!

The beautiful thing though, is even with an ugly graph there are parts of it that will crystallize. You immediately get ideas suggested to you for genuinely interesting events, quests, and relationships. You can spot things that seem a bit out of place or wacky.

Another thing I do is put "want" nodes. These are actually maybe the most important nodes, and represent the player's desire. A want node "deliver_letter" pointing to an npc "npc_joe" means that when the player interacts with Joe, they should end up wanting to deliver the letter. Simple as that!

I've also realized that "want" nodes map very nicely to my "notes" system. So this design document works on a few different levels.

Here's the Final Graph

This graph is the product of almost a week of work. It's a wonderful thing because it's specific and at the same time very "light". I jogged and jostled nodes around and could very easily imagine the gameplay flow as I did so. You can see, this one looks much more managable.

Everything flows so logically, and for the most part is balanced. It's less linear than you might expect, but there is a definite story progression.

Now I get to implement it! =)

H1N1 Flu, Ahoy! and Ephiphany, Ho!

Mon, 26 Oct 2009 17:42:14 GMT

So last Thursday I got sick, maybe this H1N1 thing. I'm feeling better now.

Reccomended reading: The Plague, by Albert Camus. I read this novel last summer and found it simply amazing. I think it's one of my favorite books, along with the just-recently-read Treasure Island.

The Library Event

So last week I showed the game off at a small business fair at the local library to the general public. Lots of non-gamers present and many I convinced to try the game. It was really illuminating! Here are some fun facts:

- Women really enjoy it.
- They require some major cajoling to give it a try.
- The "sticking to walls" bug is very disrupting.
- There are some visibility issues that are very disrupting.
- Maybe 50% of the people asked, before trying the game, "What's the point?"

The last point is really interesting. Remember these are mostly non-gamers. Could it be people don't play games because they don't see any point to it? Weird!

By the time it was done I answered this last question along the lines of:

"It tells the story of a man from Texas who takes a Holiday in England, and then slips through a rabbit-hole like in Alice in Wonderland and ends up in an alternate Texas. He has to find his way back home, to the Real Texas, which is what the game is called: The Real Texas."

It was a bit more polished on Tuesday and I should probably have written it down.

What's next? Collisions fixed!

Well, I've fixed the collision code so that you don't get caught on walls anymore. That was yesterday, and it was a surprisingly clean fix. Very satisfying as well, and amazing that I let it go for so long with such a poor implementation.

Epiphanies! YESSSS!!!11

Wednesday, the day after the library, I had an epiphany. I was half-slumburing on the couch and realized what I need to do to restructure the start of the game, introduce a much snappier flow and prevent the player getting bogged down in puzzle solving before any action hits.

It's so obvious, and so smart! You'll have to wait for the next demo to see, and before I actually do implementation I need to do some short-story writing and diagram sketching. But this is truly rewarding:

I've been gathering feedback, observing, and thinking about the game and all it's virtues and problems for over a month now. Finally, it all sort of jellied together and that is indeed satisfying. This is why user feedback is vital, folks!

My fellow game devs, do everything you can to get feedback on your game, earlier the better!

Calgary Small Business Week

Tue, 20 Oct 2009 03:49:19 GMT

The Calgary Public Library (Castell branch, downtown) is having a small business fair and I've rented out a table. Tomorrow I'll be showing off Texas in playable form to the general public; this is sure to be a disaster! Hahaha =)

It will be awesome to watch people play. This is my first trade show, and I kind of like the venue. Here's a commercial from the Library:

The Notebook

Fri, 16 Oct 2009 15:52:17 GMT

I've begun adding a notebook object. The notebook lists your next objectives:

Some might cringe at the thought of having such an object. It could become a real crutch for game development, in that no matter how bad your game is designed you've got this silly "next objective" thing leading you onward.

I think if you are a bit more thoughtful with how the notes are constructed, however, it can compliment the game nicely. The notebook can provide instructions, or it can provide clues.

More, Texas is always going to suffer from "noise"; part of the fun of the game and part of my philosophy in general is that providing players with too narrow of options is actually very heavy handed. If every object in the game has a definite purpose, the game could devolve into a "try everything everywhere"-a-thon, which you can't argue is good design.

Some people have regarded all the extra detail and objects in Texas as "red herrings". I'ev seen not-too-few players try and use the pamphlet on the parkade machine, just because both are there. But I contend this is only because players have been trained to do so by many poorly designed adventure games.

The notebook should help me to break the player out of this thinking, by providing clues and focusing their gameplay on what actually matters. Even if they don't read the text quite right, or it doesn't scan, they will end up with a clue in their notebook and their job then can be putting these clues together, rather than trying every possible combination.

Kinetics in Games

Thu, 15 Oct 2009 16:05:18 GMT

Swordstrike!

What's "action"? Some of the feedback I've had for The Real Texas has been that there isn't enough of it.

Let's rewind a bit. Most of us developers (and I hope, players) feel that games fit into the broad category "art"; they sit somewhere alongside plays, movies, songs, stories, poetry.

A broad definition of art could get murky so let's narrow it down, just for the sake of the game I'm making now. Texas fits into storytelling art. This sort of game is a story told in the second person: "You do this", "You feel this" rather than the third person "He went here" or "He was upset" or the first person "I needed to get some alchohol, but fast!"

I'm aware of only one novel that does this. It's by Italo Calvino, but I can't remember what it's called and I haven't read it. I'd like to. For games, though, the second person narrative quite a natural fit. What gives it this power?

Storytelling in the second person works for games because we're able to create an environment that mimics reality, and give the player enough freedom inside of this that they feel they are the one experiencing the story. That is, the story that we the game designer is actually telling. It's a wonderful and unique virtue of game design but maybe we aren't conscious enough of it.

Reality

I recently read a book that suggested that some of the most popular english nouns are time, person, way, water, and thing. This is really evocative for me and suggests what might be the most important concepts to have in a game to create a believable reality.

Beyond these concepts though, we all have an intuitive grasp of physics. If we don't have a believable physical system in place, to some degree, the game will lack reality. This doesn't mean you need a solid body simulator to make a good game; but it does mean that if there are walls, you oughtn't be able to walk through them. It also means that to hit something, and have it smash, will help create immersion.

Smashing

If you look at certain games, it becomes obvious that a great deal that is going on is kinetic, based on the motion of physical objects. Platformers are based on our intuition about gravity; such a game world can seem very convincing because of this simple physical fact and the way we can experiment with it as we play.

Part of our physical intuition also has to do with things breaking, or us being hurt by things. I'd imagine we have it buried deeply in our subconscious that heavy things thrown at us are dangerous, sticks or swords swung at our head should be ducked, and so on.

I think this goes a long way to explain why so many games are based around combat. It's a good way to help build the sense of reality around the player on an intuitive level.

Along the same lines, I think physical intuition is also why so many lines of code have been written to simulate water in some form or another. Game designers that don't have "water" as a tool in their belt might find it hard to construct a believable world.

Well, I'll leave it at that, for now.

Texas Alpha 101 is Ready!

Mon, 12 Oct 2009 21:00:13 GMT

Hooray, I've got Alpha 101. It adds an automap and fixes some other gameplay flow issues. I haven't addressed very many "bugs" in this one, so if the game crashed for your before it'll probably still crash for you now, unfortunately.

If you wanna test, please just reply here or send me an email, psysal@gmail.com.

Thank you!

Automapping is Subtle

Sat, 03 Oct 2009 04:54:09 GMT

What a great day! I got it almost all worked out. There are some subtleties. Since my blog topic is "really boring game development minutae" I'm going to lay it out for you.

A funny compiler error

I got this just now:

CODE: texcoord_ratio = (rep_size - 1) / mkrloc (tex_size, tex_size);

ERROR: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second

Interesting! I have no idea what it means, but the trick was that (rep_size - 1) was supposed to convert the 1 into a mkrloc (1, 1). Oh well.

Sectioning

The previous post lays out how the automap works. The thing is, we actually need to section it. Why? Because the player only sees about 1/3rd as far as the actual area stretches. So if we go auto-mapping the entire area (50x50 blocks) then it will be hard for the player to really know where they went.

The solution is to section each 50x50 block further into 3x3. But there's a catch! What this means is when we step on a ? block, we figure out what 17x17 section we are in. But we can't compute the visibility only limited to that 17x17 section, because what that would mean was if there was an impassable fence (that opened up later on) we wouldn't be able to see it. Ugh! I know this is horribly complex and boring but it's funny how subtle this actually was.

So what you do is when the player steps on a ? block, you compute the visibility temporarily for the entire 50x50 area. Then, you only take and copy into the automap from the appropriate 17x17 section of THAT.

What you get is a pretty natural seeming automap.

Line-thicken Filtering

This is all well and fine, but it ends up with a pretty high-resolution automap. It starts to feel artificial, to me, something like a high resolution image in the middle of a pixellated indie RPG.

So what we want to do is filter it, i.e., thicken the lines. This can happen when we're preparing the texture for rendering of the minimap, and it's not hard. You just run a filter on the minimap data that will take the maximum (brightest) line value from each 3x3 surrounding block for each pixel.

Despeckle

Close, but even that's still not enough! Why?

Because you're going to get a lot of "dots" on your map, anywhere there is a tree. Tree's are 1 block impassable things, but having them show up on the minimap is irritating. Worse, they get thickened in the previous step so they start to look very significant. In some cases, it looks like a pathway is blocked off.

Remember: we are still computing the minimap and storing it on a per-pixel (per-block) high resolution level. This filter is just for the purposes of display.

So what you do is, similar to the above filter you go through and look for any "loners", i.e., single pixels without any neighbours, and you clear them. Simple enough.

However, you need to run this filter BEFORE the line thicken filter.

Voila!

And... minimap! In case you think I'm crazy, and that this much detail is overkill...

Here is the "too fine resolution" minimap:

Here is the thickened, but not despeckled minimap:

And here's where we are at the end of the day:

What's left

What's left is really mainly to color it blue, move it to the right and down, and then put a system in place where you can click it and get a special-UI scrollable minimap. Maybe you will access this from your watch, but I think it will be a better choice to put a "GPS" button on the minimap itself. More intuitive!

Then I have to make it know to pop in and out, tie it to ownership of the GPS watch item, and give the watch item the ability to turn the display ON and OFF.

Voila!

Automapping, Walking

Fri, 02 Oct 2009 15:48:30 GMT

I've got two fairly-big programmerly issues ahead of me. One is automapping and the other is to clean up the walking code.

I think I would be smarter to tackle just one of the two for the next update. Since walking isn't as critical (although annoying) I will tackle the automapping.

How it Works

I've got it fairly clearly figured out now. The automapping system will be of course area-based. It's not enough to just show what areas the player has been on, we also need to show some detail in those areas, for the player to recognize.

We will use a fill algorithm to determine the shape of the area the player has explored. Basically, what this means is that when the player has stepped on a square that is not yet automapped, we will try to fill it in similar to a floodfill tool in a paint program.

To generate the fill, we could do pathfinding; in theory this might seem OK, but I've a hunch that in practice it will produce maps that are too detailed. So instead we will use a simplified algorithm based on the player's altitude and the wall height.

When we fill, we just look for squares that aren't too high/low verus the "base altitude" (in this case, ground level). If they are above a certain altitude we'll stop filling.

This approach should produce fairly nice-looking automaps, which are representative of what the player has seen.

The second part: UI, Savegame, and more!

We need to integrate automap with the rest of the game (read: lua). In particular, automaps need to be stored to savegames and they need to be displayed.

To bridge this gap, we will represent automap data as a string of "?", "X" and "."; at least initially. The savegame will store the automap data for each area, and we can fairly easily introspect this data to determine when we might need to automap.

"?" means "unknown". If the player steps on an unknown square, we initiate an automap fill to add detail to the automap.

"X" means "wall". In the process of automapping, if the neighbour of a filled square is impassable, we mark it "X" so the player knows he/she can't pass through.

"." means "passable".

This data can be introspected relatively easily from a simple lua class we will make. This class might do the automap-filling itself but I think more likely this algorithm will be written in C++.

The data can also be passed to a user interface object that we'll generate as needed. This UI object will take such a string and produce a custom texture that it will use to render each block.

Of course, on the automap we aren't going to just show the 50x50 area the user is on; we'll show a few neighbouring areas, too.

Gameplay Control

The automap will be controlled via the player's watch, a starting inventory item. I realized that this was a nice natural fit; GPS-watches aren't exactly the most common thing (A vehicle GPS unit would make more sense) but there are GPS watches and such that runners use. It's not hard to imagine a modern day cowboy might have such a watch to use for trekking across the range, or something.

This will provide a simple interface for the user to turn the automap on or off (in case they don't want it onscreen) and maybe other features.

Problems

The biggest problem is that it's a fairly major system to implement. =) But, for an exploration game it just makes sense.

The second problem is how to handle areas like the castle where there is a main floor, and a top floor. For now, I'll not worry about it and only automap the main floor. It shouldn't be too hard to manually tag areas that need multi-level automaps and then switch between them as necessary, once the main system is in place.

Where to now!

Wed, 30 Sep 2009 17:22:57 GMT

Wow, between the user feedback I've gotten (and if you're wondering, I devour it ALL) and the data coming in that's automatically collected, I have been able to formulate an excellent plan for the next alpha. Besides bugfixes, here's what's (probably) coming:

Some kind of Minimap

I haven't figured this out exactly. Should it be an automapper, like Super Metroid, or more of a "you get a map object and then you get to see a map with your position", like Super Zelda. Of course, Super Metroid has it's own version of the map item, those little charge stations that give you a map. But being able to see where you have explored is a nice feature.

I don't know yet! Other questions are, should the map be only per-area (i.e., one map square per area) or not?

To tell you the truth, I like the idea of a pre-drawn map with a grid overlaid on it. You'll have a "dot" showing your position in the grid. Perhaps we can show which grid squares you've explored. A map like this needn't show too much detail, but would give you an immediate sense of where you are at. Being able to find/collect maps would be really useful.

We can even show NPCs as dots along with the player. This is maybe (definitely) unrealistic but that doesn't matter as much as a person might think. The main thing is to give the player the information they need. Sometimes, you just tell them.

Telling the player radar-like, without an in-game explanation, where NPCs are: that's breaking the third wall. But your choice might be to dumb-down the NPCs daily schedules, so that they are easy to find, or this. I think you're giving the player a more interesting world to explore in the latter.

Another example is say Castlevania: SoTN. As you enter areas, it tells you the name of the area. As you strike enemies, it tells you their name as well. It's breaking the third wall, but it adds a lot to the feel of the game.

Smooth Boundary Walking

I had rather forgotten how irritating it is to walk along walls in the game! The player should of course slide smoothly along the walls, not instantly get stuck on them.

Lots of gameplay tweaks!

This is the real value of the data collection. I can see what people are trying, and make it work, or lead them in different directions. For example, more than one player has tried to smash the other car in the parking lot, and more than one player has gone back to their car to put the parking ticket on it. These are obvious things that I wouldn't have been aware of if it weren't for the data collection system in place.

Once again, to all the testers, Thank You!

Unexpected Consequences!

Wed, 30 Sep 2009 02:23:32 GMT

Aha, here is an interesting consequence of having a replay system in place. As it turns out:

- Everyone has a faster computer than me

Coupled with:

- The replay has to play back each frame of the game no matter what

Means:

- There are more frames to play back (as a rule) than my computer can process in realtime

Ergo:

- Watching the replays is rather... tedious =)

I did implement something of a FFWD, that will at least play it "as fast as possible". But it's still not incredibly fast =)

Milestone 1, Reached!

Sun, 27 Sep 2009 02:13:10 GMT

Hooray, fireworks, that kind of thing.

I have put together "Alpha 100", at long long last. Holy crap, games are a lot of details to be sorted out.

If you'd like to be an alpha tester, I'd love to have you. Please post a message here or email me, psysal@gmail.com. Thank u!

More Musings

Fri, 25 Sep 2009 17:22:05 GMT

LTTP Dark World Dungeons 1, 2, 3

I'm continuing my playthrough Legend of Zelda: Link to the Past.

I think that Dungeon 1, "The Palace of Darkness" is the most interesting and polished of the three, sort of a gem. I think it might be bigger, as well. It's a nice mix of interesting linear sequences and choices you need to make.

Dungeon 2 and 3 feel a bit short by comparison. Dungeon 2, the water one, has a few interesting tricks where they take advantage of the fact that they know which direction you are likely to head, and design it so that it's the wrong direction. Dungeon 3 has just a few tricky puzzles in it, but doesn't feel very large overall. The leadup to the final boss (Big Moth) is nice.

This game is a lot more fun when you try to use the bow and arrow almost exclusively.

Millions... of tiny... bugs

Finishing a game is about millions of tiny things. It truly, truly is.

Onward I slog. There are some crucial things that still need to be in place before I get beta (alpha) testers. If you want to be a tester, please post on this blog, or email me psysal@gmail.com.

Thank you!

On Alternate Dimensions

Mon, 21 Sep 2009 15:19:27 GMT

The latest Texas video. I updated the video export to also export audio.

Means of Transferral

The Wardrobe.
Moongates.
The Magic Mirror.
The Rabbit Hole.
The Small Door Behind the Filing Cabinet.

These are all devices for moving between dimensions. And there are more!

Types of Alternate Dimensions

The idea of exploring an alternate reality has everything to do with putting a new take on our own reality.

Some stories take place in that alternate reality itself. Take for instance the Discworld novels by Terry Pratchett. Discworld is a fantasy take on the real world, and has it's own alternate dimensions (for instance where Elves come from) but it's grounded only in itself. As a reader it's up to you to realize that Ankh Morpork is (I'm assuming) a certain loving take on London, or all big cities.

Take then something like the Chronicles of Thomas Covenant. Stories like these are grounded in the real world. The story starts in the common real world we are all familiar with and moves to an alternate dimension where the rules are changed. The story is grounded in reality, not in fantasy itself.

Sam's Experience

Texas is set up like the second case. The game is grounded in the real world, with an alternate-reality intruding on it. Sam will be thrust into this alternate reality.

In my grade 7 science class we were learning that all things could be classified into living, nonliving, and dead. Things that were nonliving were things that hadn't ever been alive, like a rock. I was not encouraged by my science teacher when I asked: "What about undead?"

You and I both know that undead are things that were once dead, but are now living. They've come full circle and it's usually not pretty.

I think Sam's experience is going to be like an undream. He was awake, but he's fallen into something like a dream-become-real. The rules of the subconscious are in play, but they are manifest physically to interact with in a conscious way.

What am I saying?

Well it's just another darn alternate reality story anyhow. It's after all just a device that should serve some story-telling end. Funny but I haven't thought too closely what that might be!

The Lion, the Witch and the Wardrobe was a Christian apologetic. I remember the uncle who said, if the youngest boy said there was a magical world behind the wardrobe, it wasn't certain if there was such a world but surely it wasn't rational to believe he was lying.

Ultima was a morality fable. An ordinary person (in fact, the player himself) was brought into an alternate reality where he/she was expected to be an upholder of virtues. The red moongate bridged the gap between our morally ambiguous world and a sort of philosopher's example world.

Zelda: Link to the Past is a subconscious fable. Rather than debate anything consciously, the storyline appeals to us on a primal archetypal level. This may sound kind of esoteric but it's the most common type of fable. Evil, good, heroism, maidens in distress etc. are all presented as archetypes that appeal to us subconsciously but don't really create a meaningful conscious debate.

Alice in Wonderland, I really have no idea. I haven't read it. It might be the most interesting example of all.

Being John Malkovich was sort of an interesting experiment in sense of self and free will, and did a nice job of playing with certain paradoxes. I think it was sort of asking the question, in many different ways, of "Who are you? What if you were someone else, who would you be then?"

No Conclusion Yet

Texas right now uses a moongate-esque teleportation device, but this was an arbitrary choice before I thought about what the alternate reality really was going to represent.

Now, I'm more thinking that it will be an exploration of Sam's mentality. I don't want to get too serious or heavy, but what if things that are present in the alternate reality are really brought out of Sam himself?

There is, certainly, a "real" malevolent force in the game, pulling strings. It's not going to be "Oh! It was all just a dream!" (which sounds pathetic but can be really effective). But maybe that force plays with Sam's own ideas to create the alternate reality world.

I think I had better read Alice in Wonderland.

First section: done?

Sat, 19 Sep 2009 20:54:41 GMT

Could it be that the introductory section of the game is done?

I think it could be.

Well there are a few pieces missing. I need a bit of an introduction story, explaining how you got to the Castle. Um. I need an animation when you first fall into the alternate reality universe.

And I need to put a room in the alternate reality that explains you've reached the end of the beta test. Wow.

What excites me the most about this is that I can start sketching out and implementing the "meaty" part of the game. I've learned so much about doing this, and once I get started I will have a good idea of how long until the final game is done.

Trade Show

In other news, I'm going to be at a trade show. This is my first trade show and I'm really excited. It's for small business week in Calgary, and held at the downtown public library.

I'm going to set up the booth with a small Kitty Lambda sign, business cards, an information sheet, and the playable game.

There are supposed to be about 500 people come through, and I will try and get them to play Texas. I'll be sure to relish this opportunity to watch people play the game.

Music

Mon, 14 Sep 2009 23:59:27 GMT

Flow is fixed

I've fixed most of the flow issues-- or so I think! Having written some short stories was very helpful. I boiled down the dialogue to it's bare essentials, and removed about half of the NPCs (a bold move, don't you think?) A side effect of not using some of the NPCs is that I get to fill the wardrobes of the castle with their now-unused clothing, which is a nice bonus!)

Music is magic!

In game development you slog and slog and slog away. You try to stay on-track yourself, and above all things keep the game focused. But sometimes things start to crystallize for you. When they do, it's truly magical. Today was like that.

I have to be the luckiest game dev of all, in that I know a lot of musicians who are happy to let me pilfer their music for my games. For VtV I used the music of Lapine and it really completed the game.

For Texas, I'm using the music of my friend Yesso and today having put the first of the music in place I can only say: hoorj!

Here is the title screen music:

A Sad Cowboy's Song

More Playtesting

I am going to have Yesso playtest a new build later this week. I hope he can feel it's a bit magical with his music in place, too.

I think I need to get somebody (or somebodies) playing a new demo every 2 weeks or so. I'm *THIS* close to starting into the second, main part of the game. Ah me!

I will try to put out another video this week, too. Hopefully I can find some way of capturing the audio with it, I don't want to write custom audio exporters but I probably don't have to, either.

Flow bugs, NPCs

Sun, 13 Sep 2009 16:21:37 GMT

Types of Bugs

You can divide bugs into at least two categories, when you do playtesting:

Bona-fide bugs. This is when an action does not work, the player discovers something you didn't forsee and it breaks things, or the game crashes/freezes/etc.

Flow bugs. This is where the player could, and would do something either eventually or if they had some crucial insight or understanding, but that insight isn't forthcoming.

I've fixed most, not all, of the bona-bugs that came up during playtesting with Kevin. I've made a few modifications to the gameplay world to address some flow bugs, for instance blocking off a whole section of the overworld that he spent a lot of time wandering around in, and putting another staircase so the upper floor of the castle is more obvious/accessible.

To fix more of the flow bugs, I need to rewrite the dialog, so that's my next project.

Focus

Mozart once said, when some rich dude said that his music had "a lot of notes", that there were "exactly as many as were necessary, and not one more."

The biggest flow problem in Texas right now seems to be focus. There are too many possible actions for the player to do, so that what they really need to do is lost in the noise.

For instance, there is a spellbook in the game with five spells. At least some of these are obviously just for humour; only one of them is absolutely required. Some others I have planned to be functional later on in the game but do nothing now.

Giving the player these five spells at point in the game is really confusing. When you've got a hammer, you're going to look for a nail.

Too many NPCs and too much Dialogue

Another for instance, there are way too many NPCs in the first part of the game: 7 to be exact. It's just not even close to necessary, even with respect to the roles or sidequests they might play in later on in the game. So I'll cut it down to 4, which is still plenty.

It also doesn't fit with the story. It's more believable that a seldom-visited tourist exhibit would have 4 full time employees, rather than 7.

The NPCs also have too much dialogue. This will be cut down vastly.

Here's hoping this will result in a much better flow for my next victim!

First Playtest, Venture the Void 1.1.5

Fri, 04 Sep 2009 19:20:15 GMT

First off, I've got a pre-release of VtV 1.1.5 ready, and if some of you lucky readers could just give it a test run and let me know if it works, that would be luscious! Forum post is here:

http://www.venturethevoid.com/forums/viewtopic.php?t=218

Tanku!

Texas Playtester no. 1

My friend Kevin came to stay for awhile and while he was here I held his bicycle hostage and made him play Texas. Here's what happened:

- There were some simple bugs that I fixed; I hadn't played the very first part of the game through for awhile. Blah blah boring blah.

- The first, "tutorial" area, in spite of all the bugs that popped up, went swimmingly. This is victory with a capital V for my special GraphViz-based game design technique.

- The user interface also went swimmingly. There were a few bugs, and a few "false starts" (he tried to click the player picture to remove the pants instead of the draggable icon, but I can't fix that too easily... I might though). The worst had to do with walking. Awhile ago, to make the game work with only one mouse button (because It's twice as simple as with two mice bittins) I changed the walk interface slightly from "click" to "click drag". I need to make it work with "click" again, because even after an hour or so he still kept running into that one.

Problem 1: TMI!

There is too much dialogue in the game. Kevin kept getting confused and didn't pick up on hardly any of the given clues. I had to give him hints to get to the end.

This isn't a big problem, but it was majorly useful feedback to get at this point, when I'm just about to rewrite all the in-game dialog. The problem is that in an effort to create some "backstory" I sort of drowned out the main flow, so the hints and so forth just get lost in background noise.

Instead, the dialog needs to be as focused as the rest of the gameplay. Backstory is good, but if an NPC references something backstory-related it should have a counterpart in the game world.

Is an NPC good with trivia? Then it has to have a relevance to the game.

Is an NPC seen carrying an item? Then it should have some use, the player should be able to get it.

Does an NPC mention some event, or person, or personality quirk? Then it should relate to the main story or a side quest, in that it's something the player can explore in the game world.

This seems obvious in retrospect but this is the #1 thing I am glad to get out of this playtesting, because it's something I somehow overlooked entirely.

Games like Ultima 6 that have a lot of dialog work because all the dialog is relevant. You can explore many situations in-depth by discussing them with NPCs, but if you explore it outside the context of NPC conversations, it relates and proves real.

Lesson lern't, and just in time!

Problem 2: Too much wandering

This was something I knew beforehand, there are large areas of the map where you do really nothing but wander and admire the scenery. This is compounded by the fact that sometimes you need to find a certain NPC, who are normally in the (comparatively small) bounds of the castle but sometimes are out-of-doors.

Even before playtesting, I realized that I had a problem in that the player won't have any experience smashing things for a long time. I'd like the game to have a simple, tried-tested-and-true "smash it with a stick" mechanic in addition to the "shoot it with your gun" mechanic.

To remedy these two things, I'm going to put some monsters (that fit with the storyline) around the field, and give the player a stick first-thing. As well, all NPCs will be inside the castle walls. Entering the castle grounds will be made evident by a change in music, perhaps, and if you ask an NPC about another NPC they will tell you where they probably are.

Problem 3: Not enough basic actions

The game has a nice "try sum'm" feature, where you can type in an action to try on a given object. Kevin, it so happens, is an avid IF-er and so he knows what the logical things are to try.

If I'm going to have a feature where you can try anything, then I need to either have it work in a much wider context than it presently does, and/or I need to put some default responses in.

I'm toying with the idea of taking it out altogether, but I don't know. I really like the core idea, of most of the time just using a menu but sometimes when you gain some insight you can try a certain action.

Of course, we could have those actions added to the menu automatically once we've learned the relevant clue, but I don't know how I feel about that in the long run. Further, it wouldn't be too hard to add default actions to objects, based on a simple property system, that could really improve the flexibility of the gameplay a lot.

Onward!

Now that I've got VtV 1.1.5 just about out the door, I'm glad to be able to next week get back to Texas. I am excited to do some more playtesting after I can make these changes, and the game is just about ready for a private playtesting release where I can test out the first part of the game.

Until then, happy playtesting fellow game devs!

The Legend of Zelda: A Link to the Past -- First Impressions

Thu, 27 Aug 2009 17:59:42 GMT

Not to make you jealous or anything, but I have a real live SNES with a real live VGA-box that lets me plug it into my monitor. Last night I hooked her up and put in the venerable classic, LttP.

It's hard to believe this game was made in 1991. In some way, I think a lot of us indie devs are still chasing it (although, with so many platformers released perhaps we are really chasing SMB3...)

The Magical Intro

Do you remember how it opens? You wake up in the middle of the night, having received a telepathic message from the princess, held captive in the castle. Your uncle is heading out out to rescue the princess, and you follow him. There is a driving rain which gets louder when you go outside. Eventually, you receive another telepathic message, a hint to try searching the well. You do so to the familiar boo-dee-doo-dee-doooo of Zelda-secret-finding, and jump in.

For it's time, it was a startlingly dramatic opening to a videogame, and I have a feeling it formed a strong impression on a lot of us. But here is where I'm going to stop waxing poetic.

Secret Passage

You enter a secret passage and get the sword. From here on, some fairly low-level enemies are thrown your way.

What struck me at this point, actually, is how devoid of detail the environment itself is. I'm so used to looking at Texas, and other modern (particularly indie) games which nowadays are just bursting at the seams. Just look at Fez, for example. Tons of little details: bushes, shadows, different types of blocks. LttP looks comparatively boring! Not something I expected.

Fez.

Gameplay

The gameplay is, as always, really very solid. But there's something else that struck me as I was playing, and that is how much these games from Nintendo have come to actually define gameplay for us. Think about it: we have, as with SMB, as with every other Nintendo game of the era, a little kinetic simulation with items and objects and enemies. The core of the gameplay is determined by the interaction of these. This is probably something like the "early Miyamoto" formula for game design.

We have a hero who interacts kinetically with the enemies. Enemies have different properties that change how we approach them, but it's all fundamentally kinetic.

Cyclops Enemies

Do you remember the "cyclops eye monsters"? Giant statues that come to life when you are close, open one eye, walk towards you for awhile and then go back to sleep? There is a very careful balance between how long it takes your bow to load after you push the fire button, how fast they walk, how long it takes them to open their eye (you have to shoot them in the eye when it opens) and how close you have to get to wake them up. A typical strategy involves waking one up by walking close, backing off to buy yourself some time, and then firing your arrow. If you just try to shoot your arrow from up close, you'll typically get clobbered.

Because they walk so fast, and make a beeline for you, they tend to breed chaos. If you wake three of them up, you'll never get enough space to aim and shoot. This is sort of an example of emergent gameplay. If they bump you, you might get close to another one and wake him up. At this point, you have to change strategies and just avoid them until they fall asleep again, since you'll never have enough space to get a clear shot off.

It's really wonderful, and the game is filled with things like this. It's what we love Nintendo for.

Detail

I realized that my games tend to focus more on the environment and setting than "gameplay". Playing LttP has caused me to re-evaluate what I tend to spend my time on.

The DROD series are fantastic indie games which also have a fairly simple environment. In this case, the gameplay is expressly not kinetic, although I'm not sure of a single word to describe it. But overall, there is a similar balance here as in LttP.

Deadly Rooms of Death: Journey to Rooted Hold

Messiaen

Perhaps this is like a theory I've heard about eastern vs. western classical music. Western music is all about the action, moving forward. A symphony is a journey through time and psychological space, and you never end up where you started. Eastern classical music is more like a garden that you freely wander in. I don't know Eastern classical music but the (western) composer that was the original context for that thought is Olivier Messiaen, and his music is certainly garden-like.

Early Game Pacing

LttP employes some devices for pacing. In particular, if you play the game you'll notice it tends to divide quite neatly into sections. It is definitely not a continuous flow of gameplay.

The castle itself is more of a mystery in terms of function. It might have been unintentional, but once you get past the secret passage into the castle courtyard, the flow kind of hiccups, because it's not obvious where to go in the castle to find the dungeon. I think players will typically gravitate to the throne room, and/or spend a bit of time exploring the (rather nondescript) castle itself. This might be intentional, to cause the player to see the throne room before they enter the dungeon, and also to add to the sense of urgency as you are frantically searching the castle for the dungeon entrance.

Once you get to the dungeon, things definitely pick up. To create a sense of urgency in rescuing the princess, there are fairly wide-open and fast-flowing linear passages. Unlike the castle, the flow here is very linear. They also employed a short-cut back to the main floor. Once you get the princess, you'll head straight south and they've placed a ladder directly in front of you. If you climb it, you get to avoid all the enemies you had to battle your way through on the way there.

After this, you head back to the throne room and make for the sewer. The sewer itself is sort of a blend. It's linear in flow, and so you do have a sense of being propelled forward, but the darkness adds to a sense of frustration since you don't immediately see which direction you go. The sewer also introduces some of the first elements of puzzle-breaking, as you need to find a key in at least one place.

This culminates in arriving at the sanctuary, where things take a great big breath "ahhh", the music changes, you are rewarded, and you finally get your quest.

In retrospect, completely brilliant.

Level Structure

The first three dungeons are structured rather interestingly. I want to wrap up this post but, generally:

- The first dungeon (the Eastern Palace) is completely linear
- The second dungeon (the Desert Palace) is almost completely nonlinear, and (for me) one of the most memorable, particularly as it interleaves the outside with the inside.

The third dungeon (the first "hard" dungeon, Tower of Hera on Mt. Doom) is split into two sections. First you go downstairs to get the big key.

Downstairs is composed of three "challenge rooms", i.e., kinetic challenges you must pass directly as opposed to larger, flowing rooms. This was my first death in the game, and I bet it will be yours too.

Room 1 is a tile throwing room, where you dodge the tiles.
Room 2 plays a nice trick on you with difficult snake-like enemies trapped behind blocks.
Room 3 I can't remember, it might be skeletons in the dark.

The three rooms are structured hard to easy, the tile room being actually quite challenging for this stage in the game.

Upstairs is a set of rooms involving bouncy enemies, and in fact bouncy environmental objects. When you hit them, there is a large recoil which is paired with some holes in the floor, which don't kill you but send you down one level.

Interesting! This area is actually structured circularly, since you tend to keep falling back down and having to climb back up. The final boss here plays off this as well, he's a large version of the unpredictable snake-like enemies and he keeps knocking you down.

Flow: Then and Now

The latest Zelda game I've played is Wind Waker. From what I recall, it doesn't really have the same sense of flow as the older Zelda game. A lot of people complained about the sailing sections, and I think that's why. Myself, I quite enjoyed this "garden-like" experience.

What I didn't love was the way the dungeons were structured, which was really just a sequence of very obviously-laid-out puzzle rooms. To each his own, though!

Halfway through my re-play I remembered that I haven't yet played Twilight Princess, and thought to myself "well, one day I'll get a Wii". Then I remembered that there was a Gamecube version. Then I remembered that I actually have the Gamecube version, but haven't played it yet. I've had it for about a year, maybe two, I think.

Game developers are a really weird breed, I guess.

At any rate, unless I want a career of "game critic" which I definitely DO NOT, I better wrap this one up.

Storytime

Sat, 22 Aug 2009 18:16:23 GMT

The Perils of Game Design...

There is an easy trap to fall into, as a game developer. That trap relates to the vast, almost insurmountable difference in time-scale between player and developer. A player will play your game in several hours, maybe 10 or so. You will spend maybe a year or more developing it. Your perspective is... somewhat warped by this.

And a few very treacherous things can happen because of it:

You get lost in implementing/tweaking details the player will never notice or care about

The graphics and art that you put in which look fine to you are actually incredibly ugly, but you can't see it anymore

You lose all sense of flow or purpose (read: gameplay) and the game just becomes a meaningless sandbox

Why Smaller Games are Better

If you think about those three sins, you might realize that the shorter, simpler and smaller of a game you create, the less you are likely to commit one.

So for instance, if you are creating a platformer with an existing engine, there are a lot of technical details already taken care of. You don't lose sight of your game while constructing your engine, because you didn't construct the engine. Instead, you keep nicely focused on only the platforming aspects of the game.

But if you're coding your own fully 3D physics-based engine, by the time you get around to even creating the simplest prototype you are going to have so forgotten what it even is to make a game, that everyone you show it to will just go "neat." and be unimpressed. In the meantime, some 13 year old with RPGMaker or something is going to get a lot of attention for his game "Stars of Destiny 7: The Sword of Pearl" that he made over the past 3 months with his classmate, Stinky. This will frustrate and demoralize you! Worse, his game will be legitimately better.

You Could Just Endlessly Test

Actually, this is a good way to avoid certain of these problems. If you endlessly play your game over and over again, you should get a good sense for the gameplay and flow. This can be really great, and is what some people call "balancing."

The trick is, this will only happen right if you've already managed to not lose perspective.

If you've already lost perspective on your game, gotten buried in details and technical mish-mash, then your test runs are going to be more about bouncing chairs or crates off walls with the spread shotgun than they are about the overall flow.

My Current Problem: Coherence in Story

Right now I'm suffering some loss of perspective on The Real Texas. In particular, I've lost all sense of story and background. The basic flow of gameplay may or may not work, and I might have problems with graphics too, but right now what I'm feeling is the biggest hole is a sense of coherent universe or story.

Our main character, Sam, has come from Texas to England. While there he visits a tourist-trap Castle which, it turns out, is being subjected to some strange forces. Investigating these he slips into an alternate reality which blends Wild West Texas with Ye Olde Englande.

It's not a bad premise, but needs some fleshing out! I have characters, with basic parameters, but they are still very 2-dimensional (in the literary sense, natch.) They have functions in terms of the game flow (i.e., such-and-such a character gives you such-and-such a clue) but the dialog is really bad, and I want to redo it.

How do I flesh it out?

I realized a couple mornings ago while sipping my tea and stroking my feline companion Princess Ohio Pickles that what I should do is write stories.

I have a friend who is in Minneapolis and he is pursuing something of a career in writing. Talking to him about his story, MEGASEX 3000, got me thinking about it. I used to really enjoy writing stories or poetry and actually I'm not afraid to say that wordsmithery one of my strengths, even if "wordsmithery" is not an actual word.

This year I also read something by an author, Roger Zelazny, that said he often wrote side stories that were essentially just for getting his gears oiled. Even though for almost every novel he published, he wrote at least one of these short side stories, he only ever published one (in the anthology I was readying, called Unicorn Variations). Interesting, hmn?

So what I need to do is just write short stories based in the game world. These won't for the most part be implemented in the game. But when it comes time, for instance, to put a book in the game that includes the history of the Castle, it will be there. And when it comes to certain mannerisms of character, it will be there.

Hopefully, this will keep the story, setting, and characterization not only coherent but interesting and fleshed out. Convincing dialog will make or break this game.