71 replies to this topic

[Mikhalio]

LRM & SSRM are the least difficult weapons to play as. They are the ice-mage of MWO. Sit and spam. This is the only reason why players want ECW removed, to enhance their speed grind to min/max mech bux's gained per hour.

And yes, that net code guy needs to be hired already. But this has been talked to death, and Paul still has no Netcode guy.

[Protoculture]

Mikhalio, on 17 January 2013 - 05:02 PM, said:

LRM & SSRM are the least difficult weapons to play as. They are the ice-mage of MWO. Sit and spam. This is the only reason why players want ECW removed, to enhance their speed grind to min/max mech bux's gained per hour.

And yes, that net code guy needs to be hired already. But this has been talked to death, and Paul still has no Netcode guy.

Wrong. Check my sig.

[Dukarriope]

What's bugging me is how they ended up with their balance decisions, and how long it takes them to respond on balance issues or to change them...

I mean, has Paul ever explained what they have to do to make a balance change, not including the internal playtesting? Just modifying some variables in an .XML? Etcetra?

[Nightfire]

First point, thanks for the update Paul. The occasional reminder that you haven't forgotten about us and a some communication puts a lot of us at ease.

MajorLeeHung, on 17 January 2013 - 11:09 AM, said:

Dont feed us that BS Paul! YOU HAVE HAD MONTHS and all you have done is introduce a non cannon and broken ECM, disabled collisions and made light mechs god of the battlefield (and if you dont beleave that look at my game footage for the last week and watch as me and three merc corp buds win EVERY MATCH and abuse it for 2million cbills+ an hour) and pushed us farther down the road tward gauss warrior online with your inability to balance weapons (hence broken *** ECM). You and David have flat out failed to do your jobs. Your netcode guys need to be fired or have there pay cut so that actually DO something and we wont even start about your lack of content, no CW, no good MM, crap mechbay and frontend, 6 month old bugs, or the hundred other things that should have been addressed by now.

1) Collisions would have made lights useless with bad netcode. Imagine crossing the path of an Atlas 100m in front of it and getting tripped. It would be the last thing you ever did in that match, there is no way you could compensate for it (because the Atlas on the server could be anywhere in that 100m on the server!) Since the first mech most new players will get will be the cheaper lights, that would compound the issue into punishing new players who are already being brainwashed into thinking all woes that befall them are the fault of the omnipresent "premade". (See, I can drag in irrelevant pet peeves in attempts to derail you too!)

2) Take your ECM complaints to an ECM suggestion thread. Just because your pet peeve project isn't mentioned, don't try to hijack this one. Again, constructive, cordial.

3) Weapon balance can be done to some extent on internal systems where the netcode has far less of an impact. Just because the initial balancing is exasperated by external latency and then doesn't polish up to your expectations doesn't make it viable discussion here. It is especially unwarranted when it is used for no purpose other than personal character assassination. Again, constructive, cordial.

4) Oh I love this one! Netcoders and incentivising them! Let us start from the point that this addresses the comments of a number of posters and that PGI have multiple teams. (Disclosure: I used to code network comm systems and lecture in networking.)
A) Fire the Netcoders: This will only slow things down. This is a rare breed of coder and while any coder can code these types of subsystems they won't do it anywhere as quickly, the code won't perform as efficiently, the code will not be as logical and there will be (guaranteed) more issues caused by the implementation later on. In short, unspecialised coders here will just make it take longer and perform worse.
Cut the pay of the Netcoders: Then they'll quit and find work elsewhere pretty quickly. If you have the skillset here, you won't go long without a job, if at all. Outcome, see A.
C) Merge the teams until the Netcode is fixed: The rest of the teams have their own specialities and cannot really contribute effectively. You may have a few multi-skilled coders if you're lucky. Some of the other coders might be able to clean up some code others have written. At the end of the day though, they cannot jump in like they can with their own area and not hamper what is already being done.
D) Fire everyone but the Netcoders: Just because the netcode needs work doesn't mean the other work doesn't need to be done. If you have a resource that can be producing, you don't get rid of it because you need more of another. That is asinine! The other developers cannot help in netcode, that doesn't make the work in what they can do go away.
Netcoders are not the easiest specialty to find, they can also be kinda warped people. Something like pure mathematicians.

5) If you can't be constructive, especially when people are trying to be nice, you really need to learn how to not say anything!

Edited by Nightfire, 17 January 2013 - 10:59 PM.

[CrashieJ]

Paul Inouye, on 17 January 2013 - 10:41 AM, said:

It is myself and David B. who do the game balancing. Both of us are not programmers and you DEFINITELY don't want us playing with netcode. I'll let you and the rest of the community in on something. Netcode is our #1 priority on the engineering side of things. The guys working on netcode have touched nothing but netcode. They have nothing to do with game balancing or adding new mechs/maps/items. Their main focus is netcode. i.e. Finding problems, re-writing a LOT of code that is part of the engine and making sure it doesn't break anything back up the chain. This is a VERY long process and not something that is addressed in a few days or weeks for that matter.

THIS. we need more of this... COMMUNICATION.

Paul, next time, can you handle the patch notes and such so that the forums aren't raging with misinformation?

[Machinae Mortis]

8RoundsRapid, on 17 January 2013 - 10:47 AM, said:

My question is this, Paul: Why was netcode, since it is such an essential part of any online multiplayer game, released in such a shoddy state?

It hasn't been. It's a beta.

Edited by Jlad, 17 January 2013 - 11:24 PM.

[MajorLeeHung]

Nightfire, on 17 January 2013 - 10:58 PM, said:

First point, thanks for the update Paul. The occasional reminder that you haven't forgotten about us and a some communication puts a lot of us at ease.



1) Collisions would have made lights useless with bad netcode. Imagine crossing the path of an Atlas 100m in front of it and getting tripped. It would be the last thing you ever did in that match, there is no way you could compensate for it (because the Atlas on the server could be anywhere in that 100m on the server!) Since the first mech most new players will get will be the cheaper lights, that would compound the issue into punishing new players who are already being brainwashed into thinking all woes that befall them are the fault of the omnipresent "premade". (See, I can drag in irrelevant pet peeves in attempts to derail you too!)

2) Take your ECM complaints to an ECM suggestion thread. Just because your pet peeve project isn't mentioned, don't try to hijack this one. Again, constructive, cordial.

3) Weapon balance can be done to some extent on internal systems where the netcode has far less of an impact. Just because the initial balancing is exasperated by external latency and then doesn't polish up to your expectations doesn't make it viable discussion here. It is especially unwarranted when it is used for no purpose other than personal character assassination. Again, constructive, cordial.

4) Oh I love this one! Netcoders and incentivising them! Let us start from the point that this addresses the comments of a number of posters and that PGI have multiple teams. (Disclosure: I used to code network comm systems and lecture in networking.)
A) Fire the Netcoders: This will only slow things down. This is a rare breed of coder and while any coder can code these types of subsystems they won't do it anywhere as quickly, the code won't perform as efficiently, the code will not be as logical and there will be (guaranteed) more issues caused by the implementation later on. In short, unspecialised coders here will just make it take longer and perform worse.
Cut the pay of the Netcoders: Then they'll quit and find work elsewhere pretty quickly. If you have the skillset here, you won't go long without a job, if at all. Outcome, see A.
C) Merge the teams until the Netcode is fixed: The rest of the teams have their own specialities and cannot really contribute effectively. You may have a few multi-skilled coders if you're lucky. Some of the other coders might be able to clean up some code others have written. At the end of the day though, they cannot jump in like they can with their own area and not hamper what is already being done.
D) Fire everyone but the Netcoders: Just because the netcode needs work doesn't mean the other work doesn't need to be done. If you have a resource that can be producing, you don't get rid of it because you need more of another. That is asinine! The other developers cannot help in netcode, that doesn't make the work in what they can do go away.
Netcoders are not the easiest specialty to find, they can also be kinda warped people. Something like pure mathematicians.

5) If you can't be constructive, especially when people are trying to be nice, you really need to learn how to not say anything!

1-4: OMNOMNOMNOM food!!! thanks!


5: I said good game. Guess you no can read! Oh but you left that out to try and assassinate my character! constructive and cordial please good sir!.

[Tickdoff Tank]

F lan Ker, on 17 January 2013 - 12:51 PM, said:

S!

Things like Paul posted could be put up in a blog or something and the thread locked out of comments. People could see where the things are going etc. But nevertheless good to hear things are being worked at

Most of the whiners would never bother to read it anyway, the few that did would pick it apart and continue to complain ad nauseum. Which is part of the reason my ignore list is so large.

[CMGrendel]

Orthodontist, on 17 January 2013 - 11:13 AM, said:

You know.

You should be quiet.

The game is FUN right now. I have many, many hours of enjoyment thus far into this game. Let them clean it up, right now the game IS playable.

The important modifier you missed here was "for you". I'll happily sit out changes during development, but when half of my corp stop playing MWO and the only times people are playing is "just to grind XP (including myself) I start to worry. With the current state of play I will not be spending another dime on the game and I have already begun to stop playing. Overall, this game has lasted me less time than MW2/MW3/MW4 and the end game still seems 6 months away, assuming the development team focus on that.

[Thor 1]

Interesting dicussion. However, to make a point, read "The Mythical Man Month". In short, adding unfamiliar and or untrained personel to a project will actually slow a project down consderably, eg. "too many cooks spoil the broth". It is up to PGI to have the right number of people in the right place. However, once a project is resourced, unless someone quits, it will finish when it is done.

Don't believe it, imagine adding infinate people to a project, will the project be done instantly? or infinate money for that matter. There is only so much that can be done in the short term to increase a projects resources to complete it in less time. I'm sure PGI got the message and will take appropriate action!

So chill out and make constructive observations that "help".

[Steven Dixon]

Thor 1, on 10 February 2013 - 09:31 AM, said:

Interesting dicussion. However, to make a point, read "The Mythical Man Month". In short, adding unfamiliar and or untrained personel to a project will actually slow a project down consderably, eg. "too many cooks spoil the broth". It is up to PGI to have the right number of people in the right place. However, once a project is resourced, unless someone quits, it will finish when it is done.

Don't believe it, imagine adding infinate people to a project, will the project be done instantly? or infinate money for that matter. There is only so much that can be done in the short term to increase a projects resources to complete it in less time. I'm sure PGI got the message and will take appropriate action!

So chill out and make constructive observations that "help".

I read that years ago in college, its actually a very interesting read. If Brooks law (which is what the book is essentially about) doesn't make sense to someone think of it this way- if they suddenly added more people who weren't really experienced with working with this particular netcode (or god forbid they weren't really programers at all like the people doing art or game balance), then the actual experts are going to have to spend all of their time training the newbies. These new guys are going to make a lot of mistakes that the experts are going to have to double check and repair.

Basically unskilled people will do most of the work while the skilled people will be trying to keep the project together, and the skilled people are skilled in netcode not necessarily training or management so they might completely suck at getting the newbies up to speed. This is why it can take longer when you add more people. Adding more money also won't necessarily help, if the people working on it are working as hard as they can simply paying them more won't make them work faster. You could offer them a bonus for finishing early but this would just encourage them to cut corners and can also actually increase the development time.

[KingNobody]

Man, if I was the Devs, and I got responses to my posts like some of the rude and childish rants seen on this thread, I would stop posting altogether.

If you want the devs to provide timely information and good communication, don't jump on them like wild hyenas every time they post anything.