Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline
|
quote:
ORIGINAL: David Clark
quote:
ORIGINAL: ncc1701e
It is my fear. I am playing solo from time to time not following all patches. But, if Steve leaves, does anyone in Matrix have an idea of the code to take it back?
Nope. MWiF is programmed in object pascal, which is a sufficiently obscure language now that the remaining people who know it command big bucks, certainly beyond Matrix's inclination for a game whose marketing budget is long spent and whose niche-of-a-niche-of-a-niche market already either purchased the product or decided not to. Steve has these huge binders of the source code, but the vast majority of what he knows is probably implicit - approaches he could have taken, but decided not to for one reason or another, and bugs he saw coming and avoided without documenting. It would take a new programmer forever just to acquaint themselves with the code sufficiently to make minor changes, let alone code new features. Consider that MWiF was pretty much written from scratch rather than adapted from CWiF, which was an order of magnitude simpler.
In any case, Matrix doesn't really have 'programmers'. They're an online publisher that provides branding and marketing support, forums and download infrastructure to small groups that already have a largely finished product. What 'should' have happened was when the game was shipped in an unfinished and largely unplayable state, Matrix would have contracted someone to augment Steve and hopefully to take over from him someday. The decision was made to not do that, and I can't really argue. Matrix knows very well that post-release support is usually a waste of money with this customer base (which is mostly composed of game collectors, not game players) except for 'gamer goodwill', which is about as fictional an entity as can be imagined.
Everyone's gotten more than they by rights could have expected - Matrix has another entry in the product list, Steve is still working on his labor of love, and we get a game that works better than our tiny customer base would justify.
One small correction.
The CWIF code was not simpler.
It rarely used case statements, instead relying on nested IF statements for branching logic. For example, using case statements makes it easy to read and understand the processing for the 27 different subphases of naval combat. Similarly processing the 60 different phases of the game.
I also put the code for initializing, processing, and terminating each of the phases into separate modules (i.e., pascal files). As part of those changes, I also standardized the code structure for each phase - you read one and all the others have the same structure. You don't have to twist your mind into a new logic structure every time you change which phase of the game you are analyzing.
Another aspect of the CWIF code that I removed entirely was the use of WITH clauses. [I despise them.] A WITH statement applies to a following block of code and adds a prefix to numerous variables within the code. For example, WITH U (U being a specific unit in the game - e.g., a land unit) means that variables such as MovementPoints, CombatFactors, Name, Country, etc all translate as U.MovementPoints, U.CombatFactors, U.Name, U.Country, etc. That isn't too bad if the block of code is small, say less than 20 lines. But when the block of code is over 200 lines and there are nested WITH statements in the block, it can become virtually impossible to understand. 'Name' could be U.Name, or U.Country.Name, or City.Name, ...
---
MWIF has increased the number of forms in the game enormously over what were in CWIF, and there are also a bunch of new features for optional rules and the player interface. The Delphi compiler tells me that the current number of lines of code is 708,000+ and they are separated into 430 pascal files (which I refer to as modules - Delphi calls them Units which to say the least is awkward when working with WIF code). So, yeah learning the code for the game would take a lot of time and effort.
But the code isn't opaque, and Pascal doesn't have a lot of obscure features like some other languages. More to the point in this instance, I always choose the simplest way to write code and avoid all those "new and wonderful improvements", authors of compilers like to invent to sell upgrades to their product. Give me a FOR loop, a FUNCTION call, rudimentary PROCEDURE calls, a CASE statement, IF .. THEN, and a few variable types and I am happy.
_____________________________
Steve
Perfection is an elusive goal.
|
Printable Version
RE: State of the Game and Future Plans, as of November ... - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread