c7-game / prototype Goto Github PK

The AI should factor in resource location when deciding where to settle cities.

Eventually it should also consider whether it already has that resource (it's more important to secure iron if they don't have any), but that will require having a way to figure out which resources they have. For now, just make sure the AI adds some priority to it.

With the existing weights, IIRC coastlines get +10 bonus. I'm thinking luxury resources should be at least the same, and strategic double.

Resource yields should also be considered in the AI's calculation as to where to settle - much better to settle on plains with cows than without.

This is a more advanced one, after #92 and #91 . Currently, the AI only considers tiles immediately next to cities. This is pretty much okay early on since those will be the tiles that the city works. However, there should be some consideration of the tiles in the BFC (big fat cross) as well, and the AI should also consider whether tile improvements can increase the yield - notably, Hills and Mountains get +2 shields with a mine, versus +1 for other tiles, which is worth something, whereas tundra cannot be irrigated, and volcanoes cannot be mined; volcanoes should be considered less valuable than mountains despite the same initial tile yield.

The improvement weights should likely be considerably less than the base yields, to avoid the AI hamstringing itself by choosing tiles with low yields early on. Desert can be improved just as much as grassland, but is a much inferior choice early on, for example. The AI should also likely consider an either/or for food/shield improvement, since you cannot make both. Intuitively, I'm thinking 1/3 the weight of base yields, although that may be too high or too low. Make it configurable.

BFC weights should also be considerably less; we don't want the AI choosing locations because there are a bunch of cows right outside the new city's borders. But if there are two locations the AI is considering and one has Game outside the borders and the other doesn't, it's a tiebreaker.

It may be necessary to bump the base yields to make these lower weights feasible, e.g. the value of a base commerce might be 20 instead of 2. Alternately, we could use floats so we have decimal weights when dividing.

The current state of the demo map is not a base for the future and is starting to cause a dev bottleneck.

Implementing the more feature-full map display of the TempTiles is a good base to move forward with, but as a side effect we'll lose terrain generation as that is not sophisticated yet.

As a first step I'll hard-code a feature-incomplete map extracted from a real Civ3 save and display all base terrain types.

I want to

• Warn if the save json isn't found and copied into the artifact but not fail
• For Mac, add the json in the zip archive output by Godot export
• For Mac and Linux, name their archive files with the suffixes

They should be imported and displaying on the map.

We seem to be using a very different style than the default Godot one, which is white text on a dark background. So, we have a lot of one-off overrides. It's probably time to bit the bullet and add a global style theme.

Stumbled upon this while reviewing Jim's PR.

Steps to reproduce:

1. Find a Windows box without Civ3 installed, or (more plausibly, since we all have Civ3 installed), rename the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Infogrames Interactive\Civilization III to something else temporarily, so C7 won't find it.
2. Run C7

Expected: You are able to select the Civ3 home.
Actual: C7 crashes. Output:

Unhandled Exception:
System.ArgumentNullException: Value cannot be null.
Parameter name: path1
  at System.IO.Path.Combine (System.String path1, System.String path2) [0x00003] in <1400ea11d6fd49d4939be686a9549fb4>:0
  at Util.FileExistsIgnoringCase (System.String exactCaseRoot, System.String ignoredCaseExtension) [0x00001] in C:\Development\Civ Related Projects\Prototype\C7\Util.cs:60
  at Util.Civ3MediaPath (System.String relPath, System.String relModPath) [0x0008e] in C:\Development\Civ Related Projects\Prototype\C7\Util.cs:109
  at MainMenuMusicPlayer._Ready () [0x00002] in C:\Development\Civ Related Projects\Prototype\C7\MainMenuMusicPlayer.cs:14

The fact that it can't find the main menu music is a red herring, the real problem is that it's even trying to despite the registry not containing the expected key. The relevant code in GetCiv3Path():

                // Look up in Windows registry if present
		path = Civ3PathFromRegistry("");
		if (path != "") return path;

It turns out that the method we use in Civ3PathFromRegistry to check the registry returns null if it doesn't find anything, but out code expects it to return the empty string.

