the infantry is kind of a pain because i dont want to overload the game with many small units for infantry and im trying to figure out how a 'squad' like unit should work properly. orignally we though making a lua script that controls satellite units thru a null unit in the center, but that would only really help control of a squad, the movement of each indivdual unit would still be some waht clogging to system res (move and hit calcs) so i can only assume the next best step is a single unit with many little clones that have a fancy animation in thier script to look not so single unit/ tankish.
Quit worrying about that. Just worry about getting them functional, and think hard about balance. I'd make infantry representational, for performance reasons- use 7-man squads, but give them strength based on platoon rules.
But you don't have to, so long as you're aware that there are no free lunches. I'd honestly have to say... forget the multi-guy-on-one-base ideas... they've been tried with OTA and Spring, multiple times, and always, always, always have cost more CPU time than just using lots of independent actors, and always look like crap. It seems crazy, but it's just how it is.
I have squad code written, and it's well-tested and works. Performance of even up to platoon-sized elements in Spring is not a big deal, so long as you keep piece-count and polycount down... and by the time you're really ready, P.U.R.E. will be out and I will answer questions about how to integrate it into your project. And no, it doesn't require any really fancy COB, weird modeling, etc. Just make your guys as singletons, get them polished, and be patient. It does not do DoW-style stuff, because I found that it simply costs too much CPU, at the typical unit-counts in Spring- a 15-guy squad is unusually large, in DoW- I have a feeling they hit the same wall I did
Other stuff...
Heat management is mainly simple COB.
The only Lua you need is to let people choose priorities on weapons, whether or not to risk destruction, and a heat gauge.
Doing a gauge is probably the most non-trivial part. KDR has some nice code available, as do the CA guys- the Healthbars Widget could be modified pretty easily to do a gauge like that. Basically, it's just a matter of displaying a texrect above the unit, that's scaled / colored based on how hot it is.
As for priorities and controls... that's mainly good ol' COB. You probably have the main systems written already, but meh, here's some code.
You just need a loop changing which heat-management system runs- you could have settings for default, short-range, medium-range, long-range weapons, for example. Then, if in auto-management mode, it simply won't let anything fire if it will exceed a certain heat value, by jamming the weapon script. Then cycle back through after a second, and lower the heat values again. Simple.
The only Lua needed is a control that calls a COB script that changes some static-vars. There isn't any reason to make this more complex than it needs to be.
Here... this is a sketch of a very simple management system, on the weapon end...
Code: Select all
AimWeapon1(heading, pitch)
{
WeaponType = 1;
HeatLevel = 6;
if (WeaponTypeRequested == 0 or WeaponTypeRequested == WeaponType or CurrentHeatLevel + HeatLevel < MaxHeatLevel / 4) {
Aiming Stuff
return (1);
} else { sleep WaitCycle; return (0);}
}
Shot1()
{
CurrentHeatLevel = CurrentHeatLevel + 6; // Do it here to prevent borks
}
And on the user-control end... they just need to have a control loop, called by Lua-->COB, something like this:
Code: Select all
HeatControl()
{
If (ControlNumber > 5) { ControlNumber = 1; }
If (ControlNumber == 1)
{
ControlNumber == 2;
WeaponTypeRequested = 0;
call-script lua_HeatControls(2);
return(0);
}
}
}
And that's just about all there is to it. You just call the HeatControls Lua script, which, based on the argument, changes the text on the button. Every time users hit the button and issue the command, it just runs that COB, which in turn calls a Lua script that changes the label. The real stuff- the actual game-logic- is in COB, where it should be, instead of making life more complicated than it needs to be.
So, all you need now is to learn the Lua for displaying a command button (check out THIS or a bazillion other things) and you need to know how to change the text of a command (again, this is in multiple projects, it's very easy to do). Lua's not the complex part, and I know you know how to write COB, so there ya go- do your gamecode where it needs to be.
You can do amazing stuff with Lua by just keeping it simple, frankly. Look at Lua as a way for users to control the main state loops of your game logic- it doesn't
need to be some incredibly messy piece of automation. Let COB handle all the stuff it already does well- don't make a Lua hack that does something that's trivial in COB, that's just poor design.
This isn't Fibre, after all, it's a pretty straightforward RTS, and the only fuzzy bits are the rules specific to Battletech, almost all of which can be handled more than adequately by COB (critical hits, or even doing a full, accurate armor-point schema, for example, is trivial, if tedious, but meh, it's just one giant include you only have to write once besides some values anyhow- I could write that in my sleep, tbh).
While COB is significantly slower than Lua, so long as you're not doing something foolish like higher math on a per-frame basis, COB is speedy enough for what you want it to do, and is just fine for logic like this. I have lots of COBs in P.U.R.E. that are hundreds of lines long- most of which aren't running most of the time, and just sit there, waiting for the right condition to occur- most often, a Lua instruction from a user command, which may trigger other Lua elsewhere, then circle back again.
but 6 works too) this gives you scout, light attack, anti-air, light assault and fire support. The reason i am suggesting that you stick to light tech, is because it should help keep the gameplay of your first release nice and fluid. Adding hovers as a separate fac (and indeed including them in the first place) makes sense, it should be a conscious descision to use the speed and mobility of BT hover vs its relative lack of armor and high cost compared to wheeled/tracked, plus it will keep maps with water on from turning into gigantic lagfest airbattles
