Home » Blogs » tung's blog

Making an RPG with Quipkit (Hypothetically)

18Jun2010
tung's picture

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

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!

2. Initial Design

With Quipkit, we'd have game states, resources and tools at our disposal to design and create our Island Dude RPG. Let's break it down:

2.1. Game States

A game state is like a type of level. Different game states control and are drawn differently. Island Dude could have these game states:

  • Title Screen State - a title background with a Start/Exit menu
    • When Start is chosen, go to the Map State.
    • When Exit is chosen, exit the game.
  • Map State - a tiled map that lets our dude move around
    • After some number of steps, go to the Battle State.
    • When escape is pressed, bring up a menu to end the game.
  • Battle State - the dude and the monster appear while exchanging blows in turns
    • When the monster runs out of HP, the player should be rewarded with experience.
    • When the dude runs out of HP, the game should end.

There are some vital omissions here, like how pressing escape in the Map State works, but for the sake of example we'll get back to them later.

2.2. Resources

Now that we have our main game states, we need to think about the resources they use. A resource can be simple like image and sound files, or complex like maps and sprite sets.

We can think up what resources we'll need for Island Dude using the game states:

  • Title Screen State
    • Images for the title background and menu cursor
    • Fonts to draw the menu text
  • Map State
    • Maps to create the island
    • Tile sets to hold the tile images to be used by the maps
    • Sprite sets to hold the images of the dude on the map
  • Battle State
    • Sprite sets (again) to draw the dude and the monster
    • Fonts (again) to draw the menus and the dude's HP
    • Images (again) to draw the menu cursor

2.3. Tools

With our resources laid out, we can now think of tools to help us make resources. A tool can be an external program like an existing image editor, or made using Quipkit's internal GUI system.

Here's how we might choose what tools we'd use to craft resources for Island Dude:

  • Images could use an external editor
  • Fonts could be left alone with no tools
  • Maps will need a map editor
  • Tile sets will need a tile set editor
  • Sprite sets will need a sprite set editor

Tools made to work in Quipkit could be downloaded from a team mate helping us make Island Dude, or a talented programmer who likes making RPG editing tools, or even made from scratch.

3. Revising the Design

With our game states, resources and tools put in black-and-white, we can now see what's missing:

  • Map State

    • Pressing escape brings up a menu to let the player exit, but menu logic mixed with map code seems like poor form. We should add an Exit Menu State.

  • Battle State

    • When the player wins, they get experience, but there's no logic to make them level up. A Battle Victory State should be added to show the rise in experience, raise the level and raise the dude's strength.
    • When the player loses, the game should end, but how? We should have a Game Over State that is transitioned to when the dude dies in battle.

Now we need to change our game states to add these revisions:

  • Title Screen State - a title background with a Start/Exit menu
    • When Start is chosen, go to the Map State.
    • When Exit is chosen, exit the game.
  • Map State - a tiled map that lets our dude move around
    • After some number of steps, go to the Battle State.
    • When escape is pressed, go to the Exit Menu State.
  • Exit Menu State - a menu that shows over the Map State letting the player exit the game
    • When Back to Game is chosen, return to the Map State.
    • When Exit is chosen, return to the Title Screen State.
  • Battle State - the dude and the monster appear while exchanging blows in turns
    • When the monster runs out of HP, go to the Battle Victory State.
    • When the dude runs out of HP, go to the Game Over State.
  • Battle Victory State - shows the dude's status, with experience, level and strength
    • When any key is pressed, return to the Map State.
  • Game Over State - shows GAME OVER
    • When any key is pressed, return to the Title Screen State.

There. Now each of these game states can be programmed without too much difficulty, depending on how "one with the code" you are.

This sort of revision is at the heart of making indie RPGs, so that's something we'll need to get used to.

4. Making the RPG (Finally!)

Between the game states, resources and tools above, we have a design for our game. We could continue and keep adding cool new features forever, but we need to stop for now, because if we didn't, we'd never finish our game! So, onto giving life to our hypothetical Island Dude RPG...

4.1. Programming the Game States

I left out details about what game states were all about before. Now it's time to revisit them, otherwise we won't be able to write any code!

A game state is a kind of level, like the title screen, or a map engine, or a battle system. It comes with a drawing function, and an update function that drives the game state's logic.

