Possible new civilization game: make our own!
- Thread starter Steph
- Start date
That's 2D. Bhiita made the first version before disappearing.
Then another French artist made another version... before disappearing also.
Then another French artist made another version... before disappearing also.
Jawa'sRevenge
Warlord
Wow!
That's fantastic but...
The graphics are a bit Civ II looking
Looks like there is small amount of colors, on of the annoying parts of Civ III was having only 265 colors
This is probably a stupid question but why can't you use the Civ IV AI for this game?
Otherwise looks good job!
That's fantastic but...
The graphics are a bit Civ II looking
Looks like there is small amount of colors, on of the annoying parts of Civ III was having only 265 colors
This is probably a stupid question but why can't you use the Civ IV AI for this game?
Otherwise looks good job!
Thank you for volunteering to make true colour graphics, which my engine support.
When can I expect to receive the first graphics made by you?
I'm using the graphics currently available here, which are all 256 colours. But I'll take these 256 colours graphics made by really talented artists such as Sandris or Wyrmshadow anytime before the ugly one from Civ IV.
And you are right, this is a stupid question.
nick0515
C7 Fanatic
Harsh Steph. But witty as usual. Personally I quite like civ 3 graphics, and especially all the nice graphics made by various people. The civ 4 graphics completely put me off. And was the AI any better than civ 3? I didn't play it long enough to find out.
Keroro
Dororo: Ninja Frog
The civ 4 AI can be improved by users, so in that respect it is better. The AI in civ 4 also seems to be able to understand how to create an army with a realistic chance of taking cities, which is where civ 3 is often lacking. I've lost count of how many times a massive AI army in civ 3 has walked up to a city and then not attacked it - giving me time to take it down with artillery and quick attack units. It's not just frustrating that this happens, it's majorly frustrating that we have so few ways to stop it from happening.
nick0515
C7 Fanatic
Yes the Civ 3 AI is, unfortunately, very bad. That's good I guess that the AI for Civ 4 is better. AI is so crucial to a fun game. Thankfully Civ 3 has enough other redeeming features that make up for the poor AI enough to make it one of my all time favourite games!
A quick update.
This week, I've been busy with streamlining two concepts: inheritance, and attributes, working together with the class system.
I hope to have some screenies to show soon.
This is an important part, because it's a kind of basic foundation that I will then use to quickly do other stuff.
It takes time.... But when it will be finished, I hop I'll be able to move forward faster.
This week, I've been busy with streamlining two concepts: inheritance, and attributes, working together with the class system.
I hope to have some screenies to show soon.
This is an important part, because it's a kind of basic foundation that I will then use to quickly do other stuff.
It takes time.... But when it will be finished, I hop I'll be able to move forward faster.
Time to show something 
.
It's not finished yet, but this should illustrate the concept well. And will explain why I cannot make an editor that works both for CivIII and for my game.
The example here is a bit silly, it's just to show how it works. The value used have no real meaning.
First, this is the part of the editor where you can add/remove or edit land terrain.
You can notice that you can have an editor name, and a usual name, and they could be different. Here the use is not obvious, but imagine in the editor "German_Paratrooper_WWII", and in game "Fallschirmjaeger". It make it easier to identify and organize in the editor, while showing a nice and clean name in game.
Then, if you select the first terrain, and click on the edit button, you can get edit the terrain. Here, you see the "single attributes" page. For the moment it's empty.
I want to modify the combat bonus...
So I click on the "add attribute" button (left).
Now, in the "add attribute" window, I can select a category (comlat) and an attribute (melee combat). The list of categories and attributes can of course vary with the type of objects (different for a unit, a terrain or a building). However, the interface will always be the same.
Here, I decide to give a 10 bonus to artic in melee combat.
When I save, the new attribute appears in the list. Of course, I could also cancel. The important point here is that only the attributes which are interested are listed. In that case, I have a combat bonus for melee. But not for range. And if I don't want to add one, I have nothing to do. In other words, you set only the important values. Everything else is just ignored.
Now, if I do some drag and drop in my terrain list, I can maje an object inherit from another.
Here, the plain inherits from grassland which inherits from Artic. What is the interest? By default, Grassland has all the attributes of the Tundra. So, it has how 10, and I don't need to set it one terrain by one terrain if I don't want to.
but there is more! If I edit my grassland, and try to add the Melee combat attribute, I see it already exist! There is base value of 10 coming from the parent (arctic).
I could replace the value, so grassland has a new absolute value. But I can also use a modify, with +5. And so the final value is 15.
If I save and edit plain, with the same attribute, I see it already has 15 (10 from artic + 5 from grassland), and for specific value I decide to make in a %: the final value will be 3.75 in that case.
Every attribute for every object will work this way, and every object can inherits from other.
And obviously, if I later want to increase the base value for Artic from 10 to 12, then the value for Grassland will automatically become 17 (12+5), I don't need to edit individually all the objects to rebalance a mod.
Compare that with civ... Where you have an A/D of 3/2 for all 20 flavour units swordsmen, one of each civ, and for balance you want to make it 4/3... You'd have to edit 20 units! Here, just edit the "swordsman" unit, which have 20 flavour units as child.
Another beauty of the system is I can easily add new attributes. You want to have a new attributes "chance to find water for travelling unit" in the terrain? No problem!
And this will need no rework of the interface (as the attributes are in list, not in fixed fields as you can find in CivIII editor). And no impact on file format!
You could load your old mods. You'll just have to add the attribute to the terrain that
need it. By default, it will just be considered absent (ie can't find water in that terrain).
.It's not finished yet, but this should illustrate the concept well. And will explain why I cannot make an editor that works both for CivIII and for my game.
The example here is a bit silly, it's just to show how it works. The value used have no real meaning.
First, this is the part of the editor where you can add/remove or edit land terrain.
You can notice that you can have an editor name, and a usual name, and they could be different. Here the use is not obvious, but imagine in the editor "German_Paratrooper_WWII", and in game "Fallschirmjaeger". It make it easier to identify and organize in the editor, while showing a nice and clean name in game.
Then, if you select the first terrain, and click on the edit button, you can get edit the terrain. Here, you see the "single attributes" page. For the moment it's empty.
I want to modify the combat bonus...
So I click on the "add attribute" button (left).
Now, in the "add attribute" window, I can select a category (comlat) and an attribute (melee combat). The list of categories and attributes can of course vary with the type of objects (different for a unit, a terrain or a building). However, the interface will always be the same.
Here, I decide to give a 10 bonus to artic in melee combat.
When I save, the new attribute appears in the list. Of course, I could also cancel. The important point here is that only the attributes which are interested are listed. In that case, I have a combat bonus for melee. But not for range. And if I don't want to add one, I have nothing to do. In other words, you set only the important values. Everything else is just ignored.
Now, if I do some drag and drop in my terrain list, I can maje an object inherit from another.
Here, the plain inherits from grassland which inherits from Artic. What is the interest? By default, Grassland has all the attributes of the Tundra. So, it has how 10, and I don't need to set it one terrain by one terrain if I don't want to.
but there is more! If I edit my grassland, and try to add the Melee combat attribute, I see it already exist! There is base value of 10 coming from the parent (arctic).
I could replace the value, so grassland has a new absolute value. But I can also use a modify, with +5. And so the final value is 15.
If I save and edit plain, with the same attribute, I see it already has 15 (10 from artic + 5 from grassland), and for specific value I decide to make in a %: the final value will be 3.75 in that case.
Every attribute for every object will work this way, and every object can inherits from other.
And obviously, if I later want to increase the base value for Artic from 10 to 12, then the value for Grassland will automatically become 17 (12+5), I don't need to edit individually all the objects to rebalance a mod.
Compare that with civ... Where you have an A/D of 3/2 for all 20 flavour units swordsmen, one of each civ, and for balance you want to make it 4/3... You'd have to edit 20 units! Here, just edit the "swordsman" unit, which have 20 flavour units as child.
Another beauty of the system is I can easily add new attributes. You want to have a new attributes "chance to find water for travelling unit" in the terrain? No problem!
And this will need no rework of the interface (as the attributes are in list, not in fixed fields as you can find in CivIII editor). And no impact on file format!
You could load your old mods. You'll just have to add the attribute to the terrain that
need it. By default, it will just be considered absent (ie can't find water in that terrain).
Here's to Steph and the beauties of object-oriented programming 
timerover51
Deity
In some sense, what you are trying to do with your combat system is something that is already used extensively in miniature war gaming, although normally, ammunition is not a factor except in skirmish level games where one figure represents a single combat unit.
Supply is normally factored in, with the level of supply required increasing with the technology of the units. Supplying units during the Napoleonic Wars was not that different from supplying the units of Alexander the Great, as the major weight factors were food for the men and fodder for the animals. The weight of ammunition was only a small fraction of that. Mechanization changed that drastically, with rations now assuming a small percentage of the tonnage required. As a rule of thumb for WW2, a US logistician would assume 65 pounds per man per day in the combat theater, only 6 pounds of which was food, the rest being ammunition, POL (petroleum, oil, and lubricants), spare parts, replacements for lost equipment, construction materials, etc. Japanese units, with a much lower level of mechanization and a lot less artillery could get by with 25 to 30 pounds per day. Germany's mechanized units required supply levels similar to the US, while their horse-drawn infantry units more closely resembled the Japanese.
What your combat mechanism should allow for is the changes in supply level required between units of different eras. An army such as the Macedonians of Alexander the Great or the Romans could pretty much live off the land as long as they kept moving or did not have to deal with a enemy close to them. Gunpowder units, especially if prosecuting a siege, would require some form of supply line to a base of operations. World War 1 units and beyond would require extensive supply lines (perhaps making railroads mandatory before producing such units), and if invading another continent, access to a port/harbor for supply. In other words, no rampaging armored units until they have a port/harbor either captured or built, and of course, oil in the port/harbors resource box. The same thing should be required for aircraft. If invading a small island, of only a few tiles, a port would not be required, but a supply dump would be. Supply is always a headache to represent in a board or miniature game, but with a computer, it could be done fairly easily, similar to say the trade route between cities in Rise of Nations. The difference would be that instead of a market, the route would connect a base city in your homeland to your foothold port/harbor in the conquered area, say supply dump to supply dump. The enemy would then have the option of attempting to interdict the supply lines.
I like the combat rating system of Age of Empires 3, with it positive and fractional bonuses verses different types of units, which seems to be what you are aiming for.
When it comes to unit combat values, I am a military and naval historian, with an extensive personal library of military history and science extending from the Sumerians to the present day, along with a very large collection of board war games and miniature war game rules sets to draw on for units and unit ratings. I also do consulting work for US government agencies in the area of weapon effects, bomb damage, and ship vulnerabilities. I have managed to avoid a security clearance, so I can work freely. I also am a student of ancient technology specifically, and technology in general.
Last but not least, I have extensively modified the Wonders in the game, and I think that the game mechanism should allow you to take a basic Wonder and then tailor it for your own specifics wants and desires, with every additional characteristic costing either more time to build, additional specific resources, like the Ivory for the Statue of Zeus, or greater cost, or a combination of all three, with possibly a minimum construction time.
Oh, and the editor must run under the Mac OS.
I also have some thoughts on Ages, but I will allow you to digest this missive first, and determine if my thoughts are useful.
They are.
Regarding supply/ammo. The tactical battles are battles, not compaign.
Something that could be fought in a day. That's why I think during a single battle, the ammo is important, but supply is not.
That's because supply will have an effect at the strategical level: if your unit is not supplied properly, then it will start a battle with some penalty, and after the battle you can have difficulties to reinforce. But during the battle itself, it has no effect beyond that.
Regarding the MacOS, first I don't see why the game must work on it. Second, I'm programming in C#, and I have no idea if there is something like Microsoft framework to support C# on MacOS.
Beside, I don't have a MAC, so it means I cannot develop and test on it.
Regarding supply/ammo. The tactical battles are battles, not compaign.
Something that could be fought in a day. That's why I think during a single battle, the ammo is important, but supply is not.
That's because supply will have an effect at the strategical level: if your unit is not supplied properly, then it will start a battle with some penalty, and after the battle you can have difficulties to reinforce. But during the battle itself, it has no effect beyond that.
Regarding the MacOS, first I don't see why the game must work on it. Second, I'm programming in C#, and I have no idea if there is something like Microsoft framework to support C# on MacOS.
Beside, I don't have a MAC, so it means I cannot develop and test on it.
timerover51
Deity
The main reason for wanting it to run on a Mac is that I primarily use Macs. As for the programming, I will check on that.
To continue with the concept of attributes and inheritance.
Last time I show how to add an attribute modifier to an object.
You have several possibilities to display them afterward, shown in the screenshot below.
Top: Display ALL the possible attributes. They are blue if they are enabled for this object, and grey if they are not. Here it means that it's not possible to travel on a grassland (world map), although it's possible to move on it on tactical map (battle). I now, it's a sily example
Middle: display only the specific attribute, i.e. only what has been modified for the grassland terrain (not taking the parent into account).
Bottom: display all the attributes enabled for the item, including the parent. So here we can see that the grassland would inherit the normal speed from the parent, but would override the maximum speed.
Last time I show how to add an attribute modifier to an object.
You have several possibilities to display them afterward, shown in the screenshot below.
Top: Display ALL the possible attributes. They are blue if they are enabled for this object, and grey if they are not. Here it means that it's not possible to travel on a grassland (world map), although it's possible to move on it on tactical map (battle). I now, it's a sily example
Middle: display only the specific attribute, i.e. only what has been modified for the grassland terrain (not taking the parent into account).
Bottom: display all the attributes enabled for the item, including the parent. So here we can see that the grassland would inherit the normal speed from the parent, but would override the maximum speed.
Bomberman2
Chieftain
- Joined
- Feb 21, 2009
- Messages
- 11
When you get to that point when you start designing the details of the game I have an idea I think was left out of Civ3. You could have countries fall apart. When that happens the cities that get into disorder run a risk of starting a rebellion. Then it can ferment into a full scale revolution. Then it will split from your civ and form a new Civ(under AI control of course, also if playing multiplayer that civ will stay in AI control till a new player joins). Then if you conquer a civ partially or fully your control will never be complete. You will have to constantly contend with rebel forces. Also the rebels can ask for forein help. Also the other nations that reconquer the town in your already conquered country they have the option to grant the city its independence back to you.
Another Idea is that when you invade a square that has an enemy unit in it you have the option to play a RTS battle(like Age of Empires III) to take that square. If the square you are invading from has more Units you will receive reinforcements every 5 minutes. And the closest city to the invasion force will be like the home city in Age of Empires III. Also you can switch between the world map and the battle map. This Idea will get people that like the RTS in to the game.
I am thinking about becoming a game developer. If you would like to send me a Disk(I don't trust downloads anymore. Downloads have been screwing up my computer.) of the game to play test I will be more than welcome to. Here's my e-mail so that we can get into closer contact: mickey.martin7@gmail.com
Bomberman2
Chieftain
- Joined
- Feb 21, 2009
- Messages
- 11
I actually perfer civ3 graphics.
If an RTS type element is added to the game why not go to a first or third person shooter (I would like this alot as I also a console gamer) like playing as a soldier and having some sort of effect on the battle, depending on your performance as a in a console type game. This could also eliminate events like spears beating tanks, as it would not be based on random chance but on a player's skill in battle.
Having said this, this type of game would not only be incredibly hard to program, but would cause your actual civ game to become extremly long and tedious. With every battle being played in real time, even a part of a battle such as naval bombardment or aerial combat, the game would take a very long time to go from ancient to modern, especially on a large map or a game with many wars.
The spearmen vs tank has nothing to do with a FPS or RTS, it's just bad design of the combat system.
If you read a little the thread, you'll see that I already planned two level og games: strategical game and tactical battles.
But they will not be RTS, just TBS.
Imagine a civ game on a smaller map (20x20?), with only military units, no techs, no economy, just combat and more options (like improved range warfare).
If you read a little the thread, you'll see that I already planned two level og games: strategical game and tactical battles.
But they will not be RTS, just TBS.
Imagine a civ game on a smaller map (20x20?), with only military units, no techs, no economy, just combat and more options (like improved range warfare).
Last time I showed the principle of attribute inheritance with simple attributes.
Now, I will explain something a little more complex.
As a prerequesite, I've create two terrains, grassland and plain. As I don't want to waste to much time, I've set grassland as a parent of plain.
So by default, plains share all the attribute of grassland, unless specified differently.
Then I go to my object editor, edit the grassland, and add a new class attribute, the movement speed.
Here I say that by default, the normal movement speed is 6 for every unit in grassland terrain.
So, OK, default is 6... But I would like my cavalry to be faster than infantry. I want it to be twice as fast.
So I add a new attribute, but instead of keeping "any class", I select a specific class, here cavalry, and I say the attribute is modify by a percentage, 200%
This way, cavalry has a speed of 12. Obviously, if I go back to the "any class" and change it from 6 to 7, the cavalry final speed will be 14.
I could also remove an attribute. Like here: I say that the "heavy" subclass of the "cavalry" class doesn't have an attribute in grassland. So heavy cavalry will not be allowed to move in grassland, while light cavalry will move twice faster than infantry.
I'm happy with the movement speed in grassland, I'll now go to the plain.
I want the speed in plain to be slightly faster, by default (for most units).
So I edit the plain, and add a new "movement attribute", any class. But this time instead of applying the change to the class, I apply it to the parent.
And then, I want to have a specific movement speed for light cavalry.
So I add an attribute for it.
First possibility: I apply it to the parent (120% modifier).
The final result is 14.4 (base speed for grassland = 6, x200% for cavalry, x120% for cavarly in plain).
The list of classes can be freely edited. You can add, or remove them as you want, with two levels (class/subclass).
And the principle will be extended for many things.
With this you can adapt the movement cost or the combat bonus for terrain relatively to units, or bonus for unit class against another class, etc.
Now, I will explain something a little more complex.
As a prerequesite, I've create two terrains, grassland and plain. As I don't want to waste to much time, I've set grassland as a parent of plain.
So by default, plains share all the attribute of grassland, unless specified differently.
Then I go to my object editor, edit the grassland, and add a new class attribute, the movement speed.
Here I say that by default, the normal movement speed is 6 for every unit in grassland terrain.
So, OK, default is 6... But I would like my cavalry to be faster than infantry. I want it to be twice as fast.
So I add a new attribute, but instead of keeping "any class", I select a specific class, here cavalry, and I say the attribute is modify by a percentage, 200%
This way, cavalry has a speed of 12. Obviously, if I go back to the "any class" and change it from 6 to 7, the cavalry final speed will be 14.
I could also remove an attribute. Like here: I say that the "heavy" subclass of the "cavalry" class doesn't have an attribute in grassland. So heavy cavalry will not be allowed to move in grassland, while light cavalry will move twice faster than infantry.
I'm happy with the movement speed in grassland, I'll now go to the plain.
I want the speed in plain to be slightly faster, by default (for most units).
So I edit the plain, and add a new "movement attribute", any class. But this time instead of applying the change to the class, I apply it to the parent.
And then, I want to have a specific movement speed for light cavalry.
So I add an attribute for it.
First possibility: I apply it to the parent (120% modifier).
The final result is 14.4 (base speed for grassland = 6, x200% for cavalry, x120% for cavarly in plain).
The list of classes can be freely edited. You can add, or remove them as you want, with two levels (class/subclass).
And the principle will be extended for many things.
With this you can adapt the movement cost or the combat bonus for terrain relatively to units, or bonus for unit class against another class, etc.
Similar threads
