Extendable Implementation and Parallelization of Turn Processing
in an Online Strategy Game Using MASS Project Overview
Stuart Drummond
10/11/2014
1. Sponsoring Organization/Project
 PDMFC
o PDMFC is the organization that created the original implementation of Almansur.
I will be in contact with one of the members at PDMFC in case I have questions
regarding the original implementation of the software in question.
 Distributed Systems Lab
o Distributed Systems Lab is the research group run by Dr. Fukuda at University of
Washington Bothell. This research group is responsible for updating and
maintaining the MASS library.
2. Faculty Advisor
Munehiro Fukuda
3. Responsibility Matrix
 Stuart Drummond
o Primary developer and researcher
 Munehiro Fukuda
o Stakeholder, project advisor and technical expert on MASS library
 Luis Landeiro Ribeiro
o Correspondence at PDMFC, technical expert on Almansur
4. Project Scope and Student Learning Goals
One of the most important and obvious motivations of utilizing parallelization technologies
is performance gains. As I’ve learned in Dr. Fukuda’s CSS 534 class, it is important to get both
the correct result as well as gaining a significant level of increase in performance to make the
time spent parallelizing worth the effort. The focus of this research project in regards to
performance is the comparisons in the following way:
 To compare the differences in performance between the original Ruby implementation of
Almansur and the MASS-optimized version of Almansur written in Java.
o Comparison between sequential and parallelized versions
The target of parallelization in this project is the turn processing. The thesis paper given by
the developers at the beginning of the project explained the progress that occurred from
Almansur 1.0 to 2.0. In this paper, PDMFC identified three different points that were noticeable
bottlenecks for Almansur. Two of the bottlenecks, which were scenario cloning and scenario
importing, were slightly improved in performance on version 2.0 on the larger scenarios. In
general, these two functionalities have been considered “fast enough” and not really worth
parallelizing considering they are often bound by the speed of the network and database in the
original version. However, due to the advancement in the logic used in various agent classes in
the new iteration, it has become far more costly to process turns in version 2.0. This is far more
noticeable in in the results of larger scenarios in the benchmarking test that the developers
conducted.
Performance/benchmarking tests, especially when it comes to game applications, often
involves using the worst case scenario as the point of comparison between different versions,
patches, platforms, etc. Most of the heavy computation in Almansur, as I mentioned in the
previous paragraph, occurs at the turn processing. Because this is a turn-based strategy game, all
players will be waiting to sync with other players while they complete their turn (similar to
barrier synchronization). Due to this, a test program that tests the amount of time it took to
process the turn can be used a point of comparison between the various versions of Almansur.
By mixing various types of scenarios with different levels of territories, agents, and players, this
will allow us to do complex performance analyses to truly test how much better the results of
using the MASS library can be. The scenarios that will be used in the results will match set of
scenarios that are being used by a student that is implementing Almansur in Go at PDMFC. This
is in order to facilitate accurate comparison in any future publications between the three
implementations. The resulting data will explore the following cases:
 Smallest scenario
 Medium sized scenario
 Largest scenario
 The scenario with the biggest level of improvement
The original plan to use Jruby in order to facilitate interoperability between Almansur source
code and MASS did not succeed due to constraints on both software. Almansur, utilizing the
ActiveRecord ORM that is provided in Ruby, stores in-game object in a MySQL database. This
notion is facilitated by the developer’s insistence on the importance of utilizing caches in turn
processing. However, because the distributed array in MASS must remain in memory, it is not
possible for Places and Agents to exist on the database. This also require the current
implementation to have a method of importing scenarios, saved as numerous .csv files, into Java
MASS.
The decision to use the Java version instead of the C++ version is to facilitate the first of the
two additional requirements of the project on top of performance. One of these requirements is
evolvability. Because this project simply building the foundation of MASS-optimized Almansur
by implementing turn processing and scenario import, future graduate students that are interested
in Almansur can add additional functionalities such as scenario cloning, web deployment, GUI,
etc. As I’ve found out early in CSS 595, Java is much more useable in web development, with a
plethora of available and well documented web frameworks, than C++ is. In addition, the second
requirement for the project is maintainability. Because future students will also have to interact
with the original version of Almansur, they may struggle as much as I did on understanding and
using Ruby. This is a reasonable assumption as Ruby is not readily taught in most CSS courses at
UW Bothell outside of courses on scripting languages. In order to mitigate the amount of
potential issues and risk that the student may encounter, I will be constructing a manual that
details the way both the Java and the Ruby versions are run. This manual will loop back to
support evolvability by allowing future students to build upon the detailed documentation that
will be contained in the document.
Finally, when it comes to the student learning goals, this project encompasses the three foci I
was interested in when I began this program at UW Bothell:
 Game development: I wanted the focus of my project to be something related to the
