Matrix Games Forums

ORIGINAL: Shannon V. OKeets

Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:

// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;

...

TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);

As I understand this, it really means that there are no generics in Delphi like there are in Java, ADA or C++ templates.

What was the rationale behind the choice of Delphi ?
I know you had no choice ; but did Chris tell you why he chose that framework ?

Yves

ORIGINAL: yvesp

ORIGINAL: Shannon V. OKeets

Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:

// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;

...

TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);

As I understand this, it really means that there are no generics in Delphi like there are in Java, ADA or C++ templates.

What was the rationale behind the choice of Delphi ?
I know you had no choice ; but did Chris tell you why he chose that framework ?

Yves

I don't know.

However, I believe that Delphi was a good choice (maybe the right choice).
---
I've written major applications in C++ (> 100,000 lines of code) and one of its weaknesses is it strength: the ability to do whatever you like as far as variable typing is concerned. Often that is done by inserting C code down at a lower level.

There is a substantial amount of code in MWIF that uses pointers, with the variable type being 'cast' onto the abstract pointer. I am not real happy with that code since it is vulnerable to errors that the compiler can not detect. To give you some insight into how I prefer things, I use AU, NU, and LU as variable names for air, naval, and land units. I restrict using U for a unit to those cases where I do not know the branch of service. In comparison, CWIF used U almost exclusively, which provided less information to me (the programmer) when I was reading the code. I also use Bmbr and Fgtr for bombers and fighters if the code fragment has narrowed down the unit type to that degree.

My point here is that by choosing good names for variables and functions/procedures the code is much easily to proof read. If I never see another Void Pointer in my life, I will not shed hot, wet tears. Being able to override the principle purpose of a language (e.g., Pascal: strong typing) is not a good thing in my opinion. It opens the door for creating code that can go flying off into the weeds without any warning. In essence, I deploy "tricky code" since being able to recognize it and remember what it does is difficult 6 months after you have written it.

Most of the 'tricks' are in legacy code (or taught in computer science courses as "neato stuff"), which were written when available memory was at a premium and CPU speed was a driving concern in order to get a program to function at all. Neither of those should be a factor in 99% of the applications written today. [Of course real-time software is an exception.]

Just my highly biased viewpoint.[:)]

ORIGINAL: paulderynck

There is no major bug. There was a major overhaul of the development platform that caused a number of unanticipated side effects that took time away from development over the last two months. There is further development and bug fixing still to be done. Details regarding the further development outstanding are provided in previous monthly updates.

Thank you so much Paul. You gave me just the answer I was looking for. Hopefully this new development platform will prove itself worthy of so much work, and of course that these unanticipated side effects are as minimal as possible. I also hope all this translates to 'We're now able to push forward.' Godspeed Steve!

I don't know
However, I believe that Delphi was a good choice (maybe the right choice).

Since I have only written once in pascal object, I cannot really tell.

I've written major applications in C++ (> 100,000 lines of code) and one of its weaknesses is it strength: the ability to do whatever you like as far as variable typing is concerned. Often that is done by inserting C code down at a lower level.
...
My point here is that by choosing good names for variables and functions/procedures the code is much easily to proof read. If I never see another Void Pointer in my life, I will not shed hot, wet tears. Being able to override the principle purpose of a language (e.g., Pascal: strong typing) is not a good thing in my opinion. It opens the door for creating code that can go flying off into the weeds without any warning.

I too hate those void* (which sometimes are even void** or worse!) [:D]
You're right, they are holes through which many bugs slip in.

Just my highly biased viewpoint.[:)]

Beeing myself a veteran developper, I fully agree with you (I am also highly biased).
I hope you enjoy yourself on this daunting task!

Keep up the good work, Steve! [&o]

Yves

Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

ORIGINAL: wif_o_matic

Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

Complexity is not really the problem. It is the sheer magnitude of, ..., well, just about everything. If I need to make even a small change, then there are often a 100+ places where that change needs to be made.

ORIGINAL: Shannon V. OKeets

ORIGINAL: wif_o_matic

Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

Complexity is not really the problem. It is the sheer magnitude of, ..., well, just about everything. If I need to make even a small change, then there are often a 100+ places where that change needs to be made.

Strictly as a matter of technical interest (not back-seat driving), this sounds like a good argument that more FTEs on the project would have been more effective.

Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!

The flip side of this, of course, is reducing scope. Here we have a contractual and business commitment to a truly ginormous scope.

ORIGINAL: SamuraiProgrammer

Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!

I think the only drawback to being so well informed about the progress of MWif is that we see the results of months like February; where little game development is accomplished. The nuts and bolts work is not glorious or satisfing except that its absence can ruin a product. All those "nothing new's" are dishearting to the impatient but what was done will silence some of those inevitable post-release " this game is broke" whiners. Sadly no matter how bug free a product it is, there'll be someone who owns a computer that won't run it -- and they'll post a dozen times complaining (take a look at the Guns of August forum).

