How have your games evolved since your first?

[spirit bomb!]

Hello, I was wondering how people progress in game development. We can all remember our first game. That horrible moving what-not that didn't do too much, but it was sick because you made it.
Then as you progress your games have gotten more complex, and you start to explore different approches.

I wanted to know how everyone developed their skills from their first game to present. Use what ever format u see fit or do follow a format such as....

GAME 1: pong
Language: c++
Enviroment type what nots: Visual Studio + DirectX 9 + Dark gdk <-(has easy to use functions that "write" directX code for you)
What it dun:
Simple unbeatable pong game. The opponent's paddle matched the ball's Y coordinate. So the paddle's center was allways positioned where the ball was.
Learned: collision, user input, simple game logic

GAME 2: top down 2d shooter (no real name)
Language: c++
Environment type what nots: Visual Studio + DirectX 9 + Dark gdk
What it dun:
w,a,s,d moved player. when mouse clicked the player shot from his spot to the mouse.
Enemies ran about switching the object they used as cover while shooting you.
Weapons could be picked up, and included bullet shooters, lasers, rockets.
Learned:
how to make an inventory system,
complex collision,
keeping track of projectiles + enemies,
Artificial intelligence!,
How sin, cos, and tan are useful. (yea never thought the unit circle would come in handy)
how to kill your frame rate,
panning the camera,
so much random math and logic
how to be frustrated beyond comprehesion

GAME 3:
Just starting, going to take game two and make it 2.5D lol.
Ditching Dark GDK, and going straight to DirectX. This way i won't be limited by the lameness of relying on someone else's $h!++y code.

PLEASE SHARE! or i will be a sad panda....sad, sad, panda.....

[programmerinprogress]

Oh! this sounds interesting!

GAME 1: Hangman
Lanaguage: c++ (in the console with windows.h)
Learned: not much, this thing didnt loop or have a GUI, it was essentially just a bunch of simple (and badly written) functions
Description: you got given a mystery word (this was pre-defined) and you had to guess it, you got a few tries before you lost, if you got a hiscore, the game wrote it to a file, the entire game
was in colour, thanks to some messing about with windows.h

GAME 2: Find the Gold!
Lanaguage: c++ (in the console with windows.h)
Learned: more about functions, again, this was just me messing about for some fun
Description: Basically a battleships esque game where you were presented with a small path of ocean-coloured squares with grid references, you typed in the grid references, and if you managed
to find all 3 pieces of gold (represented by the letter G) without hitting a mine (represented by the letter X) then you won the game! I have a real soft spot for this game, mainly because it was
in colour, and it had lots of bleeps and bloops, things that entertained me back when I was starting out, those were the days

GAME 3: BLOCK
Language: c++ (with SDL)
Learned: how to use a multimedia API (or rather how not to use it at some time ), more about classes, pointers, useful stuff
Description: A platformer game, that allowed you to control a block on the screen, when the block got injured by spikes, it changed colour, when it ran out of health, it disappeared.
Another game I look fondly at, an a likely candidate for a reboot at a later date
PS: This game was accompanied by my first level editor, thaty was a really fun project to do, And hope to make a future version of that too!

GAME 4: Match Up
Language: C++ (with SDL)
Learned: how to structure a game properly, how to use at least a minimum level of polish, oh and how to optimise my algorithms (at one point I manged to get a function down from 40 lines of code to about 6!)
Description: a simple tile-matching game, highly unoriginal, it was an example project in one of my books, but that didnt matter because I was using a different API and wrote it my own way, I was also not trying to go
for a complelling storyline, but reallly just trying to see if I could make a game that had some logic, and looked ok on the eyes.

GAME 5: Alien Invasion!
Language: C++ (With SDL)
Learned: how to work to a deadline, the advantages of static allocation over dynamic allocation (that was accidental haha), how to make a SHMUP
Description: This was probably one of my most important steps forward in my programming career to date, I was no longer mashing away at at a keyboard and taking as long as I liked, I was working to a deadline. The game
consisted of a player on oneside of the screen, and a bunch of aliens dropping bombs down on the player, the player had 3 lives and a hiscore, I designed and implemented this game in a month, as a demo for potential universities,
did it work? well, I'm in university! :lol
SIDE NOTE ABOUT GAME 5: I actually wanted to make a WW2 themed SHMUP, instead of aliens I would have had planes and the player would have been an AA gun, but I REALLY couldn't draw back then (not much has changed but I'm learning)

I don't really want to include any projects further than here, mainly because I've got little done for the past year, it's kind of a shame really

[avansc]

started with pascal

1. ascii space invaders
2. snake (pascal had an awesome graphics library)

then moved on to C

3. platformer with windows GDI
4. something with DX
5. asteroids

after that i started caring less about games and more about the nitty gritty. so after that came a slew of feature specific mini games than never really were games. physics, quadtree, oct, those kinda things. implimenting something like that became more fun than making a complete game.-

