Jump to content

This game and others are more fun to me now


LookBehindThee

Recommended Posts

Bean counters. Rabid bean counters are the worst. Management that likes rabid bean counters cause soul rust, drought, acid rain and cooties. Not to mention that they smell of mildew, and moldy elderberries.

 

Ayup. I have done battle with 'em so many times. I actually got one so incensed that he threw a Coke can at me. :p

 

It was a proud day for me. :D

Link to comment
Share on other sites

  • Replies 56
  • Created
  • Last Reply

Top Posters In This Topic

I didn't say this :D but there is sooooo often a HUGE gap between the "doers" (coders, QA, TS/CS etc.) and "management", especially in cases like EA/BW where there's a parent company and a dev house.

 

Even in small dev. houses management has such a different understanding of and expectation of how the process works it can get very frustrating and downright ugly. I've seen some hellacious battles between mgmt. and "everyone else". Often, too, management haven't the first bit of experience in the nuts and bolts of development, they're, well, management not coders etc.

 

My "dev house" was about as small as you could get without calling it a one-man cottage -- myself and my immediate supervisor, who then reported to a vice president who neither cared nor understood diddly about programming and didn't need to. She wanted to know it worked, and that was it. So on that, I agree with The Olde Witch.

 

Point A (my fingers on the keyboard) to point B (users out in the field telling the VP that the software worked correctly) was fairly straightforward, and involved lots of back and forth conversations with my boss. We weren't blessed with a set of specifications, just "Mark, program something so the people in the field can do so-and-so." My boss's ideas and my ideas formed the framework of what I had to do. So what's different from DieAlteHexe's post above is that there wasn't a lot of management types involved, at least for us.

 

I've also worked in coding houses involving 5,500 employees. It was a medical software company, and everyone had to have a say in the process -- sales, marketing, engineering, education dept, communication... and oh yeah, my boss. Those were 18-month turn around cycles to get anything out the door, but it wasn't because we were standing around not doing anything, it was just a huge system to build, and it had to make many folks happy.

Edited by xordevoreaux
Link to comment
Share on other sites

My "dev house" was about as small as you could get without calling it a one-man cottage -- myself and my immediate supervisor, who then reported to a vice president who neither cared nor understood diddly about programming and didn't need to. She wanted to know it worked, and that was it. So on that, I agree with The Olde Witch.

 

Point A (my fingers on the keyboard) to point B (users out in the field telling the VP that the software worked correctly) was fairly straightforward, and involved lots of back and forth conversations with my boss. We weren't blessed with a set of specifications, just "Mark, program something so the people in the field can do so-and-so." My boss's ideas and my ideas formed the framework of what I had to do. So what's different from DieAlteHexe's post above is that there wasn't a lot of management types involved, at least for us.

 

I've also worked in coding houses involving 5,500 employees. It was a medical software company, and everyone had to have a say in the process -- sales, marketing, engineering, education dept, communication... and oh yeah, my boss. Those were 18-month turn around cycles to get anything out the door, but it wasn't because we were standing around not doing anything, it was just a huge system to build, and it had to make many folks happy.

 

Oh gawd. I'd blacked out memories of marketing/sales types. They used to make us all homicidal. "Sure, we can get that in there by next Monday, nooooo problem".

 

Gnah.

Link to comment
Share on other sites

Oh gawd. I'd blacked out memories of marketing/sales types. They used to make us all homicidal. "Sure, we can get that in there by next Monday, nooooo problem".

 

Gnah.

 

UNGH, That's my current boss.

 

