Mike C. of Origin Systems writes....

Hey there. I was just browsing through Gamebytes #20 and I ran across the letter from "Richard S." with his suggestions to improve Origin's games.

Richard's back again in this issue if you hadn't noticed yet...

Before I start, I want you to know I'm not a mouthpiece for Origin and if you relate my insights to your readers, I'd prefer not to have my name attached or

Your identity is safe with me, Deep Throat...

referenced, but I thought you might be interested in our side of things from somebody in the trenches here. I've been with Origin for about 3 years and I've seen the troubles and triumphs that have accompanied a wide variety of projects I've been associated with, but for the most part, I just want to address Richard's points.

I yield the floor to Mr. C. of Origin...

Firstly, the savegames in RAM would have been a good idea for Ultima 8, considering the excessive load times it had. It might even have been useful in U7 & U7.5. All those games had to essentially save or load the entire world map (well, objects and their locations, anyway) and all game flags. That's a pretty sizeable chunk of data, as you can imagine. Unfortunately, due to the sheer size of the maps and number of objects in the world, there was just no good way to streamline the savegames, and trust me, we optimize them as best we can with every game. In the case of U8, toward the end when we realized just how bad the load/save times were (and how often you had to do it with all the certain death puzzles we included), there was talk of preserving the last savegame in memory as a quickload feature, but we were so late already that it just wouldn't fit in the timeline and the idea had to be scrapped.

Remember also, that we're trying to keep the system requirements for our games under the 4 meg limit for as long as we can. Richard S., however seems to think that keeping the savegames in memory would speed up the game overall, and I'm sure you realize that's not true. We cache as much as we can internally to the games, but we can only count on having so much memory available to us. Fortunately, many of our games don't have the sheer volume of data to save off that the Ultimas have, so their load/save times arent't as bad. The delay isn't confined to the reading in of the data, either. It also includes the parsing and processing of that data. Load/save time will probably be a concern for the forseeable future, though. The best way to handle it would probably be to keep the difficulty level low enough that you don't have to do it all the time. That's something we're attempting to address in game design now.

Points well made and fully taken... Please continue.

Ok, next, he suggests using the coprocessor on the 486DX to speed up game play. Well, the fact is, our games use very little, if any, floating point math. There are incredibly few games coming from any developer that include support for a math coprocessor, because, frankly, it's not of much use to us in what we do. I think most other game developers will tell you the same thing. It seems to be a fairly common misconception that a coprocessor will either inherently speed up an application or game or that the code can be modified to utilize it. Well, that's just not really the case.

Yes, I agree. There is a very naive believe that simply adding horsepower of any kind, floating point or integer will suddenly make things get a lot more zippy. Simply not the case. Proceed.

Finally, he suggests working entirely in assembly. I'm not really gonna argue this one. The fact is, yes, software programmed competently in assembly is much faster and the instructions can be more efficiently optimized. The bulk of our games are written in C++ with speed critical functions optimized in assembly as much as possible. What it really boils down to is time and the maintainability of the code. It takes a hell of a lot longer to produce optimized assembly than it does to do it in C and compile it and since we're famous for missing our deadlines as it is, we just can't afford the additional delays.

Again, Richard was either a little confused or vague about the size issue in relation to assembly. He seemed to believe that writing the games entirely in assembly would make the games smaller. If he's referring to the size of the executable or the space it takes up in memory, then he's correct to some degree. The .EXE wouldn't shrink that much though, really and neither would the memory requirements. Of course, the bulk of the space our games take on a HD is dedicated to art, sound, and general data files. The only good way for us to address that is to start making all of our games CD playable. That's the direction we're heading. In a year or so, you may well not be able to find a floppy version of our newer games.

That's my hope in fact. I'd also like to see them go further and not only be delivered entirely on CD-ROM, but be entirely PLAYABLE from CD-ROM. No more of this install DMA, base memory address, IRQ out the wazoo, crap either. I have friends here in Houston who simply can't/won't make a decent DOS game work because they don't know a dam* thing about their own computer. And THEY SHOULDN'T HAVE TO! I don't know the IRQ of my VCR and IT HASN'T ASKED ME FOR IT when I want to watch Jurassic Park.
..
Whew...
..
Almost got myself into a bit of a tizzy there! :-)

Anyway, as I said before, I'm not a spokesman for Origin, but I've been here a while, and I have a pretty good grasp of what's going on. Most of what I've related to you comes from conversations with programmers, directors, producers, and the like. It's entirely possible that I may have misrepresented a point or two on the technical side of things, but I think the overview is accurate. Bear in mind that I'm not a programmer, but rather a techical design assistant. We have our problems at Origin, but we're struggling to eliminate them as best we can. We do listen to our customers and we know we're always teetering on the bleeding edge of hardware, but in order to break new ground as everyone expects us to, we have to punch the envelope. We're really sorry that means leaving a few of our fans in the dust.

Once again, if these comments find their way into your magazine, I'd appreciate it if you'd paraphrase and not use my name or position. Speaking publically on the procedures or inner workings of Origin is kind of frowned upon around here. It probably wouldn't get me fired, but it wouldn't help me any either.

Oh, I don't know about that. I believe some of your upper management folks might just like the points you've just made.

Finally, if your readers have comments like this to direct at Origin, a couple of good venues are AOL and Compuserve. They can address their mail to Wayne Baker (but I don't know his address). He routinely scoops up

Wayne has hit the highway, unfortunately. On to greener pastures and we wish Wayne luck in his new adventures. He's been a strong supporter of Game Bytes over the years. Wayne, if you're reading... You're a pal! Thanks!

threads relating to our games out of their forums and reposts them here on our internal email bulletin board system so that we can see what people think and respond to questions or comments. Anyway, I'm very impressed with your publication and I wish you the best of luck with your expansion, whether it's CD-ROM,Mosaic, or whatever. Keep up the good work...

Hmm. I wonder which one it will be??? Thanks for the note!