Programming Matters

If you haven’t read the first and second parts of this article, you’ll probably want to check them out here and here.

So I was working with a company that did 3D development for games! It was 1998 and things were still fresh and new in that area. The three API’s of mention were Glide, Direct 3D and OpenGL. I was working with some amazing artists and programmers and was glad to be learning more about the ins and outs of 3D development and tools. This was my first taste of a scene graph using Paradigm Entertainment’s Viskit. Scene Graphs are amazing things - and I was learning everything I could. Viskit was based on SGI’s Performer and like OpenGL - they had done something really, really right when crafting this API. Viskit sat effortlessly on top of OpenGL or Direct3D. I ended up working quite a bit on our Multigen loader to get all the bells and whistles supported. We used Max for our prerendered scenes but at this point Multi-Gen creator was huge in developing real-time models. It was a great app that made both programmers and artists feel immediately at home. Scene Graph nodes could be mapped very easily to Multi-Gen nodes. It was a perfect match.

As usual my dedication ran high. I was able to entice a truly stellar programmer from my time in NJ to live with me a significant portion of the month so he could code on the team as well. I worked with two artists that two this day I have to say are second to none. We created an amazingly beautiful world with truly stunning environmental effects. It was enthralling. In the end though small companies with only one project are fraught with peril. In 2000 Aeon closed it’s doors and my love for Viskit took me to my next job at console developer Paradigm Entertainment. They had built a version of Viskit that ran on all the next-gen consoles including the X-Box, Game Cube, PS/2 and even the dreamcast. It could still be baselined on the PC as well. This was my first time working with consoles - a fixed format machine, finally!
It was now 2000 and I found myself in Dallas, Texas, In typical game industry fashion several weeks after joining Paradigm they sold themselves to Infogrammes. However, they still were able to call their own shots for my time at the company. It was awesome having 3 or 4 teams working with 3D technology for multiple consoles. This technology was developed by a dedicated core technology group - I hadn’t been lucky enough to work with a company big enough to have this luxury before. They were the think tank of the company always getting all the heavy pressures but coming up with some truly stunning innovations. All of our artists were using Maya - which worked well, it supported a group hierarchy for scenes like Multi-Gen creator had previously.

Consoles are truly outstanding beasts to develop for. In all the years of working on the PC I had always dreamed of being able to develop for fixed platforms. You could know that once your testing was done it was good to go - no surprises based on machine configurations later in the pipeline. C++ was still the defining factor in game programming, although plenty of PS/2 code was written in Microcode as well. Common acceptance of scripting languages for high level prototyping was still a few years off. The best part about working at Paradigm was access to resources. When teams ramped up they could have 8-10 artists and almost as many coders. Things could really come together fast.
2003 found me back in Virginia where I started working for ITSpatial - a company that did 3D representations of cities a la Google Earth … before Google Earth had been around. In fairness there was Keyhole, but what ITSpatial offered was a different kind of thing all together. ITSpatial built a product that provided data integration and fusion in an environment that supported 2D and 3D mapping. This was perfect for command and control applications, situational awareness and emergency training. It was really one big serious game and had many of the elements of a full fledged game development effort and content production pipeline. The only thing difference was the price point of the product and the number of shipping units.

ITSpatial was strong and knew a lot about sales and business development. They were phenomenal sales people. I will always be amazed at how effortlessly they were able to get potential clients in the building, looking at demos - 3 or 4 times a week some weeks. They really were devoted to finding and wooing clients. This is a skill I’ve still got a long way to go on. I guess in some ways I’m still 100% a programmer at heart:)

In 2005 I broke away and this time started my own company Eureka 3D, Inc. I’m more of a hired gun/contractor with the luck to have access to a lot of other proven hired gun contractors. Eureka3D has worked on entertainment 3D, GIS and I’ve really boned up on my web programming skills in the last two years. Deep down inside I’m still wanting to get back “into the game” and sink my teeth into that big 2 year development project. Right now my pipeline is very full and I really am enjoying what I’m doing - so no complaints!

