Do bits have a soul?

[zwzsg]

I am making a new stupid game mode for KP. One that again reward porcing and discourage rushing. I've temporary named it "Save Our Souls".

It works like that:
- Whenever a unit dies, it leaves a soul on the place it dies
- The soul lingers until it receives salvation
- The only way to salve a soul is to have a unit from same team touch it
- Every team start with a given amount of faith
- Every soul make the faith of the team decrease every second
- When a team has no more faith, it loses the game

The name "Soul", "Faith" and "S.O.S." are temporary. My question is, what could be the equivalent of soul and faith in the Kernel Panic world? I'm asking you every geeky, nerdy, computerish, robotic, internet lore-ish, cyberpunkish words that could hint at the idea of a machine soul.

[Beherith]

Allocated sector.
Leaked memory.
Garbage collection.

[aegis]

NX Bit
IPv6
NAT
Sledgehammer
Packet Sniffer
Remote Exploit
Virtual Machine

[zwzsg]

The word NX is already used by the Pointer special weapon.

<Dotz> hm...
<Dotz> I'm trying...
<Dotz> data recovery?
<Dotz> defrag?
<Dotz> corrupted file?
<Dotz> are those good names?
<zwzsg> Bad block is already used for the walls btw
<zwzsg> The mod could be called "data recovery"
<zwzsg> And the faith, uh, fragmentation?
<Dotz> no
<Dotz> fragmentation is bad
<Dotz> binary!
<Dotz> an excellent name!

[Pxtl]

Orphaned memory. You have to rescue the orphans.

Too many orphans causes out-of-memory-error.

A better metaphor is a memory-leak, but "orphans" are better imagery.

The "corpse" of the Bit is a "memory leak". Your "faith" is memory. Running out of memory = death.

[knorke]

floating eyes like the eaten ghosts in pacman!

[Pxtl]

Alternately - this is a bit of a metaphor jump - but make the animated corpse of the unit a "Zombie Process", and you have to KILL your zombies instead of touch them.

I just like zombies, and zombie processes would be a good concept for KP... although they're superheavyweight programming objects to be corpses of "bits".

Alternate metaphors for "ghost" memory:

Shadow memory (when every operation is done twice)
Journal entries (journaled filesystems note all their changes, including deletions)

Interesting possible reference: one of the two main open-source journaled filesystems, ReiserFS, has become something of an orphaned project because the lead developer (Hans Reiser) was convicted for the murder of his wife.

Plenty of opportunity for morbid humour with that theme, if you wanted to go there.

[zwzsg]

Some more precisions no one asked:
- The souls spawn as immature
- Souls aged 5 seconds turn mature
- Only mature souls can be salved
- Only mature souls decrease faith
- Larger units drop bigger souls
- Souls that are close fuse into a bigger soul

It bears some similarity to the wreckage system, which maybe I could have used and built upon instead of reprogramming all in Lua. Bah.


To ensure I don't promise then not deliver, I waited till I had it coded and running before making thread. And yeah it does look a bit like ghastly eyes cause I cba to do fancier OpenGL stuff than gl.DrawGroundCircle.



There's a bug that packets leave a soul when they are getting bufferised , flow might be OP again, and AI lose alot because of it, but otherwise it works.

The idea of running out of memory because of memory leaks sounds good, it fits with the concept of having to find memory leak to "free" them, and it fits with the concept with a bar that start a large value, then goes down to zero at which point you die. Save that freeing forgotten memory leak should give back your memory, and that orphan use memory once when done and not every second, while now it doesn't work like that, but I could just change my gamemode a little bit, where instead of minimising the time you have souls, you'd have to make sure the number of memory leak never exceed a given amount. I kinda like the idea of irreversaible and constant loss of power though, give a stronger feeling of urgency.

KP already has zombie, they the virus! When you get bitten by a worm, when you die you spawn a zombie (=virus) and unit that gets bitten by virus (=zombie), when they die, the come back as zombie (=virus). I mean, infection.lua has code such as: local zombie="virus" and local zombieID=UnitDefNames[zombie].id

[REVENGE]

lulz Spring.Bioshock

[hoijui]

an other analogy:
when you delete a file (which is formed out of bits and bytes ), it just removes the FS entry to it, usaully. so the souls could be a thing like such a file, unreferenced memory, may be freed at any time to be used by an other file. saving a sould could be either: reuse the memory for new data, or reacreating the original data -> re-referencing it.

[zwzsg]

I think I'll go with "memory leaks" or something to that effect.

After playing a string of multiplayer game with them, I found that:

• Sudden death when you're out of faith is anticlimatic, especially when it happens by surprise to one of your adversary. I will have to think of another effect than "now you lose" for when faith is running low. Maybe something like having all units armor multiplied by current faith/initial faith, or a mighty attacks by creep units out of nowhere attacking you and only you, or whatever.
• Faith goes down much faster than I thought it would. I have to use values in the range of several ten thousands for any medium to large maps.
• Somehow, the more units you have, the more souls you inadvertently drop, which means that in late game, the one with most units lose. Also means that it doesn't matter what you do in the beginning, since anyway at worse you'll be like -7, while at the end any mistake result in immediate -50. Maybe I'll make scale the faith decrement scaled to number of live units, or something.
• Also, would be cool if I could devise a formula to scale initial faith to map size / number of geos / number of players / skill of players / else. Right now the host has to guess what would be a proper value for each game, too low and player dies without even having realy started to battle, too high and faith stop mattering.

