Collectible Card Game Headquarters

EDIT: thread title updated, because the thread kinda derailed towards the multi-module maven setup, which seems to be working out very well

TL/DR : I'm considering writing a bunch of automated tests (not unit tests though), which might also (eventually) involve some refactoring to make code more testable.

Long version :
I would like to write automated tests to verify that rules and cards are implemented correctly. Such tests would set up a minimal game situation, let some time pass and/or have one of the players (attempt to) perform some action and/or let some more time pass, and then inspect the game situation.
These kind of integration tests don't directly point to problems (as unit tests might), but they are useful to have around to detect new changes or bugfixes breaking previous functionality.
Of course, it might be necessary to do some refactoring to make it easier to do all that. Such changes would be purely technical (ie, moving code around, without changing functionality from the point of view of the end user), but they obviously do have an impact on the developers... Of course I would not do that any more than needed, and only after making sure that the refactorings don't end up breaking anything either. Such refactorings would have to happen on a separate branch, to make sure that other developers can review them without any impact on trunk.

Some background :
I've been coding for about 12 years, working as a software developer for 6 years. I mainly do Java-based web development. The things I enjoy most about my job/hobby are bug-hunting, refactoring, performance-improvement, writing non-trivial automated tests, and writing clean code.

I totally like the idea of adding more tests.

ptx, do you eventually know how to set up pom.xml to split the game into modules?

Yea it'd be great to have more tests since there are a lot of corner cases that sometimes get clipped when adding new rules in.

Max mtg wrote:ptx, do you eventually know how to set up pom.xml to split the game into modules?

I've worked with Maven a bit, though I'm far from a Maven expert
At the moment, I'm obviously also not very well acquainted with the Forge code-base yet, but my initial cursory reading has given me the impression that splitting up everything into proper modules with well-defined dependencies is going to be quite a challenge. For example, currently we have things like CardFactoryUtil (a very low-level core class) directly calling GUI code etc.
I'm not saying I'm not up to that challenge, but at the very least I'll need some time to prepare
EDIT: found the other thread about Maven stuff, so I'll continue talking about this subject over there.

ptx wrote:

Max mtg wrote:ptx, do you eventually know how to set up pom.xml to split the game into modules?

I've worked with Maven a bit, though I'm far from a Maven expert
At the moment, I'm obviously also not very well acquainted with the Forge code-base yet, but my initial cursory reading has given me the impression that splitting up everything into proper modules with well-defined dependencies is going to be quite a challenge. For example, currently we have things like CardFactoryUtil (a very low-level core class) directly calling GUI code etc.
I'm not saying I'm not up to that challenge, but at the very least I'll need some time to prepare
EDIT: found the other thread about Maven stuff, so I'll continue talking about this subject over there.

I have some ideas where to draw the borders for modules, but cannot setup those pom.xml files for each project without ruining the build process.

Max mtg wrote:I have some ideas where to draw the borders for modules, but cannot setup those pom.xml files for each project without ruining the build process.

(Note: I wrote this post differently at first, but then edited it as this version is probably clearer)

First we set up the initial structure :

1. Define what modules we want
2. Create this new structure. But just the structure, don't try to actually move any code to the new modules yet. Instead, keep a "deprecated" module containing all the current code, having a dependency on all the new modules.

At this point, we have the new dummy structure, but still the old code. Everything should still work at this point (it might take a bit of fiddling, but not too much, I'll gladly help out with trying to iron out all the issues).
If everything is indeed OK, this change should be merged to trunk soon to minimize future merge conflicts.

Then we can slowly reorganize the code :

1. Identify a piece of code that is not in the right module, but does not have too many unwanted dependencies
2. Perform some refactoring to eliminate the unwanted dependencies
3. Move the piece of code (closer) to it's intended module

This will be a rather slow process, as there is a lot of work to do, but most of these individual changes should be relatively small, and merging often will help minimize merge conflicts.
As we go through these iterations, existing code structure improves gradually, and new features slowly start automatically adhering to the new structure.

I have some ideas where to draw the borders for modules, but cannot setup those pom.xml files for each project without ruining the build process.

Just let me know where you want to split things and I can take care of the pom.xml files. What I could do is set up the module directory structures and some dummy pom.xml files with dependencies. Max, we could then try to move in files slowly for each module. If I have it set up correctly, everything *should* build without impacting the current setup.

Just let me know the names of the modules
e.g.
forge-gui
forge-core
forge-ai

etc

Dave

Just as you've listed it:
gui, core and ai.


I expect AI to be hardest module to separate from the rest of code.

Hi Max,

So I did some experimentation and have made progress. I set the main forge directory to be a parent project. I created module projects and everything builds. We still get a runnable assembly at the end. The main caveat is that I had to move the entire source tree from the base forge directory into forge-core. This should be ok since you can then move code into forge-ai and forge-gui. I set dependencies up amongst the modules so it should still work. The pom.xml files are still pretty messy but at least the build works. Let me know if this sounds good and I can check the changes into svn.

The windows-linux profile build works. The osx build succeeds but the dmg file is messed up. Since the .app does not currently work anyways due to the Java 7 on osx problem, is this an issue? I hope to look at the Java 7 problem after the re-org into modules.

Hi Dave,

Good to know it builds now.
I suggest that all the existing code should be moved to gui module and then we'll extract purified classes (that won't depend on swing) to core and ai projects.

Dependencies are to be like that:
GUI imports ai and core
ai imports core

The main problem I could not handle was the build process. Thanks for solving it.
For the rest it looks good to commit.

Hi Max,

Took your suggestions and made the changes. All of the code is in forge-gui. I added module shells for forge-ai and forge-core with the dependencies you suggested.

I committed the changes to svn. If there are issues, let me know.

I'll start looking at fixing the OSX app.

I had a few problems updating to rev 23605 but I was able to resolve most of them. The project will not currently build on my computer:

Code: Select all

Project 'ForgeSVN' is missing required source folder: 'src/main/java'   ForgeSVN      Build path   Build Path Problem

Project 'ForgeSVN' is missing required source folder: 'src/main/resources'   ForgeSVN      Build path   Build Path Problem

Project 'ForgeSVN' is missing required source folder: 'src/test/java'   ForgeSVN      Build path   Build Path Problem

The project cannot be built until build path errors are resolved   ForgeSVN      Unknown   Java Problem

 
I have not yet figured out how to fix the problems above.

Hi Chris,

That is strange. I am updated to r23605 and can build it without issue. I did a clean checkout to a new directory and was still able to build it. That said, I am using the Maven command line.

I see - Eclipse .classpath file needs to be updated. I'll take a look.