No wait - clarification: it's the "big boss" that's like that. His brother - my immediate boss - is much better (he doesn't feel like a boss, but rather the "part of the team that sets up our work"). He's the type that's like "Let me get back to you on that" then goes "Guys, we have this and that coming up. Can we fit that in somehow, or are we booked up for production?". And then either negotiates a later date, or just.... doesn't take the order.

 

I don't work in programming anymore (been over 10 years since i have) but printing promotional items has similar situations.

Link to comment
Share on other sites

UNGH, That's my current boss.

 

No wait - clarification: it's the "big boss" that's like that. His brother - my immediate boss - is much better (he doesn't feel like a boss, but rather the "part of the team that sets up our work"). He's the type that's like "Let me get back to you on that" then goes "Guys, we have this and that coming up. Can we fit that in somehow, or are we booked up for production?". And then either negotiates a later date, or just.... doesn't take the order.

 

I don't work in programming anymore (been over 10 years since i have) but printing promotional items has similar situations.

 

Blessed art those who have that type of boss for the alternative is truly soul-sucking.

Link to comment
Share on other sites

Having worked in the dev industry for years I can heartily agree.

 

I still think that all gamers should spend one week in a dev. house in the pit and another week on the front lines (TS/CS).

 

It would open their eyes.

 

Come on.... it doesn't take being the best or even experience in that field to always be knowledgeable about it. I don't need to be a iron chef with 100 restaurant chains to know that crap on a plate is going to taste awful, and neither do I need to spend a week as a dev to know if a game is good or bad. Yeah I might feel for them a bit more, but overall their still getting paid for doing nothing. Honestly I want to see how much the PVP team in this game gets paid, as they did literally nothing for almost two years.

 

I ... I know this is on page one and were like on four ...but still... thought I would bring this up.

Edited by peter_plankskull
Link to comment
Share on other sites

Come on.... it doesn't take being the best or even experience in that field to always be knowledgeable about it. I don't need to be a iron chef with 100 restaurant chains to know that crap on a plate is going to taste awful, and neither do I need to spend a week as a dev to know if a game is good or bad. Yeah I might feel for them a bit more, but overall their still getting paid for doing nothing. Honestly I want to see how much the PVP team in this game gets paid, as they did literally nothing for almost two years.

 

I ... I know this is on page one and were like on four ...but still... thought I would bring this up.

 

Experience in the kitchen, and in the purchasing/distribution center for the restaurant chain, would tell how HOW it got to be bad, not just that it is.

Link to comment
Share on other sites

Would it also be.concievable that SWTOR might be restricted not only by new contract endeavors but old ones that might restrict how they go about bringing in 3rd party people to help ?

 

Any answer on the forums to that question would be complete conjecture. They'd have to tell us and I doubt we merit that much information about their back-end business model.

Edited by xordevoreaux
Link to comment
Share on other sites

Experience in the kitchen, and in the purchasing/distribution center for the restaurant chain, would tell how HOW it got to be bad, not just that it is.

 

I think we only need to look no further than EA and see that they care more about the money rather than a good product now a days.

Link to comment
Share on other sites

For my computer science bachelor's degree I had to take a game programming course. The engine we used was Unity3d.com, from which I was able to create terrains, players, camera, sounds, along with the required code (C#) needed.

 

Still I am impressed huge vast scope and scale of planets and economics involved in this game.

Link to comment
Share on other sites

Armchair game developers are:

a) clueless

b) amusing

c) infuriating

d) all of the above.

 

One is free to have opinions about their work, but one does not have the right to label them 'lazy' without having insider knowledge about what they do and how they do it.

If you did have that kind of insider knowledge, you wouldn't use that kind of label.

 

(This post is not directed at anyone in particular - its just a general response to prevailing attitudes in these forums)

Link to comment
Share on other sites

For my computer science bachelor's degree I had to take a game programming course. The engine we used was Unity3d.com, from which I was able to create terrains, players, camera, sounds, along with the required code (C#) needed.

 

Still I am impressed huge vast scope and scale of planets and economics involved in this game.

 

I so wish computer game courses had been in my curricula when I was in college, but I was there back when Reagan was in office and the computer gaming industry wasn't anything at all like what it is today.

Link to comment
Share on other sites

I wish that the education system would recognize the world we live in and include computing science in with the mainstream curriculum like most places have with physics/biology/chemistry.

 

What's going to be more useful, the knowledge that carbon has 4 valence electrons, and how that controls the chemical and structural formula of hydrocarbons, or some basic programming (probably web stuff: HTML, Javascript and CSS), along with some basic knowledge of symbolic logic and the architecture of the Internet? Throw in some graphics design stuff and you get a pretty good year to build onto the next.

 

When I graduated from high school, the only mainstream computer course taught typing, excel and powerpoint. All good and fine, but most students figured that stuff out years before, and wouldn't mind moving on. Rather pathetic

 

We slap ourselves on the back for having high literacy rates, only to fail miserably on computer literacy, which nowadays is rather important. Maybe if we fixed that we wouldn't have so many useless armchair developers.

 

 

What would be awesome is if these forums could detect a technical post and lock it behind a captcha that delivers a simple technical question to unlock it... wishful thinking I know but oh it would trim the fat off the forums nicely.

Link to comment
Share on other sites

My gaming cs final was a black box shooting red squares at a green box. I passed. I have also worked game engine design professionally for some big named projects. Where the line of demarcation begins is the budget. Big name places have staffing that keeps out in front of a lot of the crap that goes on. When they start re-releasing bugs... Well, someone isn't keep out in front of it. They aren't even keeping to the side of it.

 

Every episode has released with glaring bugs. Zero progression, unplayable/incomplete, not Fire and brimstone/server crash/data wipe (although there have been a few server crashes on release). Be it the Revan fight or the meat stick when ToS dropped, the re-released class completion bit, not being able to finish Ashara's conversation line, Lore entries now being unable to be completed, wiggy gtn search that would reappear, blah blah blah blah blah....

 

In short. QA isn't doing QA, or the management figures incomplete/unplayable = release (which is probably closer to the mark).

 

There may be that one programmer in the back office at BW railing against management that the system is borked and they are working hard to fix it. Tuning algorithms to Log(o) notations, and making everything hum. Given time, this person would have this game so streamlined, it would run on a Nokia 500 cell phone. However, this person is so OCD, they can't even say OCD because the letters are not in the right order. Management won't ever give them the time or resources. Its business. BW decided years ago to keep a minimal contact policy with the forum users. They also decided that the subscriber "free preview" was paid beta-testing... To think they are going to change now...

Link to comment
Share on other sites

Having worked in the dev industry for years I can heartily agree.

 

I still think that all gamers should spend one week in a dev. house in the pit and another week on the front lines (TS/CS).

 

It would open their eyes.

 

Been there, done that on both situations and I have to agree that it helps to understand the complexity of bugs and why it can take a long time to solve. In the programming, things aren't always as obvious as it seems ingame. Not to mention the cause can be completely different from what you expect.

Link to comment
Share on other sites

Been there, done that on both situations and I have to agree that it helps to understand the complexity of bugs and why it can take a long time to solve. In the programming, things aren't always as obvious as it seems ingame. Not to mention the cause can be completely different from what you expect.

 

And, in and amongst those hundreds of thousands of lines of code, there's that chance that when you fix "this", you bork "that". Then the whole process begins anew.

 

I get amused when I see arm-chair "coders" making claims that "this bug" or "that bug" should be easily fixed by a ten-year old. They haven't the foggiest idea.

Link to comment
Share on other sites

Insofar as bugs go, i think most players' gripe is not so much with the developers, than with the management, even if they don't realize it. And another thing is: many problems won't go away faster/easier just by "throwing money" (hiring more people) at it. Being understaffed is one thing, but there comes a point where more staff just makes things worse (too many cooks spoils the stew). Whether we've reached that point, here, with SWTOR, or not is certainly open to debate, and i have no idea of the inner workings of either EA or BW. But it';s something to keep in mind

 

I know if i was a coder working on this game, i certainly would not want to look at the forums at all. Probably wouldn't have time anyways!

 

That's true for me or at least I'd like it to be true, as I have no idea whether certain actions they took in the past were their own decisions or EA's.

 

I understand that smaller but none the less irritating bugs will always make it into the live game and I usually don't b**** about them as long as they get fixed. It's the huge glaring bugs that are so obvious that they simple couldn't have been missed that make me wonder. Like the "meat tree" on Rishi or the solo Revan fight on Yavin for example.

Those are bugs that should've never been released into the live game.

 

So I have to assume that things like that are either EA's fault because they pushed BW to release in spite of those bugs or it is BW's fault for deeming those bugs acceptable in the initial release.

 

Now I wouldn't even be surprised if it was ultimately EA's doing as such behaviour is to be expected from them, but if it was BW's choice, it speaks to a severe lack of pride and commitment towards their own product IMO as the right decision (IMO at least) would've been to delay the release while communicating their reasons for it or pulling extra hours to get the most blatant things fixed in time.

Link to comment
Share on other sites

Possible, both but knowing the code is a huge step toward being able to ferret out problems. Bringing a team from another project could be done but they wouldn't be as efficient and it might end up being "too many cooks spoil the code" :p

 

Fair enough I can understand that. Not the biggest fan of EA but alot of their policies and licensing agreements are fairly rational. I'd have to think if I owned a company that large I'd also be reluctant to hand over code to someone else. Better to be cautious and all, it sucks but at least I understand now why they probably have a small QC team.

 

Preface this by saying I have over a decade on the job coding, and a large portion of that spend maintaining code I and other team members wrote.

 

There are really three elements here.

 

First is QA.

 

In order to do a solid QA job on a product, you have to have a solid idea of how the system works, how it was planned and how it changed during development, or updates. Coming in cold to QA a product can actually help in some ways because you are testing it with fresh eyes, but think of it like police work. You can't patrol a city effectively without knowing the neighborhoods, knowing the people and knowing the weak spots in the overall body politic.

 

In the early days we would send a product out the door fairly confidant it had gotten a good test. To use the Pixar motto, we 'sanded the bottom of the drawers' and then we tested each one over and over with a variety of clothing and towels and anything we could think of. But frankly, as the years have progressed, there has been a creep of more and more laxed assignment of QA resources. As soon as you accept that some bugs will get through to launch, that starts being used to rationalize letting testing scenarios go unaddressed. We CAN'T catch EVERYTHING. And that drives relaxing assigning QA dollars. It sucks and I've sat almost huddled with QA colleagues as we've watched products go out the door that we KNOW aren't adequately tested.

 

Then there are the initial coders.

 

Now this may seen like a strange thing to say, but the more you go up the complexity scale with programming, the more your code and coding choices become akin to music and art. Now I don't mean that in terms of the quality per-say. We'd all like to think we are making beautiful code of course, but most of it is blasted out the hatch, adequate to the task by definition only, and not much more, though we all have exceptions. What I mean by 'art;' is more that there are a million permutations of how to code up a complex system, and your work becomes less a task of obvious construction, and more one of harmonizing all the bits to each other based on your own vision or gut.

 

Then there are the QA and Coder debuggers/fixers.

 

What that leads to is even for those coders who do a good job commenting their work, using sensible and solid practices with regard to code inclusions, file naming and folder structures, proper use of variable naming, application of objects and functions, and all manor of other choices, the end result is almost always very, very personal. Add in the pressure that modern coders are almost ALWAYS under today (being that their time is one of the most expensive bits of the process) and you end up with a very difficult brew for someone else to unwind and work through, searching for buggies to fix....or more to the point, a fix for a buggie!

 

Thus, the point is that bringing in another outfit to debug is up to an order of magnitude (x10) less efficient than having the original authors fix and test their own stuff.

 

It's not entirely unrelated to the concept expressed in Brooks law, which states adding coders to the late stages of a project actually makes it later that if you just bite the bullet and play out the hand.

 

tl;dr =Their guys built it. They are really the only sensible crew to debug/fix it.

 

------------------------------------------------------------------------------------------

 

Two other things to say if I may:

 

1) When modern MMO code is updated, the factor of QA testers to users is very large. We are talking from around 10 people trying to play the game in such a way as to find all the 'oopsies', to in many cases MILLIONS of people playing a million slightly different scenarios, catching FAR more things, naturally!

 

2) One thing that I wonder about is if they are running the exact same server and DB software on QA and PRODUCTION. That is one way that a lot of outfits end up in release hell. God knows I've been in that special hell (:sigh)

Edited by ChakraFive
Link to comment
Share on other sites

 

Preface this by saying I have over a decade on the job coding, and a large portion of that spend maintaining code I and other team members wrote.

 

There are really three elements here.

 

First is QA.

 

In order to do a solid QA job on a product, you have to have a solid idea of how the system works, how it was planned and how it changed during development, or updates. Coming in cold to QA a product can actually help in some ways because you are testing it with fresh eyes, but think of it like police work. You can't patrol a city effectively without knowing the neighborhoods, knowing the people and knowing the weak spots in the overall body politic.

 

In the early days we would send a product out the door fairly confidant it had gotten a good test. To use the Pixar motto, we 'sanded the bottom of the draws' and then we tested each one over and over with a variety of clothing and towels and anything we could think of. But frankly, as the years have progressed, there has been a creep of more and more laxed assignment of QA resources. As soon as you accept that some bugs will get through to launch, that starts being used to rationalize letting testing senarios go unaddressed. We CAN'T catch EVERYTHING. And that drives relaxing assigning QA dollars. It sucks and I've sat almost huddled with QA colleagues as we've watched products go out the door that we KNOW aren't adequately tested.

 

Then there are the initial coders.

 

Now this may seen like a strange thing to say, but the more you go up the complexity scale with programming, the more your code and coding choices become akin to music and art. Now I don't mean that in terms of the quality per-say. We'd all like to think we are making beautiful code of course, but most of it is blasted out the hatch, adequate to the task by definition only, and not much more, though we all have exceptions. What I mean by 'art;' is more that there are a million permutations of how to code up a complex system, and your work becomes less a task of obvious construction, and more one of harmonizing all the bits to each other based on your own vision or gut.

 

Then their are the QA and Coder debuggers/fixers.

 

What that leads to is even for those coders who do a good job commenting their work, using sensible and solid practices with regard to code inclusions, file naming and folder structures, proper use of variable naming, application of objects and functions, and all manor of other choices, the end result is almost always very, very personal. Add in the pressure that modern coders are almost ALWAYS under today (being that their time is one of the most expensive bits of the process) and you end up with a very difficult brew for someone else to unwind and work through, searching for buggies to fix.

 

Thus, the point is that bringing in another outfit to debug is up to an order of magnitude (x10) less officiant that having the original authors fix their own stuff.

 

It's not entirely unrelated to the concept expressed in Brooks law, which states adding coders to the late stages of a project actually makes it later that if you just bite the bullet and play out the hand.

 

tl;dr their guys built it. They are really the only sensable crew to debug it.

 

Two other things to say if I may:

 

1) When modern MMO code is updated, the factor of QA testers to users is very large. We are talking from around 10 people trying to play the game in such a way as to find all the oopsies, to in many cases MILLIONS of people.

 

2) One thing that I wonder about is if they are running the exact same server and DB software on QA and PRODUCTION. That is one way that a lot of outfits end up in release hell.

 

 

 

A most excellent post. And, btw, I don't think it's odd at all to think of code as an art form.

Link to comment
Share on other sites

 

 

 

 

A most excellent post. And, btw, I don't think it's odd at all to think of code as an art form.

 

How very kind of you to say :)

 

I honestly can't recall the last time anyone else noted the point you made that got me a'typin', so honestly kudo's back as well.

Link to comment
Share on other sites

How very kind of you to say :)

 

I honestly can't recall the last time anyone else noted the point you made that got me a'typin', so honestly kudo's back as well.

 

I come from the distant past where keypunch was how things got "coded". It's still magical (FM technology :D ) to me so I suppose that colours my viewpoint as well. For those born into the world when computers were mundane, I can see where they wouldn't have the same appreciation (rather like me and radio, I guess).

 

When people try to sell me on "oh they're just in it for the money", they're showing a fair bit of ignorance. Sure there are "rock star coders" but, in the main, nobody gets rich in that area, many are salaried and not paid by the hour and trust me (preaching to the choir most likely) its out of desire to do it and not money when you realise you are making about 5 bucks an hour trying to find that bloody problem. You have to love what you're doing to pull those hours and stick to it when that blasted bug just will NOT show its face.

Link to comment
Share on other sites

Bean counters. Rabid bean counters are the worst. Management that likes rabid bean counters cause soul rust, drought, acid rain and cooties. Not to mention that they smell of mildew, and moldy elderberries.

 

And This ^^^^

 

That sir est the red tears of poetry man.

Link to comment
Share on other sites

×
×
  • Create New...