Unit Level system (think Warcraft Heroes)

[SeanHeron]

Hey all,
I'm working on a Game where "leveling up" is a key element of gameplay ( http://sourceforge.net/projects/enginesofwar/ ). I've come to find that implementing this is not as trivial as I expected though :/.

Therefore, I wanted to ask whether anyone else has given something similar a go ? - that I have obviously missed, else I'd have just looked at their/your code :D. That would, of course be a great convenience to me!

Otherwise, below is a description of what I have so far, and what is to me the stumbling block:

I have a rudimentary XP system in place, and making Calls/changes when a higher level is reached is not a problem. What really hurts is making stat changes - there's a few there are SyncedCrtl commands for (eg maxDamage...) - but I'd kinda glossed over that anything beyond that is not easily accesible - ie MaxVelocity, turnrate, idleheal (I may be mistaken, of course). I realize all these are (probably) "fudgable" with appropriate Lua code - but I was hoping not to have to take more and more into my own hands.

I guess the path I might (be forced to) take is using morph.lua and try to rig that up for smooth transitions (which means one "unit" for every level with different stats - not really what I want...).

But, like I said, if anyone has done something like this, please give me a shout!

Edit:
P.S. If there's a simple way to shutdown the Engines experience system (that I've missed) that would be nice :) .

[imbaczek]

but I'd kinda glossed over that anything beyond that is not easily accesible - ie MaxVelocity, turnrate, idleheal (I may be mistaken, of course). I realize all these are (probably) "fudgable" with appropriate Lua code - but I was hoping not to have to take more and more into my own hands.

movetype-related parameters will be (mostly) lua-accessible in the next version, relevant code is in master. check movectrl wiki and/or commit messages for more details.

[JohannesH]

Isnt comm morphing in XTA pretty similar? Just remove the m/e/bt costs and get xp requirements only.

[zwzsg]

Which means one "unit" for every level with different stats - not really what I want...

You can generate units with code. They still have to be all defined before the game start, but it is less painful to maintains a couple "for" loops than a hoard of .FBI. (Or whatever .lua is used for units definition nowadays). Oh, and weapons stats can be generate by "for" loop in code as well. Just remember that weapons are linked to units with an intermediary weapon thing, that implements things such as limited firearcs and target preference, and point to the actual weapon stat sheet. Check Kernel Panic \gamedata\ to see how I generate Heroes and their weapons with Lua code instead of static stat sheets.


However, you probably want the player to be able to choose which skill to raise. And even with a limited skill tree, the number of possiblity can quickly spin out of control. For instance, five skills, ten levels per skills, would already be 100 000 possibilities, and I don't think Spring would like 100 000 unit types. TA had less than 512, even after adding all Cavedog add-ons units and one of the hugest third party mod.

So you need to limit generating new unit types to one or two attributes that really can't be changed otherwise, and do the rest without the need to create new unit types.


Max speed can easily be changed by .bos/.cob (and .lua)

Max health can easily be changed as well.

Switching units ON and OFF switch radar and other stuff.

Cloak can be controlled by .bos/.cob (and .lua), remove the cloack button and use set WANT_CLOAK to TRUE/FALSE;

Units can sport something like 16 weapons. Give all units all weapons, and use .bos/.cob (or .lua anim) to block every weapons but one. But use that only for weapons that are really different, like insta laser vs ballistic plasma balls. Weapons that are just different power level of the same weapons should be the same weapon.

The damage a weapon deal can be tweaked with gadget:UnitDamaged (Not sure what UnitPreDamagedis for).

The gadget:Explosion call-in can be used to give weapons some special effects at the weapon point of impact: Like KP's NX flag. But you could also do much more than DOT with it.

Artificially restricting the range of a weapon (so you heroes can buy weapon range upgrade) is doable in a variety of way. Though the engine would have trouble knowing how close to go to be in range. Anyway, you'd already lost that by having every unit sports every 16 weapons.

Then you could implement tons of things with pure lua (or pure bos/cob), disregarding the hard coded way of storing unit and weapons properties. For instance, nothing prevents you from having a custom button triggering a custom action making the unit shoot a custom Lua OpenGL colored beam that deal damage to units, without using any weapon. Recoding a custom projectile system in Lua would take some work, but less than you'd think. Heck, I've done it within TA .bos/.cob limitation.

