Wow, do I feel old now?

Everyone else appears to have coded their first games in fairly modern environments but my first was "Hunt the Wumpus" on the TRS-80 Model 1 and Apple II. For those younger than 40, it was a text-based locater game where you picked a co-ordinate and the computer told you in which direction the (statically-located) Wumpus was - hence an easy binary chop could defeat the game quite quickly.

The first graphical game I did was Connect-4 (or Four-in-a-row if that's more legally acceptable) on the COMX-35 [don't ask, this computer was heralded as using the same RCA1802A CPU as used by NASA but I think NASA used it to monitor the temperature in the toilet near the Apollo spacecraft simulators - it was pretty basic].

The funniest thing about the COMX-35 game was that I inserted totally random output occasionally such as "Oh no, I'm in trouble" and "Ha, I've got you now" and it freaked my mother out as she tried to figure out the computer's strategy and why it felt that way. I didn't have the heart to tell her the truth.

It did make me a better programmer since it was enjoyable and cemented my desire to do it for a living. The code itself was no doubt rubbish by my current standards (at least I hope so :-) but that's irrelevant to making me want to cut code forever.

My first game I made was a text adventure game in QBasic ^[1], under MS-DOS 5 ^[2], on a 386 ^[3] running at 16 MHz, about 15 years ago.

Did it make me a good developer? Definitely not! The code was full of GOTOs (the spaghetti code ^[4] type) without any functions, and I barely understood the concept of variables.

Most of the branches in the code was a variation of the following:

INPUT a$
IF a$ = "north" GOTO nextlocation

As my understanding of conditional statements and variables were very minimal, all knew was that as long as I replace the contents between the quotes (a string literal), an IF statement would allow me to GOTO to another line. (Resulting in a nice spaghetti of GOTOs.)

The thing that made programming so "addictive" was the part where I could write a program and then run it (play it) and it would perform as I told it to do. At that point I was in 4th grade and these were the times before the "World Wide Web" was widely available as a resource for learning like it is today.

Snakebyte (DOS, Turbo Pascal) and Tetris (DOS, Turbo C), i learned how to avoid common programming pitfalls like off-by-one errors, and the basics of arrays

It was a shoot-the-guys-popping-up-in-windows type game for the c64 supposedly like Operation Wolf or Operation Thunderbolt ^[1] called, amusingly to my 12 year old self, Operation Thunderbox.

What did I learn from it? That it's really hard to control spaghetti code when you don't pick a big enough gap between line numbers. Though I think it was one of the first programs I used subroutines in.

The first game I ever programmed was SpaceQuest ^[1]. I made it using Visual Basic 6, and Directx 7. The link has the source code for it. I enjoyed making it very much. The second game I ever made was Need for Feed ^[2]. Again a game in VB6+ DirectX. This one was simpler.

Did I learn something?

Yes, I learnt how DirectX works, I learnt about DirectShow, about joystick and keyboard control, about sprites, about frames per second, about making the game work in VB.

Though most of it wasn't used because I ultimately started making business apps, it was 100% fun.

Edit: This was in 2001. Sigh. I am growing old. Those were some days.

My first real programming project was a Gameboy Advance game entitled "Falling Star". It was a Scorched Earth clone with some fancy transparency effects, multi-player, AI, etc, which I developed on emulators and hacked hardware. Originally it was Phase I in my master plan to become the next Warren Spector. Phase II was when I got contracted for by a tabletop RPG company to produce a GBA version of their game, spent six months on it, was never paid, and collapsed into a slovenly pile of anti-industry human matter.

The project taught me more than I would have ever though possible about programming. Particularly with regards to resource management, team formation, and code-as-math. I'm sure that if I looked at the code today (I do have a copy somewhere) I would marvel that it worked at all, but it did work, was suitably bug-free, and accomplished something that I truly lusted after: seeing my own code run on native hardware. (Thank god for the #gbadev hackers.)

If not for that project I don't know that I would still be interested in coding today. It was a way to get at the interesting design problems by writing the code myself (because finding a coder was impossible), but I ended up enjoying the coding so much that the design began to seem insignificant.

I can't find any reference to the project online anymore, but every once in a while I find mention of it on GBA roms site, which trade it like a full title. I guess that is another accomplishment of sorts.

The first game I attempted to program was a version of a Choose Your Own Adventure book. It was in QBASIC in DOS. The only thing it showed me was how fast you can get up to neck in spaghetti code.

AssaultCube ^[1], a full FPS game based on the existing Cube engine. Lessons learned:

• OpenGL ^[2] graphics development
• Cross platform C++ development using SDL ^[3]
• Designing lightweight network communication using Enet ^[4]
• Optimizing C++ code for better performance (physics, etc)

It increased my C++ skills and taught me quite some refactoring skills, when to rewrite code, how to reuse legacy things, etc.

I have not actually written an entire game yet, but I and some friends at work have begun the process. I am most of the way through reverse-engineering Bejeweled in Flex.

The studying, thinking, and math I've had to do and learn has absolutely made me a better programmer and continues to do so. I'm a .NET developer/architect; the stuff I'm having to learn to do game programming feels like real programming, whereas the business development I've done so far is more like digital carpentry. I'm running into all the stuff Joel requires of his interviewees!

