Hi there!
I recently started a Tetris-Clone, which isn't going too well due to a lack of planning. I have some code written, but it contains elements from different ideas that I had over the course of a couple of days, and whilst some of the code is still useful - this project is unlikely to go anywhere without some direction.

Could someone please explain how to make an effective plan for an OO game?
Thanks in advance

Try to think of the different parts you need. OO programming is called such because it is a bunch of parts that fit together in a certain way. A Tetris clone has pieces (the 7 Tetris pieces), blocks that make up those pieces, a place to put those pieces, etc. Figure out how you want your objects to be. You might decide have blocks to make up the pieces is a stupid idea and just decide to have a Piece class that defines the entire thing.

Making mistakes is totally fine. Just make it work. Once you have something that works, then go back and consider how you can improve it.

When you have experience, then you can start foreseeing the problems you'll face. Essentially, you can then skip making most mistakes and go straight to building something reasonably well-designed.

Hi there!
I recently started a Tetris-Clone, which isn't going too well due to a lack of planning. I have some code written, but it contains elements from different ideas that I had over the course of a couple of days, and whilst some of the code is still useful - this project is unlikely to go anywhere without some direction.

Could someone please explain how to make an effective plan for an OO game?
Thanks in advance

With something like Tetris, don't be afraid to just chuck it all and start over, referencing the good bits as you go. Even larger games (say Quake 1-3 for instance, as documented examples) tend to throw out large bits of code while trying to find the correct solutions. Part of the challenge in this is learning which pieces you end up reusing and then finding a way to place those pieces of code in a utility library while allowing you to keep moving forward. Now, having said that, I don't suggest this as a learning method, even if you've screwed things up, try to push through them and get a functional result prior deciding to restart. As you move forward with your abilities you don't want to give up on things too often, later in life, if you go professional, "other folks" will make mistakes and you'll have to learn how to fix the problems without the ability to rewrite. Fixing your own problems is a good starting point, even if in the end the result sucks, at least you worked through it and not only understood the problem enough to fix it in a possibly hacky way, but worked through something when you can't just go back to scratch.

Having said all this, I highly suggest you look into test driven development when starting out. It's not "OO" directly but forces you to think in the way which works towards it. By definition, test driven development forces you to work in a piecemeal manner. Write a single "concept" of code which can be tested. It can be a complicated piece of code such as say: "determine if the input data contains a row of blocks to be removed", it's a simple thing but it is both testable and reusable in the long run. Better, if you decide you want to represent how the blocks are stored in memory differently, you have a great place to test any new code involving how to find a "row", how to map the world of blocks to easy access indices or how ever you may want to access the information. If this item fails testing, something in the new code or support code is broken.

The big deal is "don't think about the game" when writing code but the bits that go into making the game. There is no way to learn this other than by experience. And test driven development helps greatly in forcing you to think in the "bits" way when writing code because if you can't test it, well it's probably monolithic and not OO. (And before everyone flames me, THIS IS NOT SUGGESTED TO BE PERFECT.. Just a very good starting point.)

I recommend using Microsoft Visio to make a UML structure.

[color=#1C2837][size=2]

The big deal is "don't think about the game" when writing code but the bits that go into making the game. There is no way to learn this other than by experience. And test driven development helps greatly in forcing you to think in the "bits" way when writing code because if you can't test it, well it's probably monolithic and not OO. (And before everyone flames me, THIS IS NOT SUGGESTED TO BE PERFECT.. Just a very good starting point.) [/quote]
[color=#1C2837][size=2]

[color=#1C2837][size=2]This.
[color=#1C2837][size=2]

[color=#1C2837][size=2]You want to make a tetris clone?
[color=#1C2837][size=2]

[color="#1c2837"]Start at the lowest possible level available to you.
[color="#1c2837"]

[color="#1c2837"]The block.
[color="#1c2837"]

[color="#1c2837"]How many pixels wide is the block? What properties does it have? Does it do anything besides describe a block is?
[color="#1c2837"]

[color="#1c2837"]Moving on then is the shape that incorporates these blocks.
[color="#1c2837"]What are the shapes properties? How many blocks wide/long is it? (Notice I never mentioned pixels? )
[color="#1c2837"]How fast will the piece be moving?
[color="#1c2837"]

[color="#1c2837"]And this is just the icing on the cake, but if you can visualize tetris, then try to describe everything as clearly as possible then convert that into an object.

I recommend using Microsoft Visio to make a UML structure.

Not to say UML is not useful but, I've never found it very viable in the long term other than for the TDD process so others get some idea of the outline of things. As such, I've stopped using UML directly but instead write headers which include the outline methods and data requirements. I run those through DOxygen or Understand For C++ and simply drop the resulting UML images into any documentation required. When tech types question things, I just give them the headers and explain the thinking. For more detailed questions I "outline" certain functions which usually ends up modifying connectivity between the headers and/or moving data from one to another because the initial visualization didn't take into account for proper dependencies.



It may be a personal item but I find most UML tools more of a headache than they are worth compared to just generating UML from a placeholder header. I say this in terms of the size of the item though. Obviously I would not write all the headers for a complete game, but I would systematically start at that point from a high level UML which describes the game in a non-technical manner.

[color="#1C2837"]

The big deal is "don't think about the game" when writing code but the bits that go into making the game. There is no way to learn this other than by experience. And test driven development helps greatly in forcing you to think in the "bits" way when writing code because if you can't test it, well it's probably monolithic and not OO. (And before everyone flames me, THIS IS NOT SUGGESTED TO BE PERFECT.. Just a very good starting point.)

[color="#1C2837"]
[color="#1C2837"]This.
[color="#1C2837"]
[color="#1C2837"]You want to make a tetris clone?
[color="#1C2837"]
[color="#1c2837"]Start at the lowest possible level available to you.

[color="#1c2837"]The block.

[color="#1c2837"]How many pixels wide is the block? What properties does it have? Does it do anything besides describe a block is?

[color="#1c2837"]Moving on then is the shape that incorporates these blocks.
[color="#1c2837"]What are the shapes properties? How many blocks wide/long is it? (Notice I never mentioned pixels? )
[color="#1c2837"]How fast will the piece be moving?

[color="#1c2837"]And this is just the icing on the cake, but if you can visualize tetris, then try to describe everything as clearly as possible then convert that into an object.
[/quote]

I personally take this view even further. Every program in existence is a database. Even "Hello world" is a database, it consists of the data "Hello world" and the "view" or "transformation" how ever you want to specify the results of "printf" in this case In terms of "transormation" it would be to move DB entries to console output, in terms of view it would be "printf" is the view implementation. Blocks are just a piece of data: "color at grid location". A "pixel" representation of the block is just a transformation to a different view, and a shape is just a higher level representation of multiple blocks in the database.

Usually these data transforms are thought of as various game systems and the connections between them. Consider the case of taking a game world item and transforming it into a visible form, you "transform" the internal representation into 2d/3d coordinates and assign a view to the result. I.e. you map an index in the db to a pixel location on screen and draw the "view" of the data at that location. Going the other way, you can't just insert multiple blocks into the game world to represent a shape, you have to keep information about the shape so that moving it down, rotating it etc properly move all blocks at the same time. In DB terms, you build a temporary table to contain the shape, and the "visualization" merges the temp table and the game world.

I know, an odd idea. But I'd put bets on no one able to present a case where a program is not explainable as a DB.