Now playing

Now playing:

Penguin Cafe Orchestra/, Fight Club (Soundtrack)/, Tron 2.0 Theme, (Odd that I find this helps me focus), Schoene Blaue Danube, Vindaloo, Fatboy Slim – Praise You, Blur – Song 2, Shakira/Britney/Beegees QMix

Code in progress:

  // Check the population of hulks in the zone around this 
  // hulk's grid, tracking which cell has the highest count so that 
  // we can pull an older hulk if population limits are reached.  
  GridKey key(gx, gy) ;  
  ChatGrid& cell = _chatGrid[key] ;      

  if ( _countHulks(cell) > wwii_config.stosHulkLimitPerCell )  
    _popHulk(cell) ;     

  // Setting shlpa to zero disables this functionality  
  if ( wwii_config.stoHulkLimitPerArea <= 0 )  
    return ;     

  // Start with the assumption ours will be highest populated  
  ChatGrid& highestPopulatedCell = cell ;      

  // Iterators/counters for the loop  
  NEIGHBORS::iterator nIt ;  
  STOS::iterator sIt ;  
  UINT32 hulksInArea ;      

  for ( nIt = cell.neighborhood().begin()  
      ; nIt != cell.neighborhood().end()  
      ; ++nIt )  
    ///TODO: Track the highest populated neighbor, count  

  // Are we worried about population counts?  
  // NOTE: shlpa values can go down as well as up, so  
  // don't assume we'll never be more than 1 over  
  // (hence while instead of if)  
  while ( hulksInArea > wwii_config.stoHulkLimitPerArea )  
    _popHulk(highestPopulatedCell) ;  
    --hulksInArea ;  


PS – You get to look at it before the compiler does ;)

Looks good to me, but I had all my error warnings turned off at birth.

I read once that the best concentration music is actually reggae. I’ve done my own testing and found it to be true. I get generally higher scores on Tetris and Zuma listening to reggae than any other music that I tested.


should that last line be

–hulksInArea ?

And shouldnt you clean up every cell that is over headcount, in case the max_value is turned down server side to account for too much traffic?


stupid font.

i meant
– – hulksInArea

but obviously it renderes two -‘s as one long..

I gave up trying to persuade WordPress to render “- -” as two dashes and not one.

Besides, that’s the code in progress. The actual final code will be significantly different, but I always build an initial frame function to extrapolate from. Sometimes you get lucky and that drops into place and works. In this case it won’t because I actually have to split the process up across a bunch of different entry points.

It’s an annoyingly simple-but-tricky problem, that’s usually a neat little undertaking. If I’d known last week or even on Monday I was going to be working on this, I’d be enjoying this. But since I only found out yesterday (a) that it’s on the todo list, (b) the deadline was yesterday, it’s already late, and I’m not getting the least bit of pleasure from having to write code that only uses as much effort as it has to, because I don’t rate my chances of success at getting it right by designing-by-coding very high. I’m either going to expend too much effort (big cpu spike) or too little (‘why dont the hulks go away when I do this?’)

Well, that sounded a little more angry than it should.

I’m temporarily disgruntled because I don’t like having to “discover” the nuances in a feature rather than have a day or two to figure them *before* I start coding. And this feature is full of variables, which leaves me flopping like a wet fish. I have to code up a bunch of stuff before I can see the constraints on those variables, which invariably then means rewriting bits of it.

And then I’m annoyed because after derailing me with this, when Killer/Gophur saw how genuinely irritated I was yesterday, they said “Well, you could say nows not a good time”. ARGH.

Anyway. I think I have it worked out now, so I need to start working on my test harness for it.

Time for Nightmares on Wax…

I’d think it’d be neat in the event of hulk overpopulation to be able to pull one from the nearby cell with the *lowest player population*, not the cell with the *highest hulk population*.

Pulling hulks from the vicinity of players would continue the disruptive and anti-immersive aspects of despawning, i.e. “that object over there just disappeared.”

Getting rid of visually prominent object disappearance has always seemed to me to be one of the nicest benefits of the hulk concept.

