Thread: Start program games

You gotta start small like Oysterman is saying, get console programming down to a T, then move on to Win32 API (if your going to be making windows games and also if you're going to be using API's like OpenGL or DX), and then onto an API you like, such as OpenGL or DirectX, and you just keep moving on from there.

The key is however, you can't skip a step. You can't jump from knowing just a little console to delving right into the complicated API's of DX or OGL. It's like wanting to play baseball but never starting at T-Ball and instead jumping right into the Majors!

So get down console programming, then spice it up a bit, add color, then do some SDL, and go on from there. I know many people tell you this and you're sick of hearing it, hell, so was i when i was in your shoes, but it's the truth, after a few years of programming i can tell you right now, its the truth.

Good luck!

Have Fun!

=D

To program games seems hard and that's why i want to do it!
Where should i start? I've read an article at GameDev and it says i should start out with building a Tetris game.

When you break anything down into smaller tasks, it makes it a lot easier. I believe the main problem people have is that they fail to plan out the project properly. Most good game guides you read will tell you the same thing. If you are good at breaking down a big problem into lots of smaller problems, then you are halfway there. The other half is actually doing it. I try to look at it like you are an architect or an engineer. Whatever you are building, be it a house, a car, or a program, you need to have a good blueprint to tell you how everything fits together. There is no way you could build a house without first drafting it out on paper, so why would anyone think they could create a program without first drafting it out on paper? You wouldn't start off building houses right away either. You would work your way up by building a birdhouse or some smaller project that gives you the confidence and skills that you can apply to bigger projects. Also you don't really build a house by yourself. You have plumbers, electricians, concrete masons, and carpenters. Same with large games. You need a team of specialists.

I would suggest that you pick a game that YOU are really familiar with. Maybe it is a childhood board game, a card game you play with friends. Pick something you know the rules for, and how the game flows. Then play through the game writing down what you do each step. Make a note of ALL possible choices not just the one that you made. Also make a note of the different paths that exist and what conditions are required to take that path. Once you have a detailed blue print, it is just a matter of abstracting the data. How do you want it to look on the screen, the colors, menus, what graphics library to use, what data structures will you use, and so forth. Any choices a player makes is going to be a place where you need to input data from the player either through the keyboard or mouse.

Lets take Tic tac toe as an example.

First you draw an empty board which is a 3X3 grid with no outer border # This gives 9 spots

Two players

One player choose X, the other O

choose which player goes first

There are 9 initial choices for the first player to place the token

once a token is placed the spot becomes occupied and no other tokens can be placed there

Players take turns placing one and only one of their tokens on an unoccupied spot on the board until game ends

game ends in either a win or draw

winning conditions is 3 of the same token in any row column or diagonal

for the first four turns we do not need to check for a winning condition since a win is not possible in less then 5 turns

3 rows
3 cols
2 diagonal

8 total conditions

it is a Draw if all 9 spots are filled and there are no winning conditions

Without thoroughly planning it out, you may not think to check for a draw condition until later on. You may not realize that the game can only go a maximum of 9 turns. You may not realize there are only 8 winning conditions.

Most of the time you spend learning how to use the graphics library has nothing to do with how your game works. You can think of it kind of like a separate layer. You have your game logic code that you would create from the above. And then you have the graphics and input which can be implemented in a variety of ways. You could do a 2d tic tac toe, or a 3d tic tac toe. You could do it in OpenGL, DirectX, Allegro, or SDL. The underlying game logic will be the same no matter which graphics library you use. That is why most people recommend using a console. You don't need to concern yourself so much with all the bitmap manipulation, animation etc. Once you have the game logic down, it is very easy to rewrite it to use use a graphics library of your choice.

After tetris, improve it first, then id go for pac-man. This involves a decent level of enemy AI and you will have to keep track of the game engine state more that tetris does. Also, ensuring that an enemy ( ghost ) has been eaten or not, or pac-man has eaten a power pill was one of the main challengers I faced. Great fun. And the sense of achievement you get out of completing a game is top notch