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.

Play some Supreme Commander to get an idea :)

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.

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.

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!

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.

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.

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!