Insta-build, insta-cost. Gimme AoE/DoW/SC.

[Argh]

Dear LUA people:

I would really, dearly like to have true insta-build, insta-cost (i.e., pay now, get now / no gold, no tanks) economic model as a part of PURE's game design. IOW, like every major RTS ever made, pretty much- AoE, DoW, Warcraft series, Starcraft, Kohan I / II, etc., etc., etc.

I have figured out how to get a Unit to build another Unit within a chosen area, and subtract costs immediately, and check against available M/E. That was a fairly simple addition to the Mine Layer script that I was working on, and I have used it to prototype some stuff already.

However!

To get all the way to my goal is going to require better LUA skills than I currently possess, because:

1. This needs to be hooked in directly to the LUA generating standard UI for Builders and Factories, so that AIs can use this, and players from the world of BA aren't confused. I can't expect people to use an unfamiliar UI for a brand-new game that is still a fairly traditional RTS, in Spring, and expect good results. We have a darn-nice UI already- why make another one? Moreover, an AI that could handle this would have to be customized, which I think is silly- KAI / RAI / AAI should be able to play this game, and I should be able to make a NTAI config, so that newbies have a practice tool out of the box.

2. It needs something better than Echo to send information back to clients (which is what I've got now). I need a UI element that explains that you need X Metal, Y Energy in order to buy this (whatever), and it'd be incredibly cool if it showed the amount you're going to need and updated while it was being shown- an active Tooltip, basically, so that people can know their timing. Again, for AIs, it's going to create problems, I'm sure, because they won't "understand" why they "clicked this button" and did not get the desired Unit / Building, but I'm sure that we can cross that bridge later on.




Do I need this tomorrow? No. Can I finish PURE to Alpha without it? Of course, and in fact it's currently planned around OTA style timing and resources. Do I mind if it's GPL'd? No, I have zero problems with that. PURE already uses GPL'd stuff, and we'll be releasing a lot of the game under various CC or LGPL, minus stuff we're already using that's GPL. I don't want a private script, I want another option for basic game design, and I think many other people would like this, too.

I really need this, to get PURE where it should be, instead of just being a minor variation on an OTA theme here. In the current design, I'm already doing things to very deliberately screw with OTA's exponential growth curves, because I already did that once with NanoBlobs, and we all saw how that worked out But this would give me a lot better overall control over timing and player choices- it'd give players a series of branches, instead of very mushy curves of probability.

If you don't have time to actually do anything towards making this a reality, any hints as to how I'm supposed to hook into the standard UI would be greatly appreciated, because that's the key- I want to continue to have the flexibility to define my Unit list and develop the game balance in the "traditional" Spring fashion, which is super-flexible at this point, and add a config that specifies costs and the Unit to be bought, as I add stuff to the Alpha.

The big issues are hooking into the standard UI, instead of bypassing it, like I did for the Mine Layer, and passing some meaningful feedback to players, i.e., "You don't have enough (resource/s name/s) to build this yet". And then, lastly, the commands have to obey the standard UI stuff- i.e., Repeat, queuing up multiple Units, etc. I doubt if that'll be a major problem.

Again, any information on how to achieve this, or much better yet a working implementation with config, even if missing some of my wanted features, would be very handy. I got the Mine Layer working... and I immediately thought to myself, "well, shoot, it's not very far from this to a true SC economy model". So... I've already set up buildings that are delivered via "airdrops", with cool FX scripts and sound effects and everything, DoW-style... I've got a lot of other things done here, all ready for this model of game design, and I'm quite sure that changing PURE's overall balance to fit it will not be painful.

All I need, for now, is a script that provides the nuts and bolts to make this happen. Please help, I'm buried in animation work and everything else to deliver Alpha here, and if I could get this working before Alpha release, it'd really help PURE differentiate itself as a not-just-another-OTA-game, without the hobbling, non-intuitive features I've currently put into the game design to create some of the same problems via nasty hack-arounds and various tricks. Help me get rid of the need for smoke and mirrors, and deliver the game design I'd actually like here!

[Maelstrom]

Quite easily done really. Just use CommandFallback()/AllowCommand() to check for a build order. If a build order is found, then check for enough resources to purchase this unit. If there is enough resources, then create the unit and deduct resources. If there isnt, cancel the order.

This way, you use normal build buttons. This has many obvious benefits over a straight Lua thing, including AI integration, and is MUCH simpler to make, plus is easily portable to other games/mods.

[Argh]

Hrmm, ok... so, do you know any example scripts I should look at, to see these two callbacks in action? That certainly sounds simple enough, and I agree, it would solve the problem entirely.

[imbaczek]

Tower defense guys have something like this, don't they? Maybe they could share.

[tinnut]

You can do something like:

Code: Select all

function gadget:AllowCommand(unitID, unitDefID, teamID, cmdID, cmdParams, cmdOptions)
	if (cmdID < 0) then
		if Spring.UseTeamResource(teamID, {["metal"] = UnitDefs[-1*cmdID].metalCost, ["energy"] = UnitDefs[-1*cmdID].energyCost}) then
			local unitID = Spring.CreateUnit(UnitDefs[-1*cmdID].name, cmdParams[1], cmdParams[2], cmdParams[3], teamID, 0)
		end
		return false -- we've "used" this command, so remove it from the unit's queue :)
	end
	
	return true -- we didn't use this command
