Steve A. Baker

EDUCATION

I was attending El Camino College, at the time, studying Electronics, Microprocessors and Computer Science. My 1st year I developed a new method of solving Bridge Circuit problems that cut the calculations in half. The professor started teaching it as Baker's Theorem. I also created the lesson plans for the Electronics Math course including tests, quizzes and during the 2nd semester, I was at the chalkboard, showing them step-by-step how to solve various problems.

My 2nd year I decided to build a perfect amplifier for my final exam. I made many trips back to the parts bin to find the "perfect" part. If I needed a 1K resistor, I took 15, 1K resistors back to my desk and measured each one until I found one that was dead on. I did this with all of the parts, including the transistors. When I was done, I had made a perfect amplifier. All of the "test points" were whole volts or milliamps. Exact on, flat response from 10-200khz. The professor looked at my exam sheet and noted the readings. He then began to fiddle with the power supply and the dual-trace scope. Muttering under his breath, "No way, can't be". He said I'll give you a "B" for a final grade. What!?! He turned his head and laughed, "Excellent work". Excellent heck, it was perfect.

<hr />

APPLE COMPUTER

Joe Ennis is an odd sort of fellow, one of a few that I met at Softape. He had shown me an old Dr. Dobbs paperback article on a reverse linked list that reused earlier entries as needed for amazing text compression. I took the article home with me and brought a working version for the Apple-II the next day to work. He was amazed that I did this in one night. He thought that I was the best coder on the planet. If I am into a concept or idea, I will put something together very quickly to see the results.

He was hired by Apple Computer in the Service Engineering department. About 6 months later I got a phone call. Hey Steve? How would you like to fly up and interview for a job with Apple? Hell yeah! I was hired by Apple, they moved me and my family to Cupertino and put us up in a Hotel, while finding an home for rent. I was a happy camper. I now had access to the innermost listings. I created a Confidence Disk that contained many test programs for the Apple-II. Testing its hardware and Disk software. I wanted to make something that could help you determine if a given floppy disk was on the edge of failure. Magnetic field loss was commonplace, and sometimes hours or days worth of work would suddenly become "unreadable". But what I discovered, shook Apple's assembler world.

Apple had their own assembler, EDASM, created by John Arkley. It was disk based and I switched over from my assembler to the company's version. It worked great for many months until my disks were failing left and right. I would make one opcode change in my code and suddenly, after assembling the code, the disk would be unreadable. I changed the faulty opcode, and the problem would go away. But I really needed the opcode that destroyed the disk. I narrowed it down to where the binary object code was written to the floppy. Using a disk sector display program, I could see that EDASM was overwriting the address marks for the following sector if a certain group of opcodes were being outputted. I was concerned and relayed my findings to John's attention along with the sample disks and the "special" sequence of opcodes that produced the disk error. His reply was immediate, "There is nothing wrong with the assembler, must have been an error on my part". No way John, just look at these disks and let me know later. About 2 weeks later I got a call from John, "You were right, I don't know why, but the following address marks were blown away during the binary write on the previous sector." He asked me if I would help him design, code, and debug a new assembler for Apple. That is when the ProDOS 8/16 Assembler was born.

<hr />

OFFER I COULDN'T REFUSE

I got a phone call from a headhunter working at Atari. The 5200 system was being released and they needed game programmers. I was happy working at Apple, and in hindsight, I should have stayed. But Atari's offer even made my co-workers and management tell me to go for it. I could work at home. I would be paid twice what I was currently earning at Apple. Every game that I released, I would get 10 cents per cartridge royality and $50K bonus when the game was released.

My 1st project for Atari was coding Defender for the 5200/800/400 Atari systems. Atari had a PDP-11 host with scores of video terminals and one line printer. The throughput was very slow with dozens of programmers working on their own games. I decided to use my trusty Apple-II computer and a EPROM burner to create games for the 5200. I would assemble, burn EPROMs and plug them into the T-card for testing. This worked out very well for me and Atari was happy. Defender came out with flying colors. This was my 1st 5200 game using Atari's display processing system. I even got to chat a while with Eugene Jarvis, the original programmer behind the arcade game. He let me in on a little known secret. Fly past the swarmers and quickly flip around behind them and pick them off one at a time. Swarmers do NOT fire behind themselves.

