The Kuriotates

Year testing will be needed bevor taking that step. But ill change the code to allow downgrading cities nevertheless as its better to have the option and test the system with it, than to have to rewrite the system when we finally want to use it. ;).

Hmm if you do it by a building i'll come up with something that reports the most valuable citys (a python function for your cannot build - can you post yor code for the "Upgrade" - Building?). We need a City building anyway (to switch to the third ring so that does match :)) .. if we limit the upswitching building to 2 we would not even need the cannot build for the player :D .. the only thing with this solution is it might count to the max. 2 National Wonders per city. Do you know how that is handled with the palace? )
 
Chalid said:
Year testing will be needed bevor taking that step. But ill change the code to allow downgrading cities nevertheless as its better to have the option and test the system with it, than to have to rewrite the system when we finally want to use it. ;).

Hmm if you do it by a building i'll come up with something that reports the most valuable citys (a python function for your cannot build - can you post yor code for the "Upgrade" - Building?). We need a City building anyway (to switch to the third ring so that does match :)) .. if we limit the upswitching building to 2 we would not even need the cannot build for the player :D .. the only thing with this solution is it might count to the max. 2 National Wonders per city. Do you know how that is handled with the palace? )

In onBuildingBuilt, where BUILDING_CITY is the "Upgrade to City" option.

Code:
		if iBuildingType == gc.getInfoTypeForString('BUILDING_CITY'):
			pCity.setHasRealBuilding(gc.getInfoTypeForString('BUILDING_SETTLEMENT'), False)
			pCity.setHasRealBuilding(gc.getInfoTypeForString('BUILDING_CITY'), False)

In onCityBuilt:


Code:
		if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_KURIOTATES'):
			if pPlayer.getNumCities() > 3:
				city.setHasRealBuilding(gc.getInfoTypeForString('BUILDING_SETTLEMENT'), True)

in onCityAcquired:

Code:
		if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_KURIOTATES'):
			iSettlement = gc.getInfoTypeForString('BUILDING_SETTLEMENT')
			iCount = 0
			for i in range(pPlayer.getNumCities()):
				pCity = pPlayer.getCity(i)
				if pCity.isHasRealBuilding(iSettlement) == False:
					iCount = iCount + 1
			if iCount > 3:
				city.setHasRealBuilding(iSettlement, True)

In cannotTrain:

Code:
	if pCity.isHasRealBuilding(gc.getInfoTypeForString('BUILDING_SETTLEMENT')):
		return True

in cannotConstruct:

Code:
	if pCity.isHasRealBuilding(iSettlement):
		bValid = False
		if (eBuilding == gc.getInfoTypeForString('BUILDING_OBELISK') or eBuilding == gc.getInfoTypeForString('BUILDING_WALLS')):
			bValid = True
		if eBuilding == gc.getInfoTypeForString('BUILDING_CITY'):
			iCount = 0
			for i in range(pPlayer.getNumCities()):
				pCity = pPlayer.getCity(i)
				if pCity.isHasRealBuilding(iSettlement) == False:
					iCount = iCount + 1
			if iCount < 3:
				bValid = True
		if bValid == False:
			return True


I think the palace gets away with it because the buildclass is defined as bNoLimit. But thats just a guess, I havent played with it.

Code:
		<BuildingClassInfo>
			<Type>BUILDINGCLASS_PALACE</Type>
			<Description>TXT_KEY_BUILDING_PALACE</Description>
			<iMaxGlobalInstances>-1</iMaxGlobalInstances>
			<iMaxTeamInstances>-1</iMaxTeamInstances>
			<iMaxPlayerInstances>1</iMaxPlayerInstances>
			<iExtraPlayerInstances>1</iExtraPlayerInstances>
[b]			<bNoLimit>1</bNoLimit>[/b]
			<DefaultBuilding>BUILDING_PALACE</DefaultBuilding>
			<VictoryThresholds/>
		</BuildingClassInfo>
 
