I've been struggling for a long time with completing my hobby game projects. Years in fact. Actually, more than a decade. That makes me sad. My better half suggested that perhaps it's because I don't plan anything and suggested that maybe I should do what we tell n00bs to do, and actually write tic tac toe and various other simple games and work on my planning and design skills in the process. So I did. I wrote tic tac toe in 2.5 hours and it was a hacky mess, but it worked and it was complete. Feel Good++. So now I had to choose a second project. Pacman I thought, that should be reasonably simple. Then I started coding. I found the pacman dossier by Jamie Pittman. I then realised this was no simple task. My code was once again becoming a hacky nightmare (with objects!), so I began to wonder where I had gone wrong, and then I read a post on GD talking about abuse of OOP. That's what I'm doing. All this time I've been abusing OOP, not using it. So now I'm working on some planning and some analysis and design of the problem (game design). I've refrained from posting for quite some time to give myself time to really try and analyse what I'm doing wrong and I think I may have worked it out. Origianlly, I had a GameScreen object which was meant to handle the game rules, updating and drawing. In the update routine, I updated the player and the ghost, by calling player.Update() and ghost.Update() (in a loop for each ghost). I was letting the player and ghost objects control whether or not to move into a cell by checking the game map for walls. I also had gone down the path of making the player remove pellets and update score, and die when it hit a ghost, and the ghosts check the map and determine which way to move, whether or not they should be scared, chasing, or hovering in the home corner. They also killed the player if they caught him. I realised most of this functionality is meant to be one level higher, in the game screen. That was ok, until now, I'm still trying to let the ghost decide what cell to move to next and whether there are walls in the way. I now think this is wrong too. I think that the ghost should simply be storing where it is, which ghost it is and whether it has been chomped or not, and the game screen should have the code that determines the next move for the ghost, and whether it should be scared or not. Hopefully this should end my abuse of OOP. I'm asking (any of you that managed to read my long winded drivel) whether my final assumption is the correct one, in that an object stores its state, and has methods to modify its state within the designed constraints (ie. the ghost can't chase or hover in the home corner when it has been chomped). I also think that by writing this all out I have answered my own question, but just incase I'm completely wrong...

Quote:

Original post by BLiTZWiNG Hopefully this should end my abuse of OOP. I'm asking (any of you that managed to read my long winded drivel) whether my final assumption is the correct one, in that an object stores its state, and has methods to modify its state within the designed constraints (ie. the ghost can't chase or hover in the home corner when it has been chomped).

Ja, you would be correct in that assumption. However, it is very important to keep in mind that OOP is *just a tool*, and a means to an end. Far too often I see code that is OO for the sake of being OO, rather than any benefit it might convey.

Simple projects are poor test cases for OO. I can assure you that the original Pac-Man did not use OOP, and that using OOP for this will make your code more complex, more difficult to write, and of generally lower quality.

Quote:

Original post by Sneftel Simple projects are poor test cases for OO. I can assure you that the original Pac-Man did not use OOP, and that using OOP for this will make your code more complex, more difficult to write, and of generally lower quality.

I realise that I am over-engineering it, as swift said, OO is just a tool, but I also realised that I creating the same kind of mess I have done with my more ambitious (and ultimately re-written 17x before failing) projects. So this is more an exercise in planning than it is writing a simple game. My thought was to use this as a base for some kind of maze based RPG after finishing it, but right now I've refined my goal to "cleaner design".

I tend to make in the bottom level classes too smartand give them too much responsibility. I was doing that with my pacman game, and I have been doing the same thing at work (a non-game project). The project I'm working on was never designed, it just grew organically when the hardware engineers needed a gui to control their hardware, and they were very inexperienced with .net and thus broke most of the good programming rules with it. Those people are gone now, and I'm that maintainer guy you read about in FAQs. I'm fixing what they made (in that is was mostly a prototype that used smoke and mirrors to appear as though it worked) and adding the remaining features. In fixing / expanding it I need to actually design parts of the system. My parts work, but most of the time I sit here realising I made it overly complex in some places. In some places, co-workers have made it hard for me not to make it complex, but I'd like to make my bits as clean as I can.

So it's not all about the simplicity of the project I have selected (yes I was around to play the original pacman), it's about the projects I will build after this one as well. I'm nearly done with it now, I just want it to be not so hacky.

Edit: Though, I do hear you. I'm basically going to write this one off and finish it without going overboard on the OO.