Cells are 512x512m. You can see 36 of them. We are setting limits per cell and per area – an “area” being the 6x6km area of cells that you can see. “Areas”, naturally, overlap.

So trying to do it by player population is a total no-no. Of the 6 reasons I can think of, off the top of my head, consider a typical tank battle fighting between two positions. Hulks will accumulate at the positions, but any hulks that form between will tend to pop very quickly – ergo you will tend to *notice* hulks dissapear more often.

I want hulks to be fair and visible to all. I don’t want one of two players not to be able to return fire because he’s the only one that sees that hulk.

And when you’re dealing with areas like that, saying “in” is a very, very crude measure. A fight moves to the edge of town, the defenders are in cell(10,15). 600m away (10,16) there are a bunch of you hiding behind a friendly tank which gets hit, destroyed and despawns, and his hulk vanishes and you all get killed. Why? Because there were more of them, so it didn’t delete the ET hulk on the other side of the block of buildings they are infront of. (So none of you can see it).

and the top of the remove-old-hulks will be is hulks has a score of units (enemies and friendlyes) near them, and the ones with less score are removed first. Conclusion: hulks that are nothing to anybody are removed first, and hulks with units hidden are there more time…

Check units around 10 meters around a hulk (you can even score 1 per inf, or 3 per tank, 5 per ATG,…). If a unit has 0 score, no one is around it, so it is a first candidate to be removed. A hulk with 3 inf behind and a poor ATG should stay longer.

Of course it is harder to program than a FI-LO pool, but it is cooler too.


Define “near”?

Are guys standing on top of the hill at dinant facing east “near” a hulk 2m away from them (x,y) but at the bottom of the cliff, which it is impossible for them to see?

If you are “near” two hulks, one 5m away, the other side of a berm, that you can’t see, and another 9m away, that you are facing and looking at, which one gets the score of 0?

Complex but incomplete rules are a fantastic way to crush immersion, and if they are sufficiently complex, typically work out worse than simpler, arbitrary rules.

The chat grid system knows your x and y position. It is terrain, LOS, heading, orientation, and vehicle-specifics unaware.

Sorry for my english, maybe I didnt explain myself…

Every HULK has a score of 0, add 1 point per unit around him a 10 meter circle. After scoring we have:

Hulk.01 – 3:00 – 0 points
Hulk.02 – 4:00 – 0 points
Hulk.03 – 7:00 – 4 points
Hulk.04 – 1:00 – 9 points

Currently, your system remove first the oldest hulk, in this scenario, Hulk.03. Note that it has 4 score… maybe 4 inf (not necesary of the same country!) or 1 inf and 1 pak.

If you get scores, Hulk.01 and Hulk.02 are the ones with 0 score. As Hulk.02 has been longer than .01, remove .02.

The idea is to remove first the hulks in mid of nowhere (a tank destroyed 2.0 kms away of the city?) and leave the most used ones, as hulks near cities, used for infantry to hide or for Paks.

In my previous post I set 3 scores for tanks and 5 for ATG because I think it has more importante to keep hulks with hidden ATGs than hulks with tanks hidden, mainly because after all, a Tank does not hide very well behing a hulk :) and the extra cover is not as important as for ATGs.

Add 1 point per tank, 2 per EI and 3 per ATG.

In your example, both hulks scores for the inf at 5m and 9m.

More points in a hulk means that there is more people hidden in them and also that this hulks where in middle of combat, and so they are more important than a far away tank cutting resupply, where nobody cares about him or see him.

Maybe a max score for hulks is desirable (10 points?) so hulks on ABs (camped ones) do not live forever… or if they get MANY points (20?) they get 0 instead of 20, as this high score hulks probably will be in the middle of an AB on the final attack…

If the chat system already knows every unit position, use this info (1 point per unit) for hulks score. Maybe use the .whisper setting by default.

The main idea is to determinate which hulks are more important for the action and keep them longer than solo hulks.

The main idea is to determinate which hulks are more important for the action and keep them longer than solo hulks.

