Sign in to follow this  
Jiggle156

Planning (OO - Design) ?

Recommended Posts

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 :)

Share this post


Link to post
Share on other sites
[quote name='Jiggle' timestamp='1318188472' post='4870878']
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 :)
[/quote]

Don't have different ideas. I don't mean to be a smartass, but that's something to learn: think through a few designs in your head (do some prototyping as needed). Eventually you'll end up with [i]one [/i]that is well formed in your head. Don't code while you're still trying to pin down which of the different approaches you want to go with or else you end up with this sort of result.

Don't worry too much about it though. You'll only learn how to make an effective plan by making a few ineffective ones.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I usually have a pen and legal pad at my side so I can sketch out my ideas when I first approach a problem. This could be literally sketching or writing pseudo code, essentially working through the design (in my head, as well on paper), or comparing different solutions (usually fitting time/space complexity requirements, or keeping things simple).

I'm a big believer in iterative and incremental development, where you continually develop and prototype a solution until its satisfactory. I find prototyping (especially prototyping in the small, e.g. a subset of the solution) helps to try out your code so you can find and fix deficiencies in the design, before it becomes costly to remedy them. Like some of the other folks who have replied, this is very important when you're designing a solution in an area you're unfamiliar with. A big part of this approach is to "divide and conquer" the problem you're trying to solve, so you break your overall design into smaller, more manageable chunks, which certainly is a big part of OO design. Heh, I think that's the usual advice for dealing with math word problems too, but it helps! It also helps in testing, since you can test individual pieces of your code as single units as you're developing, rather than having to test your application as a whole (which can be time consuming and frustrating!).

Share this post


Link to post
Share on other sites
[quote name='Jiggle' timestamp='1318188472' post='4870878']
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 :)
[/quote]

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.)

Share this post


Link to post
Share on other sites
[color=#1C2837][size=2][quote]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][/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[color=#1C2837][size=2]This. [/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[color=#1C2837][size=2]You want to make a tetris clone? [/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[size="2"][color="#1c2837"]Start at the lowest possible level available to you. [/color][/size]
[size="2"][color="#1c2837"]
[/color][/size]
[size="2"][color="#1c2837"]The block. [/color][/size]
[size="2"][color="#1c2837"]
[/color][/size]
[size="2"][color="#1c2837"]How many pixels wide is the block? What properties does it have? Does it do anything besides describe a block is? [/color][/size]
[size="2"][color="#1c2837"]
[/color][/size]
[size="2"][color="#1c2837"]Moving on then is the shape that incorporates these blocks. [/color][/size]
[size="2"][color="#1c2837"]What are the shapes properties? How many blocks wide/long is it? (Notice I never mentioned pixels? :))[/color][/size]
[size="2"][color="#1c2837"]How fast will the piece be moving? [/color][/size]
[size="2"][color="#1c2837"]
[/color][/size]
[size="2"][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. :)[/color][/size]

Share this post


Link to post
Share on other sites
[quote name='Daniel_RT' timestamp='1318362102' post='4871567']
I recommend using Microsoft Visio to make a UML structure.
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Fekete' timestamp='1318378232' post='4871665']
[color="#1C2837"][size="2"][quote]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][/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]This. [/size][/color]
[color="#1C2837"] [/color]
[color="#1C2837"][size="2"]You want to make a tetris clone? [/size][/color]
[color="#1C2837"] [/color]
[size="2"][color="#1c2837"]Start at the lowest possible level available to you. [/color][/size]
[size="2"] [/size]
[size="2"][color="#1c2837"]The block. [/color][/size]
[size="2"] [/size]
[size="2"][color="#1c2837"]How many pixels wide is the block? What properties does it have? Does it do anything besides describe a block is? [/color][/size]
[size="2"] [/size]
[size="2"][color="#1c2837"]Moving on then is the shape that incorporates these blocks. [/color][/size]
[size="2"][color="#1c2837"]What are the shapes properties? How many blocks wide/long is it? (Notice I never mentioned pixels? :))[/color][/size]
[size="2"][color="#1c2837"]How fast will the piece be moving? [/color][/size]
[size="2"] [/size]
[size="2"][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. :)[/color][/size]
[/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.


Share this post


Link to post
Share on other sites
Visio (or a similar piece of software) and a pen & pad combo are your best friends when it comes to the OOP design paradigm. While there is always some debate as to whether UML is actually useful, it all comes down to preference. For example, my design process is like so:

1) I usually run through the program in my head, thinking about the various class that I would need to create. While this never is an exact match to the end product, it gives me a place to start.
2) Once I get some ideas flowing through my head, I go to the pen & pad, and start to jot down my ideas, considering how they all fit together. I continue to do this until I have a prototype that I think might work.
3) At this point, I move on to Visio and create a UML structure from my prototype. While creating the UML, I usually realize a few flaws that I didn't catch before, and fix them accordingly.
4) Once the UML Is finished, I take a few days (different sittings) to reread the UML and try to catch more problems.
5) Once I'm confident that the UML is sound, I start to implement it in code.
6) There is sometimes some tiny details that I missed that I directly correct in code and then alter in the UML.

