Kernel Panic
Moderator: Content Developer
Well, you could kill them with mines! XD Anyway normally you play KP only on ground only maps, so it's not like it matters. It's just at some point I thought it would be cool to have a KP map with an area where units get strange property (like, no fire zone) under a strange texture, but yeah, I haven't really completed that aspect. So just ignore it.KDR_11k wrote:Careful with amphibious units, you don't have any weapons that can shoot underwater so a unit in the water would be impossible to kill.
Oh and is there any AI that know how to play Kernel Panic?
hi guys. sorry for dissapearing, but yeah, real life caught up with me. i passed my tests, and now i'm in my new semester and am studying like 60 hours a week...
right now I don't even have time to play spring, let alone mod for it. therefore i have given KDR_11k and zwzsg the authority to publish official releases.
have fun with kp, i certainly did. also props to everyone who liked my idea and made a really cool mod out of it.
see you guys around, i hope to see a kernel panic game when i log in once and a while :)
right now I don't even have time to play spring, let alone mod for it. therefore i have given KDR_11k and zwzsg the authority to publish official releases.
have fun with kp, i certainly did. also props to everyone who liked my idea and made a really cool mod out of it.
see you guys around, i hope to see a kernel panic game when i log in once and a while :)
NTai plays kernel panic however there is one issue, everytime you rename the archive or update the mod you need to build a new config because Kernel panic doesnt have the NTai modname tag telling it what the cofnigs are called, for example:
Code: Select all
[MOD]
{
Name=Expand and Exterminate v 0.173;
Description=E&E Battle for the Blue Planet v0.173;
URL=TBA;
ModType=1;
NumDependencies=0;
[NTAI]
{
tdfpath=EE;
}
}Thanks Alantai Firestar! Indeed yours is the first AI that managed to build sockets. However, there seem to be a slight problem with where it lays its "attack pos": it insisted on massing its army near the bottom of a cliff, instead of going killing the last remaining buildings.
Oh, and everybody get & play KP 1.0 now!
Oh, and everybody get & play KP 1.0 now!
Your description calls the pointer useless against moving units, that's not true. It was in 0.7 but ever since I changed the shot to a missile it can hit moving targets as well.
BTW, your concern about bytes being too weak might've been addressed better by making pointers weaker against them, not them stronger against bits to weaken the RPS rather than strengthen it.
BTW, your concern about bytes being too weak might've been addressed better by making pointers weaker against them, not them stronger against bits to weaken the RPS rather than strengthen it.
Please fix that filename:
logic_bomb.jpg
to
logic_bomb.bmp
Because, that is really a BMP, not JPG. And it makes problems when converting those images to JPG, for modit. (this is not first time when i say about that).
Now its there:
http://modinfo.unknown-files.net/modit/ ... _panic_1.0
logic_bomb.jpg
to
logic_bomb.bmp
Because, that is really a BMP, not JPG. And it makes problems when converting those images to JPG, for modit. (this is not first time when i say about that).
Now its there:
http://modinfo.unknown-files.net/modit/ ... _panic_1.0
========================================
========================================
Stuff I would do for KP 1.1 if I were doing a KP 1.1 but anyway I won't ever have the time to:
========================================
========================================
Hmm, I think I haven't well explained why I have that problem with mines. Well, first, we all agree that something > nothing. So, considering that assembler cannot heal*, cannot reclaim-attack*, cannot assist, and cannot build more factory once all geos are covered, they are better off buildings mines than standing still, doing nothing, right? (*: not sure of those two). So we can assume that for fairly competent players, all assemblers will be churning mines once they're done with making sockets. Now, let's consider a byte. Leave it alone for 5 mins, you still have one byte. Leave it alone for days, you still have just a byte. Now, let's take an assembler. Leave it alone for 5 minutes, you get a small minefield. Leave it alone for half an hour, you get a huge minefield. Leave it alone for days, you get the whole map covered by mines. See the problem? The power of assembler augments over time, while the power of attack units don't. It seems to me like a free infinite growth loophole.
Some idiots might retort that since every unit is free, why do I have only a problem with free mines and not the free other unit, but this doesn't hold, because:
- Yes it should be every player aim to cover the map with his units and factories. But not to cover the map with mines! You can't cover the map the factories, because sockets are limited by the number of geos. As for units, well, the output flow is constant once you reach max socket, while mine flows keeps ... err sorry I need to adopt a more mathematised standpoint:
- During the intial growth phase (between start game and last geo getting covered), the number of factories augment linearly over time, and the number of units per factory augment linearly over time, so the the function "number of units over time" is like t├âÔÇÜ├é┬▓. Well, actually, that's if you build a couple builder the first instants and no more after, because if instead you keep the proportion of builder constant over time and over factories, the number of units over time is more like t^3: the first factory taking time to build, but the other factories getting built three at a time because you have more builders.
- Once all geos are covered, the number of factory stays constant, and they output units at a constant rate, so the number of units over time is like t.
Well, as time goes toward very long, the importance of the initial phase goes toward negligible, and so only the second phase where number of units over time is like t matters. But that is if we don't have mine!
Crap, as I reread myself, I just realise that the only factories you can build cannot build assemblers not bytes, which changes my growth rates calculations, so much for me trying to sound all important with my t vs t├âÔÇÜ├é┬▓. But bear with it, my point still holds anyway.
Now let's consider again with mine. If the factory are building bytes, which can't build mines, then the number of units over time is still like t. However, if the factory are busy building sockets which then build mines, then the number of units over time becomes t├âÔÇÜ├é┬▓: there's a constant flow of builders, and each become a new constant source of mines.
So, if a player builds bits, bytes, pointer, well, regular attack units, is number of units rise like t.
But if a player build assembler and mines, his number of units rise like t├âÔÇÜ├é┬▓.
No matter how underpowered and near useless the mines are, geometric progression will always win over linear progression, given enough time. So, on long term, building mines always becomes the best choice.
I think you already thought about it by now, and granted, in those consideration I neglected the fact that units also get destroyed in battle. So my reasonings only hold:
- If the map is very large.
- If both player decide to porc.
- If you build up in the back of your base.
- If the game last very long.
Another way to handle it would be to consider that anyway both player are busy killing units, and that the battle and killing us just what happens to unit already built, and that you just have to consider that "unit over time" means "total units built and destroyed since game started" instead of "current unit count". But in my reasonings I considered assmebler built forever, without ever dying in combat, so that only works if builder and factories doesn't participate in the battle and only bit, bytes, pointers and mine do. But then the player getting more assembler will get less attack unit and so won't be able to hold against someone building more attack unit, so this doesn't hold. So if there is battle, the difference between going asm+mine or going assault units isn't linear vs geoemetric. Nevertheless, still, even in a normal game with battle, if you manage to spare one byte, after two hour you only that one byte, but if you manage to spare one assembler, after two hour you get one assembler and a gigantic battefield, so going asm+mine still wins on long term. Just as quickly as geometricly.
Oh, and this is a Kernel Panic specific problem, because in a normal, TA-like mod, you don't have that loophole because:
- A cons that has nothing else to do could be busy building solar, metal maker and factory. Or it could be busy assisting a factory. Or a myriad other use, that are unavailable for a kernel panic assembler.
- Like above show, there's a hundreds other opportunities for infinite growth. Mass mine churning is not the only one.
- Mines have cost. So each mine you build, is one less peewee you could have built with the same metal/energy/builpower.
- Each mine consume energy, which make likes an upkeep. Ok you could consider {mine + fusions} so this isn't the strongest argument.
- Mines can only be built by specific mine builder. Yes, when you decide to build a mine layer, it should be making mines till death come. But usually you build regular cons, which can't build mine, and only get a mine layer when you invest in one in the intend to make mines. You don't get mine building available for free on every cons.
And also, I don't have that problem with walls, because:
- Walls aren't units. To me, they are, like, changes of the terrain.
- Walls can't kill units.
- Even if you covered the whole map with walls, bytes move through walls with so much ease it wouldn't be an issue.
- I actually would be happy if players covered 90% of the map space with walls. I'd say w00t, terraforming, cool!
Of course, the reasoning that geometric growth always win over linear growth given enough time only impact the game if the "given enough time" condition is met. A regular kernel panic being over in less than 10mins, it doesn't matter if after two hour you can make a terrific come back with minefields if you lose under the five minutes mark. This is whay I said my concern with mines is based upon theorical/philosophical consideration, and not upon pratical experience of games played.
For actual game, the geometric growth rate of mass mines means one thing: Kernel Panic can only be balanced for a certain game scale:
- If Kernel Panic is well balanced for small scale, then mines becomes overpowered for larger map / longer games.
- If Kernel Panic is well balanced for big map / long game, then mines becomes underpowered for small maps.
As long as we consider Kernel Panic is only to be played on Marble Madness, or similarly sized maps, this is not an issue. But if we want Kernel Panic to play well across diverse scale, then the mines will be an issue. The other issue being that kernel can't be built (spare me why it's an issue while commander unbuildable in TA mods isn't an issue, this should be obvious enough).
By the time I devised such a lenghty exposition of the issue, of course I add time to sparkle an idea of how to solve "the problem with mines in KP":
- Make mines die over time. Each mine would have an internal timer, and after a given amount of time, would self destruct. I believe that in Spring, combining "force spawning a shot in the script", and "shot affect who fired it" allows use to have scripted self destruct. Heck, anyway, KDR_11k already scripted mines to self D when all other units are done, so no point in arguing that unit can be scripted to self D. Anyway, by having mines self destruct after a given time, and by making mines taking loooong to build, we can make it so an assembler constantly busy making mines can not have more than 10 alive mine at a time. Or 8, or 12, or whatever number, which anyway also depends a bit on how far those mines are. Of course, the mine self destruct should harmless, only the regular detonation through enemy proximity should cause damage. Ironically, I think the kamikaze deal their self destruct explosion, while the "killed by a weapon spawend by self" would trigger the regular explosion, but anyhow, enough sidetracking. Assembler would be "Assembler + 0.2*t mines", t being the time, making assembler power grow toward infinity over time, but "Assembler + 10 mines", that remains nicely finite, and even damn close to simply "assembler", no matter how much time has flown. That means that asm having nothing else to do wouln't be building endless minefield, but would be constantly rebuilding the same 10-mines minefield. The added micro is not a problem once you realise Spring has a "repeat" button. A tiny problem would be that's it's unreliable, you never know at which point of the minefield rebuilding cycle the enemy would come, so if you need a mine precisely on that spot, you can't be sure the mine will be there and ready, under construction, or just self removed. A much bigger problem would be that seeing a busy assembler and shiny construction laser show, going forever in an area, would give quite a hint to the enemy which of you area are mined.
- So instead of making mine die over time, maybe we could use some Z-class heavy scripting on the assembler, that make it so as soon the assembler starts building an eleventh mine, it auto-forcibly-fire a focused anti-mine shot right into the first mine, effectively making it so making new mines kills old mines, but not making new mines let old mines live. The idea that immediatly pop to mind would be to make mines die when their assembler father die, but I'd rather have them remain. Let's just consider that instead of buying an assembler, you buy {1 assembler + 10 virtual mines}, and that killing the assembler doesn't kill the mines.
========================================
========================================
About balance:
First, let's clear up what the role are. To me, it seems obvious that the role should be:
- assembler: it's a builder, not an attack unit!
- bit: cheapest unit, very weak both in weaponary and armor. Fast, expendable, near harmless, and numerous, to make it a good scount. Dies in seconds and can't deal much damages, so is only good for combat when en masse. Or when the enemy offers no opposition.
A key point of the bit is that they are the only unit socket can make. This mean that even if the bit were completly underpowered, they would be still be built en masse. Meanwhile kernel would be solely build byte and pointer. So you would have every unit present in fair amount on the battlefield, and so KP would be balanced. However, should bit be overpowered, then socket would still only make bit, but so would kernel, and there would be only bits and bits, no byte nor pointer. Therefore, to be balanced, bits should be underbalanced!
- byte: I see them as mmorpg tanks, slow, heavily armored, and with a short ranged weapon. Kinda like an OTA dt'ed HLT, but mobile. Good for spearheading assault, and for killing other attack units. Excelling at soaking damage.
- pointer: I see them as long range damage dealer, but frail and unable to cope with close combat. So long range, heavy damage, but very low armor, and inability to hit fast moving target or close target. Good against buildings or tighly packed group of immobile units. Die surprisingly fast when under fire. Like an archetypal arty unit, since they look like one they should be one.
KDR_11k complained that I upped the byte armor. He said that I made bytes able to stand on their own, while before they had to be supported by bits. First, I must point that I only increased the hp from 7000 to 9000, not such a cataclysmic change. Then, I will say, that for once, the change was dictated by actual gameplay experience. When playing harbl, whoever whose smurf it is, I noted that while I was striving to build one byte in my kernel, his kernel had time to build a small horde of bits. And then, when my byte went out, it was killed in seconds by like 3-4 bits. It seemed bad to me that you could spam much more bits than it took to take a single byte for the same buildtime. Today I just looked at the figure, and found out, that for the buildtime of one byte, you can get 15 bits. This meant that to be balanced, a single byte should win against 15 bits.
"Win" because:
- 7 bits win against a half built byte, more generally, the more investement and the less unit count, the more power/cost the ratio should be, to compensate for the investment and for the inability to split a big unit.
- Like I said above, bits must be underpowered to be balanced.
Now, I think everybody who played a bit Kernel Panic can tell it takes much much less than 15 bits to kill a byte.
If you look at number, actually my bump to byte health give them just as many hitpoint as 15 bits. (But, yet, because of overkill, 15 bits still can soak more damage than one byte.)
I haven't looked at weapons numbers, but from what it feels ingame, I say 15 bits have much more combined firepower than one single byte.
KDR_11k said the pointer is also very good against moving unit, thanks to its shot tracking. I think that if so, then we kinda lose the arty role there. If all units are all good against the same target, then all units compete for the same role, and only the best units remains, only by giving specific role we can hope to have all units useful. Also, I looked at it, but admit I didn't really understood the nature of the pointer shot. Is it an xta-raven-style drunk fire rocket, only without the innaccuracy, and with a heat seeker head? Is it a ballistic shell that use some new and strange tags to make it ignore gravity and always arc the same? I admit I sound like a fool, pretending to balance better than KDR_11k the weapons he designed, while I don't even understand crucial point like whether they track or not. I'm not sure saying it's pretty hard to notice tracking ingame is an excuse. Anyway, the thing I know, is that I like the current pointer shot speed, because it makes that nice trail. If the shot is faster, then, like in KDR Edit 8, you only see a rainbow going from pointer gun to target, but you don't get to see the actual shot moving through the air. Also, faster shot like in KDR Edit 8 make it almost instahit, which remove the whole "cannot hit moving target" that makes the specificity of artillery. If the shot was slower, then its trail would be shorter, and not as nice. Yeah again I sound like a fool basing balance defining values upon look, but I feel that there is enough other parameter avaialable that we can still balance it all we want even with shot speed fixed. Anyway, enough foolery for now.
========================================
========================================
========================================
Stuff I would do for KP 1.1 if I were doing a KP 1.1 but anyway I won't ever have the time to:
- The bit laser looks like a corrupted texture. Ok actually, it's not, when you look very close, you see it's an attempt at imitating old school vectorial style graphic, but I still find this shot is not as pretty as it should be. KDR_11k told me he couldn't keep continuous laser because Spring handling of continuous laser is hacky and buggy and specifically, they can't use the tag to pass through friendly. However, an important aspect of 0.7 bit weapon that is lacking in 1.0 is to see that a bit is firing, and what it is firing at. For the gameplay, it is important to see which bit is firing and at what. With 0.7 bit weapon it was clear, but with current bit weapon we can't. I think we can still keep a regular non insta small shot for bit, but solve the issue by having a bright elongated lasting flare when a bit fire. Bright and lasting so we get time to see it, and elongated so we can see precisely which way it points.
- The bytes weapon has abruptly cut start and end. I know previously there was an issue with a gap between the middle of the byte laser and the round start or end, but I don't think the current sharp cut is a solution. What about putting round ends on the main central segment texture, with alpha? We can specify which texture to use for laser or at least lightening rendertype weapons, no?
- I made the asm crusher class, because I thought "anyway builder can reclaim wall, so it might as well crush them and save on the micro". But now I realise that asm risk to also crush the walls they just built when moving around, which is not good, so I should revert it to not crushing and stop trying to undo what KDR_11k did with good reasons. Also, while I was busy fiddling with movementclass, I was surprised to see units with different footprint sizes use the same movementclass. Can someone confirm that movementclasses are independant of footprint sizes?
- I should run Gimp, open losange.tga, change canvas size to make it square, check that added left and right column are transparent, and save, so that the byte icon use an elongated losange instead of a square-on-tip. BTW, the "default" icon doesn't work, Spring keep using the hard coded round dot for default. Not that it matters anyway.
- Rename logic_bomb.jpg into logic_bomb.bmp, like TradeMark told me to.
- The wall are ridiculously short. Ok, it's because KDR_11k found that while tall feature only collide with the footprint, they prevent firing through the whole hitsphere. But I hope that if so dev will soon fixe Spring source, so that I can have walls tall enough to block shots, because right now, KP walls are pityfull: shots passes over, bytes remove them simply by touching them, ...
- I still don't like the mines, the anti-mines, and the walls. Because of the nature of Kernel Panic gameplay, where the only way to gain the upper hand is to take care of your unit instead of wasting them in wasteful assault, because how once geo are covered the only thing to keep cons busy is to build mines or walls (so basically, it makes it so you have to build free mine instead of letting cons idle, cuz mines free and cons has nothing better to do), because cloacked mine have the potential to slow game into boring minesweeping, the very reason while mine warfare was removed from supcom btw, (but granted at least KDR made a minesweeper mine and coded mine to self D when no other unit exists), and because the whole mine and antimine mess detracts from Kernel Panic simple is beautiful concept, I'm afraid of mines. I would like comments from people who have used mines and walls about that issue, because maybe it's just myself that has ignored them in all games I played and so didn't realise the new tactics and fun they offered. The rest of my mine text has grown too overlong, so I moved the rest of it below.
- Kernel Panic is filled with custom damage between about every kind of unit, and I don't like that. It prevents player from getting an intuitive feel of the game if shots do surprise extra damage against some unit with not visible reason, so I would like to remove as much custom damage use, however this must be done with care to not throw the balance upside down. Oh and course some custom damage, like the minesweeper extra damage against mines and features, are ok, since they're frank and clearly labelled, and anyway they're more a technical workaround to remove certain unit that a real weapon vs unit damage table.
- The CPU race is lacking its lobby icon. Any idea? I was suggested a microchip, sounds fitting.
- I should add that paragraph in modinfo so that NTai can use the same profile as Kernel Panic versions change. BTW, how do other AI know which mod is being used? And are there any other AI that works with Kernel Panic, or other any makers planning to support Kernel Panic? With so few and archetypal units, so null ressource management, and only a single map to worry about, Kernel Panic could provide AI coders a nice playground to worry more about attack movement, grouping, retreating, leavy arty in back, without all the hassle of dealing with hundreds units, hundreds maps, and complex economic system full of traps.
- Yesterday I add an idea: let's give the Kernel a shield, a bouncing shield cuz bouncy is funnier, that is so powerful it can reflect all shots, is solid so even if you drive inside you still can't shoot, but, consume tremendous amout of energy. Then let's make it so sockets, but only sockets, produce even more energy. That way, the kernel will be invulnerable until all socket are destroyed, a bit like UT2K onslaught. I always disliked how a couple bits are enough to pin down your kernel, destructing units inside before they are completed.
- Attempt to solve the starting position bias with some heavy scripting in the kernel.bos, if the issue doesn't get solved by Spring source code before.
- I'm still not sure about socket being commanders. Shouldn't only the kernel be commander? (commander as in: must kill all commanders to win in commander death end games). I understand the reasoning behind "as long as you have on factory, there's hope, but when you lose all factory, game's virtually over), but it just sounds more natural to me that in comm death end, it's the first unit that mattersd, especially considering how in Kernel Panic said first unit is actually much more important than any other. I mean, in game like EE when you start with a lowly builder, comm death end makes no sense so let's use it for something else, but for KP, "protect the kernel" makes more sense and seem more natural than "protect the uber kernel or any lowly socket".
- For more long term plans:
- There's still a very cool KP map concept I had in my head that I really wanna do.
- I'd like to come up with interesting idea about how to use water. Which won't look as water but as a strange texture under which unit get strange properties. But more thought must be put into it.
- Make kernel buildable, maybe if possible on four geo spot, or maybe use some maxslope tweak so they use other areas than socket, or if nothing else work, script them, or sockets, to jam if metal_extraction < some_threshold (if socket were buildable on metal spot, and kernel on geo, kp would become playable on most maps). Because it annoys me that even if the map was large and the game went for long, each player could still only have a single factory producing other than bits.
- Virii race! (Don't bother putting any thought, will never get that far.)
========================================
========================================
Hmm, I think I haven't well explained why I have that problem with mines. Well, first, we all agree that something > nothing. So, considering that assembler cannot heal*, cannot reclaim-attack*, cannot assist, and cannot build more factory once all geos are covered, they are better off buildings mines than standing still, doing nothing, right? (*: not sure of those two). So we can assume that for fairly competent players, all assemblers will be churning mines once they're done with making sockets. Now, let's consider a byte. Leave it alone for 5 mins, you still have one byte. Leave it alone for days, you still have just a byte. Now, let's take an assembler. Leave it alone for 5 minutes, you get a small minefield. Leave it alone for half an hour, you get a huge minefield. Leave it alone for days, you get the whole map covered by mines. See the problem? The power of assembler augments over time, while the power of attack units don't. It seems to me like a free infinite growth loophole.
Some idiots might retort that since every unit is free, why do I have only a problem with free mines and not the free other unit, but this doesn't hold, because:
- Yes it should be every player aim to cover the map with his units and factories. But not to cover the map with mines! You can't cover the map the factories, because sockets are limited by the number of geos. As for units, well, the output flow is constant once you reach max socket, while mine flows keeps ... err sorry I need to adopt a more mathematised standpoint:
- During the intial growth phase (between start game and last geo getting covered), the number of factories augment linearly over time, and the number of units per factory augment linearly over time, so the the function "number of units over time" is like t├âÔÇÜ├é┬▓. Well, actually, that's if you build a couple builder the first instants and no more after, because if instead you keep the proportion of builder constant over time and over factories, the number of units over time is more like t^3: the first factory taking time to build, but the other factories getting built three at a time because you have more builders.
- Once all geos are covered, the number of factory stays constant, and they output units at a constant rate, so the number of units over time is like t.
Well, as time goes toward very long, the importance of the initial phase goes toward negligible, and so only the second phase where number of units over time is like t matters. But that is if we don't have mine!
Crap, as I reread myself, I just realise that the only factories you can build cannot build assemblers not bytes, which changes my growth rates calculations, so much for me trying to sound all important with my t vs t├âÔÇÜ├é┬▓. But bear with it, my point still holds anyway.
Now let's consider again with mine. If the factory are building bytes, which can't build mines, then the number of units over time is still like t. However, if the factory are busy building sockets which then build mines, then the number of units over time becomes t├âÔÇÜ├é┬▓: there's a constant flow of builders, and each become a new constant source of mines.
So, if a player builds bits, bytes, pointer, well, regular attack units, is number of units rise like t.
But if a player build assembler and mines, his number of units rise like t├âÔÇÜ├é┬▓.
No matter how underpowered and near useless the mines are, geometric progression will always win over linear progression, given enough time. So, on long term, building mines always becomes the best choice.
I think you already thought about it by now, and granted, in those consideration I neglected the fact that units also get destroyed in battle. So my reasonings only hold:
- If the map is very large.
- If both player decide to porc.
- If you build up in the back of your base.
- If the game last very long.
Another way to handle it would be to consider that anyway both player are busy killing units, and that the battle and killing us just what happens to unit already built, and that you just have to consider that "unit over time" means "total units built and destroyed since game started" instead of "current unit count". But in my reasonings I considered assmebler built forever, without ever dying in combat, so that only works if builder and factories doesn't participate in the battle and only bit, bytes, pointers and mine do. But then the player getting more assembler will get less attack unit and so won't be able to hold against someone building more attack unit, so this doesn't hold. So if there is battle, the difference between going asm+mine or going assault units isn't linear vs geoemetric. Nevertheless, still, even in a normal game with battle, if you manage to spare one byte, after two hour you only that one byte, but if you manage to spare one assembler, after two hour you get one assembler and a gigantic battefield, so going asm+mine still wins on long term. Just as quickly as geometricly.
Oh, and this is a Kernel Panic specific problem, because in a normal, TA-like mod, you don't have that loophole because:
- A cons that has nothing else to do could be busy building solar, metal maker and factory. Or it could be busy assisting a factory. Or a myriad other use, that are unavailable for a kernel panic assembler.
- Like above show, there's a hundreds other opportunities for infinite growth. Mass mine churning is not the only one.
- Mines have cost. So each mine you build, is one less peewee you could have built with the same metal/energy/builpower.
- Each mine consume energy, which make likes an upkeep. Ok you could consider {mine + fusions} so this isn't the strongest argument.
- Mines can only be built by specific mine builder. Yes, when you decide to build a mine layer, it should be making mines till death come. But usually you build regular cons, which can't build mine, and only get a mine layer when you invest in one in the intend to make mines. You don't get mine building available for free on every cons.
And also, I don't have that problem with walls, because:
- Walls aren't units. To me, they are, like, changes of the terrain.
- Walls can't kill units.
- Even if you covered the whole map with walls, bytes move through walls with so much ease it wouldn't be an issue.
- I actually would be happy if players covered 90% of the map space with walls. I'd say w00t, terraforming, cool!
Of course, the reasoning that geometric growth always win over linear growth given enough time only impact the game if the "given enough time" condition is met. A regular kernel panic being over in less than 10mins, it doesn't matter if after two hour you can make a terrific come back with minefields if you lose under the five minutes mark. This is whay I said my concern with mines is based upon theorical/philosophical consideration, and not upon pratical experience of games played.
For actual game, the geometric growth rate of mass mines means one thing: Kernel Panic can only be balanced for a certain game scale:
- If Kernel Panic is well balanced for small scale, then mines becomes overpowered for larger map / longer games.
- If Kernel Panic is well balanced for big map / long game, then mines becomes underpowered for small maps.
As long as we consider Kernel Panic is only to be played on Marble Madness, or similarly sized maps, this is not an issue. But if we want Kernel Panic to play well across diverse scale, then the mines will be an issue. The other issue being that kernel can't be built (spare me why it's an issue while commander unbuildable in TA mods isn't an issue, this should be obvious enough).
By the time I devised such a lenghty exposition of the issue, of course I add time to sparkle an idea of how to solve "the problem with mines in KP":
- Make mines die over time. Each mine would have an internal timer, and after a given amount of time, would self destruct. I believe that in Spring, combining "force spawning a shot in the script", and "shot affect who fired it" allows use to have scripted self destruct. Heck, anyway, KDR_11k already scripted mines to self D when all other units are done, so no point in arguing that unit can be scripted to self D. Anyway, by having mines self destruct after a given time, and by making mines taking loooong to build, we can make it so an assembler constantly busy making mines can not have more than 10 alive mine at a time. Or 8, or 12, or whatever number, which anyway also depends a bit on how far those mines are. Of course, the mine self destruct should harmless, only the regular detonation through enemy proximity should cause damage. Ironically, I think the kamikaze deal their self destruct explosion, while the "killed by a weapon spawend by self" would trigger the regular explosion, but anyhow, enough sidetracking. Assembler would be "Assembler + 0.2*t mines", t being the time, making assembler power grow toward infinity over time, but "Assembler + 10 mines", that remains nicely finite, and even damn close to simply "assembler", no matter how much time has flown. That means that asm having nothing else to do wouln't be building endless minefield, but would be constantly rebuilding the same 10-mines minefield. The added micro is not a problem once you realise Spring has a "repeat" button. A tiny problem would be that's it's unreliable, you never know at which point of the minefield rebuilding cycle the enemy would come, so if you need a mine precisely on that spot, you can't be sure the mine will be there and ready, under construction, or just self removed. A much bigger problem would be that seeing a busy assembler and shiny construction laser show, going forever in an area, would give quite a hint to the enemy which of you area are mined.
- So instead of making mine die over time, maybe we could use some Z-class heavy scripting on the assembler, that make it so as soon the assembler starts building an eleventh mine, it auto-forcibly-fire a focused anti-mine shot right into the first mine, effectively making it so making new mines kills old mines, but not making new mines let old mines live. The idea that immediatly pop to mind would be to make mines die when their assembler father die, but I'd rather have them remain. Let's just consider that instead of buying an assembler, you buy {1 assembler + 10 virtual mines}, and that killing the assembler doesn't kill the mines.
========================================
========================================
About balance:
First, let's clear up what the role are. To me, it seems obvious that the role should be:
- assembler: it's a builder, not an attack unit!
- bit: cheapest unit, very weak both in weaponary and armor. Fast, expendable, near harmless, and numerous, to make it a good scount. Dies in seconds and can't deal much damages, so is only good for combat when en masse. Or when the enemy offers no opposition.
A key point of the bit is that they are the only unit socket can make. This mean that even if the bit were completly underpowered, they would be still be built en masse. Meanwhile kernel would be solely build byte and pointer. So you would have every unit present in fair amount on the battlefield, and so KP would be balanced. However, should bit be overpowered, then socket would still only make bit, but so would kernel, and there would be only bits and bits, no byte nor pointer. Therefore, to be balanced, bits should be underbalanced!
- byte: I see them as mmorpg tanks, slow, heavily armored, and with a short ranged weapon. Kinda like an OTA dt'ed HLT, but mobile. Good for spearheading assault, and for killing other attack units. Excelling at soaking damage.
- pointer: I see them as long range damage dealer, but frail and unable to cope with close combat. So long range, heavy damage, but very low armor, and inability to hit fast moving target or close target. Good against buildings or tighly packed group of immobile units. Die surprisingly fast when under fire. Like an archetypal arty unit, since they look like one they should be one.
KDR_11k complained that I upped the byte armor. He said that I made bytes able to stand on their own, while before they had to be supported by bits. First, I must point that I only increased the hp from 7000 to 9000, not such a cataclysmic change. Then, I will say, that for once, the change was dictated by actual gameplay experience. When playing harbl, whoever whose smurf it is, I noted that while I was striving to build one byte in my kernel, his kernel had time to build a small horde of bits. And then, when my byte went out, it was killed in seconds by like 3-4 bits. It seemed bad to me that you could spam much more bits than it took to take a single byte for the same buildtime. Today I just looked at the figure, and found out, that for the buildtime of one byte, you can get 15 bits. This meant that to be balanced, a single byte should win against 15 bits.
"Win" because:
- 7 bits win against a half built byte, more generally, the more investement and the less unit count, the more power/cost the ratio should be, to compensate for the investment and for the inability to split a big unit.
- Like I said above, bits must be underpowered to be balanced.
Now, I think everybody who played a bit Kernel Panic can tell it takes much much less than 15 bits to kill a byte.
If you look at number, actually my bump to byte health give them just as many hitpoint as 15 bits. (But, yet, because of overkill, 15 bits still can soak more damage than one byte.)
I haven't looked at weapons numbers, but from what it feels ingame, I say 15 bits have much more combined firepower than one single byte.
KDR_11k said the pointer is also very good against moving unit, thanks to its shot tracking. I think that if so, then we kinda lose the arty role there. If all units are all good against the same target, then all units compete for the same role, and only the best units remains, only by giving specific role we can hope to have all units useful. Also, I looked at it, but admit I didn't really understood the nature of the pointer shot. Is it an xta-raven-style drunk fire rocket, only without the innaccuracy, and with a heat seeker head? Is it a ballistic shell that use some new and strange tags to make it ignore gravity and always arc the same? I admit I sound like a fool, pretending to balance better than KDR_11k the weapons he designed, while I don't even understand crucial point like whether they track or not. I'm not sure saying it's pretty hard to notice tracking ingame is an excuse. Anyway, the thing I know, is that I like the current pointer shot speed, because it makes that nice trail. If the shot is faster, then, like in KDR Edit 8, you only see a rainbow going from pointer gun to target, but you don't get to see the actual shot moving through the air. Also, faster shot like in KDR Edit 8 make it almost instahit, which remove the whole "cannot hit moving target" that makes the specificity of artillery. If the shot was slower, then its trail would be shorter, and not as nice. Yeah again I sound like a fool basing balance defining values upon look, but I feel that there is enough other parameter avaialable that we can still balance it all we want even with shot speed fixed. Anyway, enough foolery for now.
========================================
========================================
The pointer weapon is a missile with TrajectoryHeight=1, like the missiles in E&E or artillery in Gundam. Its old speed was somewhat based on the AT guns in Company of Heroes, it just arced because unlike CoH Spring has terrain that can block shots.
Assemblers can repair, they're not as good in Edit 8 as Edit 6 or 7 (not sure which) but that's because 2-3 assemblers could repair a byte faster than an army could damage it in that version. Also the "game of minesweeper" is greatly reduced since assemblers see mines and can debug them to clear a minefield pretty fast (or let bytes shoot at them). On a map like AzureRampart you often see mines used but they aren't a major power, they help a bit with the frontline by killing some advances but usually a small number of bits will run into them first, often setting off two to three mines at once. Assemblers can only fortify your own territory, you won't see them mining the frontlines while a battle is taking place, at least not for long.
Personally I see bytes as armored nukers, they do area damage and often hit a whole swarm of bits at the same time but their weapon is kinda slow so they aren't as evil against swarms as, say, Gundam's Gundams. They are very useful fire support though since an army of bits that went through some byte fire won't be able to take much more damage and will fall prey to other bits easily even though the byte won't be able to finish them off nearly as quickly.
I think the current shots make it clearer what's shooting at what, the beamlasers made it hard to see which bit was shooting and which was getting shot.
Assemblers can repair, they're not as good in Edit 8 as Edit 6 or 7 (not sure which) but that's because 2-3 assemblers could repair a byte faster than an army could damage it in that version. Also the "game of minesweeper" is greatly reduced since assemblers see mines and can debug them to clear a minefield pretty fast (or let bytes shoot at them). On a map like AzureRampart you often see mines used but they aren't a major power, they help a bit with the frontline by killing some advances but usually a small number of bits will run into them first, often setting off two to three mines at once. Assemblers can only fortify your own territory, you won't see them mining the frontlines while a battle is taking place, at least not for long
.Personally I see bytes as armored nukers, they do area damage and often hit a whole swarm of bits at the same time but their weapon is kinda slow so they aren't as evil against swarms as, say, Gundam's Gundams. They are very useful fire support though since an army of bits that went through some byte fire won't be able to take much more damage and will fall prey to other bits easily even though the byte won't be able to finish them off nearly as quickly.
I think the current shots make it clearer what's shooting at what, the beamlasers made it hard to see which bit was shooting and which was getting shot.
1) don't like the idea of UT-Ons-style gameplay. I don't like the idea that defending the Kernel is optional once you've got sockets. I'd rather see the Kernel just get some defenses or something - for example, let the Kernel instabuild a big bomb that will isntantly destroy everything nearby, or a big turret. Either way the problem is that, because the Kernel must do it and it blocks the exit-port, it means the Kernel must cease production for a moment - so if you don't have any other Sockets that can build units that come to the Kernel's rescue, the Kernel Defense will only provide a momentary repreive.
2) I have a solution to mines: make them big, expensive nuke-mines, and temporary (they have negative regen and self-destruct over time). Thus, using a mine is a gambit, and you can't flood the map with them either. Then remove minelayers - the way to set off a mine is to send out a single Bit to detonate it. Otherwise, mines are an annoying secondary RPS gameplay feature, or redundant with walls.
3) No matter what walls will have the same "exponential growth" problem that mines did (although less worrisome since walls are physically harmless) so at least one unit needs to be able to get rid of them quickly - even if that's just a quick reclamation time for the assembler.
2) I have a solution to mines: make them big, expensive nuke-mines, and temporary (they have negative regen and self-destruct over time). Thus, using a mine is a gambit, and you can't flood the map with them either. Then remove minelayers - the way to set off a mine is to send out a single Bit to detonate it. Otherwise, mines are an annoying secondary RPS gameplay feature, or redundant with walls.
3) No matter what walls will have the same "exponential growth" problem that mines did (although less worrisome since walls are physically harmless) so at least one unit needs to be able to get rid of them quickly - even if that's just a quick reclamation time for the assembler.
in the time it took you to write that, you could have implemented three of the mentioned pointszwzsg wrote:lots and lots of words
in all honesty, i think you make good points and i really wish you could spend some time working on kp in the future.
personally, i think that before all else we need more maps. playing on marble madness is getting boring. when we have like 5 or six maps, we can tackle gameplay tweaks.
Question - instead of scripting an assembler to only allow 10 mines per assembler (a lot of scripting!), just limit the number of mines a player can have to say... 20 or 30. Much less scripting, and also removes the need for mines to slowly degen (which is sort of ugly and microtastic compared to the simplicity of the rest of the mod.