<hr />

2600 ATARI REVISITED Epyx asked me if I would be interested in doing some Atari 2600 work. Here we go again. But this time I _did_ get paid. I worked on Winter/Summer/California Games for the 2600. Wow. Now we are talking strange programming. The 2600 draws to the TV screen a line at a time with each line taking exactly 76 cycles. If you crossed into 77 cycles the screen would tear and stretch out past the bottom. I found out that you could use code for data. Halfpipe took advantage of that, but its the ONLY known code that did NOT tear the screen using 77 cycles for a frame or two. Why? No answer, it just works. I coded Halfpipe, Speed skating, Rowing, Biathlon Shooting, Surfing, and the sound generator used for the series.

<hr />

CALLING DICK TRACY Apple-II software jobs were still hanging on by a thread when I started working for Decision Development Corporation. They had a job to do a Dick Tracy game on the Apple-II. When I called, they were a bit reluctant to interview me. I was a tad arrogant when I stated, "Oh, you don't want state of the art coding, with double Hi-res screens, 3 voice sounds with a drum track and my newest 25khz PCM sound code for human voice." After a brief pause, they called me down to show them what I can do for them. I was hired and soon met David Mullich at Disney. They had a video tape of the Nintendo version of the game and a skeleton IBM version. I said its very doable on the Apple-II.

I worked for about a year on the project. I was trained by the Disney artists and I even have a letter stating that Disney was amazed at the quality of artwork I was producing without being a professional artist. That my style was very close to their licensing guide. The mugshots were the hardest to do. I created my own camera capture routine and took the photos from the movie and digitized them for use on the Apple-II. I then went beyond the 140 horizontal pixel res and pushed it to 280 pixels and beyond. It was the only way I could "move Flattop's nose 1/2 pixel to the right".

<hr />

BACK TO EDUCATION

Needless to say, I was heart broken after all that work I put into Dick Tracy, only to have it shelved. My next project was to recreate the Plymouth Pilgrim's crossing and settlements in the New World. I worked with Brooke Boering on this one. He was in his 60's at the time and wondered if he could handle the programming. I would do all of the graphics and hard parts for him and he would handle the historical part of the game. The project went very well, and I further dove into FM synth hardware. I created the music for the game using my own instrument tables for the Sound Blaster FM chip. I then coded the PC speaker to duplicate the music as much as it could. I created a 3D driver for the sailing across the Atlantic section and within the bay.

Now came the "chores" section. I made a logging game where you ride a log down the river to the settlement to increase your "wood" supply for cooking. A fishing game for the food and fertilizer used for growing crops. The turkey shoot was another fun game to create for the project. If you hit the turkey with your bullet, its feathers would fly off leaving a naked turkey covering itself. The game chats had characters with moving mouths and eyes. Chatting with the ship's captain or a nearby Indian chief allowed you to trade your goods for other needed supplies.

<hr />

CREATIVE INSIGHTS My 1st tasks there was to do more sound work for the Sega Genesis and Alien Legacy. I used my FM instrument creator for the Genesis, and a programmer there said its the best sounding instruments that he had heard coming from a Genesis.

Next I started experimenting with a new way to draw sprites. Since DOOM had 3D enivronments but only 2D "enemies", I started working on a method to draw 3D sprites. I like to call it "spoke" rendering. Each horizontal line of the bitmap would be wrapped around a "surface of revolution". Picture a Lathe sideways. Each line wrapped around whatever width was on that line. Rendering a pawn chess piece is a good example. Now the enemies had volume. This technique was further expanded to allow a "surface" height for each spoke. Now you could model a nose and deep set eyes into your object. Last variation was adding rotation to rendering and adding live light shading to the bitmap colors. My Earth Wrap demo is a good example of spoke rendering.

<hr />

JAVA AND SABGAMES The Internet was just getting popular and Java was in its 1st release. I looked at it for a bit and then decided that I could start my own Internet game arcade. Pachinko came to life in about 4 hours. It was a hit. In fact, all of the games that I released on the Internet were top rated at JARS and other Java review sites. I then proceeded to code, A-Train - A bullet train scrolling game. StarJAM - A musical puzzle game where you place various given blocks on a grid which change the direction of the ball. When the grid is close to full, it sounds like "Hey Joe" with lead notes being played whenever the ball hit a block. AirRescue - A helicopter flying game where you drop lifesaving rings to drowning people in the water. SurfH2o - a scrolling surfing game surfing Pipeline. SABgolf - A beautiful 18 hole course with a course Editor to make or edit the holes. SABbowl - An in your face bowling simulator.

