How can I tackle building a tetris game in C++ with my team?

[prelic]

I'm taking an undergrad CS course, and we've been split up into teams and have been assigned a tetris game in C++. The limitations are very loose, and we can basically do it however we want. I've had 2 C++ classes and a class in Java, so I'm not that new to programming, but I am new to something this complicated and in-depth. Most of the programs I've written have been console-based applications that are single-purpose and not very complicated. I know I won't have that much trouble writing the classes once I have a good idea of where to start and a decent algorithm, but as of now, I really have no idea where to start, so any and all advice would be greatly appreciated.

 

[mgb_phys]

MVC (Model-Controller-View) You need three parts:

Model = stores the data describing the state of the program, which blocks are present, where are they?

Controller = works out how each block will move on the next go, which are already at the bottom, which are falling, where the sideways moving thing is.

View = takes the model and displays it on the screen. Don't worry about this too much - in fact for testing it might be easiest if it just wrote out lines of text with * representing the blocks.

 

[ganstaman]

And the greatest part of the MVC ______ (some noun fits in that blank rather well) is that it breaks down the problem into testable units. Each part should work in somewhat of an isolation -- that is, the model doesn't care what the controller actually does so long as it actually provides the methods/functions that it's supposed to. Likewise, the controller doesn't care if the view is a GUI, text, or Morse Code. The controller only needs to know that the view will provide the necessary functions so that the controller can call them without things crashing.

To start off, get everyone together and brainstorm, map out what objects and classes and methods you'll need. It may sound a bit corny, but a 'whiteboard jam session' actually works (at least it did for me once). It's explained on this website for a class I took some time ago: http://www.cs.jhu.edu/~scott/oose/lectures/design.shtml. The idea is simply that with everyone putting up ideas together (good ideas and stupid ones too -- you need them all at first until you know where you're going with it), you'll hit on good things. And if you map them out properly (not perfect UML, but enough to make sure things work), you can see the potential problems before you start coding.

If people are hesistant, just declare that you guys should make Class X to do job Y and build from there. Once you have to start thinking of related classes and how they'll work together you'll see if class X doing job Y is really viable.