Yearly incompetent programming

[coogrfan]

Quote: Originally Posted by CM Hooe

The thing is though, Tiburon did internal research of their own engines and determined that those in place on the PS2 / XBOX were not going to be ideal going forward. That decision surely wasn't made in a vacuum and it surely wasn't made lightly, as it involved investing a ton of money into new tech. It's easy for us to say "Tiburon should have stuck with their old tech" using only 2K's work as a basis, but we aren't privy to the technical reasoning behind why Tiburon decided to throw everything out. I think we've been seeing returns on it since the M10 / NCAA 10 games, however, and in particular M13 was a huge leap forward for Tiburon IMO that NCAA should hope to replicate next July.

There's some truth in this, but when one compares the relative state of the Madden/NCAA franchises with NBA 2k it seems clear which approach has proven correct.

It's important to note that MS should probably bare some of the blame for the current state of football gaming as well:

http://xbox360.ign.com/articles/655/655273p1.html

Quote: Originally Posted by State of the Xbox 360: Final Kits, Oct. 2 2005

We had seen the future of HD, and it wasn't all it was cracked up to be. The truth of the matter was that the vacuum of information that created one of the dullest summer sessions in countless years. It turns out this effect was partially created by design, partially because of the late delivery of Beta Kits. Microsoft finally delivered Beta Development Kits in June, several weeks after they were promised to developers. Their delay partially caused the unimpressive E3 showing, but it also meant that developers didn't have the triple-core processors to work with until well into the summer. The kits, as reported in our feature story "Enter the Beta", were unstable and difficult for developers to adjust to at first, but in time their games started showing some breakthroughs. The Beta Kit architecture much more closely resembled the final console architecture, it showed real processing power, and it gave programmers a much clearer idea of how to address the totally new multi-core processors, which game developers had never seen before.

This was significant because it meant that the team responsible for developing the initial Madden 06 (360) (i.e. the basic code that would be the foundation for all of EA's next-gen football titles for years to come) had to do so with only limited knowledge of how the final 360 hardware actually worked.

I'm not saying that MS's failure to deliver beta dev kits on schedule was the sole cause of all of the problems we've seen with EA's next-gen fb titles. There were some very questionable initial design choices made as well, decisions that repeatedly forced the development teams of the subsequent Madden/NCAA's to spend a fair amount of their time trying to fix mistakes made in the past. I am saying that this generation's Madden/NCAA got off to a dreadful start, one from which the series has never fully recovered.

[Isura]

Quote: Originally Posted by Herky

I don't blame the programmers. NCAA isn't coded from scratch each year. The problem stems from the people at the top. They decide what goes in and what comes out each year. When a programmer works on a project that has been developed before, he or she cannot control how framework is, only what goes into it. They aren't going to start over and re-code the entire game unless a new engine comes out. I'm pretty sure they are using the same code going back to 2008 at least. That isn't the programmers choice. They work with what they are told to. It's not uncommon in the software world to re-use old code or build upon code already there. I think NCAA has some big problems, but it's not broken. Some of the logic should and could be fixed by a patch/tuner, but the programmers can't do that until they are told to. It all goes back to the people at the top. Testing is something else that doesn't happened very often by EA. Even the best programmers in the world need QA to re-check things because coding is not easy.

I'm a developer and this is a BS excuse. Programmers have a HUGE impact on the quality of the final product. Regardless of the previous state of the code base great programmers will make the best of it. They will redesign, refactor, fix bugs. With EA/Tiburon the opposite is true. They consistently break old features and gameplay with "fixes" and feature enhancements.

Guess what, my company has code that is 20 years old. We still manage to fix bugs, maintain backward compatibility, add new features, and keep the customers happy.

EA needs to dump the Tiburon shop and find a quality dev shop.

[Aranor]

Alright, so now that we have a skilled developer that knows how to keep old code working correctly while adding new coding, what excuse can there be now for the incompetence of the programming for these football games. Constant glaring broken functions or things that don't work right at all. And the excuse that betrays all when they say "wait for next year for it to be fixed" instead of the year people bought it and expected these programs to be working right from the start.

[The_Rick_14]

Quote: Originally Posted by Isura

I'm a developer and this is a BS excuse. Programmers have a HUGE impact on the quality of the final product. Regardless of the previous state of the code base great programmers will make the best of it. They will redesign, refactor, fix bugs. With EA/Tiburon the opposite is true. They consistently break old features and gameplay with "fixes" and feature enhancements. Guess what, my company has code that is 20 years old. We still manage to fix bugs, maintain backward compatibility, add new features, and keep the customers happy. EA needs to dump the Tiburon shop and find a quality dev shop.

I have to ask a few questions.
What is it that your company makes?
How are your feature deadlines set and who sets them?
How large is the code base?
How many developers are working on overlapping sections of the code base?
How interconnected is the code base?

Not saying your post is wrong, but let's make sure we're actually comparing apples to apples first.

[Isura]

Quote: Originally Posted by The_Rick_14

I have to ask a few questions. What is it that your company makes? How are your feature deadlines set and who sets them? How large is the code base? How many developers are working on overlapping sections of the code base? How interconnected is the code base? Not saying your post is wrong, but let's make sure we're actually comparing apples to apples first.

Deadlines and feature selection is done by upper management. It's an enterprise client-server app. Server side code is approx 500,000 lines (all C++). Application server (C#) and front end client app (Java) is probably another few million lines (I work on server side).

The subsystems are well decoupled for obvious reasons. It is EA/Tiburon's fault if they can't build a game engine in a modular way. That is not really management's fault, it is on the devs/architects.

Rather not get into company specifics.

[Isura]

Also the purpose of my post was not to just bash the devs. I understand that the gaming industry is different and EAs management has a big part in the final result. But it annoys me when people here consistently defend the devs as if they have no input on the final product.

[Herky]

Quote: Originally Posted by Isura

Deadlines and feature selection is done by upper management. It's an enterprise client-server app. Server side code is approx 500,000 lines (all C++). Application server (C#) and front end client app (Java) is probably another few million lines (I work on server side). The subsystems are well decoupled for obvious reasons. It is EA/Tiburon's fault if they can't build a game engine in a modular way. That is not really management's fault, it is on the devs/architects. Rather not get into company specifics.

They've been using the same engine for years. Programmers don't get to chose when they use a new engine. It costs more money to upgrade and those calls come from management.

[PocketScout]

I work in the aviation simulation field. Our code base is over a million lines of code (C++ and Fortran) for each device. We have multiple engineers working on each device at any given time. We use off the shelf computers that interact with real world avionic equipment (the parts are interchangeable in our full flight simulators and aircraft). Our devices must feel, sound and react just as the real aircraft does and we also have full visual systems. (Click Here to see what a flight simulator is if you do not know) Each device is must be FAA part 60 compliant or the flight/training hours are void.

The code base for the simulators was written in the early 1990s and still receives major modifications to this day whenever we add equipment to our revenue fleet or the aircraft has a block point update from the manufacture. These are not simple things and small bugs do show up. But since we are governed by FAA part 60 these must be reported to the FAA if they are not fixed in 30 days and the problem must be fixed by 60 days with the possibility of another 30 day extension.

There is no such thing as a feature that is 85% working, if it doesn't work 100% we have major issues with the FAA and our devices could be decertified.

As for NCAA they have an issue with balancing adding new features to the game to "keep it fresh" and spending time actually fixing many bugs at are in their product and maximizing some of the great feature concepts that they have created. It does frustrate me to see them add new features while there are glaring bugs that should be addressed that are not. Outside the "gaming industry" some jobs do not allow you to actually put out a bug ridden product where major features do not work as per design.