Spring RTS Engine

Also, I prefer being able to load the texture directly into photoshop instead of having to go through a silly plugin.

THIS :D

i can understand its useful for s44, but for ES png is totally enough

------

the morph/dropship-thing doesn┬┤t work because i have no idea how to use it.

guiz, someone help this boi.

About the tank: can you upload your revised version? I┬┤m curious which faces you removed at the bottom.

missed this post, im at work now so ill pm u later.

Seriously, where do you guys come up with this stuff?

wiki. it says tga is for nubs so nubs use it.
fix it or prepare to write your posting again in texture thread #532 in a few months.

but tga is for nubs. engine spends more time to eat your shitty tga and made mipmaps from it. better way to use preassembled dds with pre-made mipmaps, also dds is better compressed imo.

smoke_th wrote:but tga is for nubs. engine spends more time to eat your shitty tga and made mipmaps from it. better way to use preassembled dds with pre-made mipmaps, also dds is better compressed imo.

thisdis

I played your mod, and I like it! Keep up the good work!

thanks yanom :)

I have some free time on my hands this month, so i will start working on it again.

The next version will have 2 new units and hopefully new/more sounds and explosion effects.

At the moment i am working on the heavy gunship (WIP)

much slower than i hoped, but never the less i made some progress with the unit. Still have to work a bit on the second texture, add normal map before releasing a new version. Also, i┬┤m not entirely sure which role this bird will fill.

anyway, some pictures:

Had a look, haven't managed to try multiplayer, and I have some bug reports/suggestions.

Firstly I don't think you have to reduce unit health. There is a wide range of game speeds and everyone will have their preferences, (judging from evo Forb likes flashy battles that are over in the blink of an eye ). Looking at your speed, range and LOS scales with relation to normal map sizes I get the feeling this game is suppose to be slow and epic so high health is a decent way to go.

The ground units have very annoying manoeuvring. They slow right down and turn on the spot when given an order. You may be able to fix this with 'turninplace = 0' in unitdefs but I'm not entirely certain as tuninplace is broken in this engine version. Instead of turninplace = 0 you could consider messing with accel and deccel.

Hovercraft cannot be transported by the transport aircraft, is this intentional? It is a bit weird as it gives tanks a manoeuvrability bonus. If this is an oversight you can edit modules.lua with this entry: Transportation aircraft take forever to pickup and dropoff units. Additionally when dropping off they drop the unit inside their own hitsphere which causes the transport to fly off and bug below the ground, this can be reproduced with the cloakytank.

Just looking at the firing style of MARS it doesn't look too powerful as I don't think it can hit moving targets at all. Same with raider bikes, I like the idea of a dedicated cheap anti-building unit. It should make for an interesting attacking and defending unit mix.

There is a tag for the drop off thing google.

Quite a while back there were complains about units reacting to slow to given orders. To prevent that, i increased the brake rate to a point which resulted in that behavior. I┬┤m not sure, if i favor it this way or not. Maybe I will test how changing the behavior in the manor you suggest affects the playability while it will surely look better.

The transporter issue is due to the "early" stage of this game. When I included the drop-ship, there were only two ground units and none of them was a hover. After playing around a bit with the .fbi tags, I could not get it to work in the way I wanted it. So after wasting a few hours, I decided to work on creating new units instead. Since then the dropship stayed the way it was.
So, it┬┤s not really intentionally that hovers can┬┤t be transported, I will try to fix that ( thanks for the solution for that problem :).
About the load-, drop-off-speed thing and the unload "dive" thing: it annoys me as well. It is on the has-to-be-fixed-list, just not very far on top. Adding better sounds, fixing the drop-zone build behavior, letting the constructor-truck "morph" into a weak drop-zone, improving some of the weapon effect┬┤s by replacing them with superior ones from evo, and some more stuff, have priority in my opinion.
I have to admit that i myself practically never use the dropship as a transporter because of that bugs, but as a meatshield for my bombers.

The thing with the MARS is, that one isn┬┤t much of a problem. But five, 10 or even more can create such a dense field of aoe-hits, that you cant pass with fast small units or with slow heavy units. There is no way to end such a bombardment using only ground units. Since I balance the game mainly through playing against RAI┬┤s, the MARS is still far from being satisfyingly balanced. RAI loves to build huge amounts of them to guard the base, making it only possible to to attack early or later with air.

I still hope that i will be able to insert tactical weapons similar to the Ground Control 2 concept one day, which will make it possible to counter such static tactics even while using mainly ground-forces.

thanks for the input Google_Frog :)

Played around with your game a bit :)
Some units look quite good (I like fence/grid thing and the mex animation, rocketbike is cool too.)

