New(ish) To game programming, Were to go next?

[StoveBacon]

Well, I've been working with c++ on and off for about a year and i'm starting to work into games.
I've learned alot of Allegro.
I've made a space invaders game along with a pong game.
My question is..What game should I make next?
I would really hope to be working on a serious game within a couple months, instead of the "Games to learn what your doing" kinda stuff.
Thanks
Keith.

EDIT: i'm also art and music self sufficient

[mv2112]

Well, whatever type of game you want to make is up to you. However, i would recommend as you get more comfortable with C++, move to SDL (im a SDL fanboy ). It doesn't have built in primitive or text support, but is more powerful than allegro and will allow you to integrate openGL in the future. You could try you're hand at a 2d game engine, or maybe recreate one of your favorite games or make up a entirely new game. Just try not to be over ambitious or you'll set yourself up for failure.

[StoveBacon]

Ok, i was considering moving up to SDL sometime soon.
I think that a 2d engine right now is slightly out of my range.
thanks for the reply

[WSPSNIPER]

Ok, i was considering moving up to SDL sometime soon.
I think that a 2d engine right now is slightly out of my range.
thanks for the reply

i would go SFML but i love SDL as well. but back on topic i would recommend making a top down shooter... just because then you follow my progression! but whatever game you make it will be fun and you will learn from it :D

[davidthefat]

Physics based projectile/cannon program... LOL I might consider doing it in a week end and giving it to my Physics teacher for extra credit... Too bad he has a real life mini cannon he demos with

[Milch]

I would recommend read this article:
http://lazyfoo.net/articles/article01/index.php

[StoveBacon]

Alright, i'll try and make a simple game with SDL to get used to it.
probably just going to follow lusikkamage's pickin' sticks guide.
I'll post back later with my progress and hopefully little questions.

UGH I'm trying to Learn SDL and I've been reading articles and stuff but i just cant get it.
Apparently i have a real bad memory leak since drawing one image uses 100% of my CPU.
Also my color key is only making half of the magenta color disappear.
AND i can't find out how to clear the buffer after you flip it to the screen, because when i move my player it permanently draws it to the screen( when i move it left it draws the player at every pixel between were i started to were i stopped).
I'm considering just going back to Allegro

[Bakkon]

AND i can't find out how to clear the buffer after you flip it to the screen, because when i move my player it permanently draws it to the screen( when i move it left it draws the player at every pixel between were i started to were i stopped).

Just literally clear the screen with a solid color.

Code: Select all

SDL_FillRect(screen, NULL, 0);

As for ideas of game progression: Breakout => Tetris => Shmup

[WSPSNIPER]

well here is my progression

pickin sticks -> small platformer -> shmup -> top down shooter -> (in progress) top down racer

i have also made some 3d stuff and a few map editors and stuff like that

[Moosader]

well here is my progression

pickin sticks -> small platformer -> shmup -> top down shooter -> (in progress) top down racer

i have also made some 3d stuff and a few map editors and stuff like that

Pickin sticks -> Shmup -> Other (80's) arcade-style game -> Platformer -> Rpg
is what I would usually suggest (in general).

Shmups are easier than platformers, since platformers have physics/gravity, maps, and more collision detection going on.

By RPG I just mean really the implementation of a scripting language and various game states.


I pretty much tell people that they should try to make games based on the history of video games.
First pong, then slightly more advanced stuff like maybe Robotron, Defender, Frogger, etc. Then old Atari/NES type games, and on.

[MrDeathNote]

I pretty much tell people that they should try to make games based on the history of video games.
First pong, then slightly more advanced stuff like maybe Robotron, Defender, Frogger, etc. Then old Atari/NES type games, and on.

We look to history to find the way forward...

[Moosader]

I pretty much tell people that they should try to make games based on the history of video games.
First pong, then slightly more advanced stuff like maybe Robotron, Defender, Frogger, etc. Then old Atari/NES type games, and on.

We look to history to find the way forward...

Those who fail to learn history are doomed to repeat it.

Keep this in mind when designing games as well. Don't over-design and over-hype and under-organize (*cough*Daikatana*cough*)

[GroundUpEngine]

I pretty much tell people that they should try to make games based on the history of video games.
First pong, then slightly more advanced stuff like maybe Robotron, Defender, Frogger, etc. Then old Atari/NES type games, and on.

We look to history to find the way forward...

Those who fail to learn history are doomed to repeat it.

Keep this in mind when designing games as well. Don't over-design and over-hype and under-organize (*cough*Daikatana*cough*)

Very true. Hmm I can't remember trying an Rpg, though they can be discouraged when your just starting out.

p.s. cool avatar

[dejai]

I would probably just start learning about storing game data outside of code. That seems to be where you are up to and it is a critical skill in game development, parsing data and efficiently storing and accessing it and representing it. From what it seems this is something you have not become familiar with. Try embedding scripts in your games (lua) to describe object behaviour which is a standard in the industry... Learn opengl and or directx as they are really important. Throw in some maths. Do you want to be an engine developer or a game developer? They are different. The above advice was for an engine developer which is what I aspire to be.

[Van-B]

When learning, I would take an old, established game and add my own spin on it. It's vital to make a game that you want to play, so if you never liked an old game then you could put it right. For example, I made an Arkanoid game, but the most annoying thing about those games for me is the lack of control, so I made it possible to control the direction based on the movement speed, so it's possible to send the ball back in the opposite direction. Anyway, I do this quite a lot, because it's a great way to learn. If you take Arkanoid and break it down, you have ball collision, updating collision data, level loading and progression, vectors and projectiles. That's a lot of useful learning, and simpler games are easy to keep organised, so it's a good way to test out ideas and techniques once the learning is out of the way.

It's worth having a game project in the back of your mind, like the game you always wanted to make, then pick away at it, learn the techniques you'd need to make that game by making smaller, retro games. I find though, that it's the theory that has to be learned, not exact code - there's no point in pasting in someone elses code if you don't understand most of it. Game logic is portable, doesn't matter if your using BASIC or C++/C/C# or anything, learn the theory than convert that to code yourself. If you don't know the code/syntax, then needing to know the code/syntax is a very good motivation for learning it - personally I learn a lot quicker and better if it's something I need to progress - I wouldn't bother with any 'teach yourself...' books, there are far better references and resources online, for free.