psysal

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! =)

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!

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:

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.

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.