Jump to content

  • Log In with Google      Sign In   
  • Create Account

Retro Grade

[Case] Breakout!

Posted by , in Case 30 November 2012 - - - - - - · 720 views

Wow, it's been a very long time since my last case study! Well now, I'm here to give you a great one: Breakout!

Let's start with the mechanics, as usual:
  • You control a single paddle that can move left and right.
  • There is a 2D array of blocks.
  • The Paddle is at the bottom of the screen, the blocks are at the top.
  • There is a ball that bounces off your paddle, the walls, and the blocks.
  • If the ball hits a block, it will destroy the block, making it disappear.
  • If the ball goes past the players paddle and hits the bottom of the screen, you lose the game.
It's pretty simple, however to help you, here's a picture:

Posted Image

So, this was extremely popular back in the day. What made it so popular?

Well, it was a single player game. At this time, Pong required two players and was very simple. This simply blew people away, and it didn't require someone else.

It also had interesting game-play. Pong was relatively simple compared to this, and this was far more addictive. Failing when you were only 1-3 blocks away was common, and kept people hooked. Newer versions of breakout (Such as Arkanoid, etc.) also had power-ups and more levels, making them even more addicting. Working your way up a steady stream of harder levels, and trying to get the next power-up, still remains fun and challenging. (If you want to try, I've attached DXBall, a newer version of breakout, for you to play :)!)

Polish

This game doesn't really need to be that "polished". The one "polish" aspect of it that I see being important is the GUI, however besides that, this game is fun even with bad sprites/collision detection (In this time period, of course. Back when it was an arcade game and it cost a quarter to play, having buggy collision detection would make no-one play it because you could randomly lose your quarter. Now, however, it's free and having slightly buggy collision detection isn't that big of a deal.)

Implementation

Implementation is very important. If the ball is moving too fast, you can't survive long enough to get rid of all the blocks. If there is too many / too little blocks, your player will get bored / feel ripped off. Level design isn't that important, considering you can really do whatever you want for level design and it still is generally fun to play. The actual core values of the game is important (Like the Paddle Speed, Ball Speed, Amount of Blocks, etc.) however many of the extra things (Power-ups, special blocks, etc.) are nice extras that really help tie it together, yet aren't needed if you can make sure your player is having fun without them.

Fin

Well, I hope you enjoyed it! Keep calm and sneak on Posted Image!

Attached Files




[Structure][C++11] The Auto Variable

Posted by , in Structure, C++11 30 November 2012 - - - - - - · 1,357 views

How many C++ programmers reading this know what an auto variable is. Come on, raise your hand. I count 1... 2... 3... Almost all of you!

However for those of you that don't know the basics of the new standard yet, auto is a new variable that works like this:


Code:

// Hooded.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
int _tmain(int argc, _TCHAR* argv[])
{
auto Compiler_Determines_This_Is_An_Int = 5;
auto Compiler_Determines_This_Is_An_String = "I Am A Auto-String";
auto Compiler_Determines_This_Is_A_Float = 3.14;
auto Compiler_Determines_This_Is_A_Char = 'C';
auto Compiler_Determines_This_Is_A_Boolean = true;
std::cout << Compiler_Determines_This_Is_An_Int << std::endl;
std::cout << Compiler_Determines_This_Is_An_String << std::endl;
std::cout << Compiler_Determines_This_Is_A_Float << std::endl;
std::cout << Compiler_Determines_This_Is_A_Char << std::endl;
std::cout << Compiler_Determines_This_Is_A_Boolean << std::endl;
system("pause");
return 0;
}
Output:
5
I Am A Auto-String
3.14
C
1
Press any key to continue . . .


I can't believe it! It's the equivalent of a "var" in other, newer programming languages! It's perfect!

So, what just happened? The compiler used the values I initialized the variables with too set their type. Essentially, an auto variable that's type can be determined by the compiler.


There are some rules, however:
  • Auto variables have to be initialized to a value when they're created.
  • Auto variables can't have their types changed after initialization.
There are many uses for this in advanced and generic programming, however I'm going to talk about it's use for the beginning C++ programmer.

First off, I believe that using this for generic programming is fine, as clarified by Aardvajk.

The problem arises when beginning programmers want to be lazy and use these for everything. That is bad programming practice, and a lazy work ethic. You should know the types of your variables in your program, and using the auto variable because you don't want to memorize the names of the basic types defeats the purpose.

Now, where can I see myself using this variable? When I don't know the type of a variable I'm receiving. This generally doesn't happen very often unless you're dealing with generic programming, in which using this value is perfectly fine.

I also believe auto variables could be very confusing. If someone defines all their variables as auto variables, than I'll have no idea what the type of each variable is. This is especially noticeable in classes with an auto variable in them. If the variable is initialized in the constructor of the class, then I'd have to hunt through your code to find the type. This can be overcome by leaving a comment telling me what type the auto variable is, however that seem to defeat the purpose.

I hope you enjoyed my (now corrected) blog post. Cheers Posted Image!