• Advertisement
Sign in to follow this  

Unity Pong Project near completion; looking for Critique.

This topic is 1865 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello community,

I have completed a small Pong project, I am quite happy with it and am looking towards the community now that I am at a point to share it. At some points it got me down, as this was my first outing with SFML and there are some aspects that I definitely need to understand better (such as the ordering of event queues and key-presses), but I am happy that i persevered.

I wasn't sure where to put this, it is kind of an announcement, but I am also looking for a code critique and some feedback. Basically, I have gone back to basics and am trying to code a game as quickly as possible, with as few mistakes as possible, but they definitely exists. Currently I am aware that the Paddle and Ball classes share some methods, and this will lead me to developing an inheritance structure, this is one of the known issues and an example of what I am aware of in my code.

I am trying to find as many shortfalls and understand why some concepts shine, through the experience of not using them.

A few things I am aware of:

  • Hard-coded values,
  • Movement that jutters at times.
  • Over-diluted with methods that could be combined.
  • Unclear comments in some places.
  • A few methods that are not used or have no body.


    I appreciate any feedback on my code and the application itself, and look forward to your comments. Below you will find two rar files attached, one with the exe and one with the Header/CPP files.

    Regards,

    Stitchs. Edited by stitchs

Share this post


Link to post
Share on other sites
Advertisement
Hey Stitchs,

The executable complains about MSVCP100.dll not being present, you might as well want to include that.
Furtermore, I took a quick look at your code, and it seems okay to me. I don't know how much experience you have in C++, but I think this program is written with a good sence of object orientation. One thing though, why do you save the score in the bat, and not in the arena?

Aart

Share this post


Link to post
Share on other sites
One problem I see is that, probably because of hard coded values, what's happening is that no matter what angle the ball hits the player controlled paddle from, the ball always goes towards the bottom of the screen. This can be easily fixed by changing some values however, so it's not that big of a deal :).

Also, before you continue reading, realize I also finished Pong with SFML in C++ only about a month ago.

Another problem in your code is over-commenting. Holy crap, you're probably getting half of what you should be getting done finished because you're commenting obvious things. And if you're having to write comments for obvious things, it's bad code. An example would be this code in your Paddle.cpp:

void Paddle::SetPositionY(float yPosIn, float elapsedTime)
{
if(position_.y < (yPosIn - 10))
{
// prevents paddle going off screen
if(getArea().Bottom < 800)
{
position_.y += speed_ * elapsedTime;
}
}
else if(position_.y > (yPosIn + 10))
{
if(getArea().Top > 0)
{
position_.y -= speed_ * elapsedTime;
}
}
}


This is hard to understand, even though you have that comment.

It would have been better to have some const int's like so:

enum Screen
{
Left = 0,
Right = 800,
Top = 0,
Bottom = 600
};


Now look at your code:

void Paddle::SetPositionY(float yPosIn, float elapsedTime)
{
if(position_.y < (yPosIn - 10))
{
// prevents paddle going off screen
if(getArea().Bottom < Screen.Right)
{
position_.y += speed_ * elapsedTime;
}
}
else if(position_.y > (yPosIn + 10))
{
if(getArea().Top > Screen.Left)
{
position_.y -= speed_ * elapsedTime;
}
}
}


Not to mention all the other variables with other names. If you corrected those, then it'd be way, way, way easier to understand. Also, what's with the _ after the name of everything? Edited by superman3275

Share this post


Link to post
Share on other sites
Instead of using if-else chain to manage states, you could have used a nice polymorphism.
[source lang="cpp"]while(running)
{
currentState->update();
currentState->draw();
//change what currentState points to when necessary
}[/source] Edited by lride

Share this post


Link to post
Share on other sites
Thank you all for your responses, I am not currently at my home computer and will make a fuller reply tomorrow, when I have had a chance to compare the notes with my code. Two things I picked up on from Superman and rip-off; the trailing '_' after variables and using 'k' in Enumerated types is something I have been following from the Google Style guide on C++. I wanted to find a way of making my code consistent. If it seems wrong, then I will look into changing that for my next project.

