Spring RTS Engine

Google_Frog wrote:Dragon egg flies around because current mass equation is mass = cost/2. This has a few problems. Skuttle is heavier than Can, Reaper is lighter than Merl. If you can think up a good equation that uses hp and cost to get mass go ahead.

What about "mass = (HP/3 + cost) /4". That way mass and cost would be around equally important in determining the mass, what is good to prevent heavy but fragile units from being too light while preventing light but expensive units from being too heavy.

MidKnight wrote:how about ((cost + (hp/3)) /3 )/2
?

I think that dividing everthing for 4 rather than 6 will get it closer to the current weights. (Except for the wronged units that are supposed to get fixed that is)

why the hell the cost of a unit should have anything to do with it's mass ?

just use collision mesh's volume = mass ...

EDIT: if you want to add some redundancy divide the volume by the unit's acceleration constant

The cost is directly proportional to the amount of metal resources poured into the unit. (Since metal and energy are Spring's only two resources) It is not completely irrational to include cost as part of a units mass.

However, I do like the idea of also including the mesh volume, but depending on how heavily armored the unit is, the density of the armor would affect the mass greatly, so size wouldn't necessarily be the best fit for the mass, unless you also factor in the armor/health.

After a certain extent the mass of the units doesn't really matter because they all act like little rubber bouncy balls anyway.

maackey wrote:The cost is directly proportional to the amount of metal resources poured into the unit. (Since metal and energy are Spring's only two resources) It is not completely irrational to include cost as part of a units mass.

Except that the tiny roach costs more than many bots even though it's the size of one of their feet.

If metal cost was directly proportional to mass then mass is directly proportional to usefulness of the unit. Which is ridiculous.

Metal use = mass is a realism argument, and besides, obviously cost and mass being equivalent would be silly, viewed in modern day perspective - jet fighters that "cost" the same as a tank weigh much much less. Perhaps the "metal" used in some units is Beryllium, while in other units is depleted uranium, and is measured by unit volume?

While it's a good baseline to start from, including a custom "mass multiplier" tag for units where mass is obviously silly would be a good idea.

Pxtl wrote:While it's a good baseline to start from, including a custom "mass multiplier" tag for units where mass is obviously silly would be a good idea.

There is already a tag for mass. The mass equation will be used in CAedit to normalize all unit masses. The reason we're starting to look at mass is it's become important for balance. With cores new grav rays, leveler/outlaw shots and the impulse increase for gauss strange masses are becoming more visible.

We're not setting it manually because noone wants to manually set 200 unit masses and an equation will be consistent.

the way CA is devved you can just change them slowly over time and add some interesting choices to mass values for certain units...Something which is impossible with an equation..

Gota wrote:the way CA is devved you can just change them slowly over time and add some interesting choices to mass values for certain units...Something which is impossible with an equation..

An equation as a basis can help a lot thought.

I think and equation involving unit size, hp and speed would give out good results winhout being very complicated. Something like:
"mass = (((Size * x) * HP) / speed) * y"
Where x is a number to scale size so its importance is on the correct proportion with hp, as I dont know how size calculation works.
Where y is a number to scale the whole result to values similar to the current ones, so that it is not necessary to recalibrate all the weapons.

Better unit guide: http://trac.caspring.org/wiki/UnitGuide

Now has every unit and structure in the game.

CarRepairer wrote:Better unit guide: http://trac.caspring.org/wiki/UnitGuide

Now has every unit and structure in the game.

Well, not really, since some units are lacking their description, and some of those units are some of the most obscure ones. I think the most screaming examples are the meteor controller and the arm... laser of doom? :)

Also, the Tarantula is lacking its picture for some reason.

The unit guide gets generated from the game files so changes you make to it will be overwritten. But if you'd love to help, please make a translation of the unit descriptions in Brazilian Portuguese so that we can one day include it in our interface. See how bebert made a new page for the French unit guide (which needs updating).

I'm aware of how CA handles mass. I suggested a mass multiplier as a way to work with your equation without simply overriding it.

But yeah, thinking it over, keeping track of the exceptions would be too much of a pain. If the hitsphere can be accessed at def time, then volume of hitsphere could be something to incorporate. If not, then height * footprint could give you a volume metric.

The problem is that logically, the units that are massive should be the units that _look_ massive. A big slow hulking brute, even if it's cheap should weigh more than a quick, small, nimble, but expensive unit.

Making an equation that reflects this, but handles the boundary conditions, is going to be tricky.

CarRepairer wrote:The unit guide gets generated from the game files so changes you make to it will be overwritten. But if you'd love to help, please make a translation of the unit descriptions in Brazilian Portuguese so that we can one day include it in our interface. See how bebert made a new page for the French unit guide (which needs updating).

That would be a good idea, except for 3 facts:

1. Most brazilians dont like strategy games
2. Most brazilians dont read manuals
3. Pretty much ever brazilian who likes strategy games and reads manuals will also know how to read english

But, off course, there are other countries that speak portuguese and I suppose they would understand brazilian portuguese :) Someone give me an e-mail I can send the translations to.

