Color Wars
Moderator: Content Developer
Re: Color Wars
Since I couldn't find any way to have always visible features, I replaced them by live units. Suprisingly, it made the thing faster. And with the added advantage of seeing the minimap being beautifully covered.
Only issue is that Spring 78 crash with a div by zero when there are 10 000 units (exactly). And Spring 79 crash when there are MaxUnits * Team Number(including gaia) units, so even earlier.
Only issue is that Spring 78 crash with a div by zero when there are 10 000 units (exactly). And Spring 79 crash when there are MaxUnits * Team Number(including gaia) units, so even earlier.
Re: Color Wars
Could you instead calculate and draw (viewport and
radar), the team colored blocks using a lua array?
radar), the team colored blocks using a lua array?
Re: Color Wars
I probably will have to, indeed.
Re: Color Wars
would it be possible to have color areas grew slowly *during* the game?
something like:
square has > 3 neighbours of own color -> stay else became neutral.
think game of life.
and have the painting start from captured sockets.
it would be like a game-on-a-game and you could really see your mapcontroll spreading across the land
something like:
square has > 3 neighbours of own color -> stay else became neutral.
think game of life.
and have the painting start from captured sockets.
it would be like a game-on-a-game and you could really see your mapcontroll spreading across the land
Re: Color Wars
So, in KP 3.4, I updated the color gadget, it lags a little less during the expansion phase, but lags much more when it's just being drawn. From the couple games I had yesterday, I saw it lagged so much it made every other player time out.
I did try to use DisplayList, but it appears gl.UnitShape doesn't work when inside a DisplayList. Or something, I dunno. Open Kernel_Panic_3.4.sd7, deactivate ColorWars1.lua and reactivate ColorWars2.lua.new to see my attempt failing. Or not see, actually.
Unless someone comes with an easier solution, the next step will be to drop .s3o and draw textured quads myself in OpenGL Lua.
To knorke's idea:
The rule of the genuine game of life says every cell has two state. But in KP there are more state: Free, occupied by own team cell, occupied by allied team cell, occupied by enemy cell.
The rule of the genuine game of life makes patterns that bloom and die in funny ways the first time you see them, but after a couple time you realise a randomly seeded screen always end up with non-descript noize with a couple tiny flickers, a couple tiny traveller going out, and the same flower. Patterns giving interesting special properties don't happen randomly, they're always hand crafted, and are destroyed by the tiniest grain of dust.
In the genuine game of life, you start with a given frozen state, thaw it and watch it evolve. Currently in KP color wars, I seed once when the game end, then watch it evolve, so it's compatible. But like you said I made the Color Wars last the whole game, like another layer of game surimposed to the normal game, then I have to come up with rules about how one game interfer with the other.
So in short, you can't just say that the game of life is cool and should be used in Color Wars, because the rule of the game of life cannot be applied as they are, having different team and constant seeding requires a new set of custom rules, which make it so different it stop having anything in common with the game of life beside the idea of an array whose cell changes state.
Well, I can probably come up with something like: Each unit seed, the team color diffuse while losing power, the teamcolor that is the strongest in a cell win the cell.
But then comes up the problem that currently my Color War code is too laggy to be used during the whole game.
I did try to use DisplayList, but it appears gl.UnitShape doesn't work when inside a DisplayList. Or something, I dunno. Open Kernel_Panic_3.4.sd7, deactivate ColorWars1.lua and reactivate ColorWars2.lua.new to see my attempt failing. Or not see, actually.
Unless someone comes with an easier solution, the next step will be to drop .s3o and draw textured quads myself in OpenGL Lua.
To knorke's idea:
The rule of the genuine game of life says every cell has two state. But in KP there are more state: Free, occupied by own team cell, occupied by allied team cell, occupied by enemy cell.
The rule of the genuine game of life makes patterns that bloom and die in funny ways the first time you see them, but after a couple time you realise a randomly seeded screen always end up with non-descript noize with a couple tiny flickers, a couple tiny traveller going out, and the same flower. Patterns giving interesting special properties don't happen randomly, they're always hand crafted, and are destroyed by the tiniest grain of dust.
In the genuine game of life, you start with a given frozen state, thaw it and watch it evolve. Currently in KP color wars, I seed once when the game end, then watch it evolve, so it's compatible. But like you said I made the Color Wars last the whole game, like another layer of game surimposed to the normal game, then I have to come up with rules about how one game interfer with the other.
So in short, you can't just say that the game of life is cool and should be used in Color Wars, because the rule of the game of life cannot be applied as they are, having different team and constant seeding requires a new set of custom rules, which make it so different it stop having anything in common with the game of life beside the idea of an array whose cell changes state.
Well, I can probably come up with something like: Each unit seed, the team color diffuse while losing power, the teamcolor that is the strongest in a cell win the cell.
But then comes up the problem that currently my Color War code is too laggy to be used during the whole game.
Re: Color Wars
I've played a 2-player variant of Game of Life. Life is 23/3 square cellular automata, that is maintenance on 2 and 3, birth on 3. Since 3 is an odd number, in a 2-player game you can determine the faction of the newborn by vote. It was a turn-based game, so placing organisms was all about trying to disrupt the enemy's space or grow your own. Square blocks are incredibly resilient, so getting them is good. 3-line throbbers are not.
Wouldn't work as well with more than 2 players, since you'd have to find a solution for 3 different factions having a baby.
http://en.wikipedia.org/wiki/Life-like_ ... _automaton
is a good list of other rulesets if you want to try a different algorithms.
Wouldn't work as well with more than 2 players, since you'd have to find a solution for 3 different factions having a baby.
http://en.wikipedia.org/wiki/Life-like_ ... _automaton
is a good list of other rulesets if you want to try a different algorithms.
Re: Color Wars
I just started making the ColorWar! display be fully OpenGL Lua: no unit, no feature, nor even UnitShape or FeatureShape. It goes very fast, until a certain point where the initial cells stop to be rendered and it lags all of a sudden. Nested DisplayList probably were a bad idea.
Edit: Ok, now I made it both prettier and faster:



