OT = How Does Shrapnel Stay In Business

dogscoff · #1 August 2nd, 2001, 03:11 PM

I don't know. With the success of SEIV and the amount of work invested in it, I imagine SEV will be a looooooooooong way off. I'd be interested to know just how far Aaron envisages taking SEIV in it's lifespan though.

The demo was SE4.0.99, right?
We're now on SE4.1.41
What about SE4.2.00? I know Version numbering on software is fairly arbitrary, but normally "milestone" Version numbers represent a _major_ update.

Is SEIV even planned to go that far? Does Aaron have a finite list of bugfixes and features to patch, and then SEIV will be complete, or will he just keep adding to it forever? There's certainly scope to add to SEIV indefinitely, there are just so many ideas.

Does anyone remember how it worked with SEIII? Did that Version reach a plateau, where Aaron just said "that's it finished then", or was he improving right up until he started on SEIV?

------------------
"Pinky, are you pondering what I'm pondering?"
"I think so Brain but, if you replace the P with an O, my name would be Oinky, wouldn't it?"

Baron Munchausen · #2 August 2nd, 2001, 04:32 PM

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.

geoschmo · #3 August 2nd, 2001, 06:28 PM

quote:
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.

I can understand your frustration coming from the perspective of a programmer as you do. But don't forget it's all "thingamajigs" that give us a market for all the lines of code to begin with.

As much as some computer nuts (an I count myself in this group, although I am by no means a programmer) hate to admit it, if it weren't for Windows, or something else like it, computers would have never had the mainstream appeal that they do. Without the GUI interface your typical non-techie, the vast majority or the population, would not see the need for having a computer to begin with. They certainly wouldn't plunk down hard earned cash for a game program that's just a series of columns of numbers and text Messages.

Not to mention the fact that you would never have the monster processors and bottomless memory storage that we have today. It's been the added complexity in the programming that has produced the need for the advancments in processing power and memory size and speed.

Geo

[This message has been edited by geoschmo (edited 02 August 2001).]

Alpha Kodiak · #4 August 2nd, 2001, 06:45 PM

quote:
Originally posted by Baron Munchausen:
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?

Actually, if you are smart about how you set it up, the GUI doesn't have to require that much code. It does require a lot of planning and design, but the right tools can supply most of the handlers you need. If you don't properly design it, however....

Nitram Draw · #5 August 2nd, 2001, 07:22 PM

I know that if you are convinced something can't be done you are beaten. I believe anything is possible, especially if you don't know any better.

#6 August 2nd, 2001, 09:02 PM

quote:
Originally posted by Nitram Draw:
I know that if you are convinced something can't be done you are beaten. I believe anything is possible, especially if you don't know any better.

A perfect straight line available when I came back to post! Thanks!

I know about UPS but never needed one before. The problem is a circuit breaker that trips in the new house. I have been informed that the problem will go away in the next few weeks as microfuzz causing heating on the contacts wears down. Since my bank account is seriously depleted by the move, I would have to wait till next month to spring for a 2 hour battery backup UPS anyway, because it costs $200.

Just out of curiousity since there seems to be some interest, I did a web search using Hotbot with the following results :
1) general purpose simulator -44,200 2) same +macro -5900 3) same +parse -1200 4) same +relocatable -56 5) same +overlay -43 6) same + macrocommand -1
So it looks like there is probably action going on, but most of it is not posted where the public can see it. The searches at level 4+ mostly hit on dictionaries.

"What we have here is a lack of communication."