manored wrote:

CarRepairer wrote:The unit guide gets generated from the game files so changes you make to it will be overwritten. But if you'd love to help, please make a translation of the unit descriptions in Brazilian Portuguese so that we can one day include it in our interface. See how bebert made a new page for the French unit guide (which needs updating).

That would be a good idea, except for 3 facts:

1. Most brazilians dont like strategy games
2. Most brazilians dont read manuals
3. Pretty much ever brazilian who likes strategy games and reads manuals will also know how to read english

But, off course, there are other countries that speak portuguese and I suppose they would understand brazilian portuguese :) Someone give me an e-mail I can send the translations to.

It would still be cool.

No need to email, just post it on trac like bebert did.

http://trac.caspring.org/wiki/Manual#UnitGuide

CarRepairer wrote:

manored wrote:

CarRepairer wrote:The unit guide gets generated from the game files so changes you make to it will be overwritten. But if you'd love to help, please make a translation of the unit descriptions in Brazilian Portuguese so that we can one day include it in our interface. See how bebert made a new page for the French unit guide (which needs updating).

That would be a good idea, except for 3 facts:

1. Most brazilians dont like strategy games
2. Most brazilians dont read manuals
3. Pretty much ever brazilian who likes strategy games and reads manuals will also know how to read english

But, off course, there are other countries that speak portuguese and I suppose they would understand brazilian portuguese :) Someone give me an e-mail I can send the translations to.

It would still be cool.

No need to email, just post it on trac like bebert did.

http://trac.caspring.org/wiki/Manual#UnitGuide

You mean make an equal page, make a lead to it there and then translate all the text? Good idea :)

By the way, he forgot to translate the faction descriptions.

Well the unit guide changed a lot after he made it so it needs a lot of updates.

I'm glad you'll do it. We can learn some Portuguese that way. So far I know one word: lua = moon.

Not all translations will be literal thought, because some english terms and expressions have no perfect translation to portuguese. For example the best portuguese translation for the word "raider" is "saqueador", but saqueador means something more along the lines off "someone who attacks, steals what he can and gets away" than "someone who attacks, destroys what he can and gets away". So I will probally have to use some other word there :)

That word is correct.

That is exactly why we'd need human translators rather than go with google language tools, which was our second option.

CarRepairer wrote:That is exactly why we'd need human translators rather than go with google language tools, which was our second option.

to further this point, try going to any online translator, and trying to get the spanish equivalent of "annoy." see what happens

Cost should in most circumstances be indicated by the size of the unit anyway. Mechs are huge, fleas are tiny. Although Google makes a good point that these are balance factors and a few exceptions (roach) are perhaps warranted (though, imo, it wouldnt hurt the roach to be larger).

In most cases cost = mass is fine, the reason the dragons egg flies around so much is because it has a huge amount of HP when closed. This means its not taking much damage when its hit be a weapon, but still taking the full impulse.

The major problem with impulse is map gravity effecting its usefulness, not so much on special weapons like grav guns (though they are crazy on comet) but on everyday weapons for which impulse is a major component of their effectiveness (levelers).