Saturday, July 23, 2011

Wrapping up the Summer Semester

Thanks to those of you who have followed this blog. The Summer semester has ended, and the team produced a digital prototype of the game. This prototype is being transferred to another unit on campus for polishing (mostly visuals) before the public release. Hence this blog will be quiet for some time, but I will be sure to post more news as soon as we have it.

Trial and Error

With more errors than results. This was one of the more frustrating elements, for me, of this entire project. I'm not a real big "Well, give it a try and see if it works" type of guy, I try to have everything planned out before I start whatever it is that i'm starting so that at no point am I lost or have no idea what i'm doing or feel like I have just wasted any amount of my time. I can't help but think about that quote Paul said about how doing something multiple times beforehand allows you to plan better for the future. Well I've never really done anything that occurs within this project at all, so everything was basically flying by the seat of my own pants. I'm pretty sure that every time I found out that I wasn't doing something right or heard "try something else" my little man was wanting to go Network all over the project. But that was the way it had to be, we only had 5 weeks. There was no way I could've gotten all the background experience needed to cut out middle mans or avoid trial and errors throughout this process. It caused me to be more flexible as well as to adapt to the situation at hand. I found myself causing many less errors in the final week than I had towards the beginning of the week. I kind of felt like I was a baby tossed into a pool and expected to learn how to swim. Now i'm not making an allusion to Ron, Paul and Mark having poor parenting skills, actually quite the contrary. The student-based, instead of professor-based, project allowed me to learn more in 5 weeks about a wide range of topics than I could have taking a normal summer session 2 class. As long as we're sticking with the swimming analogy, I kind of feel like we were all just expected to learn how to doggy paddle and then we all came out learning how to breaststroke.

Fears

I recently discovered that this blog got put into my other blogger, so that's cool.

Now that we're a few weeks into the project it almost seems like I don't have any fears at all, rather than the time factor. It's wacky to think that just a few weeks ago this project was rather ambiguous in my mind. I signed up for this project the night before we met on Monday and really had no idea what was going to be happening. I'm not really the type to have a fear for the unknown so it wasn't that big of a deal to me. However, after a few days into the project I realized that my knowledge of history isn't really going to be too useful during this project. I mean, I'm interested in Archaeology and really have no interest in computer science other than enjoying their creations. It was quickly becoming obvious that my knowledge of the archaeology wikipedia as well as the references wasn't really enough to keep me afloat. Lucky for me, i've gone through a couple majors and have been able to relate my past interests to this project. I'm looking forward to gaining more knowledge of the archaeology process as well as maybe a tiny bit of computer science

Friday, July 22, 2011

HCI Patterns

The four Computer Science students working on this project all signed up to receive course credit which would fulfill a major requirement in HCI, or Human Computer Interaction. There hasn't been a major focus within this course to learn HCI standards or practices, but I feel that the four of us walk away from this experience learning quite a lot.

We've learned how to work with C#, the ins and outs of Unity3D software, as well as a lot about Archaeology. We've learned why having realistic goals are vital, and how we should always be willing to throw (bad) ideas out if necessary. When I asked our CS advisor on the project to point me in the right direction for an HCI-related topic he suggested I look into affordance and how it relates to HCI. A few googles later, I've got an understanding of what HCI is. The interesting thing is that the lot of us were keeping HCI in our minds, subconsciously, while we developed.

Wikipedia lists the principles of user interface design here. It's surprising how many of these concepts that we followed (either instinctively or with some slight prodding via our advisors). We stayed consistent with our layouts and functionality. The team also tried to maintain a simple UI design, while being flexible with user inputs.

Yesterday, for example, I instinctively began reworking an OK box/button.  It was designed to pop up based on the location of the mouse. I spent a bit of time getting this button to have a maximum X and Y coordinate, so that if the user did click at the edge of the screen then the resulting button wouldn't be hanging in limbo, off the side of the screen. I didn't realize it, but I was trying to be tolerant in my implementation. There are likely better examples from the past 5 weeks, but this one is off the top of my head.