I did a really simple minesweeper in Perl. It has many of the features of the Microsoft classic, except the display is an ASCII-grid in the terminal and just uses print statements (doesn't even use curses) and the stdin - you have to type in commands, like c,1,1. It is only 10x10 with 10 mines, but it does use object orientation and recursion and has run without modification on both Windows and OS X.

The first game I programmed was a version of the board game Roborally. I did it in Java (1.0!) and never finished. I found it useful because it gave me a sense of purpose learning to program. It's easier to learn with a project in mind. It also helped a lot by forcing me to learn new techniques and understand how all of the pieces work together. It wasn't a particular algorithm although the game lends itself well to design patterns.

Years later I returned to this game and wrote an implementation in Smalltalk.

The first game I wrote was a version of Asteroids on the ZX81 in 1982, in ZX BASIC using the MCODER compiler. It taught me a lot about performance, given the game was running on a 3.5mhz processor, and game and compiler had to fit into 16k. I moved quickly onto assembler after this one.

I am not a game developer at all, but Robocode ^[1] was and is a super interesting learning experience. Not just for gaming, but it is also an interesting testing ground for basic AI concepts, adaptive heuristics and flat out tuning.

I replicated in a TRS/80 Model I a text-based game I saw in a CP/M computer. A horse race. The horses looked like this:

-( 1 )'=
 <   >
    -( 2 )'=
     /   \
  -( 3 )'=
   <   >

At each iteration of the loop, a randomly chosen horse would advance one character cell, while changing the "leg" disposition.

The original, CP/M version was made by a classmate of mine. People would gather around the computer and bet money. I kid you not.

First thing I coded, period, was a "fire simulator" in QBasic, somewhere around '95. It showed a top view of a random office building floor, and randomly showed fire situations, and reacted on the route you chose to leave the floor ("don't use the elevator!" etc.). If you didn't leave the floor in 4 or 5 moves, you were dead :)

Of course I wouldn't be where I was today without it, but I honestly don't know if it has made a great impact on my programming skills. That was, I think, more of a learning process over the years.

I'm still sad I don't have it anymore, though. :(

In my very eaarly teens I used to go to my local Boots on a Saturday and type programs into their display home computers. The first game I attempted to write was "Guess the number". I'd spent a few days planning out the code (instead of doing my homework) and was really exited. I picked a Vic20 (IIRC) and got typing. Probably an hour later, I'd filled a couple of screens of code and pressed "Enter". Clonk. All but the first 255 characters vanished.

Ah. Definitely a lesson learnt. Understanding why I'd lost all my code and the link it revealed between hardware, operating systems and software was pretty profound for a young coder-in-the-making.

(Unfortunately I didn't learn the biggest lesson until many years later - games programming for a living is the worst career I could have chosen. What a hellhole those years were!)

PaulS

Go-moku AI.

It didn't make me much better developer, but it made me better go-moku player...

My first game was an arcade game, something Donkey Kong alike.

Language: MSX-Basic. OS: MSX-2

But you could control it using a joystick!!!

I had to go through great efforts to make it perform somewhat, but it was very playable. But since I didn't know assembly at that time, I could not use it.

BTW: I was around 14 years old, Internet did not exist, programming books were expensive, in English, a language I did barely speak/read back then, and rarely available in the small village I lived.

Can you imagine the spaghetti code it must have been?

And yes, every single statement I wrote back then, made me a better programmer. Oh boy, there was so much to learn.

Made one call Space Command (or something) in TRS80 BASIC on a friend's dad's computer, you enter your name then were greeted as

'Captain' + N$

You go on a trade mission, but encounter a meteor shower on the way and had to decide

a) Keep Going

b) Try to avoid meteors

c) Turn back

If you chose a or b, you died (how unadventurous I was).

It got boring pretty quickly.

Did it make me a better developer? I guess so, but I was only 12 at the time, so I had no way to go but up. I am however impressed that I did do what I have never done since. I wrote out the whole program in pen in a notebook the night before, and counted the characters to ensure it would fit in an 8k memory (it turned out to be about a 1k in size)

I rewrote it a few months later on a VZ200, my first computer, and randomized the chances of your dying, which was a bit more fun, but just as futile.

"Cat and Mouse", in BBC BASIC on a BBC Model B. Aged about 9 I'd guess.

The cat was represented by a 'C', the mouse by a 'M'. Each was controlled by a human player, sharing a keyboard. The cat was fast, but had a lot of momentum. The mouse was slow but could change direction faster.

Although it would look very simple now, it was a great foundation for my programming career - this is where I first learned to manage loops, variables, all the basics.

Also it's where I learned about keyboard clash.

My first attempt at a game was Blackjack on a CDC Cyber 74, running NOS/BE. It was written in Fortran, and used a command line interface.

The first person to use it soon discovered that they could enter a negative bet, and then deliberately lose. The program would then -subtract- a -negative- bet from the total money, which was the same as a win.

This program taught me a lesson that I never forgot. Check your inputs.

Monopoly. DOS. QuickBasic. I learned how to waste time and make it look like I was doing something I was supposed to be doing (it was high school). This lesson was more valuable than any. ;-)

Woops, that's not right. BlackJack, same O/S, same Language. only preceded the Monopoly game by a couple of months, though. Again, same lesson learned.

I have no idea what the first game I made was, but whatever it was, it was on a TI99/4a, probably with the built-in BASIC (though later I got the Extended BASIC, which was much better.) I do remember typing in ELIZA from "More BASIC Computer Games," and studying the (extremely opaque) code for hours and hours until I understood how it worked (I was 13 years old or so.) And I remember sending away to some outfit advertising in Compute! magazine for a pamphlet explaining how adventure games like Zork worked. It included a sample game, Deathship, which understood a few verbs and nouns (significant to 2 characters!) More horrendously awful completely uncommented spaghetti BASIC code I spent hours and hours debugging and deciphering.

Turbo Pascal was a big deal for me... I still have a TP 2.0 manual around here somewhere. Wrote lots of partially finished games with that.

Did it help me become a better programmer...? I learned almost everything I know about programming, pretty much, from programming games -- or more accurately, trying to program games. Programming games is probably one of the best ways to learn programming there is. It tends to be somewhat fun, so you keep your interest up, and keep going, and it's demanding, the problems you run into aren't trivial like what you get with school exercises.

There was a long time from about 1994, when I started using linux at home instead of Windows/DOS to about 2005 or so when I didn't do any game programming, because X on linux in the early days was not great performance wise, but recently I've gotten back into it a bit. Latest effort is here: http://wordwarvi.sourceforge.net -- imagine the vi vs. Emacs flame war acted out in the form of the old video game "Defender," and you've got a good idea of what the game is like.

It wasn't a full-fledged game, but I wrote a turn-based battle system (random battles until you die) on a TI-92 during my math classes in high school. I think I also had a save/load system set up for After that, I wrote a BattleShip game on the 92 with enough AI to aim in open areas in the field and figure out which way sink a ship as soon as it found one (no cheating).

What did I learn? AI is hard to write, but very rewarding and TI sucks as a development platform - the batteries died in it a few weeks after I finished writing both and just before I got the transfer kit to move all that work to the family computer

