Modding unit classes

[LDiCesare]

Since we can do little but speculate right now, here's food for thought.
Do you think wa might be able to mod in new unit classes?
Even better, to mod new dynamic unit classes?

Under all likelihood, I've now lost half of the potential audience of this thread. What do I mean?
We know that there's one unit per tile.
We know that there's actually one unit of a kind (military != worker) per tile.
So if we can add new unit kinds, we can stack more units in a single tile.
If we can create new unit kinds dynamically, we can put each new unit in its own kind. Which means we effectively got rid of 1 unit per tile.
Note that I think 1 unit per tile sounds great. I loved Fantasy General. But those who dislike the idea might very well be able to get rid of it by modding. The "dynamic unit class" being just one idea.

 

[Yakk]

Almost certainly the "one unit per tile" thing will be a value in the code set to 1 by default.

Ie, I strongly suspect that allowing 2 military units per tile will be as easy as changing a number from 1 to 2, and allowing unlimited as easy as changing 1 to -1 (or some flag value).

 

[LDiCesare]

It may be more complex, since you have to decide which unit(s) to draw. It's likely that only one unit of one kind will be depicted. If not, then changing the number will lead to lots of units being drawn in the same place and a big mess.
It's also far more natural to code something like:

class Tile
{
 Unit* currentUnit;
};

and using currentUnit than

class Tile
{
 Unit currentUnit[1];
};

and iterating on a size 1 array in case someone would want to change the value.

 

[Gre_Magus]

Yakk may be right. But I also think that it may be possible to mod in a new unit "class." This might be useful if someone wanted to create a mod that distinguished, let's say, ranged units from non-ranged, and allowed one of each to be present in a stack.

Then again, on second thought, the combat system may not be able to handle more than one unit with a combat strength value present in a hex. In Civ 4, the strongest defender in a stack defends, and only it is damaged. In Civ 1, the strongest defender defended, but if it was destroyed, the whole stack went with it. How would that work in Civ 5? I've seen rumors (I think they're rumors) based on the way things work in Panzer General that a unit might retreat after if it loses in Civ 5. If you had more than one unit in a hex, would they both retreat? Would the unit(s) that wasn't (weren't) involved in the combat be left in the hex? I guess what I'm saying is that adding stacked combat to a system that is designed for one combat unit per hex is probably more difficult than it seems at first glance.

 

[Gre_Magus]

LDiCesare said

It may be more complex, since you have to decide which unit(s) to draw.

I imagine they already have a solution for this problem, since it is confirmed that you will be able to have a civilian and a military unit together on the same hex.

 

[Decimatus]

Changing 1UpT may be more complicated than just changing values in 1 spot.

1 The combat system is going to be based upon 1UpT. You will have to tell it how to deal with combat when there are 2 or more units in a hex. IE Which unit is going to defend. Or if all units are fighting together, and if so how.

2 The same for ranged bombardment. You will have to instruct the game as to which unit to hit unless it is defaulted to all units.

 

[Yakk]

Creating N types of units by class stored in each tile is an option. A stupid option, but an option.

Far easier is to store a collection of units by tile (or a tile for a unit, or both), and simply enforce "you cannot have 2 units of the same kind in a tile".

Almost as easy is "you cannot have more than n units of the same kind in a tile". And doing so in development makes it easier to change your mind during development. And given that this game developed from an unlimited unit per tile game (civ4), going to an n unit per tile with a restriction of n=1 is probably an easier path than "one unit of each class per tile" system.

As a side benefit, screwing up the 1 unit per tile rule results in 2 units in a tile. Screwing up "there is one slot per class" rule results in a segfault, or a unit being leaked.