project

Quipkit is a work-in-progress (read: not even near finished) indie RPG dev kit. This blog entry describes how we might make an RPG using Quipkit.

• 1 Vague Game Description
• 2 Initial Design
  • 2.1. Game States
  • 2.2. Resources
  • 2.3. Tools
• 3 Revising the Design
• 4 Making the RPG (Finally!)
  • 4.1. Programming the Game States
  • 4.2. Organising Resources
    • 4.2.1. Resource Support Code
    • 4.2.2. Making Custom Tools
    • 4.2.3. Make the Resources
  • 4.3. Testing the Game
• 5 Summary: The Finished RPG
• 6 Conclusion

1. Vague Game Description

Most games start as vague ideas, and indie RPGs are no exception. Here's one for our hypothetical RPG:

You play a guy in a traditional fantasy RPG. You walk around a map of grass and water, and every so often you encounter a monster. You exchange blows with said monster in the battle system until either you or it dies. If you win, you gain experience. With enough experience, the guy can gain a level and grow in strength. This continues until the player chooses to exit.

It shall be dubbed... Island Dude.

How would be breathe life into this little RPG? Read on!

I haven't written here often, because it's stunningly difficult to write something worth reading; only more so when your thoughts are fleeting and your Internet access is sparse. However, just to affirm that I'm still alive and kicking, I'd like to share some stuff I've been up to and thinking about.

First is my new project: Tea. Tea is a simple 2D game development library for Ruby. It's made for the sort of grass-roots development that was popular with QBASIC back in its era. Tea is designed with simplicity in mind: 0 is better than 1, and 1 is better than 2, but at the same time, it won't avoid a valuable, convenient feature just because it can be built from other features. Graphics, input, sound and text are the pillars of Tea.

Tea is making slow but steady progress. Events have been blasted right through. Sound and text are waiting on graphics, and speaking of graphics, that has been a royal pain to deal with so far. Why? In the words of Joel Spolsky:

All non-trivial abstractions, to some degree, are leaky.

To demonstrate, I'll describe what I'm dealing with in the graphics subsystem of Tea. Tea is built largely on Ruby/SDL, which, surprise surprise, provides a Ruby-like flavouring to SDL.

Official reason for this halting of development is this bug: many JS-enabled sites won't work, even when whitelisted. I have a vague idea of how to fix it, and it ain't pretty: recreate a large amount of Firefox's own JavaScript blocking. It's a show-stopper bug I can't fix, so I'm going to have to admit defeat here. Sorry for all you hangers-on.

Well, it was a fun excuse to learn how to work with GitHub: that site's awesome. Meanwhile, SomeScript's GitHub project will continue to be hosted there until it gets in my way, so if somebody wants to take it up and run with it, they can.

On the side, I never thought I'd meet something I'd hate more than web development. Firefox extension development isn't as bad, but it's awful close.

EDIT: SomeScript development has halted. Heh, didn't even last the week.

SomeScript is a simple JavaScript whitelist add-on for Firefox. You can read all about it on the GitHub site, or install the very very very early version from the downloads page.

SomeScript is just YesScript backwards: instead of allowing JavaScript and blocking it on selected sites, it denies JavaScript by default and only allows it on selected sites.

The question on everyone's lips: why?

Looks like I found the perfect way to get those project pages to show the correct breadcrumbs.

Before, each project page was listed under the Projects section, but when you clicked on those pages, there was no breadcrumb trail leading back to that section. Some Googling I did didn't seem to shed any light onto it.

And then I stumbled across the Custom Breadcrumbs module.