My first "real" game was in high school - pick a number between 1 and 100 sort of thing on a Mac (forget the OS version) in Pascal.

I was getting my severely impacted wisdom teeth out at the time, which required a day long trip to get to the dentist that could do the operation and back... and I had heard that wisdom teeth can knock you on your but for a while after... so I quickly programmed it.

In the end the teeth went well so I had a few weeks to make it better... way better. Since I just had time to play with the code I learned a lot in that time, so yes it made me a much better programmer.

Funny thing is I just gave my students a similar assignment (1st year Java course) but they had to make it work for a human, an optimal computer player, a random computer player, a start-to-end computer player, and an end-to-start computer player (polymorphism). So I am actually still improving on that little program so many years later :-)

It was a horizontal submarine shooter game using Qbasic on IBM PS/1, I was twelve. All graphics were drawn using 2d shape and filling functions, the screen was never cleared, only the parts that needed to move were. There were mines, horizonally movin and only linear moving enemies. It definately did make me a better programmer. And it also thought me the limitations of the language I've been using, so I've started playing with Turbo C after a short time.

My first (and only) game was..

http://www.google.com/search?hl=en&q=free+the+pharoah ^[1]

It did make me a better developer although I didn't become an actual professional developer until years after.

I programmed my Atari 800 to play Handel's Water Music. Oddly enough I was trying to figure out my college major. I picked political science. It never occurred to me that programming a computer could be anything more than a hobby. It was so much fun...I'm over that now.

I had a penchant for Pac-Man.

First in GW-BASIC. You know, 320x200, 16 color, theme song via PLAY command and piezo buzzer.

Then, to kill time in high school computer science, where we had to learn Pascal, I created my most ambitious version. Features included

• 3D map (wireframe)
• Rotate and tilt map while playing
• Jump (to avoid ghosts)
• Customizable maps. You could create maps using a simple text format, and select them using a tiled preview.
• All done on a 286! (which meant, alas, it was unplayable when I brought it home to my 486)

Finally, I created a Javascript version, circa 2004. How much has changed since then!

They're all long gone now... the last one being a victim of Hurricane Katrina. No great loss!

The first time I even really used a computer was typing in a game from a book. Long ago, my friend and I laboriously slaved over a computer we barely knew how to use, typing in an enormous (to us) BASIC program that doubtlessly ultimately would create a shockingly mediocre game. It took us about 3 hours to type in, then another half hour to fix the typos (I, as the typer, had a tendency to type THAN instead of THEN), and then we didn't even get to play it because his mother had finished her meeting, and we had to go home. 3-4 hours "wasted".

And every minute was awesome. As I was typing it all in, I could guess (it was BASIC, after all), what the commands would do, and I was trying to convince my friend that we should replace the strings reading "B-17 bomber" with "X Wing" and things like that. He was too scared, afraid it wouldn't work, but I knew it would. I was so giddy...I knew I could do anything I wanted!

Now, I know a lot better about the "anything" part, but that was what got me into programming at all...so in that sense, I'm definitely better than I would have been otherwise.

First game I programmed was a Space War game running on DEC VT125 / GIGI terminals. You drove a little space ship around with your arrow keys and space-bar fired bullets at rocks and the bad aliens. I wrote this around 1980. Probably in Pascal on RT-11 running on a PDT-11 (personal computer!)

outputting ReGIS code.

Before that I had done some minor Game-like things on an IMLAC PDS-1 and a COSMAC Elf single board PC.

Since then I've done games for Atari 800, Commodore 64, Amiga, Sun and IBM Workstation, and PC.

And yes I think like everything I've done it all certainly helped improve my skills.

My first programming experiences as a kid were me and a couple of friends making games in QBASIC. Our first one was a text adventure, it didn't really work. The most successful was a "lights out" clone.

As a full-time web developer now I tinker with a game engine as a hobby and to learn. Working with a game engine has taught me a lot of things that you don't necessarily learn when developing web sites.

My first game was called "The Railfanning Game", and it's about as exciting to play as the title suggests. I wrote it for a friend of mine, and he made the graphics.

Platform: TI83Plus calculator from Texas Instruments
Language: TI-Basic
Web site: http://sourceforge.net/projects/ti83railfan/

I wrote several variations of the game, each time adding some strange new feature. All of the development took place during our high school math class. After high school I decided to take all the "best" features and combine them into one game, which is the v4.0 available on SourceForge.

I learned a lot about code minification and memory management. (Variables persist after the program terminates unless you clear them explicitly.)

Wow, I entered games not long ago.
My first wan a text based commands Quest in C#.

Recently I translated the engine to JS (And it was much more shorter :-) ) http://blackrenz.googlepages.com/quest.html

A Ports of Call clone in VB 3. I was about 15 at the time and this was the first time at all that I tried to program.
(I don't know if this game is known outside Germany - it was made by a German company and it has only a German Wikipedia entry, but no english one.
So, for those who do not know it: Ports of Call is a trading simulation where you can buy freight ships and earn money by transporting cargo around the world).

The screens where you could buy and load ships were all working (and I was very proud of what I had accomplished!), but the original game had a main screen with a world map, where you could see your ships moving around the world. I made the map, but I had no clue how to let the ships move over it.
That's when I lost interest.

So I didn't really learn anything. When I found the code years later and looked at it, I learned one thing: back then when I wrote it, I didn't know what functions were. Just copy-and-paste spaghetti code :-)

The first game I wrote was a turn-based racing game with still graphics to add to the experience over the text. It was for the commodore 64, and I was five years old. It took me two months and filled the better part of a single sided 5 1/4" floppy disk.

Yes, a turn based racing game. You'd go cross country and encounter obstacles and interesting people who would help you get to your destination faster. There was also subterfuge where you could damage your opponent's changes of winning.

Nokia Snake Clone on VB4. My dad had bought me the visual basic bible book, and I spent close to a week figuring out how to do keyboard interaction. It was an awesome experience and taught me how to program from books.

Chess. Windows. Java. Assignment for a post-secondary course.

Instructor focussed solely on object-oriented programming theory in his lectures and neglected to teach us anything about GUI stuff (Swing). Everybody had all their classes set up with constructors, but nothing more. The lab assistant gave us code examples on how to use MouseListener. I managed to get that set up so all my squares were clickable. Movement and capturing sort of worked, but I never figured out how to implement the movement rules.