Keep in mind, however, that although this is my method, everyone has their own ways of doing things. The trick is finding your own means. No one's mind works the same as some one else's.

Share this post


Link to post
Share on other sites
[quote name='AllEightUp' timestamp='1318388427' post='4871703']
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.
[/quote]

That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1318444213' post='4871944']
[quote name='AllEightUp' timestamp='1318388427' post='4871703']
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.
[/quote]

That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.
[/quote]

Actually I have a much similar approach in thought ^.^ Maybe I don't go as hardcore as the feller in the quote, but it's basically manipulating data.

Share this post


Link to post
Share on other sites
[quote name='boogyman19946' timestamp='1318446451' post='4871952']
[quote name='Telastyn' timestamp='1318444213' post='4871944']
[quote name='AllEightUp' timestamp='1318388427' post='4871703']
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.
[/quote]

That seems like an awkward way of thinking of things. At least the 'everything is a function' mental model of lambda calculus has its own elegance/provability.
[/quote]

Actually I have a much similar approach in thought ^.^ Maybe I don't go as hardcore as the feller in the quote, but it's basically manipulating data.
[/quote]

Data is the #1 item in most games, code is secondary in my thinking. (Long years of optimization; almost everything ends up as a data access problem at the most critical points.) But, keep in mind when I said "database" I should have been using the term "data" without limitation or implied structure. A vector is a database, a list is a database, a scene graph is a database, and of course a simple "string" is a database. A database in my thinking is "data" with a set of queries defined and/or a generic query system. (All containers in STL are "databases" by this definition.) For the game programmer, this means thinking about something like a scene graph and considering the data which is stored and how you intend to query it (and by definition use it in various places). Or, for a spacial awareness system, a db of points in space, some underlying structure and the queries which will be used on it.

Given the original question this is getting very off topic, but the underlying data almost always drives the oo "design" and the problems with the designs are usually only found when you try to access the data and find that various pieces of code don't have efficient/direct access. I'll write entire systems using nothing more than a vector knowing that it will be horribly inefficient just to make sure the data organization works. So long as the data layout is valid it is quick and easy to rewrite all the internals with proper structure and efficient implementations. As soon as you hit a data layout problem though, those are usually the most nasty issues because moving data implies changing all accessors to that data which can be very significant portions of code.

Again, it's an extreme view, but it works for me.

Share this post


Link to post
Share on other sites
"A database in my thinking is "data" with a set of queries defined and/or a generic query system. (All containers in STL are "databases" by this definition.)".


In OO parlance, this is an "object".

Share this post


Link to post
Share on other sites
[quote name='jonbonazza' timestamp='1318439605' post='4871915']
Visio (or a similar piece of software) and a pen & pad combo are your best friends when it comes to the OOP design paradigm. While there is always some debate as to whether UML is actually useful, it all comes down to preference. For example, my design process is like so:
[/quote]
I think the UML standard is more debatable than the concept of diagramming your system. I don't know anyone who has found diagramming bad and consistently made good system design decisions.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this