Matrix Games Forums

Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

Coder Diary #4 -- All Quiet on the West Front?

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [Current Games From Matrix.] >> [World War II] >> John Tiller's Campaign Series >> Coder Diary #4 -- All Quiet on the West Front? Page: [1]
Login
Message << Older Topic   Newer Topic >>
Coder Diary #4 -- All Quiet on the West Front? - 6/4/2013 11:23:36 PM   
berto


Posts: 18293
Joined: 3/13/2002
From: metro Chicago, Illinois, USA
Status: offline

Coder Diary #4 -- All Quiet on the West Front?


And the East Front? And in the Empire of the Rising Sun?

No way. No summer letup. We continue working on this as hard as ever.

When I first got access to the Campaign Series code in early March, there were two separate codebases

  • the inherited Campaign Series codebase
  • the inherited Modern Wars codebase (a fork of the Campaign Series codebase)

    Since early March, I have been working with a copy of the latter inherited Modern Wars codebase

  • cleaning up, removing legacy cruft
  • reorganizing
  • tweaking and fixing to achieve first builds
  • thereafter, adding new features (windowing the game, hot keys, variable animation speeds, etc.)

    So now, we have a third codebase

  • my Modern Wars codebase (a fork of the inherited Modern Wars codebase)

    That's three codebases in total. It gets to be rather hard to manage, not to mention confusing.

    It is absolutely vital that I merge the codebases! And the sooner the better. Why so?

  • It's less work. One edit vs. two (or more).
  • For better Quality Control. Fix once, in one location, versus twice, in two locations (two or more codebases, the Campaign Series one, and the Modern Wars one).
  • For greater project flexibility, and more frequent builds.

    Where there are multiple codebases

  • Bugs get fixed in some of the games, but maybe not in others.
  • Game features maybe get out of sync.
  • Updates and patches are sequential, not simultaneous.

    No, just by throwing the appropriate IDE switches, we want the capability to rebuild the entire Campaign Series of games (including Modern Wars and all future titles) in an hour or two -- the time required for the Microsoft Visual Studio IDE to compile and link the half dozen or games in the current lineup (EF, WF, RS, and the future ME, VW, and others). With all new features and bug fixes etc. in perfect sync.

    Diff'ing the inherited Campaign Series and Modern Wars codebases, there are



    telemann:/games/matrix/cs/devel # egrep -c "^diff" 20130304_CS_CSM.diff
    122

    telemann:/games/matrix/cs/devel # wc -l 20130304_CS_CSM.diff
    8378 20130304_CS_CSM.diff



    122 files, with 8378 lines (actually more like half that) that differ.

    And let's not forget: My working Modern Wars codebase differs in some measure from the inherited Modern Wars codebase.

    How much greater the pain if I attempt to reconcile all the diffs, merge the several codebases, six months to a year from now (after Modern Wars is released).

    Putting it another way:

  • Merging now, difficult.
  • Merging six months to a year from now, effectively impossible.

    So, by merging now, we avoid the future impossibility. Less pain.

    And more gain. By merging now, we have greater flexibility in our release schedules. (Hint, hint. )

    Not to mention that future titles in the series after Middle East and Vietnam War -- Korean War, NATO Wars, WWI, etc. -- they will come quicker with a merged code base than not.

    Okay, okay, I think you get it: Merge, and merge now.

    Merging is a delicate and arduous process. I have done a global diff of the two inherited CS & MW codebases, with output like so:



    telemann:/games/matrix/cs/devel # head -n 40 20130304_CS_CSM.diff
    Binary files 20130304_CS_MCS_diff/Campaign Series/audiere/bindings/python/pyAudiere.txt and 20130304_CS_MCS_diff/Campaign Series Modern/audiere/bindings/python/pyAudiere.txt differ
    Binary files 20130304_CS_MCS_diff/Campaign Series/audiere/doc/dependencies.txt and 20130304_CS_MCS_diff/Campaign Series Modern/audiere/doc/dependencies.txt differ
    Only in 20130304_CS_MCS_diff/Campaign Series Modern: Btl_gen.bmp
    diff -r 20130304_CS_MCS_diff/Campaign Series/Campaigns Engine/appl.cpp 20130304_CS_MCS_diff/Campaign Series Modern/Campaigns Engine/appl.cpp MERGED
    378,379c378,379
    < case XRussiaNation : cell = RussiaIconCell; break;
    < case XGermanyNation : cell = GermanyIconCell; break;
    ---
    > case XChinaNation : cell = RussiaIconCell; break;
    > case XWarsawPactNation : cell = GermanyIconCell; break;
    1434a1435,1446
    > // V i e w W r e c k C l e a r i n g
    > //
    > // View the results of Wreck Clearing.
    >
    > void ApplWindow::ViewWreckClearing (HexCoor hex)
    > {
    > HasChanged ();
    > _map->DelBurning (hex);
    > _map->DrawArea (hex);
    > }
    >
    >
    1582a1595,1607
    > // C l e a r E f f e c t s
    > //
    > // Do clear effects. April 08
    >
    > void ApplWindow::ClearEffects (HexCoor hex)
    > {
    > ClearSound ();
    > if (_map->Isometric ())
    > _map->AnimateBomb (hex);
    > _map->AddBurning (hex);
    >
    > }
    >
    1599,1600d1623
    < if (_map->Isometric ())
    < _map->AnimateMine (hex, dir);
    [...]



    In my high-tech basement "man cave", I am surrounded by four systems -- Windows, Linux, etc. -- and six monitors, all of them internetworked. I use my swivel chair to turn from one system and display to the next as the need arises. (Crazy, no?)

    I am doing this code merge in Linux. Why? For speed and ease of use. On my dual-monitor Linux systems, I typically have a half dozen to a dozen terminal windows open simultaneously side by side by side:

  • A terminal showing the diffs (the .diff file).
  • A terminal showing the full text of the first file version.
  • A terminal showing the full text of the second file version.
  • A terminal where I am editing (using Emacs) my version of the file.
  • Other terminals where I can do various Linux commands to aid in the diff'ing and editing process.

    I can't imagine doing this work in a single IDE on Windows, without the multiple terminal window and tool support available in Linux. Simply impossible. So I do it in Linux.

    When I am done merging the codebases in Linux, I will re-import the unified all-game codebase back into the Windows IDE, and be on my merry coding way again.

    What's the merging process like? File by file, I look through the diffs, compare and analyze the diffs against the one version versus the other version and edit in the needed changes in my version. Using copy-and-paste and other techniques as necessary.

    What forms do the actual edits take?

    They can be easy, like this diff



    378,379c378,379
    < case XRussiaNation : cell = RussiaIconCell; break;
    < case XGermanyNation : cell = GermanyIconCell; break;
    ---
    > case XChinaNation : cell = RussiaIconCell; break;
    > case XWarsawPactNation : cell = GermanyIconCell; break;



    leading to this merged code



    #if defined(EAST_FRONT) || defined(WEST_FRONT) || defined(RISING_SUN)
    case XRussiaNation : cell = RussiaIconCell; break;
    case XGermanyNation : cell = GermanyIconCell; break;
    #elif defined(MIDDLE_EAST) || defined(VIETNAM_WAR) || defined(KOREAN_WAR) || defined(NATO_WAR)
    case XChinaNation : cell = RussiaIconCell; break;
    case XWarsawPactNation : cell = GermanyIconCell; break;
    #endif



    Then there are the difficult cases, leading to a merged code tangle such as this one



    // MERGE:
    #if defined(MIDDLE_EAST) || defined(VIETNAM_WAR) || defined(KOREAN_WAR) || defined(NATO_WAR) || defined(WEST_FRONT) || defined(RISING_SUN)
    int region;
    sscanf (buffer, "%*d %*d %*d %*d %*d %*d %*d %*d %*d %*d %*d "
    "%*d %*d %*d %*d %*d %*d %*d "
    "%*d %*d %*d %*d %*d %*d %*d %*d %*d "
    "%*d %*d %*d %*d %*d %*d %*d %*d %*d %*d %*d"
    #if defined(VIETNAM_WAR) || defined(KOREAN_WAR) || defined(RISING_SUN)
    " %*d %*d %*d %*d %*d %*d %*d"
    #endif
    " %d", ®ion);
    return (area == region) ? 2 : 1;

    #elif defined(EAST_FRONT)
    return 2;

    #endif





    Yikes!!

    I could show you even more convoluted examples besides.

    In this harrowing process of wrapping '#if ... #endif' preprocessor directives around one snippet of code from another, it is quite easy to

  • Miss a file.
  • Miss a set of diffs.
  • Miss a line.
  • Misinterpret the diffs.
  • Make an editing mistake.

    and thereby apply the inappropriate edits to my codebase, or maybe miss some edits entirely.

    So I can't be rushed; I have to take my time. Rushing through this process might introduce bugs it could take me hours and even days to figure out later (perhaps at a much later date, when the code merge is only hazily remembered).

    By now, I am more than half way through the code merge process. I anticipate finishing up by sometime next week. Then I re-import back into the MS Visual Studio IDE, and I get to see if the whole thing blows up!

    Tedious, boring, slow-going work -- but no less important than the sexy stuff -- adding new features, redesigning the UI, etc.

    Another glimpse behind the scenes:

    A couple of weeks ago, it was reported that in one of the Vietnam War scenarios, a certain mortar unit was unable to fire. Naturally fingers pointed in my direction. (Understandable. No problem.)

    As it happens, the problem was not in the game code; it was in the game data. Specifically, (North Vietnamese) units referenced in the .scn file were missing from the counterpart .org file. An easy mistake to make. Scenario designers make mistakes, I (certainly!) make mistakes, we all make mistakes. This stuff is so mindnumbingly technical, and our brains & eyes are so humanly frail, how can we not make mistakes?

    The game data can be as obscure, complex, and confusing as the CS C++ code. It takes two to tango. It takes both game engine and data to make a game. We can have the most perfect, bug-free game code. But if the game data files are buggy, we have bugs. And vice versa.

    And once again, I turn to Linux (and its Windows cousin, Cygwin).

    Here is a "rather" complex Linux command line to discover (North Vietnamese) units referenced in a .scn file missing from the counterpart .org file:



    $ S="Binh_An_1968"; egrep "[[:space:]]21" $S.scn | awk '$4>20000 {print $4}; $1>20000 {print $1}' | sort | uniq | sort -n > junk1; egrep "P21" $S.org | awk '{print $1}' | sed '1,$ s/^P//' | sort | uniq | sort -n > junk2; cat junk1 junk2 junk2 | sort | uniq -u
    [nil]



    WTF?!



    Let's break that down.

  • S="Binh_An_1968" sets a variable S, for the scenario name
  • ; separates commands, one from the next
  • egrep "[[:space:]]21" $S.scn | awk '$4>20000 {print $4}; $1>20000 {print $1}' | sort | uniq | sort -n > junk1 gets the unit list from the .scn file -- but without the instance counts, just the unit list -- and captures that list to a file, junk1
  • egrep "P21" $S.org | awk '{print $1}' | sed '1,$ s/^P//' | sort | uniq | sort -n > junk2 gets the unit list from the .org file (where sed '1,$ s/^P//' strips the preceding P character), and captures that list to a second file, junk2
  • cat junk1 junk2 junk2 outputs the junk1 file once and the junk2 file twice in succession
  • sort | uniq -u sorts the units, then shows only the units that uniquely appear once in the grand sorted list; if a unit only appears once, it can only only be in the junk1 file, not in the junk2 file (because all units in the latter file are shown twice) -- follow?

    Because that command above yields no output, we can confidently say that, in the Binh_An_1968 scenario, every (North Vietnamese) unit in the .scn file is present in the counterpart .org file.

    Let's see what that problematic Hiep_Hoa_1963 scenario (the one with the mortar fire failure bug) shows:



    $ S="Hiep_Hoa_1963"; egrep "[[:space:]]21" $S.scn | awk '$4>20000 {print $4}; $1>20000 {print $1}' | sort | uniq | sort -n > junk1; egrep "P21" $S.org | awk '{print $1}' | sed '1,$ s/^P//' | sort | uniq | sort -n > junk2; cat junk1 junk2 junk2 | sort | uniq -u
    21049
    21107
    21201
    21402



    Those four listed unit codes -- they are present in the .scn file but absent from the counterpart .org file. The 21107 unit code corresponds to the no-fire mortar unit. Adding it (and the other units) to the scenario .org file fixed the bug. With the .scn & .org files back in perfect sync, the mortar unit was able to fire again.

    Got that?

    Can we automate checking

  • all units (North Vietnamese, US, ARVN, ..., Israeli, Egyptian, ..., German, ... Russian, ... Japanese, ...)

    across

  • all scenarios

    across

  • all games (EF, WF, RS, ME, VN, ...)

    ?

    But of course. Why, yes we can!

    I have begun developing a set of Cygwin-based tools for

  • Checking scenario files for internal consistency (so as to prevent, for example, the no-fire unit bug described above).
  • Checking all game data files for all manner of errors.
  • Reporting game data in easy-to-read fashion (e.g., csoobrpt.pl).
  • Converting hexadecimal C++ unit attribute codes to their decimal .oob file equivalents, and vice versa (csflags.pl).
  • Other purposes and uses.

    I call my toolkit "CSlint":

    quote:

    What is CSlint? Akin to the well-known C programming language utility lint. ("Lint: A Unix C language processor which carries out more thorough checks on the code than is usual with C compilers. Lint is named after the bits of fluff it supposedly picks from programs." See here.) Similarly, CSlint is a toolkit of programs designed to discover and report bugs, problems, glitches, anomalies in the Campaign Series game data files.

    With the CSlint toolkit, there are all manner of things we can QA check (and all manner of things we can make easier).

    And because our computers are so fast, we can run these checks in just a few minutes, across all games. As often as we wish! Create a scenario, edit a unit file, run the QA tools on the spot. Real-time QA, as we develop. Not post-release.

    Bless their hearts, other members of the Development Team have taken the leap of faith with me, installed Cygwin on their systems, and begun learning some of this Linux/Cygwin wizardry -- magic that will help to discover and weed out mistakes and to make for a much better, less buggy game.

    It is entirely within the realm of possibility that we will release these tools, and tutor their use (also Linux/Cygwin techniques), to the general player/modder community. So as you design your own scenarios, you too can benefit from some of the design, management, and Quality Assurance tools that we the Development Team are using.

    But that's for the future. For now, despite the apparent quiet, rest assured: all things are not quiet on the CS development front. Far, far from it!

    Until the next time ...

    < Message edited by berto -- 6/5/2013 7:55:38 AM >


    _____________________________

  • Post #: 1
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/5/2013 3:19:45 AM   
    junk2drive


    Posts: 12907
    Joined: 6/27/2002
    From: Arizona West Coast
    Status: offline
    Don't blame junk2, I had nothing to do with it

    Thanks for the update.

    (in reply to berto)
    Post #: 2
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/5/2013 5:52:35 AM   
    Crossroads


    Posts: 15164
    Joined: 7/5/2009
    Status: offline
    Wow, the most exciting news as of yet. Achieving the near impossible of joining all the code bases into one would be awesome. Good luck!

    _____________________________

    Visit us at: Campaign Series Legion
    ---
    CS: Vietnam | CS: East Front 1939-1941 IN-THE-WORKS
    CS: Middle East 1948-1985 Fully reimaged v2.0 available now!

    (in reply to junk2drive)
    Post #: 3
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/5/2013 2:31:05 PM   
    Josh

     

    Posts: 2721
    Joined: 5/9/2000
    From: Leeuwarden, Netherlands
    Status: offline
    "...Got that? ..."

    Errrr.... no?
    I say, most impressive stuff  hats off to your elite programming skillz


    (in reply to Crossroads)
    Post #: 4
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/5/2013 8:29:52 PM   
    wings7


    Posts: 4608
    Joined: 8/11/2003
    From: Phoenix, Arizona
    Status: offline
    berto, thanks for the update!

    (in reply to Josh)
    Post #: 5
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/6/2013 12:23:27 PM   
    kool_kat


    Posts: 554
    Joined: 7/7/2008
    From: Clarksville, VA.
    Status: offline
    Hey Beto:

    Thanks for the detailed and... to my "non-programming mind"... mostly meaningless text strings?

    It certainly looks like a herculean effort on your part - THANK YOU VERY MUCH for all your hard work!

    Maybe less "programming language" updates... and more "how does this impact JTCS"... and "why I should care" kinds of explanations would be more enlightening to me.

    < Message edited by mwest -- 6/6/2013 12:24:06 PM >


    _____________________________

    Regards, - Mike

    "You have to learn the rules of the game. And then you have to play better than anyone else." - Albert Einstein

    (in reply to wings7)
    Post #: 6
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/6/2013 12:43:05 PM   
    berto


    Posts: 18293
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    quote:

    ORIGINAL: mwest

    Maybe less "programming language" updates... and more "how does this impact JTCS"... and "why I should care" kinds of explanations would be more enlightening to me.

    But if you skim through the technical stuff, your eyes might alight on:

    quote:

    ORIGINAL: berto

    ...

    No, just by throwing the appropriate IDE switches, we want the capability to rebuild the entire Campaign Series of games (including Modern Wars and all future titles) in an hour or two -- the time required for the Microsoft Visual Studio IDE to compile and link the half dozen or games in the current lineup (EF, WF, RS, and the future ME, VW, and others). With all new features and bug fixes etc. in perfect sync.

    ...

    And more gain. By merging now, we have greater flexibility in our release schedules. (Hint, hint. )

    Not to mention that future titles in the series after Middle East and Vietnam War -- Korean War, NATO Wars, WWI, etc. -- they will come quicker with a merged code base than not.


    ...

    I have begun developing a set of Cygwin-based tools for ...

    ...

    With the CSlint toolkit, there are all manner of things we can QA check (and all manner of things we can make easier).

    And because our computers are so fast, we can run these checks in just a few minutes, across all games. As often as we wish! Create a scenario, edit a unit file, run the QA tools on the spot. Real-time QA, as we develop. Not post-release.

    Bless their hearts, other members of the Development Team have taken the leap of faith with me, installed Cygwin on their systems, and begun learning some of this Linux/Cygwin wizardry -- magic that will help to discover and weed out mistakes and to make for a much better, less buggy game.

    It is entirely within the realm of possibility that we will release these tools, and tutor their use (also Linux/Cygwin techniques), to the general player/modder community. So as you design your own scenarios, you too can benefit from some of the design, management, and Quality Assurance tools that we the Development Team are using.

    But anyway, if all I/we are doing is behind-the-scenes technical stuff, and we don't report it because we think the players might not be interested, then you guys might think we are slacking off, right?

    < Message edited by berto -- 6/6/2013 1:50:30 PM >


    _____________________________


    (in reply to kool_kat)
    Post #: 7
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/7/2013 6:47:35 PM   
    Kineas


    Posts: 100
    Joined: 4/19/2008
    From: EU
    Status: offline
    I see someone really loves Linux ;)

    I have to point out that merging is perfectly possible on Windows - which also happens to have multiple monitor support. (Check out: http://stackoverflow.com/questions/460198/best-free-3-way-merge-tool-for-windows).

    Since Microsoft is intent on destroying the windows desktop we probably end up using Linux anyway :)

    Condolences for the 8000 line merge. How could that happen?

    (in reply to berto)
    Post #: 8
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/7/2013 9:34:06 PM   
    berto


    Posts: 18293
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    quote:

    ORIGINAL: Kineas

    I see someone really loves Linux ;)

    A Linux devotee since 1992.

    quote:


    I have to point out that merging is perfectly possible on Windows - which also happens to have multiple monitor support. (Check out: http://stackoverflow.com/questions/460198/best-free-3-way-merge-tool-for-windows).

    No doubt. I use both, and generally prefer Linux for the heavy-duty stuff.

    quote:


    Since Microsoft is intent on destroying the windows desktop we probably end up using Linux anyway :)



    I want my Ubuntu Phone, and I want it now!

    quote:


    Condolences for the 8000 line merge. How could that happen?

    My predecessor would have to speak to that.

    _____________________________


    (in reply to Kineas)
    Post #: 9
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/8/2013 11:46:56 PM   
    TAIL GUNNER

     

    Posts: 1154
    Joined: 4/27/2005
    From: Los Osos, CA
    Status: offline
    Greetings berto,

    I'm curious if you plan to make the game moddable without having to have the modded files encrypted by a third party?

    Haven't played CS in years...but will be watching your progress and wishing you the best of luck.

    (in reply to berto)
    Post #: 10
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/9/2013 5:02:14 AM   
    berto


    Posts: 18293
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    quote:

    ORIGINAL: Juggalo

    I'm curious if you plan to make the game moddable without having to have the modded files encrypted by a third party?

    Maybe not, but this is under discussion. It's not for me to decide.

    _____________________________


    (in reply to TAIL GUNNER)
    Post #: 11
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/13/2013 4:26:14 AM   
    dogovich

     

    Posts: 11
    Joined: 10/27/2005
    Status: offline
    quote:


    Condolences for the 8000 line merge. How could that happen?


    My predecessor would have to speak to that.

    _____________________________

    Hello, in case anyone has forgotten, I'm Berto's predecessor, and by the way, I think he's doing a fantastic job.

    As to why there is such a large number of differences between the two code databases, I think I need to go back into the history of the game.

    When Talonsoft first wrote and developed the code, they followed a process that was very much like that towards which Berto heading. They basically used one set of code to cover all three of the original games, and so were able to make changes to each of they games without having to resort to keeping track on three different sets of code. However, something different happened when they developed Divided Ground and they ended up with two different code sets. This was most likely due to the nature of the weapons being used along with the time periods being encompassed. In any case, they ended up with a unified set of code for the original campaign series (WW2), and slightly different set for Divided Ground. When Talonsoft fell apart the Divided Ground code set was lost and all that remained was the WW2 set. But between that fall of Talonsoft and the acquisition of the game by Matrix, a vigorous period of moding took place, the result of which was the creation of the DGVN mod and the addition of various new countries to DG. We as modders had to way of adding additional country slots to the game, so instead we replaced the countries that had originally been occupied by WW2 nations with modern nations... i.e. Japan became North Vietnam, the Netherlands became the ARVN, and so on.
    Later, when we started work on updating JTCS WW2 for Matrix, there was a huge push to add new countries to the original nations list. That, and making what improvements we could enhanced the game, but right before the last update was complete (1.04) work was also begun to restore Divided Ground and to also add the Vietnam War (based on my Vietnam mod using Jorge Grillo's collection of Scenarios). Since we didn't have the code set for Divided Ground, I recreated it using the WW2 set and making modifications needed to make it work in the modern era (1948-1999). That was accomplished, but the price that was paid was that we ended up with a nations list that was totally different from that used by JTCS 1.04 (I think it could actually have upwards of 50 nations vs about 30), and we also were making improvements relative to Vietnam and the modern era. Meanwhile, JTCS 1.04 kind of sat there untouched. Added to this was the need to incorporate a set of datebase and graphical files that were unique to the modern era but which conflicted with the WW2 version, and example being that in place of the Soviet Union in country slot 0 for WW2, we have the Peoples Republic of China, and so on. But the biggest code change occurred when I redid aircraft so that they could cross over enemy units and vice versa. Works great, but it wasn't retrofitted back onto JTCS. So long story short, that's how all of the differences came about.

    On the other hand, the vast majority of the code in each of the sets is absolutely identical, and except for the differences in countries and such, it is mostly compatible back and forth, at least processing wise. We (my predecessor and I) actually changed very little from what the original Talonsoft programmers wrote, but mainly limited ourselves to what we could tweek here and there, or add easily without effecting the overall processing of the game. But the whole code set dates back to the mid 1990s, and was written in Visual C++ Version 6. Cutting edge stuff back then, but somewhat dated now. I was fortunate to be able to acquire a Version 6 compiler, and had the assistance of some of the Matrix coders in getting it set up and started. It has performed wonderfully all of these years. But Berto is doing the best thing possible by using his greater expertise to actually convert the code to something more modern and also to combine the whole mess back into one code set. The guy is a genius, and is much better at interacting with the public than I was. So I wish him well.

    (in reply to berto)
    Post #: 12
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/15/2013 8:19:23 AM   
    Crossroads


    Posts: 15164
    Joined: 7/5/2009
    Status: offline
    I can only imagine what a daunting task the legacy codebase has been to both of you guys.

    Of course I have no idea how well Talonsoft managed to keep it all together, but remembering they had four different games evolving over time it must have been a challenge to them too: EF -> WF -> EF2 -> RS -> DG.

    Did I say four different games? Make that five different games.

    And then the latest codebase of DG got lost...

    Future looks good though

    _____________________________

    Visit us at: Campaign Series Legion
    ---
    CS: Vietnam | CS: East Front 1939-1941 IN-THE-WORKS
    CS: Middle East 1948-1985 Fully reimaged v2.0 available now!

    (in reply to dogovich)
    Post #: 13
    RE: Coder Diary #4 -- All Quiet on the West Front? - 6/15/2013 12:42:15 PM   
    berto


    Posts: 18293
    Joined: 3/13/2002
    From: metro Chicago, Illinois, USA
    Status: offline

    The Campaign Series of games is actually one of the more difficult game series to code manage.

    We currently have three games

  • East Front
  • West Front
  • Rising Sun

    not to mention several expansions and variants thereof (West Front Sea Lion, Divided Ground, battle packs, etc.) that still haunt the code.

    Also soon to be two new games

  • Middle East
  • Vietnam War

    with several more on the distant horizon

  • Korean War?
  • NATO War?
  • World War I (West Front? East Front? Italian Front? etc.)?
  • others besides?

    so provision has to be made for them too.

    Then for each game we have

  • engine, the actual game .exe
  • frontend, the scenario selector and game launcher
  • edorg, the OOB editor
  • edmap, the map editor
  • edit, the scenario editor

    That's how many .exe's to manage? 5 X 3, 5 X 5, 5 X ... ?

    Over the years, with how many different coders and coding teams?

    So many game-conditional preprocessor directives ('#if defined(MIDDLE_EAST) || ...')! Such an "ancient" codebase! So much obsoleted, commented out code! So much legacy cruft and code garbage!

    And let's not forget the thousands of game data files -- graphics images, OOBs, maps, scenarios, ...



    _____________________________


    (in reply to Crossroads)
  • Post #: 14
    RE: Coder Diary #4 -- All Quiet on the West Front? - 8/4/2013 7:26:42 PM   
    TAIL GUNNER

     

    Posts: 1154
    Joined: 4/27/2005
    From: Los Osos, CA
    Status: offline

    quote:

    ORIGINAL: berto


    quote:

    ORIGINAL: Juggalo

    I'm curious if you plan to make the game moddable without having to have the modded files encrypted by a third party?

    Maybe not, but this is under discussion. It's not for me to decide.


    This one issue is what drove me away from modding the game...and several others including one incredible artist.

    This is the only game in my vast library that requires such an inane procedure..

    Thank you for the consideration,
    ChadG

    (in reply to berto)
    Post #: 15
    RE: Coder Diary #4 -- All Quiet on the West Front? - 11/3/2013 12:14:30 AM   
    junk2drive


    Posts: 12907
    Joined: 6/27/2002
    From: Arizona West Coast
    Status: offline
    bump 4

    (in reply to TAIL GUNNER)
    Post #: 16
    Page:   [1]
    All Forums >> [Current Games From Matrix.] >> [World War II] >> John Tiller's Campaign Series >> Coder Diary #4 -- All Quiet on the West Front? Page: [1]
    Jump to:





    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
     Reply to Message
     Post New Poll
     Submit Vote
     Delete My Own Post
     Delete My Own Thread
     Rate Posts


    Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

    0.148