• 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
stitchs_login

Unity
Pong Project near completion; looking for Critique.

10 posts in this topic

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:[list]
[*]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.
[/list]

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
0

Share this post


Link to post
Share on other sites
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
0

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:
[CODE]
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;
}
}
}
[/CODE]

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

It would have been better to have some const int's like so:
[CODE]
enum Screen
{
Left = 0,
Right = 800,
Top = 0,
Bottom = 600
};
[/CODE]

Now look at your code:
[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;
}
}
}
[/CODE]

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
1

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
0

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

Share this post


Link to post
Share on other sites
[quote]
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.
[code]
enum Direction {
DirectionNone,
DirectionUp,
DirectionDown
// ...
};

// Later
Direction direction = DirectionUp;
[/code]
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:
[code]
namespace Direction {
enum Type {
None,
Up,
Down
// ...
};
}

// Later
Direction::Type direction = Direction::Up;
[/code]
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
1

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1354580327' post='5006851']
Some people prefer to place global enums inside a namespace instead:
[code]
namespace Direction {
enum Type {
None,
Up,
Down
// ...
};
}
[/quote]

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
0

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

Share this post


Link to post
Share on other sites
[quote]
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.

[quote]
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.

[quote]
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.

[quote]
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
1

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

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

  • Similar Content

    • By OPNeonGames
      Hey guys, posting my work in progress for Macho Cat here. 

      A very early prototype for Macho Cat. Everything is just placeholder for now
      What is Macho Cat?
      A silly little game where you scrub the macho cat with random objects found in trash and junkyard to please him
      Gameplay feature?
      -Cat scrubbin, lots of scrubbin
      -Unlock moar objects in junkyard 
      -Funny, silly and easy
      When will the game release?
      December 2017 (estimate)
      Interested to Beta test?
      opneongame@gmail.com
    • By Tset_Tsyung
      Hey all,

      As the heading says I'm trying to get my head around Goal Objective Action Planning AI.  However I'm having some issues reverse engineering Brent Owens code line-by-line (mainly around the recursive graph building of the GOAPPlanner).  I'm assuming that reverse engineering this is the best way to get a comprehensive understanding... thoughts?

      Does anyone know if an indepth explanation on this article (found here: https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai--cms-20793), or another article on this subject?

      I'd gladly post my specific questions here (on this post, even), but not too sure how much I'm allowed to reference other sites...

      Any pointers, help or comments would be greatly appreciated.

      Sincerely,

      Mike
    • By E-gore
      Hi all,
      This is our (xDBAGames) first game
      Called Iron Dome Legacy.
      It is a Missile Command clone. In this game you control the Israeli "Iron Dome" anti missile defence system.
      Features: 
      The player has limited amount of missiles. The Iron dome system is upgradable. The money is determined by the outcome of a level. The game is free. There are only rewarded ads. We tried to create a game that has some context to the daily life, but we are sure not trying to be political here.
      I hope you could try this game, and we will appreciate any comments.
      xDBAGames is a company of two programmers. That have no experience in the video game industry, but have a lot of passion for games.

    • By UNNYHOG
      Hello, Colleagues!
       
      We have been working on our newest Fantasy style Gesture based MOBA game for a long time and it's releasing on Steam on July 26. Meanwhile you can already try it out by downloading our launcher from the website.
       
      Any feedback is welcome here. Thank you.
       
      If you don't want to play, I would love to share with you our teaser : 
       
       
       
    • By Scouting Ninja
      So I am working on a mobile game.
      It uses slides for a story, the slides are very large. Each slide is almost 2048*2048; the max texture loading size I am using for the game.
       
      My problem is that Unity keeps each slide in the memory after it's loaded, even when it will show only once per game. This leads to the game crashing on older mobiles.
      My idea was to destroy each object after it was shown using a coroutine, so it deletes the past slide and loads the next slide. This worked because instead of crashing on 23 slides it crashed on 48 slides.
      After some profiling I realized that destroy() isn't clearing all the memory that a slide used.
       
      What I want to do now is assign a limited amount of memory as a slide slot. Then I need some way to unload the slide from the slot, freeing the slot for the next slide; without Unity storing the slides in the memory.
      Any ideas on how I would do this? 
  • Popular Now