Intermission (cont’d): Prolonged Incubation

As my graph from yesterday might suggest, I’ve been rambling on too much lately. This is problematic not only for the reader but for me: it can take me a quarter to a half of a waking day to write and proof-read those entries to a satisfactory shine. That’s a real bite out of time I could be spending making gaming magic!

New Blog rule: If I can’t say everything I need to say in a few reasonably-sized paragraphs or less, it’s a sign I need to cut it down.

Designing good games is hard

Since yesterday, I’ve learned that inventing and using an arbitrary “Three Pillars Of Game Design” – no matter how sound I think they are – is a royal bitch to apply on a by-feature-addition basis. Trying to do so just nickle and dimed my willpower to a complete standstill. The trouble with applying a powerful filter to creativity is, like any other filter to a flow it results in a heavy decrease of current.

Instead, these “pillars” are really more of a magnifying glass, working much better after I’ve let the creativity flow into a relatively complete game design. At that point, I’m free to pick up the magnifying glass and evaluate their viability – anything majorly game-breaking I should iron out now before I regret it later? If all hope is lost, it’s best these things are figured out on the drawing board.

I essentially returned to the drawing board and evaluated some other interesting options. It was a fun exercise but, ironically enough, my original idea turned out to be the best of the pack. It really suits my pillars magnifying glass much better.

That decided, now I just need to work out the details. I’ve developed a good RPG stat system that breaks the mold while not seeming too alienating. Yet, I still need to work out the specific details, such as what specific actions will I allow the players to perform during combat? Without a good answer to that question, my actual coding progress is somewhat limited to basic foundation work.

BYOND code progress report

I did do enough thinking to get one massive improvement in the code today: I murdered my ActionQueue idea from day 6. There’s pleanty of good reasons why:

  • From a code standpoint, it’s much better organized.
  • From a game-design standpoint, it offers a lot more flexibility when all the actors can be handled differently.
  • From a stability standpoint, it means that one crashed queue doesn’t kill all the life in the game.
  • Finally, from a CPU-efficiency standpoint, it’s simply better to have those actions spread out over time instead of cycling everybody’s turn as close together as possible.

The only loser is a everybody-moves-at-once system, and I honestly don’t think anyone would notice the difference.

You can’t be afraid of murdering your darling programming code in the name of progress. (Especially when it was conceived without the adequate foresight that design brings.) I’m left with an understanding that it’s far more reasonable to develop an excellent artistic endeavor slowly over time. Perhaps the primary reason Rome wasn’t built in a day was because sound design can’t be rushed.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: