1) Use the STL, unless your intent is to learn how lists and dynamic arrays work, use the STL. The STL is fast, flexible, and far more powerful than you think. Start with learning how to use vectors, then strings, then learn how to use the STL algorithms. I'd highly recommend Scott Meyers "Effective STL" book but only after you have gotten you feet wet in C++ and the STL. Learn it early and you'll get use to using it. The hardest part will be debugging the templates created by the STL so remember these important things:
a) The simplest of errors will produces tons of indecipherable error text
b) Always check the definition of the object between the < > signs. Do they have copy constructors? Assignment operators? If you use sort, do they have comparison operators? Usually the error is in the definition of that object.
c) When in doubt check the things you most recently changed.

2) Copy code. You're a begginer, copy it and reverse engineer it. You'll learn a lot trying to figure out how other people's code works. Do not however, be content with leaving things as they are. Copy, then customize and play with it until it makes sense.

3) Do not use void * unless you have absolutely no other way out. You can use templates for most things but these can be difficult to debug when you don't fully understand them.

4) Tetris is a good start, my first game was pong but Tetris is even better.

Rather than simply write a demo showing off graphic ability, it's a good idea (if you want to be a game programmer) to write something that requires a certain amount of interaction with environment and testing for a variety of game conditions. Tetris is a good example. That way you get a fair expectation of the complexities of writing a game.

It's better than going straight for that deathmatch or RTS or FPS or RPG you've got swimming around in your mind.

I understand that if you're not planning to make anything like Tetris in the industry that it might not apply so much. I'd consider it an intermediate beginner challenge. But there will undoubtedly be times when you have to solve some problems that have a complexity that you're going to have to think and plan through. Tetris offers those kinds of challenges.

To help you out, if I were to write Tetris (I wrote a simpler version in college), you can represent the playfield as a 2D array, and the rotating pieces as a list of 2D 4x4 arrays with various blocks set on or off. Then of course there's moving them around, rotating them, testing when they land, looking for rows filled, making those rows disappear and moving everything down, phew.

Quote:Original post by baixiangzhlt
It seems everybody is suggesting tetris as a first step to join this industry

Yeah this is because, as a game, its fairly straight forward, pong is another example of a beginners game although the collision detection for pong can be slightly more complicated.

Quote:But I have been thinking about it for a few days

Excellent [smile]. At your stage thinking up a 'working' solution is IMO just as iomportant as thinking up a 'good' solution, at a later stage you begin to understand better what the difference is and then you can work on training yourself to think up good solutions.

Quote:but still can't find out how to do it.I think it is very hard to work it out

Dont feel alone, every single programmer (in the game dev community or not) gets stuck many many times and spends ages trying to figure things out, the important thing is not to give up.

Quote:So I wonder is it really appropriate for a starter?

To be honest, Yes, I still think its a suitable first game for a starter, perhaps its harder if you have no prior general programming experience but its perhaps one of the easiest to make graphical games.

Quote:I dont know if I should represent the blocks in a class or should I use a collection of bitmaps?

Whether bitmaps are suitable for your blocks can depend on which API you're using for graphics (I'm assuming its the Windows GDI functions?), if you were using OpenGL then I might suggest a simple glRectangle for each block for example.

However regardless of using bitmaps or not, you will still need some way to differentiate between different shapes and different colour blocks:

- Using a class or two is a perfectly valid option, you could create a Block class (for the individual coloured squares) and a Shape class (for the different shapes made from blocks).

- An alternative option might be to use a char to indicate the colour of a single block then the different shapes could be stored as small 4*4 arrays of chars.

You could use a combination of the two and other options exist also. Go with whatever method you feel most comfortable with and which one you think you can make work.

Quote:How do I know if a line is full and can be deleted?

Ok well think about how you how you would know (as a human being) whether a row was full or not? A good approach would then be to mimic however you would do this but in code.

For me, as a human being, if I look all along a row, block by block, and I find there are no gaps then I would conclude the row is full and can be deleted. I would simply do this exact same thing is code [wink].

Quote:If I use an array to represent the state of every grid ,wouldn't it be too much for the memory?

No [grin]
Your computer will barely notice the memory consumption.

Best thing you could do is a have an array to represent the entire grid that all the visible blocks can live on, each element in the array is one block.

Quote:Is STL effective enough in game programming?

Absolutely, trust me you will not be able to produce anything that performs close to the STL, and if you did it wouldnt be nearly as flexible.
That said, I think its definately worth while to know how static/dyamic arrays work, linked lists and trees. Knowing how these work is very valuable knowledge, but definately the STL is what to use when you make you're game.


Hope that was some help.

Quote:
If I use an array to represent the state of every grid ,wouldn't it be too much for the memory?

Seriously, are you saying you can't figure this question out for yourself? Can't you calculate, in rough numbers, the number of bytes this array would require, and compare it to the minimum RAM you expect the system to have? If not, I have to say you need to be introduced to the basics of computers and programming(or even math?). Before you start with game programming, you have to at least know some basics about your resources(CPU,RAM) and your tools(C++,SC++L).

Other than that, tetris,like any game, just requires a bunch of objectives to be met. For instance, first you have to be able to display a block. Then the shapes, then make the shapes fall, fill lines, count the score and so on and so on. Focus on one objective at a time and don't pollute your effort with irrelevancies like what happens in the "industry". And don't worry at all about optimizations. You're not writing UT2007, and you won't do it for at least 10-15 years. Yes, use the SC++L and any other standard or 3rd-party library that can make your life easier, just write the game. That's your only concern now, not what happens in the "game industry". This does not concern you at all. You don't want to know how things are done in the industry. You don't want to work with the conditions and the tools and the restrictions that are used in the industry(I would go on to also saying that you don't want to start with C++, but whatever). You're a hobbyist beginner, make the best of it.