Software Design

I'm still writing stuff that is intended to teach programming. Great fun,but very hard work (apparently). I'm up to the bit where I'm trying to make a game more interesting.

..but how do you detect when all the red bricks have gone?

I am recreating a game I first made many years ago in Lucidata Pascal on a South West Technical Products 6809 based microcomputer.  It is a simple breakout clone with one or two interesting touches as you go through the game. Apparently it was responsible for a lot of lost time in the Psychology department at the time I wrote it, because they had the same computers and spent ages playing it. Chris used to spend entire lunch-hours on it, holding a ruler against the screen to line up really tricky shots....

Anyway, I digress. The place we've got to is where we have a row of blocks and a ball, and we can destroy the blocks with the ball. It gets a bit boring when all the blocks have gone, so our program must detect when the last block is removed. There are essentially two ways you can do this, you can keep a counter of blocks that are left and reduce it each time you remove a block, or you can look through the blocks and see if you can find any which are still visible. But which is better?

Keeping a counter has the virtue of simplicity and makes the smallest program. However it also adds a counter variable which is coupled with the array of blocks. If the counter and the array get out of step for any reason the program will misbehave. If the program checks the array each time there is no question of this happening. In other words one design leaves the system open to bugs that could not occur in the other. I'm trying to get people thinking about the craft of software development and into the habit of worrying about things like this when they write programs.

I often get asked "What is the best way to do this in software?" as if there is an solution which is perfect in every way. I tend to reply that there usually is no such thing a best solution, there will be a fast one, one which doesn't use much memory, one which has the shortest program code and so on. To that you can hopefully add "simplest" which is the one that I tend to go for, unless I'm really worried about performance.

Comments

[JDog]

Apologies for the long post.

Well, I know its not what you asked, but to make it more interesting make some bricks drop power-ups ! so they widen your bat, or maybe time slow down and maybe multiple balls ! Or things which affect background details like fading colour effects or the entire game goes into negatives, HUD and all.

Oh, I dropped off my code in the drop box over at VerySillyGames.com. I've also installed c# 2005 and XNA 2.0 and am still having the same problems. If I can get over this (what i'm hoping to be) technical hitch I can program smoothly as the syntax when your used to it is easy to remember.

Oh yeah, my Heavy Weapon game is now in a fully playable state, but pretty borng with only one enemy (I know how to add more but i'm starting first optimization).

[Phil Cluff]

Right, Well, I suppose that you could do a combination of the two... ish.

So, you could have the game check once a second or so (Assuming there's a timer involved), that the number of blocks in the tracker variable == the blocks left active in the array.

This would be really easy in Perl... You could delete elements off the array as they got hit, and just cast the array to a scalar value for it's length... Shame you can't do that in C#... Well, you can, just using Dynamic Arrays... Is that getting too advanced?

Phil.

[Shawn]

You know, I like the idea of simplest, but why is it that when I go for something simple, I often over complicate it....:-]

[[ICR]]

Perhaps I'm being blind, but how likely is it that the counter would become out of step with the blocks?

[Caleb]

What I would do is make a wrapper for the brick's array. The bricks would require a link to the wrapper array when they were created. The array wrapper would have a count of alive bricks and setting the alive property of a brick would either increment or decrement the alive brick count.
It shouldn’t take very long at all to write the wrapper code and it could have the added bonus of encapsulating the code that fills the array with bricks in the first place which would keep your LoadContent method simpler (maybe).

[Rob]

I'm feeling kind of guilty now. There is actually a very good reason why you would want to decouple the array and the "number of bricks left" counter. This is when you are testing. If I want to be able to quickly remove a level without having to destroy every brick it makes sense to set the "bricks left"value to 3 so that I only have to get rid of three bricks to test the level end behaviour.

[Arthur Embleton]

"If I want to be able to quickly remove a level without having to destroy every brick it makes sense to set the "bricks left"value to 3 so that I only have to get rid of three bricks to test the level end behaviour."

Couldn't you store the bricks as objects in a list. Each brick can store its properties, such as colour, size position etc. And then, if you want to see how many remaining bricks you have; you simply count the list. If you want to reduce the number of bricks in a level you just change the number when they get created. Heck, that could and probably should be read in from a properties file.

This will teach object orientated design principles and makes alterations further down the line (different coloured bricks within the same level) a lot easier to do.

[Rob]

Not a bad plan. I did originally just make a level that just contained three enormous bricks, so that I could test more easily. Thing is, it doesn't look as nice, and you might want to progress through the game so that you can get some screenshots.

And yes, the final system that I came up with is pretty much as you described. You can find out the way I like to travel in these situations by looking here:

http://msdn.microsoft.com/en-us/library/aa446569.aspx