Game states come to life on the game state stack. This stack tells the Quipkit engine which game state's drawing and update functions should run at any one time. The state on top of this stack always has its drawing and update functions called, which may in turn call drawing and update functions of game states underneath it in the stack.

In the simplest case, game states on the stack can just be swapped in and out of the stack. This way, the stack would only have one state on it at any one time, like a stack of plates with just one plate. We can say that we move between game states.

Game states can also be pushed to and popped from the stack. This can be useful to reuse drawing or update functions. For example, in Island Dude the Exit Menu State can be pushed on the stack by the Map State, so that the map can be drawn behind the exit menu.

Coming back to game states, they can also hold variables, even as you swap them in and out of the stack. This is useful for things like saving the position and facing direction of the dude on the map between battles with the monster.

With the power of game states and the game state stack, here's what we'd need to do:

  1. Write the game state's update code.
  2. Write the game state's drawing code.
  3. Write code to move, push and pop states on the stack.

Our game states will also make use of resources that we'll be making.

4.2. Organising Resources

We had a vague outline of what kinds of resources we needed:

  • Images - external tool
  • Fonts - no tools needed
  • Maps - internal Quipkit tool
  • Tile sets - internal Quipkit tool
  • Sprite sets - internal Quipkit tool

We could configure the Quipkit editor to edit images using an external program of our choice.

Few good tools for fonts exist, and with this being a small, unpolished RPG, there's not much need to create our own font. However, if we did need a better font, we could choose one from the local system, download one (with permission), or even devise our own bitmapped font format so that we can make our own.

For maps, tile sets and sprite sets, we'll be making our own tools, or using the generously donated tools of talented programmers of the hypothetical Quipkit community.

4.2.1. Resource Support Code

Before making the tools, we need to tell Quipkit how to load and save our resources. This is done with a small source code file that tells Quipkit how to convert between the resource data on disk, and that same data loaded for use in the game or in a tool.

All resources need a support code file, but they should be short.

4.2.2. Making Custom Tools

Using the Quipkit editor's GUI feature, tools can be made to help create and edit map, tile set and sprite set resources. These tools can be as simple or as complex as we like. If we're just making our Island Dude game quickly, we may just add bare-bones features and leave it at that. If we're making tools that players can use like a level editor, or want to share our tools with the hypothetical Quipkit community, we need to think about ironing out bugs, adding features and polishing the user interfaces.

4.2.3. Make the Resources

With external and internal tools, we can now make/obtain resources that Island Dude can use:

  • Title screen background
  • Menu backgrounds
  • Menu cursor image
  • A font for the menu options and battle display
  • The island map
  • The island tile set used by the map
  • The sprite set of the dude for the map and battles
  • The sprite set of the monster for the battles

4.3. Testing the Game

The Quipkit editor should have a toolbar button to quickly launch the Quipkit engine so that we can quickly try out the game.

By default, the Quipkit engine starts in no game state whatsoever, i.e. the game state stack is empty. An init script is run, and its job is to add a state to the stack, as well as any other setup.

In testing, the Quipkit editor provides the ability to provide testing init scripts that can load any state, as well as load a save file and even set variables in any game state. This makes it easy to test lots of different situations in our RPG. Island Dude is probably too simple to benefit from this, but if it ever got bigger, this feature could help a lot.

For now, we just need to write a simple init script to kick off our game in the Title Screen State.

5. Summary: The Finished RPG

Well, that's all! Here's what we hypothetically did:

  1. Designed the game states and resources
  2. Wrote code for the game states
  3. Wrote code for the resources and tools
  4. Made resources using our tools
  5. Kicked off the game with an init script

Our hypothetical indie RPG Island Dude is finished! We can now give ourselves a hypothetical pat on the back, and feel hypothetically proud of ourselves.

6. Conclusion

Quipkit, once somewhat complete, should provide something along the lines of:

  • core engine and editor
  • game state framework
  • resource framework
  • scriptable tools
  • configuration of tool access from the editor
  • kicking off from an init script

There's still plenty to do on top of this. Resources are still pretty vague. There's no details about how tools are configured to match up with resources. How would external tools access the parts of a resource that are made of more than one file? Should multi-file resources even be allowed?

Quipkit may provide a game engine, editor and frameworks, but its core focus is scriptable tools that know about the games we're making. This feels like the missing gap in both open-source and proprietary offerings.

This hypothetical indie RPG should hopefully put the tools and frameworks in perspective of the bigger picture of making a complete RPG that could be further extended.