I only pick this out because it is the one I can answer off the top of my head.

Thanks again and I will reply in full tomorrow,

Stitchs.

Share this post


Link to post
Share on other sites

Two things I picked up on from Superman and rip-off; the trailing '_' after variables and using 'k' in Enumerated types is something I have been following from the Google Style guide on C++. I wanted to find a way of making my code consistent. If it seems wrong, then I will look into changing that for my next project.
[/quote]
These are stylistic things, so they aren't "wrong" necessarily. I use the trailing underscores myself in some projects. The "k" prefix is one I haven't seen. But if you think it makes sense for you, that is OK.

Given that C++ places the enum names in the enclosing scope, I prefer to prefix the enum names with some "tag" that groups them, e.g.

enum Direction {
DirectionNone,
DirectionUp,
DirectionDown
// ...
};

// Later
Direction direction = DirectionUp;

Some might find duplicating the name of the enumeration like this distasteful, and I can't say they are wrong.

Some people prefer to place global enums inside a namespace instead:

namespace Direction {
enum Type {
None,
Up,
Down
// ...
};
}

// Later
Direction::Type direction = Direction::Up;

However IMO now your declaration syntax starts getting quite funky.

There isn't a definitive answer, but it is good to think about these things and not just blindly applying them. Edited by rip-off

Share this post


Link to post
Share on other sites

Some people prefer to place global enums inside a namespace instead:

namespace Direction {
enum Type {
None,
Up,
Down
// ...
};
}


With C++11
you can just use
[source lang="cpp"]enum class Direction: unsigned char //You can even specify underlying data type
{
None,
Up,
Down
};
[/source]

Note this doesn't allow implicit type conversion
[source lang="cpp"]int direction=Direction::None;//Error
Direction direction=Direction::None//Ok[/source] Edited by lride

Share this post


Link to post
Share on other sites
I know this reply comes late, I do hope that it is still a valid to post in topic.

I am currently changing the code to match the suggestions made here. I have one question: would a method named 'OnPaddleCollision' be of type Bool or type Void, I can't differentiate between the two. I would of gone with bool, but what I have written in the method does not need to return true or false for the arena to reference, which makes me want to use Void as its' type.

Or, to go against my usual thought train, would I: check for a collision with the paddle/ball in the arena and, if one occurs, call the void Ball::OnPaddleCollision(). Saying it like this seems to make slightly more sense, I guess I just need some outside input to help concrete this in my head.

Thanks and I look forward to your replies,

Regards,

Stitchs.

Share this post


Link to post
Share on other sites

I know this reply comes late, I do hope that it is still a valid to post in topic.
[/quote]
It is perfectly fine. If the thread had started to be a few months old, maybe. There is no hard rule, just common sense AFAIK. Additional leeway would probably be given in this instance as this thread is very specific to your project, as opposed to another member bumping this to ask a follow up question.


I am currently changing the code to match the suggestions made here.
[/quote]
Great! When you're happy with it, you can post it here again for further feedback.


would a method named 'OnPaddleCollision' be of type Bool or type Void
[/quote]
I don't believe there is any sensible meaning to the return value of OnPaddleCollision, thus I would use the "void" version. I'd recommend against including return types when the result is irrelevant to the caller.


would I: check for a collision with the paddle/ball in the arena and, if one occurs, call the void Ball::OnPaddleCollision()
[/quote]
Yes. Edited by rip-off

Share this post


Link to post
Share on other sites
@rip-off:

So, as I said, I am using your notes to improve my game and I implemented Ball::OnPaddleCollision. Then it came to Paddle::OnPoint and I suddenly had a bit of a mind-blank. I was trying to figure out "what does this method need to handle apart from increasing the score by 1?"