[Pxtl]

Thoughts: an alternate approach would be to keep a percentage of the "leaked" memory owned by the memory leak. That is, when you rescue a memory leak, you get a proportion of the memory back (50%? 100%?). This would mean that "older" leaks are more important to recover (and, if they're enemy leaks in your territory, defend).

As for scaling the importance of leaks, I'd play with the maximum instead, and make it obvious to the player - as they build more units and watch the right side of the memory ratio go up. For extra fun, you could limit it to a small subset of units that count as storage - datavent buildings like the Terminal - in that case, territory gives you protection, and the final blow could be the destruction of a terminal instead of a sluggish countdown. Or some buildable unit, which would allow the player to prolong the inevitable indefinitely (or until he fills up his buildable space with units) - bits would mean that every terminal pushes up the max continuously, but Assemblers would create the funny image of the player keeping an Assembler farm back at home base, constantly spamming them to keep his max as high as possible.

[zwzsg]

It would indeed solve several problem at once:
- Players more likely to lose right when losing a minifac than during uneventful peacetime.
- Scales with game size / map size / number of players / number of datavents automatically.
- Let the player who owns the map able to afford much more lost sou.., err how do we call them again? Orphaned memory? Unreferenced memory?

The only problem is that, in current system, the amount of Fa.. err Free Memory start at max, then go down, always down, never up. So adding empty storage at the top would do nothing, I must add filled storage at the bottom, or invert the flux direction. Since 5,4,3,2,1 conveys a much greater sense of Doom than 2043,2044,2045,2046,2047, I'd rather have the game start with bar at whatever then goes down to zero, than have it start at zero and make player lose at a whatever number that will never look as meaningful as a zero to him. To make it clearer each building brings a memory storage, I'll make the memory bar sectionned in sectors (with thin black marking).

One problem with calling soul and faith unreferenced memory and memory is that I'm afraid that some unsuspecting player seeing "Free Memory" in his interface, might think it refer to the actual memory of his actual computer, instead of to some game resource. That's why I was hoping one of you to come with more imaged obscure nerdy reference.

Sidenote: Also, I should try to take the habit of referring to geo when in the context of KP as datavent, as it sounds much cooler.

[bobthedinosaur]

This is sounding more and more like that cartoon explaining scientology... ...

[Pxtl]

Perhaps "corruption" is a better term? Each dead unit is corruption, and the limit is "uncorrupted data".

edit: yay me, I'm pretty sure I coined the term "datavent".

[KDR_11k]

How about simply having faith generated by live (or newly built) units so more units don't result in a faster loss if some of them die? Or allowing enemies to drain souls and thereby increase their impact on your faith?

Or, if you want a nasty approach, allow units to pick up enemy souls and if they do they gain a stat boost for every soul claimed (friendly souls don't give boosts, only prevent the enemy from utilizing them). Maybe even let units that collect a certain number of souls morph into supersized versions and have the existence of those be what damages faith (they'd have to be alwaysvisible, of course).

Hm, could take it even further and make the superunits soul junkies that die if they don't get their fix regularly so they have to remain on the frontline.

[zwzsg]

So, in KP 3.4, I updated the Save Our Mem gadget. Now the memory is divided into sectors. Whenever you build a minifac or a special on a datavent, you get new sector. Whenever you lose a minifac or a special, you lose a sector. The sector you win or lose are added or removed from the right of the bar. That is, filled. They're not like metal or energy storage which instantly backup all their content to other storages right before dying. Instead, they instantly fill up to the max right before dying, to make sure they go out with a whole sector worth of memory.

Anyway, so it should now scales a little with the map size, and with how much you owns compared to other player.

Also, now, when you run out of mem, instead of instantly getting game over, you only lose all small and moving units, and gets all building health set to 1% or 2%. Well, some of them may they die too, I think because of splash damage of nearby units, but that's just a bug (pretty annoying when it happens to homebase, will have to fix). The idea is that you get really crippled, and the other player can easily finish you. But that if you were really dominating, you won't lose just because you ran out of mem. If you set the mod option to negative, you revert back to instakill when outta mem.

Oh, and to convey the idea of a loss that is continous (per second), and irremediable, from now on I'll call what is left by dead units "Memory Leak".


KDR_11k said it lacked a tooltip, so in next version a tooltip it should have: (I hope it's not too verbose):

[Acidd_UK]

I actually like the terms soul, and faith. I think it's a nice way of accepting that not everything can be expressed with computer science.

[zwzsg]

I wish I could have used a Ghost in the Shell reference, but I couldn't find a way to turn it right.