I need ideas of stuff to code!

[GermanJoey]

Clojure is fine for me, I'm familiar with it enough to translate that code back to Perl. This is supposed to be a fun little side-project for you, so use whatever you think you'll enjoy the most. Don't worry about whether its useful to me or not.

I think it'd be also more interesting for you if you actually think about what strategic factors are important for yourself. I don't have a full list in front of me or anything; I have a list of 10 things I wrote down one night two weeks ago, one of which, I now realize, is completely stupid as it's hard to compute yet probably doesn't add much. I didn't think about this for too long yet. There won't be infinite factors to consider; I'd be surprised if you could come up with more than a dozen. Some factors might be extremely hard to compute and are better left ignored. Remember, if you're not sure about the relative value of one thing to another thing you can always use a variable weight, which you can tune later through experimentation. AI heuristic problems often have some kind of ad-hoc tuning element like this, because otherwise they wouldn't work at all.

Regarding a few of the other questions you had:

• Distance to capitals is important for deciding between front cities and back-fill. Potential sites that are 3 tiles away from your capital should probably also rate higher than than sites that are 20 tiles away. It's up to you on how much you want to consider.
  
• Height is numbered because that's how the map editor stores it for some weird reason. You can use names for the height if you'd rather, its not a big deal.
  
• Floating point arithmetic is fine if you don't need to compare two floating point values exactly, which is not the case here.
  
• You can also assume that the tile hash has an "is_wet" attribute, for determining whether a tile is farmable or not. (e.g. for wet rice/wheat/corn)
  
• A list of resources is here: http://civilization.wikia.com/wiki/Resource_(Civ4)
  

[novice]

The nerdy and vastly overcomplicated way of doing the fat cross evaluator is to feed all the variables into a neural network and train it using previous RB games as input. (Train it to target Krill's choices and avoid Brick's choices.)

[novice]

By the way, impressive work, GermanJojo. Will there be a ui for combining layers or will that be done from the command prompt?

[BRickAstley]

The nerdy and vastly overcomplicated way of doing the fat cross evaluator is to feed all the variables into a neural network and train it using previous RB games as input. (Train it to target Krill's choices and avoid Brick's choices.)

That was only one game....

[Cheater Hater]

I want it to be useful though--that's what I said in one of my first posts (otherwise I could just do some koans).

The problem with strategic factors is that it could be infinite, and while something like "has-copper?" is easy, other things are hard. For example, for the "hill-capital?" you need three things:

• x=0
  
• y=0
  
• height=1
  

That doesn't even consider if you want a 2+ hammer capital. In general, if you want specific tile yields (say, a 5 food/6 food tile once improved, before Biology) it becomes hard since you need to chain together a bunch of conditions. This is especially hard since mods change some of that--maybe the best implementation is to feed it a hash of resource:yield (though in that case you'd want to do it for most of the lists, and then you're feeding it ~9 inputs, and that's a mess--that could be solved with a map of maps, but that doesn't solve the core problem, just makes me do a ton of initial lets).

I'm not saying distance from capitals isn't important, just that it isn't practical to determine when you're actually playing. Actually, wait--are you trying to use this as a mapmaker (with all information) to try to make sure every civ has the same quality cities for the first X cities rather than just capitals? I'm not sure what to think about that right now

I know floating point arithmetic is fine for the actual program, but it's a pain when I'm writing my tests

[GermanJoey]

The nerdy and vastly overcomplicated way of doing the fat cross evaluator is to feed all the variables into a neural network and train it using previous RB games as input. (Train it to target Krill's choices and avoid Brick's choices.)

lmfao.... but in all serious that would be REALLLY COOL but SOOOO much work... I think it'd be legit interesting from an academic perspective too. I've heard of neural-network-based AI's built by emulating expert players in games with simple rules like chess and go, but nothing like really something with really sophisticated like a 4X game (I just mean rule wise, now how sophisticated the game is itself... like just think about how many more different types of tiles and how many more types of pieces there are in Civ4 compared to e.g. Go - that's all stuff an AI has to understand!)

By the way, impressive work, GermanJojo. Will there be a ui for combining layers or will that be done from the command prompt?