I understood you – and my point is that proximity is not a useful metric.

H1 P1 —-H2—- P2 H3

H = Hulk, P = Player

According to your system, H2 is not important, even though its inbetween the players.

So you’ve developed a complex, and expensive to execute, ruleset that has a very low success rate.

And because its complex, there will be patterns in it that players will be able to abuse.

Net result: It lacks sufficient fidelity to make it of greater value than a simpler system.

But you have to agree that a hulk in middle of a city with a inf hidden is much more important for the game/action that a hulk 2 kms away from the city that was destroyed when cutting ressuply or a hulk of a despawn user resupling (who had to leave…)

You can program the “system” and told the userbase (but me!) that they are a time system…

I really would hate to see a dessapearing hulk covering my inf due a new hulk of this far away destroyed tank…

New hulks will always superceed old hulks. I would hate to have the tank I am hiding behind destroyed and then dissapear because you have been hiding behind a hulk for 15 minutes.

“But you have to agree that a hulk in middle of a city with a inf hidden”

And how do you, programatically, detect that an infantry is “hidden” behind a tank?

What if there is a hulk either side of you, 2m away from you. Your system scores those hugely.

1km away, in the opposite direction to which you are looking, a friendly tank has just died. It’s hulk is obscuring the view that the enemy that killed him would otherwise have of you.

Which hulk should dissapear? The one keeping you alive? Or the two that the enemy can’t even see?

if newhulk=true
for n=1 to lasthulk
hulk.score=getunitaround(hulk-n) ;set scores per hulk
if hulk.score=limit then removehulk:removed=true:exit
;check if there is a low score hulk and remove if so
until hulk=last
until removed=true ;if no hulk removed, try next score…

Excuse my pseudocode (Im a basic programmer!) or if I sound pretencious…

My idea to make it simpler:

Everytime a new hulk comes (it does not happen every second!) the system calculates the scores of all hulks on the grid. Later, it check for the first hulk on the pool with score 0 (“less” important, and also, as being the first it was the oldest). If there is one with 0 score, remove it. If not, try with next value, 1, and so until a hulk is removed.

Maybe my idea is not the best, but maybe RATS at headquarter can think on a better system…

KFS1, you are defending a system “if we can not make a system good for all, we will make a system that is bad for all”. My system is “not good for all, but at least good for many”.

Well, talk at RAT HQ about the idea of somesystem to determine if a hulk is not very important (a lone hulk!) and so removed first and if it can be implemented.

I think it is fine if you dont do it because it will load servers or you have not time to introduce it, but as general, to determine if a hulk is not important is a good idea. The real problem is how to implement it.

All my post were my 2 cents. Now is time for Doc to earn his food! (dont let him read this!!!!)

AMpos: “the idea of somesystem to determine if a hulk is not very important”

I think that what kfsone is talking about is how the heck you would implement the ‘simple’ statement above. It implies a set of assumptions that make the algorithm not a trivial solution. Plus, add the complication of who defines a hulk as ‘important’. From one players perspective a hulk may be vitally important to his survival while that same hulk may be completely unimportant to someone relatively close.

I think we all might agree that a hulk in the middle of nowhere is, potentially, very unimportant when compared to a hulk in an immediate, heavily contested area but how do you code that in a straight forward manner.

Personally I’d go with direct hulk ages – older they are the earlier they are on the culling list. Infantry should never plan on a hulk being a semi-permanent fighting position.

Plus, I believe that kfsone’s other point was that if this was not quickly dumped on him, there could have been more time for a more through, sophisticated solution.

I’m glad that they are coming and that kfsone is sharing some of the design philosophy. As a coder myself I appreciate these educational posts the most :-)

How many hulks are too many?

If it’s a decent sized number, let’s say 10-20. Then why not put a mechanism in place to reward players or their side for removing a hulk? Allow trucks to tow hulks out of the way and despawn them when they are brought into the garage or something. Then give mission points, resource points, “Hulk” kill credit, or something that will make players want to get rid of hulks on their own.

