Spring RTS Engine

video:
http://www.youtube.com/watch?v=TMZU7T7OMCM

download:
http://www.file-upload.net/index.php?to ... c78cde86ff
NOT AN OFFICIAL DOWNLOAD, TEST VERSION

how to test:
1) cheat/build some minerals (bminerals), give them to enemy or gaia.
2) cheat/build one or more deployed flagship (bflagshipbase) that serve as dropoff centers
3) cheat/build some miners (bminers) and rightclick them on the minerals.
if the distance to the minerals is too large, miners will not return to mine. blabla its beta hmkay...

compared to the version Sanada gave me in chat, I changed some things:
-decreased miners gun range to be alot shorter
-decreased minerals health so mining is faster


missing/needed:
-obey teams when returning to dropoffs etc
-mineral/spacerock units
-if miners have no LOS to the minerals, they get lost
-go to another dropoff center if the current target dies while returning
-change to gradual mining ala starcraft (one mineral can be mined numerous times before it runs out)
-not sure how this really plays, how often miners get stuck etc. -miners might need faster speed+turnrate etc.
-at gamestart, spawn some rocks in various locations or drop the from the sky or grow them out of the earth etc

finally <3

this gives totally new possibilities when creating games.

PLZ DONT STOP

PS- uh, question, is it possible to replace minerals/crystals etc. with building ?

PS- uh, question, is it possible to replace minerals/crystals etc. with building ?

what do you mean? instead of collecting minerals, have the miner goto into a vespine gas refinery or goldmine?
with this: no, as i used the destruction of the mined crystal as signal that mining has finished.
with changes: yes

do you want this or would it just be nice to have just in case?
because i would rather get the basic thing working instead of adding all kind of extra things

i could use both in, more or less distant, future. but ye, better make basic mechanism working and then think about extras :)

added:
-gradual mining (like in starcraft) instead of mining the whole mineral at once. "minerals health" = remaining ressources
-multiple units can be defined as ressource dropoff. Deployed metalstorage trucks and landed flagships make a cool combination.
-miners do not try to drop ressources at enemy dropoffs anymore
-only mark allied miners/dropoffs
-no more endless ressource by repairing partly mined minerals
( repairable = false in bminerals.lua)

changing:
-i will probally change recognizing dropoffs, miners, ressources. So that it is done by a custom tag in their UnitDef thing instead of by unitname.
-same with the cargo, units need a cargo tag instead of this table thing. maybe this way units can read the tag and if cargo > 0 show the unit carrying a mineral piece
---------

maps can contain lua too, right?
I would suggest that maps use lua to place ressources via CreateUnit because it is more flexible than features on a map.

I did a hackish example by putting the mineralplacement thing into game_spawn.lua but it could look like this:

Maps lua contains
result:


The SpawnRessourceField function: That only gives some basic mineral patches. But one could also do something like...
-randomly place minerals on high/low terrain (this way i made rings of minerals around the hills)
-only place on grass terrain
-place minerals near water
-mapoption in lobby for different settings: ressources at startpoint or more in the center?
-adjust ressources to player count

if a non-ct map is played, that does not contain such lua one could place ressources based on metal like S44 does with flags.

blabla...cool i rambled one a half screen full. lol what do you even want the gameplay/ressource system to be?

what is the advantage of using a weapon to shoot at the resource to gather it, instead of using the reclaim system (plus Lua magic)?

because i like guns

when using reclaim, the ressources are instantly added. i would have to stop that somehow. so basically, it was easier this way.

hmm err quick, think of some advantages!
-give the mining weapon splashdamage and mine multiple ressource things at once.
-reclaiming always creates nano particles. maybe you only want nano for building but a different effect for mining
-by changing the reloadtime etc of the mining weapon, you can easily have miners that do like mine...pause...mine....pause...mine
-when completly mined out/destroyed units can explode with their death animation. when reclaimed they just disappear.

