I have been working on an large, fan-based, freeware project for about 18 months. The project is now suffering from major code-design problems: 1. New features are increasingly taking longer and longer to implement. 2. There is a lot of barely compatible hybrid C/C++ code. 3. System resources need to be optimized at every build. 4. There is no design documentation for large portions of the game. I could go on, but suffice it to say, we are having some problems. We got into this mess because a code design was not fully hammered out before we started work and we have been operating in a "seat of the pants" mode. Anyway, to make an incredibly long story short, the lead programmer wants to scrap what we have and redesign the game from scratch. I will admit, that it is very appealing to throw away the mess and create the game properly. Also, if the current increase in development time continues, it may actually be faster to rework the game than it would be to try to finish with what we''ve got. The problem is that I am loathe to throw out tens of thousands of lines of working (if not ideal) code. Also, This project has been going on for quite a while and I am not sure if our development team, or our fans have the stamina to sit through a redesign. Personally, my goal is to finish the game. I would like to design the unfinished portions of the game, push through with our current code base, and NEVER repeat the mistakes we made again. I may be biased, though, as much of the current code base is my work. I would appreciate any advice you guys have to give. Thank You.

I would print out all the lines of code. Sit down with the other programmers and go through and rearrange the code on paper to suit your needs. See exactly what you are doing on each line and if it''s needed. That way you can keep the lines that are good that took you a bit of time to do. And scrap the parts you think weren''t done to their full quality. I think that would be the best solution. Of course I''m a beginner programmmer, so don''t take me too seriously here.

--Erlog--

Um, . . . if it were feasible to go over each and every individual line, they wouldn''t be worried about throwing it out and rewriting it.

A project in a similar situation to yours was Gabriel Knight 3 (You should be able to find the post-mortem in a Game Developer back issue or maybe on Gamasutra.)

Surely, some of the code must be salvageable? Could you put a feature freeze on one component, and have some people redesign/rework it while progress continues on the others, and repeat that for every major component? Or is the code so hopelessly interwined that''s impossible? Try to erect a facade around each component, and get other components working through that facade. Then you should be able to redesign that component without upsetting too many others.

Thank you, mhkrause, for pointing that article out. I found it on Gamasutra. It was scary how familair it sounded, I think it is time for me to subscribe to a magazine :-).

If I understand your suggestion correctly, the problem with erecting a facade, is that we have a couple of (rather large) core components that need effective two way communication with the other components. The others are just endpoints that take information from the major ones and act on it. Unfortunalely, the current code base consists of these (badly designed) core components and it is becoming a "hack-fest" to get anything done.

Thinking about it more, getting done right, is more important than "just getting done", so I will probably support the redesign effort. There is, as you mentioned, some code that we could probably salvage. In order to avoid the porting problems that the GK3 team reported in the aforementioned article, I will probably ignore the current code base until a design is complete and then look at what can be properly transfered over.

Starting over is highly demoralizing, but not finishing is just not an option. In the event of a redesign failure, we could always go back to the current code base.


Thank you, both, for your advice.

Hi,

I think this is kinda whats already been said but put a different way - but why not try and create interface classes that are basically classes that are how the original code should have been and then alter the code in stages to use the classes. Then, when you have time, transfer the code into the classes so that rather than just being interfaces, the classes are made ''proper''.

Hope that helps!

tip - don''t expose member variables - use get/set methods ''cause then if the implementation changes and the way the data is store alters, the get/set function calls don''t need to change, just the code inside the get and set functions. Also, it makes it easier for debugging and if you make them inline you don''t lose out on speed either.

Yeah, let the programmers answer this one haha

A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

I suggest that, assuming you''re not in striking distance of the end, you spend a few moments with the code you have to remember all the fun you''ve had together and then zip it up, and store it away somewhere where it won''t be bothering you. However look at what you did right and what you did wrong. Make note of the algorithms that worked, and for ones you think did not work, try to figure out what would work better.

Then, redesign and start from scratch. With all this experience under your belts, you should know fairly well what you should''ve done, and now you can do it. Programming should be MUCH faster because you already know the basics of what you want and you already have some ideas for the exact implementation. It will take a few months, but it should be MUCH faster than the first time, and it sounds like you''ll be happier with the result.

A few notes i bet you already know, but i''ll say for safety sake:
1. Premature optimization is the root of all evil.
2. Set out fairly strict coding standards. Keep C and C++ files seperate. They''re both good languages, but mixed, they can be a bit of a pain.
3. Write down your design, and then make notes when it changes. That way, if you don''t have any other documentation, at least you know the general design, and at very least, what the section of code should do. If people have to change a lot of parts of the code to add one feature, this won''t work, but that''s also a sign of bad design.

-ben.c

I''m with Shelrem on this. I''d scrap the project and redesign from the ground up. After taking the necessary time to redesign, you may find that you are able to salvage some of your code. But you may not be able to salvage much. And the worst mistake you could make would be to redesign with the goal of salvaging some of your code. If I''m reading this right, that seems to have been the cause of a lot of the frustration you''ve experienced.

Adding features is enough of a pain when working with well-designed code. But trying to integrate something into a sloppy system is a profession unto itself, called systems administration. Don''t kill yourself over it. Just redesign, and consider this a valuable lesson.

Actually, your experience with this project could be a good lesson for all of us. You might consider writing an article for Gamedev about this, if you can ever stand to look at the code again.

What is faster? Would you rather tie your sneakers all over again, or spend the next hour trying to ger out a massive knot?

Good luck. And don''t worry about your fans. No one minds waiting for a game that turns out great as much as waiting less for a game that is less.

And don''t forget that debugging and playtesting are some of the most important aspects of game development. Would you really want to debug this mess? Or have a friend watch your game crash repeatedly during playtesting? Nothing loses fans like poor product.

~Jonathon

Well, I have supported a redesign, and we have been working pretty consistently on it for the last two weeks. Hopefully we will be able to hammer out a well designed spec in a couple of months and then start coding.

Thank you, all, for your advice. When the game is finished I may very well write an article on it. (Titled: How NOT to make a game :-) ).