MONEY

Imagine for a second that you made a database for great big evil Bank of America and part of it needed to transfer money between accounts. You write this code:


x = moneyAmount (10, 'USD') // x represent TEN U.S. DOLLARS
 
if (account1.hasAtLeast (x)) then
 
   account1.subtractAmount (x)
   // NO MANS LAND
   account2.addAmount (x)
else
 

There is a common idea with artistic development that you will go through a period of experimentation and immitation, finally settling into a style of your own.

I'm not going to pretend that I have settled into my own "style" but certainly my technique has become fairly standard. It's just based on what appeals to me:

The Human Touch.

Awwww...

Tartan Blanket

Most games have what's called an "update cycle". One way or another, there are a bunch of entities/objects with an update () function, which is called periodically (usually every frame.) These might control enemy logic, particle positions, animations, etc.

Here is something that I have found to be incredibly helpful in reducing bugs.

Actually, I mean to talk about a far more important topic: the separation of Game and World.

A piece of software is, first, an organic whole. However, we've all had to unravel somebody else's spaghetti (or, better, our own) and know that it's useful to break that whole into organized pieces. You might use object oriented programming, for instance.

(Note: This is a bit of an interruption to my four part series on how my game is structured.)

Lately I've been polishing Texas in the hopes of submitting to PAX10 on June 15. This means I've stopped (for now) adding more content and am polishing up what's there (which is actually quite a bit.)

Prolix Dialogue

The Cutting Room Floor

Lately I have been advancing Texas by leaps and bounds. It's true that the game is still a fair ways off, but it's coming together wonderfully. Here's part of what has happened to the overworld in the past two weeks:

Note: Left is before, right is after. As you can see, I also spent too much time refining the original map graphic.

There are excellent reasons for an indie game developer to steer clear of the RPG genre. RPGs are content-heavy, have complex gameplay, and can easily fall flat on their faces when it comes to story.

New game designers often hear this: make a small game. Excellent advice, but it's often not heeded. For many of us RPGs are the games that we feel most strongly about, and so what we naturally aspire to.

Usability

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.

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