DFD: 681 vs. 757, 358 vs. 526

[Renegade]

DFD: Daily Feature Deathmatch

---

The Cruel Fight For Implementation

This is a Daily Feature Deathmatch post. If you are unfamiliar with the background of this event, please read the announcement and the schedule.

Fight 1

---

[0000681] Climbing cliffs & jumping off them vs. [0000757] Deployer Stat Changes

Fight 2

---

[0000358] Some sort of size tag for vehicles vs. [0000526] Allow units to become "phased"

By the end of the 48 hour period, two of these issues will be suspended, while the other two move on to the next round.
Remember that the coders will not take part in the discussion, so make your arguments complete, concise and convincing - when it's over, it's over.

Part of that is clearly marking what outcome you support for which issue.
There should be no ambiguity in the issue you're talking about, and it should be clear what outcome you support. Feel free to put your stance in bold, and use simple terminology like "kill #69" or "I want #42 to survive".
A decision will be made either way, so a lack of discussion will not cause all issues to live.

Be friendly, be civil, be logical.
You are allowed to try to deconstruct the arguments of those arguing against your candidate, but remember that they don't make the call - there is really no point in getting personal.

The discussion should be contained in this thread, argumentations elsewhere will be ignored, but you are allowed to transfer and adapt points made elsewhere in the past.

We want a good, clean fight.
Let's get it on!

End: ~ 18:00, 07.07.2010.

[Lt Albrecht]

#681 adds one special case that will be impossible to do in its original state (infantry climbing) which TBH isn't that amazing.
#757 allows quite a bit of customisation, I can think of more uses for this "deploy to change unit attributes" code than for #681. e.g. mimicking -to an extent- the RA3 soviet miner logic, where it can deploy to gain extra protection at the cost of speed. Also, if marshall's suggestion for techtype->techtype style implementation is done (e.g. vehicle to vehicle or infantry to infantry) this becomes even more useful, as you can change the unit's weapons, art, locomotor etc. This would allow implementation of 'transformers' (RA3 springs to mind... Japan especially) as well as other more 'traditional' uses such as switching between weapons.

#358 allows juggernauts to roam the battlefield crushing all at the expense of some really fugly art coding on your part (awesome but imractical)
#526 doesn't seem too good to me, I read the suggested implementation and it seems to me BTG has a mod planned and wants Ares to do the grunt work Apart from that I can't see any real use...

[MRMIdAS]

keep

[0000757],deployed armour (or damage on the weapons) has been done, but allowing a unit to selfheal when deployed would be pretty cool, or even, as people have requested, give it RA3 style extras.

[0000358] larger vehicles would prevent graphical overlap, help with targeting larger vehicles in a sea of overlapped large vehicles, and could possibly (and rightfully) be affected more by cellspread weapons, depending on how big they are.

[cranium]

out of all four of these #757 seems to be the only one to get my attention. I really dont see the need for cliff jumping. Kind of defeats the purpose of having cliffs dont it?

[jimmy3421]

Support #681 #358

WHY?
About #681,I feels novel,so i choose it.

And #358 v.s. #526,Both I don't like.
But I must select one,so I choose former,it seems a bit usefulness.

[Beowulf]

Kill #681. Implementation would be absurd. #757 has a much more practical application.
Kill #526. #358 at least has some benefit to it.

[Blade]

Kill 681, it doesn't seem to me to have very many useage scenarios other than to make less useful jump jet units where they can only jump in specific scenarios. Time limited deploy to fly/land units would be more flexible. 757 has IMO more modding potential.
Kill 358, it seems like people just want to make epic units take up more space on the actual map and the request doesn't really make it clear why that would be a good thing other than for graphical overlap reasons. 526 appears to be sugesting adding something like a "4th" dimension to the game which could be very interesting IMO.

[¥R M0dd€r]

Kill 358, it seems like people just want to make epic units take up more space on the actual map and the request doesn't really make it clear why that would be a good thing other than for graphical overlap reasons.

is there anything wrong with wanting a epic unit to be larger that 1x1? You cant yet said if it is going to overlap or not, becuse it isint even coded yet.

Support [0000681]
Support [0000358]

[reaperrr]

Fight 1:
Kill #757, support #681. I don't care about climbing, but jumping would be perfect for BattleMechs with Jumpjets

Actually, #757 would not be that bad either. If it was possible, I'd prefer those two over both issues from Fight 2, actually :/

is there anything wrong with wanting a epic unit to be larger that 1x1? You cant yet said if it is going to overlap or not, becuse it isint even coded yet.

I believe you misunderstood Blade, what he meant was probably that people want units that occupy more than 1x1 cell only because that would reduce overlapping.

Personally, I think #358 is probably too complicated to code (I imagine it's going to be a nightmare in terms of coordinates and stuff) for the limited advantages it brings.
I don't really care that much about #526 either because its usefulness is rather limited I think, but it sounds a bit saner to code, so my vote is kill #358, support #526.

But make no mistake, in my opinion they can both die.

[Lt Albrecht]

Kill #757, support #681. I don't care about climbing, but jumping would be perfect for BattleMechs with Jumpjets

So you'd sacrifice:
-Deploy to change (attribute)
-RA3 japan style deploy to transform from air/ground
-Emulation of many 'special abilities' from other games
For:
-Battlemechs that can Jump?

