How to organise my classes in a game

Started by
-1 comments, last by darenking 18 years, 10 months ago
Hi everyone, I get the feeling this will have been covered many times but I haven't managed to find it explained in a way that really makes sense to me. Lots of people are so helpful and thorough on this website that I think it is useful to me and hopefully other people to present the problem in a way that makes sense to me, and see if people can help me with it. Certainly it is a common problem. I'm just trying to find the best way to organise my classes. OK, so I have my main() function, and it creates instances of my Person class and my Map class and my Input class and my Output class. Just simplifying here of course. I have tried two approaches, though maybe they amount to the same thing/lead to the same problems. 1st approach ============ The main() function reads the keyboard/joystick input from the Input class. Then the main class tells the Person class how to move the player Person based on the input, and also tells the baddie Person classes to move randomly or whatever. Then the problems start. I can then tell the main() function to update the Map class, ie if there are blocks that dissolve or whatever they can do their thing on their own, a lovely example of encapsulation. Before that however, the problems occur when I tell the Person classes to move, ie the player moved by the joystick and the monsters moved randomly or whatever. People say, your Person classes or Sprite classes or Monster classes or whatever should all know how to do their own movement. But of course they have to move within the restraints of the Map class. How can they do this when they have no direct communication with the Map class, ie they both only communicate with the main() function? 2nd approach ------------ Perhaps I have organised the whole thing badly? In fact maybe there should be the main() function at the bottom which: 1 communicates with an Input class 2 comminicates with a World class (or similar) 3 comminicates with an Output class Perhaps my terminology is wrong but I'm sure you get the idea. The Input class receives the input. The World class controls a Map class and lots of instances of the Person class, one of which is the player and lots of which are the monsters and suchlike. Although the Person classes can't communicate with each other, they don't need to because they are all controlled by the World class. ie the World class will decide to move a Person left five pixels, will check the Person is able to (isn't asleep or dead or whatever) and also check that the Map allows them to do so then instruct them to move. Of course, the difference between my first approach and my second approach is that, in the second approach the Person objects and the Map object, although very different in the way they work, are both instantiated by some sort of controller class, what I've called the World class above, though I think some people call a Game class. They are both instantiated by the World class, and it is this World class that counts through the various persons/monsters etc and attempts to move them by communicating with the map. I am still concerned though with this second approach that there is a lot of to-ing and throw-ing between these different classes, ie the controlling class has to 1) check if a person wants to move, b) check if it is allowed to move on the map and 3) finally tell it to move. Is it fundamentally correct or fundamentally wrong that these three things listed in the paragraph have to happen - regardless of how I organise my objects? In other words, do I accept that that is how it is done, or take a different approach? Certainly it would be easy enough to program. I just keep thinking that it is in some way fundamentally wrong. Ooh, also, if I take this approach how does the Output class know the locations of everything when tries to draw it? Mega grateful for any help. [Edited by - joebarnslondon on June 6, 2005 1:09:12 PM]

This topic is closed to new replies.

Advertisement