consisted of some of the major problems and fixes:
---Progress Report - Week 1
Planning and brainstorming of ideas completed. Eight initial ideas
were generated 2. After weighing the pros and cons,
our decision was to go along with the real time strategy game 3. Analysis of potential problems and solutions
for the game was completed. Problems include the networking and
threading components of the program. Some research of multithreaded
servers was made. 4. Decided to test networking capabilities through
a networked chalkboard program. This chalkboard program just acts
as a test to see if our game is realistically possible to complete,
because there were initial concerns with the networking of the
game. 5. Developed/revised questionnaire, and distributed
it to the target audience. Noticed it was difficult to find females
who play real-time strategy games, this would bias our data towards
males, which is perfectly legitimate because generally the game
industry caters towards males.
analysis of questionnaire - graphs, pie charts etc. (Josh)
2. Develop HIPO/UML Diagrams - define the labour required to complete
3. Assign tasks according to group members' strengths and weaknesses.
4. Perform a feasibility study, which consists of a problem definition,
in depth problem analysis, recommendations and development plan.
Report - Week 2
Planning generally completed - UML, HIPO, video layout, feasibility
study and division of tasks. 2. Researched solution for graphics, networking
and full screen. 3. Analysis of potential problems and solutions
for the game was revised. Additional problems include free movement
of the cursor on the map while other units in game are also moving.
Revised goals for the game. 4. Threaded networking was tested successfully.
No chalkboard program was required to prove network capabilities. 5. Drew few conclusions from questionnaire as
results were much varied. 6. Researched the Graphics2D class. We were disappointed
to find out that images cannot be drawn on a real-coordinate system,
but rather, the traditional integer-coordinate system. This complicated
the algorithms for the unit class.
2. Create menu system, research pre-loading and advanced networking.
3. Continually revise program structure and paradigm.
Report - Week 3
Basic Menu completed - Pre-loading and full screen researched
and implemented. Originally, problems were encountered with the
function and layout of the game. We considered using different
classes (one for each menu item, including the game), but we failed
to figure out how to do that. This left us no choice but to have
all the menus, including the game function, within one class.
The problem was passing Canvas objects between classes. 2. Image class completed. No errors were encountered.
Preloading of the images was considered to take as painting images
without preloading created awkward and unnecessary painting. We
discovered that using a MediaTracker object would preload the
images. 3. Because we are using a Canvas to paint all
the pictures, we are unable to use a TextField, which is part
of the Applet class. We solved this problem by making a separate
TypeEvent class, which would listen for keystrokes. 4. Unit class was started - Unit attributes class
completed. Unit paradigm completed, few details left to sort. 5. Unit movement sub routines in progress. A
rather difficult problem encountered could limit the game realism
->Programming units to be able to avoid obstacles when attempting
to reach the desired location will require massively complex algorithms
to complete, barring a discarded paradigm that would consume all
or almost all system resources. If unsuccessful, all terrain in
the game would have to be rendered traversable. 6. Associates contacted to begin Unit sketches,
designs and graphics for in game Unit animation. 7. Method which gets the map and it's layers
from the harddrive have been successfully made. This method will
serve as an interface to gather map information and build a map.
2. Complete Unit class and Unit attributes class
Report - Week 4
Unit class basics completed, Unit attributes refined
and defined 2. Basic movement routine completed, advanced
object avoiding movement routine pushed back to wish list - efficient
algorithms perhaps too difficult to conceive. 3. Network communication/paradigm tested - successful.
temporary grid system
2. Make map usable
3. Implement Unit class on map
---Progress Report - Week 5
We made attempts to create a moving map. Problems were encountered
consisting of fluency of frame rate, accuracy, and extreme memory
requirements. After optimizations, map is declared useable. The
frame rate was decreased to an unnoticeable amount of 30 frames
per second. The accuracy in which the map moves relative to where
the user clicks still lacks precision and needs to be worked on.
The memory required to perform all calculations and paint calls
is sufficient for now. 2. Grid system was abolished. Calculations by
pixel now implemented. This allows for more flexibility in the
movement of the units and them map. 3. Network communication (Messaging) was partially
completed. Some minor problems involving paint clashes and keylistening
were solved. 4. Unit selection and box surrounding the area
where the mouse is dragged was successfully made. Unit AI for
moving was successfully completed. Expansion (wishlist) is left
open for extra movement capabilities including queuing of destination
via vector attributes contained in each unit thread.
and make useable networking protocol, which was previously left
2. Make mini-map usable
3. Account for Unit restrictions.
4. Implement multiple map layers.
5. Test networked unit control.
Report - Week 6
Attempt at ideal algorithm for map drawing fails due to heavy
system and processor loads. Past algorithm is deemed suitable
and reliable. 2. Networking communication completed, units
are now networked and visible by both parties 3. Box design and actual product construction
underway 4. Additional features on the map are set to
be implemented in the game 5. Finalizing of program limitations still to
what will be implemented in the game, and what isn't feasible
to implement by the time the product deadline is nigh.
2. Make mini-map usable
3. Implement multiple map layers.
4. Finish box design
5. Make game fun and useable by average user