Automatic class inter-relation

Started by
1 comment, last by Zahlman 12 years, 6 months ago
Hi guys... long time reader first time poster. Please be gentle.

I avidly create games in VB.net. Being a hobby programmer I give my games away for free. Since I'm a hobbiest without formal training I do try and educate myself on proper programming principles and follow them when programming such as OOP. There are however some things I have obviously missed being self-taught that perhaps I would know if I were formally educated.

Once such issue that has really been my bane is how different classes (from now on referred to as objects) 'know' about each other WITHOUT programming specific interaction (stay with me here... please...)

Okay imagine this, you have a space game and the following objects

clsShip
clsMissile
clsAsteroid
clsSpaceJunk

Now each one of these objects has a Health, X,Y and Z private members and properties that are all inherited from clsSpaceEntity for argument sake. Now one way of programming collision between them would be to code out the following logic in the main game loop

for each ship in a list of ships
check each clsMissile in a list to see if it collides with it and if so, reduce health
check each clsAsteroidin a list to see if it collides with it and if so, reduce health
check each clsSpaceJunka list to see if it collides with it and if so, reduce health
... and so on and so on for every object
next

ect ect ect...

Now this might seam okay if your talking about the simple example above but some of my games have tens or even HUNDREDS of objects that interact in this basic way.

Now my question to the experienced programmers out there.

Is there a way in OOP to do the following...

for each thing that inherits from clsSpaceEntity
check against every other object that inherits this type (except itself) and if they collide then reduce health
next

?


This sort of ability for a type of objects/class or whatever to be 'aware' of another and how they are the same/different and interact would save me tonnes and tonnes and TONNES of coding.



Any assistance/help or feedback on this would be very appreciated. Thank you for your time, sorry for the long read.
Advertisement
You have not many options but to check all the collision between all [color=#1C2837]

clsSpaceEntity. You don't have to do another check for ship or anything as they all are checked being a Space entity. Physic engine usually reduce the test needed by creating collision spaces, so the obeject belonging to a given space are test but not tested with the objects of the other space. When to space intersec then they become one space.
[color=#1C2837]



[color=#1C2837]

Help it can gives you some hint on how to continue.


how different classes (from now on referred to as objects)


Please don't do this. Keeping your terminology straight is very important. The class is a blueprint, and the object is a thing created from that blueprint.

Do not confuse the map for the terrain.

Now this might seam okay if your talking about the simple example above but some of my games have tens or even HUNDREDS of objects that interact in this basic way.[/quote]

In the context of anything programmed in the year 2011, that doesn't have to run on a toaster, "HUNDREDS" is a mind-bogglingly tiny number. Don't worry about it.

Is there a way in OOP to do the following...[/quote]

"In OOP" isn't even really relevant to the question.

check against every other object that inherits this type (except itself) and if they collide then reduce health[/quote]

It sounds like what you're really trying to ask is "can I somehow get the class itself to tell me about every instance that was ever created?"

The answer is no, no languages I can think of keep track of that for you by default. And it's not what you really want anyway; objects can "die" or become "inactive" (or be needed for some special purpose, and not qualify for inclusion in your collision-detection loop or whatever) without ceasing to exist.

Create a container of the instances you want to check, and update it to contain the instances you care about.

This sort of ability for a type of objects/class or whatever to be 'aware' of another and how they are the same/different and interact would save me tonnes and tonnes and TONNES of coding.[/quote]

No, it won't. Source: I've written games, and the part of the code that assembles lists of instances of stuff is not anywhere near tons of coding. (Hint: you can iterate through an explicitly created container with the same kind of loop that you're describing for iterating through the magical implicit one. Putting things in the container is as simple as adding the single statement to do so after creating an object. Actually, not even that: you can generally write something like my_container.add(Something(params, ...)). )

It also doesn't consist of "awareness of each other". You pass one object as a parameter to a method of another object. This process is not contingent on the assumption that either object will even exist immediately following the call, let alone that the two objects will ever interact in the same way again.

This topic is closed to new replies.

Advertisement