glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[glob2-devel] Core Rewrite Why & How


From: Bradley Arsenault
Subject: [glob2-devel] Core Rewrite Why & How
Date: Wed, 25 Apr 2007 23:43:16 -0400

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]