I learned absolutely nothing from the exercise. I already knew how to copy-paste, and being taught to blindly copy-paste source code is not good. Next assignment was Game of Life which turned out even worse.

If I recall properly, the first game I wrote was pong in Java... 1.2 maybe? I learned I didn't want to be a games programmer. Or do any sort of graphics programming. Man, do I hate that crap.

EDIT After reading another post, I realised that the Game of Life was probably the first game I programmed. I was in C++ on Windows. It was a console based version and I had tons of fun doing it. I had just learned about pointers. By myself mind you, not in the class. The class was a bit rubbish. So I thought pointers were the coolest thing ever. So I built my game board as a pair of two dimensional arrays. I looked at the board "on top" to figure out what the next move was. I then wrote the move to the "back" board and then flipped the pointers and did it again. I thought it was really cool, and still do actually. The instructor wouldn't even look at my code. She taught by showing a slide show of code to do X and then everyone was supposed to copy it down. I don't think she even understood what pointers were really. Which makes me very sad that she was an instructor. :-(

First one I remember was a Reversi (Othello) with a computer player in 1980.

A clone of Tetris ^[1], in JavaScript. It taught me how absolutely terrible I was at game programming, some stuff about object-collision detection, OOP and that I don't give Tetris all the credit it deserves. Now when I look back at it, I'm just glad that I wrote it a few years ago because the code is pretty ugly...

TI99/4a - Basic - the game was Camel ^[1] from the "More Basic Computer Games" book.

It was a text based game where you tried to get your Camel across the desert without dying. It kept us entertained for hours.

No, it did not make me a better developer. I was ten at the time.

First Game

I played with code a lot on the BBC Micro during the 80s, but the first proper deliverable game I actually finished was a multi platform platform game for the Commodore Amiga. Nobody really played beyond 3 levels, but it was nice to finally get something finished.

Much to my annoyance the simplistic MSDOS based Tetris game I followed that up with (written in Turbo Pascal) was way much more popular among friends and family. The really annoying part was my roommate at university knocked me off the hi-score table and I could never get back on again after that.

Did it make me a better developer?

Yes, it taught the adolescent me that coding discipline matters. A lot.

I spun my wheels a lot from badly named variables, no tabulation and making the subroutines too big. I had finally found out the hard way why gotos are so reviled. It is the game actually worked when I think about it... :)

The lessons learned gave me a huge advantage when I started getting formal programming training at school shortly afterwards.

I had worked on a Pac-Man clone on a Commodore PET computer using BASIC (lots of PEEKs and POKEs). I think I got about as far as the dude getting around the maze without crashing into it. Better developer? Maybe from only the point of view or starting to learn to think like a computer (that it literally does exactly what you tell it).

It was tank battle game much like "Battle City" on NES, written in QBASIC. It was the only option available to me at the time :) And yes, I think it make me a better developer. In fact, it make me developer :) Not a "good developer", but still.

Five in a row version of Tic Tac Toe as an online game for my BBS would count as my first real game (not counting tiny text adventures or arcade games where you can only move or possibly shoot, but nothing else). Implemented with PPL (PCBoard Programming Language). I also wrote Othello for the same system shortly after.

I typed in a lot of games, that's for sure.

My most memorable early games were a kind of "robots" game, and a submarine game.

In the robots game, it was you versus the robot, with mines in the field. The detail is that it was a "real time" game, unlike the typical robots. Hold down the appropriate key, travel in that direction. Let off the key, stop traveling, and the robots still came for you.

Mind, this was (omg) 30 years ago. But it was notable for a couple of reasons.

First was the real time nature of it. Real time keyboard scanning, robot and character update, etc.

The other novel bit was the hacking involved, as I had to find the memory address to show I was holding a key down, and what key that was. Continually scanning memory with PEEK, displaying values, banging on the keyboard. By dumb luck I found the right memory location, heck in theory there didn't even have to be one. But there was.

The submarine game played off of the same "real time" keyboard action of the first game. This game was you were a submarine base shooting at ships running across the top.

The two novelties was the "wave" animation I used (basically 3 different strings of characters printed over and over), and the other was the queue for the torpedoes (! of course). In this game, it used the SHIFT key as the FIRE key, and others for movement. Turns out in my poking around, the SHIFT key was a separate memory location, so I could check if BOTH were pressed at the same time. This allowed me to hold down the LEFT key and the SHIFT key to fire a salvo of torpedoes. After about 4 or 5, the game noticeably slowed down.

This was all done on a PET 2001 computer (As seen in STAR TREK II!) (chiclet keyboard and all).

The other notable thing, was this was all just me hacking it out. We didn't have any books on "programming". That was even before I was reading stuff like COMPUTE and CREATIVE COMPUTING regularly, much less having any understanding of what they were doing. I would do things like write loops with POKE until something showed up on the screen, or the computer crashed, to find things like the screen memory addresses.

Just ... hacking. I also had some machine language routines to do "bit blt" block moves on the screen. Those were so horrible they used self modifying code. But, hey, hand assembled 6502! POKE in to "god I hope this is safe memory" from DATA statements with READ.

Another game I did was a "space invaders" clone. I was so far off in left field, I couldn't think of how to identify which invader I hit. So each invader had a unique character in the middle of it (the notorious A, D, @, and 1 invaders!). When I found a "ship", I scanned nearby looking for the character, that told me which one I hit so I could remove it from the list. TRS-80, didn't really quite get that to work.

I tried the same thing in Z80 machine language, and when I got the base moving I thought it was broken. Hit the RIGHT key, base is on the right side of the screen. LEFT, left side. Never stopped in the middle.

1MHz Z80. Machine language. Mo' fasta than BASIC. It was working fine, just too fast. Needed a delay loop...

So, yea, I learned a lot doing those games. Did a lot of stuff I couldn't name (Queue? what's a queue?) etc.

Good times.

I'm one of those nu-age programmers. Started in 2006 (I'm now 21). My first game was "Tetris of War". It was around that time God of War and Gears of War were hits and I swore their success was in their name.