This will solve the problem of the immersion killing aspect of these hulks despawning infront of your eyes, and at the same time bring a new dynamic of “Vehicle Recovery” to the game.

Then as a saftey measure remove hulks when no one is within 2km of them for those hulks that are created in the damnest places, or are just plain outright “Lost”.

What will be, will be. Certainly however the code functions, it won’t be worse than what it replaces, which is that every object disappears, many of them anti-immersively. Now only some of them will disappear anti-immersively.

Obviously, though, preventing hulks from disappearing that are being observed by players would be near the top of a list of ways to make the game more visually realistic.

If it’s conceptually impossible to do that in code in a practical way, I hope the problem is seen as needed solving in some other way.

For instance, if the limit on hulk-count is set by polys, by utilizing lower-poly models per hulk after they’ve been burning for a while.

Dark-gray-on-black, from ammo combustion soot, is a low recognition surface. Switching to a low-poly model when the fire goes out would seem pretty reasonable to me, especially if it considerably raised the max-hulk-population limit.

I would be great if the hulk could give some sort of “warning” before it despawned. Perhaps a burst of smoke or some such to let all those near know that the cover was about to go away.

I know, just another thing to pack into an already packed update system…

Hello, Darling.

I already posed this issue to Gophur. It’s in the Dev Q&A:

Q: … there needs to be a visual (and preferably an audio) cue as to when it will be disappearing from the gameworld. I would suggest the visual cue be smoke. As long as the vehicle is persistent, it will have smoke (of whatever degree) coming out of it. When it goes into the ‘disappearing’ que, it should stop smoking…

A: Nice solution. We’ll discuss that as we finalize the implementation plan.

Instead of proximity a field of view would be better. To bad all of that info is on the client side. :( The more people that can see the hulk the longer it persists. If you could track it you would still have to ask the question. Is it worth the cost in CPU cycles to calculate all of this? Or is a length of time a close enough approximation.

Considering that an infantry life is probably less than 10 min does it matter?

KISS. fixed length of time seems to be the easiest to implement given the constraints. Cheer up at least you have a few days. :)

I support an ERP. We had a meeting the other day, apparently marketing had a new customer incentive program. Communicated most excellently with the customers. We were an after thought. Some special volume discount needed to be added to the statements and the volume discount count started at the begging of the month and needed to be on this months statements.

We replied: the statements that went in the mail yesterday?

Response: mmmmm yes, can you do it?

“I already posed this issue to Gophur. It’s in the Dev Q&A:”

Sigh, I miss reading one Q&A…

Well, we can only conclude that great minds think alike.


“if we can not make a system good for all, we will make a system that is bad for all”. My system is “not good for all, but at least good for many”.

Nope, ampos. You’re thinking strictly in the box, from a single perspective. Your, expensive, solution is good for a few.

What I’m saying is that this is true for pretty much any system you come up with.

Take a moment to reflect on how just the two of us discussing this casually have already varied your ruleset massively. That indicates that your ruleset is neither simple nor complete enough to be worth using.

You’re assuming that most of the time people will be behind hulks. But that’s because you know where the enemy is when performing the mental experiment.

I’ve already explained several times now that “people near” is just not any better of a metric than “been here for a while”. Proximity has absolutely nothing to do with visibility, but it is something that players can see and quantify in order to devise systems of abuse.

You’re also thinking primarily of piling tank-corpses onto already busy battlefields. I’m thinking on tank scales, I’m thinking of the wrecks on the outskirts of town where an AT gun takes out incoming armor. I’m thinking of the chars that get taken out by 88s on their scale-of-battle, the tigers that get bombed as they try to cross bridges.

There will, naturally, be far less people out where theye are around the wreckage of the mobile spawn in town in the thick of the action.

Steel: If no-one is within 2km of a hulk, its not hurting anyone. So there’s no reason to pull it. The issue isn’t the simple headcount of hulks, its density of hulks in busy areas.

