Sign in to follow this  
Sylon

Will my 2D TB Strategy game be slow?

Recommended Posts

Hi! This question might be a big one mathematically, not sure. I'm an artist also, not a programmer but I want to know if my idea will make a slow game for PROCESSORS (not concerning net connection speed). Basically in my sci-fi turn-based strategy game I would like the "Giant" map to allow room for 12 players, each with at least 400 population max (the allotted time for taking turns in this game may last a day to a week[?]). The player will have a completely orthogonal overhead view of the map, which will be made of 16x16 tiles. I want the giant map to be able to at least be 2560x2560 tiles (1,677,721,600 pixel area). This map will also have height levels (graphical layers that the player can cycle through, inside anything bigger than a tank such as a large ship or house or building, even inside trees to see the levels of their branches and if anyone is hiding in them). The soil can be destroyed to make underground tunnels, which can sneak underneath the basements of a constructed building. Submarines can go underwater and underneath battleships, etc. Every 16x16 tile will have its own HP and "Armor" and a few other stats. ALL structures (usually 20x20 tiles) that are built will have destructible 16x16 wall tiles, from the interior and the exterior. Infantry can walk into those structures and if you click through the height levels you will be able to see the different floors of the structures. It's basically a 2d game with an orthogonal view and square collision detection, but which behaves kind of like 3d games. So let's say a giant map has about 48 layers of "height," from the bedrock to the sky above mountains. But the sky will mostly be transparent anyway, so let's give a rough estimate of about 36 layers of height concerning graphics. That means, in this map, there would be about 1677721600x36 pixels stored in the memory somewhere which = 60,397,977,600 and 90% of those 16x16 tiles will have their own HP statistics and animations and reactions to the environment, not to mention their own "damaged" frames of destruction and animations and the other 1000s of objects on the map. Remembering the RTS Command and Conquer on the Playstation (which was something crappy like 33 mhz?), things were really slow, but my maps are much larger and have many graphical layers and each tile has destructible statistics the computer must remember. However I guess RTSs might be slower than TBSs. Sorry I don't know much about memory and processing speed and stuff, but does anyone think this game will be slow with 12 players even given today's standard Ghz processors? Because, I KNOW 3d games use a lot more pixels and bigger objects but the terrain usually doesn't have its own unique stats and animations at the 16x16 level, right? And don't 3d games use more equations to draw on the art on screen than rasterized images (don't rasters take more space?) Even playing Age of Empires 2, a 2d isometric RTS, with its giant map (smaller than mine and which didn't have as many layers), with 8 players max and 200 population max per player, starts to slow down maybe 15% offline even with a 1.6 Ghz processor!!! Anyway thanks for helping and, thanks for reading, I know this is a big post.

Share this post


Link to post
Share on other sites
Processors aren't going to be the problem with your idea. It's memory. You essentially have a giant "cube" tile map with a size of 2560x2560x48. This accounts for almost 1.2GB just to track each individual slot in the tile and nothing else (a huge 2560x2560x48 3d array of integers).

My first suggestion is cut down on the number of height layers in your 3d map from 48 to 3. Air, surface, and under ground/water.

If you need several layers for things such as structures, then a programmer can set that structure on the surface of the map, then allow that one structure to track what's at level 1, level 2, etc inside of it without a bunch of wasted map space.


3d games do not generally track unit's positions through "layers" in the height. They essentially have one giant cube area that everything fits inside of. Every object in the game has a 3d position (x,y,z) and the game draws that object there. Likewise, in a 3d engine, the engine doesn't keep track of individual pixels. It keeps track of each objects position and the corners or vertices of the object. It then draws the object by connecting the vertices together and applying the proper image or texture file to the object.

Share this post


Link to post
Share on other sites
Pickled-- That game looks awesome! Yeah I've seen it before. It doesn't have exactly everything I want but it has a lot more things that obviously my 2d TBS won't offer, especially the epic R-T battles!

Caspian-- Ah, see I thought something would make my game less efficient!

Wait so the processors aren't the problem? Let's say the programmer goes ahead and makes the 48 layers, with all its wasted space, LOL. Are you saying that processors would still be able to play the game at normal speed, but that there would be a lot of wasted space (is it RAM or something?) used up within the computer?

Anyway thanks, that was a good answer. I'll have to rethink stuff.

Share this post


Link to post
Share on other sites
From a designers point of view, do you really need that many blocks? Various things can happen: players will either concentrate on small parts of the map, making the rest more or less useless, or players will work on a larger scale, ignoring much of the detail in the map. Large maps won't magically make your game better, they can easily make it worse.

Not to mention how complicated the layer system would work: that's an open invitation for micro-management, leading to long turns. And waiting for someone else to finish up his turn could be quite boring. Besides, cycling between layers just to see what you're actually dealing with... I don't think it'll work really well. Don't get me wrong, the concept sounds interesting, but I can see various issues popping up here that need to be adressed.


As for the technical side, I'd leave that up to a programmer if I were you. A common approach is to build some stress-test prototypes to see what's possible, what's very hard to do and what's simply impossible, and work from there. For example, the numbers you mentioned are usually not decided up-front, but derived from various tests. Is it possible to have that much blocks? If so, does it lead to fun gameplay, or would smaller maps be more manageable?

Share this post


Link to post
Share on other sites
Captain P--

Thanks! Yeah I've thought about many of the qualities in my game and how to deal with the boredom and the micromanagement and stuff, yeah, it takes a lot of work but I have ideas, anyway. Plus the long turn thing, I was actually planning on that being the case - there already are some games out there where the turns can take days if there is a high time limit or something.

