My maze game design

Game Play & Game Design
#1

Hi guys, I want explain my game design, I would appreciate any kind of comments and suggestion.

The game is a tile-map maze, with a logic similar to Pac-man:

-player
-various typologies of enemies
-bonus

I’ve implemented the following classes:

  • the map class (contain the images of the tiles and a method called cantMove
    that check if a particular location on the map is blocked)
  • the sprite class (contain a sprite to be displayed on the screen. don’t contains state information)
  • the entity class (represents any element that appears in the game, setX()… setY()… setDirection etc…)
  • the player class extends entity (is the entity that represents the player, it have also a method to check if it collides with another entity).

for my bonus and enemies class I’ve littles doubts:

Bonus class:
I’ve three types of bonus:

  • A random positive bonus that casually appears in the map and it assigns a positive score
  • A random negative bonus that casually appears in the map and it assigns a negative score
  • A fixed bonus that player have to acquire to pass to the second level
    What’s is the best way to implement bonus? I was thinking to create Bonus class extends Entity
    and then create 3 subclasses (randomPos, randomNeg,Dollar)… it’s ok???

Enemy class:
I’ve two types of enemies:

  • An enemy that moves Randomly
  • An enemy that chase the player if possible, otherwise it moves randomly
    So, I’ve implemented one enemy class that extends Entity.
    I’ve also a Movement class with two methods: Random and Chase, if enemy type is 1 I call exclusively
    Random method, otherwise, if enemy type is 2, first I call chase method and eventully Random method.
    Movement class uses the “cantMove” method from map class.

I’m not sure about this last implementation (enemy, movement class)… what do you think about it?

#2

Bonus class sounds fine.

Enemy class - either take the same route as Bonus and have 2 subclasses or use the a Movement strategy (as we talked about on IM a while ago). If you’re going to implement a movement strategy you don’t have two methods on a single Movement class. You’d have a Movement interface with a single method move(Entity enity). There would then be two subclasses of Movement, RandomMovement and ChaseMovement. They would be implemented to update the entity that’s passed in.

Then when creating an Entity you’d suppy an implementation of Movement (Random or Chase). Finally in the update() method of entity you’d call move() on the Movemement implementation causing it to do what ever it does, and update the entitiy’s position.

Kev

PS. The word typology rocks :slight_smile:

#3

thanks kev, but interface (as we talked) at the end isn’t the good implementation cause chaseMovement and RandomMovement have differents references…

So I was thinking: 'cause random movement is the common method of slippyEnemy and chaseEnemy, I’ll implement an Enemy class that extends Entity… this class will contains the random movement … then i’ll implements slippyEnemy and chaseEnemy that extends Enemy
Question: is better to create two inner subclasses of Enemy???

#4

You might as well have entire subclasses of Enemy, or just include both movement methods in every enemy, then have a boolean variable that determines which method to call. I don’t understand why you feel you would need an entirely separate class to handle movement. To create the best AI and most robust game, you would have every enemy with the ability to move any which way, and why not? If you’ve programmed it for one enemy is there any reason not to allow a different enemy to do it?

Just say Enemy extends Entity and put both movement methods in Enemy (or even if Entity, to create extra options like bonuses that chase you around or something), or if you feel the two movement types are in fact radically different then have RandomEnemy extends Enemy extends Entity and SmartEnemt extends Enemy extends Entity, etc. etc.

Rather than thinking what you need to program, try to think more in real work terms – this is why Object Oriented Programming is so adopted now – you can easily apply the real world to your game. If you have an Entity, what does that mean? Well, you wouldn’t know what it looked like, so no draw method, but you would know where it was and how big it was so it would have x,y,width,height etc. You wouldn’t know how it acted, so it wouldn’t have move methods. Now take an Enemy – you still wouldn’t know how it looked unless you got even more specific (like ghost or alien etc.), but you do know that it wants to harm the player and will have some way of doing that. This means a move method and perhaps damage, life, etc.

Do you see what I’m getting at? There is no reason to put these things in external places if you are doing your subclasses right. Just base it off the real world as much as possible!

#5

Sorry, don’t normally bother with opinions,

While I agree the strategy pattern might not fit well here, don’t fall into the trap that OO means forget that you’re coding and just model everything based on the domain. It’s a good place to start but often the right decision is based on what makes more flexible, robust and modular code - not what happens in real life.

And that really really isn’t true. It’s picked up because it tends towards more maintainable and robust code. This isn’t due to modelling on real life but down to the basic tenants, Cohesion, Encapsulation/Information-Hiding and Defined Association/Dependency.

Kev

#6

They beget each other, in my book. But I respect your point and I’m sorry if I expressed my opinion as truth.

#7

I still think we can all agree that the difference, the transelation between the world and OO is a lot smaller then it is with procedural programming I mean there are other paradigm that profide for the same plusses as you described, yet we aren’t all using that other stuff (yet?).

#8

Not entirely sure what you mean, but what I do understand I agree with. True.