It’s worth pointing out here that we’re talking about hulks. The charred wrecks of vehicles that occur when a vehicle explodes. We’re not talking about the remains of broken or killed vehicles.

So in actuality the rate of occurance is going to be relatively low, but we need to keep the number of them in any given 6x6km area down below 50, or else they start putting a hurt on people entering the area or spawning in.

It’s likely that there will be a limit of something like 16 in any single 512×512 area, and 50 for an entire 6x6km area.

Fridge: “a hulk in the middle of nowhere” – its not tho, is it? Someone actually destroyed that tank. A tank fight occured a that position =) It’s only the middle of nowhere on an infantry scale :)

Steel: they don’t despawn, they explode :)

Jwilly: Poly counts aren’t/haven’t been a problem in forever, except in the number of polys being used to describe different meshes – i.e. different LODs, different models, etc. Adding another set of LODs to the models increases memory footprints and model complexity.

And that’s not the limiting factor; its cost of creating vehicle instances, loading the models if they aren’t loaded, creating the damage model and adding it to the collision tables. All stuff our current engine isn’t very good at.

Breed: Field of view? Picture the WillyT cartoon. Left frame: soldier in the “squeezing a turtle” position, face up against the ruined wreck of a stuart tank, beads of sweat flying off his head. Second frame, “n00b” asks him “are you trying to lift that with the force?”, final frame, trooper answers “no but if I don’t keep staring at this hulk that panzer is gonna see me for sure”

If you can afford to scale the hull count dynamically to rather high numbers, then a position-aware system might be good.

A background system that is run every X minutes, searching through all hulks and removing every one that does not have players within 2 km of it might do the job very well. How soon does this usually happen for towns that have been attacked and captured or defended succesfully?

Also, perhaps requiring that there be no players is a bit strong – allowing any number of players from one side would also work rather well, but then I can see some cases where it would fail in immersion. Of course you didn’t specify if you actually have the side information handy in this part of the server system.

Mainly the case where one side has captured a town and somehow managed to kill every single opponent, then timer kicks in, and hulks disappear, just when enemy counter-attack tanks are rolling out from the FB.

kfsone: “Someone actually destroyed that tank. A tank fight occured a that position =) It’s only the middle of nowhere on an infantry scale :)”

True. I fell into the infantry persoective :-)

You’re all hell-bent on trying to “clutter” hulks where an infantry fight is occuring.

Think, for a moment, what a hulk is. It’s the remains of a player. Consider 2 cells with equal numbers of players. If 5 guys die at 10,10 and 6 guys die at 10,15 … There’s more fight going on at 10,15 but there is one less player.

Also, I wish I hadn’t used the term “area”. By “area” I simply mean the 35 cells forming a rectangle around any given cell.

“Areas” overlap. Cell by cell. Cell 10,10 has an area of [4,4][16,16]. Cell 10,15 has an area of [4,9][16,21], and cell 11,11 has an area of [5,5][17,17].

Secondly, cells are fixed positions. If there are 50 players at [10.0,10.0] (top left) and 9 hulks at [9.511,9.511] (bottom right 1m away from them), they are in different cells, and the areas considered for each are different. Ampos’ solution is a “single box” evaluation. Increasing the search radius is not a sensible option.

Unless I organize the player data in a hulk-oriented sense, matching players to hulks is going to be costly.

My point here is that so far all of the proposed solutions are fairer from a single view point, and less fair from others.

0+1-2 = ?

Since tanks are the ones generating the hulks, their perspective is at least as important as the infantry that may want to hide behind them in other areas. Why is nobody sitting out there? The hulk and the nobody aren’t exactly unrelated.

Anyhow, if I flog this horse any longer, I’m going to be hitting Australia. So, I hereby declare this a challenge for you to figure out why my system is fair.

My system’s main weakness is that it doesn’t rate hulks by comparing them in the context of their own areas, in considers them in the context of the new hulk being placed. So it might pull a hulk that, from 10,10 seems to be done with, because it doesn’t see the 1000 people only a metre away in 3.511,3.511

