Tetris. It's pretty much the perfect first game. It forces you to figure out how to get everything a typical game needs up and running. You need a render loop, a logic loop, collision detection, and some way to deal with the different shapes. The shapes need to be broken up too, so there's an interesting problem to deal with. Finally, you'll also need a UI, level system, and scoring system.

Tetris is also completely understood by pretty much everyone. You know the rules so there's no actual game design that needs to happen, it's pure tech. The game itself is simple enough that you shouldn't get in over your head. An experienced programmer could probably write tetris in less than day, even without the benefit of any game engine.

Think of Tetris as you "Hello World" for game development. When you're done, post it here.

-Rez

Tetris would be a fun game to write up as an introductory type game, perfect delivery of the different aspects needed in a game. I think what prevents me is that I don't feel confident in my abilities to pull it off.

I know that you have to initialize windows, setup directx (device & swap chain), and then you have to organize your classes, setup a game loop, check for input, and perform actions based on what the user is doing. But then my brain turns to mush and I start to feel overwhelmed. I'd like to throw a prototype out just to amuse you lol.

I'm not saying it'll be easy. I still think it's a better first project than something like poker. Poker has a more complex rule set and I think you'd be fighting with that quite a bit. With Tetris, the gameplay is extremely simple so most of your work is focused on just standing up the systems.

Games are incredibly complex pieces of software so feeling overwhelmed means that you have some understanding to what you're biting off. The very first game I ever wrote was about 5500 lines of C++. The Sims Medieval was well over 1 million lines of code, and that didn't include any of the tools or source control scripts or art export scripts that were written. That had to be another 500,000 lines or so.

There's the old saying, what would you do if you knew you couldn't fail? I think Tetris is just the right amount of terrifyingly complex for a beginner. I guarantee you that the code quality will end up being terrible and you'll hate certain aspects of your design, but being able to identify those things is the first step to making it better. Your second game will be better than your first. By the time you're making your fourth or fifth game, you'll probably have a little library of functions and classes that you carry from game to game. This is the very early stage of building an engine, and your games serve as a primordial soup. Eventually, your utilities and framework code will be bigger than your game code and you'll be able to crank out games MUCH faster because you don't always have to reinvent the wheel.

The key to writing a game is modularization. Building a game from scratch is pretty much impossible, but building a system that renders textured quads is reasonable. Once you get that working the way you like, you can concentrate on something else, like playing a sound. Make a system for playing sounds and figure out how to plug it into the game. Then figure out the next piece and plug that in. The idea is that you're only concentrating on one, bite-sized chunk of work. That's how you make a game.

Structure
Class to handle the blocks that fall
// Data members
Block Name
Block Width
Block Height
Block Length
Block Color
Block Position

// Function Prototypes
Function for determining if a block fits where it lands
Function to determine if a row has been filled

Class to deal with windows and directx stuff
Class to deal with user inputs derived from block class above so that it will be able to use the data members, to make adjustments to the blocks position.
Class to deal with the user interface

Game loop to control speed, look for user input, and update everything.

Your plan seems reasonable as a first pass. I think you're going to run into trouble along the way, but that's part of the fun.

I'm going back over Classes, Pointers & References tonight since they still cause me some confusion. I know Classes are variable types that you create and the inner workings allow you to work with your variable how you want. Pointers just point to information in memory, and allow you to pass them to functions to be adjusted how you see fit, and for references they are almost the same as pointers except they are fixed. Using these your able to return more then 1 value from a function.

Classes are custom types in C++. You should think of classes as chunks of self-contained functionality. For example, you might have the concept of a 3D vector, which fits perfectly into the concept of a class:



Now you have a nice, self-contained chunk of functionality.

Pointers are tricky for everyone when you first learn them. Returning multiple values from a function is actually the least common use-case. A more common use-case is polymorphism and efficiently storing and moving objects. For example:



Polymorphism is a bit more complex. You'll read about that later, I'm sure.

I'm trying to put it all together in my head, but it's a lot to digest. It's like when I read over some code, I can see the flow of things but then I get all confused on what I mentioned in the above paragraph. So I felt writing poker would be the 'ah ha' moment I've been needing.

Yeah, that makes sense, but I still think Tetris is a better thing to start with. It's easier than Poker.

Shew, and lastly after I finish this intro to C++ book I'll be moving into GCC4, this time reading it to really absorb and learn all that it contains. From reading other books, 2D and 3D graphics are pretty much the same minus a few elements needed for 3D, correct me if I'm wrong.

You are wrong. 3D does add another dimension, but there's a whole other layer of complexity. You have to deal with 3D models, converting between coordinate systems using matrix transforms, texturing, animations (probably using skeletons), and a whole pile of complications that you can mostly ignore in a 2D world. Remember, it's more than just representing a world with a Z axis, you still have to project that 3D world onto a 2D plane (your monitor).

Feel free to give me some criticism as it would be most helpful!

I'll tell you what, when you finish your first game, send me the code and I'll give it a full code review. Also, feel free to ask any questions you come up with along the way.

And yes, that goes for anyone on this site who wants a code review.

-Rez

Seeing as Rez didn't mention it, another very important thing to do with pointers, in the case where the memory is dynamically allocated (such as with "new"), is remember to deallocate it somewhere. Otherwise your code will have memory leaks. While you're learning it's probably not a big deal, but it is something to keep in mind. Here's an example of risky code that can cause a memory leak:

void foo()
{
MyClass* pointer = new MyClass();
// Do stuff
if(myFunc() != 2)
{
// Oops, forgot to deallocate "pointer", memory leak!
return;
}
// Do stuff with "pointer"
delete pointer;
}

In this case, if for some reason "myFunc()" doesn't return 2, your code will leave the function without ever cleaning up the memory allocated to "pointer".

Once again, don't let that scare you off of dynamic allocation, just saying it's something to keep in mind. Also, in case you weren't aware, when your process terminates, Windows will clean up all the memory anyway, so you don't have to worry that your game is slowly causing memory to disappear

Cheers,
James

No prob! I'm a lead at EA so I do code reviews multiple times a day. It's become second nature.

Glad you're feeling better!

-Rez

.