Basically a macrocommand is an instruction in a LANGUAGE INVENTED ON THE FLY. As an example TDS-11 had over 300 macrocommands of varying length written in assembler. Assembler was used because it was a 1982 PDP-11 under RT-11 in a 64k byte address space. So both time and memory were critical. Nowadays a macrocommand would be written in any language at all so long as the MIE and RE working together know how to call and pass a single address to it - the address of its ADB. You invoke a macrocommand in the macrocommand language instruction files by simply giving the name of the relocatable code file as a command name, followed by the list of calling arguments referencing macrocommand variables. Each relocatable file has a function in it labeled the same as the file name, which is the entry point function. The functions in the macrocommand file are allowed to call any function library routine by invoking the engine function calldown with the (engine designer defined) index number of the function to be called and a pointer to a structure containing the required calling arguments of the invoked function. A macrocommand function in one relocatable file is NOT allowed to call macrocommand functions in other relocatable files, because it would not know the address. If you want to do that you do it as a macrocommand language instruction to be parsed. The most powerful macrocommands are CALLU/RETU the universal call/return and FORKU the universal fork. They are provided by the engine designer. Basically CALLU must make sure the invoked macrocommand language instruction file has been loaded into memory, if not load it. Then point to the next line to be parsed in the current file in the macrocommand call stack and start parsing at the line label in the new file's stream of macrocommands. RETU simply pops the stack and resumes parsing there. With FORKU you provide a macrocommand variable name containing an index and a list of macrocommand line labels in the current file being parsed. It works just like a computed goto.

So basically you see that the GPS engine is an interface to an operating system(s) that makes it possible to mix Languages in the same application and to add new functions to an application without having the language specific source code for existing functions - programmers paradise. It does not have to be a linker for labels found in the relocatable files except for the one entry point function in each file because all other labels are resolved locally by the compiler used by the macrocommand author. The TDS-11 engines had to be overlay loaders because of the 64kbyte address space and I see no reason to skip that because I can see this engine being used in applications which exceed a Gigabyte very easily. While at Datapoint in 83-86 I had to write my own overlay loader and overlay manager because the 8600 also had a 64kbyte address space and the Manufacturing Automated Test System I wrote (91000 lines source and still going strong when I left) exceeded the physical (2 megabytes) memory space of the machine as well. With a rich library of macrocommands available for gaming applications, the player can mod his purchased game to be something very different if he so desires by changing the macrocommand language instruction streams, in effect becoming another game author. If that looks too complicated, the player can experient with the configuration generator and the seed data files to create very different game universes, becoming a scenario designer. If the player finds that too complicated, he can just be an emperor using the game AI managers to do the grunt work, with occasional changes to their priorities. If he still does not like what he sees then he can get down and dirty and look at the data being manipulated by the managers to develop his own management rules, becoming an AI designer.

So far as my estimate of source lines goes, you will note that (if I do it at all) I plan to generate a macrocommand library that has only the basics in it. For elaborate games or simulations the designer of the game must invent his own macrocommands and use them with the existing library to generate new macrocommand language instruction files specific to his enhanced game. Seeds and other data needed by the configuration generator would probably also be tailored for new games.

I do not drink or use drugs, so my mind is not fantasizing. I have written over 5000 pages of software from 73-93. I know what I am talking about and am not just blowing smoke. Most of it has been done before, so I have two major concerns :
1) I do not want to re-invent the wheel if somebody else is already doing it.
2) I want TO GET PAID WHAT IT IS WORTH IF I DO IT.

Economics, politics, or warfare it makes no difference, because the interaction between game items is just another black box transfer function based on abilities, dependencies, and derivatives. I am an engineer and design for functionality, when possible also optimizing for time and memory, ie COST. Programmers often do things differently so they look like they are doing a lot of work. As an example of the way engineers see things differently, I can say in one line what Ayn Rand said in 800 pages :
I can do it. You can't, stupid. So PAY me what it is worth.
I suppose that if she had been paid for clarity of thought rather than by the word, she would have written a shorter "Atlas Shrugged"...........

geoschmo · #7 August 2nd, 2001, 10:20 PM

quote:
1) I do not want to re-invent the wheel if somebody else is already doing it.

1) If somebody is working on inventing a wheel, they aren't going to advertise the fact until they have a marketable product. At least they will keep the details protected so noone can come along and "reinvent" it and get it to market faster.

quote:
2) I want TO GET PAID WHAT IT IS WORTH IF I DO IT.

It isn't worth anything until after you do it.

"If you build it, they will come" Not "Announce that you can build it, and they will come and wait while you build it, and pay you so they can wait."

Of course you could get a job at an established software development house, and be a wage slave writing code that someone else will make the money off of and get the credit for. But if you want to be the guy who gets the praise, and the jack, you are going to have to write it, and then sell it. It's called "entrepreneurialism".

Geo

[This message has been edited by geoschmo (edited 02 August 2001).]