To summarize my other email in the other thread: 1) We need a core rewrite? Why? Becuase Glob2's existing code is really a mess, in certain areas. Plain and simple. Doesn't matter who's fault it is for making it a mess. And i'm sure at one point it wasn't a mess. Probably not that long ago. But its a mess now. And there is no changing that fact unless we tidy it up.
2) Why is a mess bad? Well it makes it harder to code new features. You want new features? Want a great **game**? Well someone has to code those features. And right now those features are hard to code. Why? Because the code is a mess. You have to dig through megabytes of code to understand all of the semantics that go into a simple change. Glob2's code just isn't maintainable, a small change causes changes in many places. 3) How does a rewrite fix a mess? Well a rewrite gives us the chance to define things with a new understanding of what is required of the code. XP programming explains that requirements on code change often and frequently, and structural changes are inevitable. This is ohh so true. Glob2 is in long need of redefining the semantics of all the classes. Reducing them back to the simplicity they once had, so that future and current programmers have an easier time. 4) The way I use rewrite is a mis-nomer: The code isn''t rewritten from scratch. Indeed, in a few areas, this is exactly what I'm doing. But for the most part, I'm moving existing code around. I'm making new functions, copying and pasting existing code, and maybe changing one line or two to suit the new arguments to the function. And then I add documentation to that new function that explains what that function does. There isn't much rewriting, just reorganizing, and lots of reading. 5) Want an example? Look at all of the init functions in Engine.cpp. Right now I'm replacing the majority of that code with code that manipulates MapHeader and GameHeader. There will be one init function that takes the two headers, loads the map, and initiates a game. Another function would generate a GameHeader for a campaign map. Campaign maps have the properties that there is one local player, and several null AI's. GameHeader can also be created by the GUI, when the user selects options they want for a particular custom game. The GameHeader could also be received over the internet. And it could also be loaded from an existing game save. And as a new feature in the future, the game header could also be saved as a "preset settings" for a custom game. In all these examples, the same init function would be called, just different GameHeaders would be supplied. If you implemented a related new feature, you could place it in GameHeader, and everything would work. Why? Because everything uses GameHeader. That is maintainability. -- Really. I'm not lieing. Bradley Arsenault. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
