As a French person I feel like it's my duty to explain strikes to you. - AdrienIer

Create an account  

 
Donut-shaped Map

So a few years ago (here) I raised the prospect of a donut-shaped map. The premise was that because of a hole in the center, each player would only have two fronts to worry about, rather than having to worry about the space all around them (depending on start location). This makes some things easier strategically -- for example, you only have to face two other players at any given time, at your clockwise and counter-clockwise fronts -- but some things more difficult -- for example, a runaway Psilon on the other end of the map is harder to reach, though it also means it'll take him longer to reach you (giving you more time to prepare). RefSteel kindly made some trial maps of the concept here.

Well I never got around to testing (i.e. playing) them, but the mathematical problem related to this has stuck around in my head. The problem is, given an initial distribution of stars, how do I map the stars' coordinates into a map with a hole in the middle, while maintaining an equal density of stars all across the map? By "equal" I mean that if the initial map is uniformly distributed (i.e. each region of the initial map has an equal likelihood of stars), the mapping would end up with a final map that is also uniformly distributed (i.e. each region of the final map still has an equal likelihood of stars), within the donut-shaped region. The reason why this is important is that without this consideration, the mapping may end up with clumps of stars next to each other depending on what part of the map the stars were at. Note that I don't know if MoO's placement of stars really is uniformly distributed (other than a blank area near the borders), but I'll assume that it is.

I got around to solving this mathematical problem a few days ago. I'm not sure if it's correct, but I *think* it is. There's basically two components to this: from a radial direction (i.e. inward or outward from the center of the map), and a tangential direction (i.e. moving along a circle of a given radius from center of map).

For the radial component, assume that the width of the initial map is 2*s1, the height of the initial map is 2*s2, the inner radius of the new donut is r1, and the outer radius of the new donut is r2. The star is currently located at (x, y), where these are the horizontal and vertical distances, respectively, from the center of the map (both positive and negative numbers possible; the save file stores them as from the upper left corner of the map, i.e. positive numbers only). Let d/s be the max of abs(x/s1) or abs(y/s2), i.e. a ratio of how far the star is from the center of the map, relative to the edge of the map, in concentric rectangles. Then, radially, the radius of that star in the new donut is given by:

r = (r1^2 + (d/s)^2*(r2^2-r1^2))^0.5

For the tangential component, if you took slices of equal radians (i.e. same number of degrees) from the center of the map, you'll find that the slices toward the corners have more stars compared with the slices toward the middles of each side. But say you took slices such that it divides each side into the same sized chunks, i.e. say to each quarter of each side (i.e. draw lines to 0*s, 0.25*s, 0.50*s, 0.75*s, 1*s where s is the length of each side), each of those slices have the same area and thus the same density of stars. So to equalize to theta, you just project each star's coordinates to the border and measure how far it's moved along the border. The formula for this is a bit more complicated simply because there are if cases, but if the star is in the right part of the map (i.e. a line from the center of the map to the star's coordinates projects to the right border), the formula for the theta (in degrees) is 45*y/x, if it's to the top it's 90 - 45*x/y, if it's to the left it's 180 + 45*y/x, if it's to the bottom it's 270 - 45*x/y. Note that these coordinates are for standard Cartesian plane, not MoO's coordinate system, but the transformation is easy to do.

Finally, if you want to (roughly) maintain the same distance between stars, the area of the donut has to match the area of the original map, so that the overall star density remains the same. This is easy; the original map's area is simply width * height, while the area of the donut is simply pi * outer radius^2 - pi * inner radius^2. Note that this requirement plus the donut's inner radius will uniquely determine the donut's outer radius; similarly, this requirement plus the ratio (outer radius/inner radius) will uniquely determine both the inner and outer radii.

An image showing the mapping using Excel is below:

   

As you can see, the new map is somewhat bigger than the old map, because of the hole in the center. To maintain the same density, stars that were originally near the center of the map tend to be squeezed (closer together) radially, while stretched (farther apart) tangentially. The closer they were to the center the bigger this distortion is. For example, in this case, a star originally along the edge of the map (i.e. d/s = 1) has very little distortion; it's stretched tangentially by around 2.3%. A star that was about halfway in (i.e. d/s = 0.5) is stretched tangentially by around 35%, while a star that was about 3/4 of the way in (i.e. d/s = 0.25) is stretched tangentially by around 123%, with the reciprocal change in being squeezed radially. If I did the derivation correctly, though, each unit area of the original map should be transformed to an area of the same size in the new map.

So how does this work with MoO? Putting this into a script into Matlab that changes the stars' coordinates in the MoO savefile (as well as adjusting the size of the map), the original and new maps for a huge sized map look like:

   

   

Note that the new map is actually bigger -- as evidenced by the location of the nebulae, whose coordinates were not changed. However, for whatever reason, the size of the viewing area (the rectangle indicated by the 4 corners that's supposed to represent how much area you see when in regular view) didn't get smaller to reflect the larger map size; I don't know where that parameter is located in the save file. (Note: I know that MoO apparently only grabs that parameter the first time you load a game, and after that it doesn't change this parameter, even if you load games of different map sizes; however, this was from a fresh load of MoO.) A view of the area around the starting point, for the original and then the new map, is below:

   

   

