• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
superman3275

What Do You Guys Think of How I Programmed This?

14 posts in this topic

I've been hard at work this week programming breakout again, but this time I'm putting heavy emphasis on programming using object oriented techniques. So, I am having my Block/Ball/Paddle class all handle their Variables, while I have a GameLogic class that handles all the logic(Collision Detection/Updating the other classes/Etc) and a GameDraw class which Draws all my objects(Just draws them to the screen). Then I have a MainGame class which has an instance of GameLogic and GameDraw, an instance of the other classes I need, and it's responsibility is to run the game. I spent a lot of time Pre-Visualizing how I was going to set up my classes, and what their responsibility's would be. This project abides by the single responsibility principle, and the Open-Closed principle(I hope, I really have a weak understanding of it).
Here's the link to the .zip fie containing my project:
http://www.mediafire.com/?r7l6hfxf8dh8c37 Edited by superman3275
0

Share this post


Link to post
Share on other sites
And I didn't link the code! FacePalm!
I'll have that up really soon!
Here's the link to the .zip file containing my project:
http://www.mediafire.com/?r7l6hfxf8dh8c37 Edited by superman3275
0

Share this post


Link to post
Share on other sites
First off, if you're going to share your code, don't include things like the contents of the Debug/ folder, the intellisense cache or other extraneous compiler generated files. Otherwise, there doesn't seem to be enough completed to comment on the overall design. There are a number of implementation details that seem non-kosher, however. From a quick glance through: you seem to have some vectors that you never resize, and it seems like you don't intend on resizing them. In that case you should consider using std::array instead of std::vector. Also you seem to use a lot of non-const references when you only need const references (e.g.: Block and Ball's constructors). You also have a number of functions that return copies of objects rather than references to objects. Ex: Block::GetImage() could probably be changed to returning a const reference. There also seems to be a quite a bit of redundant computation going on. For instance, why store ball position as a member variable if you can get it from the sprite object?

Also, GameMain has protected member variables. If a class has non-public variables that implies that the class has a class invariant. With private variables only the members of that class is responsible for maintaining the class invariants. However, if you have protected member variables then every derived class is also responsible for maintaining the class invariants. This is generally a lot more trouble than it's worth.
1

Share this post


Link to post
Share on other sites
What you said about GameMain I removed. For the redundant computation: Later on in my code, in GameLogic/GameDraw especially, I have some code that would be almost impossible to read unless I have those variables. They're to help my program make more sense later on. Also, GetImage() is never used, but that's a good idea. This is stuff I'll have to remember later on.
0

Share this post


Link to post
Share on other sites
[quote name='superman3275' timestamp='1350240383' post='4990110']
For the redundant computation: Later on in my code, in GameLogic/GameDraw especially, I have some code that would be almost impossible to read unless I have those variables.[/quote]
You can make functions with the same names that grabs the values as needed which will give you equivalent readability. See also [url=http://en.wikipedia.org/wiki/Don%27t_repeat_yourself]Don't Repeat Yourself (DRY)[/url].

[quote]Also, GetImage() is never used, but that's a good idea.[/quote]
You might want to get out of the habit of writing functions that are never used. See [url=http://en.wikipedia.org/wiki/You_ain't_gonna_need_it]You Aren't Going to Need It (YAGNI)[/url].
0

Share this post


Link to post
Share on other sites
GameLogic::CheckCollision() -- this if is freaking terrible. After 10 minutes reading I don't get it.
Why do you every time repeat this GetIsHit()? And also this freaking LogicBall->GetCollision().Intersects(LogicBoard[index]->GetTop())... It would be nice to refactore it to

[CODE]
void GameLogic::CheckCollision()
{
...
if (logic_ball->GetCollisionMgr()->Intersects(logic_board[index]) && LogicBoard[index]->GetIsHit() == false) {
...
logic_ball->UpdateVelocity(); // this func knows that GetCollisionMgr()->Intersects(...) have cached info about intersection and know how to apply velocity
}
...
[/CODE]

I hope I've gave you some ideas about how to improve your code.

And also I suggest you to use pointers instead of references. It's a little bit flexible. Edited by AlexB.hpp
0

Share this post


Link to post
Share on other sites
Your interface Manager idea is smart, and I might implement it later. Thank you for your input, just please be less harsh on people in the beginners section.
I dislike how you called my code "freaking terrible", I'm posting in the beginners section and your post made me get Effective C++, Code Complete, and C++ Primer Plus. Edited by superman3275
-4

Share this post


Link to post
Share on other sites
This code is officially dead, I'm going to try something simpler before attempting breakout again. My interface is awful (As the guy above pointed out), and I didn't plan my code at all. I'm going to try to become a better programmer by taking a smaller step, because I bit off more than I could chew.
0

Share this post


Link to post
Share on other sites
superman3275 You can use sites like [url="http://www.codeplex.com/"]http://www.codeplex.com/[/url] to post your code, it's much easier for us to access.

I didn't look over all the code, but AlexB.hpp it would appear he called the GetIsHit() each time so it doesn't check a block that has been hit? I would suggest once you hit a "block" you end the for loop. Does index refer to the 19 blocks you can hit? Sorry if I'm reading the code wrong.

Also, using references is perfectly fine! I personally prefer to pass by reference.

superman3275 don't be so hard on yourself, I learned how to program from trial and error. If it wasn't' for the thousands of times I had to reprogram the same code, I wouldn't even be able to program half the stuff I do today. I do however recommend working by setting small goals to reach your big goals. I'm doing this on my RPG project posted in my Journal, and it's coming along perfectly. Edited by Black-Rook
0

Share this post


Link to post
Share on other sites
That's smart! Black-Rook, the GetIsHit() function is exactly for that. IsHit makes it so that I don't draw blocks that have been hit and I don't check for collision on them either. I read a post about how you should set small goals and focus on getting stuff up on the screen to motivate yourself, and I think that sounds smart. As lazyfoo.net said, I'm entering the realm of pre visualization, where I have to actually think about my code before programming!?!?! It's unheard of. Thanks for your input :)
0

Share this post


Link to post
Share on other sites
I have a whiteboard, well a few whiteboards! I will often draw out what I want my code to do before I even write a line. You can do the same on a piece of paper as well, or even in MS Paint with a tablet, or mouse.

Also you should start to use these:

[CODE]//

/*
*/[/CODE]

Regardless of who reads your code, you need to make it a practice to comment code.

Example:

[CODE]// Add two values and return the sum
int Add(int a, int b)
{
return (a + b);
}[/CODE]

Note: /* */ is for multiple lines, example:
[CODE]
/*
This
is
all
comment code!
*/[/CODE]

So you don't have to use // each line.
0

Share this post


Link to post
Share on other sites
Hello superman. I have read your code, here is my opinion.

Why not implement GameLogic, MainGame, and GameMain as normal functions? Assuming you are only going to have only one instance of each.

There are some magic numbers lying around, like these:
[CODE]
Board.resize(20);
for (int index = 0; index < 20; ++index)
[/CODE]

What do those 20's mean? Do they mean the same thing? It would be good if you can assign them to constants, it will make life easier for you if you suddenly decide to change that number. It will also make the code easier to understand.

Also, more comments would be great, I think. Preferably a comment for every method/function and variable in the header file, and a comment for the very long expressions and statements. This will be help the people reading your code to understand them better, and also remind yourself what the functions/methods do if you forget in the future.

[quote name='superman3275' timestamp='1350266985' post='4990213']
This code is officially dead, I'm going to try something simpler before attempting breakout again. My interface is awful (As the guy above pointed out), and I didn't plan my code at all. I'm going to try to become a better programmer by taking a smaller step, because I bit off more than I could chew.
[/quote]

I think you should continue with it. It is good way to get better at coding, as good as reading tuts and taking lessons. Start from coding the small objects, like Ball, and make them as close to bugfree as possible. Then work your way up to the logics and graphics stuff. Edited by ultramailman
0

Share this post


Link to post
Share on other sites
[quote name='superman3275' timestamp='1350264118' post='4990203']
AlexB.hpp, considering your new to the forum I'm not going to get mad at you, but who are you to be talking like you're an expert in C++? It doesn't matter if pointers are more flexible then references, I don't need pointers and I don't plan to use their harder to understand syntax. Also, you should probably realize I AM USING A LIBRARY CALLED SFML AND OMG I'M USING BOUNDING BOX COLLISION. That's why I can't "refactor" my code, and that's probably why you don't understand this:
[quote]LogicBall->GetCollision().Intersects(LogicBoard[index]->GetTop())[/quote]
If you actually [b]used [/b]SFML you would know what was going on. You also just signed up for the forum, so I suggest you stop telling people in the [b]beginners [/b]
section that their code is:
[quote]this if is freaking terrible[/quote]

I'm in the beginners section, do you expect "your" quality code.(That's considering your an actual developer, which I doubt you are.)

I'm saying that if Collision(A bounding box rectangle) intersects one of my blocks I set that block to being hit. If you knew what you were talking about you might understand that.

BUT,

Your interface Manager idea is smart, and I might implement it later. Thank you for your input, just please be less harsh on people in the beginners section.
[/quote]

Sozz dude, looks like I was a little bit mean.

I'm not an expert but I'm trying to get some experience too. So that's why I wanna give you a little review.
Would you agree if guys will give you some feedbacks on your code to improve it. Your code looks really difficult to understand.

Did you just begin or not, it doesn't matter, 'cause you HAVE to write good code.

Let me tell what I call good code. Good code - when you send it to another programmer with enough skill, he can understand and modify it after few hours of reading.
Sooo that's why I said that that some part of your code freak me out. But ofc your code can be OK.

My suggestion - keep dev it, 'cause you've got nice feedback on it.
1

Share this post


Link to post
Share on other sites
[quote name='AlexB.hpp' timestamp='1350288760' post='4990305']
[quote name='superman3275' timestamp='1350264118' post='4990203']
AlexB.hpp, considering your new to the forum I'm not going to get mad at you, but who are you to be talking like you're an expert in C++? It doesn't matter if pointers are more flexible then references, I don't need pointers and I don't plan to use their harder to understand syntax. Also, you should probably realize I AM USING A LIBRARY CALLED SFML AND OMG I'M USING BOUNDING BOX COLLISION. That's why I can't "refactor" my code, and that's probably why you don't understand this:
[quote]LogicBall->GetCollision().Intersects(LogicBoard[index]->GetTop())[/quote]
If you actually [b]used [/b]SFML you would know what was going on. You also just signed up for the forum, so I suggest you stop telling people in the [b]beginners [/b]
section that their code is:
[quote]this if is freaking terrible[/quote]

I'm in the beginners section, do you expect "your" quality code.(That's considering your an actual developer, which I doubt you are.)

I'm saying that if Collision(A bounding box rectangle) intersects one of my blocks I set that block to being hit. If you knew what you were talking about you might understand that.

BUT,

Your interface Manager idea is smart, and I might implement it later. Thank you for your input, just please be less harsh on people in the beginners section.
[/quote]

Sozz dude, looks like I was a little bit mean.

I'm not an expert but I'm trying to get some experience too. So that's why I wanna give you a little review.
Would you agree if guys will give you some feedbacks on your code to improve it. Your code looks really difficult to understand.

Did you just begin or not, it doesn't matter, 'cause you HAVE to write good code.

Let me tell what I call good code. Good code - when you send it to another programmer with enough skill, he can understand and modify it after few hours of reading.
Sooo that's why I said that that some part of your code freak me out. But ofc your code can be OK.

My suggestion - keep dev it, 'cause you've got nice feedback on it.
[/quote]
I'm sorry, it was late at night when I made that post. I guess I was annoyed because of all the time I had invested, and when you criticized me that harshly I just felt like all my work was for nothing.
1

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  
Followers 0