On Fri, 5 Sep 2014 11:56:43 +0200 Albin Stenström <albst...@student.liu.se> wrote: > My name is Albin Stenström and I'm studying my fifth and last year of my > Master of Computer engineering at Linköping University, Sweden. > > I am currently doing a course on Design patterns, and our labs are based > around your codebase.
Well, this is a bit of a surprise. > The first lab is about analyzing Design Patterns existing, in your > codebase, Good luck with that:-). > the second about writing tests (that haven't already been done) > for non-trivial functionality in the code (and then analysing how this > works with design and dependencies. ) More tests are always welcome. > The third and final lab is about writing an "meaningful modification" > either architectural to make further work easier, or a non trivial feature > extending the game, or non-trivial bug fixes. > Making extra ambitious or significant changes can also get me bonus points > for my exam. > All this is expected to take 32 hours per person, and I am working with a > friend. We have been assigned to work within the AI part of the game. > > The thing is that I also want to contribute to your project. So the thing I > would like to ask is what we should focus on for the testing and > modification so that it is of maximum benefit to you. There is a lot of under tested functionality, so it is hard to go wrong choosing an area in which to add more tests. However, if I had to pick one I would nominate the path finding code, particularly Map.findPath and Map.search. There are many tricky cases there, as is immediately obvious if you try to read the code, many of which are not exercised in MapTest.java. Path finding is fundamental to the AI. Many AI failures are due to path finding failures. The only problem with adding more path finding tests is I that in attempting to check that it is doing the right thing, you will find more bugs. > Preferably within the > AI packages, but things crossing into other parts is ok too. (Yes I know > that starting in AI is not reccomended, but it is a cource recuirement) There is a bit of a problem here. In an ideal world it might have been more sensible if the person responsible for requiring you to work on the FreeCol AI had talked to us first. The current situation with FreeCol is that we have been trying hard since about April to get the code into a releasable state, but in attempting to fix some AI bugs the AI performance regressed significantly. Only as of about the last few weeks has it recovered, and we are almost at a point of declaring the AI stable. It is a *really* bad time to add new AI functionality. That said, I do not want to be obstructive to your studies. If you *must* work on the AI, we need to think of some meaningful AI functionality that can be added without significantly harming stability, or at least is easily revertable if it becomes a release blocker. So here are some suggestions: 1. AI colony production The existing AIColony and ColonyPlan code works moderately well, but the decisions of what to produce and build are controlled by a bunch of magic weights, and the code is covered in "FIXME" annotations for unimplemented potential improvements. I am sure this can be made much better. The obvious general problem is that production decisions are not time sensitive --- currently bells and hammers for buildings are strongly preferred, which works quite well in the early game, but in later stages the preference should be to produce military units. Currently if you run a 7 AI game (just parking the player starting unit in a far corner of the map and skipping turns) to 1700 the AIs almost all produce enough bells to declare independence, but have a military force at best about 20% the size of the REF. 2. Enhanced Missions .../server/ai/mission contains a bunch of mission classes, corresponding to what an AI unit is doing. There are some obvious things the AI does not do such as trade with the natives (or Europeans), or demand tribute. One thing that really needs to happen is better scouting. The AI threads are on the server-side, and have full map visibility, which is a major advantage, or IMHO, cheating. A long term goal is for the AI threads to run without such privilege, but to get there the AI must be a lot better at exploring the map. Currently AI scouts do explore the map to a degree, as they visit native settlements and LCRs, but there is no pure explorational goals in ScoutingMission. Worse, there is no naval scouting at all. Certainly idle PrivateeringMission units would be useful as naval scouts. 3. REF The REF has some new colony targeting code which may have fixed some longstanding problems. However it remains rather stupid, often ignoring easy unit targets, and leaving artillery units unprotected in the open. There are so many ways the REF could be made more dangerous, it is difficult to know where to start. > I would appreciate any suggestions, I will need to the same amount of work > in either case,so I would prefer if it was to your benefit. I have no good idea how much work any of the above suggestions involves. Hope that helps. Cheers, Mike Pope
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
