Basic opponents #80
Merged
Basic opponents #80
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Roadmap doesn't say when we should start adding opponents. This is probably *slighhhhhtly* too early, since there's no combat/ways to reduce the number of units. But I'd argue that it should be earlier rather than later for several reasons: - Makes the game more interesting. I've played Civ3 games in "no opponents, just build a civilization all over the whole world!" mode, and it gets boring. I've never *finished* such a game. - Lets us start playing around with AI, which is one of the big uncertainties. I can only imagine trying to add AI once all the mechanics are in place. - Gives a chance of having the AI become halfway decent at the earlier mechanics. I reckon the chances are better than if at the end we say, "well, we have 4000 features, let's write an AI that tries to use them all". - Helps with emergent design of the code. I've already realized that switching from the flat-file/save-format list of all units, to grouping them by player, probably makes sense. As of this commit, it's not great yet. Four players are spawned and they're supposed to all have different colors, but don't. The player can control everyone's units, but we knew we had a hack for unit control so that's not a surprise; now's the time to address that.
It's fairly clear that storing units both at a top-level level and at a player level (and at a tile level, etc.) is a nuisance. I am favoring eliminating the top level (we can always get a flat version from the players if we need it), while keeping copies that are useful, e.g. tiles to see if combat should occur.
…et up some structure around storing unit objectives, for various plausible objectives. In TurnInteractions, non-human players now set AI goals for units, and then execute on those goals. It's still not good, but the players do build their first city, and move units around. It also sets the stage for things like teaching the AI how to choose settler destinations for their second-and-subsequent settlers, and thus moving towards a destination instead of randomly. Before enhancing the AI much, I'm probably going to look at some display details like getting city colors to match unit colors, getting unit colors to line up properly, setting the animation direction properly for AI units, and maybe adding some basic city name lists.
… now you can add them as uints with normal 0xFFAABBCC notation and the Player constructor stuffs them into regular ints. Tested that it's working with orange. Also assign barbarian units to barbarians again. I moved their order a few commits ago which broke that.
…s. This allows city names to be player-specific, so we won't have three Neo-Tokyo cities on the map anymore.
…ons for and to found new cities. It's not super amazing yet, but is functional, using CxxC or CxxxC patterns, with the AI figuring out it can do CxCxC instead of CxxxxC. Location choice is weighted by terrain. New settlers only look within about a 4-tile radius of their home city, which is limiting, and the AI doesn't consider settling overseas at this point. But the AI will start to forge its own empire. Also enhance GetNextCityName to loop, so it won't crash the game when the AI builds too many cities.
…n turn handling mechanics.
maxpetul
approved these changes
Feb 12, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reviewers: I recommend starting with TurnHandling.cs, which is the top level and will lead you into PlayerAI.cs, which will in turn lead you to the rest of the code.
Goal: Add a little bit of AI interactivity to make the world more interesting, and to start testing the waters of what it's like adding an AI to the game.
Current status: AI will send its units out exploring. It will use its settlers to build new cities, using somewhat intelligent evaluation of potential city sites. It will fail to assign any units to defense instead of exploring.
Once the defense problem is sorted (and maybe assigning some surplus units to offensive armies?), I'm thinking the next step is a TerrainType overhaul similar to the UnitPrototype overhaul. We've got too much stuff relying on hard-coded names, and should really be relying on properties (e.g. defensiveBonus, allowsCities) rather than names.