Color Wars

[zwzsg]

I added some sort of Color Wars to KP:

A new mod setting, that let you set a timer. When the timer runs out, every unit spawn team-colored blocks and those team-colored blocks self-replicate until the whole map is covered. The team with most blocks then wins.



It sorta works, but:
- During block replication, it uber-lags. When there's only two-three spawn points the lag is heavily felt but I can still follow the block progression, but in real conditions like as many units as 3 mins into the game, it freezes until the map is done being covered. I'm annoyed to have to admit KDR_11k was a better coder than me.
- I would need the blocks to be always visible.

[imbaczek]

spawn at most N blocks each frame, should help with lag a bit.

[zwzsg]

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.

[trepan]

Could you instead calculate and draw (viewport and
radar), the team colored blocks using a lua array?

[zwzsg]

I probably will have to, indeed.

[knorke]

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

[zwzsg]

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.

[Pxtl]

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.

[zwzsg]

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:

[Google_Frog]

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.

[zwzsg]

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.

It already exists as a separate game.


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.

[zwzsg]

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!

[knorke]

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?

Each unit seed, the team color diffuse while losing power, the teamcolor that is the strongest in a cell win the cell.

thats how liquid wars does it, here each cell has a health, represented by brightness: http://www.youtube.com/watch?v=QztlQ1e4oz8
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]

It already exists as a separate game.

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.

[jK]

typo in line 245 + 398

also never use ipairs, "for i=1,#t do" is MUCH faster

[lurker]

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)

[zwzsg]

I think I found. Will have to test later or tomorrow.

[KDR_11k]

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.

[zwzsg]

Now using:

Code: Select all

		for k=#ActiveBlocks,1,-1 do
			if frame>=ActiveBlocks[k].Birthday then
				table.remove(ActiveBlocks,k)
			end
		end

Which should please both jK and lurker.

[KDR_11k]

It's still O(n┬▓)