Here we are in 2007. What have I learned from the game and serious game industry after all these years? So much… I’ve worked with top notch programmers, others who couldn’t program their way out of a paper bag; I’ve worked with great artists, and a young up and coming project manager who was one of the sharpest guys I’ve ever met. I’ve worked with some truly genius biz-dev types that knew how to sell and pitch to clients. In 24 years every theory on project management for software/hardware/games has been debated, turned over and debated again much to my chagrin. I’ve seen every element of the business from pitching the contracts, building proof of concepts to final testing and delivery/deployment/distribution. I’ve learned a thing or two about politics and how important it is to avoid if at al possible. I’ve literally seen programmers in drop-down, drag out fights (visiting programmers from another company no less!). Religious wars over version control systems, graphics api’s, and taking on the latest new technology - been there, seen that.
The main thing I’ve learned however is that I thrive on the high-intensity, creative, ingenius environment that games and serious games involve. Finding a team that works well together, or a few truly brilliant individuals makes it all so worth while. I know I want to keep raising the bar and never lose the adventure. Because in the end it’s about the product, the team, and the experience. What an amazing 24 years it’s been!

If you haven’t read the first part of this article, you’ll probably want to check it out here.

1995 - Legend Entertainment - My First Industry Years

I was finally working full-time in the game industry at Legend Entertainment and couldn’t be more thrilled! No more sandwiching game coding in between contracting gigs. I was with a company that has produced a large number of award winning titles, gotten them published and distributed - all with a company of under 20 people!

I started out coding in Watcom C on a daily basis and working in crunch time on a game called Star Control 3. I was thrilled working with industry veterans from the Zork era! We even had an inhouse testing team. I can honestly say I’ve never worked at a company that ran as smoothly and without contention as the time I worked at Legend. There were blips on the radar, but over-all development fell into place extremely well during my years there. This is a testament to team dynamics. Get a good team that works well together and keep them together.

I learned so much while at Legend. These guys were experts at what they did. It was amazing being able to sit in on the entire development process - creative, technical and other. A lot of my best practices I learned while I was at Legend and over the years this feeling never left me. We’re talking about game development done the way everyone dreams of it being done. Projects would often times have just a few coders on them for most of their development cycle. I can say that I never saw a game canceled while I was at Legend - and had never heard of one being canceled before I joined them. They ran lean and mean and couldn’t afford that kind of wasteful slack. This had an extremely positive effect on morale needless to say.

At the time we were writing DOS based games that used SVGA libraries to build 256 color 640×480 games. The WATCOM compiler let us overcome DOS’ one meg memory barriers and access all of extended memory. We had to support a dizzying array of low tech video cards and collection of VESA video modes. But boy was it fun.

From a philosophy standpoint I finally started to get behind the understanding that old rules change. Optimization was still king, but design came first. Things I had previously considered wasteful were trivial on 486 systems with 4 meg of available memory. I began to realize that when working with a group of programmers design and communication were of paramount importance. These things had to be worked at, they just didn’t fall out naturally.

By 1996 I was coding in C++ in Microsoft (Visual) C++ and we were working on a game library using Direct X 5 for Windows 95. DirectX was all the rage. The access to hardware sprites and features was a major boon. OpenGL was at the time still too high level(slow) and lacked ubiquitous support. Of course we weren’t using DirectX for Direct3D at the time. Direct3D was a few revs a way from being usable. But uniform driver support for 2D sprites and pages was a major plus in itself. However 3D was on the horizon and I was very curious.

While I was at Legend I worked on 3 games and saw 5 games ship - all with a group of under 20 people; including the testing department, customer support and marketing! I owe them a huge debt of gratitude for everything they taught me and breaking me into the game industry.

By 1997 I would find myself somewhere new. I had a hunger for cutting edge 3D and a company in NJ was doing that and more. They were actually producing their own OpenGL compliant hardware for the military using an off the shelf Glint chip (from 3D Labs) and a proprietary in house ASIC they had built for voxelized 3D terrain rendering. I was now at ASPI!

1997 - ASPI

ASPI was another opportunity to work with a small group of brilliant people. The engineers that worked on digital logic design considered machine language high level. They used custom software to produce their own ASIC’s, soldering them to the boards in-house. I had already become very sold on object oriented development at the time. I had definitely drank the cool aid. I picked up a copy of Design Patterns by the Gang of Four and fell in love with it. Years later I would spend plenty of time examining the ways that novice coders abused OOP and design patterns. But in 1997 I was still loving learning all the ins and outs. I picked the few patterns that fit the API we were developing and got to work. It took a bit but I got everyone on board with tightly optimized C++ (which at the time many saw as an oxymoron). I had realized that C++ could give you the low level control to maintain C like speed. And I liked it - a lot.

I was now using OpenGL and MESA(an opensource OpenGL) and accepting the fact that on modern machines - OpenGL definitely was worth the minor performance loss. Back in those days there were still camps that wanted much lower level access to graphics hardware to eek out every last bit of power. We even got to write our own custom drivers for MESA under SCO Unix.

The cards were awesome and we ended up calling them the “True Terrain 3D”. The military had a contract to buy them up and deploy them. They were able to ingest DTED data and use LODed voxel planes to create amazing looking terrain. We interleaved access to the frame and depth buffers with the Glint chip and OpenGL/Mesa to add polygonal features. This was in 1997 and at the time polygonal 3D cards couldn’t come close to generating the terrain that the custom cardset could. Not in the under $20,000 price range at least.
I loved everyone I was working with but invariably even cutting edge high tech couldn’t keep me from wanting to go back into the games industry. Somehow high tech and “serious games” were exciting, but games were still in my blood.
By 1999 I was back in the industry working on a submarine sim at Aeon Entertainment in Baltimore.

But we’ll cover that in part 3….

Originally I was thinking about calling this article 24 years of game programming: observations and lessons learned. Somehow the title seemed much too stuffy for an entry about something I’ve loved so much over the years.

In this three part series I trace my 24 years of game programming. From machine language in 1982, Pascal in 1987, C in 1992, C++ in 1995, using “high level API’s” like OpenGL in 97, catching the pattern craze in ‘98, the component mantra in 99, coding for 3 consoles at once in 2000, moving into Java, C#, and javascript on the top of C++ in the 21st century. And more!

Let’s go back to 1982:

This is where it all began for me. I had received my first computer a Vic-20 and dreamed of everything I could do with it. William Shatner had advertised it as a gaming system and a computer too (and we all know he has integrity from the whole priceline fiasco). I remember writing my first basic program for it from the thin manual that came with it. An animated bird that used character graphics to flap it’s wings and fly around the screen. I was mesmerized!

I quickly learned the machine inside and out, bought the Vic-20 Programmer’s Reference Guide, hung the schematic of the machine on my wall and went to work. Very quickly I realized that a 1 mhz machine with 5k of ram was going to take some heavy tricks to create games for. So I learned 6502 machine language to really pull the stops out. An 8 bit processor with an X, Y and Accumulator that could add and subtract any 8 bit value! X and Y could only increment and decrement. And of course when the numbers were larger than 255 a little juggling was required.

Very soon the Commodore 64 came out and I immediately upgraded. Programmable sprites, a SID chip for sound, 64k of ram (with 16k bank switched under rom that held Bill’s basic and the “OS”). Now we were playing with power. I wrote more than a few games for the Commodore 64 as a hobbiest in straight machine code. An Olympic games type clone, a chess game that worked with the 300 baud modem, a utility to dump on screen graphics to the printer, some arcade variations, a sprite editor.
These were the truly brass tacks years. 6502 machine language mixed with little bits of bootstrap basic was hardcore by any standards. Jumping to subroutines was something you couldn’t take lightly and the “hardware” stack was only 512 bytes long. It was strictly for keeping the return address from subroutine calls. I was firmly convinced games required maximum power and could only be written in machine language. I was pretty convinced this fact would never change.

I was of course wrong.

Fast forward to 1987:

The IBM PC/XT was starting to show promise and a friend introduced me to Turbo Pascal on it. 4.77 megahertz! 640k of ram. Sure my machine was an XT and only capable of CGA graphics (and character mode graphics - not even programmable at that). But Turbo Pascal was my first true compiler. It was actually possible to write a significant chunk of many games in high level code. Sure low-level interrupt stuff was often in assembly. We spent many, many all nighters coding games and often ignoring our girlfriends. But they couldn’t code:) I slowly got used to the fact that passing variables on the stack was a useful enough concept that it was worth the performance hit it sometimes had on games. We are talking about functions passing parameters on the stack! But this was “non-trivial” and took cycles. Things were still so tight that every cycle mattered.

Fast forward to 1992:

