Firaxis where you want to go?

[Mano3]

To hclass,

Chill out dude. You've got to remember that most people in this forum are die-hard CIV players, and it would take a lot to make them upset over the game due to a few glitches.

Selfish? Nope. I just love the game too much and feel that if it (or anything) is causing that much heartburn, then maybe it's time to to take a break or not even play it. Why play something that makes you mad?

 

[Padma]

Originally posted by Arrogant


Patched code is not "worse code". It usually is "better code". Remember, bugs creep in new, fresh code. If we assume that they recycled Civ2 code to design Civ3, then I am horrified when I think of how buggy Civ4 is going to be if they write it from the scratch. It will certainly have lots of new features and all of them would be un-debugged

I'd prefer a handful of radically new features, and a lot of gameplay polishing.

Thetyper already responded, but I think I need to add my 2 cents.

As I alluded to in an earlier post, I have been in the software business for over 20 years. In my experience, patched code is very rarely *better* code. Especially when you are patching patches on patches. THIS is where many of the bugs come in: when the piece you just patched now works they way you want it to, but you neglect to check *every* possible routine that calls your patched function, and one uses your output in a different manner than you intended. This is particularly true when you have many different people working on the code at different times in its life, all with slightly different understandings of how everything works together.

Also, sometimes, the design of the module is flakey. Or the implementation of the design is off. (This especially happens when you have interns doing some of the coding, which is not unusual - and I *KNOW* it happened with Civ3 ) Take the limit of 512 cities in the game. Theoretically it is possible for that number to be much higher. But the way some of the functions in the game were implemented, any greater number slows the game to an absolute crawl. The programmers know how to fix this, but it would involve scrapping existing code, and rewriting from scratch. But the budget doesn't allow for this, so we live with this arbitrary limitation until they can sit down and write fresh code for Civ4.

Generally speaking, when I see a patch, I think, "kludge", because I know the programmers had to *break* some code to do it. Sure, the final output is (hopefully) more correct, but the code gets messier and messier with each patch, to the point where it can be difficult to understand what it is supposed to be doing.

 

[warpstorm]

Originally posted by Padma
Sure, the final output is (hopefully) more correct, but the code gets messier and messier with each patch, to the point where it can be difficult to understand what it is supposed to be doing.

In my many years as a programmer, I've always seen this on projects that went on for long enough.

 

[TedJackson]

Originally posted by Padma
Generally speaking, when I see a patch, I think, "kludge", because I know the programmers had to *break* some code to do it. Sure, the final output is (hopefully) more correct, but the code gets messier and messier with each patch, to the point where it can be difficult to understand what it is supposed to be doing.

I've worked on two very large "legacy update" projects. One had a small team and a long timeframe, the other had a large team and was supposed to be completed in 12 months. There are no prizes for guessing which project was succesful and which failed

In both cases the system was originally written in Turbo Pascal (DOS based) and had suffered through the "let's make this work in Windows" phase. Of course extra functionality had been added as part of the process.

Both teams had access to someone who had written part of the original code but had moved onto bigger and better things.

It was really funny to sit down with these guys and watch them try to make sense of code they'd written about 5/6 years ago

It made me realise how quickly paradigms and metaphors change in the programming world.


Ted

 

[barron of ideas]

My guess is that the team with more people failed. What is the old saw? "Too many cooks spoil the broth." Of course there is the opposite, "Many hands make light work." But that one doesn't seem to work with programming. And short time frames, while wonderful for focusing the mind of the man to be hanged tomorrow, doen't seem to be really helpful in programming. Right, Cheap and Fast (pick any two) seems to be the way of the world. And sometimes you only get one.

 

[TedJackson]

I gave the game away without really intending to - "supposed to be completed". It's surprising how the subconcious works sometimes

Of course the small team succeeded and the large team failed but one factor that played a surprising part was that the small team were less formally organised/structured and had better opportunities to discuss problems both at the coding and project level.

The solution we developed incorporated an additional "interface" layer where we could make old code talk to new & vice versa. Allowing us to produce new, enhanced functionality that didn't impact horribly on the old codebase. More effort than simply patching old code but it did allow the transition to be reasonably panic-free.

In contrast, the large team (35 or so programmers and, I think 4 project managers) were so isolationist that they wouldn't tell anybody outside their team what day it was

The lesson? Simple, basic communications skills are undervalued in the programming world.

Give me a room full of programmers clustered in small groups talking, rather than a room full of programmers, each with their head firmly embedded in their own screens


Ted