OT = How Does Shrapnel Stay In Business - Page 4

Baron Munchausen · #31 August 2nd, 2001, 03:10 AM

quote:
Originally posted by Atrocities:
spirit net, your only on in the after life.

Ditched them a long time ago. Now have qwest DSL. AT&T @ home is just as bad.

Unfortunately I have no choice. It's not 'DSL' for me, it's the uplink for my ISP. So, unless they change providers there's not much I can do. The other ISPs in town are much more expensive than this one.

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

#32 August 2nd, 2001, 03:18 AM

quote:
Originally posted by capnq:
LCC, large chunks of your description sound like what the developers of Master of Orion III are working towards, according to their Web site.

Okay, I checked out the Official site by Quicksilver Software. IMHO this is just a bigger Version of the SOS PHD they put out before, and while that was okay 3-7 years ago, it will NOT compete 3-5 years from now. I bet their AI still has to cheat and not use the same rules as the player just to survive....

Aaron has the right idea for the future, let the players/modders decide what they want the game to be. I propose taking Aarons concept further, but he was by NO means the first to think of this, nor was I of course. The General Purpose Simulator notion has been kicking around for a couple of decades ever since typical machines passed the Megabyte memory stage. (BTW that was thanks to the DEC VAX when they dropped the price of memory from $500,000 per Mb by IBM to $20,000 by DEC - BIG TIME OUCH FOR BIG BLUE!) But you need close to a Gigabyte and a mutiple GigaHertz processor to make it a usable notion. I propose writing the engines of a primitive GPS and providing seed data for a typical "game" along with all the interface required to make it playable. If I do it right, then the engine could be used with the appropriate data to simulate our world economy, or that of a nation, or a city, or a company, or whatever the heck you wanted. I just do not think that there is a market for it yet except as a game, because target specific simulations/ modeling would be MUCH MUCH faster and probably get MUCH MUCH more detailed than the interpretive engine would support on a PC. Of course the supercomputer of today is the pocket pc of next decade. Read John Varly "Marooned in Realtime" IIRC. My SF books have been packed since 89 for lack of shelf space.....

#33 August 2nd, 2001, 04:53 AM

quote:
Originally posted by Baron Munchausen:
LCC, you are smoking something pretty strong if you think a game like you are describing can be done in 50,000 lines.

The power company just taught me once again - NEVER EVER try to type a long post Online - ******* power glitch.
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....

capnq · #34 August 2nd, 2001, 02:14 PM

quote:
I estimate that at 20000 lines, as generic and data driven as possible, based on my experience with the Amiga.

And this is why the younger programmers who've never wrestled with anything but Windows APIs think you're hallucinating.

Bloatware breeds bloatware, and modern hardware capacity allows the majority of programmers to hardly care about resource usage.

I can believe you're capable of writing tight enough code to meet your estimate, but I don't believe such code can be written for any flavor of Windows OS.

Also, I strongly recommend that anyone with unreliable power invest in an uninterruptable power supply.

------------------
Cap'n Q

The most merciful thing in the world, I think, is the inability of the
human mind to correlate all of its contents. We live on a placid
island of ignorance in the midst of black seas of infinity, and it was
not meant that we should go far. -- HP Lovecraft, "The Call of Cthulhu"

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

dogscoff · #35 August 2nd, 2001, 02:19 PM

QUOTE:
--------------------------------------------------------------------------------
I estimate that at 20000 lines, as generic and data driven as possible, based on my experience with the Amiga.
--------------------------------------------------------------------------------

<snip> ...but I don't believe such code can be written for any flavor of Windows OS.
/QUOTE

Write it for the Amiga then. I'll buy it=-)

Better yet, get everyone on the forum to go over to Linux (either by emulation or by pestering Aaron into porting SE4 - see parallel thread=-) and then when you code your game for Linux you'll have a whole market ready and waiting...

------------------
"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?"

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

Atrocities · #36 August 2nd, 2001, 02:47 PM

I wonder what SE V will hold? I wonder if Aaron will bite the bullet and decide to, not that it matters to me I like the game the way it is, to incorperate 3d battle senerios?

Imagine the code that will take.

dogscoff · #37 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 · #38 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 · #39 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 · #40 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....