Alpine - A downhill skiing game with slalom flags. Many of the games carried along web scores for comparing yourself to others on the 'net. I marketed many of the games and continued to make custom versions of these games for clients. Webgammon - A 10 table backgammon parlor with chat and spectator "lurking" to watch others play to learn the game. Webgammon was the biggest Java game I coded. This was done using the CGI interface and Perl. Webgammon supported 5 languages. English, French, Greek, Turkish/Farsi and Spanish. Many hours were spent figuring out which CGI interface to use with Java. After many games "died" in mid-game I had had to find out why. Simple answer, sending a packet from one computer does not guarantee its arrival to another computer. I saw about 1 packet in about 100 being "lost" stopping further gameplay. I decided on a simple solution. Send two packets with the same info and let the software figure out dups. It worked like a charm and ALL games then were completed from start to finish.

After coding all of these games and reusing all of the routines in its "bulk" form, I decided I was going to write a interpreted language using Java as a parser. SABfx was born. Simple plain text, no compiling, quick turnaround. I started coding games in SABfx and found out that I could create games quicker and with a smaller footprint. GalaxyTag, Sleeper, Tracers, and Par3 Solitaire came to life. I then added an external data file loading and parsing code to SABfx and Slot-a-Meal was born. I had the sabgames.com domain name, but it lapsed during my house remodel that left me offline for over a year. That is why I am at sabgames.net.

<hr />

MOBILE GAMING

I was contacted by an old friend from Creative Insights for some contract work doing a golf solitaire game (modeled after my Par3 Solitaire) deck generator. These are all winnable decks for use on a mobile handheld phone. Players would compete for the fastest time solving the deck. Soon thereafter I was contracted again to do a Boulder Dash Maze generator for Atlas Mobile. This was a very large project and they wanted to have preset "modules" that could be placed on the maze grid. I created a full featured Maze editor with auto generating object placements. Likewise, all of the mazes created had to be solvable with at least one path to the exit. Maze size and level of complexity were simple keystrokes. The generator part also wrote finished mazes to a file so that they could have 100's of mazes available for the cell phones at any time.

My next cell phone project was Water Balloon Drop for Infospace. This was my 1st exposure to BREW and its related development programs. I had to install Visual C Net on my computer along with the BREW ARM compiler. I had to make animation strips from the individual cels of animation for the various game characters. Size again became job one. Dealing with the various handset quirks, slow key response, slow blurry screens were a chore and at the same time fun, when I found a solution to each problem.

Infospace then wanted me to do a remake of the Frogger game they had on Verizon Wireless. The game I started with was less than 1/2 done, when compared with the original arcade game. Most of the game elements were never coded. They also wanted to add a deluxe version of Frogger to the existing game. I found an arcade machine emulator online and the original Frogger arcade ROM image. I played the game back in the 80's in the arcades, so I knew what was missing. The non-scrolling flip screen Frogger was replaced with the full vertical scrolling arcade version. The missing enemies were added. The missing levels were added. I did stumble across the original arcade game bug where you would die if you jumped on the right edge of a log in the river section. The arcade game would change every 5th log into an aligator and you would be safe on the aligator's nose IF its mouth were shut. However, if the mouth was open as it scrolled offscreen to the right, the image was changed to a log BUT the unsafe area where the mouth was would become unsafe even on a log. I fixed that bug. The stock version was done and the Deluxe version with various frog powerups were now added to the game.

BREW is a good starting point for coding games for handsets. If you structure your code properly, the conversion into J2ME becomes less of a headache. I learned my lesson from WBD and the J2ME porting went smoothly with only a few frame rate hiccups. Turnaround time was around 10 seconds for BREW assembly and checkout. However, J2ME took like over a minute to compile the same code. For game development, timing is everything and I like to work fast.

<hr />

More info about me is online at http://sabgames.net

<hr />

-SAB aka Steve A. Baker