Okay, long post. The first section is a quick response to you question, the second is what I think a general plan should be for the overall design. It's a semi-comprehensive strategy to go by, so hopefully if you like the idea it can be the end-all/say-all and we won't need another big post like this again. If it works I'll post it on the wiki.
Killamike718 said:
Hey Gerikes, Can we add new traits to Civ leaders, like militeristic...etc?
Not sure what you mean. Are you trying to say that you want to create new traits, such as a "Horder" trait for possible zerg leaders (All zergling eggs hatch three zerglings rather than two) or "Covert" trait (All ghosts always cloaked, cloaking takes no energy). Yes, this is possible. We can change the Assets\XML\Civilizations\CIV4TraitsInfos.xml file. I'm not sure if we can implement all these styles of traits in just the xml, I'm sure somewhere in the python there will need to be checks for if a person is of a trait. Luckily, that's what the PyPlayer.hasTrait() function can be used for. For example, at the start (or end) of a persons turn, there might be code saying...
Code:
ZERGLING_UNIT_NUMBER = 23
ZERGLINGS_SPAWNED_WITH_HORDER_TRAIT = 3
ZERGLINGS_SPAWNED_DEFAULT = 2
# Spawn Zerglings at point iX, iY for player p, where iX, iY are the map
# locations of where a zergling egg finished spawning.
if (p.hasTrait(HORDER_TRAIT):
# If the player's leader has the "Horder" trait, they get a different number
# of zerglings on a zergling unit spawn.
p.initUnit(ZERGLING_UNIT_NUMBER, iX, iY,
ZERGLINGS_SPAWNED_WITH_HORDER_TRAIT)
else:
# If the player's leader does NOT have the "Horder" trait, they get the
# default amount of zerglings on a zergling unit spawn.
p.initUnit(ZERGLING_UNIT_NUMBER, iX, iY,
ZERGLINGS_SPAWNED_DEFAULT)
This isn't actual code, just something I wrote as an example, obviously, so it might have bugs or whatever. But it gives you an idea. Even if what we want can't be in the XML files, just give the trait a name and we can make sure to do whatever the hell we want to do with it.
(BTW, these ideas were just some I used to prove a point. I'm pretty sure that a "Horder" traited leader would kill a "Covert" traited leader, considering that ghosts probably wouldn't be in the game until long after the Horder rushed the Coverter : P)
------
Ok, so here were my more higher-level design ideas. It's generally a way that we can hopefully follow to make the transition step-by-step from a Civ4 with Starcraft graphics gradually into a full Starcraft-like mod. This way, in the end, we'll have multiple products that all work, one more SC-like than others, with the concentration for maintanance being on the version(s) that gets the most attention (most likely the vey first one and the most SC-like one at the time.. the "extremes"). The same goes for Warcraft, but since I'm not as familiar with it, I might need some documentaiton in terms of build trees and what buildings make units, etc.
We start off with a Civ4-like mod. There are only cities and units (no unit-building combos like I've discussed earlier). Every unit is built in a city, and every unit can be built from the start. The units have no special features or whatnot, they just have their looks, production costs, attack strengths, and the like, just like if you were making any typical mod civ. Cities grow in population just like always, using the normal terrain values. Keep religions and whatnot (you can change their names and such, but the idea of what they do should be exactly the same as Civ4 with little change other than to establish that you're using starcraft units and stories. Rule of thumb: change the XML files more than the python). We can even have a full tech tree, or if we're lazy, just make the tech "tree" all the upgrades that a player can do in starcraft.
Infantry Weapon Upgrade 1 -> Infantry Weapon Upgrade 2 -> Infantry Weapon Upgrade 3
Infantry Armor Upgrade 1 -> Infantry Armor Upgrade 2 -> Infantry Armor Upgrade 3
Stim Packs
...etc...
The graphics don't have to be great, since I know those can take awhile to develop. Instead, just take normal units (Worker, Axeman, Spearmen, etc.) and rename them to the units we want them to represent.
This stage will be less than alpha. It's our starting point. Later on, we can come back to this as a seperate project and update the graphics or tweak whatever we want, since it's still playable. When the graphics are finished, it can be declared an official mod. However, for the sake of what is happening once the first version of this mod is made, from here on, we make small, minute, incremental changes, and make the results as a seperate mod. We pick one or two things out of a list of changes, and focus on getting those implemented until it's how we like. Then repeat the process with one or two new things. For those who this seems familiar to, it's straight out of the "Extreme Programming" paradigm. Anyway, here is a list of changes that can be made during each iteration:
- City Use: Cities no longer grow, or even do tile collection like normal. This can 'prolly be achieved by setting the population of a city to one, and the citizen becomes a specialist like a typical citizen specialist, where all it does is add hammers to the production of the city. These productions make the unit, just like a unit is created in Civ. Now, a city no longer works like a civ city. Rather, it's only purpose is to make units and mark territory with culture.
- Income and Expenditure (Minerals): Since the civs will no longer be recieving income, they'll have to use workers to do it. By getting the worker unit to stand on a tile with a "mineral" improvement on it and hit fortify (which we can rename to "Mine"), the worker unit can then collect the minerals by checking at the end of each turn for all "foritfied" workers that are on mineral patches and adding X amount of minerals to the players mineral reserve. Also, whenever you start to build a unit, the unit's cost is deducted from your mineral reserves (and late on, vespene gas reserves, when gas is implemented)
- Zerg Unit Building: Change the code so that zerg towns don't build units, but however, every five or so turns since a city's creation, a "Larvae" unit is spawned in a plot adjacent to the city (so long as the city doesn't already have three larvae around it). Allow this "Larvae" unit to be spawned into any zerg creature (barring in mind what buildings have been built. This should be for ANY city, not just the adjacent one. For example, if the player has two cities, called Main and Expansion1, and Main has a Hydralisk Den in it, then any larvae at Expansion1 can be spawned into a Hydra).
- Combat: Completely revamp the combat system to the way we like, or at least pretty damn close. I'm going to post my idea for how combat could work on the wiki, so check that out).
- Race-specific Construction of Buildings: Allow for "buildings" to be made. These can just be improvements on the terrain or whatever, but just make sure that these guidelines are followed:
A.) When a Zerg drone builds a structure, the zerg drone is consumed, and the construction begins. If the construction is cancelled, then the zerg drone reappears on the map.
B.) When a Terran SCV builds a structure, the SCV must stay within the tile where the building is being produced. When the building is finished, the SCV is allowed to move.
C.) When a Protoss Probe starts to "warp" a structure, the probe can move on and do as it wishes immediately after starting the warp.
- Defensive Structures: Using either the idea for defensive structures that I came up with or another way, allow building of Photon Cannons, Sunken Colonies, Spore Colonies, and Missile Turrets. (This will probably have to be done either with or after Race-Specific Construction of Buildings above)
- Buildings: Instead of building all buildings within cities, each building, when under construction, becomes a "construction" unit of some kind. When complete, that unit is replaced either by a city (with the name of the type of building it is. Like, "Alpha Squadron Starport", "Beta Squadron Starport". Then, that city can only build the types of units it typically builds (Transports, Wraiths, etc.
- Economy (Gas): Allow worker units to build their gas-extracting buildings and allow workers to collect just like minerals.
- Protoss Shield/HP: Split all Protoss units into shields and HP. Allow the protoss shield to heal every turn VERY slowly.
- Zerg healing: Allow for zerg units to heal a bit every turn, very slowly.
- Terran medics heal units and SCV's heal armored units: Self-explanatory.
- Units create/store units: This would probably be the central idea around how the more powerful seige units (Seige Tanks in Seige Mode, Reaver, Gaurdian, Carriers) can operate. Make all these units transports as well, and their cargo will...
A.) Attack something and die. Most likely, these will be typical units. (Siege Tank Shell, Reaver Scarab, Gaurdian Spore).
B.) Attack something, then return to the original unit of origin, much like a fighter or bomber in civ (Protoss Carrier)
Things like the Siege Tank can have one ammo shell appear per turn / per 2 turns / per x turns while it is in seige mode. Reavers can build scarabs while on the move for minerals. Same with carriers and their interceptors.
- Allow the user a very simple way to select a tile when asked: This would pave the way for things such as Templar Storms or Science Vessel Emp Shockwaves, or Queen ensnare. Then, obviously, implement each of those moves.
- Allow the user a very simple way to select a specific unit as a target: This would pave the way for things such as a Ghost's Lockdown, Science Vessel's Defensive Shield, etc. (I'm thinking build on whatever happened for the last one, but then have a popup where they select one of the tiles that displays all the units on that tile, which they then must click on).
- Economy (Advanced Economic Gathering): This might be fun, but we can save it for MUCH later. Instead of a unit just standing on it's collection point, it collects for one turn, then moves to the closest Command Center / Nexus / Hatchery, just like in real SC. When it gets there, it drops its load, adding to the reserves, then goes back. Quite frankly, I don't even want to think about this for a LONG time, but I might as well put it down.
Obviously, we can add/remove/change items to this list as we go.
So, for example, we finish the first part of the mod. The xml files are changed, some unit graphics are implemented, and there are fill-in graphics for those that aren't. Great. This is Civ4-Starcraft mod.
Then, we change what we have to this and implement the first change (say, City Use and Mineral Income and Expenditure). Great. Now save a copy of this for safe keeping. Perhaps throw a version number on it. (Version 0.1)
Then, we take what we have so far and make the next changes to it: Zerg unit builds. When this is finished, save again. (Version 0.2)
Next, make another change. Let's find out how we want to do Combat, and implement it. Great, that's changed. We're now at (Version 0.3).
Now say that at the completion of Version 0.3, some more graphics are completed. We can throw these graphics into both the original mod that we created first (replacing the temporary "spearman is a hydralisk" nonsense), as well as the Version 0.3 mod and future versions.
Continue on this path, and you have two seperate mods forming. One is the normal Civ4-like experience, and the other is the total conversion mod. And, in the end, what we've actually done is only create one mod, then build slowly to the other, rather than be building two mods seperately.
I can explain more if this rambling doesn't hold very well explanation-wise, but I think I'll stop here. Sound good?