1

(11 replies, posted in Feature discussion and requests)

I like it, I really really do.

I envision a nice blob of little arkhes running up and repeatably trying to steal until the chain reaction goes and everyone dies in a ball of fire.  Tempting, very tempting.

I'm not sure how the internal mechanics of ammunition/firing works, but this is worth a shot.

From visual indicators, it appears that the module 'fires', the ammo counter is lowered, the recharge cycle begins.  So a normal cycle right now is: Fire last shot, counter goes to 0, recharge cycle occurs. 

If that's the way it works, I would think it would be possible to incorporate a check for 0 ammo right after the counter is decreased.  If 0 ammo is found, then the auto-reload could start instead of the recharge cycle.

3

(106 replies, posted in News and information)

Norrdec wrote:

It all boils down to the way the SAP will be activated. Are they going to just go active, global message on the island or similar to now - territorial warfare menu that will show you what's active and ready to be capture at the time.

That's a good point.  We don't really know yet, but might as well offer some ideas on that too.

We can assume there are 3 ways of informing about a SAP activation:  None, Defender-Only, Everyone.

None would truly add spice to the game.  Attackers would have to be on the prowl or lucky, diminishing their resources in efforts to catch people.  Defenders would have to be on their toes in checking their SAPs consistantly.  Overall, people would have to be active constantly, and that's cool.

Defender-Only gives the large advantage to the defender, of course.  This would make it viable for a smaller corporation to hold an outpost longer than a few weeks.  But it would also make it really easy for a large corp to hold what they have, meaning they could hold it with less and use the extra people to move outward.

Everyone knowing at the same time kind of smacks of the current system.  Granted, no one would know until they activate, but the attackers would know exactly where to go, the defenders would know everyones coming, but not when.  This gives an obvious advantage to the attacker, and might be too overpowering right now.  Maybe later it would be cool.

Personally, I vote for the None option.

4

(106 replies, posted in News and information)

Syndic wrote:

Maybe we don't have to band together & have a DO OR DIE mentality, but that still doesn't mean we - or any other alliance in-game for that matter - should be "forced" by the Devs to disband with faulty game mechanics.

Because quite simply, we won't disband. smile

This.

The system as described actively discourages the formation of benevolent defensive alliances.  The only forms of alliance possible after this takes affect is an aggressive alliance (whose only purpose is to deny outposts to others, since they can't/don't have the manpower to hold them) or a mercenary-style defense-for-pay alliance (interesting thought, but not very reliable overall). 

Friedrich Psitalon wrote:

The only thing an alliance feature would do right now is allow oversized entities the ability to dominate larger swaths of landscape, which I get the distinct impression is NOT the intent of this system.

In both the old and the new system, if an oversized entity can dominate an area, then they can.  The mechanism may be changing, but the reality is still the same.  The problem with this new system is that it is bypassing the indepedence that an alliance allows and forcing corporations to actually merge if they want to grow.  The old phrase "Join us or die" is suddenly not only viable, but enforced by the nature of the rules. That is not the direction this game should probably go.

5

(106 replies, posted in News and information)

Hmm.  The problem before was that corporations were holding many terminals because they could effectively defend them.  With this change, corporations will definitely have to take a more active role in holding what they have, and that’s a good thing.   I almost want to say that it’s a realistic representation, but this is, after all, a fictional game.

On the matter of sniping, I think the players themselves will work out the repercussions.  If an entity gains a reputation for sniping, then they better have the resources to defend themselves, else they face destruction from the other players.  In the case that a large corporation decides that sniping is an effective tactic for preventing control of areas of an island, who’s to say that others won’t band together to teach them a lesson.  I look at this as just another mechanism for inducing competitive interactions, and that’s a good thing.

On the subject of alliances, I would say that this new system would discourage alliances that are of the type of mutual defense.  If you, and only you, can truly hold the outpost and maintain a relatively high efficiency (control) level, then forming an alliance for the purposes of defense—any defense—does not benefit both parties and thus no alliance will form.

If we take that idea a bit further, it does insinuate that perhaps you could purchase the services of mercenary groups…but then we are back to the “my corp didn’t technically win the SAP, so my control is lowered anyway”.  Could the player base find a way around this issue?  I believe they very much could, but it would be cumbersome, so why not build a mechanism into this from the start.  Perhaps something that ties in the allowed/disallowed docking list with groups who are allowed to take your SAP (which the game would consider as you having taken it).

Well, hmm.  I logged in for 30 mins before work today and did see some unexpected results.

For about 5 mins straight, the game and website were completely unreachable.  There's about zero chance this was memory or a client issue.  I usually blame Comcast for these types of problems.

My client froze 3 times opening up assignments from the assignment window.  Each lockup lasted for about 10-20 secs.  What I thought was interesting was that the background terminal animation was freezing too--no sparklies moving around at all.  First lockup occurred when I tried to open the assignment-specific map twice without closing the first one.  Locked up again opening a second assignment description window after closing the first.

My client froze one more time accessing my extensions list.  Same 10 secs or so.

I'm at work now, so can't test anything else.