Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Mar 2013
Offline Last Active Feb 06 2016 07:18 PM

Posts I've Made

In Topic: SFML 2.1 OOP Code Review

09 January 2014 - 08:46 AM

Most issues that I see have to do with code organization.

  • `using namespace` in non-local scope is a shooting offense. You put it in a HEADER. Code police is on its way. Please assume the position.
  • Global variables are a no-no. I could understand global `Objects` but global iterators? Whoa...
  • Whenever possible, prefer range-for to iterators when working with std containers. It makes for a much cleaner code and you don't have to keep coming up with a name for each iterator. ;)
  • `auto` is your new best friend. Use it wherever possible.
  • Consider encapsulating each logical part of the update loop in a "system". A function, f.ex. `doDeadCulling(std::list<GameObject>& objects)` would do the trick.
  • Two-phase initialization is not necessary in your case. Have your `Player` and `Enemy` call `GameObjects` constructor with appropriate parameters as the first statement in their respective constructors.
  • Base class destructors must be marked virtual, else nasal demons. This applies to every class that will be inherited from. Not just the class at the root of hierarchy. In your case, `GameObjects`'s destructor is in error.
  • Your `GameObject` is responsible for way too much. There are two possible ways to deal with this. Classic way would be to split it into various abstract base classes, f.ex. `Drawable` and `Collidable`, and have your `Player` and `Enemy` multiply-inherit from those. Modern approach would be to use a Entity Component System (ECS). It has many advantages over the classic aproach. Your favorite search engine should give you a couple of good hits.
  • You lose a game vs. your pants are loose. ph34r.png

I'm happy to expand on these points if you have questions.

Thank you so much!

ive copied your post to my ToDo list and will start working on them later today.

In Topic: Help with multiple shapes/sprites (SFML)

24 November 2013 - 07:33 PM



Hi, ive been able to draw as many shapes as i desire using a vector, the problem is im unsure of how to interact with them individually.



To answer this directly. You have a couple of options. You can interact with each RectangleShape within the vector by doing what you are doing in the bricks loop:

vector<sf::RectangleShape> bricks(10, sf::RectangleShape(Square));


Alternatively you can host a vector of pointers to RectangleShapes

vector<sf::RectangleShape*> bricks;

RectangleShape some_shape = sf::RectangleShape();


some_shape.setPosition(40, 40); // now bricks[0].position == (40, 40)

To address your code example explicitly, I don't think storing a bunch of drawables in a "bricks" array in this case, or many cases, is necessary. For instance, it may be better to maintain some sort of Player object or Enemy object that stores an sf::IntRect or something similar. With that IntRect you can use the intersects() method to more easily detect collision, or in the case you mention, you can detect when  enemy.collision_rect.intersects(screen_bounds), or conversely, when it does not. This way you can have a vector filled with enemies, or entities and loop through and update their screen positions.

// Say an Enemy object has the members
class Enemy
    void update(); // updates position and updates bounds based on that
    sf::IntRect bounds;
    sf::Vector2f position;

// Elsewhere you can maintain some list of enemies

std::vector<Enemy> enemies;

// add enemies



// Iterate through them and update their position and bounds

for(std::vector<Enemy>::iterator itr=enemies.begin(); itr!=enemies.end(); itr++)
    itr->update(); // move each enemy 
    if(!itr->bounds.intersects(screen_bounds)) // check if off screen
        itr = enemies.erase(itr);              // if so, delete

// Then you can check the size of enemies and add new ones if needed

if(enemies.size != 5)
    // add new enemies

// Finally draw rects by translating one rectangle to the enemies positions
sf::RectangleShape draw_me;
for(auto& e : enemies)

I'm not sure I hit all the points in your post, but I tried to hit a few here! Let me know if any of this helps.


Within the code example I purposely used two other ways of iterating through a vector(since you already showed your knowledge of stepping through based on the vector.size()). 


WOW! Thanks a bunch!

I'm gonna mess around with this for a bit now

In Topic: Hours per week

21 November 2013 - 06:16 PM

I'm just interested in hearing how much time people put into their game development. If you like, please respond with an average weekly total in hours, and what's your level of experience. (Are you hobby programmer only, or professional as well? Is this your first or second game, or have you completed 10 games?)

I'm a novice game programmer, and have only been coding for about a year (C++), so most my time is still spent learning how to do things. but on average i spend at least 6 hours a day coding, but fairly often i get into a groove and will end up spending 12+ hours coding. id say i spend between 40-70 hours a week coding.


im doing this to become a "Professional" game developer/programmer.


ive completed a handful of dinky games, and recently have been cloning classic games, starting from pong (of course! :) )

In Topic: C++ SFML Code Review

13 November 2013 - 07:26 AM

there are lots of things to take atention :

interesting int to string conversation smile.png there is functions for that,

several game loops with duplicating code,

all code that makes different things could be moved to functions draw initialize mousehandling and etc,

som drawing objects are initializing every loop - initialize them before main loop, 

magic numbers,

instead of switch with cases 0 1 2 3...   posible better to use array[]

maybe start using vectors sfVector2d  or similar


Thanks! put your post in my ToDo file and will get working on it! :)

In Topic: C++ SFML Code Review

13 November 2013 - 05:53 AM

I don't like the switch or Alvaro's code ;)


The switch is better behaved since it wont do anything if passed a value not in the range 0 to 4. I'd put in a default case that asserts or something though. All switch statements should have a default case!


Alvaro's code doesn't do any range checking at all sad.png

You're right about the default case, i should of put those in. thinking back on it i decided not too because i didn't think it through fully. but now i will add them so i wont have to independently choose a variable outside of the function to give it a default value. its ok that he didn't do range checking, i do that already in my code and would of implemented it when needed.