[Falco Girgis]

1) Some kind of Donkey Kong Rip-Off - BlitzPlus
2) DCShooter - A 2D 4-player shooter written in C/++ for the Dreamcast
3) Null - A 2D platformer written in C++ for the Dreamcast (and later PC with SDL)
4) Viva La Samba - Samba De Amigo Clone written in C for Dreamcast
5) Dead Sky - 2D RPG written in C for the Dreamcast (later became Elysian Shadows) and later SDL for PC
5.5) Dead Sky Level Editor - written in in SDL for PC
6) Elysian Shadows - 2D RPG written in C/++ for the DC, PSP, PC.

[GroundUpEngine]

This is good idea, it's pretty cool to see others game dev history

(Started with Allegro)

1] Pong - Basic 2D pong game
2] The Farmers Rage - 2D Platformer fail
3] Top Down Shooter - 2D Top-Down Shooter game with few enemies

(Moved to GLUT for practice, then SDL/OpenGL)

4] 3D Pong - 3D pong game

(Moved to SFML/OpenGL)

5] GameEngine->Build()
5.1] Pickin sticks' 3D - Super basic 3D platformer
5.2] Spiked - Better 3D platformer with unintuitive physics (current)

[cndr]

I've pretty much have always used c++, only recently have I learned SDL. started out with hangman, then moved on and did a poker program twice, improving the code each time, I then did a tic-tac-toe game, and am now working on a chess game, it's not very impressive but I've been coding for about a year.

[eatcomics]

1) text space invaders game in blitzplus
2) Ninjamurai! a 2D 2 player ninja go around stabbing and throwing shurikens... didn't finish (blitzplus)
3) Beginning of an RTS could creat unit, and move them to a destination, I had some basic building functionality but they really were just staticly placed images in the code that the units would move around... (blitz)
4) Map editor in blitz, it worked... my game did not, got a memory error whenever you hit a tile... and the editor was horribly unoptimized and not user friendly
5) Some SDL stuff.. a platformer, among other little demos
6) Started DOOM thing in SDL/OGL :D, plan on rewriting, I started once, realized it wouldn't work, then I started thinking about a new structure, haven't started coding yet
7) currently working on a pong/breakout thing for lusikka's competition

[dandymcgee]

1) Dead Gem: NYC (AutoIt): 2D Chip's Challenge / "collect the coins" type game.
2) Login demo (C++): Type a password into console, says success if it's right, colored text.
3) Stickman (SDL): Move stick guy around in the screen at a controllable speed.
4) Tic-Tac-Toe (SDL): AI was impossible for me at this time.
5) Bouncing ball (SDL): Playing with the physics of a bouncing ball.
6) Lockpick (SDL): Concept for a friend, based off Oblivion's lock-picking system
7) Journey to Hezthan (SDL): Very basic workings of an RPG and tile-based maps.
8) Lua Script Game (SDL): More advanced 2D RPG, got to the point of implementing objects/items.
9) Axe-Man (Visual Basic 6.0): 2D platformer where you kill the evil trees, for senior year of high school CS class.
10) Particle Engine (OGL): Crude 3D particle system.
11) Physics Project / Helicopter Game (OGL): More advanced physics demo done as the final project for my Physics class in HS.
12) Snake (SDL): Basic snake remake (boredom)
13) Puffle Game (SDL): Remake of a silly game where you push furry creatures into a pen (from Club Penguin)
14) Breakout (SDL): Basic breakout remake (boredom)
15) Maxuk Arcade (C#/XNA): Arcade games with database scoring system, final project for freshman year of college CS class.
16) Mysteria 2D (OGL): 2D engine in early stages of development. Just implemented point/vector math and dynamic forces.
17) Mysteria 3D (OGL): 3D counterpart of Mysteria 2Din early stages of development. Just implemented an OBJ model file parser/loader.

These are the most important ones (ie. helped development the way I think about programming) in semi-chronological order.

[jasongosen]

The first game I made was in BlitzBasic. I guess you could call it a walking simulator. You could walk around a tilemap that had 3 layers. I learned about simple coding like for loops and stuff like that. I also made a basic editor for it.

Next I made a pong clone in BlitzBasic. Nothing special, just pong.

Then came a long period of time where I didn't make any games. I was learning C++ and OOP concepts.

Now I'm working on a Pickin' Sticks clone. I moved from BlitzBasic to C++, then to Java. Now I'm using GTGE with Java.

[adikid89]

I started programming about 6 months ago when I started college. There they taught us C and asm in the first semester. I loved programming such much.. the prof used to give us some examples of programs, and make us write them... I was so curious what everything did I started exploring what would happen if I change this to that.. and why.. I guess that's a problem solving skill? Anyway I kept programming in c until I had a pretty good grip on it, and by the end of the sem. I started C++. I knew about c++ from somewhere, though I can't remember where... probably just heard that this and that were made in c++, so I had this thing in mind saying c++ rocks! And it does