I had a brainwave and I wanted to check with you to ensure that I have this right, in my head. I was trying to figure whether the paddle should reset itself on a point, or the Arena. It took me about 15 minutes and then I realised, "If I have a paddle handle it's own reset on a point score, what about the other paddle, and the ball position?". This is definitely something that the Arena needs to handle. To cement what I had just learned, I looked back to the Ball collision method and thought, "Well, when is it appropriate for the Object or the Arena to handle certain functions" such as the balls' direction changing. I imagined having 2 or more balls in play, and this is when it clicked. I realised that if the Arena handled all of these methods (reverse speed, increase speed...) then it will become very messy and confused, because with 2 balls or more, each of these methods need to be repeated. Inevitably, this will make it harder to trace bugs.

To summarise, am I on the correct train of thought? If I am, do I need to try to imagine scenario's like this, to try and make sense of what could happen and how easy it would be if someone using my code wanted to achieve these effects?

Regards,

Stitchs.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By RoKabium Games
      Another one of our new UI for #screenshotsaturday. This is the inventory screen for showing what animal fossils you have collected so far. #gamedev #indiedev #sama
    • By eldwin11929
      We're looking for programmers for our project.
      Our project is being made in Unity
      Requirements:
      -Skills in Unity
      -C#
      -Javascript
      -Node.js
      We're looking for programmers who can perform a variety of functions on our project.
      Project is a top-down hack-and-slash pvp dungeon-crawler like game. Game is entirely multiplayer based, using randomized dungeons, and a unique combat system with emphasis on gameplay.
      We have a GDD to work off of, and a Lead Programmer you would work under.
      Assignments may include:
      -Creating new scripts of varying degrees specific to the project (mostly server-side, but sometimes client-side)
      -Assembling already created monsters/characters with existing or non-existing code.
      -Creating VFX
      -Assembling already created environment models
      If interested, please contact: eldwin11929@yahoo.com
      This project is unpaid, but with royalties.
       
      ---
      Additional Project Info:
      Summary:
      Bassetune Reapers is a Player-verus-Player, competitive dungeon crawler. This basically takes on aspects of dungeon crawling, but with a more aggressive setting. Players will have the option to play as the "dungeon-crawlers" (called the 'Knights', or "Knight Class", in-game) or as the "dungeon" itself (literally called the 'Bosses', or "Boss Class", in-game). What this means is that players can choose to play as the people invading the dungeon, or as the dungeon-holders themselves.
      Key Features:
      -Intense, fast-paced combat
      -Multiple skills, weapons, and ways to play the game
      -Tons of different Bosses, Minibosses, creatures and traps to utilize throughout the dungeon
      -Multiple unique environments
      -Interesting, detailed lore behind both the game and world
      -Intricate RPG system
      -Ladder and ranking system
      -Lots of customization for both classes s of customization for both classes
    • By RoKabium Games
      Custom coffee mugs have arrived... More caffeine!
      Have a great weekend everyone! 
      #gamedev #indiedev #sama #caffeine
    • By Atwo Studios
       
      Hey guys,

      Anthony here from Atwo Studios bringing you some new updates for the new year!
      In this video I go over our game ROY, the new games and some general updates to the company!

      If you have not checked out ROY feel free to give it a try! Many people have said they enjoyed the game thus far!
      ROY: https://goo.gl/o6JJ5P
       
    • By Affgoo
      https://play.google.com/store/apps/details?id=com.NE.Alien
      still a lot of work to do, but its pretty stable  please let me know what you think <3
      Atlas Sentry is a game of destroy everything. Using your turret, simply swivel and shoot your way to victory, upgrading your weapons to unleash destruction on the variety of spaceships. The bigger your combo’s the more score you get! Earn silver as you play and then purchase new weapons and abilities to better deal with your enemy. Different enemies use different tactics and weapons, work out your own priorities in their destruction order. 

      Features: 
      **2 different game modes 
      **A level select mode with 20 difficult levels including a final boss, can you defeat it? **Arcade mode of endless destruction, how long will you last? 
      **High scores to compete against others, see who can take the top spot. 
       
  • Advertisement