Of note is that I've tested this on Windows 8.1 64-bit. I know the Windows registry format has not been entirely the same for the past 30 years, so it's possible that it does return the empty string on another version of Windows. I have separate registry-parsing code for pre-and-post-Vista in my editor, so it's not a wholly theoretical possibility.

Covered in PR #86 . The AI should not send settlers where other settlers are already going.

Sea/Ocean appear visually, but are not imported as terrain types on tiles in the script.

Flood plains aren't added yet. They kind of look like desert but there is a floodplains.pcx file. It looks like it is only used along flood plains that are near a river. So maybe this task should just be import script support, and we'll enhance it when we add rivers?

Once we have another mp3, general-purpose-ize our mp3 support.

This should probably be in a GitHub Wiki (to be added), and linked from the main Readme. Maybe we already have it somewhere, but if so I'm not sure off the top of my head.

Things to include:

• How to download and compile. Including that you'll need Godot Mono, latest 3.x
• Recommended IDE setups that we can help you with (VSCode + Godot, Rider)
• Link to the CFC discussion forum, as the main discussion area. Probably to the Discord too.
• Link to the "good first issue" issues, and note to open a pull request, probably from a fork initially for first-timers.

Maybe some other things I haven't thought of.

We can build a city with a settler, but not yet display it on the map. This is a logical next step, and also an important one leading towards being able to build things (mostly, Warriors).

Marshes. Hopefully adding support for these doesn't bog us down too much.

As discussed some in forum, removing some of my older cruft now that more devs are on the project.

The unit cursor is not being drawn 100% accurately. The trouble here is that the cursor seems to require special shading rules, i.e., the rules for how to color each pixel of the cursor based on its color palette index are not the same as for any other FLC. I created a custom shader for the cursor and added some logic so it looks decent but it still needs to be perfected.

ref https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site

11/15 - Basics done. Can add some more things like figuring out the "selected" text color, and general-purpose confirm/cancel buttons. But functions shared by 2+ popups (currently) are now in PopupOverlay.cs.

This corresponds to #80, which taught the AI the very basics about sending out settlers and building cities.

I'm mainly writing this issue up retroactively to test out the milestone feature, which appears to be useful for organizing issues by type.

Right now, imported games from non-English variants of Civ will not render the map correctly as the names are hard-coded to English.

Puppeteer and I have discussed this on the forum and have agreed that a key is a decent way to implement this, where the key may be the English name. This still allows for a more user-friendly approach to editing scenario files than the integer approach that Civ uses.

Display rivers on the map.

TBD: How much we care about "special" river features like corner-only rivers, waterfalls, and deltas at this point in time.

Right now we can play the sounds accompanying animations but only if they're stored as WAV files, and many are in AMB files. The first step is to decode these files. As of writing this, I have done most of the job but haven't finished and polished the results. If anyone is interested in working on this, contact me and I'll send you what I have. Otherwise I'll update this issue when I'm done with the decoding, whenever that will be.

In the first iteration, settlers would only settler near their home city.

They should be willing to travel farther afield, as all the good locations near their home city will eventually be taken.

Covered in PR #86 .

In PR #86 , the settlers can spread out across the continent... except some get stuck trying to go around bays due to the shortest path being across water.

This will improve their pathing so they can go around such obstacles.

Covered in PR #85 .

While overhauling the map code, I'm finding I need a native save/object format, or at least the beginnings of one.

Have been experimenting in TileMap/TileMap.tscn standalone scene

• 87381ff - Scrolling via buttons with no wrap using KinematicBody2D with no texture or collision shape and Camera2D
• 479ba3d - Can click & drag mouse to scroll and zoom with mouse wheel (no wrap)
• 42a9336 - In Experiments/TwoNodesSameReferenceScroll.tscn tried to duplicate Node2D for seamless scrolling of test icon hoping that child nodes are referenced not duplicated
• 309351c - Proof that the child nodes are duplicated and not the same, so this tactic probably not helpful

Ideas:

