Archaeology Simulation Assessment

The end of this past week saw the Digital Archaeology Project reach it's scheduled ending date. The team worked for 5 weeks on developing a digital, educational experience that was appropriate for a 4th grade level of student. This post will focus on the positives and negatives of the project.

Background On the Project
The team on this project consisted of eight students, four CS students and four Anthropology/History students, as well as three faculty advisors. The focus of the project was to create an experience that accurately depicted the archaeology process. The player would discover an artifact through digging, categorize the artifact, explore the house for more artifacts, research their findings in the library, all the while opening up interpretations. Their findings and research allowed them to make claims about the people who inhabited the land.

Our goals were pretty lofty considering that we had zero starting out. Knowing this, our advisors realized that we wouldn't be able to give the game the polish it would need. Therefore, our team of eight students would be in charge of the game design and initial development of the software. We wouldn't put the polishing touches on it, but we would have the game working completely by the end of our project. Then we would hand our product off to another on-campus organization to polish it up and prettify it.

Results
At the end of our 5 week period, we have a game. It's very, very raw, but it is a game. The data is there, the game flow is there. It's just ugly. It's all programmer and placeholder art, which is notoriously hideous, but it did it's job.

We didn't have to change our goals to meet our production rate, which is good. However, our goals were very, very aggressive - perhaps too aggressive. We weren't in a place where we could playtest a prototype with actual 4th graders, so we're carrying quite a bit of risk still. I say 'still' because the game can still be changed, once what's there is beautified. There are plans to playtest it and tweak what needs to be tweaked.



In the vein of SCRUM, I'll lay out areas that were successful and those that needed more work.

Positives

• Diverse team 
•  we had a very diverse team, but we were able to find a group identity and work well together.
• SCRUM 
• we used what I would call SCRUM lite, but the parts of it that we did use worked well. The group took to it quickly.
• New technology
• the tech team (the CS students) picked up C# and Unity3D quickly. It was fun to work with new software.
• Built off of past success
• Speaking from a tech team perspective, the Morgan's Raid experience was helpful in this project.
• Empowered team
• the faculty advisors did a good job of directing us initially, but by the end, the students were making the decisions, even the big ones

Negatives

• Pressure of lofty of goals
• while we were successful, had our goals been smaller we could've polished the game mechanics more
• Feelings of being unfulfilled
• handing off a project to someone else to finish isn't enjoyable. You get protective of a project and to see it go before it's done is a little saddening, even if it's necessary.
• Empowered team 
• having the students making the big decisions led to moments where the decision took longer than it might've, had an advisor just dictated what to do.
• Short deadlines
• having such a short timeframe for a big project led to some software debt. At the time, it made more sense to keep implementing new features instead of refactoring. Also, our Product Owners didn't dictate that they wanted code refactored, so I'm not sure who should've spoken up. 

Conclusions
After everything is said and done, the project was a success. We set out to create something educational while still being accurate and we did that. Things weren't perfect, but I feel that we (the four CS students and two of the advisors who have worked together before) are perfecting our process.

I'm glad to have taken part in the project and I would encourage others to look for similar Immersive Learning opportunities. While these projects are great learning opportunities, one problem with Immersive Learning is that not every major supports it as well as they could. I know that art students in particular have trouble finding room in their schedules to accommodate it. If I were on a tighter schedule I may not have had time for this project.

I'll use this experience, and the Morgan's Raid experience, to make the most of this Spring, where I'll be working on a project at the  Virginia Ball Center. I'm really excited about this opportunity, and I'm sure I'll blog about it in the coming months. I'm not entirely done with the Archaeology Project, as I'll likely be doing some additional development on it in the next few weeks, but I'm proud of what we were able to accomplish.

Blog Update

I noticed a few weeks back that whenever I previewed my blog things tended to lag out a bit. Scrolling up or down was very slow. Other Blogger blogs that I follow didn't, so I figured it was my background choice.

Recently I changed the background color to a solid orange. I don't really have a favorite color, but orange is one that I tend to pick when pressured. This change of backgrounds seems to have fixed it, so I'm happy.

As I was working on switching the background color, I noticed I had 4 or 5 blog posts started and saved in the backend. I'm planning on going through them and knocking out a few ideas that have been floating around my head. I started the posts and titled them as a reminder, but I've been too busy to do anything with them. The Digital Archaeology Project I've been working on for the past 5 weeks came to an end this week, so I have plans to write a summary about the experience while the memories are still fresh. I learned quite a bit so I'm excited to try to form some conclusions about how things shook out.

Unity3D So Far

We're about a week and a half away from our scheduled finish date for the Digital Archaeology Project. It's a little unnerving, but I'm not too worried.