Is fairness in fact the more important performance measure for this functionality, as opposed to minimization of object disappearance from within a player’s FOV, i.e. visual realism?

They’re both important, of course, but I wonder if there won’t be more aggregate negative impression (or positive impression foregone) due to continued in-view object disappearance than from unfair hulk visibility.

Unless I write a rule that knows and understands degrees of visibility, that’s always going to be an issue, and expending resources on a not-even-close-to-visibility metric isn’t going to help with that.

You don’t get population densities of significance out where there is no cover. You get population densities of significance in areas where there are buildings, berms, terrain changes.

Also, the grid cells themselves aren’t very high resolution. 512x512m is a reasonable size chunk of a town, so that if there is a high pouplation density, you’re going to need a very rigorous rule to implement any kind of “fair” system.

So here’s my point: Systematically created unfairness is far more immersion breaking than abstract unfairness. The more complex the system, the more irritating system-generated unfairness is.

It’s a component of why none of the other gambling machines that come along ever supplant the one armed bandit.

“I wonder if there won’t be more aggregate negative impression (or positive impression foregone) due to continued in-view object disappearance than from unfair hulk visibility.”

You should take into account that regardless of how it’s done it will be LESS “continued in-view object disappearance” than is in the game currently. I haven’t seen many complaints over the years about tanks disappearing when they’re killed.

>I haven’t seen many complaints over the years about tanks disappearing when they’re killed.

I’d think because gamers are trained to accept that aspect of unreality as game-normal. Non-gamers, OTOH, have much more trouble with such unreal conventions. A game/simulation that moves past that limitation will be significantly more attractive to the non-entertainment markets for this kind of product.

>…regardless of how it’s done it will be LESS “continued in-view object disappearance” than is in the game currently.

I made the same comment earlier. We’re only discussing degrees of excellent progress.

There were complaints, then it was just accepted that was the way it was going to be.

If there is a automatic, systematic way of removing these hulks I do agree that the “fairest” way to do it is based on time. Any kind of proximation involvement will lead to aggrevation due to cover being removed unexpectedly. I know I’d try to use cover whenever possible in long range engagements, just by putting that hulk between me and my attacker. I might not be close to the particular hulk, but it is just as important to me covering my route at a distance of 100m as it would be if it was 2 inches away.

I think the what really needs to be a focus though is how these hulks explode when their time is up. If it’s a sudden explosion I can forsee many complaints on that and how the “system doesn’t work”. If the hulk has visible and audible queues to it’s empending and violent explosion I believe the system would work very well with little room for complaints. Possibly a 60 sec animation of the burnt out hulk starting to smoke ***sizzling/crackling**, fire , more fire **Roar**, then a violent explosion **Boom**.

This allowing for not only notification of your cover is about to be removed, but also notifying you that you need to get the heck out of there before your cover blows you up!

That’s key too I think, that way you’re never left a sitting duck as infantry when the hulk is removed. If you didn’t take the warning, the hulk didn’t abandon you, it killed you when it went up.

How are hulks going to be removed?

Will be when the grid/cell is full based on oldest first, or will be after x minutes, regardles of the hulks in grid or both of them together?

As far asa I remember, there is 2 kinds of hulks. Burned tanks (in 1 piece) and exploded ones (many pieces around the terrain). Are both kind of hulks being tracked? If a exploded tank is going to be traced, it could be cool to see here the turret, there the rest…

Are trucks going to be traced?

What about missing pieces of tanks? I am thinking on 232 wheels. It is not rare to lost a wheel… I did not remember to see what happen to a 232 wheel after it goes out from the 232… does it stay on terrain or desapear?

Steel’s comment reminds me of this question: Will there in fact be a means, perhaps eventually, for tank hulks to damage soft objects that get too close to them while they’re burning, or during a state-transition-masking explosion?

I’m under the impression that *live* objects (i.e. client tanks) currently can’t do such damage while burning or during turret explosions.

Just want to point out that “cities” have AB’s. AB’s are where the fight ends. The fight usually ends with a *large* amount of players in close proximity.

