Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 09 Apr 2013
Offline Last Active Jul 21 2014 07:13 AM

Posts I've Made

In Topic: c++ function pointers

09 July 2014 - 11:20 AM

I must prefer functors. Don't have to deal with any extra weird syntax. Plus, they can store data.

In Topic: Game Heirarchy

24 February 2014 - 12:16 AM

I would create a header file with a namespace like Tools or something. Inside this namespace I would have the collision functions.

I would also have another set of headers that define the collidable types, IE AABB, a circle, etc. I would have these have NO default constructor to force their initialization upon instantiation. I would also have as much data possible in the collidable type be pointers to the relevant data. For example, an AABB would have pointers for the position that point to the position of the entity it is for. Then if possible have the width and height be pointers as well, but they would probably just be non-pointers. I would define a function for each type of collision possible. For example, I would have three functions, one for AABB vs AABB, one for Circle for Circle, and one for Circle vs AABB. They would all be overloads of HasCollided (or in your case, isCollided). Then when I run collision detection, I just take the collidable data from each object and the correct function will be ran. It would require minimal code at the front end of it, just a simple function call. The collidable data should also not be inherited but be part of the regular data for the object. By having as much as possible in the collideable data be pointers, they will automatically have the current values without needing to be updated manually.

You could end up with a lot of collision functions to define and that can be alliviated somewhat by more involved programming, but this I think is the simplest way to do it and it is quite effective.

For handling collisions, this could be another piece of collision data, which I would also have separate from the collision detection data. Then you would have the same function overload process for how to handle all the different collision types.

With this you would call HasCollided( a.GetCollisionDetectionData(), b.GetCollisionDetectionData() );

and if that is true then run HandleCollision( a.GetCollisionData(), b.GetCollisionData() );

I apologize in advance if this doesn't make any sense and I sound like I'm rambling. One too many beers and it's bedtime as well lol.

In Topic: Game Heirarchy

22 February 2014 - 10:48 PM

Hey this is my first time posting on the forums but I've used this site as a resource before. Anyways I'm in the process of creating a small game. Here is my dilemma however... I'm not entirely sure how the different classes should interact with each other.


For example, lets say that I have a Player, Wall, and Collision Class. Here are my questions:

  • What classes should know of eachother?
  • How should the classes interact?
  • Should, for example, Player be able to call a function from Collision to determine if it's colliding with Wall? Or should Collision keep an updated copy of Wall's and Player's coordinates to determine if a collision is occuring?


Thank you in advance for any help.


Ideally, a class knows nothing of another class. Two classes should interact via an interface class or some other means. Instead of having the player call a function from collision to determine if it is colliding with the wall, have a function that takes the player and the wall as arguments to determine if the player is colliding with the wall (and expand this for all the things that can collide). This way, player doesn't need to know anything about collisions or walls, player just needs to know about player and wall just needs to know about wall.

In Topic: Why C++?

16 February 2014 - 08:13 PM

In Topic: how to prevent save cheating? (for games where saving is NOT allowed)

07 February 2014 - 10:01 AM

No modding support will be in my games.

Isn't modding cheating? I read that users have no right to mod a game except the game devs add support for it.


You are correct that users have no right to mod a game, they also have no right to not mod a game. They can either do it or they cannot do it. They couldn't sell it or distribute it legally without permission from the copywright holders of the software that they based their mod on (as far as I understand). This does not stop them from doing it for themselves.

Modding could possibly be in the form of creating/performing a cheat. In the context of the discussion, it is cheating. What I am saying is that in a strictly single player game, where what one player does in their game has NO bearing whatsoever on a player playing their copy of the game, cheating is irrelevant and you are wasting your time trying to prevent it. The only one you are satisfying with your attempts to prevent cheating is yourself.


The idea of creating a game is to make something that someone will have fun with. I fail to see the problem of players altering a game so that they enjoy it more is a bad thing, and such alterations have zero affect on the other players of said game. I see it as a good thing. Are they altering the experience I planned for them? Yes. Is this bad? No.


You are trying to give a ball to a group of kids so they can play basketball, but get upset when they decide to kick it around and play soccer instead so you run out and say "No! You must play the game I want you to play, basketball!". I give them a ball with the intent for them to play basketball, and when they start playing soccer I would be estatic because they are having fun with something I gave them.

My point with all this is to save you time by having you not worry about something in your design I think you should not worry about and to help you create a game that will be more fun for people. I think you have placed your game/idea on a pedestal and think it a kind of personal insult to yourself and your creative idea for anyone to not interact with it in the way you want them to.