Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 06 Sep 2007
Offline Last Active Mar 23 2014 11:51 AM

Posts I've Made

In Topic: Name of a particular property

25 June 2013 - 04:35 PM

How does the documentation for std::cin describe it?

In Topic: Handling interaction/collision response between multiple "GameObjects...

18 June 2013 - 02:14 PM

First of all if you know you have to know what type each gameobject is... why manage them as just one type? I feel it makes things overly complicated especially when the majority of those objects are very different from one another.

I'd use the advice already given and have your objects store a collision object that can be registered with your physics system. Collision shouldn't care about anything but the physical part of your object not its type. Your collisionnobject can store the info on what objects it collided with. Then later you can update each object and apply the collision rezponse based on the stored collisionninformation.

As for special cases such as a bullet hitting the enemy. When you iterate over your enemies you know they will respond to being hit by bullets so would check the objects that it collided with if they are bullets.

In my current project I handle such responses by including a flag for friendly or enemy... and a damage value. If an object such as the player collides with another object i first check if the objects are on the same side or jot. I.e. are they both friendly. If so I just leave it to the physics to respond. If not I check if either have a damage value above 0 and apply that to the given object.

Interactable objects all derive from a base object to facilitate this but are stored seperately for easier and faster management. I.e. I know when I'm updating a bullet cause I'm updating the bullet container. No need to check types.

In Topic: How can I avoid circular dependency?

31 May 2013 - 02:45 PM

Why not have the other class return the data it wants to send to the socket. Then your protocol class can do its job and send it to the socket without the other class know how its being sent?

In Topic: Is it time to move on to c++?

17 March 2013 - 06:39 PM

No need to bash python.... op ask your self. Do I want to learn c++¿ if the answer is yes. Than by all means do so else.... well I think you catch my drift. Do what you want to do.

Also don't blame your hardware before you got proof.... you more than likely have a bug in your code causing it to freeze. Take time to fix it and learn from it.... things don't get easier just by jumpi g to another language.

In Topic: Are Certain Constants Really Necessary ?

17 March 2013 - 06:30 PM

Servants example is the biggest reason I use such constants. I will also do this a lot for variables I know later ill be loading from a config file... but in the need to get things tested asap ill use constants then later remove the constant and make it a member variable once i got the settings-loading code in place. This assumes it won't be used anywhere but the given file.

More of a place holder in bigger projects. In smaller projects I do it to keep all those variables I know ill have to tweak over and over again in one clean place.... so as servant said I don't have to hunt for them.

Edit... derp servant I didn't read your whole post.... atleast I'm your new fan boy ;)