My Programming History

(Conceived: 6-21-98) Last updated: 9-27-99

The Content Summary of this Page

Introduction

There's a great deal you don't know about programming if your background doesn't cover algorithm efficiency. When I was first getting into programming, I constantly heard the beckoning of "lower level languages" as being the way to increase the speed of a program, but rarely that my design might be inefficient as well. I attribute this to a lack of good mentors. Before coming to the University of California at Berkeley, I never realized that the quality of algorithms could really make that much of a difference.

Fun with Logo

The first programming language I was introduced to was Logo. It's certainly a language highly praised by educators; primarily the reason for my exposure to it in the 3rd (or 2nd) grade (or at least part of it). My father was dabbling in other programming languages for the AppleII+ at the time, taking his mind off of his normal job, and became interested in Logo. Having started as an elementary school teacher, yet leaving because of the low wages, it was no wonder why Logo caught his eye. One of his goals seemed to be testing it's educational value on my brother and I.
I don't know what impresses educators most about Logo - its structure or its graphics. What I spent my time doing was graphics. Who cares about anything other than drawing funny shapes and using procedures for drawing the same shape multiple times? At least I never learned to do anything more complex. I don't even recall being presented with the possibility of Logo as good for anything other than drawing geometric shapes! Maybe I was too young?

TML Pascal Challenge

Our first programming language for the AppleIIgs was TML Pascal. My father tried to make easy procedures that drew pictures just like in Logo; once again my brother and I became the guinea pigs. It wasn't too bad, I don't remember having any worse time with drawing pictures in Pascal than in Logo. Of course, we didn't do anything but draw geometric shapes!
A trip to Stacy's Bookstore in San Francisco a year or two later (I think it was that long) changed focus from graphics to text. We had found a book that described how to write text adventures in Pascal! My brother and I enjoyed Zork, so this was something we were really enthusiastic about! We wanted to make our very own text adventure! Just think of the possibilities!
The first few chapters of the book appeared to work with few hitches, then we finally arrived at the chapter for which we (my father, brother, and I) had all been patiently preparing... Promises of incredible features and the flexibility of database editing! All we had to do was compile the program!
If only it was that simple. TML Pascal had some quirks that caused the end result to operate incorrectly. My hopes dashed and my father's inability to get the program to work stopped our continued progress in the book (not the work on text adventures).
Still interested in text adventures, my brother leading, we were able to modify some of the older code that worked to make our own adventures. When I decided to add something special, I turned to my brother, and was assured that I should write the if statements like English. Slowly the complexity of my if statements increased and bugs crept in at about the same rate. Ignorant programming was beginning to take its toll.

Micol Basic and Graphics

When all else fails, it's time to move on to easier grounds. Around my 7th grade in school, my father invested in Micol Basic for the AppleIIgs. It was much easier than Applesoft Basic because it shared function and procedure definitions like those found in Microsoft's QuickBasic. It didn't require the lines to be numbered either, so it looked similar to Pascal.
My brother, still interested in text adventure games, and having been better at programming in Pascal than I, excelled at Micol Basic. Not knowing how to write a text adventure, I decided to make a graphical game. My first goal was drawing a picture on the screen. In the process of actually getting a picture on the screen, I learned a great deal of Micol Basic - how to define procedures, how to use arrays, and how to use for loops! The end result was trying to draw a pixel to the screen at a time, reading the data from an array... I discovered this was extremely slow! Especially at the high resolution I was using (320x200, 16 colors)!
Some time around the last half of the 8th grade, my father bought Micol Assembler and wrote a simple algorithm for sending a line of pixels to the display memory. Why he didn't write something to copy an entire graphic to display memory, I don't know. Anyhow, this was faster than my old routine (although still slow since Basic still moved it down to each new line of the tile). Meanwhile, my brother had completed an impressive text adventure, and had also made an adventure with a graphic per room and two player hot seat, turn-based movement. (I don't remember what I did during that time, I think I was merely toying with code. I know I tried to program in lower resolutions, but didn't like the lack of colors and the larger pixels.)
This new faster routine and my brother's introduction to displaying graphics using QuickBasic for the Macintosh, spawned his interest in writing his own tile based graphical adventure. We had already come in contact with ExplorerGS, and made our own adventures with it. Now he wanted to write his own. I became the playtester of the two adventures that resulted from this. While my brother designed those adventures (the first only copied 8bits at a time, while the second copied 16bits at a time for drawing the tiles), I worked on a two person tank game.
At school, we were programming in Microsoft QuickBasic using the MacSE, and were learning a great deal more about programming in Basic. The exciting advantage of programming the MacSE was just that we could draw the graphics faster because there was a predefined routine. The major drawback being the lack of color.

6502 Assembly Language

Some time at the end of the 8th grade, I became interested in programming the AppleII in assembly language. My father had bought years previously the AppleII-6502 Assembly Language Tutor which came with a program that allowed you to interactively change, run, and view memory while learning the language, and the Merlin Assembly Language Compiler for the 6502. All around me I could see games written in Assembly. I knew at this time that Assembly was the only way to get the speed I wanted!.
All summer I spent learning Assembly for the AppleII. I even read through a book that went step by step to make your own game! At the end of this, I was ready! Programming in assembly language wasn't so bad... except I couldn't figure out why the joystick didn't work. Unphased, I decided to learn how to program the AppleIIgs in Assembly! I bought the Orca Assember for the AppleIIgs and just started reading a book on how to program it, when ... our hard drive finally died.
This must have been around the beginning of the 9th grade. We were now restricted to those programs which we could store on our RAM. Using a program that stored programs on the RAM, the RAM now became our 2MB hard drive. The problem was that Orca required more than that to run (you had to run Apple's system as well), so that was the end of my days as an assembly language programmer. I think this lead to looking at a book my father had bought on programming 3D graphics in Applesoft.

QBasic and Learn C Now

Surrounded by IBM PCs at school, discontent with Apple Computer's abandonment of the AppleIIgs line of computers, and having IBM compatible PCs at my mothers work, all led to my family buying its first IBM compatible PC at the end of the Christmas Break in the 10th grade. It was a 20MHz 386 Packard Bell purchased on credit at Sears. Before this point we had looked at IBM compatible PCs and pondered what it would be like to own one.
This particular computer didn't have MS Windows on it (probably not enough hard drive space at 40MBs), but the tutorial that came with the computer displayed a resolution with pixels so fine it looked impressive even with only 16 colors (this was 640x480 VGA)! Then my brother and I discovered the QBasic interpreter and played nibbles as our first game for the PC. Soon to follow was Space Quest IV, which was more point 'n click than I would have liked, and Wing Commander II.
Wing Commander II was unbareably slow on that computer! Yet it did make the computer go out with a bang... Just as I was getting the communication to grant me permission to land from completing the first mission... BLANK. The entire monitor went black! Okay, I thought, maybe the computer just overheated... Two to three days passed. Still no response from the computer. Finally my brother and I made our parents call for someone to fix the computer. The technician came out, declared the computer dead, and said that he didn't have the parts to fix it.
The dead computer was sent back to Sears and traded in for a new-fangled 20MHz 486 Packard Bell with a 130MB hard disk (Space Quest and Wing Commander barely fit on the 40MB disk, we knew more was better!). This computer also came with MS Windows, so we finally had a decent word processor (Lotus's MS Windows word processor at the time) and spreadsheet (Lotus 123 for MS Windows). We could finally play Wing Commander II at a decent speed...
Soon my brother and I became curious about what type of games we could make using QBasic. My brother had found a way to display a picture on the screen, copy tiles from it, clear the screen, and draw tiles similar to what we had done on the Mac and AppleIIgs. This meant it had potential! It was also faster than the old routine our father had programmed for the AppleIIgs, so he was searching for better graphical effects to add to a new game. I don't recall being as excited over QBasic as my brother. He finished a tile editor, and I never finished a QBasic program.
One day, while looking in a bookstore under the computer programming books, I saw Learn C Now, a book published by Microsoft Press. It came with a QuickC interpreter and taught the C programming language. Ever since I had learned an assembly language, I had an affinity to lower level languages than Basic. I saw this as a chance to learn C - a language that might allow me to out perform my brother's QBasic programs!
After weeks of studying in the morning and at night, I had finally learned enough to make a program in C. I decided to write a tile editor like my brother, and make it better than his. My tile editor was more graphically pleasing than his. It drew squares, lines, and text, while his was only text. I can't remember if it was faster or not, but it impressed him.

Turbo C++ for DOS

Once we saw what C could do (believing that it had to be faster than Basic for the very fact that it was a lower level language), it was time to get something better than an interpreter! The high school we were attending had a QuickC compiler, so we could make binaries, but we really didn't want to go to school to compile our programs. Shane and I were also looking forward to putting programs on AOL to share our unique creations. One goal was to upload our tile editors to help others make nice tile based programs! :-)
At first I was considering on investinst in QuickC, but I noticed that Turbo C++ for DOS cost about the same amount. Then after talking to others, I discovered that Quick C was a cut down version of Microsoft C, but Turbo C++ for DOS was the same as Borland C++ for DOS, except it didn't have additional programs that I didn't need! It was also a more advanced language, being C++ and not C, so it became the ideal choice!
Shane and I bought a book in programming C++. I remember Shane reading through the book, trying to make it to the part on graphics! I read about a third of it, but being quite satisfied with C, I lacked the desire to finish.
For graphics we were forced to find and download a BGI (Borland Graphical Interface) for the 320x200 display mode with 256 colors. In addition to this we ended up downloading quite a few other files to help us in designing a game. We also downloaded a paint program which seemed adequate for our needs. Our plan was to make tiles on a picture, dump the picture to the screen, grab them using the function to copy a tile on the screen, so we could later paste the tile back onto the screen.
In our experimentation with the copy and paste features of the BGI, we realized that it sorely lacked a feature we wanted... We couldn't select a color to be transparent! Not knowing anything about making the compiler optimize our code, our only thought was to make a routine in assembly language! Shane had an old QBasic book which had some assembly code in it, and using that I somehow managed to combine it with knowledge of the 6502 and produced an inline-assembly procedure that worked! (Later on, when I actually learned how the 8086 worked, I was amazed that it had worked at all!)
In this period of time, my Brother and I were able to create and upload a game called Laser Disks (a light bikes clone) onto AOL. It was a graphically pleasing, four player game with disks that zipped across the screen leaving a wall behind them. Each disk could fire a laser about three times to destroy possible obtacles in its path, and if you happened to crash, the disk graphically blew up and left charred remains. The sound was limited PC Speaker noises, yet we did manage to get the pallete to scroll (albeit slowly), helping to add character to the game as a whole. Unfortunately, we lost not only the code to this game, but the game itself. If it were still on AOL, I'd be really happy to reclaim a copy, but I don't have access to their archives.
Meanwhile, I also looked forward to producing my own action/RPG game. My programming style was poor and convoluted (later becoming the death of the project, yet I learned from my mistakes). I was going to call it The Search For Time. It was going to be a game were the main character was teleported back in time through an experiment gone wrong, and he would become separated from the device that would be necessary to bring him forward in time. He would eventually need to work with the less advanced villagers and explore a world far more dangerous and hostile than the one he had come from.

8086 Assembly Language

Impressed with what we were able to do with inline-assembly, I eventually wondered what I could do with a real assembler. This led to buying the Turbo Assembler which came in a package with other Borland programming tools. To help me learn it, I also bought two books on learning the 8086 assembly language. One taught the basics of the machine codes and instructions, while the other was specifically written with the Turbo Assembler in mind.
Other books soon followed as I became more interested in trying to improve the performance of our programs. I bought a book on EGA and VGA cards so that I could learn how to do the graphical tricks other game programmers used to make their programs run fast and smooth. My brother stuck with programming in C++, while I became a fanatic glued to assembly. I believed that anything written in assembly would be fast.
With all this raw power at my fingertips, I tried my luck at a 3D game! I had always wanted to make a 3D simulator, but the computers until this time were typically slow, and more importantly, I didn't know assembly language! I learned how to use fixed point arithmetic, and developed the easiest, yet worst sorting algorithm. My procedures that drew the shapes on the display suffered from my lack of knowledge in how to drop polygons, so I used costly multiplies and divides. Other inefficiencies crept in, and although I felt that I was starting to have something impressive, it was becoming too much of a hassle to program. It wasn't as fast as I would have liked, so I eventually returned to C/C++. About a year of work went into my pure assembly language program.

Back to C/C++

Once I had returned to C/C++ programming, I became interested in refining my programming techniques. Shane had bought Turbo C++ for Windows, but I couldn't figure out how to make a program using it. This left me in DOS, but I really liked some of the menu driven interfaces in some of the programs and games we had purchased. This caused me to start thinking of the best way to design a windowed/menu driven interface. I remember making use of objects more than I had before, but it really didn't carry me that far until my next phase...

MUDs, Linux, XWindows

In our third or fourth year of high school, Shane and I became involved on the Internet. We discovered this text adventure type multi-player game called a MUD. It was an interesting game which we enjoyed for awhile, but we soon became disappointed as we discovered that it wasn't as complex as a normal text adventure. Our work was cut out for us now as we decided to make our own better MUD.
At first we tried to modify some available code that someone else made available (my brother discovered it through some message on the MUD we had been participating at). It's name was CircleMUD 2.2. Using our accounts at Richmond High School, we were able to test and run the beast. We got our hands dirty and modified parts of it, produced maps with promising story lines... and then...a discovery was made! The code was so poorly developed that it was a pain to make any marked changes in the way it functioned.
This lead to the design of our own MUDs from scratch. I striped the CircleMUD code so that all it did was receive and send messages. I even removed code that appeared to serve no useful purpose (I still don't know that the code did anything useful). In the meantime, a friend of ours also put up his own MUD with the sole desire to be the leader and add as many zones (groups of text based rooms linked together) as possible.
Somewhere in the midst of all of this, I decided to install Linux on my computer at home (486 66Mhz Compaq). This came mostly because I wanted to test the programs we were designing without having to log onto the Internet. The resources were slim on the computers we compiled and tested the software on over the Internet, so Linux seemed like an ideal development platform.
Always remembering a game of my youth called Wasteland, I envisioned designing a multiplayer game with a top-down, tiled view instead of plain text. I had already seen a mud or two attempt to do something like this, but they didn't seem to be that good, so my mission was to do better! I collected all types of information on ANSI and VT100 terminals so that I could deliver the codes to make my game come to life! I had dreams of an incredibly complex game with many features to make it lifelike... I wanted lighting, size and shape, all types of features representable in a C++ class. This was the beginning of ExpMUD!
It wasn't as ambitions as the latest specification back when it started, but I was simply overflowing with so many ideas! I wanted to make it realistic and capable of describing the world intricately enough that people would never have a dull moment! At the same time, I became interested in XWindows programming. I realized that if I could make an XWindows graphical interface with my game, then other XWindows users could have fun playing it without being limited to a text terminal's output.

University level courses

Taking CS61A during the Fall of 1995 semester at UC Berkeley really changed my thinking with regards to programming. Previous to that point, I had no real concepts of program efficiency (or inefficiency), so I wasn't aware that there were sometimes better ways of handling problems than loops within loops. Another discovery was the usefulness of functional programming and their unique way of describing objects. I remember excitingly thinking about all of the possibilities that course presented to me! Then there was the simplicity of the Scheme interpreter which also made me think about how I might be able to integrate it into my MUD... :-P

jjc@cory.berkeley.edu.
(My Home Page) - (My Personal Page) - (My Resume)