It was a pretty basic clone of Tetris in C++ using Win GDI for drawing. The most important thing to come out of that development was that blocks rotate in Tetris. Something I had completely forgotten about until very near the end of the project.

In that lies the lesson - I pried too deep into the code and lost perspective. Even now, I look back at that every time I'm in a runt trying to fix a bug or complete a design; that it's important to not get too close to a problem and I take a break or work on a unrelated problems.

First game?

Must have been about 1969. Octapawn, a 3x3 chess board with pawns, described in a Martin Gardner column in Scientific American. Octapawn played the white pawns, you played black (2nd mover); it learned what moves lead to losses, and thus eventually only had moves that could lead to wins. (The scheme for doing this Martin Gardner's, not mine). It was implemented in APL... in about 20 lines total (APL is one amazing language). I learned how to write really complex array code from this, and polished my APL skills.

The next interesting game was Space Wars, on an Imlac electostatic graphics terminal in 1971 at UC Irvine. This was interactive graphics for a 2D Enterprise and a Klingon with psuedo gravity effects drawn at 30 HZ refresh rate using graphics display lists and coded entirely in the Imlac's awful one-accumulator assembly code. At first we used the conventional terminal keyboard with the "/" key as the Enterprise "fire" key and the "z" key as the Klingon fire key. When the keyboard died of abuse (the game was an instant geek success), I built a pair of keypads in phenolic boxes that plugged into the back. Here I polished by skills at graphics, real-time assembler code, and interfacing hardware devices.

I haven't built any games since my 1983 version of Chess on a Motorola 6800 microprocessor in assembler, using a 6-8 ply alpha-beta search, giant transposition tables and the complete opening book from the FIDE encyclopedia (that filled a floppy disk).

I've discovered that building program anlaysis tools is much too much fun.

A breakout clone in Python with PyGame. After posting my resume on craigslist, someone contacted me and offered to pay me $100 to do their Game Design homework for them. =)

• A Lunar Lander in Basic on the Commadore PET ca 1980
• A Pengo-style game in Basic for RM 480Z ca 1982
• A PacMan-style game in Basic for RM 480Z ca 1982

They were not particularly polished but taught me some of the basics of programming:

• transferring an idea into code (breaking the problem down)
• looking for ways to solve a problem (learning the language and the hardware)
• improving performance
• user interface

I studied electronic engineering and had no formal introduction to programming. I guess the fact that I am still designing and programming commercial software (not games!) 30 years later is an indication that it didn't harm my progress :-)

The first game related code I wrote was a sudoku grader. I did it all in C as a hobby project, and half the goal was to optimize everything. It has a very fast solver, and the grader works up to the limit of most humans, although there were a few deeply recursive algorithms that I never got to like death blossoms. Everything was command line, but the OS happened to be MacOS. I never released it.

Sudoku is all about permutations. Especially in finding the canonical form of a board, which was fun.

I turned several recursive algorithms into indeterminate loops, which made them much faster and much harder to code.

Using profiling I found some very counter intuitive speed improvements. That is probably the best lesson to carry on to other projects. Not only that what you think needs improvement may not, but what you think will be an improvement may not be.

I did not get that much better at solving sudoku puzzles, which was a disappointment. Knowing how easy it is for a computer to just brute force a solution makes working through all the difficult human heuristics less rewarding.

Sudoku is a great candidate for bit twiddling, since the candidates for a cell are easy to represent as a small bit array. I learned some nice tricks that I have rarely used since.

My first game was a slot machine emulator, written in Visual Basic 4. Actually, it was the first thing, I ever programmed, so yes, it made me a relatively better developer :)

My first normal game was game lines, looks something like this (can't find the original image right now):

It was coded in 24h content, language: Delphi 5. Game is really simple, hardest part was path-finding. All graphics was made with ms paint on windows 95 :)

Mine was an ASCII maze game as part of a OOP & C++ course. It definitely made me a better programmer (thanks Michael DeRaadt!)

It was before '92, and i had my first machine, a 486-Dx2 Intel with Trio3D graphic card and a soundblaster.

My very very first game was a QBASIC game that told a story and painted the background with colors, it was the beginning of my programming career, and I remember it clearly. Then, the next step i took was creating a little painting program in QBASIC with my own bitmap format, in order to make graphical games, and the next complete game i did was a space shooting one.

Finally, i did a multiplayer deathmatch for 4 players in a little, non-scrollable, destructible maze, with a few different weapons, that behaved totally different (flamethrower, laser pistol, mine gun, machinegun, laser sable, raygun, nuclear launcher, ...). IT WAS VERY FUN!

Moon lander on a TI-59. The TI-59 was a programmable calculator only capable of displaying one line of digits. You had to enter an amount of fuel for the braking thrusters in time intervals of 5 seconds, the machine calculated your new speed, your new height above the ground, and your remaining fuel. Goal was to make a soft landing with your space-capsule.

If I remember correctly, this was one of my first programs I have ever written at all (I was about 14).

My first game was a simple two-user and without and AI tic-tac-toe in console-graphics in c++, after taking first semester of computer programming.

we had one week of classes off, so i sat there in my room the whole week and wrote the game on papers, and dry tested several time. I had no personal computer. so when the classes started, i sat in the lab and wrote it in computer and on first compilation it gave a few errors and then it ran smoothly.

those were the most exciting moments of my life, and i told my teacher and he became very happy also.

it was in 2003.

My first game was a load runner type game built on an Apple IIe. And yes it made me a better programmer because I can look back at that and realize all the mistakes I made. It was horrible.

This question is ancient, just like I am apparently.

My first game was tic-tac-toe (human vs. computer) on a TRS-80 Model I in its built-in BASIC. It was the only non-trivial program in my life to date that ran after I keyed-in the last line of code (after coding it up on paper first): No debugging, no corrections. And since I put a bet on this with my father for unrestricted use of the machine, after that I really got going (assembler and stuff). 1977 or so.

But the most interesting game was a very simplistic PacMan variant (no ghosts, just collect points and see how fast you can collect them all), written for a car radio! Every Blaupunkt Berlin RCM303A still has a little PacMan inside, written for a Siemens C166 and a custom 16-color LCD. But that was the around 1992...

