HoI/Total War Style Map

Game Mechanics
#1

Hello Everyone,

for my new project I need a Campaignmap in the style of Hearts of Iron or Total War.
Heres a pic if you dont know what it is:
http://l.yimg.com/eur.yimg.com/xp/justgamers/20090713/14/3516518288-hearts-of-iron-3.jpg

I got a basic idea:

A province is a object holding all the information, e.g. position (x,y), id, adjectant province ids, sprite and a polygon for collision detection.
I would then render the images with the x,y position and if the player clicks on one of the provinces I know which one, via point in polygon.

Is this a good idea? Or does anybody have a better idea? Especially with the adjectant provinces or map managment?
With polygons it would get very tedious to actually make the map, as I would have to get a map with point data and then manually create a polygon for each province.

#2

I would say you either make each province a separate image with the parts outside of the province transparent so you know if the user clicked on it, or just one picture for the entire map and only make the icons click-able. Adjencent provinces still will to be defined or you will have to write a smart piece of code which detects which province has non transparent pixels next to another provinces non transparent pixels.
Making all the area’s polygons is a lot of error prone work.

#3

But how would you pick an image? I understand, that you would technically pick and check if the pixel is not transparent. But how would you know what image you are picking. Also how would you tint the image with the corrospondent owner color.

I just talked to my father, who programms in graphics and has done alot of picking in them. He said I could make them all meshes (he has the point data) and fill them via opengl. (would look rather fugly though.) and then pick them.

My thought was to make the armys and cities as seperate images ontop of one big worldmap and only make those clickable.
I would make armys and cities as seperate images with a hitzone so I can pick them. Id still have the problem of not being able to tint the provinces.

#4
  1. For each region:
  2. Check if mouse is inside region bounding box (= inside the image).
  3. If it is, check if the pixel under the mouse is transparent.
  4. If it is transparent, you’ve found the region that is being clicked.

Assuming OpenGL, what’s wrong with glColor3f(r, g, b) for team color? Maybe multitexturing, or just a shader that adds the team color to the region color? It should be easy anyway.

Drawing lots of stuff just for picking seems like a bad idea. Picking also forces the CPU and GPU to synchronize in a way that they aren’t really meant to do for optimal performance.
If you draw each region as its own image, why is team colors a problem?

uniform vec3 teamColor;
uniform sampler2D image;

varying vec2 texCoord;

void main(){
    gl_FragColor = texture2D(image, texCoord) + teamColor;
}

Could be done with multitexturing or something else too, but that is trickier (if you ask me). With a good texture even glColor3f(teamColorR, teamColorC, teamColorB) should work fine.

#5

Thanks, that should work. The whole polygon thing didnt want to work anyways…dont know i guess my math wasnt to great.

#6

Okay, I haven’t gotten very far, mainly because I still tried it with vectors. I now trashed that idea, because its too hard for me.

After starting with your idea of every province a image, I soon got confronted with a problem: aligning the images to one big map.
e.g. making them fit snuggly together so there is no gap between them.

Maybe there is a trick to this world map…hexagons or some kind of hidden tiling.

Any ideas, even the most weirdest are welcome. No answer is wrong…i guess ^^

#7

For what it’s worth, he’s how I’d do it:

Input data:

  1. One big image for the map shown to the user.
  2. One colour map for province/region detection. This would be the same size as the map, but each province would be drawn in a different RGB value.
  3. Some kind of metadata file that links RGB values in ‘2’ to province info (name, adjacent provinces, etc.).

At load time you can use the colour map to slice up the big image into province images.

At run time you can draw the big image to show the map. Clicks etc. can sample the colour map to decide what region is clicked on. And you can use the generated province images to show the selected/highlighted provinces.

It’s a bit heavy on memory if you have really big maps, but click detection is really simple and it’s dead easy to hand-paint the collision map from the visual map. It might be a bit tedious creating the metadata file, but I think that’s going to be tedious any way you do things.

#8

Thats a pretty good idea. I like that alot. Picking that way should be rather easy that way.

I’m only irritated on how you would actually slice them up.

#9

You mean the load-time step? I’d think something like:

1 for each province in metadata:
2 find bounding box by looping over all pixels and finding those that match region rgb
3 create province image the same size as bounding box
4 for each pixel in province image
5 test if colour map pixel matches current region rgb
6 if match, copy pixel from full map image
7 otherwise, set pixel to transparent
8 store province image with (x,y) offset from origin of full map image, along with province metadata

That’s a lot of looping over all the pixels, and it could probably be made faster by calculating all the bounding boxes in one pass, but it’s load time, so it probably doesn’t matter too much. If it’s really slow you could just do this step as an offline tool and dump the result into a binary format to load if speed is an issue.

#10

If I understood correctly:

1.Grind through all pixels.
2.Find the most upperleft pixel and the most lowerright pixel.
3.Create a bounding box.
4.Then copy the pixels from the worldmap onto a new image, leaving all other pixels translucent.
5.The offset is the most most upperleft pixel
6.Store the new image in the province object.

Sounds like a plan and I will most defintily make an offline tool. Thats crazy amount of grinding. And since this game is supposed to be for android. I rather not give the droid a huge amount of data to go through.

Also that seals how I will make my map editor :smiley:

#11

Just a small note: Not the upperleft pixel and lowerright pixel, but the highest and lowest x and y values. Treat x and y separately. :wink:

#12

Yeah^^ I just noticed that when I went to bed

#13

This thread has caught my interest.
I too have wandered how one would code those character selection screens that you see in some games. (The one’s where you see 5 or so characters and when you mouse over, one character is in colour where-as the others are greyed out silhouettes)

ps: heres some JS examples of the sort of thing OP is looking for.
http://www.netzgesta.de/mapper/

#14

Oh wow. Thats exactly what I need.
I’m not great in JS so I can’t really translate this to java.

How does this work, it seems to not use a colorcoded image and a metadata file like Orangy explained, only the baseimage. This would save alot of time if there was something similiar to this in Java.

I’m really getting worried this game will be more time consuming than I imagined it to be…not that that would be bad, its just with the more work I put into it the bigger the danger gets that I get frustrated and abandon the game at some point, which would actually be too bad, because I really like my idea and would most defintitly want to play it myself :clue:

And I thought the KI will be hard to code ::slight_smile:

#15

Looks like it’s going with the vector approach (a bit like your original method), and getting the input vectors from an SVG file. If you wanted to do it that way I guess you could look for SVG loaders for java, I think Slick had one but I don’t know how good it is.

#16

I’m currently bound to libgdx, because thats the library that supports Java for Android.
I’d rather use Slick but slick doesnt have a android library yet.

I think I’m going for the image splitting and colorcode version. Let’s hope that works.

I’m still open for new attempts at solving this problem.