Edit: Ok, now I made it both prettier and faster:



-
Google_Frog
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Color Wars
This looks like it would be good as the basis of a separate game. A territory creating and control game, like fibre but simpler with a much easier interface.
Re: Color Wars
It already exists as a separate game.Google_Frog wrote:This looks like it would be good as the basis of a separate game. A territory creating and control game, like fibre but simpler with a much easier interface.
My idea with combining it with KP was that: You play a game with a fixed deadline. And the end of it, the player who owns the most territory is declared winner. Like a guarantee that KP games are short.
Except, instead of a plain message appearing, you get to see a little animation, showing you how the territory are counted. Because it's more satisfactory to end the game with some ingame animation transforming the whole map that with just a line of text.
If you want it to be more like that, sure, but then we need much better rules that just: expand in free adjacent areas.
Re: Color Wars
The "Color Wars!" does not work well! 
Disregard Kernel Panic, I released lastest Color War inside the mod Balladium_Annihilating.
That mod has two unrelated tricks, so to make Color War trigger fast, and disable the rest:
- Host Balladium Annihilating (3.43, or with the 3.44 patch added.)
- In Mod Option tab:
- set "map" to 20
- set "Color Wars" to 1
- Press + to speed up to the max
- Wait one game minute.
- You should see colored blocks like these.
Some people don't see the blocks appearing (but they see the counting). No error, just invisible blocks for some people. Like I would see the blocks, but in same game Godde and [PoCS]Sprung[CA] would not. Then Godde hosted, and I specced, and I saw his blocks, but he still saw nothing. Now that I recall, the first time I was hosting and we where three ingame, none of us not even me saw any block. But in single player, either running Spring.exe or being alone with AI in battleroom, it worked fine for me every time.
At first I thought it was a problem with multiplayer synching, but now I lean toward unsupported function in some graphical hardware.
The gadget is /LuaRules/Gadgets/ColorWars.lua
Here's the code: http://pastebin.com/m39be2115
I made patch of another version with Regret's copytable and some Spring.Echo: link here
3.44 color wars should say stuff like:
[ 2041] Adding block n=206 @ x,y,z=, 73, 14, 57
[ 2052] New blocks detected! SYNCED.ColorWars.SizeFullBlocks=219
[ 2052] Adding block n=207 @ x,y,z=, 70, 15, 48
[ 2052] Adding block n=208 @ x,y,z=, 70, 14, 64
[ 2052] Adding block n=209 @ x,y,z=, 68, 14, 47
[ 2052] Adding block n=210 @ x,y,z=, 68, 15, 65
If it says that in 3.44 version, and with proper coordinates, then I guess it's really a problem with some OpenGL not working on some graphical card.
Someone with more knowledge about OpenGL LUA helps me!
Disregard Kernel Panic, I released lastest Color War inside the mod Balladium_Annihilating.
That mod has two unrelated tricks, so to make Color War trigger fast, and disable the rest:
- Host Balladium Annihilating (3.43, or with the 3.44 patch added.)
- In Mod Option tab:
- set "map" to 20
- set "Color Wars" to 1
- Press + to speed up to the max
- Wait one game minute.
- You should see colored blocks like these.
Some people don't see the blocks appearing (but they see the counting). No error, just invisible blocks for some people. Like I would see the blocks, but in same game Godde and [PoCS]Sprung[CA] would not. Then Godde hosted, and I specced, and I saw his blocks, but he still saw nothing. Now that I recall, the first time I was hosting and we where three ingame, none of us not even me saw any block. But in single player, either running Spring.exe or being alone with AI in battleroom, it worked fine for me every time.
At first I thought it was a problem with multiplayer synching, but now I lean toward unsupported function in some graphical hardware.
The gadget is /LuaRules/Gadgets/ColorWars.lua
Here's the code: http://pastebin.com/m39be2115
I made patch of another version with Regret's copytable and some Spring.Echo: link here
3.44 color wars should say stuff like:
[ 2041] Adding block n=206 @ x,y,z=, 73, 14, 57
[ 2052] New blocks detected! SYNCED.ColorWars.SizeFullBlocks=219
[ 2052] Adding block n=207 @ x,y,z=, 70, 15, 48
[ 2052] Adding block n=208 @ x,y,z=, 70, 14, 64
[ 2052] Adding block n=209 @ x,y,z=, 68, 14, 47
[ 2052] Adding block n=210 @ x,y,z=, 68, 15, 65
If it says that in 3.44 version, and with proper coordinates, then I guess it's really a problem with some OpenGL not working on some graphical card.
Someone with more knowledge about OpenGL LUA helps me!
Re: Color Wars
yes of course the original game of life rules can not be used for that, its way too choatic. it was just an example to try to explain what i meant.
maybe something like this:
-each player gets one startcell (=your start building)
-each frame (or every 10th) each player randomly places a new block that connects to a field with your own color.
-to grow over an enemy field it has to be surrounded like this:
XX
XO
-number of sockets under control = blocks placed per frame
=>your area grows faster the more land you controll.
different version: no surrounding rule.
with a equal "spawnrate" the borders will roughly remain the same, with a little fuzzy area inbetween. a faster spawnrate will eventually lead to the victory of one team.
this shouldnt use alot cpu since you dont have to go through the whole array each frame?
health drops when near enemies and heals when near friendly. when health reachs zero, they convert to the enemy.
just pretend the cells/blocks do not move but instead the areas grow.
maybe something like this:
-each player gets one startcell (=your start building)
-each frame (or every 10th) each player randomly places a new block that connects to a field with your own color.
-to grow over an enemy field it has to be surrounded like this:
XX
XO
-number of sockets under control = blocks placed per frame
=>your area grows faster the more land you controll.
different version: no surrounding rule.
with a equal "spawnrate" the borders will roughly remain the same, with a little fuzzy area inbetween. a faster spawnrate will eventually lead to the victory of one team.
this shouldnt use alot cpu since you dont have to go through the whole array each frame?
thats how liquid wars does it, here each cell has a health, represented by brightness: http://www.youtube.com/watch?v=QztlQ1e4oz8Each unit seed, the team color diffuse while losing power, the teamcolor that is the strongest in a cell win the cell.
health drops when near enemies and heals when near friendly. when health reachs zero, they convert to the enemy.
just pretend the cells/blocks do not move but instead the areas grow.
-
Google_Frog
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: Color Wars
I know that. That wasn't much of a game though, it needs something extra, maybe buildings that increase grow speed in a radius and allow blocks to slowly eat enemy blocks.zwzsg wrote:It already exists as a separate game.
Re: Color Wars
typo in line 245 + 398
also never use ipairs, "for i=1,#t do" is MUCH faster
also never use ipairs, "for i=1,#t do" is MUCH faster
Re: Color Wars
The overhead for ipairs is less than doing a,b,c,d,e = f,g,h,i once per loop, which is a small fraction of what any of the large loops in this gadget does. If you're going to complain about efficiency, go after the function calling table.remove in a loop, a nice O(n^2)
Re: Color Wars
I think I found. Will have to test later or tomorrow.
Re: Color Wars
I'm pretty sure the spread code in Color War (standalone) is very efficient and fast, it's only the features that lag it down. Also it's much easier to count while it's spreading than to do so after it's done.
Re: Color Wars
Now using:Which should please both jK and lurker.
Code: Select all
for k=#ActiveBlocks,1,-1 do
if frame>=ActiveBlocks[k].Birthday then
table.remove(ActiveBlocks,k)
end
endRe: Color Wars
And it will skip one of two adjacent items, and still crash if the last one is removed.
Re: Color Wars
How so? It's just a single "for" loop from N to 1. Looks O(n) to me.KDR_11k wrote:It's still O(n┬▓)
Why does it skip adjacent item? When I was looping 1 to N, yes, it was skipping items (hence the repeat I had before), but now that I'm looping downard, I don't understand what would make it skip items. As for the crash, it didn't happen ingame (and the table does end up empty). But I'm all ears for better replacment.lurker wrote:And it will skip one of two adjacent items, and still crash if the last one is removed.