I'm working on it right now, it will probably be a 2D side-slider game in Java that i'll make with the help of instructions from a book on game dev. i've bought. Will post here when its ready.

First "full" and original game I can remember was a shooter on the C64 using GameCreator.

My first game was "Tabi's Dangers", a text-mode adventure game for DOS coded with Turbo BASIC. Sorry, no website, it's lost on a hard drive somewhere in my parents' attic.

Algorithms and/or AI? Sure, I had state-of-the-art instruction line parsing with INSTR and CASE. One block per room.

No graphics, you got the idea for user interaction, no file format/storage, no project. But hey, it had computer-generated music. Feeding random strings to TB's PLAY is a lot of fun when you're 8.

I remember it all started out as a block of code per room, with a few global variables for inventory. The program would initially just GOTO from one to the other as the character moved around. Then, for some reason, I heard about GOTO being the root of all spaghetti, so I just replaced them all with GOSUBs. Ta-da! Problem solved. I did eventually learn about RETURN, but it wouldn't have made any sense to use them with my program's architecture. So I didn't. I left everything as is, but then I actually hoped it would let me see some kind of a stack overflow error. Sadly, it never did.

Of course it made me a better programmer. It made me a programmer, period, and that's good enough.

My first game was a text adventure called Necromancer programmed on my C16.

Later ported it to the Dragon 32 and BBC.

Ahh the heady days of youth.

I did a clone of the classic "Pong" game in C under DOS with custom assembly language graphics routines and a multithreading library from Mix Software. 10mhz 8088 machine with CGA 320x200 4 color graphics and keyboard input!

I started by modifying the source code for ZORK on a TRS-80, when the other übergeeks would let me on it, back in Junior High School. In those days, the keyboard was still attached to the computer, we had a cassette tape drive, and the screen was a flat text monochrome green.

The thing had massive DATA sections and I was amazed at how they made the whole thing work. How did those things turn into a working program? (It was written in BASIC.)

I was all of 15 at the time. But thus began my fascination with computer programs.

It is pitch black. You are likely to be eaten by a grue.

Lunar Lander in VB6 a few years back was my first ever attempt at a game. The hardest part was getting the alien spaceship to chase you properly and avoid the obstacles the level randomly generated. I just never had the motivation before then to build a game, but since then have recreated many games like Simon and 4-in-a-Row in SVG/Javascript with use of AJAX.

Lunar Lander here as well.

Two days after finishing the monster I learned there was this thing called functions.

We've been in love ever since.

My first attempt was on an Atari 800 doing a tile based RPG which I was way too inexperienced complete. My first completed game was a space invaders type shoot em up using assets from other games. My first entirely original game was Inferno ^[1], a side scrolling platformer written in Blitz Basic ^[2].

Edit to Add - Every game I have developed has definitely made me a better developer. They have introduced me to new languages (lua, blitz, flash) and new areas of programming (ai, physics).

The first game that I can remember coding was a snake/mouse game on the Commodore 64 using character graphics and sprites. It had ten difficulty levels and was a lot of fun to play. I learned about simple optimization among other things. It was all what would now be called spaghetti code, but that was all I knew at the time, and was the norm. (Take a look at basic programs in a magazine like COMPUTE! from back in the 80's - Its amazing what the code looked like. - Meaningless variable names and goto's & gosub's all over the place.)

I'm still working on my first game (because I'm far too ambitious and it's going to take me forever). Since August, I've had to teach myself:

• Version control using Subversion and Mercurial
• Javascript
• Python
• C (the math calculations were too slow in Python)

For someone who's only known PHP for the last 8 years, I'd say it's made me a better developer more than anything else I've done in my whole career.

I did a blackjack game in Turbo Pascal. It turned out pretty slick even though I only had DOS characters to work with. It was a great learning experience. I modeled a real deck of cards and used a random function to "shuffle" the cards. The cards were displayed using little DOS hearts, clubs, etc. I had a timer loop so there was some delay in displaying the cards. Of course I had to keep track of the score, betting and winnings. I still have the executable (just played a few rounds!) but I lost the source code a long time ago.

Lode Runner with Turbo Pascal (BGI, anyone?)

Better programmer? No, not really. (I became a better programmer when I got a real job)

My first (real) game would be Spacewar ^[1] for Mac OS 7. I started writing it in FutureBasic (a dialect of Basic for the Mac that had functions, scope, etc.), eventually porting to C and then C++ (as I gradually learned those languages). While I mostly finished it, it was horrendously unstable - it could take down your OS if you looked at it funny.

Looking back, I didn't really know what I was doing at the time, although at the time I thought that I did. I had to put Trigonometry to use to get ship movement and homing torpedoes working, so that was a nice bonus.

I was also proud of the fact that an online friend of mine at the time was writing a Windows version at the same time, but never finished. I was glad that I was able to stick through it until the end, or close enough to the end for the time.

My first game was the first program I ever made: OS: iPhone, Android, any other computer. language: PHP, HTML, Javascript, Java you can go http://www.isaacwaller.com/gulp/ to play it.

The first (computer) game that I remember writing was on an Apple IIe in 6th grade... It was my first experience with the Apple's high-res graphics mode and consisted of a bunch of "missiles" (i.e., steadily advancing pixels) coming in from the top and right edges of the screen which the player had to dodge to survive. I don't recall the filename, but it didn't have any name other than that and I don't particularly recall anyone else ever playing it.

The following year, I wrote a text-based "fly around intercepting enemy space cruisers to save your home planet" game which was fairly popular among some of my friends, so that was probably the first one I wrote that anyone else played.

Breakout using Visual Basic 6 :)

Madlibs for the Apple IIe in BASIC. It asked a bunch of questions to get the values for required variables, then outputted the final story once everything was collected. Probably didn't make me a better developer considering I was six years old, but made me pretty proud of myself at the time. I guess if it taught me anything, it taught me the awesomeness of being able to put in a disk, hit one key (I think 5 or F5), and start programming.

My turn!

I created "aMazing Mazes" for MS-DOS using Turbo Pascal. The first version made use of ASCII characters with some ANSI-style graphics. There is also background music, and later you could choose from the 5 worlds. Each world has 4 stages.

