[MAPSCRIPT] Eyeball Planet

LPlate2

Warlord
Joined
Dec 27, 2018
Messages
299
Hi,

It's been a while since I've done any modding but this is my first attempt at a mapscript.

The mapscript is for an eyeball planet (http://nautil.us/blog/forget-earth_likewell-first-find-aliens-on-eyeball-planets), i.e. one that is tidally locked to its sun.

There are three map specific options; cold, warm and hot. In the warm and hot versions, there is an impassable (represented by peaks) desert in the centre of the map. The sun makes it too hot for life to survive in this desert. The cold, night side is similarly impassable, so the outer edge of the map is covered in ice and there's no x/y wrapping.

The latitudes increase from the centre/desert edge towards the circumferential edge. On the warm and hot versions, there's only an annulus where life can exist. On the cold version, the full map is playable.

The map is based on Terkhen's Discworld.

(The Ringworld mapscript, with settings for latitude to go from equator to pole could also be used to represent a game in the narrow livable region of an eyeball planet.)

Edit: Latest version available at https://forums.civfanatics.com/resources/eyeball.28735/.


LPlate
 

Attachments

  • ColdEyeballStandard.PNG
    ColdEyeballStandard.PNG
    39.2 KB · Views: 501
  • WarmEyeballStandard.PNG
    WarmEyeballStandard.PNG
    39.3 KB · Views: 510
  • HotEyeballStandard.PNG
    HotEyeballStandard.PNG
    36.6 KB · Views: 562
Last edited:
I had never heard of this type of planet, pretty cool, thanks for posting the script. For once a world map without unrealistic wrapping. I haven't played a game yet, only generated some maps and ran them on AI Auto Play. Perhaps the size should be reduced a bit, especially for the "Hot" setting: Hot Standard size is 188x188, which is more than three times as many tiles as Huge Fractal (128x80), and Large actually crashes for me during map generation. Even on a Tiny Hot map, the AI managed to found more than 100 cities in total in my test run, so I think the whole thing, including the habitable zone, is oversized. On a Tiny Warm map, a got 70 cities and 55 on Tiny Cold. This isn't a major problem, of course, as one can simpy play on Duel and Tiny maps. Tiny Cold actually seemed like a good size for the usual 7-8 players (screenshot attached; sadly can't zoom out further).
 

Attachments

  • Civ4ScreenShot.jpg
    Civ4ScreenShot.jpg
    186.3 KB · Views: 330
Hi,

Thanks for the feedback.

I had the scale adjusted based on the selected map size but had not allowed for the lower proportion of ocean in my map's playable area versus the default map. My instinct would be to scale the current height and width by 0.7.

How many cities are regarded as expected for the different map sizes and how is AI Autoplay enabled in vanilla BTS?
 
How many cities are regarded as expected for the different map sizes and how is AI Autoplay enabled in vanilla BTS?
The Python console can be opened with the [^] key, and then game.aiplay x runs the AI Play function for x turns. This deletes the player's civilization and can't be interrupted.

I don't know any widely accepted reference numbers. For Standard size, the default player count is 7, which seems to result in about 6 cities per player on Pangaea. Fractal tends to allow a bit more space, 7 to 8 cities, though not all land is necessarily reachable from the beginning. So I'd say 50 (~7x7) city sites would be a reasonable number for a map like yours. That also makes it possible to get 6 (mature) cities for Oxford University without starting a war. For the larger sizes, the number of cities per player increases (given the default player counts in BtS), but by how much exactly? I guess one would have to guess or experiment with AI Auto Play or write code that counts the resources placed on the map – I think that's a pretty good measure of the space for expansion.
 
Thanks for the advice f1pro.

I've rescaled the maps to give ~50 at the Standard map setting.
This rescaling also means the Huge Hot map works fine also.
I did one further tweak to give a few jungles on the Cold Eyeball.

Edit Version 1.1 has been superceded by version 1.2. See https://forums.civfanatics.com/resources/eyeball.28735/.
 
Last edited:
I've tried a few size/ type combinations; yep, looks good now. :thumbsup:

I've had one other thought: Sometimes fertile land, e.g. with a food bonus, is directly adjacent to impassable desert. A ring of passable desert (but without rivers) could smoothen the transition; see the attached screenshot (done quickly in WorldBuilder, resources also placed by me). Based on this little test, it seems that non-desert paths are generally faster than desert paths because of roads, though the desert does allow civs to bypass neighbors whose borders they can't enter. The way the map generator normally works, there'd be a slight abundance of desert resources. I don't know if this would be an improvement, all things considered. Visually, the bright ring makes it look less like an eyeball ...
 

Attachments

  • Civ4ScreenShot225.jpg
    Civ4ScreenShot225.jpg
    344.1 KB · Views: 292
Hi,

I don't have an issue with the occassional piece of very fertile land bordering the impassable desert. The climate could be quite chaotic with the extreme heat and extreme cold at either side of that narrow habitable band. If it was predominantly very fertile adjacent to the impassable desert, then that would look wrong though and I'd need to revisit it.

I would not like to create the passable desert walkway all the way around the impassable desert as i like that naval techs may need to be developed to fully explore the habitable land.

If I did revisit it, I think the approach that I'd use would be to have a check at the end of terrain generation and change any of the land/hill plots that are adjacent to the impassable desert to desert (or possibly plains in some instances) and leave any ocean plots as they are. I'll give people time to play with the mapscript and see how it looks and plays before doing any further work on it.

Thanks for your help and suggestions.
 
I've noticed a small bug:
The first three getInfoTypeForString calls in the file need to be getTypesEnum. Or, actually, since those values are never used, the calls can just be deleted. So, completely inconsequential unless one uses a DLL with enabled assertions. I only bring this up because you and I had been wondering about those failed assertions a year and half ago in this thread (which I didn't want to necro).
 
@f1rpo, you're a star. I've been ignoring that error message for so long now, I'd assumed it was something I did when first starting on the DLL, never realised it was caused by this. Uploaded new version with this fixed in the downloads.
 
Thanks for the script, Mr Mordhau
 
Top Bottom