thanks! A UI like photoshop or some such? A pipe dream, maybe... the system would be easily converted into a web interface because it's already completely command-driven and the map display is already html, and, thinking about it a bit, it wouldn't really be too hard... but I'll probably be fatiqued with the project by the time I get that far, heh. I plan to at least have an overlay-mode w/ the current interface to show where layers are.

[GermanJoey]

I want it to be useful though--that's what I said in one of my first posts (otherwise I could just do some koans).

The problem with strategic factors is that it could be infinite, and while something like "has-copper?" is easy, other things are hard. For example, for the "hill-capital?" you need three things:

• x=0
  
• y=0
  
• height=1
  

That doesn't even consider if you want a 2+ hammer capital. In general, if you want specific tile yields (say, a 5 food/6 food tile once improved, before Biology) it becomes hard since you need to chain together a bunch of conditions. This is especially hard since mods change some of that--maybe the best implementation is to feed it a hash of resource:yield (though in that case you'd want to do it for most of the lists, and then you're feeding it ~9 inputs, and that's a mess--that could be solved with a map of maps, but that doesn't solve the core problem, just makes me do a ton of initial lets).

Yes, you're gonna have some rules that have a multitude of conditions, like the hill-city rule you give as an example. However, there doesn't need to infinite factors here. The result of a rule could be something as simple as "increase the value so far by +10%" or something like that. What you're building here is a rule-based expert system:

https://en.wikipedia.org/wiki/Rule-based_system

I think I'm not being clear... let me describe the system a little more. For example, let's say you start with a base value for the BFC calculated by applying SevenSpirit's tile value system to every tile in the BFC outside of the city-site:

http://realmsbeyond.net/forums/showthrea...#pid234296

then choosing the best, I don't know, 7 tiles and adding up their value. This is your base_value.

Next, you have a list of rules. Each rule has a condition, a weight, and an equation of how to modify the base_value if the condition passes. For example, lets say our first rule is called "has_copper" which has the condition "copper must be in the BFC." If has_copper passes, then we apply the equation. Let's say the has_copper equation is something like: new_value = base_value + has_copper.weight*base_value. For example, if has_copper.weight = 1.0, then our base_value doubles! That means having copper was really important. However, if has_copper.weight=0.1, then our value only increases by 10%. The value of the weight will change based on what the driver-engine thinks is important at the time. For example, has_copper.weight might have an initial value of 0.5 for when the player settles their second city - important, but not screamingly important. However, after that, has_copper.weight might increase by 0.2 for each city the player settles that doesn't have copper - so 0.5 for the second city, 0.7 for the third, 0.9 for the fourth, etc, because the longer copper is delayed the more dangerous the player's situation will become. Once a city with copper has been settled, has_copper.weight might drop down to like 0.0 or 0.05 (its nice to have a backup) - meaning the copper will still be appreciated for its tile value, but its no longer an important strategic concern.

At any rate, once the has_copper rule has been evaluated, we then move on to the next rule, which has its own condition, weight, and equation. And onwards, for however many rules you have. Your job is to figure out a.) how do you describe and evaluate these rules? and b.) what rules do you need? The problems are very inter-related.

I'm not saying distance from capitals isn't important, just that it isn't practical to determine when you're actually playing. Actually, wait--are you trying to use this as a mapmaker (with all information) to try to make sure every civ has the same quality cities for the first X cities rather than just capitals? I'm not sure what to think about that right now

Yes, exactly. And also to help figure out which land is which player's. This is to help the mapmaker make sure the map is balanced, not to help a prospective player choose what cities would be best for them. What this system is trying to emulate is a map-maker (that has full, perfect knowledge of a map) playing a bunch of test games on his map to study closely how a player might actually settle from a given starting spot to make sure that the map is fair. So, its ok if you can't achieve Krill-level city judgement with this algorithm. We're just trying to get it as good as we can.

I know floating point arithmetic is fine for the actual program, but it's a pain when I'm writing my tests

If integers are easier for you to work with, use integers. Just make the result, I don't know, a number between 1 and 1000 or something.

[Cheater Hater]

I've added a couple more functions to the github account, and while I don't have many rules set up yet, I have a framework for stuff that lets me easily build functions for a lot of different rules (for example, the functions that get the resources in a fat cross, then ask if a resource is in the fat cross form the basis for all basic resource rules). Once I have all the rules, it should be as easy as adding together the values for each of the rules (assuming they remain binary) and dividing by the total.