The game is a maze game where you should find the diamond so that the exit door will appear (inspired by Solomon's Key for NES). Later I added spells which you can get when finishing a world (inspired by Megaman).

I made a port where I rendered maps in Pascal graphics instead of ASCII, though it was not finished fully, but I had a great time programming for graphics.

Things I learned:

1. Collision logic.
2. Math is very important.
3. Gameplay design basics.
4. Algorithms you have to figure out yourself (in an era with no Internet).

My first 3D graphics game was 3D Tetris written in opengl. I spent less than a month coding it.

You can find it here. ^[1]

I haven't done much game programming, so I took a while to write one. It was Blackjack written in Python. I wrote it one morning before school to just kill some time. Sadly, it's been lost to the ages.

"Low flying psychopath simulator" written in AMOS on an Amiga A600. Basically a rip-off of TLL on the speccy, but with an F-15 jet sprite rendered in Imagine 3.0 :)

Aaah, those were the days.

The first game I developed was called Gunfight which ran on HDOS (early 1980s). It was a two player shooter. I don't know if it made me a better developer but it really taught me the value of backing up. After it was done, I accidentally deleted the only copy of the source code. It had taken me a few days to develop and luckily the code was still fresh in my head, so I sat down and banged out the same code again in about an hour. I wish I still had that kind of memory ;-)

Console Noughts and Crosses/Tic Tac Toe in C#. AFAIK, I didn't learn anything new, so, no, it didn't make me a better developer.

When I was a young boy... I built a very bad imitation of Pac Man on my Commodore Pet 4016 in BASIC. Soon after, I graced the floppy disks of my Atari 800 with a minefield type of game I called Cow Crossing. (You can guess what the "mines" were.) Those were the days.

I wrote several games early on.

One of my first game in memory that I wrote from scratch (i.e. not typing in from a book) is a Space Invaders clone I tried.

The primary outcome of that project best expressed by abusing Edison: "Results! I have gotten a lot of results. I know several thousand things that won't work."

The most interesting problem I had was trying to figure out which alien I was hitting with the missile. I really struggled with that. The solution I came up with was each alien has a different ASCII (or whatever it was on the TRS-80) character in its center.

When the missile hit, I would "search" for the thing on the screen that looked like the ASCII character, and use that to determine the correct alien to delete.

Now, clearly, this is wrong way to do it. Heck it was obviously wrong at the time I was doing it, but I at the time simply could not think of a better way, and at least the technique let me progress.

What I think the real take away from that experience is that much of the time, software builds software. Only through the creation process do you really flesh out the details of a project. In a way, a project can start one way and end another because you simply didn't see or plan the path that you inevitably took. But, like music, you have to play something just to see how it sounds and how it works. Otherwise you get nowhere.

The best quality of software is simply that it is cheap to fail. Sure there's time invested, but the material is 100% recyclable, and free to use. So, don't be afraid to try stupid things. Don't be afraid to leave "stupid things" in your code if it advances the goal and opens up something new. You can always come back and fix the stupid things.

In fact, that only way you're going to learn the stupid things is to do them and later through experience or learning, discover the errs of your ways.

Risk is cheap in software, may as well take it.

My first game written was the Animal Guessing Game ^[1] on the Commodore 64. I wrote this sometime in the 80s and it amazed me that the computer could learn and be able to guess more and more animals starting with minimal information (1 question and answer pair).

Tic Tac Toe & Pong =)

If it ever had a name I don't recall it. This was back on the TRS-80. The original was programmed by someone else in Basic. The user interface was poor and the AI was awful. As I had the source I tweaked it a fair amount.

I then proceeded to rewrite the game in assembly. That version had no AI but a MUCH better interface and no delays.

Later I wrote another version in Pascal on the PC. This time I put in an AI that did a lot better than the original--the fundamental difference being that my AI could make plans for the future.

I learned that good AI's would be thought to be cheating. The heart of the game was hidden moves--the other player would see what you had moved but would not find out where it was going until it got there. One of the AI routines was an attempt to guess what the human player was up to. The key to winning battles was concentration of force and so I looked at all the outstanding moves to see if they appeared to converge on a single point. If I found sufficient convergence and had time to move in enough defenders I would do so--realistically, you couldn't expect to pull off a raid deep in AI territory unless you launched from a single point to deny the AI the ability to find the convergence.

The first game I programmed was a Haunted Maze game on the Sinclair ZX Spectrum 48K... I copied it from a programming book I got for my 8th birthday. I don't know that it made me a better developer rather than make me want to be a developer. I never lost the bug.

Chess, in c++ 101. :)

My first game was called Hobbit Popper. It was sort of like space invaders, but with hobbits instead of aliens. It was written in Visual Basic 4. I didn't even know what loops or arrays were, so I just copy/pasted code 10 times (once for each hobbit). Nor did I know how to handle keyboard input, so the player had to literally click on the left, right, and fire buttons. Graphics were done by loading bitmaps into off-screen picture controls and then GDI blitting (seriously, I knew how to blit using GDI before I knew what a while loop was) them to the screen.

I miss the days when I didn't know what I was doing and everything I did was amazing.

My first game and first "real project" beyond "hello world" is this : http://www.youtube.com/watch?v=46aopwFD3G4 The game in the video is the 3rd version though. First version was offline for GBA 2player hotseat, never released. 2nd version had WiFi and AI-player, running on DS, released in a WiFi-homebrew-competition some years ago. 3rd version got 3d-gfx, online lobby, pictochat etc.pp, released 2 years ago at neoflash-coding competition.

It's a clone of a Sega Dreamcast online game I was hooked when it was still online. (Original name Splash, one of the 5 minigames in "Planet Ring")

I learned a lot from it - basically started the project from "hello world" niveau :)

Sadly my game isn't online anymore (hosted it on my desktop-pc)

Qbasic and a game was the first thing I ever wrote. I was twelve and made two text based adventures filled with profanity and pornography for my four years younger brother to play. I remembering being proud of the compilation size of the second one that was 3mb!. I also remember getting a 2gb hard drive that cost an arm and a leg, but the poor 486 just could't take it. :P

When I went to college and had my first programming course where they told us about design patterns I had no real interest building the actual game (I already knew quite well how to turn caffeine into code by that point).