Frame rates are already bad in heavily contested towns pushed into a small front.

Hulks may best be implemented in stages. (this also defeats the “deadline” problem).

First stage: Hulks only appear OUTSIDE cities in ranges equal to 1/2 the standard distance to an FB.

This allows testing and observation and coding changes from the observations.

So the variables we are talking about is how long a hulk is persistent (time) and hulk density within varying degrees of resolution (Areas and Cells)

Define a maximum density for an Area, and a Maximum density for a Cell.

Density would be the number of Poly’s being used?

Would hulks have varying poly counts over time? Or is this a constant? (assume constant from the code)

When a hulk is being placed you cannot exceed a cells density or an area’s density.
When exceeding the cell density the oldest could be removed.
It’s once you got to the area, what would be a fair removal pattern (oldest?, weighting of hulks based on proximity to new hulk?) I say oldest for simplicity.

My experience leaves me with the impression that this is a clustering game. Deaths for armor and inf tend to cluster around certain points. Hulks might disperse this, but will it disperse it more than a few adjacent cells? or disperse it out to areas? (I’m betting only a few cells)

Breed… A few replies back, kfsone wrote:

Jwilly: Poly counts aren’t/haven’t been a problem in forever, except in the number of polys being used to describe different meshes – i.e. different LODs, different models, etc. Adding another set of LODs to the models increases memory footprints and model complexity.

And that’s not the limiting factor; its cost of creating vehicle instances, loading the models if they aren’t loaded, creating the damage model and adding it to the collision tables. All stuff our current engine isn’t very good at.

Breed wrote:

My experience leaves me with the impression that this is a clustering game.

That’s your perspective, from being on the ground rather than observing impartially. The times when tanks engage are close distance are more memorable than the long range ones. That’s all. Infantry don’t hulk. And the way vehicles die in CQB tends not to produce a hulk.

As of this point, I consider it an exercise for those of you trying to come up with rule sets and systems to see if you can work out why what I’m saying is correct. I didn’t like having to come up with it off the cuff like that, but it was the right decision. I just like time to second guess myself in advance of coding something up.

Didn’t see the poly thing. I thought that was still an issue. Are the constraints due to the original design to make it easier for modem play 5 years ago?

Don’t like the feeling that you could be coding yourself into a corner?

I feel like that almost every day trying to anticipate future business needs so that current code going into production does not need to be modified as much in the future.

Keeping in mind my near-lack of programming experience, what about something like this to determine which hulks are removed when a new one is created:

1) Around for more than 1 hour (automatic)
2) Around for more than 25 minutes
3) >1km outside city, less than 25 minutes
4) Less than 1km outside city, but around for more than ten minutes and less than 25
5) Less than 1km outside city, around for less than ten minutes

Since the largest issue is the hulk as infantry and ATG cover, I figure the most likely case for this scenario would be near cities (and perhaps FBs), so simply having tank hulk-elimination based on its proximity to a probable high-density area for infantry is probably the simplest solution. To avoid the high numbers that could come from AB hits, maybe have it so any that appear so close to an already existing one don’t get placed – keep the existing hulk instead of the new one within ten feet of it.
Again, just a possible solution. I’d have no problem with the pure timed method, but I can see why it could be iffy if a ton of tanks die in the same area in a more heated battle.

Hmm, one more detail to ponder, do trucks leave hulks? If indeed they do, what prevents players from rushing the damn things to AB entrances basically denying the access out of the AB and thus preventing them from defending the said town? Is this going to be an issue anywhere (Think of bridges, tight alleys and whatnot)? If hulks can be pushed with say tanks, then I don’t think this is a big issue, but as far as I know, we can’t push anything in this game so I doubt hulks will be pushable either.

Btw. gotta agree, fi-fo based hulk removal is probably the best way to go.

Trackbacks and Pingbacks

[…] with a cool head and implemented the design(s) I’ve experimented with (remember, the chat grid system was a prototype for such a concept). But it’s categorically not something I’m going to […]

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: