Skip to content
Permalink
master
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
 
 
Cannot retrieve contributors at this time
This file contains brief information about progress of this project.
Note: The minimap(map data) from the offical game TripleA is used in this project.
week 1:
1. learn the rules of the game TripleA and the rules.
2. design the GUI
3. Start to experiment with the technology to implement the map of the game.
4. Now, implemented(may need refactor):
draw static map(draw an image).
draw infantry on the map.
draw polygons that correspond to the territories on the map.
based on the polygons, the code can detect which territory has been selected.
week 2:
1. refactor the existing code to separate model(data) and controller from view:
add a class for territory
add a class for map data
add a calss for infantry data
move mouse lister from view to controller
2. determine the relationships of the territories(mainly to determine the distance)
3. Basically, the model part(game state) is done. But only production value and infantry information are shown on the map.
4. Start to work on the play phases with only one unit type(infantry). Using this strategy to implement a very simple
but runnable game firstly, then add other units later.
week 3:
1. add a method to compute the distance between any two territories.
2. experiment with the tenologies needed to implement views of play phases
3. still work on purchase pahse
4. spend lots of time to get familiar and learn the (unexpected) behaviors of the layouts provoided. Sometimes, this is
really confusing.
5. Basically, purchase phase is done.
6. Now, need to figure out how to refactor the code to make later development more easier: how to effectively and efficiently
reflect the model change in views. The method used now is not good enough.
week 4:
1. refactor the code to use observable/observer to replace the used push method.
2. starts to work on combat move phase.
3. try to figure out how to share a space with multiple panels(when a button is clicked, show the panel corresponding to this button).
4. Tried cardlayout, failed. Time waste.
5. Tried other layouts: flowlayout, boxlayout. Tried to make the UI make comfortable, failed. Time waste.
6. Still not statisfied with the UI. But a lot of time has been spent(wasted) on this. For, just stick to one just works and move on.
week 5:
1. refactor to make it possible for adding code for later phases
2. starts to write code for combat move phase(this is (much)slower than expected).
3. compute a shortest path between any two territories(just computing the shortest distance is not enough)
4. stucked in how to move units, figuring, figuring, figuring
5. be able to move unit(infantry) on the map(first click left to select source territory, second left click to
select the destine territory, right click to cancel a selected (source) territory). Now, work on cancel a movement and
show a movement(show an arrow).
6. combat move phase done(usable).
7. A very simple battle phase done.
8. noncombat move phase done.
9. Now, each player can play all the phases(place phase has no action for now). And still need to add code to check winning and to collect produced PUs.
week 6:
1. place phase done
2. code to check winning state done
3. Now, it's very simple playable game.
4. add code to collect PUs at the end of each turn.
5. fix bugs and refine code to make the views a litter more confortable.
6. A simple playable version is done.