|The History of Pie in the Sky Software Part 3|
|Written by Administrator|
|Sunday, 14 March 2010 23:45|
The Progression to Windows
The writing on the wall indicated that DOS's days were numbered. After ignoring the game market for years, Microsoft showed sudden interest. Microsoft had put substantial effort into Direct3D, a high performance 3D graphics API which was totally free for developers. When I spoke with Microsoft employees about it at the Computer Game Developer's Conference in Santa Clara, the story was that they had collected mountains of data from PC users about how they use their computers, and games were marked very low. However, when they looked at the number of copies of game software being sold it did not agree with their survey data. Their conclusion was that PC users did not feel comfortable admitting that they liked to play computer games even on an anonymous survey. But the truth is, the PC users were actually playing games quite a bit.
And so, Microsoft very shrewdly did not want OpenGL to be come the standard API for games, because that was Multi-Platform. Now Multi-platform would be considered an obscene concept to Microsoft execs, because multi-platform means that you don't care which operating system is on your computer. And so to make sure the game development for PC's did not go the Open-GL route, Direct3D was born. At the time I didn't realize why Microsoft was being so 'nice' to us game developers. They would ship us free DIrect3D Development CD's. The documentation was pretty good, and there were lots of working example code to start with.
It worked. Direct3D which became known as a larger group of high performance media and gaming technologies under the name DirectX became the ascendent API for PC games.
But lets step back a little bit. Even in 1994, it was clear the DOS world was going away. Then in 1995 we released our GCS. It would run on Windows 95, but it was clear the future would not be in DOS games running in a compatible mode. I knew that the future would be in leveraging 3D API's and not with hand-made custom 3D engines. I decided to invest in Criterion's Renderware graphics library. It was cross-platform, and would use a software renderer if there was no 3D hardware, and or use whatever technology was available in a way that was nearly seamlessly to the developer. There was an upfront cost which was not insignficant, and then a per unit royalty on copies sold.
And so, I began work on a new game engine, except this one would be an outdoor terrain based game engine with a virtually unlimited universe size. A friend of mine in North Carolina called me up looking for a job during that time. I told him I can't afford to hire him, but while he was looking for a real job he could collaborate with me on making a 3D vehicle simulation.
Over the next few years Eric worked out an excellent 3D vehicle physics package, while I coded up a decent outdoor terrain engine, while Colin made some beautiful 3D models for vehicles and other objects. The result was a game which was great fun to play. The physics was phenomal and the graphics of the engine were ok for the time.
Not Off to a Good Start
After years of effort, done while continuing to update and support the GCS, I created some CD's and began sending them out to game publishers. The first reply back was devastating. The publishers' tester had not only not liked the game, but written a scathing paragraph dripping with sarcasm as he mocked the positive statements I had written on the documents which accompanied the demo.
In retrospect I should not have been so depressed by that. The style of the writing and the unprofessional nature gave the impression that the reviewer was probably a teenager or somebody not much older than that.
But still, the reviewer's point of view had merit. Baja Bash was a very fun game, but it was closer to Corncob 3D in that it was on the surface slow and boring with somewhat clunky looking graphics. But the fun of the game had to do with the physics,and learning what your vehicle could do and what it couldn't. So I didn't send it out to any other publishers right away because I had to decide what could be done to improve it.
After giving it some thought, I decided to go the shareware route. That way we don't need to pass the hurdle of getting a publisher to accept it, and we don't need to trust them when it comes to sales figures. So that in itself meant a lot of work, separating the single game into two versions, the shareware version and the registered version.
So I decided it was time to call Criterion Software to find out how we could handle the royalties for a shareware product.
And It Gets Worse
Criterion did not have a royalty plan that would work for a shareware product. I do not remember the details, but it was either a huge upfront fee, or a per copy fee which would include all the copies made of the shareware version, which of course I had no control of. But whatever the deal was, it was just not possible to go this route with a Renderware-based game engine. So it was time to finally take a closer look at the Direct3D api, which was now more mature and 100% royalty free. As I got into it I realized that creating a Direct3D version of the Pie 3D GCS engine would actually be quite easy, however, the Baja Bash engine would be more challenging. So faced again with choices based on my limited time to spend on development I had to look at what would give us the most benefit, to port the Renderware Baja Bash game to Direct3D, or port the Pie 3D GCS engine from DOS to Windows DIrect3D.
I decided that I a huge base of GCS customers, and a sizeable percentage of them would buy a new GCS so they could update their games. Those were like the bird in the hand. Baja Bash was the bird in the bush. Plus, the port to Windows looked fairly easy for the Pie Engine. The new plan was to port the Pie3D engine to Direct3D, and release it, and then port Baja Bash and release that as shareware.
And so work commenced on GCS 3.0 for Windows. Getting the basic engine going went fairly quickly, and John W. was very helpful in implementing cool extra features to extend the capability. The picture at the left shows a scene with the original DOS gcs. On the right is a show with the new windows engine. We had lighting effects, fog, color lights, terrain, and finally material effects like shiny surfaces and translucent panels.
On the left is Santa's Rescue, a little game made with the DOS GCS. The weapon was a magical candy cane which would set the forest animals free.
On the right is a GCS 3.0 game, with 3D modeled props such as the lighting fixture and the chairs, with the the semi-transparent window looking out into another area of the level.
The GCS sales continued to come in, but even after all this effort, the advances in 3D technology were coming in so much faster than I could handle that it just seemed like there was no place for the small developer in the world of 3D Games. It didn't make any business sense to continue, and so it was time to stop trying. Sales of GCS were suspended and I still provided tech support for a time but eventually when something went wrong with the website I just took it down.
I think in the end it became evident to me that I was really lousy at business decisions. It was very depressing to feel like everybody had been let down, both the customers even more importantly, the people who had been part of the business. I would like to think that now I am much wiser and if I were able to go back in time I could do everything right. Maybe so but probably not. But just for the heck of it, I'll try identifying the major flaws in the over plan which ended in the business shutting down.
Let's assume that InnerMission and Corncob3D were the right decisions. Both were fun and successful, and really had no downsides. After Corncob 3D came the Pie 3D Game engine for DOS, and the retail deals. This is probably the first mistake. When ID software released Castle Wolfenstein 3D, everybody realized that PC's could do textured 3D graphics, and so the market jumped in. 3D Shooters were popping up everwhere, many with fleets of programmers and artists.
So for a small developer, trying to jump in the same direction as rest of the market was a futile exercise. The place to be for a small shop is in the niche markets, where the large companies doesn't see enough profit potential to bother with. So what direction should PIe in the Sky Software have taken after Corncob3D? Since it was the physics of Corncob which was its strength, probably a better move would have been to develop a general purpose physics engine using integer or floating point arithmetic.
Was developing the GCS a mistake? Well, it was definitely a successful product which many people enjoyed and earned a decent amount of money. But it was not possible to keep it current unless the company grew, and there wasn't enough money to grow. Was Baja Bash a mistake? Let's see. Years of a development time and nobody ever played except me and my family and friends and we sold zero copies. I think there probably was a mistake in there somewhere.
The mobile phone market has really changed the rules, and suddenly it is the smaller developer who has the upper hand. How can a huge company afford to spend any time on designing an producing a game that will sell for $1.99 in the App store? There is not enough profit potential in there for them to even plan an application, much less actual build it. Especially for Android, with a free development environment, good documentation, and an easy way to put the product on the market, they have created a wonderful enviironment for the small developer.
And this is why the Pie in the Software website is back online today. It may not stay this way for long, but for the moment it seems like a great way to make some fun products that people enjoy and maybe make a little spare change at the same time.
|Last Updated on Monday, 15 March 2010 04:42|