Defense Is Too Powerful

[myndzi 0]

New thoughts, or rather refinements on some unsupported ideas I mentioned previously.

 

A concept that is easy in my head but harder to express relates to 'resolution'. Just as with your monitor, when you have more pixels in the same amount of space, you have a finer 'resolution' and thus more control (in this case, over the quality of what you are looking at).

 

Time: milliseconds have a higher resolution than seconds; thus, if you are trying to do something periodically, or measure something in time, you will get more accurate results using milliseconds than seconds.

 

'Duh', you might say, but the same concepts apply to prizes in the zone. I already pretty much laid this one out: the more the prize weights total up, the more 'resolution' there is, thus you have a finer control over the relationship of one prize to another. The smallest change you can make makes less of a difference when you have a high resolution.

 

Follow me a little longer here... think about teams. Ignoring for the moment centerkillers and people who are afk and such, if you pit two teams against each other, who are approximately equal in numbers, you will notice that the more players on both teams (the higher the *resolution*), the less (in general) a single player (the smallest change you can make) affects the outcome. When the resolution is high (lots of players on both teams), the teams behave more like a unit, even when they are not cooperating. The smallest change that can happen (a player joining or leaving/spawning or dying) makes less of a difference when there are 20 people attacking than when there are 2.

 

What I've been grasping at follows along this line. The low pop games that we are experiencing, with say 4-7 players per team, create an environment in which it is pretty easy for a single player to affect the balance of the game. With low 'resolution' games, a single player can make a much greater difference. As well, a single *ship* can make a much greatter difference. The capabilities of a given ship in SWZ affect the balance of a game more greatly when the resolution is low. Because of this, small imbalances in the ships can become magnified... or rather existing imbalances aren't noticed as much during large games (when everybody is watching).

 

I think where this is leading me is simply this: if we tone down the power of the ships, games will be harder to throw out of whack in low populations. This could mean anything from reducing fairly common items (such as bouncing bullets, portals, repels) to reducing the ships themselves somewhat (I don't think this would go over well, however). Perhaps some scrutiny on the bases would be warranted here... less powerful choke points would certainly do something about people milking small games against hopeless attackers.

 

I guess that sort-of counts as the 'what can be done' segment too. Eh, I'm stopping here.

 

[Circle 0]

There's a new bot-controlled map in powerball. When the population is low, it raises some walls and enclose the arena in a smaller area; when the population is normal, it lowers the walls (opens the doors); and when the population is huge, it opens up even more places.

 

So something like this could work in SWZ. Though I think it's harder to attack when there are more people (it's easier to get past 2 defenders as 2 attackers than 10 defenders with 10 attackers). So if the population is large, open up every base a little more. Widen the choke points, add holes.

 

But right now I'm just waiting for the cap ship (bot) to be fixed.

[Helluary 0]

OMG THAT SOUNDS SOOOO COOL!!!!!!!!! lets do it =).... i mean if we can hehe

[miew 0]

Sry for the slow responses. My computer has been playing up alot lately so i have been trying to back up all my stuff and reinstall everything. I'm at work at the moment so i cant spend too much time here. I'll sneak in this quick response before everyone else turns up

 

Anyways, with the talk about map work brings to mind the need for ppl with map making/designing skills. Senti has been the main driving force with map making until now. With his departure from staff and semi inactivity there is in need for some new talents.

 

Circle, that would be a real nice idea to try out. I can see some tricky issues with having a dynamic map though. If there are any talented developers out there who wishes to have a go at this i would be more than happy to support them

 

[senti 0]

I've got this map laying around with some bases in it that i would like to see tried out for a week.

If it's working, some1 can make a map based on those bases.

I will send it sometime this week, miew.

[miew 0]

cool, i look fwd to seeing them senti

[myndzi 0]

I hate to keep heaping "oh let's make a bot for this" ideas on 50 (or anyone else for that matter). That said, I don't know if this would really be needed.. it certainly wouldn't be much more than "clever".

 

The map with the minibases was an excellent idea. You don't need any bot to control the use of bases... just design them so that they can only hold with an approximate number of people. Large bases with multiple entry points or easy-to-run passages won't hold in small games, but small bases with easily wallbombed borders and nowhere to fall back to won't hold in large games. Especially with caps.

 

Besides that, it's one thing to close off areas in a map in powerball (the PB map is like one big "base" in a way); but "expanding" bases dynamically is another thing entirely. For one thing, if you control some doors with bots, you won't be able to have random doors. For another, it'll just look silly. You'd have to turn the door tiles into wall-style tiles, and you'd only be able to use 2 graphics unless you wanted it to animate... which could be worked in, but essentially you have an "up and down" graphic and a "left and right" graphic. These would work for closing off passages, but not for opening up choke points or other locations as far as being "wider" than before.

 

Even so, I think it's an interesting idea to play with, but I don't see that it is something that should be a priority coding task.