Sign in to follow this  

turn-based game questions

This topic is 4695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm currently in the early stages of designing a turn-based strategy game (with abstract units on a terrain). I'm going to use SDL and OpenGL. I think I will restrict the user to looking at the map top-down, and within a continuous but not too large a range of zoom levels, but I will allow them to rotate the map about the z-axis (which points perpendicularly out of the screen). I think with these restrictions there are going to be some advantages for me the programmer. But I'm not sure what exactly. Can you think of any advantages to this approach? I don't really want to get into ROAM or other simplification algorithms, because I'm scared of them. Would my game be ideal for brute-force rendering? I assume it would be ideal because I wouldn't have to draw all of the map, just a small portion of it, the portion that's visible (easily calculated because it's top-down). And then maybe I could use a simplified texturing approach. But again, I'm not sure what. Any ideas or criticism would be appreciated.

Share this post


Link to post
Share on other sites
Quote:
Original post by cragwolf
I'm currently in the early stages of designing a turn-based strategy game (with abstract units on a terrain). I'm going to use SDL and OpenGL. I think I will restrict the user to looking at the map top-down, and within a continuous but not too large a range of zoom levels, but I will allow them to rotate the map about the z-axis (which points perpendicularly out of the screen). I think with these restrictions there are going to be some advantages for me the programmer. But I'm not sure what exactly.

Can you think of any advantages to this approach?


It should simplify things some. On the different aspects:

1) top-down. Unless you're going to have like bridges which units can go underneath as well as over, you don't even have to really worry about the 3rd dimention, and instead render things atop each other as needed. Aka, render the map, then the units on top of it, then the overlaying UI, etc...

2) not too large a range of zoom levels. Limiting the range won't help much, but it'll prevent you from having to try and playtest with different settings trying to make the game look good at a large range of zooms. May or may not make a difference - but this is pretty easily changeable, so, you can allways change your mind later.

3) Rotating around the z-axis. Should be easy. Just adds a glRotatef call, right next to the glTransformf call you'll do to do scrolling, and the glScalef call you'll do to do zooming.

Quote:
I don't really want to get into ROAM or other simplification algorithms, because I'm scared of them.


While it's a bit irrational to be scared of them, it's fine to avoid them - especially if this is one of your first major projects :). A top-down view won't have any noticeable culling (except for the FOV/Field Of View - aka, dont render what's way off the left of the screen, way off the right, etc - this will be easy with your top-down view) so these will have limited benifits anyways.

Quote:
Would my game be ideal for brute-force rendering? I assume it would be ideal because I wouldn't have to draw all of the map, just a small portion of it, the portion that's visible (easily calculated because it's top-down). And then maybe I could use a simplified texturing approach. But again, I'm not sure what. Any ideas or criticism would be appreciated.


Yes, this should lend itself well to "brute force". Well, of course it depends on your definition of brute force, but... yeah, rendering a few hundred quads shouldn't be that much of an issue.

If you wanted to further optimize the outer zoom levels, you might try combining texture tiles. Aka, you might have 4 possible variations on a corner tile (say, of land corners) you might reduce that to 1 in an outer zoom, but combine it with neighboring tiles. Or, approximate, aka, using just poor ASCII art:

Close Zoom:

+----+----+
| | |
| | | <--land tile
+----+----+
| | /|
| | /~| <--land/ocean tile
+----+./--+

Far Zoom:

+---------+
| .'|
| /~~|
| .'~~~|
| /~~~~~| <-- 3 land + 1 land/ocean tile combined intoo a single land/ocean
| .'~~~~~~| at farther zoom.
+'--------+


Quote:
Original post by Telastyn
You might not want your heart set on the rotation. It makes said calculationa nd rendering a bit more tricky.


If he's using OpenGL it should be a piece of cake to add. Just add a glRotatef call next as mentioned above. If you're refering to the culling outside the screen bounds, there's a cheap shortcut we can take: for the sake of rounding all that off, draw a large square of the terrain, in which the 'screen view' should fit at all rotations. Aka:

One rotation:
+--------------------+
| | <--- rendered
| |
| +------------+ |
| | screen | |
| | | |
| | | |
| +------------+ |
| |
+--------------------+

A different 90 degree rotation:

+--------------------+
| | <--- rendered
| +----------+ |
| | | |
| | screen | |
| | | |
| | | |
| | | |
| +----------+ |
+--------------------+

A 45 degree rotation
(poorly drawn):
+------------.\------+
| .' \ | <--- rendered
| .' \ |
| .' \ |
| .' screen .' |
| \ .' |
| \ .' |
| \ .' |
| \.' |
+--------------------+

Share this post


Link to post
Share on other sites

This topic is 4695 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this