Class Design

[ashish2199]

I am thinking of creating these classes under these packages.

Bomberman (Project Name)

Source ( Folder )
    Contstants ( class )
    GameState ( class )
    GameController ( Package )
        EventHandler( class )
        GameLoop  ( class )
        GameVariables ( class )
    Algorithms ( Package )
        Enemy Movement ( class )
    Entity ( Package )
        Static Entity ( interface )
            Walls ( class )
            Stones ( class )
            Bomb ( class )
        Moving Entity ( interface )
            Enemy1 ( class )
            Enemy2 ( class )
            EnemyN ( class )
            Player ( class )
        BoundedBox ( class )  For collision
            Rectangular BoundedBox
            Circular BoundedBox
    Animations ( Package )
        Player Animations  ( class )
            Walk Animation
            Dying Animation
        Enemy Animations  ( class )
            Walk Animation
            Dying Animation
        Bomb Animations  ( class )
            Ticking Animation
            Exploding Animation
    Scene ( Package )
        Level1 ( class)
        Level2 ( class)
        LevelN ( class)
        Curentscene  ( class )
    Renderer  ( class )

  Resources  ( Folder )
    Images ( Folder ) 
    Sound  ( Folder )

Please provide your feedback

Update: Changed to exploding animation , also added multiple classes for vairous levels.

[ItsStolas]

Could we make a parent character class to derive enemies and players from, instead of just an interface? In my experience, there is always a lot of similar code. Or we could do it through composition, either way, I think having concrete code rather than an interface makes sense maybe?

[lyx13710]

At first, I was about to agree with @CoreyHendrey. On second thought, they have different logics, assuming the game is single player. Player character's movements and, where it places bombs will be controlled by the player. But bots' actions will be controlled by algorithms. So, it probably makes sense to make a separate interface for their actions but for their characteristics, isn't it better to make a parent class, e.g. Character, with common attributes like color(which they all have) and inheritance from that class? This is how I thought. Please, correct me if I am wrong.

[ItsStolas]

I think the algorithms should output which way to move, and the parent character class will take those as inputs to move the character. However the player will use the keyboard as the inputs. I don’t think the algorithm should actually move/translate an object directly. :)

[ItsStolas]

It's good to talk about though. Thinking about it more, it'd be better as a separate class entirely. We can then have things like friction (for sliding), velocity, gravity etc in a movement object. Then we can even use them for the bombs and whatever else needs to move.

[ashish2199]

@CoreyHendrey, @lyx13710 Thanks for your feedback.

What I am thinking, is having interface for the entities is because they may have common behavior that is moving, collision detection ect but I feel the way they implements/how they behave is different for example movement of two different enemies will be different. Also interface will allow us to do things like have a single list for enemies of various types. We can use their common method like draw() to render enemies of various types using same for loop.

I agree there will be lot of common code like knowing the position of that entity or getting health for that entity.

One approach is to have Static entity as interface which defines behavior and have a abstract class called Enemy which will have common state and behavior.

But again the instance variables should be based on the behavior we want to provide not they other way round . By making a abstract class, we would inherit them all even if we don't need/use them.

Hence I have my doubts with this approach. What do you guys think ?

[lyx13710]

@ashish2199 Yeah. That's what and how I wanted to say. God damn it >_<

[ItsStolas]

Either way sounds fine. I’m just wondering how their movement will be different to the player though. I think my way may be a bit to convoluted. I was thinking the movement receives something like a 2D Vector, and moves based on that. How we generate that could be different for different entities. I’m very new to architecture so I could be way off, though. I’m happy with whatever you guys want to do :)

[ashish2199]

@dostertag commented on Nov 17, 2017, 6:15 AM GMT+5:30:

Bear with me, guys. I'm very new to Java and am really glad Ashish created this project. That said, I'm having difficulty wrapping my head around the Entity class and how the other player/ai/stationary objects will inherit from that interface. Any chance some of you have experience creating an UML to explain?
From my (limited) understanding, I see the Entity interface as having: a position(x, y) boolean moveable health image/sprite

Player would implement Entity and add void move(event e)??? animate(Direction direction) attack(dropBomb?)

I realize this is basic and incomplete... I'm willing to learn how to create an UML with easyUML1(netbeans plugin) if no one knows how to but will need a more fleshed-out direction to start.

It seems to me that we'll need to have a basic 'player' implementation before we can set the movement and direction efficiently.

Again, I'm a beginner, and am happy that this was posted in the first place.

First of all, Thanks for asking such question. It I feel it will be helpful to others too.

First of all let me tell you what I mean by Entity. For me Entity is anything that is drawn inside gamescreen(the box that represents the area in which game is played) which affect the behaviour of player.For example a wall is a entity for us as it stops player from moving across it. Examples of entities: Player, other player(in case of multiplayer game) , Enimies , Stones , Walls , Bombs , Gates , any powerUp/Enhancement to bombs ect

First of all Entity is not a class, it is a interface ( that is it will only tell what behaviour i.e Methods the class that implement it will provide). Since it is a interface it will only have abstract methods and wont have state. Position(x,y) is state of entity and hence cannot be added to a interface.

Entity interface will be extended by two other interfaces that is StaticEntity and Moving Entity. Methods which EntityInterface might have are checkCollision(Entity other) , drawIself() , removeFromScene()

StaticEntity interface will provide the behavior for entities that donot move such as Stones as Bricks. It might include methods such as getDamaged(int damageLevel) , isOverlapingWithOtherStaticEntity() ect

MovingEntity interface will provide the behaviour for entities that move across the gamescreen such as Player and various types of enemies. It will have methods like move(int steps, enum Direction), die() , getHealth() , reduceHealth(int damage)

Now comes the actual class which will implement this interface that is Player Class class. Player class will have state that is instance variable such as positionX , positionY , health , playerName ect. Since it will implement MovingEntity interface which inturn extends the Entity interface so it will have methods from both the interfaces. Here will we provide the method body for these methods for example die() method will be implemented diffeent by enemy classes and player class. For enemeny class when die method is called we would simply just set isAlive boolean of that enemy to false, increment the score and remove it from the list of aliveEnemy which will present it from getting drawn on screen. Whereas die method is a very important one for player class, lot of things will take place when the player dies that is the method which will be responsible for getting the game over will be called which in turn might call other methods that will dispay screen text of Game Over , change screen ect.

Here is a UML diagram showing the same

[llllllxu]

Based on the current code, I think we should add a class for enemies...

[ashish2199]

Here is current structure, the above was just a reference for how things should work. Its not the actual structure for the classes.