Infinite resource amount and storage

[smoth]

Notice: please read the entire post before posting an answer to this, and sorry it's so long! Also thread derailment

Why is this thing in Content Creation -> Games & Mods forum? I recall posting it in the Feature Requests, as it was and still is a genuine engine feature request.
I'm not satisfied with the proposed solutions as they all look hacky, and I don't think lua should be used just because you can, as it either unnecessary complicates the game or wrongly models (f.e unit with large amount of storage, large real value amount of storage) the desired effect (infinite storage in this example).

Now since the thread has already derailed, I'd like to whine about this and a couple of other things (such as the Invulnerable units thread, or changing Unit Defs runtime and changing players/teams runtime):

Even though you can normally work around some of these things, it is still a problem when you get to more complex things such as f.e scenario(mission) editors in which you'd like to allow users an easy way to edit stuff, and you don't want to annoy yourself by doing game restarts (for teams/players/unitdefs changes), or hacky things that may/may not work depending on the mod you are using (no idea if bullethits or economy changes would conflict with existing mod mechanics).

Also, the more of these core concepts that you have out of the engine, the harder it will be for new people to create content for Spring, and the harder it will be for AI creators to work with Spring - simply due to the lack of a proper, well known interface.

My current aim with Spring is twofold:
1. To assist in creation of non-skirmish games, such as f.e multiplayer competitive/cooperative games (think WC3: footmen frenzy, risk, tower defenses, hero arenas/sieges, etc.), as well as single/multi-player storytelling games with a (linear/non-linear) campaign. I believe in order to facilitate that we need to widen the range of people that can create that content (which they will most likely base on existing skirmish mods/games). I also believe this should be done by creating graphical tools (such as the existing ZK mission editor, but better), and I believe those tools should be built on top of the engine, since WYSIWYG tools ease the start for people familiar with the game they'd base their work on (which they probably played a lot and got their motivation from), but not with lua or the spring engine interface.

2. Create a good environment to develop AI in multiple languages, with the ability to easily test, compare and compete with other AIs. For this I'm working on springgrid, a site that allows people to queue AI games, create AI leagues and whatnot. I'd also like to see AIs that can solve scenario based games (and not just skirmish ones), which I think would be a great thing for AI research as well as AI gaming.

The problem I see with Lua is that it complicates creation of new content by independent developers. If someone were to implement some feature (such as f.e infinite storage or invulnerable units) in the engine, it would be easily used by any of the target groups: mod/game devs, AI devs (such a small community), widget devs (sorry! i believe they still exist), scenario devs (indirectly, by using a scenario editor), etc.
However, if someone were to do it in Lua, and say he were to also create an library-like interface, how would we be able to use it in our independent widgets/scenario editors/AIs - i.e how can we know of it's existence (programmatically).

