I find that object oriented design is nice, when used sensibly. Don't go overboard and try to have a perfectly OO system, because it can be more difficult. At least that's my very humble opinion.

What I usually do, is I have one main class, usually built off a JFrame/JApplet, that does things like create the window, handle events, and has the update/render game loop in it.

Each general grouping of game objects I make a new class for, like I'd have a Ship class, an Asteroid class, and a Missile class, if I was doing an Asteroids clone. Each one of these is going to have render/update functions, that will be called each frame from the main game loop. They might also have special event handling code that will be called from the main program event handler. Then they would have any other code that would be important for their interaction with another object, like the ship would have a function called fire_missile(), or explode(), and the asteroids would have ones like spawn_two_smaller_ones(), stuff like that.

Quote:Original post by ggp83
I'd say you should just finish the game by all means necessary, instead of thinking up some kind of design. Thinking about designs to much can lead to a trap which prevents you from completing something because your design isn't right or your code doesn't follow the design enough etc... Believe me that can happen, and you can be stuck in it for many years. Also if you skip the design process and just try to finish the game you will learn alot of things along the way, that will make it alot easier to design your code in the future. I don't recommend you start designing before you got some heavy-ass coding experience...

I suuggest you finish that tetris game and then design it.

I agree with most of this. I would start out throwing the game together. This is usually a pretty fun process. Then, as you get to a functioning point (IE background displayed, sprites working, player input working, etc.), refactor and clean up the code. Again, this is an exciting phase, as you see it start to come together. Focus on naming convensions and consistent naming across classes/functions.

I've recently had trouble starting projects because I get bogged down in creating the perfect design. It will almost never happen, the design should be an ongoing process.

I've also recently had to do a lot of restructing of some old code I wrote. This was much easier to get into. I started out improving areas of the code; But, I never got bogged down in redesigning the entire program. I've made a lot of progress, enjoyed doing it, and feel good about what I've ended up with. And, an improvement usually inspires the next improvment. I've taken the approach that I am going to upgrade the program in small steps, rather than in one big swoop. Which, ironically, is how I created the program in the first place. I started out creating a proof of concept, and added to that, as needed.

There's also stuff you won't know in the beginning. For example, what return value will you use for a function? Initially I used DWORD values defined in #define statements. This seemed a good choice at the time, but in debugging all I got was a return value of 7. I had to go find the #define statements and look up 7. But, when I change the return value to an enum, Visual Studio actually displays the name of the enum. This saves me a step in debugging, and isn't any worse than a DWORD return value.

[Edited by - cdoty on April 20, 2007 11:51:04 AM]

I think you're going to have difficulty applying the method of use cases to games. Really, there is only one use case: The gamer sits at his computer and plays the game. What you should perhaps borrow from this method is instead writing the story of what the gamer does. He double-clicks your icon, and gets a start menu, with maybe some music. He clicks on "start game" (well, for Tetris you may want to skip this step) and enters level 1. He moves blocks back and forth. And so on.

The objects inside your game are not actors in the sense that use cases speak of, so don't try to apply what you've learned about use cases to them. What you should do instead is figure out what objects you need. For Tetris, basically, you only need blocks. Reading keyboard input, displaying the game board, music, high scores - all this is just scaffolding; the entire game logic is contained in those blocks. So you should start with the blocks, and figure out what sort of scaffolding you need. The most basic would be a display and a keyboard input.