Game Development and OO

Started by
21 comments, last by ChaosEngine 23 years, 10 months ago
quote:Original post by Kylotan

I think the point is that if your class is just a big list of Get/Set methods and very little else, then you''re not really understanding the point of Object Orientation. Of course, nearly all classes will need some Gets, and some Sets, but generally you work with your objects on a higher level than that.


Well his biggest points are that you shouldn''t ask an object for data that you need to do something, rather ask the object to do something with that data for you. That goes against the encapsulation rules. I''m having trouble with this personally, but so far, in my most recent project, I have been able to move towards what he is talking about. It seems to be working, though I am just at the beginning stages.

Advertisement
At some point, however, there has to be an exchange of data between objects. Consider this scenerio:

Two ships in space, one needs to intercept the other. In order for this to happen the interceptor needs to know the location of the other ship. I can think of no way to do this other than to have the iterceptor object ask the object that it is targeting for its location.
At this point when you start to abstract data and treating it as an entity, you start writing code that can become cumberson and moderately difficult to use.

If you are enforcing business rules for a large DB process this is ok, you can always strap on another server to make your backend services execute a little faster.

In gaming (programming) you generally call a spade a spade. In other words, you decide up front how 'fixed' your data types are and how they are access. Cuz' if you don't, your code is going to be soooooooooooooooooooo slow. Once you have decided that you don't need an abstract data type, acces/manipulation is straight forward.

Gaming class hierarchies generally are not very deep (BTW shallow class hierarchies are a good design), but they are generally wide. The reason for this is that you pack in as much functionality into the base (and child classes) as you can without adressing the final derivation (BTW this is what your supposed to do in OO, its called abstraction).

Remember the engineers rule of thumb, KISS. Keep it simple (stupid). This is especially true in OO.


Edited by - DeltaVee on June 21, 2000 1:58:20 PM

Edited by - DeltaVee on June 21, 2000 1:59:23 PM

Edited by - DeltaVee on June 21, 2000 2:16:47 PM
D.V.Carpe Diem

This topic is closed to new replies.

Advertisement