|
Thoughts:
|
| Initial Thoughts: |
Initially, we figured completing OOGA would be only as difficult as
the games we chose, since we already had a general idea of the game
architecture. Professor Astrachan had lectured on using the MVC
(Model-View-Controller) design pattern to implement his games and so
that was what we chose to use. We had all decided to implement
Tic-Tac-Toe together as a group so that we could get a better idea of
the specific things we could exploit in the architecture. The other
three games were to be implemented individually, utilizing the
knowledge gained through programming Tic-Tac-Toe together. Even after
coding Tic-Tac-Toe, our initial architecture was rather vague, but
time was winding down so we decided to just go ahead and work on our
individual games rather than solidify the architecture. So at that
point, our architecture included having a Model and a View, and have
the GamePlayer classes control the flow of the game. We also knew
that our architecture was not as solid as it could be so we figured we
would refactor towards the end when we had completed our own games.
At the very least, we had something to work with.
|
| Future Work: |
As with all projects, this was not perfect, nor did it meet all our
initial expectations. Initially, the plan was to make more games, but
we ended up only doing the games that we guaranteed would be done. At
the beginning of the project, we had set a time table to finish our
project. We stayed relatively close to our time table, except we
spent a little more time coding than we had alotted.
- There are some imperfections in our code that could be fixed. Our
Bejeweled code does not exactly fit into the architecture, not because
of the way we coded it, but because we did not have enough time to
refactor after we finished coding it.
- Also, for our menus, clicking the NewGame option does not remember
the selections made in the Options menu. However, clicking NewGame
isn't the only way to start a game. Clicking "OK" in the options box
after making customized selections also starts a new game, so the
options menu is not totally useless.
- Another thing we would improve would be to extend the gui to be able
to support more options. One example of such would be to support
more/unlimited players.
- We would also have liked to be able to make our games so that they
were resizable, and when you resized them, the icons resized as seen
fit. As we have it right now, decided to not let the user resize the
window.
- If there was something that we could understand better in this
project, it would be how to use threads. Threads did work in our
program, but we think it would be worthwhile to learn more about them,
how they work, and how to use them effectively.
The most frequent errors in our program occured in the area of
threads. We spent the most time in our program trying to learn how to
use them. We had logic errors in our program when we first
implemented threads (like an error that would freeze the game) simply
because we didn't know exactly how they worked. There probably is no
way to avoid these types of problems, as naturally, it takes time to
become familiar with something new, and we must always experiment with
it to see how much we can/cannot do with it.
Right now, if we could do one thing to improve our grade, we would
refactor the code in Bejeweled to make it fit into the architecture
established for our other three games. We would do this, because we
would like all our games to be able to fit into one single
architecture (as is also the point of this assignment). Insteads of
each game be an individual, stand alone project, it should be easy to
make new games once the foundation is set.
One more thing is that extending the core classes to create different
games requires too much knowledge of the base classes. We rely too
much on knowing about the protected variables of the parent. They
should be more encapuslated into set methods (methods that change the
state of the class) rather than accessing the state variables
themselves.
|
| Lessons Learned: |
There are many things that met or exceeded our initial expectations for this project:
- In the beginning we had guaranteed at least 4 working games
(Bejeweled, Chomp, Connect-Four, Tic-Tac-Toe). At the end, we had
these four games in good working condition.
- We had also worked through an architecture on by first writing
Tic-Tac-Toe together as a group. Then as we split up the work for the
other games, we were able to stick to the original architecture in
most of our games.
- Another thing about our architecture that we accomplished is that
there is little to none repeat code. We refactored our game codes so
that anything that was the same between different games became
shared.
- Making applets was another thing that we wanted to do initially. We
were able to make our games so that they could be executed both as
applets and as applications without creating seperate files for each.
- Our options menu was also completed according to what we initially
planned. We were able to support 1 or 2 players, start/quit games,
etc.
For the shortcomings of our program, look at the future work section.
In addition to those listed there, though, we would also do the
following:
- Make our AI a bit smarter for the games that can support AI. Right
now, the AI consists of just random moves.
- We would make subclassing easier to implement because right now subclassing requires knowledge of the protected variables of the base class.
In doing this project, we might have underestimated the amount of time
we needed to work on the project, and the size of the project. This
is reflected int he late hours we spent working on the project the
last few nights before it was due. The impact it had on our code,
though, was relatively low, because at the end we were able to work
through the problems by spending the extra hours on it. Even though
this is true, next time we would still not do the hardest program
last. We would also start our program a bit earlier, and not do
hoomework in any of our other classes.
|
|