Rename 'game-core' -> 'game-engine'? Moving packages from: games.strategy to org.triplea

[DanVanAtta]

I did some prototyping on package grouping and came up with the list below:

- games.strategy.engine.framework => org.triplea.engine
- games.strategy.triplea => org.triplea.engine
- games.strategy.engine => org.triplea.engine
- games.strategy.ui => org.triplea.engine.ui
- games.strategy.debug => org.triplea.engine.debug
- games.strategy.net => org.triplea.engine.net
- games.strategy.performance => org.triplea.engine.performance
- games.strategy.security => org.triplea.engine.security
- games.strategy.sound => org.triplea.engine.sound
- games.strategy.util => org.triplea.engine.util
- org.triplea.util => org.triplea.engine.util

Any thoughts on this grouping? Does org.triplea.engine seem like a better fit than org.triplea.game? Any thoughts/feedback on updating the name of the sub-project: game-core to game-engine?

[RoiEXLab]

Does org.triplea.engine seem like a better fit than org.triplea.game?

Both are ok IMO, no objections on changing though.

Any thoughts/feedback on updating the name of the sub-project: game-core to game-engine?

If previously in the package name game and engine are replaceable, then game-engine seems a bit odd. I'd rather drop the game- prefix entirely or replace it with triplea-, but again no strong objections here.

In both cases I'm not a huge fan of renaming top level folders to be honest: This always makes the git history harder to work with. (See isaacs/github#900 )

[DanVanAtta]

triplea-engine does have a nice ring to it 😄

As far as rename, @RoiEXLab I think you convinced me to hold off on the game-core rename. I'm thinking instead we'll continue to chip away at game-core with new sub-projects.

[simon33-2]

In both cases I'm not a huge fan of renaming top level folders to be honest: This always makes the git history harder to work with. (See isaacs/github#900 )

Totally agree. I don't understand why these things ever needed to be changed or why they would be changed again.

simon33-2 out.

[DanVanAtta]

Considering the package updates spans all of games.strategy, we're effectively having a top-level rename. Hence it is a convenient time if any.

Looking into this further, it seems like it's a difference of:

 git log --follow

vs

git log

I'm less convinced about the impact of changing top level folder given that.

Example:

find . -name "GameDataManager.java" | xargs git log --follow

Shows the full history back to Sean. Seems like it's just a matter of making --follow default if that is your preference.

@simon33-2 The reason to make these types of changes is so we can improve TripleA API's and class boundaries. Better package placement, less visible classes, and generally more intentionally designed public APIs will help clean up messes like for example places that interact with battle code. In something like BattleTracker, it's an example where there is very few boundaries and everything just calls into low level APIs as it pleases. Package structure does not enforce a fix for this, but it does help as public modifiers can be removed, and it becomes more obvious when cross-package calls are performed. The sub-project on the other hand creates a compile-time check to 100% disallow this. My thinking is sub-projects are going to be useful as just package re-arrangement is not enough to untangle the tripleA ball of yarn.

I also think the ball of yarn problem goes to other deeper problems, like it being very difficult to test game rules due to everything having a dependency on GameData in test. This leads to us loading full XML maps using a GameParser and falling into a general trap of code that cannot be unit tested. If on the other hand the 'GameParser is in a project of it's own, and that then helps/forces us to split the underlying game rule logic to have good APIs where we can inject test code, then we'll suddenly be able to isolate game rules and test them without having to load a game XML file to supply those rules.

Hopefully that illustrates the benefit to fixing API/package design problems and where sub-projects and re-arranging packages fits in. Since the overall goal is to get the game engine to be more testable, notably so we can create game components in test without loading a game XML, any additional ideas to do that are welcome.