[SeanHeron]

Well! I'm definitely more than set up to continue now :).

Thanks imbaczek for the heads up on the movetype stuff - that just what I'm looking for on that side of things!

Johannes - that was kinda my fallback option.

Zwzsg - the call on using "for" loops is a very good one! I can't quite think through how it'll work, but I'm sure that will change when I check the code you're referring to.

And yeah - you've caught on to the big problem, wanting to give players full freedom of choice - without me going crazy keeping track of all the combinations that means...

I think with the movetype things accesable, that probably actually covers most of my worries - besides weapons, which you've done a very nice job of laying out how best to address!
I reckoned multiple weapons, and blocking those not "available" was the way to go - range finding problems don't really come into play, since the plan is to have keyboard steering of your "Engine of War", similiar to in Mech Combat, or Heroes of Mainframe :).
I didn't realise you could change the damage, reloadtime, etc. of weapons within it, though - that helps a lot!

I must admit I'm reluctant to place stuff inside units scripts - I was hoping to keep this as modular/reusable as possible, and a set of gadgets would seem far simpler to copy-paste than stuff that is "hidden" within a units animition files. But I'll certainly not shy from it where necessary .

Anyways, thanks again for all the info - I can now pick and choose a path forwards :D.

Edit: And yeah, I intend to have damage abilities which are lua only - Artillery or Airstikes, etc.

[Argh]

UnitPreDamaged() is, imo, the preferred way to implement special damages. It catches it before the damage is actually applied, and is cleaner / faster.

[MidKnight]

Erm, I didn't really understand the OP, I hope this helps.

I made a gadget that slows units down. The code could very easily be adapted to speed them up.

The original code is here: http://trac.caspring.org/browser/trunk/ ... meslow.lua
but beware: this is from my uber-noob days, and is riddled with confusing/scary code.

CarRepairer made a much nicer version that's used in The Cursed. If you want to look at that, it's available in the Cursed modarchive.

If you're too lazy to look at the code:

Code: Select all

local MAX_SPEED = 75
...
SetUnitCOBValue(unitID, MAX_SPEED, newSpeed)

[SeanHeron]

Argh, for me changing the weapon values the way Zwzsg described (ie from within the weapon code) is the slicker way to do weapon "upgrades" - but the function you described may come in handy anyways, thanks :)!

Midknight, you seem to have caught the overall drift, at least . I guess I was a bit short on what I'm aiming to set up - maybe I'll expand a bit on that later.
Your code seems to do one of the things I wanted to - but if I read the MoveCtrl wiki section (that Imbazcek pointed me at) right, that'll be an even smoother way to do things :). Thanks anyway though!

Edit: This should give some context to the Level-up system: Engines of War (announcing)

2nd edit: Just stumbled upon modrules.lua, which lets you set the Experience multiplier (ie to 0 ). Any documentation on this wonderful tool ?

[Erik]

I would highly like something like that because i have a similar plan. Upgrades that are either dependant on unit experience or a global upgrade(per player) would be very cool.
These should allow changes to stats, weapons, model and script.
I wanna use this aswell for a game
If needed i might help out a bit with my C++ knowledge.

[Argh]

Why would you want to set up lots of weaponDef variants, when you can just handle most of the behavior via a Lua damage system?

For something with DoTA-like gameplay, you need to implement something very like a resistance / elemental system (whatever you call it- if it's sci-fi, maybe it's "lasers / ion / plasma / impact"), and you simply can't do that by having bazillions of weaponDefs; that would get absurd in a real hurry.

Just handle actual damage via Lua, store the weapon's current stats via some GG array, and modify it as needed. Bought weapon damage +10? Increment GG.heroWeapons[myTeam].baseWeaponDamage +10, for example. Much, much, much cleaner. So, if you have a Laser Sword, it's category is Laser, it's a Cleave-type damage, it has this damage range, etc.

For examples of buyable upgrades... meh, look at THIS, and P.U.R.E. has several things like that. Basically it's just a Command- in your case, it'd be a Command that was contextually tied to the currently-active Weapon, so if you upgrade the Sword of Pwnage, the other weapons aren't also upgraded (or are, ofc- the choice is whatever you think is fun).

