How to Structure Lots of Code?

Hello Bukkit,

I'm trying to structure a large amount of code and don't quite know the best way to do this. I have a game per world running and I need to keep track of all the games and data from a central main plugin, and manage games (create new games in worlds that didn't exist before).

What I'm trying to accomplish is being able to hook into a main API plugin and running each world of the server as a game. These games would be scale able, meaning I would be able to create new worlds (and in effect, create new games) whenever I wanted to or delete them when needed, and would allow me to call a game by its world and run methods from the main API from within the plugin.

The way I see it, there are 3 main ways to do this.

A) Create a game interface with the required methods and let every game extend "GameInterface" and handle worlds/games themselves, meaning every sub-plugin would have to handle creation of new games and lots of copied code, but easier to implement.
B) Create a game object and onEnable for each of the games, register a new object. When a game begins, store the new game object with the world in the main plugin and call the game object every time its needed from methods inside the sub-plugin.
C). Create an abstract class for games and let the games follow that format/use those methods. The plugin itself would handle world games and storing all that data. (much like A but more flexible, but less rigidity).


Which way would you say is easiest to manage and implement? If there is a better way, please share it here!

Thanks,
ccrama

 

ccrama

• Interface
  • This is an odd idea if there is only one game implementation. If there is only one implementation of an interface, then the interface is useless. Say you have an FFAGame, and a TeamGame, but they have common methods. Then it is logical to have an implementation such as Game. Following code conventions, never have classes such as <Class>Interface, I<Class> or <Class>Impl (<Class> = Class name)
  • Each Game wouldn't have it's own-class ....
  • What do you mean by a sub-plugin? Do you mean one that uses your Game as an API?
  • Instead of an interface and copying code, why not use abstraction? Much easier.
• onEnable + new Game instances
  • This is a viable option ... Personally I don't like having too many methods in my main class. Only setting up stuff like dependencies, configs, etc. but that is just personal preference.
• Data Abstraction
  • I think this is better than an Interface, as discussed in point A. Therefore it easier than creating an Interface
• My Approach
  • Singular Game/Arena "type"
    • Usually I have one Game object and a GameManager of some sort that handles these individual objects and stores them in a list of sorts.
  • Multiple Game/Arena "types"
    • If many methods are the same in each type (such as lots of getters, setters, and other methods like starting and ending), use data abstraction.
    • If the first point doesn't suit you, follow the use of interfaces.
    • Additionally, you could also use annotation-based arenas; however, this is not common, and personally I have never looked into it.

 

AoH_Ruthless Very thorough answer. I think I'll go more towards your approach, sounds very nice