I haven't done extensive reading over HCI, so this intuition came from two places. The first was my experience programming and designing past projects. The other source:  my experience (and frustration) with games and interactive software doing this poorly. Nothing is more frustrating than when a game keeps you from its fun parts accidentally.

HCI is deeper than I've shown in this post, but I feel that we did a respectable job of keeping it in mind while developing over the last five weeks, even if it was accidental success. To improve on things in the future, I should be more aware of HCI principles when I am developing. The crux is that on such a short development cycle, it's hard to do more than develop, test, and immediately develop again, repeating for the necessary amount of time. I'm proud of what we were able to achieve in 5 (very quick!) weeks, and I would encourage everyone to take part in at least one project of this caliber in their scholastic career.

Thursday, July 21, 2011

HCI and our Project

One of the biggest things about HCI and a project you've worked on since its conception is that it's hard to see its shortcomings along the way. For instance, if I make a button with a vague label, it's all to clear to me what it means because I put it there, I told it what to do--so of course I know what that label is supposed to mean. That's when it's helpful for someone else to come along and take a fresh look at a project and get user feedback. Of course, we didn't have that along the way, so we don't really know how hard our UI is to interpret.

That being said, I think we've done a good job making a clean looking UI. The Navigation buttons remain constant throughout the game. It's good to have them anchored. Having the interpretations pop up in the same place whenever they're updated is also good design. Consistency is good for a good GUI. Whenever a window pops up with artifact information, it's presented in the same manner. This consistency makes it look polished. Regardless of whether or not the behind the scenes stuff is done well (or finished, in this case), the look and feel can give a positive impression of the project.

One of the things we've worked on with this project that, in my beliefs, fall under HCI is how we're working on this game for a specific audience. It's definitely constrained/molded what we've developed. It's not everyday you make a video game for fourth graders, but this is now the third semester I've worked on such a product. I'm in no way an expert on fourth graders, but I feel like I can develop better under such a mindset because this is what we've been working on. We have to consider what they'll understand, what they'll want to see, what can keep them captivated while still having them learn something. It's definitely changed some of the text we put into the game. Fourth graders definitely don't have the same vocabulary we do.

I guess that's the biggest thing I've learned--that you have to know your audience. You can't design past their comprehension level.

Human-Computer Interaction

Working on this project reinforced something I have been slowly learning throughout my CS courses: how a program looks does matter.

I don't mean that fancy graphics or animations can make up for bad software design. What I do mean is that lack of planning with regards to the design and layout of a program can detract from an otherwise good program. This idea is nothing new, and is certainly not limited to computers, but has been pointed out to me many times in this project.

One specific example: Today I was playing through the game, looking for anything that needed to be fixed. After playing portions of the game numerous times I became annoyed with one of the features - when analyzing an artifact, the interpretation pane pops up and covers one of the classification buttons. While this didn't affect the gameplay (you could click through the box if you really wanted to) it was rather distracting and made it hard to tell what button was underneath.

I mentioned this problem to David, who immediately began messing around with the code trying to fix the issue. In a few minutes he had rearranged the buttons on the screen so they were no longer covered up by the interpretation panel. Just this small change made the game seem that much more put together. A few minutes playing with the design made the analysis screen look much less cluttered, and much less hectic. I don't know if David's new layout is the best option, but it is an improvement. This small example reminded me of how important the layout of a screen can be. While I know there is more to HCI than just where buttons are placed on a screen, I think this is a good concept to understand.

Unity

When the technical team sat down to discuss which programming language/engine would work best for us, I had already had my mind set on Unity. I didn't really know much about it, but from the little bit I had played around with, I was really excited to continue learning about it. Now that we are in our final week, I am looking back at the past few weeks, specifically at our use with Unity, and I feel like we all grew as programmers and picked up on Unity quite well. The game, however, may have been looking a little more complete at this point if we went with an easier(for us) language. Though Unity has been very helpful in some places, the tools it offers were probably a little overkill for the design we had for the game. I do not regret using unity, I just wonder if maybe some of our time could have been spent developing instead of learning to use the Unity game engine.