Resources abstraction

[hoijui]

Idea:
instead of the engine beeing fixated on energy & metal, we would have a dynamic set of resources.
This concept is already visible in the C AI interface, and in:

Code: Select all

rts/Misc/Resource(.h|.cpp)
rts/Misc/ResourceHandler(.h|.cpp)

A similar concept is used for resources as is used for unitDefs, weaponDefs and featureDefs. Each resource has an id, eg metal:0, energy:1, ...

for taking it further, the rest of the engine, and (later) the Lua interface would adopt the principles the C AI interface uses already. To clarify, a fe examples:

now:

Code: Select all

struct UnitDef
{
	float metalUpkeep;
	float energyUpkeep;
	float metalMake;
	float makesMetal;
	float energyMake;
};

class CUnit
{
	bool UseMetal(float metal);
	void AddMetal(float metal, bool handicap = true);
	bool UseEnergy(float energy);
	void AddEnergy(float energy, bool handicap = true);
};

after:

Code: Select all

struct UnitDef
{
	std::vector<float> resourceUpkeep;
	std::vector<float> makesResource;
	std::vector<float> resourceMake;
};

class CUnit
{
	bool UseResource(int resourceId, float metal);
	void AddResource(int resourceId, float metal, bool handicap = true);
};

if there are no complaints, i will start a new branch for this.

[imbaczek]

problems:

- resourceMake and makesResource are confusing (they already are in makesMetal/metalMake case)
- need a way to tie makesResource to another resource for consumption/production, perhaps with a triple (int idxConsume, int idxProduce, float ratio)

otherwise +1.


edit: also, do you plan to support multiple resource maps?

[hoijui]

- resourceMake and makesResource are confusing (they already are in makesMetal/metalMake case)
- need a way to tie makesResource to another resource for consumption/production, perhaps with a triple (int idxConsume, int idxProduce, float ratio)

good point, i'll consider that.

edit: also, do you plan to support multiple resource maps?

i would say yes...
thing is, i will do it pretty much automatically. the AI interface already supports multiple resource maps. I will not dig into the map formats too deep, except it would be obvious to me how to do that, but engine wise there will be support for multiple reousrce maps, yes.
for simplicity, all resources are bound to be float, i guess that is acceptable, right?

[Argh]

This would be great, if finally implemented. However, how are you going to abstract the various costs?

So many things currently have costs (usually Energy) that really need to be made generic for this to reach its full potential.

[imbaczek]

probably the tag will be resource1cost, resource2cost, etc. with metal/energy being aliased to resource1/resource2, if that's what you're worried about.

[Argh]

It's more that I'd like to see stuff like shieldPowerRegenEnergy= become shieldPowerRegenCost:Resource2= or something of the sort. There are a (few) things that are like that, with specific, hard-coded formulas for cost, etc. and no current flexibility, and if it's going to be extended then I'd really like to see that included.

Otherwise we'll see those things end up with a "reserved resource" just for them, etc., and more confusion for newbies trying to make a game for the engine.

As a more radical alternative... perhaps it's time to allow game designers to remove resources from the engine side's control completely and just do it all with Lua gamecode, without the hidden cost of running superfluous C++ code all the time.

[hoijui]

if we have abstraction, we can thing about the other things, they will be trivial then, as in: chaning small parts of 3 engine source files, instead of 300.

when i will be working on parts that interact with the outter world, like Lua interface or the parts of the engine that handle unit scripts/definitions or whatever, and things are not clear, i will come back here and ask for advice.
most likely, i will start converting all the purely engine internal stuff.

[imbaczek]

side performance note: superfluous C++ is still much cheaper than almost any Lua.

[Argh]

Really? When it's running over hundreds of Units, and the Lua could run on hardly any at all? Seems counter-intuitive to me, I didn't think the total speed advantage was that huge.

[jK]

probably the tag will be resource1cost, resource2cost, etc. with metal/energy being aliased to resource1/resource2, if that's what you're worried about.

different idea:

Code: Select all

local wood = 1
local metal = 2
local gold = 3

unitDef = { --//normal lua UnitDefTable
  unitname = "foobar",
  ..
  costs = {
    [wood] = 300,
    [metal] = 100,
    [gold] = 0,
  },
  make = {
    [wood] = 0,
    [metal] = 10,
    [gold] = 0,
  },
  ..
}

[zwzsg]

I've played and modded mods where the hard coded energy and metal are completly hidden and disregarded, and then whole new resources system have been programmed in Lua. See for instance:

Gundam
Which has Basic, Refined and Exotic materials, as well as a C&C-style power bar.

Kernel Panic
Which has "buffer" resource (when playing Network), and "Memory" resource (when Save our Mem gamemode ticked).

(And there are more.)

These aren't just concept or work in progress, but fully implemented and released completely working new resources system. And they allow vastly more flexibitly than anything implemented engine-side, even if well abstracted and configurable. For instance I would bet that whatever abstraction you come up with still won't allow to implement something that KP's SoM (where lua pseudo-wreckage are what drain the resource.)


So explain me again why you need to make changes at the engine C++ source levels, changes that will add their share of bugs and required mod fixes, when we are already using someting something better?

[hoijui]

side performance note: superfluous C++ is still much cheaper than almost any Lua.

it also makes communication between different parts possible/easier (eg mod<->AI).

[Auswaschbar]

zwzsg: does the share window allows me to share metal and energy in kernel panic? Does the endgame graph shows metal and energy used?

edit: like often, you seem to miss the point. With the proposed refactoring, it allows you to have NO ressources engine-wise.

[zwzsg]

Ok.

But then just make a system for mods to declare their resource, and their value at each frame, but still have the resource system managed mod-side, just there'd be an abstracted interface to tell the engine (and so the AI, the end graph, etc..) what are the resources and their current values.

Because really, an engine implementation of resource won't ever be as flexible as a Lua scripted one.

Just from the very few lines you wrote, I already see: "float metal". But what if I want my resource to be of type int?

[FLOZi]

Then just make sure that all your units only make/use integer values of it?

[zwzsg]

<zwzsg> Oh, then I'll ask: Is there any imprecision when storing an integer like one million as a float?
<Auswaschbar> there definitely is a limit
<Auswaschbar> from which on imprecision starts
<Auswaschbar> yeah, I think it should start to kick in about 10^6 ~ 10^7
<Auswaschbar> 8388608
<Auswaschbar> exactly

I want my resources to read as 8765432 and not as 8765432.000000001

[Kloot]

Ssingle-precision floats can exactly represent any integer less than or equal to 1 << 24. But the issue is moot since the Lua library in Spring uses floats itself to store all numbers, so what you want isn't possible anyway.

[zwzsg]

Ah ok. Anyway, that point about precision isn't important, I just tried to pick something to show that hoijui already made assumption about how resource structure work with as little as his 7 lines.

[lurker]

Yeah, 1<<24 because of the implicit 1, making it 16777216. And at that point precision loss just makes it so you're stuck on even numbers, then numbers divisible by 4, etc. You're not going to get danging fractions until you're dividing.

[hoijui]

you are more flexible with Lua then with engine side things.
This is your only argument (if it is not meant as an argument for anything, it would be quite displaced in here).
As this is true for everything, you should write the whole engine in Lua and use that.