This could be a bit more complicated.
What I'm proposing is allowing units to have build spots on themselves. Certain attachments could be built on those. When constructing something that needs a socket all available sockets are highlighted and when you mouse near one the nearest is highlighted and shows a preview of the attachment. Attachments would also be able to have sockets so you could essentially have a tree structure.
Each attachment would have a tag telling it whether it should act independently (i.e. be selectable and receive orders) or inherit the orders from its parent so you can do both "integral" parts of the unit and separate parts.
An attachment would be able to have any role a building can currently have, especially including factories.
Obviously not all attachments fit on all sockets.
This would be useful for e.g. flying bases like spaceships or stations (or the fortresses in Stratosphere) that could be expanded with stuff or buildings that get expanded like the LC's in Earth 2160 or upgrades in Command and Conquer 2 and 3. Perhaps even modular units like those found in Colony Wars, Earth 2150/60, Warzone 2100, etc but that would require some kind of automation.
Sockets on units
Moderator: Moderators
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I am also interested in looking into this.
I'm interested in commander uprades; this would be one way to do it, though I'd be happy with a hacky (though functional) lua work around.
Possible to simply delete the original unit, then replace it with the "modified" (new) unit?
Say, I have my commander, I click the "shield upgrade" button. It waits until the shield upgrade has been built (not sure how you'd detect this), then you have a smoke and mirrors explosion, and the old, shieldless unit is deleted, and the new shielded unit is created.
Perhaps the player has an option of a shield or a new weapon, but cannot have both; the old unit may have two build pics that he can click, but the new replaced unit with the shield simply doesn't have that in it's build list.
However, I could foresee issues occuring if it was a Comm:ennds game, and the upgraded unit was a commander unit and you removed it, wherein Spring assumes the commander has been destroyed and the game is over...
I'm interested in commander uprades; this would be one way to do it, though I'd be happy with a hacky (though functional) lua work around.
Possible to simply delete the original unit, then replace it with the "modified" (new) unit?
Say, I have my commander, I click the "shield upgrade" button. It waits until the shield upgrade has been built (not sure how you'd detect this), then you have a smoke and mirrors explosion, and the old, shieldless unit is deleted, and the new shielded unit is created.
Perhaps the player has an option of a shield or a new weapon, but cannot have both; the old unit may have two build pics that he can click, but the new replaced unit with the shield simply doesn't have that in it's build list.
However, I could foresee issues occuring if it was a Comm:ennds game, and the upgraded unit was a commander unit and you removed it, wherein Spring assumes the commander has been destroyed and the game is over...
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
Not to sound too off-topic, but the MTR on upgrades has been repeatedly hashed out to a series of non-agreements and zero people willing to code it. (If only the code was so simple to plug in.) With a socket this might just be the springboard so to speak.
If one could use a place marker unit that only had the socket for the unit spawn - the marker counts as the actual unit - then no "switch" would have to take place. The marker could be a temporary-psuedo representation of whatever unit one wanted it to be, but then when the "socket" upgraded the stats would swap to a new temporary-psuedo representation. Destroying the socket would not destroy the unit, but it could be a marker is only worth 1 hit point type of situation and its cob self-d's whenever no socket is detected.
If one could use a place marker unit that only had the socket for the unit spawn - the marker counts as the actual unit - then no "switch" would have to take place. The marker could be a temporary-psuedo representation of whatever unit one wanted it to be, but then when the "socket" upgraded the stats would swap to a new temporary-psuedo representation. Destroying the socket would not destroy the unit, but it could be a marker is only worth 1 hit point type of situation and its cob self-d's whenever no socket is detected.
Well... I think the best approach is a to implement these three seperate ideas:
1) Upgradeable units.
2) Child-attached units.
3) Death-transformation.
1) Upgradeable units. The old mutalisk trick. In that concept, the socket is just an immobile unit that can be upgraded into other immobile units. Upgrades should be able to have negative cost, so you can have downgrade-paths to return a unit back into it's original form.
2) The "child attached unit" is a typical solution to the "mobile factory" issue - you have a normal, mobile unit, but one of it's pieces is actually a fully independant unit. The independant child is an immobile unit or building, like a factory or something. It can be selected and given orders seperately. The child-attached-unit only means that the unit is physically grafted to another - there are three sub-issues for child attached units that will vary depending on needs. The child is killed instantly when the parent dies.
a) independant health-bar - good for "socketed units" but bad for mobile-factories.
b) independant orders - an extra gun doesn't need to be independantly selectable, it can just receive copies of the orders from the parent. A factory is a different story.
3) Obviously, if a part of a larger unit is blown off, you want to be able to rebuild it, so having units that turn back into sockets is necessary. Death-spawning is obviously needed for other tricks too. Of course, you'd have to be careful to make sure that the death-transformation plays nice with the child-object system.
Thus, the socket is an invincible (zero-diameter hitsphere, untargetable and infinite health) child-unit grafted onto the parent unit. Building onto the socket is an upgrade into something more corporeal. When it gets blown off, it turns back into a socket. The invincibility isn't a probelm since the socket dies when the parent unit (commander/starship/whatever) dies.
My point is that all together, these features make the socket possible, but individually these features are also very useful.
1) Upgradeable units.
2) Child-attached units.
3) Death-transformation.
1) Upgradeable units. The old mutalisk trick. In that concept, the socket is just an immobile unit that can be upgraded into other immobile units. Upgrades should be able to have negative cost, so you can have downgrade-paths to return a unit back into it's original form.
2) The "child attached unit" is a typical solution to the "mobile factory" issue - you have a normal, mobile unit, but one of it's pieces is actually a fully independant unit. The independant child is an immobile unit or building, like a factory or something. It can be selected and given orders seperately. The child-attached-unit only means that the unit is physically grafted to another - there are three sub-issues for child attached units that will vary depending on needs. The child is killed instantly when the parent dies.
a) independant health-bar - good for "socketed units" but bad for mobile-factories.
b) independant orders - an extra gun doesn't need to be independantly selectable, it can just receive copies of the orders from the parent. A factory is a different story.
3) Obviously, if a part of a larger unit is blown off, you want to be able to rebuild it, so having units that turn back into sockets is necessary. Death-spawning is obviously needed for other tricks too. Of course, you'd have to be careful to make sure that the death-transformation plays nice with the child-object system.
Thus, the socket is an invincible (zero-diameter hitsphere, untargetable and infinite health) child-unit grafted onto the parent unit. Building onto the socket is an upgrade into something more corporeal. When it gets blown off, it turns back into a socket. The invincibility isn't a probelm since the socket dies when the parent unit (commander/starship/whatever) dies.
My point is that all together, these features make the socket possible, but individually these features are also very useful.
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30