• Might be able to copy texture of ViewPort without re-rendering tiles; e.g. render once, steal the texture to draw in another Node2D
• Might segment map horizontally into chunks and have only the necessary chunk duplicated at any time; still duplication, but less of it
• Might segment map horizontally into different Node2Ds and just translate them as needed, but would reduce the max displayable width

Now that QueryCiv3 should handle bics with and without custom rules properly, ensure modRelPath being passed to Civ3MediaPath and we should get modded terrain when a modded sav is imported

Arguably Dutch, but we might want this for Carthage since being able to tell who's units are whose will be useful for prototype combat.

Extract popup logic from Disband Confirmation and make it general-purpose. Likely will go hand-in-hand with adding another popup.

Linux and Windows auto build artifacts are working, Mac not. Want to fix directory structure inside tgz files.

Might try to get Mac working; might try some input parameters to name export folders.

Add the bonus grassland overlay.

These use the "desert" TNT overlay, specifically the 4th row down (first row being row 1) in Art\Terrain\tnt.pcx. I have not determined which one Civ uses, and in my editor use a deterministic calculation based on the tileIndex % 3. I suggest we start with something equivalent; if someone really cares and knows how it's determined, great, but the important thing is it doesn't change every frame.

Grassland forests (including jungles and pine forests).

Plains forests (including pine forests).

Tundra forests (including pine forests).

Optionally can split into multiple PRs.

https://docs.github.com/en/actions

The functions to import, load, and save exist, as does a file browser dialog. They just need to be plumbed together

The current setup for Biq FLAVs assumes that there will always be exactly 7 flavors. This is true for the vast majority, but not all cases. It would be better to handle the dynamic cases.

As the title says. I tried loading a save from Civinator's German Conquests compilation, expecting a terrain error. Instead, I got an error that I traced to the map not being "square". Later duplicated with an English Napoleonic Europe save.

Too tired to fix now. But we probably should as a lot of scenarios have non-"square" maps.

Near-term goals are identifying the "has custom rules" part of the Bic and the overlay terrain graphic selector.

Creating _Console/LuaCiv3 to use QueryCiv3 to analyze stuff.

Right now, the weights given by the AI to where to settle are hard-coded - food yield, shields, commerce, and distance, as well as bonuses based on hills and coastline. But it would be nice to make this configurable and available to mods.

I'd suggest making them configurable, but with default values that will be used in lieu of any being set. There should also be some sort of a setup for AIWeights, which will be mod-configurable (in the JSON file?).

Longer-term, I'd like for it to be possible for different AIs to have different weights; maybe a Commercial AI puts extra weight on commerce yield, and an Industrious one on industrial output. Whether this is changing the direct weight (+1 for shield output for industrious civs), or a percent bonus (+20% weight to shield yield) is to be determined. Optionally, think about and add something to make it variable by civ.

We're using dummy terrain types for now, and have been building more and more on those dummy terrains. Long term, that dog doesn't hunt, so it's time to switch to reading the terrain types in SAV/BIQ files.

Looks like I need to convert to an issue to make progress notes and comments?

The method used to tint units with their civ color is to multiply that civ color by a color sample taken from the white (ntp00) palette. For proper compatibility with the base game we must add the option of instead reading the color from one of the other palettes.

Right now, the settler AI settles in CxC. This shouldn't be the default; tiles that close to other cities should be skipped.

I would suggest making this configurable via a boolean; for some AI strategies (100k culture, Feudalism government type unit support, for example), it might make sense.

Add a configurable INI file if it isn't already present. If there's a built-in C# library to handle them, great, if not, it's an INI file, what could go wrong with building our own?

Add a volume and music volume options to it. Probably an integer from 0 to 100. Have the sound react to this value, at least for music.

Borderline whether it's a good first issue, but the risk is low so why not?

After #89 , most aspects of tile yield will be integrated. However, river commerce bonus will not be. This should be integrated into the calculations, and since they're already compartmentalized, it should be as easy as factoring it into commerceYield.

(Also, since the rest of the original scope of this issue has already been subsumed, and we don't use commerce yet, this could be punted to post-Carthage)

Not necessarily an Aztec 0.0 target