Proposal for restructuring the project.

[scottazord]

Hey all,

I was wondering if we could move the current project structure to a gradle structure.

• .idea/
• src/
  • main/
    • java/
    • resources/
      • maps/
      • config.properties
  • test/
    • java/
    • resources/
• build.gradle
• settings.gradle

At the moment to setup the project in Intellij (or another IDE), you need to manually define the project structure (libs, src folder, java version, resource folder).

The above proposal allows the structure to come predefined. Other benefits include

• Gradle's dependency manager, which will allow us to remove jdom / minimial as an embedded dependency.
• Unit Testing structure.
• Resources folder, if you build the current MicroRTS as a Jar, you need to specify the maps folder as a resource folder, in which all elements of maps are added to the root of the jar (not in a seperate folder). Adding the above resources folder will prevent this.
• Provides a universal structure for all developers.

The above changes are not backwards compatible as such the major version would need to be incremented.

As well as the above, i also propose the implementation of a main class which is configurable. Configuration could be as below.

### NETWORKING ###
server_address=127.0.0.1
server_port=9898
# If true the environment will be running as a server, false as a client.
server=False
# XML = 1
# JSON = 2
serialization_type=2

# MAP
map_location=16x16/basesWorkers16x16.xml

#### GAME SETTINGS ###

# The max number of cycles the game will perform.
max_cycles=5000

# If false, the players have full vision of the map.
partially_observable=true

# Versions (DEFAULT = 1)
# 1 =  Version one
# 2 = Version two (a fine tune of the original)
# 3 = A non-deterministic version (damages are random)
rules_version=1

# Conflict policies (DEFAULT = 1)
# 1 = A conflict resolution policy where move conflicts cancel both moves
# 2 = A conflict resolution policy where move conflicts are solved randomly
# 3 = A conflict resolution policy where move conflicts are solved by alternating the units trying to move
conflict_policy=1

I have experimented with both proposals and have them working quite well. I'm more then happy to submit two seperate pull request for each proposals so they can be examined.

Note: The above isn't for bots to participate in a tournament, but to provide better infastructure for remote agents running the game locally.

Regards, Scott.

[santiontanon]

Hi Scott,

I really like the idea of the configurable main file. There is currently an attempt at this coded by Nicolas Barriga (basically this is what he was using for running his experiments) in test/RunConfigurableExperiments.java. But I haven't used it myself, so I don't know how flexible is it. But this is something that I'd definitively want to do. Your proposal sounds pretty good, so, if that ends up being enough, it should replace the current test/RunConfigurableExperiments.java. Since that would not break anything, if you want to do a pull request with that part, please go ahead, since I think that's be a great addition!!!! (thanks one more time for your contributions!!)

About the project restructuring, I am a bit hesitant about it... on the one hand I have always wanted to add unit tests, but never had the bandwidth to create them. But on the other hand, I don't like the idea to adhere to a given building pipeline (e.g., gradle) (I've had bad experiences in the past committing to certain building pipelines or third-party dependencies, that I never thought would disappear and they did). So, I understand the advantages, but this is something I will need to think about a bit more before deciding one way or the other! I'll keep it in mind though!

[scottazord]

Hi Santiago,

Understandable about the project restructure, thought it was a bit of a stretch myself.

In regards to the configurable main file, i'll send the PR asap. Though at the moment it's only suitable for one remote agent playing against a local bot, is this fine?.

The future plan was to allow the configuration to support N number of remote agents along side M number of bots.

[santiontanon]

I think it's a good starting point anyway. Perhaps instead of "server = true/false", we could have a "mode = server/client/standalone", and in the third mode, the game would would just run on its own, locally.

The only thing that would have to be added is to specify the opponents to use.

Once this is set up, extensions can be easily added to specify whether we want to save a replay to a file or not, launch a window to see the game progress graphically or not, etc. But those can be added later. And of course, once functionality is complete, I'd like to then remove the test/RunConfigurableExperiments.java class, for not having replicated functionality.

[scottazord]

20 Have sent a pull request containing the main class.

[santiontanon]

got it! I'm going to leave this issue open, to remind myself of extending the new main class to support the whole range of configuration options of the game

[santiontanon]

I just extended your class a bit to allow for Stand alone games. I also changed the "TOURNAMENT" constant to "GUI", since there are more things the GUI can do, and also made some parameters optional (for example, if you are not running CLIEN/SERVER, you can leave out the IP, port, etc. of the config file, and it'll work fine).

But thanks for creating those classes, it was actually a very flexible way to configure the game, and I feel it can be extended very easily now! So, I am going to close this issue, but if there is any additional feature you would like in the MicroRTS.java main file, by all means feel free to reopen! :)