development of a video game. While I will not be able to fulfill my initial goal of
developing a complex system in C++, I feel that I will learn more with the project scope
being bigger than what was originally planned using C++ MASS.
 Distributed computing: ArenaNet LLC in Bellevue, WA opened up my interest in
working on distributed systems with their focus on large scale MMO (Massivelymultiplayer) games using distributed technologies. Because Almansur is an online game
that can also be played between live players, I will be able to learning about distributed
application architectures.
 Parallel computing: The Java version of the MASS parallelization library, which was
recently refactored, is the focus of this project. I’ve had the opportunity the last two
quarters to learn more about this custom parallelization library as a part of Dr. Fukuda’s
research group. I find the entire topic of parallel computing to be both rewarding and
challenging and wanted to incorporate it as a part of my graduate project.
5. Proposed Product Activity Grid and Deliverables
 Project Management/Communications
o Stakeholder Communication Strategy
 Weekly meetings with stakeholder/project advisor and discuss current
progress and upcoming goals. Topics covered in each meeting will be
turned in as a deliverable to showcase the gradual steps in which the
project was completed.
 Artifact: Risk analysis documentation.
o Requirements Analysis
 Determine which portion of the code must be parallelized for the purpose
of this assignment. Because it is not feasible to create the entirety of
Almansur within the six months I have to complete this project, I will be
contacting Luis to discuss what portions should be left out for this
implementation.
 Artifact: Requirements analysis documentation.
 Technical Approach
o Architectures used in web development
 Establish baseline understanding of the two governing architecture
 MVC
 Client/Server
 Artifact: Literature review document.
o Databases
 Understand some basic database operations using MySQL (used for the
original implementation)
 Artifact: Setup and modify databases by importing necessary
scenarios to the test the Ruby version of Almansur.
o Web Game Development
 Literature search on web game development
 Artifact: Literature review document.
o Ruby Language
 Learn the syntax of Ruby
 Artifact: Completion screen of Ruby tutorial on codeacademy.com
o Game parallelization strategies
 How are games optimized/parallelized? I will be focusing specifically on
literature that features web game projects.
 Artifact: Literature review document.

Testing Strategy/Results
o Unit/Integration testing
 Make sure that individual components work properly. Specifically should
focus on the Places and Agents that are used within the MASS library.
 Artifact: JUnit unit testing code
o Performance testing/Benchmarking
 Embed a timer class in the MASS-optimized version and calculate the
length of time it takes to complete the operation
 Artifact: Testing document that details the way it was tested /
literature review document.
o Almansur Manual
 In order to decrease the risks and challenges of future students using
Almansur, a documentation manual on both running the code for the Java
version and the Ruby version will be documented.
 Artifact: Almansur Extension Manual

Looking Back
o Monthly reflection
 This will be used as a way to detail what was done, what needs to be done
and specific tasks that are urgent/behind schedule.
 Artifact: Monthly reflection reports
6. Quality management/assurance process plan
As described above, the code artifacts on this project will have appropriate unit and
integration testing modules that will be used for quality assurance. For development and QA, it
will begin with testing the two core classes, Places and Agents, prior to developing and testing
various module classes that is required for turn processing.
On top of this, all artifact documentation must be checked off and approved by the
advisor. Because these are integral parts of the project that affect the development of the entire
software system, it has to be approved and adhered to during development. Finally, code reviews
will be done on the key components of code in this project. Feedback and suggestions given in
the code review, if applicable, will be reflected in the other modules as well.
9. Detailed Resource Requirements
Task
Read and analyze the research
documentations of Almansur written by Dr.
Fukuda in 2008
Literature Search (web framework, web game
development, game parallelization)
Familiarization with Java MASS library
Familiarization with Ruby web programming
language
Write requirements documentation
Implement Event Manager class
Implement Places and Agents class prototypes
Setup Maven, MASS and other libraries in
IntelliJ IDEA IDE
Implement Places and Agents full version
Implement other classes
Conduct performance testing
Meet with advisor and compile weekly
discussion documents
Write technical write paper for final
submission
Write Almansur Extension Manual
Target Period
June 2014
June-July 2014
July 2014
July 2014
July 2014
August 2014
August 2014
August 2014
October 2014
October 2014-Early November 2014
November 2014
On-going
On-going
On-going
10. Architecture Diagram