There is actually a reason I want to derive those map numbers beforehand - I'm not just arbitrarily picking them out because it makes a nice 3d-ish game set on a big map, it's because I need to know the max map size so I can calculate the unit statistics in a more balanced way (particularly in this case the movement stats). For example the movement of the units may just be 40 tiles per turn - therefore the big map doesn't become so hard to cross, etc., but I can still have room for gameplay details on the smaller level. For example how many turns will it take for an infantry unit to cross the map vs a flying unit? I am testing out how things will look, and testing scale ratios, in MSPaint, and every statistic I am putting a lot of thought into how it can be balanced between civilizations.

------------

But basically what I'm reading from you is that, it might just not even be possible to have that many blocks, we'd have to test it out. What is the limit, the actual numbers themselves may be too much for the computer, or it all just might take up too much RAM? Which, in the case of the RAM, the computer would only need to have a horseload of RAM to play the game, right? Is there an actual physical limit to computer coding that can't be overcome by superior technological development in the realm of speed and memory? Hehe.

By the way your AI WARS TBS looks interesting!

Share this post


Link to post
Share on other sites
Quote:
Original post by SylonBut basically what I'm reading from you is that, it might just not even be possible to have that many blocks, we'd have to test it out. What is the limit, the actual numbers themselves may be too much for the computer, or it all just might take up too much RAM? Which, in the case of the RAM, the computer would only need to have a horseload of RAM to play the game, right? Is there an actual physical limit to computer coding that can't be overcome by superior technological development in the realm of speed and memory? Hehe.


Assuming infinite memory and infinite calculations per second, you can pretty much do anything you want in code without worrying about efficiency.

Barring that, however, you have to worry about those things. And what you have suggested would be fairly simple from a processors point of view to handle. While the tile map total space usage is huge, the dimensions are relatively small. And being turn based, it's not going to be limited by the processor.

That said, you're looking at taking up over a gig of RAM just for a single 32-bit integer value in the height map. And that's before you try and load images and statistics values for all your units. In other words, yes, you would need a horseload of RAM. Especially considering most people only run 1-2GB (and 4GB or 8GB is the most you'll find in just about any standard desktop system) - and your game won't have access to all of it, seeing as the operating system and any other processes running will still be using them.


I think the point is, your game doesn't need all that space for what it sounds like you're trying to do. If it does, then you'd be better off using a real 3d engine rather than trying to simulate a 3d environment with that many height layers.

Share this post


Link to post
Share on other sites
Caspian, wow, awesome answer, good stuff to know!

I might consider maybe, bringing it down to 1280x1280x10 tiles (16,384,000 tiles).

Two last questions:

How did you get the 1.2 Gb RAM calculation off the 2560x2560x48? You multiplied the total amount by 4? Is it 4 bytes per tile, or does that vary depending on the programmer and other considerations?

Then I'd also have to multiply the pixels in each image of each frame of animation and stuff, per object, right?

Theoretically** If I create ALL the 2d art in the game, what would I have to multiply in order to find out how much RAM the graphics will take up alone?

I kinda just want to know the equation for determining that stuff. After posting this I will try to research it on my own on the web.

And then yeah that RAM would not even be including sound files, AI files, etc. etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sylon
There is actually a reason I want to derive those map numbers beforehand - I'm not just arbitrarily picking them out because it makes a nice 3d-ish game set on a big map, it's because I need to know the max map size so I can calculate the unit statistics in a more balanced way (particularly in this case the movement stats). For example the movement of the units may just be 40 tiles per turn - therefore the big map doesn't become so hard to cross, etc., but I can still have room for gameplay details on the smaller level. For example how many turns will it take for an infantry unit to cross the map vs a flying unit? I am testing out how things will look, and testing scale ratios, in MSPaint, and every statistic I am putting a lot of thought into how it can be balanced between civilizations.

So you've already been thinking about these things? That's good. :)

However, you can't calculate any realistic values up-front: reality will always throw up some surprizes. Balancing multiple units is especially tricky, since they affect each other and there are likely many more factors involved that you just don't see untill you're actually playing a prototype. That's not to say that doing some maths and thinking beforehand is bad, certainly not, but don't assume you can do everything on paper.

What might be more helpfull, at this stage, is writing down the dependencies. For example, unit A should move faster than unit B, but should not be able to traverse terrain X. Unit C should have transport capabilities. Units A and C should be able to traverse a map in roughly 6 turns and the player should be able to build them in turn 4, so combat can roughly be expected from turn 10 on forwards. So, no exact numbers, but usefull information for when the testing starts.

Either way, level designers tend to create maps of varying sizes, which can result in different tactics being used. That's good, as it ensures some variety. Don't stick too much to one map size, experiment with different approaches. Adding some unit A-only obstacles here and there can result in a totally different gameplay. :)

Quote:
By the way your AI WARS TBS looks interesting!

Thanks. :) We made it for an AI class at school. A friend wrote an AI client for it so we could watch some fireworks, but it's not really humanly playable. I was planning to release it last week but didn't have much time for it, but a download link should appear on my blog within a few hours now. Thanks for the reminder. ;)


As for memory, integer numbers are often stored in 4 bytes, so if you use an integer for every block, you end up with (block_count * 4) bytes. For images, it depends on their format. A 32bpp image takes up 32 bits per pixel, which is 4 bytes per pixel. So, a 32bpp, 512x512 image would take up roughly 1 MB.

Share this post


Link to post
Share on other sites
Wow, thanks! Yeah I just found something explaining all that image memory stuff. Man, I have a lot to learn. Programming has always intrigued me but when I try to study it in-depth, I get flustered!! Of course, I heard C++ was a little bit tough anyway.

Thanks for your help!

Share this post


Link to post
Share on other sites

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