Instead I learned just how much time you can spend building on a system without improving it by any measure that isn't just mental masturbation. I'm sure the teachers appreciated I wasn't less verbose in the documentation than in the code. :)

I built a Tic Tac Toe game in high school in about 1988. It has been shown ^[1] that this game is equivalent to some of the most complex game theory ^[2] and puzzles of all time, so I figured I would quit while I was ahead.

I made a game immitating the original NES zelda dungeon levels, with a hint of gauntlet. It was called Meepers ^[1] and was built in C having read and followed along with the book Game Programming in 21 Days ^[2].

It made me a better developer for the application domain by learning how to use pointers, manage memory, build a library, create functionally modular code (most code still in one file), trigonometry and geometric math with vectors, code in assembly but only where necessary, manage the video buffer, double buffering (off-screen buffer) to prevent flickering, develop sprite maps (ie: similar to css sprites today), and plenty more. Overall the process of developing the game taught me how to write code better through both imitation and experimentation.

The interesting thing is that while some of the programming techniques are not used any more, and it was all single threaded sequential code, there was a lot of fundamentals (including math) that has definitely stayed with me through school and work. I often think back or explain something based on the knowledge I gained through learning to develop a game.

However, the biggest lesson I learned is that to learn programming you definitely need to not attempt too large a project because while I implemented all the features of the game, I didn't actually finish writing the game and it only had 2 monster types, 2 levels, and no bosses. Games are probably one of the largest and most complex type of software you can or will write, and also depends on multiple disciplines (art, audio, music, writing, etc).

That said, writing a simple game is probably more fun than a spreadsheet program, though that depends on who you are.

Things I learned:

• Simple AI (MinMax, Evade, Chase, Finite State Machine)
• Mode 13h (VGA 256-color)
• Self create buttons, detect click events by calculation of mouse position
• PCX run-length-encoded image file format
• Self created level file format .mep
• Heavy use of structs (no classes - regular C)
• Erase, Update, Draw run loop
• No project and time management learned, always takes longer than planned :=P
• Much more of course

Wow, popular topic, are we all gamers at heart?

I wrote various bits of games for the Spectrum and played with the game development kits, I wrote a comedic stick man version of streetfighter in TurboBasic and a text version of minesweeper "mines weeper" once on the train home (4 hr train journey), but my first real and only "proper" game was Anagramarama. I wrote it as part of my wife's christmas present because she was addicted to such games.

Homepage - Anagramarama ^[1]

Source - Google Code ^[2]

OS - Linux, Windows, OSX, Amiga, BeOS, too many to count

Language - C

Library - SDL

Learning experience?

• Algorithm - DLB Tree, a beautiful data structure to be sure, written from scratch, last time I had worked on anything as much fun as that was at college working in Pascal
• Anagram routine - hacked away for ages and then came up with a dodgy anagram routine - turned out to be quite fast
• Graphics - it's just letters flying about the screen, with a Barnsley fractal in the background. My mate Alan (an artist) produced the logo for me.
• User Interface - Learned that's what a game essentially is and that it's the most boring bit to write.
• File formats - nah didn't really learn anything there, already had the standard ones down pat
• Project and Time management - hah!

Did I become a better developer? I guess I did, it did show me that for once (non-corporately) I could actually finish something. So much more could have been done and it could have had all it's bugs worked out and removed that ridiculous method for choosing the anagram (i'm ashamed remembering it!) that I put in quickly and always meant to get rid of...

Did I learn my language better? Yes definitely.

The first game I have written is The Game of Life. This games was played at the command prompt in a bidimensional array. There were some persons represented by an asterisk (*), and in order for them to live, they had to have neighbours at the around locations. Too much neighbours around caused them to die, so was it if they had not enough neighbours.

This was programmed in Borland Turbo Assembler 4.0 ^[1], and the code was written in the DOS 6.2 EDIT editor.

It brought me to another level of understanding how to manipulate arrays, and how the stack worked, as we had to write "transparent" procedures, that is, we had to PUSH onto the stack the registries which I was to use before using them in order to save their state in the beginning of the procedure code. At the end of the procedure, before returning to the caller, we had to POP these registries in the right order.

PUSH AX
PUSH BX
PUSH CX
PUSH DX
PUSH DS
... ; Performing procedure operations here...
POP DS
POP DX
POP CX
POP BX
POP AX
RETURN ; to caller...

This has been a great experience to me! =)

Arknoid and tiny Logo [not actually a game] that mimiced few functionalities of LOGO at that time. DOS based. used TSRs and Interrupts extensively.

Being just 20 years old I obviously have no experience with the older PC's where a lot of people are talking about in this question. So don't expect epic Assembly or pure C games here...

Let's say I tried and failed a lot with game programming. I always tend to put the bar too high initially. My first attempt was a 3D game written in java and obviously I failed horribly. I abandoned the project in frustration because of slow progress and just lack of knowledge.

However, just recently i picked it up again and write something very easy. As you should when just starting out with these kind of things.. Right now I am working on a very simple 2D game, again with Java. Been studying some good tutorials and examples and having a lot of fun creating the base engine right now.

I used a program called Game Maker to create my first game, but it didn't really involve any coding, or much effort for that matter.

The first game I actually programmed (python) was a text-based RPG, modeled after Runescape, but obviously singleplayer (and text-based.) You started in an empty "area", and you would enter walk, there would be a 5-10 second delay, and you would wind up in a new "area." Each area had a randomly-generated number and types of trees, rocks, and other things like that. If you mined Gold, you could smith it into 10-15 coins, which could be spent at a randomly-generated store, willing to sell you randomly-generated items for a randomly-defined price. There were also levels that would make woodcuting faster, mining more likely to yield better ores and better quantities, etc. You also had an energy level that starts at 1000, and is depleted slightly as you walk between areas, and depletes more rapidly if you run between areas (using the run command.)

Not only did this make me a better developer, it essentially taught me how to program. At this point, I had done the first 20 or so Learn Python the Hard Way lessons (just beginning functions), and all the trial and error in this program helped with that. If you mined Gold, for instance (3/1000 chance with random.randint()), ic would call xpup(), which would increase your XP in Mining with the number of gold you mined, e.g. xpup("Mining", qtyMined). Had I not wanted to make this game, I might not really "know" python today.