The right, bottom right, bottom left, and left stars used to be 3, 3, 4, and 3 parsecs away, respectively. After the transformation, they're now 4, 4, 5, and 3 parsecs away. Meanwhile, the purple star to the upper left used to be 10 parsecs away but is now 5 parsecs away, due to the squeezing in the radial direction. So the bottom left star (which was close to a tangential direction) is now somewhat farther away, while the purple star (which was close to a radial direction) is now closer. The other stars, which were a mix of the two, had their distances adjusted somewhat but not too much. I don't know if this is ideal; I think "ideal" is really something more like if a typical star usually has say 5 stars within 5 parsecs, then after the mapping it should still (on average) have 5 stars within parsecs. I don't know if maintaining the same density achieves this, but hopefully it's a "good enough" approximation to start.

(more in the next post due to attachment limit)
Reply

How might this play out in an actual game? It seems like it's doable, but you still have to try this with a number of maps to get a good one. For example, I mentioned here that the idea is for example to play as the Mrrshan, who normally gets dogpiled, but having only two fronts to consider at a time might make things easier. So I tried this donut script on a medium impossible map, and the before and after are below:

   

   

The Alkari, Silicoid, and Meklar, which used to be relatively far apart, are now a lot closer due to the squeezing along the radial direction. Compare their before-and-after distances:

   

   

Again, this is because the mapping tends to squeeze along the radial direction (while stretching along the tangential direction). So it probably works better with maps where the homeworlds are initially far apart tangentially.

Anyway, I'm not sure if I'll have time to play a map like this any time soon, but I thought it was an interesting problem mathematically, and may open up some interesting ways to play the game.

P.S. So for savefile editing, I wanted to mention Sargon0's savefile reference here:

http://realmsbeyond.net/forums/showthread.php?tid=2891

Things like the nebulae positions should be changeable, and you *should* be able to change the coordinates of ships/transports that are enroute to another star as well. Although note that in the latter case, the distance may be much greater/lower than what they were previously, depending on the direction they were heading in relative to the center of the map. This should probably only be done at the beginning of the game anyway.

Also, in the code, I wrote an exception where if a star were in the very center of the original map (and thus had a radius of 0), it would be placed in the very center of the donut. But it's also possible to do something like stick Orion in the center of the donut, which may make for some interesting strategic possibilities since if you can take (and hence reach) Orion, you basically get a shortcut star that can reach just about anywhere on the donut.
Reply

So something like what I had in mind are in the before and after maps below:

   

   

The human player as Mrrshan start in the south part of the map, on impossible difficulty. If he goes clockwise (to the left), he eventually encounters the Klackons who, due to their isolation and race bonuses, will likely be pretty strong. If he goes counterclockwise (to the right), he eventually encounters the Humans, Darloks, and Silicoids. On the far side is the Psilons, who may reach runaway status if they're left alone for too long. So the player has to decide between going up against one strong computer or three weaker computers before encountering the Psilons. If he decides to go after the Klackons first, he may get bogged down early when the player is usually weaker relative to the computers. If he decides to go after the three weaker computers first, he may potentially face a runaway Klackon by the time he defeats the potential runaway Psilon. On the original map, the player maybe has a similar decision to make -- but he could have expanded toward the middle to be closer to everybody involved, and grabbing the middle tends to be a good strategy in many strategy games anyway. With a donut-shaped layout, it removes this option, forcing the player to decide which computer race to go through, with the Psilons as a ticking clock on the other end.

Am I reading the strategic implications of a donut map (as compared to a regular map) correctly? Any thoughts on this? If I have time I'd like to play this map, but I'm not sure if I'll have time plus I'm really rusty at this point with MoO's game mechanics so I'll have to read up on everything again.
Reply

Since there are really only two directions to travel through the galaxy, it seems like a donut map would make it very easy for a race to get "squeezed" between two races that just happened to be close.

In your last map, compare the starting postions of the Silicoid or Darlock (squeezed) vs. the Klackon or Mrrshan. This would increase the chance of a runaway empire that was able to claim many systems uncontested and then protect them all behind fleets defending the border colonies.
Reply

Your images aren't showing for me? Oh, it shows now AFTER I logged in... shakehead

In any case, playing MoO 1 with any other shapes besides the default rectangle would prove to be an interesting experience! That's the biggest reason why I added support for galaxy map shapes using image files in my game I'm working on. You can see that I made my own donut-shaped galaxy here!

http://beyondbeyaan.blogspot.com/2015/04...-dust.html

The relevant image being this one:

http://2.bp.blogspot.com/-VhN-ZVufv00/VU...Galaxy.png

Mind sharing the save file? I'll give it a try and see how it fares! EDIT: Doh! I skimmed too quickly, you included link to RefSteel's post, my bad.
Dominus Galaxia, a Master of Orion inspired game I'm working on.
Reply

