StarCraft
Moderator: Moderators
StarCraft
I'm proposing a project. The idea is to theoretically implement StarCraft. Not a SC mod, nothing playable (and no SC graphics, either), just implement all the scripts, features, etc that would be necessary to implement StarCraft. The goal would be to create a pool of scripts and tricks to implement features from SC for every modder who wants them and to identify things that cannot be done without a lot of workarounds, drawbacks or at all in order to find areas where Spring must be improved.
I was thinking that since TA and SC are pretty much polar opposites, an engine that can implement both of them would be hopefully flexible enough to host almost any mod conceivable.
There is a large volume of requests for features present in StarCraft but not Spring so the demand is there. While some things could be implemented through less obvious ways not every team has a person sufficiently versed in Spring to implement them from scratch and having a "modder's help book" at hand might help some teams to implement features they were planning but incapable of implementing.
Please keep "SC FTL" comments out of this thread, if you don't want to play un-TAish mods get back to AA/BA/XTA/whatever the flavour of the day is because those of us who make mods that aren't just TA stat tweaks don't care if you think the feature doesn't belong into TA. We aren't making TA and we don't want to be forced to limit our game designs because of some fanboy war between SC and TA.
I was thinking that since TA and SC are pretty much polar opposites, an engine that can implement both of them would be hopefully flexible enough to host almost any mod conceivable.
There is a large volume of requests for features present in StarCraft but not Spring so the demand is there. While some things could be implemented through less obvious ways not every team has a person sufficiently versed in Spring to implement them from scratch and having a "modder's help book" at hand might help some teams to implement features they were planning but incapable of implementing.
Please keep "SC FTL" comments out of this thread, if you don't want to play un-TAish mods get back to AA/BA/XTA/whatever the flavour of the day is because those of us who make mods that aren't just TA stat tweaks don't care if you think the feature doesn't belong into TA. We aren't making TA and we don't want to be forced to limit our game designs because of some fanboy war between SC and TA.
StarCraft features that are currently very hard (if not impossible) to do in Spring:
- Resource harvesting model when workers have to return to base to drop off gathered resources;
- Upgrades;
- Prerequisites;
- Terran flying buildings;
- "Spells" that affect other units (most of them are possible, but then every unit has to have script functions for every "spell" that may affect it)
- Attacking without decloaking;
- "Detector" units that reveal cloaked objects to their owner, but not to other players;
- Units that attack with other units (Protoss Carrier);
- Attacks that spawn units (Zerg Queen and "Spawn broodlings" spell);
- Units morphing into buildings (Zerg structures).
Most other things can easily be done using units scripting, others with lua scripts.
- Resource harvesting model when workers have to return to base to drop off gathered resources;
- Upgrades;
- Prerequisites;
- Terran flying buildings;
- "Spells" that affect other units (most of them are possible, but then every unit has to have script functions for every "spell" that may affect it)
- Attacking without decloaking;
- "Detector" units that reveal cloaked objects to their owner, but not to other players;
- Units that attack with other units (Protoss Carrier);
- Attacks that spawn units (Zerg Queen and "Spawn broodlings" spell);
- Units morphing into buildings (Zerg structures).
Most other things can easily be done using units scripting, others with lua scripts.
Starcraftian feature i would most like to see in spring: the way the nuke worked. A unit has to acquire and maintain targetting data for the nuke silo to be able to launch (in the case of SC the ghost). I think this could have some interesting implementations in a few mods
/me wants the hammer of dawn in com shooter
/me wants the hammer of dawn in com shooter
-
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I think I just broke my nose with my own knee...
STARCRAFT SUXXORZZ!!!eleven!
It's like saying "The new Open Source Humanity aims to take reality into account and actually define the laws of physics based on scientific analysis!"
...And then going on to say "However, we also have plans to consider paganism, polytheism, and pretty much any religion that involves baby killing. And Creationist Theory."
STARCRAFT SUXXORZZ!!!eleven!
It's like saying "The new Open Source Humanity aims to take reality into account and actually define the laws of physics based on scientific analysis!"
...And then going on to say "However, we also have plans to consider paganism, polytheism, and pretty much any religion that involves baby killing. And Creationist Theory."
That would be doable. Make the silo a factory that produces invisible, flying things (or if you want the silo to hold only one, invisible immobile things) and let the Ghost build a target (invisible unit that isn't attacked by anything, see e.g. the Debugger in Kernel Panic KDR Edit . That target, once complete, would grab and destroy one of the nuke silo's invisible things and force-fire a nuke from a position above. If there are no invisible things to grab the target just destroys itself (with a weapon that can only hurt targets, of course). The only limitation would be that you can only aim at unoccupied areas.pintle wrote:Starcraftian feature i would most like to see in spring: the way the nuke worked. A unit has to acquire and maintain targetting data for the nuke silo to be able to launch (in the case of SC the ghost). I think this could have some interesting implementations in a few mods
/me wants the hammer of dawn in com shooter
This is kinda how you'd do upgrades, invisible flying things that other units look for. I've successfully applied that in my WIP version of CvC (the upgrades, not the nuke).
Prerequisites could be handled similarily, when the construction begins the unit checks if all prerequisites have been cleared and if not self-destructs.
Forcefiring weapons does not decloak a unit so you could make a unit that shoots without decloaking although it'd probably shoot more often than it should since you'd have to fire when aiming finishes.
Spawning more units can possibly be done with LUA. Units morphing into buildings could be done by the buildings grabbing their builders and destroying them when done.
Flying buildings can be done for factories, let them build a "jetpack", an invisible flying transport that grabs the factory that made it. Once it unloads it self-destructs.
Ok I'm about to rant here... I'm trying to hold it back... and it's not what you think.
I loved StarCraft, WarCraftII, WarCraftIII, Dune, Age of Mythology and a number of other games, there are hundred of thousands of people who have played and loved RTSs that weren't TA, I believe some of those people even attempted to help with the spring project and either went crazy or moved on to the OSRTS project (which I have high hopes for when they get it halfway close to being done as the Spring Project is).
There are many things that a lot of people like about Blizzard style RTSs and there are many things that a lot of people hate, and many of them overlap. There has been endless talk in the feature requests and mod forums on how to implement these features, but very little in the development threads... so I will Quote some Elder Gods to explain the problem:
So, here's the end of what I'm trying to say I guess... figure out everything that you could ever need to do to make starcraft style gameplay work, figure out which things can be done with the engine as it is and make your example units to support this, and put it all somewhere for some imaginary future mod to use (like Zwzsg keeps doing), that way when someone comes in here asking how to do it you can say, check out Unit X to see how it's done and provide a link instead of having big ugly arguments over weather or not it can be.
For things that can't be done make them into a big feature request thread and post it over at OSRTS or learn C++.
I loved StarCraft, WarCraftII, WarCraftIII, Dune, Age of Mythology and a number of other games, there are hundred of thousands of people who have played and loved RTSs that weren't TA, I believe some of those people even attempted to help with the spring project and either went crazy or moved on to the OSRTS project (which I have high hopes for when they get it halfway close to being done as the Spring Project is).
There are many things that a lot of people like about Blizzard style RTSs and there are many things that a lot of people hate, and many of them overlap. There has been endless talk in the feature requests and mod forums on how to implement these features, but very little in the development threads... so I will Quote some Elder Gods to explain the problem:
Here in lies the problem, Modders aren't coders so only those features that coders see value in get implemented.SJ: I think Spring would be better off if you used your time and talent to improve the underlaying C++ code instead of testing how weirdly one can hack the cob files Zwzsg :) (like adding a way to switch movetype on a unit to create proper walking factories)
Zwzsg: I guess I took the bad habit of devising .bos/.cob workaround instead of modifying straight at the source when modding TA.
I'm afraid that if start learning C++ I'll get swallowed whole by it.
Oh, and most of the change in the source needed to have it work are already made. All I'd need changed is to have transported buildings not blocking the terrain they are over anymore. And maybe something to read the unitlimit from the script, cause it's bit dirty to have to suppose it's always 5000. But I think that even if maybe it wasn't supposed to happen, the current code is able to handle those factories welded on the back of mobile units. And anyway, even after modifying the source code, one would still have to make and script a demonstration unit, so
So, here's the end of what I'm trying to say I guess... figure out everything that you could ever need to do to make starcraft style gameplay work, figure out which things can be done with the engine as it is and make your example units to support this, and put it all somewhere for some imaginary future mod to use (like Zwzsg keeps doing), that way when someone comes in here asking how to do it you can say, check out Unit X to see how it's done and provide a link instead of having big ugly arguments over weather or not it can be.
For things that can't be done make them into a big feature request thread and post it over at OSRTS or learn C++.
Damn right, I hate all craft games but WarCraft 1 with a passion for their stupid straight forward gameplay and limitations. SC FTL!!!
But, since we are looking at features, I totally agree. Makes spring more flexible and that is good. Would be even better if things which are strongly limited (or influenced) by TA would get "fixed" along the way.
The way weapons are done for example. Freedom would mean that weapon types do not influence the way they are rendered (blended for sprites) or how physics apply. This just bothers me the most...
Okay this might take it in the wrong direction, you can either implement starcraft or fix mundane things like this (by fix I mean add switches to change behavior, before anyone bitches at me for being careless or even clueless). I prefer the whole 9 yards instead of expanding spring's flexibility into one direction only.
The major problem is probably to find someone who wants to put some effort into spring to get at least some of the SC features done for a start.
But, since we are looking at features, I totally agree. Makes spring more flexible and that is good. Would be even better if things which are strongly limited (or influenced) by TA would get "fixed" along the way.
The way weapons are done for example. Freedom would mean that weapon types do not influence the way they are rendered (blended for sprites) or how physics apply. This just bothers me the most...
Okay this might take it in the wrong direction, you can either implement starcraft or fix mundane things like this (by fix I mean add switches to change behavior, before anyone bitches at me for being careless or even clueless). I prefer the whole 9 yards instead of expanding spring's flexibility into one direction only.
The major problem is probably to find someone who wants to put some effort into spring to get at least some of the SC features done for a start.
Ok, that point wasn't key, I think the main point is that the best way for a feature that a modder wants implemented in this project is for them to do it themselves and the "real" devs might not have time to make sure it's good enough to be included for a long time... I think the better way to put it is that the Lead Devs are currently too busy to be modders... is that safe to say?FLOZi wrote:Speak for yourself. I know of atleast 3 modders who have submitted patches which have been comitted.Modders aren't coders
edit: also, I think we should call this the "Things Spring Can Do Already and Here's How" Project, everything else is just feature requests.
- Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
That's just the point of the "modders are not coders", while we have some modders who can code, we don't have any who can do more than minor things... we have perhaps 6 people who can actually do major things in the code, and none of them mod.FLOZi wrote:Anyway, I'm currently open to (minor) requests
edit. On the original topic, add prerequisites a la "building X is required for building Y to be buildable", and "building X is required for unit Y to be buildable". Ideally we would also have the ability to have a substitute buildpic for a building whose prerequisite is not met.
- Lolsquad_Steven
- Posts: 488
- Joined: 27 Jun 2006, 17:55
I asked for a simpler way of doing this, having a tag that implied the unit was illuminating the target and if the shooter died then so did the target lock of the weapon. If the shooter's team/side lost contact with the unit (visual/radar) then the lock would be lost, too. I realize you don't want to shoot without illumination of the target, but the idea I had requires illumination before it can fire.KDR_11k wrote:That would be doable. Make the silo a factory that produces invisible, flying things (or if you want the silo to hold only one, invisible immobile things) and let the Ghost build a target (invisible unit that isn't attacked by anything, see e.g. the Debugger in Kernel Panic KDR Edit . That target, once complete, would grab and destroy one of the nuke silo's invisible things and force-fire a nuke from a position above. If there are no invisible things to grab the target just destroys itself (with a weapon that can only hurt targets, of course). The only limitation would be that you can only aim at unoccupied areas.pintle wrote:Starcraftian feature i would most like to see in spring: the way the nuke worked. A unit has to acquire and maintain targetting data for the nuke silo to be able to launch (in the case of SC the ghost). I think this could have some interesting implementations in a few mods
/me wants the hammer of dawn in com shooter
This is kinda how you'd do upgrades, invisible flying things that other units look for. I've successfully applied that in my WIP version of CvC (the upgrades, not the nuke).
Prerequisites could be handled similarily, when the construction begins the unit checks if all prerequisites have been cleared and if not self-destructs.
Forcefiring weapons does not decloak a unit so you could make a unit that shoots without decloaking although it'd probably shoot more often than it should since you'd have to fire when aiming finishes.
Spawning more units can possibly be done with LUA. Units morphing into buildings could be done by the buildings grabbing their builders and destroying them when done.
Flying buildings can be done for factories, let them build a "jetpack", an invisible flying transport that grabs the factory that made it. Once it unloads it self-destructs.
This would make it easier to simulate semi-active homing on missiles.