Death and rebirth: my own roguelike reloaded

Hi there! Time to spend some words on what my Xarr project has been.

Project is dead, but it was not a death without a sense. It teached me a lot on OpenGL, but my goal was to make a roguelike, and so I switched to the classic ASCII style, embracing the *curses libraries, because graphic issues was becoming overwhelming and my interests was in the game not in the graphics mechanics this time.

Xarr is ended with my @ wandering in a maze and with a couple of S randomly moving all around. Good enough to end a demo.

The new project is something more… mature. Its codename is Dunia. I have a couple of great ideas, but I don’t want to tell about them now because of the fear of can’t accomplish them.

Up to now, Dunia comes with a @ exploring a loaded map. I said “exploring”, not “wandering”, because a field of view algorithm has been implemented, as written here.

Also, a “look” command has been implemented, as well as a “grab” command, a “drop” command and a “view inventory” one.

Oh, and there is also an “open” command! @ can move in all directions and collisions are rightfully detected.

The map features plain walkable squares, walls, doors (opened and closed) and furnitures. I defined “furnitures” all the items the player cannot grab, such as statues, but that are sensible to the look command. A nice feature a suppose.

By now I have only one kind of item: food. What else?!?

The look command in action

The inventory screen and the drop command

Line of Sight algorithm: Bresenham

While I was working at my roguelike I faced the issue of what player can see.

This issue is known as Field of View. In a roguelike, player lives in a grid-world. His field of view are the tile he can see all around, given a certain range (influenced tipically by lighting). One of the possible methods to resolve this is using a line of sight algorithm, usefull also in other circumstances.

The plot is simple. Can player see from his position A to position B? If a rect line can be traced from A to B without passing through an obstruction (wall or whatever) he can.

Calling this for every end point of the area around the player results in the field of view. Sound simple, but it’s a bit tricky to implement.

I started with a couple of implementation of mine, based on the rect-between-two-points equation, that sounds like this:

(y – y0)(x1 – x0) = (x – x0)(y1 – y0)

and I reached a quite good result. In my game, player has a sight of 6, which means he can see at 6 cells, or tiles, around him. With this, almost the full area was correctly filled but some cells did not obey rightly.

After a bit of headache I opted for google and found this nice article on Bresenham line drawing alg.

Copy/paste on my routine, made some little edit and the result is pretty good. If you are looking for a line of sight algorithm I suggest it. It worked for me.

Bye.

My Own Roguelike Part 3: Loading/Saving

I made some progress and archived part 2. Now the camera follow player in a correct way (thanx Tristam! ) and I haven’t the blinking problem yet. I’ve added a “tell me what I’m doing” feature to the message handling component, so that now a green writing serves as narrating voice at every action the player performs (walking, up to now). Collision detection with walls is also active, and a “Ouch!” message appears when it happens.

I positioned the camera higher and more distant, in order to haven’t to rotate the view to see the hero when a wall is between.

Now I have to make the loading/saving routines. I already made a load function that loads a map of arbitrary dimension and it works great. Screenshot shows this feature in a 15×21 map.

I’m very excited because, after the save method, I will enter in the real domain of the project: monsters and interaction! Bye!

the load map feature

My Own Roguelike: part 2

A little update on development of my roguelike.

A first attempt in creating the floor

In Part 2 I have to deal with the map. First, I started drawing something under my character. I defined my map as the most simple thing: a matrix of uint. I implemented the matrix not as array of arrays but as vector of vectors, using the plain good old STL. After that, I have filled my matrix with 0s and then, in the draw() method, drawed a red square of given width cicling my matrix.

Next, I opened blender and modeled a cube (well, it was pretty easy since a cube is the default mesh as you open blender…). After a bit of UV mapping a texture was applied to my cube.

I decided to maintain the old tile method, but using 3D tiles instead of 2D ones, and so a cube in place of a square. Quite straight, isn’t it?