Thanks Steve for the updates, and the effort.

ORIGINAL: SamuraiProgrammer

Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!

I have a favourite quote (translated from swedish): "-I hate all people that generalize." [:)] While there is some truth in what you are saying(in particular the last sentence), I believe that for most projects the optimal work conditions are created in a harmonized group. The irony is that programmers aren't exactly famous for their social skills [:D]

Regards,
Oscar

Using my own PERT analysis to estimate when the game will finally be released using the following assumptions:

Optimistic: 8 Months
Most Likely: 16 Months
Pessimistic: 30 Months

PERT Calculation: (8+(4*16)+30) / 6 = 17 Months

Using a three point calculation (instead of PERT) with same Optimistic, Most Likely, and Pessimistic assumptions:
(8+16+30) / 3 = 18 Months

Feel free to plug in your own numbers

Next up, some qualitative risk analysis. What is the likelyhood that using old programming code as the starting point for development will result in a complete or partial re-write of code and hence negatively impact the schedule):

Likelyhood: (1=Low, 5=High) = 5
Impact: (1=Low, 5=High) = 5

5*5=25

Congratuations you made top score. (hehe)

But wait, lets subtract the benefits of using the old programming code as starting point, hmmmm.

Keep plugging away Steve, a bump in the road is all.

My only real concern from a risk point of view is the "Hit by Bus" risk. What is the risk response to that one besides sending flowers? What a subject, (brrrrr), but it does have the highest impact of all risks (followed closely by Matrix going tits up). It is also one of the least likely to occur (thankfully). From a risk response point of view Steve, I hope the code has been placed in Escrow for your Wife (or family) or some other agreement is in place. This is a huge investment you have made in terms of time and therefor $$ if an act of god were to occur.

Geez, why am I thinking like this--do not respond Steve. (just wanted to make sure your aware which I'm sure you are).

Don't waste your time reading that Steve and keep working! [:D], I'm eager to beat my friend pinkpanther again, after few years. Scared he even moved out from our city (well, probably his girlfriend has somthing to be) without resolve the question who’s better playing WiF after some games and different scenarios. Well, is obviously for me but not for him and this is our chance to put this on trial [8|]

Yes, and don't leave the house or eat any strange spicy foods. And work dammit-work!!

So given Parkinsons law that work will shrink or expand to fit the time available, can we now set an aggresive date with say two months contingency to account for the unexpected, and work towards that.

Say T + 12 Months.

I'm such a brat.

I guess right now we're waiting for the assembler code to be re-written into this Pasqual. Until that is accomplished, we can expect no progress. Am I to believe this is not finished yet? If not I hope Steve lets us know when it's finished so we can finally, hopefully, have some idea of how long this thing may take.

Am I also to believe that the AI will still present many intangible delays that are impossible to predict, only to the effect that it still may take several years? All I can say to that is ...BUMMER.

But alas, I make one request as I delete this bookmark. Steve please let me know when this project is making tangible progress again. While discussing computer programming may be entertaining to those in the field, the pace of progress is going to drive me crazy.

I have got to take a break from visiting this forum, which translates to forgetting about MWiF. If I'm still at the same email, the most I can hope for is the pleasant surprise that I may still be alive to see the release.

I work in a team of five on a software project, and we have a meeting per alpha release, which is around 6 weeks apart.

Though when taking on a new team member people have a bit of a hard time to contribute 100% I would say that working on a team is rather more productive per hour than working alone, if the team has the right members. But if you work with 20 or so people or more I guess it would be hard to keep such a team productive...

Also, Steve, if you need to change on 100 places to make one change, something needs to be done, Is the inherited code really that bad? Code Refactoring is your friend...

ORIGINAL: CarnivalBizarre

I work in a team of five on a software project, and we have a meeting per alpha release, which is around 6 weeks apart.

Though when taking on a new team member people have a bit of a hard time to contribute 100% I would say that working on a team is rather more productive per hour than working alone, if the team has the right members. But if you work with 20 or so people or more I guess it would be hard to keep such a team productive...

Also, Steve, if you need to change on 100 places to make one change, something needs to be done, Is the inherited code really that bad? Code Refactoring is your friend...

The assembler code used one routine to call 1700+ different functions (a generic 'loop' capability). To replace all those calls with loops required unique control variables for the loops - since they can be nested. Not all the variables have to be unique, but many do. In any event, replacing a single line of code with 8-12 lines of code is not something refactoring handles. In Pascal, the variable are defined in one location and then the loop occurs later.

In some cases I was able to do a one-to-one replacement, and in those cases refactoring would have worked. However, the functions that were called needed to use 'global' variables, since the 'new' calling function was unable to access local variables. So, I needed to examine each of the functions that was called to make sure none of the variables it used were local.

Steve,

To say this is a monumental piece of work is understating it somewhat [:'(]

Thanks for the regular updates - it has been a while but I will read through the 60 plus odd pages and do some catching up.

The screenies look really good mate.

Cheers
-Gil