Thread: Tactical TBS Game...

I'm seriously contemplating making a tactical turn based strategy game in C++, with the SDL libraries. Like most TBS's, the map is going to be divided into a grid of small rectangular sections, and I plan to have a number of 'properties' assigned to each section. The map is intended to be fairly large (300+ sections, so about 7500 pixels wide), though this is entirely optional, and I've seen more CPU intensive games (I would assume) than what I would expect this one to be.

To make a long story short, I was wondering if SDL is a good library to make such a game with right off the bat, or if I should pick a different library. Also, I was planning to hold info about each tile in an array ( like array_name[position_x, position_y, property], and then have property 1 for instance be the type of terrain, and either assign it a character string or an integer corresponding to a specific type of terrain -probably the latter of the two); I have some practice coding in C++, and quite a bit in a number of Basic varients, but I still have this sneaking suspition that I'm doing something wrong and am going to create a monster of a program, as far as memory leaks, resource consumption, et al, goes.

Thanks for any help.

I was wondering if SDL is a good library to make such a game

Well, I have tried to make a similar game with SDL. My experience hasn't been too good I must say. SDL is surely an OK library (better than Allegro, at least), but you will maybe experience some problems with speed. The problem here though, isn't that SDL is very slow, but rather that the code that is dealing with the drawing operations is not enough optimized. For a programmer who knows what he is doing very well, and one who has written games before, this is surely no problem at all. If you haven't done much programming though, it may well be a bit of a challenge.

On the other side SDL is easy to learn and is rather simple in use for simple purposes.

But I wouldn't have advised you using it. If I were you, I would have chosen OpenGL. It is faster and, in my opinion, much more convienient as soon as you get used to it. (There are of course many more advantages too). But, again, OGL isn't easy to learn for a beginner.

(300+ sections, so about 7500 pixels wide)

This is not a problem at all. The point is that you have an array of these objects in computers memory, but you do not draw all of them at the same time. The trick is to draw only those tiles which the user can see. Everything beyond screen borders must be left alone until the character on the map has moved and a new section of the map is revealed.

This means that after all you will only be drawing, say 10x10 tiles, at a time. That isn't much. Actually 300 quads at the same time isn't much either (unless the textures are very comples of course or the CPU is busy doing something else). So , again, that is not a problem.

I was planning to hold info about each tile in an array

That is certainly a good idea. in your case it can well be a 2-dimensional array, like Objects [x][y]. That will probably make coding a bit easier for you. (Note: x and y in Objects[x][y] are NOT coordinates on the screen)

but I still have this sneaking suspition that I'm doing something wrong and am going to create a monster of a program, as far as memory leaks, resource consumption, et al, goes.

Well, that isn't anything you should be worrying about. All of us have to start some place or another. Take me as an example. My first games were not just ugly, but also contained many memory leaks, and crashed every second time I launched them. But after I spent some time developing new games, trying different approaches and just having fun, I am now able to build better games. And I am sure you will be able to do the same.

So good luck with your project!

Well, considering I can't get SDL working right, I'm probably going to have to code it in another language. I'm thinking about XBasic (if that's too slow, someone tell me now so I don't end up hurling my computer out the window), but I'm still looking around. Anyway, thanks anyway (though I'll still use the array idea for simplicity).

By the way, I was speaking of terrain tile specifically, so I was going to have something like Map_Tile [x][y][p], and then give each [p] value, at each [x][y] position, a value that would effect the functions (as in actual functions, not C++ functions like void main() and such, though it would probably end up running as a function anyway). Like, randomly give the tiles different properties, and then when interacted with (i.e. displayed, moved onto by a unit, terraformed, et cetera), run it through a series of if-then statements. That's why I was worried it'd slow it down (though I can't really think of a faster way to program it)...

I think I'm using improper terminology... By tile, I meant one square of the map, not the graphic to represent it's type (of terrain, in my case). I'm planning on storing the tile assigned to each sector of my map(s) as a property in the array (i.e. for the sector at position 2, 3, I would have map_sector [2] [3] [1] = "a number that corresponds to a terrain type", assuming property 1 is the terrain type property in my arrays; then I would have an if-then statement that would place the proper graphic for the terrain type on the x y position of the sector). In other words, the graphic would be a property of the sector of the map at hand, a property corresponding to the terrain type. Navigatability would be a seperate property (the rock could increase movement, if I so chose).

In any case, there's not much point in replying here since I've decided to make the game in XBasic (before you guys bite my head off, read my previous post). Thanks for the advice.