Developing a Rogue-Like Top-Down RPG Game in SFML

I’ve been busy developing one of those old-school 2d RPG games in the past week. It’s still far from complete, but I thought I should just document a bit of the development process. Firstly, I chose the Simple and Fast Media Layer (SFML) API for graphics, sound and input processing. Why? Because unlike SDL it has a C++ OOP Interface and I don’t have to deal with all the ugly C stuff and Pointers. It could have been a bit better though, if it implemented exceptions instead of returning error codes. For example

try
{
    img.LoadFromFile("my_img.png");
}
catch(ImageNotLoadedException& e)
{
    ...
}

Is much better, in my opinion, than

if (!img.LoadFromFile("my_img.png")
{
    ...
}

Anyway… Where was I?

Well, I began with creating some custom classes. I created a Player class for the main character. Next I created a Tile class for the RPG tiles. I derived both of them from sf::Sprite. Next I created three classes for level parsing. LevelReader, LevelSymbolTable and LevelRenderer. Although I am parsing the level line-by-line instead of character-by-character, it still works pretty well. A typical level script for the game looks like this:


// Level 1 Map
// Comments start with '//'
// Symbol -> Tile Assignments start with '=>'

=> G ? data/tiles/grass.png ? false
=> W ? data/tiles/wall.png

// Symbol Representation of the Map
WWWWWWWWWWWWWWW
WGGGGGGGGGGGGGW
WGGGGGGGGGGGGGW
WGGGGGGGGGGGGGW
WGGGGGGGGGGGGGW
WGGGGGGGGGGGGGW
WWWWWWWWWWWWWWW

Now the above script renders this:

The syntax for a symbol – tile assignment is

=> {Symbol} ? {Filename} ? optional {Solid} ? optional {depth}
// e.g
=> A ? Wall.png

All tokens are separated by a ‘?’. The first token is the symbol which is later used for representing the tile in the map. The second token is the filename of the tile’s image. The third optional token is for setting whether the tile is solid or not. If the tile is solid, it will collide with the player. Otherwise, the player will just walk over it. Hence the ‘false’ at the end of the assignment for ‘G’ tells the level parser not to make the player collide with the grass tile. Finally the last optional token, ‘depth’, sets the depth level of the tile. It should be a value between 1 and 3. Tiles with depth 1 will be drawn first, followed by tiles with depth 2 and then depth 3. Depth 1 and 2 are drawn before the main character, depth 3 tiles are drawn after the main character, hence the player will walk under tiles with depth 3.

Next, I wrote code for camera management, so that the main character can scroll around even if the level script is bigger than the screen resolution. I also wrote collision detectors and handlers.

Currently I’m coding a ‘text area’ class in order to display updates and messages. I’m in a hurry right now, so I’ll explain the whole process of developing the game in detail in later posts, perhaps even create some tutorials.

Advertisements

2 comments

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s