I got my first 386 20 mhz clone with 4 meg of memory and an 80 meg hard drive. I quickly bought a soundblaster card for it. Before long I was coding games in MCGA 320×200 256 color graphics mode. I learned everything I could about palette manipulation and palette color theory. I was coding in C by this time as well 8086 assembly of course. You could actually inline your assembly right there with the C code. It was awesome. I wrote a sprite compiler that would literally turn all the data into straight machine code so it didn’t have to loop and check for key colors. It used a triple buffer, dirty rect system to update the screen as efficiently as possible.

I learned Autodesk animator inside and out and spent hundreds of hours working on a sprite editor with bucket fills, circles, lines and palette manipulation functions as well as animation capability. I was in heaven. I recruited some good friends to do graphics for me and created a number of demos to show off the library.

I still hand-optimized everything and didn’t trust the compilers at all. A C compiler may not use a bit shift for an integer multiplication. The horror!

I made sure and learned all I could about fixed point numbers. At this point floats were still done in software and slower than hell. Since C didn’t support operator overloading the code looked pretty clunky. But it didn’t matter. 320×200 256 color mode was fast - really fast. And I was learning all I could from Abrash books about mode 13 hex that allowed the full 256k of graphics memory to be utilized. At the time the PC was still back switching 64k into it’s memory map. And don’t even get me started on 80×86 segment offset addressing!

I ended up releasing all my code as shareware and learning the ins and outs of shareware distribution mechanisms. I remember printing labels for 5 1/4 and 3 1/2 disks and mailing them off to shareware distribution hubs. This was before the internet took off of course and everything was BBS based.

1995 was right around the corner and soon I would find myself working at Legend Entertainment on Star Control 3 - my first commercial game product.

Part 2 cracks the lid open on my game industry years.

I have been in the game industry on and off for the last 12 years. I have seen commercial games go from a programmer and an artist and a budget around $100,000 go up to teams of 30 people with multimillion dollar budgets. In all of this time I have seen an insane amount of pain caused by management trying to manage 30 people as though they were 2. Once you have 30 people working on a project for several years you have a machine - like it or not. Things have to be remarkably well structured or they just don’t work at all. Currently the game industry often has a disfunctional model of production. As teams got this large a working model for running this process already existed. Hollywood has had an effective process of making movies for years now. This series will concentrate on the various aspects of what concepts can be migrated from the movie industry to the game industry to make it flow more efficiently and predictably.

Today we will concentrate on the game design/script analogy.

A huge problem in the game industry is when the game designer holds the game development team hostage. In many development houses games are pitched and won and a game designer “assigned” to the project. Say a dev house has access to a great piece of IP. They will take advantage of it and make a game. But by simply assigning a game designer and having him prep a game design document before game development begins a rats nests of problems occur right off the bat. This model lacks the proper incentives to get a fully fleshed out design early and up front.

A game designer dreams of creating the best game he possibly can. It’s in the game designer’s best interest to keep himself/herself from getting pinned down, that keeps things open-ended for later so that changes can be made. That also keeps things honky-dory with the game team. When things are “fluffy” and poorly defined everyone is happy. Until the project is underway and work can’t get done. With a team of 20-30 other people on the project it’s a nightmare. Their are plenty of management techniques to “extract” the information from a designer and pin him down. But the truth is that at this point it is way too late. It’s like filming a movie and writing the script as you go. Who would possibly do that.

The solution? Go the Hollywood route. If multiple game designer’s had their game designs “as complete as possible” up front and then had them compete to be selected this would put the motivations in the right places. The producer, art and coding leads that had been earmarked for the new team could review everything for completion. In the end the game with the best “proposed” gameplay and highest level of demostrated definition would be chosen by a group comprising the producer, programmer, and art lead. This would motivate the game designers in all the righ ways. He would make his design document as detailed as humanly possible in order to win the position of game designer. You wouldn’t see a script written in Hollywood with big vague blocks to be fleshed out later.

In the rare circumstances that Hollywood lets a movie go forward without a decent script you get movies like “Speed 2″. If the game industry would sit up and take note, create a competitive market for game designers, and only greenlight games that win this darwinian battle, a lot fewer games would end up being schizophrenic, poorly inspired “Speed 2″’s that lack any kind of cohesion or true focus.

Next article in the series: Vetting from the A list