But basically, the weapons are just some base behaviors the Unit can follow- their gameplay after you start upgrading depends on the upgrades you choose. Maybe some weapons can buy some things, but not others- a "plasma grenade" might be really awesome during early play, but while you can upgrade the AOE, it doesn't get better, damage-wise, so it eventually is just crowd-control for weak mobs.

Lastly, I am pretty sure you will see CAI problems, if you don't keep the range of Weapon1 the same as the active weapon, because the aiming / movement behaviors will tend to bork if you jam it and the 'real' weapon you're supposed to be using is not in range yet.

[CarRepairer]

Artificially restricting the range of a weapon (so you heroes can buy weapon range upgrade) is doable in a variety of way. Though the engine would have trouble knowing how close to go to be in range. Anyway, you'd already lost that by having every unit sports every 16 weapons.

Spring looks at the first weapon for range. For changing range, the solution I use in my game (CAK) is to have the first weapon simply be a fake weapon and never fire. I modify its range based on the other weapon(s) changing range. A few gotchas:

1) A unit that has no weapon now but might have a weapon later. Without a weapon it will still chase other units.

2) Similar to #1, different weapon types means you sometimes want the unit to chase certain units and sometimes not, and you can only set that in the nochasecategory in the unitdef. Your unit may not start out with a weapon that's anti-air but later acquire it.

I don't have a verified solution for these yet, just some vague ideas (for #1, maybe I could give the weapon a huge range but that's not perfect).

[Pxtl]

@Car - how much does Spring try to get into firing position? Wouldn't that cause trouble if the dummy weapon LOS but the actual weapon was some kind of high-traj weapon?

[zwzsg]

Not much a problem considering the heroes are microed by the player: You can only control one single unit in DOTA-like. Even less a problem considering:

range finding problems don't really come into play, since the plan is to have keyboard steering

[CarRepairer]

@Car - how much does Spring try to get into firing position? Wouldn't that cause trouble if the dummy weapon LOS but the actual weapon was some kind of high-traj weapon?

Yes that's an extension of the problem where the fake weapon is too different from the real weapon. Unfortunately the thing to do is to try to match them up as close as possible and design the unit as such. I am not using any arty weapons in this way so that's not an issue for me. The anti-air thing is however. I welcome discussion and suggestions on this topic in hopes that it helps me and SeanHeron should he need it as well.

[SeanHeron]

I've made a little headway - and I now think I can set up a system that can do most of what I want :D. It's wait and see though...

A question that's come up to me - more often than not, I'm calling a UnitID - and as "Heroes" respawn, those change. Now getting the right UnitID is not really a problem. However I'm often using the players TeamID to help me grab it - which obviously only works if you only have one "Hero" a team.

Now I have no plans whatsoever of changing the "one player one hero" concept - but for the sake of reusability I was wondering
1) what might be a neat way of keeping track of "Heroes" over their deaths - I guess really, this would have to be solved in conjunction with their spawner - (how) might I implement a placeholder globalvar ? Or would it be easier to try to keep the spawner pretty general, and implement a "Hero" tracking var there...

2) Is anybody actually interested in this? Having multiple - variable path upgradeable units interesting to anyone? Hmm, I think I remember a CA contributor saying yes maybe...

OK - there's not going to be a generalised version any time soon, but gadgets to showcase might be ready soonish.

@Argh - I'm sorry - I thought I'd thanked you for your considerations already,else I would have replied earlier. They were quite interesting to read, thanks!
And indeed, it might be easier to go down the route you described after all. Not sure yet though (there won't be much/any "items" in the earlier versions of the Game).

@CarRepairer - the trick with using the first weapon as a dummy "rangefinder" is a neat one :) ! Wouldn't have thought of that myself soon. As Zwzsg pointed out though, that's not likely to be a problem for us (if things work and stay as planned that is). I'm afraid I can't help you on the category problem - you might be better of starting a new thread on that, seeing that people are not exacly going to look with that in mind .

Edit: After some more play, I've found that the range problem you described, CarRepairer, very much is one after all! Disregarding the movement into range issue (which as said isn't one for us), a unit won't actually target (as in shoot at) a enemy it's given an attack order too, until it's within it's primary weapon range... This I had not realised. So thanks again for the solution - I'll be taking that up. And I'll look into your as yet unsolved problems when I don't use the time for other stuff .