The AI problem.
Sending messages to lua sucks, I want a clean interface (with doc) to work with.
F.e in a Java AI, how am I to know that a certain unit can be invulnerable (or any other Lua game/unit property)? I would probably need to have an additional library (an additional .jar) from that mod that supports the notion of invulnerability (and what happens if a scenario supports that concept while the mod on which it's based on does not? the creator of the scenario would need to supply it).
Now if we don't want those content developers to spend their time creating java libraries that expose the features they're using, we would most likely want some sort of a parser that would create an interface automagically (yes, that interface may send messages to lua all it wants, but that should be hidden from the developer). I'm worried that this is a hard problem, seeing as how we're still struggling to create basic (spring engine) AI interfaces for other non C++/Java languages.

The Scenario Editor problem.
So what extra stuff does your mod support? What can the users configure? What values does it take, etc.?
In the process of creating the Scenario Editor, I've reached a point where I'd like to allow users to configure/test properties, and based on that make some changes to the game/have some sort of notifications (f.e: if hp% of trigger unit < 50% send message "the base is under heavy fire!"). The problem is with the idea that I'd like to support all mods with this - which in theory should be possible since it's based on the same engine, however, while I could define properties such as this:

Code: Select all

		{
			humanName = "Unit HP%",
			name = "unitHP%",
			data = { "unit" },
			output = "number",			
		},

I have no idea how to do this for mod-specific properties outside of writing custom files for those mods that should hold those properties, (imagined) example:

Code: Select all

		{
			humanName = "Unit Neutrino Capacity",
			name = "unitNeutrinoCapacity",
			data = { "unit" },
			output = "number",			
		},

It gets more complex with infinite storage and other stuff that isn't just simply properties, but rather game options.
The problem boils down to the same thing like with the AI, can lua feature creators specify stuff that they created in a way that allows usage on the same level of quality like it would be with the official Spring engine documentation? And how can we expose that stuff in a pleasant manner to other (independent) devs?

(copied your post so it doesn't get skipped over)

why lua? because not everything uses metal and energy.

you are requesting an engine feature for a game.

there is no such thing as infinite number. There are ways to work with around such limitations but you'll consider them hacks.

"what about ai not being able to read lua" HA HA HA deal with it? I have to.

Dude, your problem could be solved with lua. That is how we are supposed to do it. "hacky" no, I think we have had this conversation before you just don't like the answer.

Your thread was derailed because any of us with the knowledge to handle it answered/saw your request as silly(this is my guess).

but but I need to be able to dev in an environment where ai has infinite resources... you still cannot has infinite resources. Data is limited and spring is 32 bit at that...

I feel like you will just ignore all this and complain that you didn't get what you want and deride all the solutions that have been offered, including mine should I offer a solution.

ps: engine "infinite" resources won't be supported by anything with custom lua economies... so it would be a "hack," with "HACKS" to cover it...

[gajop]

(copied your post so it doesn't get skipped over)

why lua? because not everything uses metal and energy.

you are requesting an engine feature for a game.

there is no such thing as infinite number. There are ways to work with around such limitations but you'll consider them hacks.

"what about ai not being able to read lua" HA HA HA deal with it? I have to.

Dude, your problem could be solved with lua. That is how we are supposed to do it. "hacky" no, I think we have had this conversation before you just don't like the answer.

Your thread was derailed because any of us with the knowledge to handle it answered/saw your request as silly(this is my guess).

but but I need to be able to dev in an environment where ai has infinite resources... you still cannot has infinite resources. Data is limited and spring is 32 bit at that...

I feel like you will just ignore all this and complain that you didn't get what you want and deride all the solutions that have been offered, including mine should I offer a solution.

ps: engine "infinite" resources won't be supported by anything with custom lua economies... so it would be a "hack," with "HACKS" to cover it...

what does resource type have to do with whether a resource or it's storage should be infinite/unlimited? (if you're implying that other resources aren't supported, there's an existing GSOC project for implementing custom resources)

"haha deal with it" -> The best way people "deal with a lacking API" is to find a new one, f.e http://code.google.com/p/bwapi/. If we want to drag people into spring, we should at least offer a comparable API (ITT problem: lacking lua extensions). And the reason I want to use spring is because in general, open source solutions make your life as a developer somewhat easier (f.e it's just annoying to go to menus to create a game, where you can do it by simply executing a script in Spring).

While infinite resource amount semantics may be questionable, i'm sure you can imagine quite well why unlimited storage (instead of it being infinite it may be better to think of it as unlimited) makes sense. Sometimes you just don't want to impose a limit on how much resources there should be (why is that even a default?).

The thing I said in the second part of the last post is, while you indeed can do nearly everything in lua, I claim that it is harder to have other people use it independently (as a part of an AI/scenario) when it's in lua, rather than if it were in the engine. I also claim that things that can easily be generalized to all RTSes (such as having or not having a limit on the amount of resources, having a unit that can or cannot take damage, etc.) should be a part of the engine. And since I haven't seen anyone come up with a reason how this may restrict anyone in their game creation, I'm asking you this "why shouldn't it be in the engine?".

The thing I'm saying is:
- Things that are often seen in many RTS games and don't constrain your game possibilities -> "engine it".

PS: No idea where you saw me saying infinity was a number - if I did I was wrong. However programmatically, we can represent it with a (bool) flag which determines if it's infinite or not, and even use IEEE double/float markers for infinity if someone is to invoke calls to determine it's numbers.

[smoth]

"why shouldn't it be in the engine?".

why lua? because not everything uses metal and energy.

you are requesting an engine feature for a game.
. . . .

ps: engine "infinite" resources won't be supported by anything with custom lua economies... so it would be a "hack," with "HACKS" to cover it...

[knorke]

Why is this thing in Content Creation -> Games & Mods forum? I recall posting it in the Feature Requests, as it was and still is a genuine engine feature request.

I moved it because it seemed asking for something that "is already easily implementable in many ways."
(dunno if that is wanted, but otherwise "feature requests" would be full of threads that are actually "how do i do xy", which lowers chances of engine devs reading legit threads)

Sometimes you just don't want to impose a limit on how much resources there should be (why is that even a default?).

actually the default limit is 0:
games have to use Spring.SetTeamResource(teamID, "ms", limit) to set a limit.
For no storage limit you can set it to "99999999999999999999999", which seems to work for Conflict Terra.
Probally gets clipped to <limit of float> or w/e but it is more than enough for any realistic use.

(no need to display unit cost of a resource that you have an infinite amount of, no need to display the current / max_storage bar if max_storage is infinite).

Possible:

notice there are not even metal income bars. Games can make their UI whatever they want.

In Kernel Panic you have "unlimited" resources, as in you can build as many units as you want and will never run out of metal.

However programmatically, we can represent it with a (bool) flag which determines if it's infinite or not, and even use IEEE double/float markers for infinity if someone is to invoke calls to determine it's numbers.

That requires work: In all places in engine where is a check for "has enough resources" it would need an extra check, those lua function like GetTeamResources would need an extra parameter etc.
Hardly worth it when you can make it work without that (see above)

---

The thing I said in the second part of the last post is, while you indeed can do nearly everything in lua, I claim that it is harder to have other people use it independently (as a part of an AI/scenario) when it's in lua, rather than if it were in the engine.

I think that is just because some Lua stuff is made without too much thought or care.
Some gadget actually to interact with other Lua (be it AI or scenario) for example:
http://code.google.com/p/zero-k/source/ ... _morph.lua (read comments at top)
For example the healthbars widget reads from that gadget and displays remaining morph time. So it is possible.

Some people (like me) do not bother with that mainly because it is not worth it to add lots of maybe-to-be-used interface stuff to every few lines gadget you make.
Also, say you have a weapon where electric lighting jumps unit to unit and damages multiple targets:

The weapon is obviously much stronger than the numbers in weapondef might suggest, but how to tell it to the AI?

Also, the more of these core concepts that you have out of the engine, the harder it will be for new people to create content for Spring,

No, it becomes easier.
With lua so much more people can create stuff. It is also easier put into eg maps, should all maps with scripts include some .dll files written in C?
Most people can hardly look up stuff in the engine code, how should they edit it..
"core concepts" is a matter of taste:
For example healthbars for units are a standard in rts games, but spring games do them via external lua scripts. Advantage: can easily add new bars (shield, mana, stamania etc) or change the appearance.

and the harder it will be for AI creators to work with Spring - simply due to the lack of a proper, well known interface.

That is not purely the fault of Lua though, most AIs sadly seem to end at this stage:
http://springrts.com/phpbb/viewtopic.php?f=15&t=28124

you can even make mods without any strange Lua that are "unplayable" by AI: There are many examples of features from games that AIs do not use. For example when E&E introduced "construction hubs", AIs were confused.

In the starcraft AI api you linked:
http://code.google.com/p/bwapi/

bool siege();
Orders the unit to siege. Note: unit must be a Terran siege tank.

Note the note.
As far I see, there is no canSiege (returns true/false) function because "everybody knows the terran tank is the only unit that can siege." That is obvious, so there is no function to check for that.
imo it is similiar with spring, AI maker has to asume/know some things about the game.

[Google_Frog]

I fix the AI interface problem by writing my AI in Lua and using both customparams and Spring.SetUnitRulesParam. Does this online AI battle system support Lua AI?

[gajop]

I fix the AI interface problem by writing my AI in Lua and using both customparams and Spring.SetUnitRulesParam. Does this online AI battle system support Lua AI?

No idea what exactly SetUnitRulesParam is, but I assume you use it to set mod-specific unit properties?
Problem with Lua AIs are that they enforce a language choice which may not be a very good one - imo there are no benefits of dynamic typed languages in AIs (the complexity tends to not come from the AI interface), they lack proper OO concepts and numeric/AI libraries, and have an often drastically slower language that compile-time ones.


(The site) works if unitsync lists Lua AIs. It's only a central repository for scheduling games on people's PCs much like the @Home programs.


PS: I've read your post knorke and I'll answer it when I get back home, got to run now.

[gajop]

actually the default limit is 0:

what does that mean? a limit of 0 means that it's unlimited? i.e storage is infinite?

games have to use Spring.SetTeamResource(teamID, "ms", limit) to set a limit.
For no storage limit you can set it to "99999999999999999999999", which seems to work for Conflict Terra.
Probally gets clipped to <limit of float> or w/e but it is more than enough for any realistic use.

Indeed, while this "seems to work", it wrongly models the desired effect (no limit), and may cause unexpected problems.

Possible:
*picture*
notice there are not even metal income bars. Games can make their UI whatever they want.
In Kernel Panic you have "unlimited" resources, as in you can build as many units as you want and will never run out of metal.

Yes, indeed, you can create whatever UI or AI you want, however if f.e the creator of the game (scenario/mod) does not work in coordination with the widget creator (not the same person/team), it may be hard/ambiguous to represent the desired effect, such as unlimited storage. I've even seen it once in that zero-k asteroid mission, where I assume that metal or energy was supposed to have unlimited storage, but it was still shown (as a nearly empty bar), as the widget was not set to interpret it - it may've been non obvious.

That requires work: In all places in engine where is a check for "has enough resources" it would need an extra check, those lua function like GetTeamResources would need an extra parameter etc.
Hardly worth it when you can make it work without that (see above)

Yep, it does, most engine features do. However, I can try implementing any feature I propose - it would serve as a motivation to accept it first though, so I know my work wouldn't go to waste.

Lua functions would probably be ok without extra parameters, they can just return inf. if it's unlimited (the code may need to check for it though, which is the entire point).

I think that is just because some Lua stuff is made without too much thought or care.
Some gadget actually to interact with other Lua (be it AI or scenario) for example:
http://code.google.com/p/zero-k/source/ ... _morph.lua (read comments at top)
For example the healthbars widget reads from that gadget and displays remaining morph time. So it is possible.

While that seems to be relatively easily readable by humans, it doesn't seem machine readable. However, ideally, we would want to be able to parse such files (or other files that annotate them), and be able to generate executable code/data that may be used elsewhere (i.e by creating a java library that exports the morph command so AIs can use it indirectly, some sort of javadoc/doxygen-like generated docs, etc.).

Some people (like me) do not bother with that mainly because it is not worth it to add lots of maybe-to-be-used interface stuff to every few lines gadget you make.
Also, say you have a weapon where electric lighting jumps unit to unit and damages multiple targets:
*PIC*
The weapon is obviously much stronger than the numbers in weapondef might suggest, but how to tell it to the AI?

Yes, some stuff may not be worth working for, esp. currently since spring has few scenarios/AIs. Certain things may be hard to annotate exactly, but it can still be approximated, in your example, you could somehow annotate that weapon def with a Lightning Effect, which is a custom weapon effect, and it's type is f.e "lightning_ark".
But from that example you can imagine that a lot of games have weapons that may have a certain extra "effect" (other than the direct damage). In fact, there are few games that only have the simple direct damage weapons. It would thus make sense to have some sort of "WeaponEffectType"s on the engine side so you can formalize (at least in name only) what your weapon/bullet can do.

No, it becomes easier.
With lua so much more people can create stuff. It is also easier put into eg maps, should all maps with scripts include some .dll files written in C?
Most people can hardly look up stuff in the engine code, how should they edit it..
"core concepts" is a matter of taste:
For example healthbars for units are a standard in rts games, but spring games do them via external lua scripts. Advantage: can easily add new bars (shield, mana, stamania etc) or change the appearance.

The idea is that you are creating (game) content with lua, but you can use (vast) existing engine features to easily model the desired mechanics. "Core concepts" is what the engine devs decide are things that occur in games often enough that they would be implemented in many games. The main reason for the original thread was to evaluate if those things were worthy of being added to the engine.

In the starcraft AI api you linked:
http://code.google.com/p/bwapi/

bool siege();
Orders the unit to siege. Note: unit must be a Terran siege tank.

Note the note.
As far I see, there is no canSiege (returns true/false) function because "everybody knows the terran tank is the only unit that can siege." That is obvious, so there is no function to check for that.
imo it is similiar with spring, AI maker has to asume/know some things about the game.

Indeed, the AI has to know some things about the specific game, but ideally that shouldn't be much more than what the players know (every half-decent SC player knows what can/can not siege). However, the main difference between SC and Spring, is that in Spring, you may want to expose those unitType properties if not for the reason that you can have a multi-game AI.
Now that doesn't necessarily mean that the AI would be able to play any game (even those that the creator doesn't know about), but that you could have a single AI, that works slightly different depending on the game, while still sharing a lot of common code. A lot of SC bots can share code in between races, and SC races are more different in comparison to each other than are many Spring games.

[Karl]

C'mon man why do you want so badly infinite storage/ammount?

Just give your self over ridiculously highly astronomical numbers and you will be fine this is close enough...

But oh well it seems no body cares and wants a true infinite resource/storage...

[gajop]

C'mon man why do you want so badly infinite storage/ammount?

Nah, I don't want it that badly. This thread derailed a long time ago, and we (or at least I) am currently discussing possible pros and cons of using lua instead of engine support for certain features I consider "too common to not be in the engine".

[smoth]

C'mon man why do you want so badly infinite storage/ammount?

Nah, I don't want it that badly. This thread derailed a long time ago, and we (or at least I) am currently discussing possible pros and cons of using lua instead of engine support for certain features I consider "too common to not be in the engine".

You are just ego wanking.

Possible pros and cons.. learn them by trying first.

this community loves to talk and ego stroke about ideas and seldom ever implement them.

it is all mental masturbation and I loathe "idea guy" types for it.

[KDR_11k]

If you want AI you need to write it yourself. An AI needs to know more about how to play the game than just raw numbers. "Generic" AIs either just randomly build crap or are designed for TA-based gameplay. The physics simulation alone makes predicting behavior algorithmically difficult, then there's stuff like turret turn rates which aren't stated explicitly anywhere. The old BOS scripting could already generate units that are too complex for AIs to understand.

The TA economy that's in the engine is already a bit too specific for what an engine should be doing (and it's pretty far from the standard for RTSes too) but it's being left in because it's so widely used. Sticking more on-off options on that mess doesn't really make it more palatable as an engine feature.