I guess eventually all will fall into place, but what really I did not like is the scale/speed/range of units.
Units are quite small, have large ranges and move slow, they also turn slow.
You have nice details (like the support beams of the con truck) but if players have to zoom out to get an overview, they will never see them.
I did not play in MP but I did play Micron Wars which has/had similiar scales. Imo that is problematic because I always want to increase game speed and it does not feel epic but rather sluggish and dull, because it is just about making huge blobs of armies.
To me the combat dynamics of C&C, Starcraft etc just play way more interessting.
Also if you zoom in on a small Spring unit then the ground looks ugly, among other issues. Imo scale like in zK or xta works best.

Also same models do not even use the complete footprint of the unit:

You could upscale the model by 1.5 without change to gameplay.

Another small thing is the teamcolor textures, imo a few big distinct shapes look better than having many fine lines etc across the unit.

fixing the drop-zone build behavior

Is it supposed to work like in Dune:Emporer (and I think GC) where you select some units and then they all get delivered at the same time?

the problem with the scaling is that the fabs get to big. The footprint thing is anoying... 1x1 is too small, 2x2 to big. Admittedly that would be easier with a larger skale.

Maybe i┬┤m too used to the speed/game-play of supcom to see the issue there.

I agree on the teamcolor issue, but i have a hard time choosing big spaces for that on a unit. While I texture, small patches seem better to me. Then later in-game, i think that the icons do the trick for recognizing fast which team the unit belongs.

The Ground Control 2-dropzone thing is on my feature-i-like-to-have-but-pretty-sure-never-will-have-list.

thanks for the feedback knorke :)

easiest way for GC2 drop zone would be to have a factories stores all units it built (either hide under the map or just in an array) and make them appear once the transporter is there.
it might not be excactly like GC2 but something similiar.
also unforeseen consequences are unforeseen.

/edit
yup, seems to be possible like that.

knorke wrote:consequences

will never be the same...



LordMuffe, maybe you don't want exactly the GC2 mechanic, what are you looking for, what does it need to do? I have to write something like what knorke describes but I have not started it yet.

you need this file: http://code.google.com/p/springtutorial ... script.lua
in LuaRules/Gadgets so that Lua unitscripts work.

script:
http://pastebin.com/TS2ZTLQz
(obviously raw version, the unit "flickering" for a second can be fixed, also waypoints etc)
You can "buy" up to 8 units and then the dropship will come and deliver them.
The dropship will also deliver if the build que is empty.

I┬┤m on my way on a important business trip and thanks to you i will have trouble to concentrate and don┬┤t think about that .gif of yours :).

gl with your trip.
It is not really a GC2 dropship system but more a normal factory with fancy animation.
2nd version: http://pastebin.com/wVprJjXs

units in build progress are now invisible & unselectable (but progress bar is still there because that is usefull) and waypoints from factory are copied to unloaded units (like one expects from Spring factories)
If the spaceport is destroyed while the dropship is inflight then it crashes \o/ (the dropship, not spring)
With /cheat /nocost it is possible to make the transporter unload more units than it should per landing. Not sure if that can also be triggered without cheats. (did not manage)
It is still very basic, but I do not know what exactly you want.
ie if you have built 4 units and metal-stall on the fith, it would be possible to make the transporter notice that and deliver the 4 finished units instead of waiting like it currently does blabla

The system I would like to implement would work like this:

Similar to Ground Control 2, the transporter has a specific size of space, say 8 S(pace)U(nits) for example. All units are categorized in 3 size-classes, light ( 1 SU ), medium ( 2 SU ), heavy ( 4 SU).
Instead of delivering one unit per drop, like it is now, you get a set of units, like knorke┬┤s .gif shows.
But you dont order singel units, but units sets. A set would consist of units and be limited by the SU of the Transporter.

So far not much different from IW┬┤s or S44┬┤s squad building.

The clue would be to give the player the possibility to edit or create new unit sets while in the game.

The costs for build units would have to be paid instantly.

The cost of a set could be a base cost ( for the drop flight ) + the unitcosts. That way ordering a full set would make it cheaper per unit while loosing flexibility and maybe time.

I think it would generate some additional depth to the game. Smaller unit sets may be the better way to go while the economy of the player is slow, or if he has not enough storage to even build an expensive set (f.e. ordering and paying one instead of two heavy tanks at once).

Since I like to keep the game macro, the exact same method like used in GC2 is not an option.

I┬┤m perfectly aware that this might be a bad gameplay mechanic , but i haven┬┤t played a game which used such a system on a larger scale and would really like to test it.
Sadly, as stated before, I┬┤m not the great with coding. Haven┬┤t even transfered from bos/cob to .lua for unit-scripts. So its pretty much daydreaming.

I don┬┤t want to ask if someone can program me that, since there is no way of telling if I will ever complete the rest of the game. And I would not feel well with the thought, that someone put hard work into my game and see it wasted.

The emp artillery, a medium sized unit.

Still a wip, but it only misses a few small details and a thorough clean up.
About 1800 tris atm.

I hope to get the tracks animated this time, all attempts ended in failure so far.



With the completion of this unit, I will release a new version with improved sound-effects, transporter behavior and a few refurbished cegs.

nearly finished the unit, just a few things on the texture and a fitting ceg for the weapon.