Somehow I don't think that's the right way round. Consider how many modders would use each feature, I can see a MUCH larger usage for #757 than #681...

I believe you misunderstood Blade, what he meant was probably that people want units that occupy more than 1x1 cell only because that would reduce overlapping.

Oh well, their choice as to how to use it... It may be a bastard to code but at this point that's D/Ren/AlexB's call. I just think people would get more mileage out of it than ths kinda weird phasing idea which has exactly one usage.

[reaperrr]

(...)

hm, you got some points there. If it wasn't for the fact that my mod will feature BattleMechs, I would have voted for #757 myself.

Well, as I said, this is one of the fights where I'd prefer both to survive. Right now it looks like the majority favors #757 and from an objective point of view it has far more uses, so I doubt my vote will have an impact on the outcome either way.

[Lt Albrecht]

This isn't about the majority ren hates 'democracy' in these matters and basically choses the one he thinks has the best arguements for (or least crippling flaws), these things are a meritocracy. May the best idea win!

[AlexB]

Fight 1
The deployer changes have a lot more use cases. Jumping/climbing would not add that much to the game. So this time I'm quite terse: Deployer Stat Changes.

Fight 2
What are the uses of Phasing (except from phasing units)? One argument in favor is it is easier to code. It isn't fleshed out very well. It can be used to keep a player alive if the enemy doesn't have any access to phased units, just like the RA1 submarines. On the other hand the unit size isn't important to the gameplay. Well. Both are equally "good" and should be a pain in the ass (<= the animal) to code. I'm inclined in favor of the phasing, as it might be a bit easier to code. It still needs some serious treatment. (Last unit problem, can SWs destroy phased units?, are there weapons to unphase units? can phased units enter transports/be crushed by tanks?) Very complicated stuff for just one tiny feature.

(Democracy is a good thing, but with 1050 issues it is advisable to pre-select. Several issues are just benefiting very few modders and are really time-consuming to code. Everybody has a voice but in the end I can't do everything. I think the other devs have a live beyond Ares, too. I like to code up stuff and complicated issues aren't uninteresting automatically, but forgive me if i can't let the majority decide how to spend my time. Good stuff will survive even if it loses in the first round.)

[Renegade]

I don't "hate democracy" in these matters or any other, kthx. Pure polling just simply doesn't work to decide which features to implement - as recent DFDs have proven.
Every feature is wanted. If they weren't, they wouldn't have been requested. And all features are different. So to make inclusion dependent on how many people turn up to write "I can haz feature X?" at a given time-frame is insane.

Especially if the voters utterly fail at reading the requests or thinking about the changes in practice...not that that happened in the past two DFDs...

Also, "meritocracy" is the wrong word. Geniocracy might apply.

Either way, to judgement!

Fight 1

---

Unfortunately, it seems wishing and planning is preferred over reading and arguing this time around. The fact of the matter is, while Marshall's suggestions are interesting and certainly a possible way to implement this, they are not part of the request.

So both of albrecht's argumentations as well as any other in that direction are moot, because they hinge on one particular implementation that is neither requested nor guaranteed in the request.
We could easily implement #757 without Marshall's suggestion, satisfying the request to the letter without providing any of the features used to argue for it here.

Unfortunately, the other argumentations for the issue are kind of thin - "allowing a unit to selfheal when deployed would be pretty cool", "#757 seems to be the only one to get my attention", "#757 has a much more practical application", "757 has IMO more modding potential".
No argumentation based on the actual request, only one example that is actually founded in the request itself, and that's just a random statement of opinion about it.

The arguments for or against #681 are of similar nature. "Kill #681. Implementation would be absurd". Really? Well alright then.

So yeah. Given that neither side is ultimately giving a good reason for choosing its issue, I'll choose this one on projected complexity and potential:
#681 would need entirely new attributes, movement states, pathfinding, etc., only to ultimately achieve a shortcut that a carryall gives just as well.
#757, as it is requested, should be comparatively easy to implement.

Kill #681
Support #757

Fight 2

---

While I have pretty good reasons to believe #358 isn't quite as complicated as it's made out to be, and I don't see any basis for the random claims that it's mostly a graphical thing, once again, there aren't any deep arguments for either issue, so I'm left to make up my own mind again.
Size= for units would provide exactly that - fat units. The same tanks with the same abilities as before, just larger.
Phased units will create a new variety of units with new tactical abilities, which increases the number of ways modders can change the game and gameplay.

Kill #358
Support #526

[DCoder]

Fight 1

---

#757 - changing unit stats when it's in a specific state (deployed, amphibious, etc) is a very cool feature. It's a real bitch to code, but that's my problem.

Fight 2

---

#526 - the latest comment on the issue adds extra tactical value (I thought of a generator that can imbue a cluster of units with phasing for a limited time, and then you can send them off on recon/extraction/ambush missions, while a small bar next to the unit shows you the remaining charge mobile EMP style... ) Not sure how this would influence pathfinding (can a line of permaphased trucks block a choke point and annoy normal units to no end? backwards, can normal units barricade phased ones from passing?) and superweapons. #358 would only reasonably be worth doing on naval units (great dreadnaughts) , but I'd love to have it done someday... Ren has already seen some of my progress here