Sign in to follow this  
Frequency

Question about code structuring/design

Recommended Posts

Frequency    442
'lo devvers, This is my first game with a characterer and multiple static objects and AI-controlled enemies. Right now since I'm very early in development all I have is my player class written and my game loop calls Player->Update() (which internally checks keyboard input and moves itself around, sort-of animates, etc. No parameters yet) and Player->Display(). I draw the background too. So I guess what I'm saying is that the design is pretty open right now. Right now I'm contemplating how I will manage interactions - collisions, damaging other entities, picking them up - between the many entities. I'll just look at this from the viewpoint of getting the Player to update properly for simplicity: What is the best way to do this? The only thing I have in mind so far is passing a reference to a vector full of all the enemies, a vector full of all the movement-blocking objects, a vector full of all the med-kits (or whatever...), etc. This seems like it would most certainly work but would be quote unquote "ugly". Player->Update(vector <Monster> &MonsterVector, vector <Pillar> &PillarVector, ...) If there is no better way to do this, is this all there is to the system? If there is a better way, what is it? Many thanks.

Share this post


Link to post
Share on other sites
Heewa    140
One way to do it is to have a collision manager of sorts. That would hold lists of everything collidable. You'd ask it if you're colliding with anything (something like collisionManager.colliding( entity ) where entity is the thing you want to check) and it'd notify you (and possibly the thing you're colliding with) in some way (like calling a collidedWith( Entity* e ) function or something).

If it also returned true if a collision happened and false if none, then you could use it to determine whether you can move somewhere or not. You could loop through everything trying to move, and call that function and if it returns true, roll back to the old position.

Share this post


Link to post
Share on other sites
Troll    246
I have a question. Everybody talks about making managers for everything these days. What benefit does a collision manager provide over just a free-standing function? I'm not trying to say there is no benefit. I've just never thought about it, so I don't presently see any advantage.

Share this post


Link to post
Share on other sites
RobAU78    206
Here are some advantages, as far as I can see:

1. It keeps the code cleaner and therefore easier to understand.

2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).

3. Per #2, it allows the game to run faster. :)

- Rob

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by RobAU78
Here are some advantages, as far as I can see:

1. It keeps the code cleaner and therefore easier to understand.

2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).

3. Per #2, it allows the game to run faster. :)

- Rob


You can do that without a manager though, so per Troll's question
whats the advantage - what can be done that wasn't possible before?

Share this post


Link to post
Share on other sites
RobAU78    206
Hmm... nothing, I suppose, but there is still the issue of code conciseness. The idea is to keep things clean and as easy to understand as possible. Doing so will make it easier to change the code later.

- Rob

Share this post


Link to post
Share on other sites
Aeneas    100
The major advantages that I see on this topic are those here:

1: It makes the code EASIER to read

2: The code will be Object Oriented

3:As of 2, Object Oriented Programming allows for more reusable code later, rather then if you just throw it all into a function and make it for this specific code source....


As I see, Its a ton better to make it reusable later, :-D

Share this post


Link to post
Share on other sites
Troll    246
Quote:
Original post by RobAU78
1. It keeps the code cleaner and therefore easier to understand.


I agree that clean code is, all else being equal, easier to understand, but how is the code cleaner when you have a manager? Just having the infrastructure around for a separate management class is going to add code, which all else being equal, will result in more code for the same functionality, which would tend to obscure things.


Quote:
Original post by RobAU78
2. It allows for more efficient management of collidable objects. That is, if the objects are stored in a data structure that reflects the geometry of the game world, then each object wouldn't have to be compared with every other, only the ones within a certain distance (whatever that may be).


I don't see this at all. Doesn't a scene graph serve a similar function? Wouldn't tracking collisions be somewhat related to the world representation, (e.g. a quake level vs. an rts game)? Wouldn't the collision manager then end up defining a parallel data structure when it doesn't need to?

Aside from that, why would a free-standing collide function be unable to use some sort of spatial data structure? Let's say I kept all my world objects in an octree for view frustum checks. Why not just pass that to collide?


Quote:
Original post by Aeneas
2: The code will be Object Oriented

3:As of 2, Object Oriented Programming allows for more reusable code later, rather then if you just throw it all into a function and make it for this specific code source....


Being object-oriented to be object-oriented has no intrinsic value. The fact that Java considers the sin function to be a part of some math object is very silly to me. Object-orientation doesn't mean that code is more or less reusable. Some of the most-reused code out there isn't object-oriented. The entire ANSI C runtime is not object-oriented, and it gets used a lot even in C++ programs. Believe it or not, but the STL is not object-oriented, at least so says its designer.

Share this post


Link to post
Share on other sites
Frequency    442
Whether or not its object oriented, the idea that I have a function/object that I pass all my objects to to check them against each other as opposed to having each object check itself against everything else is a keen idea, the kind I was looking for really. I'm not sure if a collision manager has enough stuff to keep track of to make it worthwhile to turn into a class; I'll have to see when I get there.

A question, though - how would one do things like path-finding for enemies with a system like this? It will of course have to know all the locations of objects on the map so it will know where to go and how to get there, but how can this be expressed besides passing it references to all objects in vectors (like my first [bad] suggestion for collision)? I don't see how one could make a PathFindingManager.

Thanks!

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