quote:
Originally posted by LCC:
Okay, I will be brief. Way back in 82 I worked for a (long dead) company called NL McCullough Wireline Logging. They had a BIG TIME problem. Their customers all had a different notion of how to interpret the data coming up out of their oil wells. Although it paid BIG BUCKS ON BIG TRUCKS to service those customers, it was no where NEAR enough to support writing a customer specific realtime program for each one. Also, they had to support requests from geologists to change the formula used to generate the graphs in the next FIVE MINUTES. The data had to be done right and done NOW because the decision to take more depended on what they saw, and it cost $2-20 MILLION PER DAY for downtime on those wells. So the guy I worked for (Mike Smith, still out there somewhere?) had a BRILLIANT notion. (Those of you who are software developers will recognize his notion as similar to later Versions of Basic, but THIS WAS 82!) He developed a macrocommand interpreter engine (MIE) and a runtime engine (RE) to use its output. Basically a macrocommand was an assembler language function with just one call parameter - the address of an address/data block (ADB). The ADB size varied but contained just one kind of parameter, the address of an input/output parameter for the function. So with a little indirection it looks the same as any multiple argument function call. What the MIE did was parse the macrocommand language (TDS-11) file line extracting the function name, and text argument list. If the function had not already been loaded into memory then its name would be used to open the relocatable file and overlay load it into memory (the PDP-11 used was 64kbytes ADDRESS space) The list of arguments was translated into the adresses of standard data storage blocks with offsets for the specific variables. Then the function address was added to a chain of function calls along with the address of the ADB into which the variable addresses had been placed. When the file had been completely interpreted you would run the RE to execute the chain of function calls, passing the ADB pointer to each function. It was up to each macrocommand to correctly process its input list, calculate the outputs, and place them at the proper addresses. If the customer wanted to change the TDS-11 instructions, then all the MIE had to do was remove changed links and insert the new ones into the proper point in the list of function calls. The TDS-11 language was so simple that even the customer geologists could write and maintain their own custom programs. All of this was done in 82 on a miserable PDP-11 with less than 10000 lines of source code for the engines. So having seen it done, I KNOW HOW TO DO IT, AND ANY REASONABLY INTELLIGENT COLLEGE FRESHMAN COULD DO THE SAME USING THE DESCRIPTION I JUST PROVIDED.
Okay, so much for the language engine at 10000 lines. The other tricks lie in system and user interface of course. I estimate that at 20000 lines, as generic and data driven as possible, based on my experience with the Amiga. The final Category is the macrocommands to be interpreted by the engine and which in turn use the data files to either generate more macrocommands or to process the game data. What I plan is generic black box functions to do a variety of data manipulations, but NONE OF THEM HAS TO KNOW WHAT THE DATA MEANS. That's why I feel confident that 20000 lines will be sufficient...
So having spent a year or two writing that stuff I will still face the problem of game data - which could take another year just to create the tens of thousands of lines of names and numbers for the seeds to be used by the configuration generator. Plus all the audio and video files too of course, never forget that! But that can be done by OTHER people, and probably will be....
This sounds fine for the 'old school' wargame that uses ascii graphics to represent the planets and ships!
I can believe that very elaborate games can be designed with relatively little code if all you are doing is the simulation mechanics of the game itself. What will kill you is making the GUI interface to all the various aspects of the game so people can play the way they expect with the mouse/trackball/whatever. Displaying all the fancy dialog boxes and adding all the 'mouse events' will take several times the code of the game engine itself, I think. Maybe you could make a client/server system like VGA Planets? Or maybe the latest VGA Planets is already everything you had in mind for this project?
It is somehwat annoying to think of how much of our computer power gets eaten by these fancy doodads. Do you realize that the old way of even
measuring computer power, MIPS (Million Instructions Per Second) is now obsolete? An AT-20Mhz would do something like 1 MIPS. A relatively standard desktop now does something like 100 MIPS. The number has gotten so huge that it doesn't tell you anything anymore about the real abilities of the computer to run current software. Then there's the gigantic leaps in RAM and HD capacity. Think of the incredible things that could have been done in the 1980s with this kind of power! But it's being eaten by these stupid GUI systems and all the kewl 'multimedia' thingamajigs tacked onto our WinDOS systems.
Re: OT = How Does Shrapnel Stay In Business
Threaded Mode