bNoLimit does allow it as you suspected. Very good.

in cannotConstruct:
The number of Buildings of a class a civ posesses is (as the number of units of each class) already stored in
Code:
pPlayer.getBuildingClassCount(gc.getInfoTypeForString("BUILDING[b]CLASS[/b]_SETTLEMENT"))
so no need to count yourself :D.


I think we can streamline there even more when you have my code :) which will probably be this evenening, dependend if i go to the Open Air Cinema today or saturday.
 
Chalid said:
bNoLimit does allow it as you suspected. Very good.

in cannotConstruct:
The number of Buildings of a class a civ posesses is (as the number of units of each class) already stored in
Code:
pPlayer.getBuildingClassCount(gc.getInfoTypeForString("BUILDING[b]CLASS[/b]_SETTLEMENT"))
so no need to count yourself :D.


I think we can streamline there even more when you have my code :) which will probably be this evenening, dependend if i go to the Open Air Cinema today or saturday.

Good call on the getbuildingclasscount, ill switch to it.
 
I'm just running some more tests with the mage ai and will pack the things afterwards for you. So you should get them in one or two hours.

Do you want the modified FfH editor with the new attributes? I figured you would have changed much of the contents but could use the modified scripts.
 
Chalid said:
I'm just running some more tests with the mage ai and will pack the things afterwards for you. So you should get them in one or two hours.

Do you want the modified FfH editor with the new attributes? I figured you would have changed much of the contents but could use the modified scripts.

Whatever is easiest for you. If you tell me the attribute names I can look for them in your xml and get the syntax and such from that. I will have to manually merge with my editor copy because Ive made so many changes but thats not a big deal.
 
Chalid said:
You should be able to query for

if pPlayer.isSprawling()

now instead of

if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_KURIOTATES'):

Cool, will do.
 
Chalid said:
You should be able to query for

if pPlayer.isSprawling()

now instead of

if pPlayer.getCivilizationType() == gc.getInfoTypeForString('CIVILIZATION_KURIOTATES'):

Initially this didn't work because it wasn't defined in the CyPlayerInterface1.cpp file. I checked in the following change and it works now:

Code:
		.def("AI_maxGoldTrade", &CyPlayer::AI_maxGoldTrade, "int (int)")
		.def("AI_maxGoldPerTurnTrade", &CyPlayer::AI_maxGoldPerTurnTrade, "int (int)")

//FfH: Added by Kael 05/03/2006

		.def("getAlignment", &CyPlayer::getAlignment, "int ()")

//FfH: End Add

[b]//FfH: Added by Kael 06/15/2006

		.def("isSprawling", &CyPlayer::isSprawling, "bool ()")

//FfH: End Add[/b]

		;
}
 
Woodelf, would you move this thread to the public forum please.
 
Thanks man. I wanted to release this just because I think its an interesting read and a good repersentation for how we come up with concepts (for those that are interested). Take a read of the thread and I think there are a few interesting things to note:

1. The idea evolves from a central concept, "Creation". We have a general idea of what the feel for the civ should be but we don't have mechanics.

2. When looking for mechanics we aren't afraid to throw them away. There are a lot of good ideas in this thread that we don't use. No one stays to attached to anything and we brainstorm through ideas until we hit the one that seems perfect to us.

3. Its a team process. Contributions come from everyone, including art and writing team members (who have always contributed much more than just in the art and writing areas).

In our final form, the one that will be in 0.13, the Kuriotates can have 3 real cities. These cities can work the 3rd plot ring, meaning they can be huge production machines. All of the Kuriotates other cities are "Settlements" and cant produce untis and only a very limited number of buildings (walls and the obelisk). Settlements don't require any maintenance or war weariness, and dont supply any research or gold so they allow the Kuriotates to expand their borders without building more "real cities".

Kuriotates are awesome for the single city challenge.

We don't have the centaurs in yet but they are still planned for them, we see a design need for the kuriotates to have some very mobile defenders to guard their expansize empires.

I hope you enjoy them, I will be interested to hear feedback after the release on Friday.
 
I think I found a new favorite civ. I already liked the Kuriotates' flavor, this pushes them over the top for me since I tend to be a slow builder type that concentrates on a few core cities.
 
Zurai said:
I think I found a new favorite civ. I already liked the Kuriotates' flavor, this pushes them over the top for me since I tend to be a slow builder type that concentrates on a few core cities.

Good to hear, our goal is to make each of the civs play differently and I think we did a good job with the Kuriotates. They won't be for everyone, but some players will love them.
 
still seems you will have problems getting important resources too me even with smaller settlements. unless you spread the wealkth and stretch resources into alot of different lands so they are not all clumped together
 
ChaoticWanderer said:
still seems you will have problems getting important resources too me even with smaller settlements. unless you spread the wealkth and stretch resources into alot of different lands so they are not all clumped together

The Kuriotates can have as much landmass as any other empire, but they will only have 3 main cities. Their settlements, as far as cultural borders go, are just like normal cities. But thats about all their settlements do.
 
The Kuriotates will be an awesome civ for builders when it&#180;s ready, good job. I think the 3rd ring and the settlements are great ideas, and will make the Kuriotates, if left alone, the most powerfull civ in the end-game.

The Centaurs are great ideas too, will they replace only the archer units or will also replace some mounted units ?
 
I must agree, this does look really cool and have the potential to easily become one of my fave civs, too. :)

Just one thought - the Kuriotates might have severe difficulties once they end up in wars. Consider this scenario:

Player with eight cities produces two military units in each city and then goes on to build buildings for the next couple of turns. One unit to attack, one to defense. Eight offensive, eight defensive units produced total.

In the same timespan, the Kuriotate player capped to three cities likewise produces two military units in each. One to defend, one to attack. Three offensive, three defensive units produced total. This means that the bigger player has almost three times as many units - if the Kuriotates want to ensure that the other won't decide to invade, they must spend several of the next turns to build (at least) more defensive units to compensate for the difference in cities. In the meanwhile the other player isn't even breaking a sweat and improves his infrastructure by constructing buildings in his cities, and after some turns will idly instruct his cities to again build a new batch of units without it affecting his empire much - at worst, just when the Kuriotates finish building troops to make up for the *last* batch of new units. Even if the situation wouldn't be this bad, over the turns even smaller differences accumulate. Imagine a Bannor player with eight cities *and* the Crusade civic in effect... the Kuriotates being forced to constantly build their military in order to just survive doesn't really fit their builder flavor. (Might not necessarily be a problem at lower difficulties where the AI is pretty toothless, but much moreso at higher ones - or against human opponents.) Plus it might force them to play as a defensive player, period - while I do prefer to mostly just be peaceful and not fight very much as a builder player, even I do want to wage at least the occasional war at times.

Of course, I haven't actually played any games with the New Kuriotates yet, so it could be that the increased production in their cities makes up for this. If not, two ways to help avoid this might be:

1) Scale the amount of cities allowed to the Kuriotates to the map size. Only being allowed three cities isn't any sort of a problem on a Duel map, but it will be much more so on a Huge one. The downsides are that it's probably tricky to code and might be confusing to casual players.
2) Boost the amount of cultural defense the Kuriotates get in their cities. Fits nicely with the flavor (huge, sprawling cities that are legendary for being almost impossible to capture by any foreign invader) as well as the fact that they get added culture bonuses otherwise, too. This forces the invader to either spend more turns besieging the cities (giving the Kuriotate defenders more time to build defensive units) or build more siege weapons than actual city attackers. The downside is that I'm not sure if this actually has any real effect - cultural defenses are something that I usually just either bomb away in a couple of turns or downright ignore entirely.

But other than that this does look like a very, very nice civ now. I'm loving it already, just a bit worried if it'll keep up with the others. :)
 
Top Bottom