Name:        Andrew Dieffenbach

Age:           30
Location:    MA, USA
Email:         
Profession: Software Developer

My name is Andrew Dieffenbach, I'm 30 years old, and I'm currently a software developer at Vistagy.  I consider myself a creative person.  I like to write music and play it on guitar or sequence and mix something on the computer.  I used to draw fairly well, but I can't say I've drawn anything serious since high school.  How I focus most of my creative efforts these days is through programming computers.

As many people are, I am very much interested in making computer games.  However, I suppose I am something of a perfectionist and maybe a pinch lazy.  I have been studying programming (bent towards making games) since I was fairly young.

I started programming by copying BASIC code from examples of old Commodore 64 programming books.  It would usually involve text input and output.  Others dealt with sounds and sprite graphics.  What I enjoyed most was making small changes to the code and then running it to see what would happen.  If it didn't work at all, I'd change it back.  That became my primary method of learning to code in years to come; which I suppose is the same for many programmers anyway.

Many years later I stumbled upon QuakeC after playing the game, Quake developed by Id Software, and going online to download additional modifications.  At the time I had never heard of the C programming language.  Really not knowing C, I did the same thing with it as before with the Commodore books:  modify and run it.  What I changed usually didn't even compile--I really didn't know C.  However, I could tell it resembled the programming structure of BASIC and I could at least follow the code without knowing the syntax.

Soon after that, I permanently borrowed a friend's TI-85 Texas Instruments calculator for some of my math classes.  While unfortunately many of my classmates would use its "programming" functionality to store text to cheat on tests, I would sometimes write programs that would help me perform some of the formulas quickly.  However, much of my programming on the TI-85 during school consisted of little graphical demos and simple games.  I was particularly proud when I figured out you could resize the graphing screen to where each pixel was an integer coordinate.  From the code, you could call point plotting functions.  Utilizing the built in graphing line functions was alot faster than implementing your own.  I ended up making a pretty snazzy TRON light cycles game with collisions and even a decently simple and competitive AI.  I never did bother to program the TI-85 in the Z80 assembly language, as I had seen Commodore 64 assembly from other books I had.

Around the same time, I played with QBASIC on my Windows computer (which quietly came with every copy of Windows 95).  I was able to program graphics, pc speaker sound, and even joystick input.  My running goal was to remake the original Castle Wolfenstein.  I meticulously hand coded bitmap arrays pixel by pixel from images I captured with C64 emulator CCS64 and my trusty Paint Shop Pro.  Getting the data from files on my computer through the program seemed at the time a daunting task.  I managed to create a demo of the player moving around (no animation though) with the joystick.  I even managed to accurately emulate the movement/gun aiming control scheme.  However, the graphics output was noticely slow, but it was a good exercise.  I knew then I needed to program games like the pros, with something obviously more efficient.

Afterwards, I purchased a game programming starter kit which came with a Sam's Teach Yourself C in 24 hours.  To this day, I prefer that book series for programming.  It also came with a Borland compiler.  I remember Borland having a great integrated function help system complete with example code for each function.  Borland was also really good for the DOS graphics libraries it included.  Still, the idea of opening graphics files was a very hard task at my skill level, although I remember trying unsucessfully.  I did manage to open up "raw" image files and spit them out on the screen.  I started converting my QBASIC Castle Wolfenstein code to C, but I don't recall ever making it to the same working level.

I graduated high school and decided to go to college for programming.  Distracted by my studies and other "things" at school, I put my dream of making games aside for a while.  But not for too long, near the end of my second year I ordered a book that changed my outlook on my ability to program games--Andre Lamothe's Windows Game Programming for Dummies.  This is I think still a great book to this day.  It focused on C, although I had been learning C++ in class, and introduced me into Windows API/GUI and DirectX.  The main concept that I think holds back most CS students, wishing to game program, from actually doing it is the lack or realizing the idea of the finite state machine game loop.  Lamothe teaches this very well.  Another big thing I learned from this book was how to animate graphics.  I definitely started using the game engine he provided on the CD that came with the book.

When I got the book, DirectX 6 was out.  The frequent upgrades to 7 and 8 changed quite a bit with graphics and a little bit with device input.  Although new DirectX runtime versions were completely compatible with programs made with an earlier version, the code was not necessarily the case; although Microsoft tried.  I think this change jossled me then as a newbie.  I don't think it would have as much of an effect on me now.  But, ultimately that led me to look for other alternatives.  I looked at OpenGL, but it just dealt with graphics and, at the time, looked pretty confusing as I never saw any books as good as the one I had on DirectX.  Regardlessly, the working demos I made at the time where pretty satisfying for me.  I used the graphics from the classic game M.U.L.E., making tons of little multicolored aliens walk around the screen.  I quickly adapted that same code as a start of incorporating 3D graphics after purchasing the book Multiplayer Game Programming, edited by Lamothe.  Instead of M.U.L.E. characters, I had 3D robots.  You could observe them with a first person shooter style control.

Time passed after that with little progress.  This point in my life is when things started getting a little weird, including how I used and programmed a computer.  It was a particularly tumultuous for Windows XP, plagued by some severe viruses, especially on campus, which I managed to avoid by reinstalling weekly from discs with up to date patches.  I will also admit the constant reinstalling was partially for my then addiction to Counter-Strike, which had a damaging effect on my studies and game development goal--a fresh Windows install meant faster load times for Counter-Strike.  I installed Linux on my main computer alongside Windows.  I had toyed with the idea in the past and I had even installed it on my old system after I upgraded to my newer game system (for Counter-Strike of course).  I have always been very nostalgic mixed with delusions of eliteness, so I purchased an old IBM monochrome monitor for the Linux box.  By this time I had spent a little time porting the game engine to C++ in a more object-oriented approach.

Linux threw me back in time in many ways--good and bad.  It was like I was back on the Commodore 64 or using my brother's college's computers with DOS, or from a programming standpoint, like I had those Commodore 64 books open or Borland's IDE open.  The open source mentality of Linux felt very natural for me.  Especially at the time, trying to play Windows games in Linux was challenging but possible.  But that was the kind of deterrent I needed deep down--the irony was that I needed to stop playing so many games in order to start making them.  I decided to port the game engine to use SDL, an open source and cross-platform game programming API much like DirectX.  SDL integrated pretty well with OpenGL; so I had my sites on using it for even the 2D graphics.  I had just finished a graphics programming class at school that used OpenGL, so this time I was not afraid.  Looking back, me making this port is a little funny, as SDL/OpenGL are both very tied to C and not too strongly object oriented and I had just made the engine with C++.  Initially, I tried to make it even more object oriented and it worked somewhat with SDL as its guts.  But once I used OpenGL, some of the same object relationships I made went to crap.

At various breaks in time, I started taking those old demos forward, with the intention of remaking M.U.L.E. (puzMule).  I also spent time looking at the original game's disassembled machine code.

After some time learning Java on my own (as my college did not teach it), I ported much of my game engine to Java.  I wanted to use OpenGL through JOGL, but I'm initially using the built-in Java 2D graphics libraries.  Even still, I plan on making minor changes to the engine to make it work on Android enabled devices as well.