While I'm also helping out with SWTA, I'm also allways thinking of doign my own Spring game(I Prefer game over mod since mod is so unfitting for a spring project. It's like callign all Unreal engine based games mods... kinda )
but the mod/Game I'm imaginging won't be that similar to TA, as suchs, in some way it would be and in some ways not. What I do wnat is for it to be made such that it is mostly designed to used water based maps, where the water will be the main dividng field between players and also the main and best route for troop transport.
Which requires carriers of course. But currently carriers are nothign more than mere repair and rearm stations(if you use the use ammo thing). I want them to actuallybe usefull and function AS carriers. for this I've thought out a 3 stage aproach to introducing new carrier code to the game without doing it all at once.
Stage 1:
First for this to work I need units to be able to use other units as ammo(yeah I'm sure some of you are thinking StarCraft fanboy now, but I actually really dislike SC, but it does have some good ideas :p). The Carrier would then have a set number of planes aboard, using the sammo ammo tag as you can now use on planes to have them return to rearm, in addition, as planes are shot down, the carrier will also need to return to port, t rearm itself with planes.
I'm not sure if you can make ammo cost something when rearming but this would \obviusly need to be added too(no free planes dammit)
The Carrier would then in the first version of this carrier code act simply as an air defense unit for naval fleets. if Set to defend mode if would automatically launch fighters when enemy planes are in range. and you'd have a "scramble button" added to the interface that launches the planes, it coudl also double as a target button, or you could have a separate target button to make the planes target specific targets(instead of making the unis individually selectable wich would probably be more diffficult if they are treated as a weapon themseves)
You'd of course have a tag for the carrier that sets what kind of planes it carries and what type(unit) it is.
Stage 2:
With air defense taken care off, stage 2 would be a relatively simple modification to the code, allowing the carriers to carry at least 2 different planetypes. And also adding an "attack"/"strike" button along witht he scramble button. So the second type of plane would be some kind of ground attack fighter you coudl use for ground attacks(duh).
should be a somewhat simple modification witht he code allready done for stage 1 done.
Stage 3
Stage 3 is where it gets more interesting again :).
At stage 3, instead of just havign the attack and scramble buttons, you'd have all the planes listed on the side menu withthe carrier selected, divided into plane types. Which also means you can have more than 2. This way you could have some number of ground attack fighter, some air superiority, some Awacs, and maybe some VTOL Gunships.
You'd also be able to mark multiple individual units and launch them.
And an idea to go along with this, maybe give each launched squadron a sequental , but recycled squad number. and then either go to simple way of using a separate alt or ctrl+ number keys to select squads. Or have it so that if the Carrier is assigned group 2, you could click 2 collowed quickly by 4 to select squad 4 from this carrier, wich would allow for more squadrons with lots of carriers
Anyway, this owuld be a nice addition to Spring, and something more mods could use I believe. and I even divided the developement to the final version into several iterations (yay for iterative programming:))
Carriers reimagined
Moderator: Moderators
everything is relative.
And if you don't add new features to the enigne outside of new graphics effects, Sprign will never be more than a TA/Supcom clone.
Spring needs to expand and be more than these games, TA is where Spring came from, but it shouldn't be where sprign dies, and neither should Supcom.
And if you don't add new features to the enigne outside of new graphics effects, Sprign will never be more than a TA/Supcom clone.
Spring needs to expand and be more than these games, TA is where Spring came from, but it shouldn't be where sprign dies, and neither should Supcom.
plz watch what u say. The devs have added way more than "graphical effects" and saying otherwise is just ignorant.
I really like this idea however it is a lot of work regardless of wether or not u think it is. This means a lot of changes to the code with god knows how many interlinked pieces involved. this isn't just plopping down a few lines of code. It would take extensive work and testing to even make it remotely feasible.
I really like this idea however it is a lot of work regardless of wether or not u think it is. This means a lot of changes to the code with god knows how many interlinked pieces involved. this isn't just plopping down a few lines of code. It would take extensive work and testing to even make it remotely feasible.
-
Shadowsage
- Posts: 73
- Joined: 01 Dec 2005, 05:50
The problem is that there is no neat, generalized way to make some of the elaborate changes we're talking about.
Imho, the best approach would be as follows:
1) a good easy-to-use scripting language and workflow for UnitAI. Like setting up the Lua interpreter to handle UnitAI calls.
2) a way to force unit X to use a given UnitAI.
3) a way to eliminate units from being able to take certain (or all, in the case of fighters) orders.
For example, I'm assuming a Starcraft-style carrier.
So you have a waterunit that owns a factory and a bunch of internal airbases. The Lua-scripted unitAI overrides orders to the factory to provide a limit on the total number of units that this air plant can own. It also passes along any attack orders given to the carrier to it's child fighters. Child fighters are ordered to dock in the bay when not attacking, and return to their parent when out of fuel (fuel is currently a hardcoded concept).
The only problem is that unitAI is currently clientside, and we'd need this to be serverside unitAI, or else a player could hack their unitAI files to be smarter.
This would be the most generalized solution to the problem of complex unit behaviouirs... but also the biggest burden on the modder, since they'd have to script the specialized behaviours themselves in the AI script language. A scripting language is necessary though, since AI dlls are a maintenance nightmare for modders, and also bad for Linux/Mac ports of Spring.
edit: reading your design over further, the best approach for giving the units individual orders would be to have them be individual units. The current airbase functionality is really what you're looking for, combined with the fuel limit (yes, Spring supports aircarft with fuel).
Really, if you want a basic carrier (a unit that just transports air) you can do that right now with a bunch of airbase platforms (see AA's carrier). To get the "return home" behaviour in planes, just use fuel limits. The carrier won't pass orders off to the planes, but planes are pretty smart about attacking nearby targets, and you can select planes that are sitting in airbases individually or in groups or in "all of this class". Just drag a box around the whole carrier and order an "attack" command to get them to rush a target.
Imho, the best approach would be as follows:
1) a good easy-to-use scripting language and workflow for UnitAI. Like setting up the Lua interpreter to handle UnitAI calls.
2) a way to force unit X to use a given UnitAI.
3) a way to eliminate units from being able to take certain (or all, in the case of fighters) orders.
For example, I'm assuming a Starcraft-style carrier.
So you have a waterunit that owns a factory and a bunch of internal airbases. The Lua-scripted unitAI overrides orders to the factory to provide a limit on the total number of units that this air plant can own. It also passes along any attack orders given to the carrier to it's child fighters. Child fighters are ordered to dock in the bay when not attacking, and return to their parent when out of fuel (fuel is currently a hardcoded concept).
The only problem is that unitAI is currently clientside, and we'd need this to be serverside unitAI, or else a player could hack their unitAI files to be smarter.
This would be the most generalized solution to the problem of complex unit behaviouirs... but also the biggest burden on the modder, since they'd have to script the specialized behaviours themselves in the AI script language. A scripting language is necessary though, since AI dlls are a maintenance nightmare for modders, and also bad for Linux/Mac ports of Spring.
edit: reading your design over further, the best approach for giving the units individual orders would be to have them be individual units. The current airbase functionality is really what you're looking for, combined with the fuel limit (yes, Spring supports aircarft with fuel).
Really, if you want a basic carrier (a unit that just transports air) you can do that right now with a bunch of airbase platforms (see AA's carrier). To get the "return home" behaviour in planes, just use fuel limits. The carrier won't pass orders off to the planes, but planes are pretty smart about attacking nearby targets, and you can select planes that are sitting in airbases individually or in groups or in "all of this class". Just drag a box around the whole carrier and order an "attack" command to get them to rush a target.
The main thing I get from this idea, frankly, is that you're not really thinking the gameplay issues through very well. Or that you're confused about what RTS players want.
There's a good reason why things this complex aren't in any RTS games- it's simply too much micromanagement to be much fun. I'm having trouble imagining the amount of user-directed controls that would be necessary to use this fully-functional and totally simulated carrier in a game, honestly. You'd have to start with making the game's scale so vast and time between events so long that controlling this monstrosity would be practical... or give it a super-robust UnitAI that would pretty much cause it to operate without any but the most general instructions ("go here", "attack here", "guard this").
Deeper control, in the context of a fast-moving game, would be both un-necessary and entirely pointless as a practical exercise. And if you're going to do this through UnitAI, then you're going to not only have a huge piece of very complex code running, at a serious detriment to overall performance, but that code must be flexible enough that it can meet the demands of your players. It's a very tall order.
I've seen stuff as complex as what you're talking about in serious war simulations. However, I'll be the first to say that unless you're a serious military buff, these sims are far from fun.
Ever played the classics of this sort've thing, like Harpoon? They're so complex, and require so much practice and study of the UI, that they're not going to appeal to typical RTS gamers. They're for people who really just want to play out an ultra-realistic WWIII scenario, or discover whether the bombing of Libya in the 1980's could've been done more efficiently or whatever.
That sort've thing is to RTS gameplay what a good comic book is to Proust. Both are art forms. Both involve reading. They're equally "good" in the subjective sense- they both can involve personal enjoyment. However, they're completely different animals in substance.
So, to summarize:
1. Even if this idea was realisable tomorrow, I'd say it was a bad idea in a RTS context, because it involves far too much UI complexity and way too much overhead on the UnitAI end. The only way you'd be able to make it practical, at least so far as I can see, is to make the entire game design centered around these carriers, and make darn sure that there weren't very many of them in play at once, to avoid overwhelming people's processors. That's a pretty limited game design scope.
2. I don't think something like this is what Spring should aim for. While it'd be great for people with tremendous amounts of talent and free time to code up a UnitAI that would do this kind've thing, as well as the customized UI that would be required, I find it very unlikely that this would be something most modders would want to tackle, and I seriously doubt that anybody's going to code it for you, just because it sounds vaguely cool for your very specific use. So... if you're serious about this idea... sit down with Spring's codebase, and start studying how AI calls are made, and write a GroupAI or three, because these are in the gray area between PlayerAIs and UnitAI, and can use the PlayerAI hooks for the most part, other than the cheating code.
At any rate... if you want it badly enough, then you'll figure it out. I can't say I think it's a good idea, but "good" is entirely subjective- you want Proust, and I want a good comic book. This doesn't make your idea "wrong", so don't take my critique badly, please- you're perfectly entitled to whatever Dream Game you are willing to put the effort into building
There's a good reason why things this complex aren't in any RTS games- it's simply too much micromanagement to be much fun. I'm having trouble imagining the amount of user-directed controls that would be necessary to use this fully-functional and totally simulated carrier in a game, honestly. You'd have to start with making the game's scale so vast and time between events so long that controlling this monstrosity would be practical... or give it a super-robust UnitAI that would pretty much cause it to operate without any but the most general instructions ("go here", "attack here", "guard this").
Deeper control, in the context of a fast-moving game, would be both un-necessary and entirely pointless as a practical exercise. And if you're going to do this through UnitAI, then you're going to not only have a huge piece of very complex code running, at a serious detriment to overall performance, but that code must be flexible enough that it can meet the demands of your players. It's a very tall order.
I've seen stuff as complex as what you're talking about in serious war simulations. However, I'll be the first to say that unless you're a serious military buff, these sims are far from fun.
Ever played the classics of this sort've thing, like Harpoon? They're so complex, and require so much practice and study of the UI, that they're not going to appeal to typical RTS gamers. They're for people who really just want to play out an ultra-realistic WWIII scenario, or discover whether the bombing of Libya in the 1980's could've been done more efficiently or whatever.
That sort've thing is to RTS gameplay what a good comic book is to Proust. Both are art forms. Both involve reading. They're equally "good" in the subjective sense- they both can involve personal enjoyment. However, they're completely different animals in substance.
So, to summarize:
1. Even if this idea was realisable tomorrow, I'd say it was a bad idea in a RTS context, because it involves far too much UI complexity and way too much overhead on the UnitAI end. The only way you'd be able to make it practical, at least so far as I can see, is to make the entire game design centered around these carriers, and make darn sure that there weren't very many of them in play at once, to avoid overwhelming people's processors. That's a pretty limited game design scope.
2. I don't think something like this is what Spring should aim for. While it'd be great for people with tremendous amounts of talent and free time to code up a UnitAI that would do this kind've thing, as well as the customized UI that would be required, I find it very unlikely that this would be something most modders would want to tackle, and I seriously doubt that anybody's going to code it for you, just because it sounds vaguely cool for your very specific use. So... if you're serious about this idea... sit down with Spring's codebase, and start studying how AI calls are made, and write a GroupAI or three, because these are in the gray area between PlayerAIs and UnitAI, and can use the PlayerAI hooks for the most part, other than the cheating code.
At any rate... if you want it badly enough, then you'll figure it out. I can't say I think it's a good idea, but "good" is entirely subjective- you want Proust, and I want a good comic book. This doesn't make your idea "wrong", so don't take my critique badly, please- you're perfectly entitled to whatever Dream Game you are willing to put the effort into building
Actually this was made to be easy. like the aiutoscramble of the carrier fighters.
I'm not sure "you" know what "all" RTS players want either.
and this is no more difficult that managign allready existing units, you select units and tell them to attack they go within range and fire weapon.
you select carreir groups and select to "strike", they go within range and launch their strike squadrons. in fact it reduces micro as you don't have to manage the indidual fighters at ALL. being abel to select and manage indidivual fighters aboard the carriers was part of stage 1, but that doesn't remove the abilities for no micro in Stage 1 and 2. And remember Spring is an Engine, it doesn't and shouldn't cater to a single type of gameplay.
The stage 3 part of for more advanced players who WANT to have more control.
This whol thing was abotu makgin fighter the Carriers "weapon" so that it attacks with them, and they are treated as Ammo and in turn the carriers then need to return to port to replenish downed fighters.
And outside of hitting attack all this would be automatic, and it would remove air clutter from permanent cirlcing fighters, add realism by not havign permamently circlign fighters.
and it's be usefull to a whole range of mods from WWII mods, to modern day mods to SciFi mods like mine.
I'm not sure "you" know what "all" RTS players want either.
and this is no more difficult that managign allready existing units, you select units and tell them to attack they go within range and fire weapon.
you select carreir groups and select to "strike", they go within range and launch their strike squadrons. in fact it reduces micro as you don't have to manage the indidual fighters at ALL. being abel to select and manage indidivual fighters aboard the carriers was part of stage 1, but that doesn't remove the abilities for no micro in Stage 1 and 2. And remember Spring is an Engine, it doesn't and shouldn't cater to a single type of gameplay.
The stage 3 part of for more advanced players who WANT to have more control.
This whol thing was abotu makgin fighter the Carriers "weapon" so that it attacks with them, and they are treated as Ammo and in turn the carriers then need to return to port to replenish downed fighters.
And outside of hitting attack all this would be automatic, and it would remove air clutter from permanent cirlcing fighters, add realism by not havign permamently circlign fighters.
and it's be usefull to a whole range of mods from WWII mods, to modern day mods to SciFi mods like mine.
1. There is no ammo for weapons. You can add that with a script but it's not supported by the engine itself. Planes can have fuel and weapons can use that fuel up but only airfields can restore fuel, you'd need to implement a new refueler system for ground units.
2. Units cannot be weapons. The weapon system is very limited.
Implementing it like that would require huge rewrites AFAIK. It's much easier to 1. allow transporters to build units internally (since nothing needs to be visible for that, just make it use the ressources, count how long it takes to build the unit and when it's done add it to the transporter's cargo bay) and 2. allow transporters to automatically unload and relay attack orders to units inside. Making the planes return is more difficult but you could use the fuel system to prevent them from going too far away.
This would also allow building planes on land and sending them to support the carier group while automatically adding them to the group (since any plane landing on the carrier would become its property). After all, a carrier is but a mobile airbase.
2. Units cannot be weapons. The weapon system is very limited.
Implementing it like that would require huge rewrites AFAIK. It's much easier to 1. allow transporters to build units internally (since nothing needs to be visible for that, just make it use the ressources, count how long it takes to build the unit and when it's done add it to the transporter's cargo bay) and 2. allow transporters to automatically unload and relay attack orders to units inside. Making the planes return is more difficult but you could use the fuel system to prevent them from going too far away.
This would also allow building planes on land and sending them to support the carier group while automatically adding them to the group (since any plane landing on the carrier would become its property). After all, a carrier is but a mobile airbase.
The idea sounds like an awfully complex version of the aircraft carrier in Red Alert 2.
That was a normal unit (no extra UI controls) with aircraft (1 type) as weapon. Ie. attack sends out the planes to the target. Aircraft that died were regenerated for free by the ship (but that took some time). I forgot whether the planes itself where user controllable.
That was a normal unit (no extra UI controls) with aircraft (1 type) as weapon. Ie. attack sends out the planes to the target. Aircraft that died were regenerated for free by the ship (but that took some time). I forgot whether the planes itself where user controllable.
Carriers should have the following options
Protoss style carriers from starcraft that build aircraft internally then send them out to attack
HW2 style carriers that build fighters but can also have them dock with the carrier internally so the carrier can jump to hyperspace then release at target
TA style repair pads and radar, with possible construction but no storage.
But not all 3 at once. You have to keep them simple
Protoss style carriers from starcraft that build aircraft internally then send them out to attack
HW2 style carriers that build fighters but can also have them dock with the carrier internally so the carrier can jump to hyperspace then release at target
TA style repair pads and radar, with possible construction but no storage.
But not all 3 at once. You have to keep them simple
I like the red alert idea, seems simple enough to be feasible, but a tad to simple to be taken full advantage of. So, heres my proposal of how to handle it, instead of automatically regenerated for free they would be built by clicking their little build pic and take up a bit of storage, then could be selected as individual types by clicking the icon next to their build pic.
From there you would controll them like any other group except they would still have to return for fuel and weapons as per the modders choice, you could then either select them normally or click the same icon you used to select them the first time in the carrier to give them new orders or return to ship.
I'm not entirely sure how to handle selecting part of the group, but what do you guys think of my idea gameplay wise? Or coding wise if you have a clue about coding spring.
From there you would controll them like any other group except they would still have to return for fuel and weapons as per the modders choice, you could then either select them normally or click the same icon you used to select them the first time in the carrier to give them new orders or return to ship.
I'm not entirely sure how to handle selecting part of the group, but what do you guys think of my idea gameplay wise? Or coding wise if you have a clue about coding spring.
Soo.... that'd be IsTransport=1, and something like "InternalBuilder=1" and "UnloadAttack"?
The units built could be put onto the transport's available "slots" and handled by the BOS code upon being built, just like any other unit, with extras being halted from being built until slots are free (to prevent players from building 1000 fighters in one tiny carrier).
That might be a good way to handle that issue, and yet keep it within Spring's current limitations. Moreover, if done that way, it'd allow HawkMan's ideas of multiple types of aircraft. However, scripting that puppy on the BOS side would be a ... er... it'd be bad. Really, really, really painful. Doable, yes. Fun, no.
The units built could be put onto the transport's available "slots" and handled by the BOS code upon being built, just like any other unit, with extras being halted from being built until slots are free (to prevent players from building 1000 fighters in one tiny carrier).
That might be a good way to handle that issue, and yet keep it within Spring's current limitations. Moreover, if done that way, it'd allow HawkMan's ideas of multiple types of aircraft. However, scripting that puppy on the BOS side would be a ... er... it'd be bad. Really, really, really painful. Doable, yes. Fun, no.
This kind of mentality is a dead end. It adds tremendous complexity to the engine for each type of unit, and maybe one game will use each class. In that kind of case, it's best to load the hard parts and complex parts of unit behaviour onto the modder, or else each modder will beg for minute differences in the carrier behaviour.AF wrote:Carriers should have the following options
Protoss style carriers from starcraft that build aircraft internally then send them out to attack
HW2 style carriers that build fighters but can also have them dock with the carrier internally so the carrier can jump to hyperspace then release at target
TA style repair pads and radar, with possible construction but no storage.
But not all 3 at once. You have to keep them simple
That's why I think simpler concept: 1) units that can build into an internal bay, and 2) a way to make unit AI forced onto those units so I can restrict their functionality into the Protoss Carrier-style of play.
Really, the way that random shopping for features keeps getting added to the engine is just making it complex without making it powerful. Instead of getting more generalized, we're getting "TA with switchable high-trajectory guns" etc.
There already are (sometimes 
) working airfields that can repair airplanes. With the new fuel-system they will probally be able to refuel planes as well.
Now just put this on a ship and voilá you have an carrier that can repair and refuel all aircrafts. (The aircrafts would have to be smart enough to go to the nearest free carrier when in need of repair/fuel)
If you want to limit the carrier-use to special "sea-planes" (ie Harriers and helicopters) the airfield would need some "AllowLanding=plane1,plane2,plane3;" tag.
To limit the distance that planes can fly away from the carrier just give fuel for only 30 seconds or something.
If you want the planes to stay on the carrier after refueling, you would need to press "s" for stop or maybe toggle it with the "on/off" options of the carrier, that would open/close the bay or something.
I think thats the easiest way to use for the player and hopefully not too complex to include for the devs.
) working airfields that can repair airplanes. With the new fuel-system they will probally be able to refuel planes as well.Now just put this on a ship and voilá you have an carrier that can repair and refuel all aircrafts. (The aircrafts would have to be smart enough to go to the nearest free carrier when in need of repair/fuel)
If you want to limit the carrier-use to special "sea-planes" (ie Harriers and helicopters) the airfield would need some "AllowLanding=plane1,plane2,plane3;" tag.
To limit the distance that planes can fly away from the carrier just give fuel for only 30 seconds or something.
If you want the planes to stay on the carrier after refueling, you would need to press "s" for stop or maybe toggle it with the "on/off" options of the carrier, that would open/close the bay or something.
I think thats the easiest way to use for the player and hopefully not too complex to include for the devs.