0

I'm doing a Fruit Ninja clone in java (language not really relevant). It's not completed yet, but here is the point I'm in now:

Currently I've:

  • Difficulty interface, where several classes will implement it to decide the fruit moving speed based on the game time, and also determine how many bombs will be created compared to fruits (the more bombs, the more difficult).
  • GameOverCondition interface, where it's implemented by ArcadeGameOverCondition and ClassicGameOverCondition, because in Classic you lose when lives end. and in Arcade you lose when time is up.
  • There is a GameObject abstract class that's extended by Fruit abstract class and Bomb abstract class. Fruit is extended by concrete fruit classes, and Bomb is extended by concrete different bombs.
  • There is a FruitNinja class, which take GameOverCondition and Difficulty in the constructor. And in the constructor it will run a thread that constantly create more GameObjects. And each GameObject will run a thread in the constructor that moves it with the specific speed determined by the Difficulty.

At this point, I just noticed that Difficulty logic currently will be the same for all game types (arcade & classic) (which could be making the game faster and also increase number of bombs). However, I'm thinking that later I may want different logic. How should I change my design?

Feel free to tell any improvements you see.

1 Answer 1

1

Here are some notes, starting with your question:

  • Yes, you should change your design if you see you can get away with a simpler design. With every feature you build in you basically force yourself to maintain something without needing it. So, if you don't need an interface, don't have one. Introduce it only when you actually need it, even if you think it's tomorrow.
  • GameOverCondition sounds wrong. It's technical. ArcadeGame and ClassicGame sound much better, I would also assign the responsibility for the whole game to these, not just the condition when it ends.
  • I'm uneasy with the GameObject hierarchy. It's an inheritance tree, and inheritance is very difficult to get right. I would just go with interfaces and delegation unless there is a really good reason against it.
  • You mention the speed and composition of objects is determined by Difficulty and based on that FruitNinja object will create GameObjects. Instead having a concept of speed, and what I assume are numbers about the composition, etc. why not have the Difficulty object directly create objects for the game? It has all the information it needs to do so, so it doesn't really make sense to publish that information, and let somebody else take action on it.

As always my general object-oriented rules apply:

  • Don't have getters. It messes with your design, very seldom for the better.
  • Have meaningful (i.e. domain-relevant) names for all public identifiers.
3
  • "why not have the Difficulty object directly create objects for the game?" because the FruitNinja class should be aware of them, I want the caller to be able to do: fruitNinjaInstance.getObjects() and it will return all the current objects.
    – Youssef13
    Commented Apr 19, 2020 at 16:02
  • and because Fruits and Bombs have similar behavior, I've implemented this behavior in a parent abstract class GameObject, what do you think?
    – Youssef13
    Commented Apr 19, 2020 at 16:04
  • And you didn't mention how to handle the different logic of difficulty based on the game type.
    – Youssef13
    Commented Apr 19, 2020 at 16:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.