Apocalypse Defense.
A mobile zombie tower defense game written in Java for the Android 2.3 operating system.
Spring 2012:
CSCI 576 - Human-Computer Interaction - Dr. Yolanda Reimer
CSCI 591 - Game and Mobile Application Development - Michael Cassens
What was the project assignment?
This Android mobile game was a semester-long collaboration between Pat Kujawa, Nada Ibrahim (Alhothli), and I.
We worked on the project in two separate courses: Game and Mobile Application Development and Human-Computer Interaction (listed above).
Groups were assigned by Dr. Reimer. Pat suggested a tower defense game, I wanted anything zombie-related, and Nada wanted to do the project in 3D.
We settled on an apocalyptic tower defense game while Nada designed the character models and maps in 3D. We worked through a handful of individual assignments
and milestones in both classes using an iterative design process to design, prototype, refine, build, and test the application. The philosophy of an interative design
process is to design, implement, test, and rinse-repeat these steps until you have a product that truly reflects the user's interfacing needs.
As I mentioned above, we were required to reach a set of milestones within a certain time period. These milestones included designing the user interface, creating usability and functional requirements,
coming up with use cases, creating 3 levels of prototypes (low, medium, and high fidelity), user testing, critiques by our peers between each milestone, and presentations on how well we achieved each milestone.
-
Milestone 1: Functional and Usability Requirements
For this milestone, we were required to create a report outlining our functional and usability
requirements, possible use cases, who our users might be, and what sketches we would include in our low-fidelity prototype (my report
).
-
Milestone 2: Preliminary Design, Low-Fidelity (Lo-Fi) Prototyping.
For this milestone, we were required to identify users, how they would want to experience the interface, as well as what functionality would be most beneficial to them to play the game and get enjoyment out of it. Each member of the team was
supposed to draw up a crude preliminary sketch of each screen set out from the original functionality report in milestone 1. We then accepted design critique from our peers, as well as critiquing their designs as well. Our final deliverable was the
sketches, as well as our report of the feedback received during the design critique. This was an individual assignment; my sketches covered mockups for the title screen, game options, splash screen, mission select, saved games, custom map editor, upgrade
options, in-game UI, store, and scoreboard. I separated the 10 screens into 3 sets, but the images didn't come out as well as I had liked, so I enhanced them using a high pass filter and hard light blending options in photoshop. I wrote up a document illustrating
the improvement
. Our group write-up
was done as a collective effort through Google Drive (at that time, Google Docs).
Pat, Nada, and I were able to edit the documents remotely, so we saved time and energy by not having to schedule face-to-face meetups.
-
Milestone 3: Iterative Design, Medium-Fidelity Prototyping, and Testing Without Users.
For this milestone, we were required to incorporate or address feedback given to us from our first design critique, combine our individual low-fidelity design sketches into a design that the entire group decides. Basically, we brought in what we considered to be the best of all the preliminary sketches to create a system design that either
compromises on a certain feature or compliments an existing feature to create our medium-fidelity prototype. We then set out to evaluate our system without users. We achieved this by performing a cognitive walkthrough and a heuristic evaluation on our new prototype. A cognitive walkthrough is where we list out a set of tasks that should be performed
by the user to complete all the features that we want to test. We then walk through these tasks and report whether each task makes sense and is simple to complete. A heuristic evaluation is similar, except we ask ourselves a few questions: "Does the program use simple and natural dialog? Does it speak the user's language? Does it minimize user memory
load? Is the user interface consistent? Does it provide feedback? Are there clearly marked exits? Are there shortcuts for tasks? Are there good error messages? How do you prevent errors in your program?". If you can trust yourself to be unbiased, you can help save yourself some time with user testing by performing this heuristic evaluation and hopefully
fixing potential future bugs.
My individual report,
our group's presentation on the cognitive walkthrough and heuristic evaluation (.pdf,
.pptx),
and our collaborative medium-fidelity prototype (.pdf,
.pptx)
-
Milestone 4: User Testing.
For this milestone, we were finally ready to test our product with real users from among a random selection of our friends. The users were given a set of tasks and asked to perform them without any help from Pat, Nada, or I.
We recorded their behavior via head-mountedGoProcameras and noted any actions the user took, whether beneficial
or detrimental to the completion of each task. We noted on a User Evaluation Data Sheet
whether the user interface seemed intuitive to the user and what comments the user made as they were performing their set of tasks.
After the tasks were completed, the user was asked to complete a short questionnaire of their user experience. At the end of the survey, it asked the user to write down any comments or suggestions for how to make the game better or more fun and engaging.
Misc. Deliverables:
-
Milestone 5: Overview of project progression.
For this milestone, we were required to create a presentation illustrating the project progression through the iterative milestones. Pat, Nada, and I collaborated to created a presentation viaPrezi. This was our final product
. Once
again, we were able to complete the presentation soley online, although we did have a personal meeting to discuss any last minute changes and fine polishing. This was also essential to making sure we knew what our parts were for the final presentation. This final presentation overviews all of the milestones and outlines each group member's
individual assignments and project participation.
Additional Documents from Game and Mobile Application Development:
What did you learn from the project?
Before developing this project, I never really had a clear understanding of user-centered design principles. I had a pretty good grasp on what it meant to use an iterative design technique. It makes sense to design something thoroughly, test it, and make sure it's flawless before sending out the final product. The problem is that I can develop the "perfect" system that
accounts for every piece of functionality that I think the user desires, but there is no way to know what functionality I am missing without running the user interface through a rigorous scientific process. Cognitive walkthroughs, heuristic evaluations, and peer reviews on the design really helped refine the end product. The user-testing especially opened my eyes to how much
different our views of functionality can be, even among people of similar backgrounds. This is especially true when it comes to games and mobile applications. I think the low and mid-fidelity prototypes really showed me how simply we can create a "working" user interface to show a client and have them critique or agree to a specific design before you even start any
implementation in code.
What are you most proud of?
I'm proud that we were able to come together as a group and design and create a working product by the end of the semester. I think we all had pretty high hopes for what we could accomplish, but we ran out of time to fully implement everything on our low priority list. We ended the semester with a working deliverable with zombies and towers and a money system and I think
that given a few more months, we could create a really great product that would be worthy of the Android app store.
What was your role in completing the project?
Besides the individual and group assignments for the milestones, I developed the initial game logic using Python and used Matplotlib to demonstrate the working zombie-pathing and survivor tower defense. It was designed to be fairly robust for later upgrades and enhancements to the characters such as armor and different weapons and weapon upgrades. We used this initial prototype as
a proof-of-concept in the Game Development class. I attempted to save some time by using the Python game files and Jython to create .Jar files for the Android implementation to no avail. For the remainder of the semester, Pat and I used the pair programming technique to translate the Python code to Java and implement in Android while Nada did extensive work in the graphics department.
What would you do differently next time?
I would probably rush to get a working prototype of the user interface with limited functionality onto the Android platform. Once I was able to create a tower and a zombie, I would work on their ability to interact and create the main gameplay user interface around that interaction. As I tested the product with and without users, I would be able to see where the interface
could evolve and I could enhance playability and the overall user experience.
This project is also found onGitHub