knorke wrote: with this: no, as i used the destruction of the mined crystal as signal that mining has finished.
with changes: yes

knorke wrote: added:
-gradual mining (like in starcraft) instead of mining the whole mineral at once. "minerals health" = remaining ressources

So these changes have been made already, if i understand correctly?

And i was wondering, would it involve mayor changes if the crystals were to be be 'picked up', and remain visible? In witch case the miners would be transporters, and maybe the drop off point could be a circular area (in proximity of building) in witch the minerals would be doped off and reclaimed in some way.
Or would that be a whole other story?

So these changes have been made already, if i understand correctly?

yes, was easier than i originally thought. (unitdestroyed <-> unitdamaged)

And i was wondering, would it involve mayor changes if the crystals were to be be 'picked up', and remain visible? In witch case the miners would be transporters, and maybe the drop off point could be a circular area (in proximity of building) in witch the minerals would be doped off and reclaimed in some way.
Or would that be a whole other story?

How about a railroad transport system while we are at it? Zepplins could pull the waggons!
Actually your idea is possible but isnt it gameplay wise quite similiar?

Quite similar, yes.
but not exactly:

-It would allow for visual representation of transported cargo/resources.
-The mining ability would become less unit specific.
personally i think it cool game play if a crystal mineral can be destroyed by any unit witch can damage it.
The cristal shards formed in the death explosion would be resource, and can be 'harvested' by any transporter.

It might be a minor difference, but I think that's how I would do it, if I were able to.

And i was wondering, would it involve mayor changes if the crystals were to be be 'picked up', and remain visible? In witch case the miners would be transporters, and maybe the drop off point could be a circular area (in proximity of building) in witch the minerals would be doped off and reclaimed in some way.
Or would that be a whole other story?

Don't make the miners transports, I think this would cause a lot of headaches with target acquisition. Instead use the current system and simply add minerals to the unit model which can be hidden or shown when required. When the minerals are dropped near the base for the base to reclaim spawn a separate unit that only the base can act on.

I just saw the latest post and my technicalities of the implementation still stand. If you want any unit to destroy minerals but only specific ones to collect them it could still be simpler to implement many mineral units than to fight with Spring transportation code.

-It would allow for visual representation of transported cargo/resources.

can be done by hide/showing pieces in the unit script.
like this: (the yellow/red groundshape around the miners is just stand-in)

personally i think it cool game play if a crystal mineral can be destroyed by any unit witch can damage it.

already possible, just a matter of how the mod sets up armor, weapons and target categories.

The only way I see how this would be different gameplay wise, if you it works similiar to the relics in age of empires: few relices on map, monks carry them into the church. relics in church generate income.

oh Google_Frog said it already too

Insteaad of SpawnRessourceField (x_center, z_center, number, half_side_of_square)

I'd rather have:

SpawnRessourceQuad(x1,z1,x2,z2,density)

local x1,z1,x2,z2=math.min(x1,x2),math.min(z1,z2),math.max(x1,x2),math.max(z1,z2)
for k=(x2-x1)*(z2-z1)*density/1024, 0, -1 do
local x = math.random(x1,x2)
local z = math.random(z1,z2)
local y = Spring.GetGroundHeight(x, z)
local res = Spring.CreateUnit(ressource_name, x, y, z, math.rand(0,3), Spring.GetGaiaTeamID())
Spring.GiveOrderToUnit(res, CMD.ONOFF, { 0 }, {} )
Spring.SetUnitAlwaysVisible(res, true)
end
end
-- Or write a version with regularly placed minerals.


SpawnRessourceDisk(x,z,radius,density)