Generic engine-wide AIs just don't exist for any engine. Engines can come with AIs for the gameplay of the game they were originally made for but anyone who isn't making UT in the Unreal Engine will need to modify the AI for his own gameplay.

[Google_Frog]

I agree with smoth, have you looked into current implementations of this stuff?

Look into Spring.GetUnitRulesParam and Spring.FindUnitCmdDesc. If the non-Lua AI interface has equivalent functions it is able to fetch a lot of the information that is available to players. But with the amount of lua flying around this cannot be done without game-specific knowledge so you may as well hardcode yourself some data tables.

Implementing complex interfaces is a waste of time if they are not going to be used. Do you want to make a non-Lua AI for ZK? If so, explore the current interface and get something basic working. If it turns out the interface is too limited I can implement more stuff gadget-side.

[FLOZi]

If you want AI you need to write it yourself. An AI needs to know more about how to play the game than just raw numbers. "Generic" AIs either just randomly build crap or are designed for TA-based gameplay. The physics simulation alone makes predicting behavior algorithmically difficult, then there's stuff like turret turn rates which aren't stated explicitly anywhere. The old BOS scripting could already generate units that are too complex for AIs to understand.

The TA economy that's in the engine is already a bit too specific for what an engine should be doing (and it's pretty far from the standard for RTSes too) but it's being left in because it's so widely used. Sticking more on-off options on that mess doesn't really make it more palatable as an engine feature.