end

This ignores build range.

[imbaczek]

nit: change -1*cmdID to -cmdID

[Argh]

Tinnut, that's awesome! Worked great, right off the bat.

I'm gonna see if I can refine this a little bit, with some simple feedback for the user, and maybe a time-delay (I could read Buildtime, convert to seconds, for Units where I want a several-second time delay regardless of resources, for game-balance purposes) then I'll pass this back to y'all, GPL'd. Thank you very much, this solves almost all of the major problems

[edit] forgot that Gadget code must be GPL'd, oops. At any rate, I will set this free, if I can get it to work.

[Argh]

Whoops! It's giving everything to my team, when the AI uses it! Hmm...

[Argh]

Double oops! It also does not respect BuildDistance. Worse yet, it will build on top of trees.

Hrmm, guess I'd better go grab ye old Minelayer code, eh?

I have no idea how to fix the tree thing... I have a sneaking suspicion it won't test for blocking, either. Hrmm. Anybody know what the blocking callback is? That's a big problem, obviously. I can make Trees get destroyed during Create(), but that's side-stepping the issue with a kludge, and it would effectively turn my Units into weapons :/

[Maelstrom]

I can make something if your willing to have CC-SA work, not GPL work in your mod.

[lurker]

forgot that Gadget code must be GPL'd, oops. At any rate, I will set this free, if I can get it to work.

Really? Why? The close integration?

[Argh]

I am perfectly willing to have CC-SA stuff, and I'm hardcore about crediting anyhow, but my previous understanding was that Gadget code is supposed to be GPL only, due to reliance on other GPL code, based on previous discussions with Quantum. If this is not the case, then my feeling on this is that if you have something that works, great, post it up in public or via PM, include the CC-SA License, and I will test it and integrate it into PURE for game-balance testing and further evaluation. I can't guarantee I'll take it, until I've tested it, but I already know you make stuff that works, so I'm in little doubt it will be perfect for what I need.

Even with what I've got working at the moment, this is clearly not a bad direction for the game design to go in, and I'm rather excited by the prospect of having this work entirely correctly!

I think that the GPL status of Gadget code is really something Trepan should explain, as this pertains to many possible game designs. However, in my case, I don't really care if the License is "loose" or not, as I do not think this is a limiting factor, so long as I do not have to abrogate the Copyrights of other contributors, or put the game in a position where I can't do what I want with it, without breaking the License.

[Maelstrom]

Ok give us a few minutes, Ill see what I can put together.

[Maelstrom]

Hmm, this is being quite difficult...

I tried using AllowCommand, but that presents its own difficulties I didnt think of before, namely the build range issue, plus possible issues with queued orders. So I tried using UnitCreated.

The plan was to check if, when a unit is first started, there is enough resources to buy the unit. If there was, set the unit to full health and send it on its merry way. If not, remove it quietly. Unfortunately, there is no difference in Lua between a unit that was just created via a build order, and one that was .given, or even worse, the units that were created as commanders or spawned through Lua. So, these units also have costs deducted when they are created, and are destroyed if they cant be. Which obviously presents a problem...

So, thinking around the problem, i decide to check the build percent of a unit when its created, to see if its already on full health/build percent when its created, as commanders and .given units are. Turns out they DONT start with full build percent! Lua gets called when they still have 0 build percent, as they do at spawn. After the Lua call their build percent and health get set to 1, so no luck there. aegis suggested in #lua to check a second later to see if the unit has gotten its full health yet. I tried this, and it works.

Kinda.

It worked in the sense that the build percent issue was fixed, but I came across another issue. I was going to check to see if there was enough resources inside this new check I had, and do what ever depending if you could afford the unit. If you could afford the unit, then set it to full health and send it on its merry way again. If not, kill it. I got it all working, except for one minor problem...

Spring crashes.

Go here for details:
http://spring.clan-sy.com/mantis/view.php?id=624

[trepan]

Already have a patch started to fix that crash, and a number of other ones

[Maelstrom]

Already have a patch started to fix that crash, and a number of other ones

Yay for trepan

[smoth]

the code has to be gpled if it is based on gpl code... ie if you use a gpled script you have to gpl your modifications... I think.. this is why I hate gpl... stupid virus license.

[KDR_11k]

I don't think it's all that inappropriate for lua scripts though, after all the GPL only means they can take the scripts from your released mods, it doesn't mean anything else for you (e.g. there's no requirement to release test versions to the public if you're concerned about that). People would take these scripts anyway.

[smoth]

correct, why do we even bother with GPL, as long as we are not say.. oh copyrighting the shit who cares?

[imbaczek]

Don't worry about GPL. The only place you need to be afraid of it is when you're including (requiring, loading, whatever) a GPL'd script into your own and wanting your own to be under a different license. As long as you only put a self-contained GPL script in your mod, you're safe.