So I went up with my textured cube. I placed some 1s on my matrix and coded a routine that draws the cube in the right position according to the position of 1 on the matrix.

first blocks of terrain in my world. @ is not alone now!

Ok, shame on me for my graphic skills in doing the texture, but it works. Ah, I also coded the routine to load texture and UV coords from .X files. If someone need of it… maybe I’ll do a post for it.

It’s been a little issue to define a unit of measure in order to make all the same size: the @’s steps and the tiles I mean. In the end I calculated the minx and maxx for the blocks and it gave me their length. After a bit of attempts I came with a correct @ position and step.

Next, It was the time to apply a texture to the floor. Not only: the floor has become made of tiles too. I modeled a simple little plane, scaled it as the blocks and textured. Now, when processing the matrix values I place a floor tile for 0s and a block tile for 1s.

To make possible exploring the map I wrote a routine for the camera to follow the @. But here I have a question: I used the gluLookAt, but in order to appreciate changes I have to switch everytime to projection matrix and call glLoadIdentity on it. This give me an annoying blink effect I would like to avoid, but at the moment I don’t know how.

an entire level textured

Next, to complete step 2, I have to deal with wall collision detection, but this is very simple. Since it’s turn based and movements are steps of predefined lenghts, I can simply use the 2D method: look at the terrain matrix and its 0s or 1s values. I think I’ll do a little refactor after that, ’cause my code is becoming messy in some points.

My Own Roguelike: part 1

So I decided to write my own roguelike.

Fine. In this article on roguelikedevelopment.com I found an interesting starting point.

The author lists 15 steps to develop this type of game. Shortly:

1. Decide to write a game
2. Hello World!
3. It’s a boy!
4. The map
5. Saving/Loading
6. It’s alive! Alive!
7. Interaction
8. Data files
9. Items
10. Magic
11. Simple game
12. Levels
13. Experience
14. Citizens
15. Free at last

Step 1 is rather easy and yet completed. My roguelike will be something about a bad guy named Xarr hidden in the deeper level of his ultra deeper dungeon, the Kingdom of Evil.., and a good guy must reach and defeat him. Sounds original, uh?

Step 2 is quite simple too. I opened my code::blocks, created a new project and imported libraries from Pong to create an OpenGL graphic context with SDL and manage some basic input. Compile, run et voila, my Hello World works without surprises.

Step 3 is the first real milestone. I have to display something on screen, and this something is no less than the player. Yes, the good guy of my plot. The hero. Well, in most modern games this will require a beautiful textured mesh, but in Roguelikes the hero is simply a @, which really simplify life. But, as said in previous post, I want to make this game something between classic ASCII roguelike and modern 3D RPG. So I opened Blender, modeled a @ and exported. Now I have my beauty 3D version of the hero.

Author of the article seems to follow a XP way, because he repeat more than one time to not troubles about planning everything or write the best code from the beginning. Implement only what serves at the moment seems to be the rule, and so I do.

Player class is born, featuring a draw() and move() methods.

The last issue is text. After a bit headache I opted for a temporary solution: using SDL_ttf library. Probably I will look for some other solutions, maybe FTGL.

It’s all for now. Next I will face the map.

The Hero wandering in the empty world

What about a Roguelike?

Next project as I have in mind to deal with is a roguelike.

Yes I know, this is a huge amount of work, and probably it will not end as good as Pong… but I really want to try.

I have an idea about the interface. I would like to keep using OpenGL and the little framework builded for Pong, and so using a graphical user interface instead of text. But I love text-only roguelike, I found them … poetic, while tile-based are often nothing more than… 80ish (maybe because tilesets are always the same in all games, since about 20 years i think!).

But my roguelike will use 3d graphics in a nice way. I’ll keep the classical @ and other symbols, but they’ll wander in a 3d dungeon with textured walls and floors.

This is my Colombo’s Egg. I always wanted to develop an RPG but 3d modeling or even 2d graphics always represented a big obstacle. Maybe this time I’ll be able to move some more steps into this dream!