Hmm... I think it goes like this:
1) Tic-Tac-Toe: A console game. You could use the arrow keys to move the selection box and press enter to make the choice(where to put the x/o). No computer player. Didn't learn much while doing it. Maybe just about GetAsyncKeyState() and others, and practicing what I had already learned.

2) A shooter: A console game. You could move with the arrow keys and shoot with the space-bar. It was a human-vs-computer game. The computer was at the top of the console, and the player at the bottom of the console. I learned about buffers and practiced some oop design... although now that I look over it.. it doesn't look all that good. The computer player had some very basic and retarded ai... I just followed the player, and if a bullet was nearby .. tried to dodge it.

3) Not sure what this is...: A SDL project. I started learning about sdl from lazy foo's tutorials. I wrote a game engine to hide the implementation details and made my first graphics game called yoshi in wonderland. I found on google a nice sprite on yoshi, so I figured I'll make a game about him. I wanted some sort of a mario game... I learned the basics of sdl, some oop designs and concepts.

3.1)Modified Not sure what this is... This is the stage I am currently at... I'm probably going to abandon or write the entire(or most of the) game engine, because when I wrote it, it didn't have in mind that I would load levels from disk. At first the game was all about the yoshi moving up/down, left/right and collision with the edges of the screen.. Then I added another yoshi and called him bad_yoshi.. and made them kill each other. The problem is that I was so lazy to rewrite the engine that my logic looked like this: everything on the screen is a unit except the background, that includes the bullets. Every unit has a unique sprite that loads an image from the disk... (i was too lazy to make a Animation class to extent to Sprite class, so I just made sprite class handle some sort of animation). Learned some "optimizations tricks" (that is.. I only rendered sprites that were on the screen.. that all ), and some things about game states.

Almost everything about 3.1 were a hack to the engine. So I'll ask people who read 3.1 for a little advice :
It is inefficient to load something twice (or more) on memory from disk. So how do you load sprites/etc ?
Here is how I currently load them: check the level data... if it's a unit load that unit. Based on the type of unit in the level data.. it selects the appropriate unit to load(for example if it's the player it load's "yoshi.png" and it also loads 5 times ... "bullet.png", the same is true for computer opponents)

[XianForce]

It is inefficient to load something twice (or more) on memory from disk. So how do you load sprites/etc ? Here is how I currently load them: check the level data... if it's a unit load that unit. Based on the type of unit in the level data.. it selects the appropriate unit to load(for example if it's the player it load's "yoshi.png" and it also loads 5 times ... "bullet.png", the same is true for computer opponents)

Well in the SDL framework I've made (and am currently making), I've created a Resource Manager of sorts. In the manager I have separate banks for images, sounds, and music. So whenever you load something you do this:

Code: Select all

ResourceSystem->GetImageBank().GetImage("yoshi_sprite");

And that will get me the image.

First, it checks to see if it already has the image (it's stored in a map with it's name as the key ("yoshi_sprite" in this instance)), and if it hasn't been loaded, then it loops through each extension it supports and attempts to load it.

If no load attempt succeeds, it returns a default Bitmap that just says "Error" across it.

[adikid89]

Thanks

Well in the SDL framework I've made (and am currently making), I've created a Resource Manager of sorts. In the manager I have separate banks for images, sounds, and music. So whenever you load something you do this:

Code: Select all

ResourceSystem->GetImageBank().GetImage("yoshi_sprite");

And that will get me the image.

First, it checks to see if it already has the image (it's stored in a map with it's name as the key ("yoshi_sprite" in this instance)), and if it hasn't been loaded, then it loops through each extension it supports and attempts to load it.

If no load attempt succeeds, it returns a default Bitmap that just says "Error" across it.

Thanks! That's pretty much exactly what I was thinking of doing. Also the default image is a great idea.

[XianForce]

Thanks! That's pretty much exactly what I was thinking of doing. Also the default image is a great idea.

Yeah I asked a similar question not too long ago. Falco is the one that suggested I use a default image to return. His system seems more complicated and useful though haha =D.

[GroundUpEngine]

Thanks! That's pretty much exactly what I was thinking of doing. Also the default image is a great idea.

Yeah I asked a similar question not too long ago. Falco is the one that suggested I use a default image to return. His system seems more complicated and useful though haha =D.

Nah, Falco's system is pretty smart implementation imo

[XianForce]

Thanks! That's pretty much exactly what I was thinking of doing. Also the default image is a great idea.

Yeah I asked a similar question not too long ago. Falco is the one that suggested I use a default image to return. His system seems more complicated and useful though haha =D.

Nah, Falco's system is pretty smart implementation imo

That's what I'm saying haha >.>