Introduction:

This week we had a special sprint, sprint 4, which is the exchange projects sprint. It’s a short sprint, just one week, and we exchange projects to design, document and implement an achievement system for the other team’s game. I’ll also comment a bit on contribution.

The Sprint:

In sprint 4, we passed our project to the other team and they passed theirs to us. Next we designed an achievement system and implemented said system into their game. This was a great sprint, especially for me. Dustin and Rachel had some other obligations that they needed to catch up on, so we mentally prepared a bit for their leave, which worked out just fine. In previous sprints they had definitely put in a substantial amount of work.

A quick over-view of how sprint 4 went, I worked on the design and documented it. Then I began implementing that design. After the vast majority was done, roughly 90-ish percent, I ran into some barriers. I met Nate and got some insider information about how Unity thinks and works, which sped up resolving the issues I had, and I finished the first version of the achievement system. Afterwords, Nate sat down with the code and knew some different points where some optimization could be done, primarily from his deep understanding of the Unity game engine, and added those.

The above set of tasks went off well without much issue or problem. Despite our professor’s saying, “everyone else writes horrible code”, I found their code to be well written and well organized. Their project made a lot of sense and I learned a couple of nice ideas and tricks that I should use in the future, more on that below.

The Design:

So Friday I designed their project, complete with requirements, class diagrams and sequence diagrams. Saturday I wrote up the testing document and finished creating the diagrams and compiling the documentation. Sunday I implemented the first version. I ran into two problems, which was how to display images on screen, and how to play sound. I like the fact that I didn’t bang my head on the wall for too long to get it to work, but instead just asked for help. It’s an important skill to know when you should request assistance and when you should figure it out on your own. I knew the other folks on the team were more familiar with Unity and I shouldn’t spend too much time figuring out how to get Unity to do the thing I needed.

One issue that I ran into, was that I thought a bit too much in programming languages and not enough with the Unity engine in mind. One example is I wanted to instantiate the achievement class via a constructor, rather than calling the start function, which is what Unity apparently prefers. Also I wanted to programmatically load the achievement images and achievement sound into the game, rather than making the variables public and accessing them through the Unity inspector, another point that the Unity engine prefers. These are two places where Nate’s expertise and familiarity with Unity really came in handy.

Nate, later added some better art and optimized a few things, taking advantage of what Unity provides rather than what can be done through C#. The biggest change I think was altering the system to allow for dynamic additions of achievements to the game. My initial solution, for development-speed purposes, was to use a simple array of set size. This was later replaced with an ArrayList or similar data-structure, which is certainly a more appropriate solution.

For really interested readers here is the documentation we put together:

[Design Doc – pdf]

The Main Difference:

There were a few major architectural differences between our projects and they are interesting to consider.

In their project, for some prefab they have a number of components, namely scripts, added to a single prefab. So if they want to have a creature have health in their game, they have a health script, which is like 20 lines of code. Any prefab that needs health, gets that game component (script). For each animation there is an animation script. If the creature has different attacks, each attack is a different script. It’s a smart way to implement those aspects into their game and allows for a lot of code re-usability.

In our code it’s a slightly different paradigm. We treat each prefab as a separate class, rather than each script, and then make a single script for managing that class/prefab. Where as they treat each script as a different class and add a number of scripts to a single prefab.

I don’t think either one of us designed the wrong solution, but actually each approach is appropriate for the project we are developing. It makes for a very good case study, to review each of these two different design paradigms. In class we spent some time trying to consider how our project could be written with their architecture, and the reverse, but it was difficult to imagine and certainly didn’t feel natural. Thus, it is interesting to see how different our two approaches are, yet how correct both are at solving the problem they should.

Team Contributions:

A quick note on contribution, overall, I think this team has worked out well since sprint-3, or whenever it was we paused, took a deep breath and re-structured a bit our work-flow. In general I think the team contributions have been balanced pretty equally. I really appreciate the solid effort by all of the members of the team. Some roles we’ve assigned, and others have been adopted as the need and skills have called for them. I truly feel each person has done their best to complete the work they can, given their schedules, abilities and their other obligations. Despite some of the inter-personal issues we may have faced early on in the semester I really appreciate and respect the other members of this team, it’s no surprise they have been recognized as solid producers and recruited into research laboratories.

Conclusions:

The final sprint, final three weeks and finals are upon us. Stay tuned as we finally polish up some different items and really start to publish some quality content from the game.

Thanks for reading.