for k=math.pi*radius^2*density/1024, 0, -1 do
local a = math.random()*2*math.pi
local r = math.random()*radius
local xc = x+r*math.cos(a)
local zc = z+r*math.sin(a)
local yc = Spring.GetGroundHeight(xc, zc)
local res = Spring.CreateUnit(ressource_name, xc, yc, zc, math.rand(0,3), Spring.GetGaiaTeamID())
Spring.GiveOrderToUnit(res, CMD.ONOFF, { 0 }, {} )
Spring.SetUnitAlwaysVisible(res, true)
end
end
-- This end up with mineral more concentrated in the center.
-- Or write a version with regularly placed minerals.



Also, can't mineral be features instead of live units?

Edit: added random facing

Don't get me wrong.
I'm not asking for anything and I'm very impressed (and happy if i learn how to implement it myself) with this gadget.

But the solution proposed become more complicated if a game has 10, or more realistic 5 resource types, that can be carried by the same miner-unit.
Making a cargo bay look good would be very complicated.

More importantly I realise now that, although i had not mentioned it before, i was thinking about multiple resource types. And i suppose my question has become somewhat invalid because i imagine multiple resources might raise some other problems i havn't thought of yet.

zwzsg wrote:stuff about spawning minerals

yes, cool. stuff like that i imagined.
Problem with the density approach is, it will be harder to see how much metal will actually be placed. (must do area*density instead of just seeing "thats a field of 20 blocks")
guess both have its use.

zwzsg wrote:Also, can't mineral be features instead of live units?

maybe. i just did not have a map/mod with attackable features to test. Might use less cpu or why do you ask? ~100 mineral blocks do not slow it down noticeable.
With units you could even have moving ressources like animals.

FireStorm_ wrote:if a game has 10, or more realistic 5 resource types, that can be carried by the same miner-unit.

yes more possibilities is nice and everything but there must be a point where it stops. :) Next someone wants multiple miners carry one big mineral together or something. Also what use are features if nobody uses them, like i added stuff to demonaut/knorkebot and never got feedback so yeah. Now I only try to make stuff that I can see being used in a realastic time frame. And it seems CT only needs one type of carryable ressource (?) so thats it for now. Still appreciate your feedback of course!

Making a cargo bay look good would be very complicated.

instead of hide/show pieces one could use the opengl function stuff to draw the ressource that is being carried.
like
DrawUnit (the ressourceThatsCarried at the position of the claw)

Last time I tried, shockingly, covering a map with features ate way more FPS than covering the map with units.

I'm just asking because somehow it seems more coherent for minerals to be feature, reguarding how .smf and mapconv can add features but not live units (yes I know, those are deprecated and featureplacer is all the rage now), reguarding on how we are used to have trees and rocks and geo be features and not live units.

I understand your point about autoattacking units and not features, but, mining should use a custom command anyway, and wouldn't it cause more troubles if assault tanks passing by fired on mineral fields?

wouldn't it cause more troubles if assault tanks passing by fired on mineral fields?

i think that can be avoided with notarget etc in the weapons def? similiar to how only flak can shot airplanes only miners can "shot" the minerals.

mining should use a custom command anyway

eventually yes. but this is just the second spring project i am doing and the demonaut thing was basically
SomeCallin:
WriteFile (getunitname, getunithealth, getunitweapons,...)

Well let me try to explain how we wanted resource collection. Meteors would fall from the sky in waves damaging crap on impact. Units would go out and collect the falling meteors and return them to a drop off building for metal income.

Knorke has clearly made huge strides in making the latter part happen. The first part was supposed to happen with this:
http://code.google.com/p/conflictterra/wiki/SpaceRocks

It currently spawns death features if i remember right. Which means it's not really compatible with knorke's work. It does not do waves nor can i control different types of rocks. Like for instance larger higher density (worth more metal) or smaller rocks that are worth less and do less damage on impact. I did not write this, Quantum did. I can barely put together a unitdef. So help and opinions are wanted.

Yes, but for *every* armed unit that is not a miner you need to give it an only target category which excludes minerals (Not always a trivial thing to do!)

small notes

remember that mining units might get killed, what with crystals they were transporting ?

also, another extra, make it work for trees :D