The technical team decided to work with the Unity Game Development Tool, and so far it's pretty cool, albeit a bit overwhelming. It reminds me of Adobe Photoshop, but my past experience with entity systems and components has definitely helped.

I'm especially thankful for a nice, well thought out API site that Unity has implemented. It comes with code examples for all 3 of the supported scripting languages ("JavaScript", C#, and Boo).

Unity has many features, and a ton of preloaded components to add to your game objects. It's shockingly simple to create a physics-enabled environment. The power of Unity comes in the in the ability to run the game and modify values real-time. It makes tweaking things like the UI a cinch, allowing the developer to get back to doing things that are more deserving of their attention.

I'm at a near impasse at the moment, so I decided to write about my experience with Unity so far. Working with it has been challenging, as I had a few initial tasks not related to Unity or programming. The other three CS students on the project got a bit of a head start over me, so they're a little more comfortable with C# and Unity than I am. Note: my programming experience has been almost completely isolated to Java. I've done a few projects in C#, LISP, and Prolog. I've taken to C# fairly quickly, as it is pretty close to Java.

As I mentioned, Unity uses components pretty heavily. I've looked back to the Morgan's Raid source code a bit to get a comparable idea of what things are trying to do in Unity, which has been pretty helpful. Some of my difficulties now remind me of last fall, when the Morgan's Raid source hierarchy was, to put it bluntly, a mess. It's hard to get my bearings when the folders are such a mess. In the next week and a half we'll have to clear up the Digital Archaeology source hierarchy (among other things) as we prepare to hand the core game off to another university group to polish and apply the visuals. A lot remains to be done, but Unity affords us the biggest chance to succeed. I am glad that we chose to work with it, and I'm happy the developer license will be mine (hopefully) to explore with over the next several months.

This is a bit premature for a review of Unity, so take it as more of a preview. I'll try to sum up my thoughts on Unity as well as the Digital Archaeology Project in a future post.

Searching for Other Options

A few quick emails yesterday afternoon all but nixed using JavaFX. Apparently it doesn't work at all with Mac, and our project is attempting to be cross-platform friendly from the beginning .

For our Digital Archaeology Project, we had a few ideas as to what software to use to design it:

• Swing
• GWT
• JavaFX
• Unity3D
• Slick

Swing was quickly eliminated, as there are more powerful options in the list. Slick is what was used for the Morgan's Raid project, so we all are very familiar with it. However, it doesn't have a good solution for creating buttons and a custom interface. Those things would need to be done by hand,which is possible but difficult. So that left us with GWT, JavaFX, and Unity3D. The latter option is a 3D game engine that has some really approachable tools. The downfall is that these tools cost money and aren't very recreate-able without going in and typing things in by hand. In other words, it can't be used in other instances programmaticly, other archaeology sites would need to be redone by hand.

So with Swing and JavaFX out, the team is focusing on GWT and Unity3D this weekend. We know what Slick can do, but the other two options are relative unknowns. I have GWT all set up on my machine here at home and a free afternoon ahead of me!

Digital Archaeology Project & JavaFX: First Impressions

For the Digital Archaeology Project I am working on, the Computer Science students in the group were given the weekend task of tinkering with JavaFX. So far, things are going well!

JavaFX was described to me as a language that allows us to do some interesting animation and visual effects, all while allowing us to build off of our knowledge with Java. It seems pretty robust, but I've only looked at a few code examples. Getting it going with Eclipse was fairly simple. I followed this tutorial Oracle JavaFX Tutorial and was able to work along side it very easily.

I have some plans outside of staring at a computer monitor tonight, or else I would continue on with these tutorials, but that is where I plan to get back into it tomorrow.

I haven't mentioned it in this space, but I am working with a few other students and professors on developing a digital archaeology simulation (a game) for 4th graders. I wrote a quick summary of our work so far, which can be found here. I'm not sure how to use this space in conjunction with a class-wide, shared blog. I'd like to keep working in this realm, as it's easier to wrap all of my thoughts up onto one page. I could also post to both spaces simultaneously.

I like the progress that was made today. I feel for the non-Computer Science students with the prototyping that we've done this week. They've done a great job so far, but the process can be frustrating initially. Those of us who were around for Morgan's Raid last fall were subjected to our fair share of prototyping, and, as Dr. Gestwicki would and does say, you do it so you can throw ideas out. It really saves you time later. Looking back, I wish we had done a bit more prototyping in Morgan's Raid at times, but with this project I think the Anthropology students are getting a good experience. One of them mentioned in a reflective post that they didn't think they would be doing so much design - that they enjoyed getting to take part in it. I'm glad they will have the opportunity to give a lot of feedback. CS people tend to be min/maxers, power users, so we might be more interested in the numbers side of things. A fresh perspective could really be huge for keeping the game fun on a surface level (I made an archaeology joke!).