Generic engine-wide AIs just don't exist for any engine. Engines can come with AIs for the gameplay of the game they were originally made for but anyone who isn't making UT in the Unreal Engine will need to modify the AI for his own gameplay.

kdr hits the nail as usual

[knorke]

a limit of 0 means that it's unlimited? i.e storage is infinite?

0 means zero: no storage at all
remove game_spawn.lua (or whats it called) from BA and see.

No idea what exactly SetUnitRulesParam is, but I assume you use it to set mod-specific unit properties?

UnitRulesParam: per unit data that can be read/written by Lua.
It does not really do anything (as in affect the physics) and is more like per-units notes and other lua can read it.

There is also SetTeamRulesParam:

I've even seen it once in that zero-k asteroid mission, where I assume that metal or energy was supposed to have unlimited storage, but it was still shown (as a nearly empty bar), as the widget was not set to interpret it - it may've been non obvious.

Could modify the resource bar to be hidden on certain conditions. (eg your missions does SetTeamRules ("infinite metal") and the resbar reads that)

The idea is that you are creating (game) content with lua, but you can use (vast) existing engine features to easily model the desired mechanics.

No, not really...for most lua things there exists no similiar part in the engine. The engine gives mods some Lua function such as setting the health of a unit. But what is done with it (burning units that lose health, hero that heals near units, undestructable units, armor upgrades) is not in engine. So if an AI wants to know "is this unit burning?" it should ask the mod, not the engine.

[gajop]

this is totally not my bot

[Forboding Angel]

Billie Jean is not my lover.