Very basic game programming help and advices

[Miramon]

Ok, fine. Success!

Now it runs at 195 FPS where it ran at 9 FPS before :)

I commented out a single line. I think it re-drew the dungeon once for every monster present (so when it takes 4ms to draw it once, and you multiply it for 20-30 monsters, then you get enough ms of delay to slow down everything).

195 FPS without any optimization, that is. The standard map mode runs easily at 300-400 FPS.

After a while you will get to the point of expecting your problems to always stem from some horrible stupid thing you've done yourself, and when you actually find a bug in a library or OS you won't be able to believe it :)

[HRose]

The problem was that I didn't know in any way how much "room" I had for my code. So it was even possible that the game ran poorly as a fact, and so requiring a technical level that I can't afford.

But since it's now 195 FPS unoptimized then it's more or less exactly where I expected it. Lots of room. So now it will be easier to figure out if I ran into a limit or if I did something wrong.

I'm not interested at wasting my time with optimization already. As I'm not interested in elegant code. It's already enough that something works. And the idea of not having enough room to work in was CATASTROPHIC.

[HRose]

And to start well the new year I think I managed to fix the bug in turn based combat that sometimes gave garbage values in the initiative list and moved monsters that were not in sight.

The bug was that the initiative values were stored both in the monster vector and in a vector used just for initiative. When turn happened I cycled trough the monster vector to check if the initiative values matched. The problem, I think, happened when values matched for monsters that rolled for initiative in previous turns (and whose initiative value weren't cleaned).

Anyway, every new turn now I reset the whole monster vector so that everyone has initiative at -1, before rolling for new initiative. And that seem to have taken care of the problem. Now everyone participates in combat when on sight, is properly ordered, and properly takes turns.

Now as far as I know, this last version does everything as it is intended to, and there shouldn't be bugs in the flow (and this includes the fixes to the performance bug previously discovered): http://www.cesspit.net/misc/prog/foe031.zip

[wordswords]

This looks great, well done for getting this far! Could you post the source code for your latest version? I am writing a roguelike and would like to find out how you implemented some of the features.

[JoshV]

The bug was that the initiative values were stored both in the monster vector and in a vector used just for initiative. When turn happened I cycled trough the monster vector to check if the initiative values matched. The problem, I think, happened when values matched for monsters that rolled for initiative in previous turns (and whose initiative value weren't cleaned).

Hmm, rather than a vector of initiative values, could you just store the monsters that are in the combat, in a vector, sorted by initiative value?

[HRose]

This looks great, well done for getting this far! Could you post the source code for your latest version? I am writing a roguelike and would like to find out how you implemented some of the features.

Those links I post contain source code. But my source code is a mess, so you can just ask or read the thread, since I explain what I'm doing.

I think I finished to update maps to the larger size so that now they all scroll. The next step should be about starting to play with more varied dungeon generation, but I can't find any decent tutorial about that.

Also, usually implementing something takes about 20 times more work and time than I expect. So before I can have some results it will be a while :(

Hmm, rather than a vector of initiative values, could you just store the monsters that are in the combat, in a vector, sorted by initiative value?

Maybe, but there were a bunch of hurdles when I made that. So there was probably a good reason why it ended up like that. And right now I want to move on to see something different.

[Miramon]

There are large numbers of open source roguelikes around to look at, including mine of course, though omega is so old now you'd probably have to violate some kind of law against defiling graves if you wanted to look at it.

[HRose]

As I said, my programming skills aren't high enough to make me understand and use someone else's code if it's not followed by some in depth explanation of some sort.

Figuring out an existing game would require me as much time and work as writing my own from scratch. So it's just not possible, I'm far from that point.

You really made Omega? Wtf are you doing out of the business then?

[HRose]

Ok, last version before I start breaking things:
http://www.cesspit.net/misc/prog/foe033.zip

This only enlarges the map area to 220x140 cells. Supporting visually three scales: the full 220x140 (subcell 8x8), 110x70 (8x8 tiles) and 55x35 (16x16 tiles).

[HRose]

Here's something new:





This stuff uses a really stupid way to make the map. It simply starts in the center, rolls up a number between 1 and 4 (N,S,E,W) and then moves in the corresponding direction through a switch. Then it digs out the current location.

And finally it has some random chance of spawning a new "digger" who's fit in the vector and so starts moving on its own.

This also guarantees everything is connected, since the diggers move out from the center and only spawn from known locations.

Though this isn't exactly what I wanted. I want more varied locations, with doors and other things that make sense. But I'm also realizing that in many cases this is achieved by pre-building rooms manually, and then only randomize how they are connected, like the "random" dungeons of Daggerfall.

[Miramon]

You really made Omega? Wtf are you doing out of the business then?

Heh, thanks. I did it as an alternative to actually working in grad school. My first non-trivial C program. I was flattered to be told once that the code had been used as an idealized example of data-driven programming in some CS course: then they told me it was cited as an example of what not to do....

[wordswords]

Those links I post contain source code. But my source code is a mess, so you can just ask or read the thread, since I explain what I'm doing.

Ah thanks, I didn't realise the code was all in a single (!) CPP file :)

Usually what happens in these projects is that it becomes harder and harder to add new features to a codebase that is messy. Eventually it becomes so difficult to add features that you are forced to give up or reorganise.

But you seem to be going strong and adding new features, so you must have quite a strong natural programming ability. Just out of interest, how many hours have you spent on the project approximately?

[HRose]

I still have to learn different files juggling and for now it's not necessary.

No idea how many hours since I work on this sporadically and it depends if I have a clear picture of what to do. Most time is spent tracking bugs or understanding what the library lets me do.

[Clay]

I still have to learn different files juggling and for now it's not necessary.

No idea how many hours since I work on this sporadically and it depends if I have a clear picture of what to do. Most time is spent tracking bugs or understanding what the library lets me do.

It's actually very simple. You might want to take an hour and start a different throwaway project, just to get comfortable with it. Once you get the hang of it, you'll be glad you spent the time.

[HRose]

I'm thinking how to deal the map.

Right now it's sort of non-existent. It simply uses an internal map thing of the library that is used to check line of sight. It's essentially a structure with two boolean values: whether the cell is walkable, and whether the cell lets pass light.

There's nothing else. The map is simply drawn accordingly to walkable/non-walkable to print either a wall or a floor. This means that the map can show a grand total of two features. A wall and a floor.

Now this is obviously far from what's ideal. I want varied maps that can display a great variety of environments. Change the colors of walls and floors, changing their tile and so on.

So I'm thinking what's the best way to do this (that is simple and flexible so that I don't need to rewrite it at some later point). I could do in layers. For example I could make an "object" layer that drops objects in the map, so that if there's a door, I handle the door as a layer that is drawn on top of the basic map.

But I also don't want to repeat everything. Maybe I can add this other layer that holds for each map cell a boolean with an override value. So, if false, the map-drawing function defaults to the current barebone behaviour, while if the override is set to 1, then it looks into some other member variable that could contain an index with all possible tiles. So if cell 56 has the override set to 1, then it looks into its property, which corresponds to some arbitrary 324, which is equal to "wood floor", and so I print on screen the wood floor tile. So my "advanced" map would be a structure made by a boolean + int (for every cell).

MIRAMON, how did you handle maps? Layers? All into one thing? How many properties?

[HRose]

Sort of implemented doors:



And now they block the visual too (otherwise they are inert, open and close automatically as in Star Trek):




OMG ITS STARTING LOOKING LIKE A GAEM!

[HRose]

The implementation of those door is quite lame.

Basically it has nothing to do with rooms and corridors logic. Doors are added when the dungeon is done.

This means that I had to write a sort of door logic. It checks EVERY empty cell in the dungeon. Then it looks if there are adjacent supporting walls. Then starts checking nearby space to detect some sort of open space that would define the threshold to a room. Nested "if"s as usual.

It's horrible, but it works. Like all I've done.

for (int i = 0; i < MAP_HEIGHT ;++i){
        for (int l = 0; l < MAP_WIDTH ;++l){
            Door door1(l, i, 0);

            if(!map_array[i * MAP_WIDTH + l].blocked){ // if cell is free
                if(map_array[i * MAP_WIDTH + (l-1)].blocked && map_array[i * MAP_WIDTH + (l+1)].blocked){ // H walls
                    if(!map_array[(i+1) * MAP_WIDTH + l].blocked && // S
                        !map_array[(i+1) * MAP_WIDTH + (l-1)].blocked && // SW
                        !map_array[(i+2) * MAP_WIDTH + l].blocked && // 2S
                        !map_array[(i+2) * MAP_WIDTH + (l-1)].blocked ){ // 2SW 
                        
                        doors.push_back(door1); // creates the door
                        map_array[i * MAP_WIDTH + l] = Tile(0,1); // makes the door-cell block LOS
                    } else if(!map_array[(i+1) * MAP_WIDTH + l].blocked && // S
                        !map_array[(i+1) * MAP_WIDTH + (l+1)].blocked && // SE
                        !map_array[(i+2) * MAP_WIDTH + l].blocked && // 2S
                        !map_array[(i+2) * MAP_WIDTH + (l+1)].blocked){ // 2SE
                        
                        doors.push_back(door1);
                        map_array[i * MAP_WIDTH + l] = Tile(0,1);
                    } else if(!map_array[(i-1) * MAP_WIDTH + l].blocked && // N
                        !map_array[(i-1) * MAP_WIDTH + (l-1)].blocked && // NW
                        !map_array[(i-2) * MAP_WIDTH + l].blocked && // 2N
                        !map_array[(i-2) * MAP_WIDTH + (l-1)].blocked ){ // 2NW 
                        
                        doors.push_back(door1);
                        map_array[i * MAP_WIDTH + l] = Tile(0,1);
                    } else if(!map_array[(i-1) * MAP_WIDTH + l].blocked && // N
                        !map_array[(i-1) * MAP_WIDTH + (l+1)].blocked && // NE
                        !map_array[(i-2) * MAP_WIDTH + l].blocked && // 2N
                        !map_array[(i-2) * MAP_WIDTH + (l+1)].blocked){ // 2NE
                        
                        doors.push_back(door1);
                        map_array[i * MAP_WIDTH + l] = Tile(0,1);
                    }
                }

[amandachen]

What if you want to have rooms (with doors) and caverns (no doors)?

[HRose]

It simply doesn't run the make_doors function if I'm generating the cave-like thing. I guess I could even mix the two map styles in one if I give the generation some boundary boxes.

Otherwise I think I could safely enable it too, since it's the layout that would prevent many doors appearing in the cave map, I guess. But some would show for sure.

[HRose]

Now the tile mode also has doors appearing properly:

[HRose]

Experiments...