I would almost think that a donut-shaped map would help the human player, even in the case of runaway Psilons. The problem with the computer AI players are, the longer the game goes on, the more options are opened up in the technology tree, and the harder a time the AI has actually using the technology that it has. I've seen runaway AI players time after time again build stupid stuff like cloaked nuclear missile fighters. I feel like, the longer the game goes on, and the longer the human player can survive, then the better the odds are at winning, assuming that the human doesn't have a supremely stunted initial opening.

I'd rather face an endgame runaway AI where its tech levels are 70 and mine are 40 than face that same AI earlier when its tech levels are 20 and mine are 10. There are way more tools in the toolkit for the human to use to outwit the AI by the end of the game. And the donut map would seem to help the human reach the endgame without having to deal with some of the AIs if the human didn't want to, which counts as a plus for the human in my book.
Reply

Oh, the reason why the viewing rectangle didn't shrink when viewing the overall map is that they're actually a graphic file. If you open up the LBX files with LBX Extractor utility I wrote, you can see there's four versions of the viewing rectangle, one for each size. So you'd have to edit the graphic to have it be accurate, which is too much work at the moment as LBX extractor can only unzip, but not zip up the images.
Dominus Galaxia, a Master of Orion inspired game I'm working on.
Reply

(January 13th, 2016, 11:02)Ray F Wrote: Since there are really only two directions to travel through the galaxy, it seems like a donut map would make it very easy for a race to get "squeezed" between two races that just happened to be close.

Well, keep in mind that there's a difference between the donut map as a concept and my coordinate transformation. Yes, a donut map means that you only have to deal with two races. And that's the purpose, so that it's more consistent the maps that you get. Otherwise sometimes you're in the corner and you get your own stockpile of stars, or you're in the middle and you get fights from all sides. As for the transformation, IIRC part of the star-generation code is that each homeworld starts out at least 7 parsecs away from each other. Because of my transformation, it basically stretches that in one direction while collapsing it in the other so that you can end up say 3 parsecs away in one direction (radially), but 14 parsecs away in another (tangentially). It really depends on the starting map though.

(January 19th, 2016, 21:47)Zeraan Wrote: Your images aren't showing for me? Oh, it shows now AFTER I logged in... shakehead

Yeah, I noticed that...has something to do with that I uploaded the images directly to the forum, as opposed to hotlinking them offsite, I think.

(January 19th, 2016, 21:47)Zeraan Wrote: In any case, playing MoO 1 with any other shapes besides the default rectangle would prove to be an interesting experience! That's the biggest reason why I added support for galaxy map shapes using image files in my game I'm working on. You can see that I made my own donut-shaped galaxy here!

http://beyondbeyaan.blogspot.com/2015/04...-dust.html

The relevant image being this one:

http://2.bp.blogspot.com/-VhN-ZVufv00/VU...Galaxy.png

Mind sharing the save file? I'll give it a try and see how it fares! EDIT: Doh! I skimmed too quickly, you included link to RefSteel's post, my bad.

Hey, neato! Yeah ultimate a coordinate transformation of an existing map file is a hack, and being able to generate a desired star map layout "natively" is better. It's interesting how you do it from an image file, which allows the user to give any desired arbitrary shape. Maybe each player starts in their own isolated cluster. Or maybe each player is at the end of a starfish-shaped arm, and the middle is a number of rich/ultra-rich/artifact worlds (although that would take the map image having colors to tell the generator what type of planet).

Um yeah it was on another computer, I'll have to dig up the save file. Actually I ended up playing from a different save game, both the original version and the transformed version, and it did turn out that it played pretty differently once transformed to a donut.

(January 19th, 2016, 22:23)Psillycyber Wrote: I would almost think that a donut-shaped map would help the human player, even in the case of runaway Psilons. The problem with the computer AI players are, the longer the game goes on, the more options are opened up in the technology tree, and the harder a time the AI has actually using the technology that it has. I've seen runaway AI players time after time again build stupid stuff like cloaked nuclear missile fighters. I feel like, the longer the game goes on, and the longer the human player can survive, then the better the odds are at winning, assuming that the human doesn't have a supremely stunted initial opening.

I'd rather face an endgame runaway AI where its tech levels are 70 and mine are 40 than face that same AI earlier when its tech levels are 20 and mine are 10. There are way more tools in the toolkit for the human to use to outwit the AI by the end of the game. And the donut map would seem to help the human reach the endgame without having to deal with some of the AIs if the human didn't want to, which counts as a plus for the human in my book.

Hmm I hadn't considered that -- that against a runaway player, if you survive long enough you can end up outwitting the computer to win with enough tech levels. Would that really help you though if the computer itself is already coming at you with death fleets? I mean, I don't know if there's enough time to tech up to level 40 if they're just steamrolling down the donut long before then.

(January 19th, 2016, 22:26)Zeraan Wrote: Oh, the reason why the viewing rectangle didn't shrink when viewing the overall map is that they're actually a graphic file. If you open up the LBX files with LBX Extractor utility I wrote, you can see there's four versions of the viewing rectangle, one for each size. So you'd have to edit the graphic to have it be accurate, which is too much work at the moment as LBX extractor can only unzip, but not zip up the images.

Huh, interesting. Yeah I didn't know it was just a graphic file, makes sense though.
Reply



Forum Jump: