My Plans are Foiled: Goo Balls, Weeks 1 and 2

Last time I spoke about toning down the scrum process; making it simpler and easier and not worrying about the process as much. As it turns out, that's not really possible this prototype. Surprise! This time, we're working with another producer and joining teams of nine to ten. In my case, the team has three producers (and therefore ten people). So the idea of using post-it notes and letting people communicate directly (either through email or in person) doesn't work as well. However, I have been prepping for this moment all semester, whether I knew it or not, with my overly complicated and under-utilized scrum spreadsheets! Speaking of, here's my newest iteration (click on the screen shot to view the actual spreadsheet):

I changed a few things up this time, throwing the spreadsheet more in-line with the actual scrum process. First off, I decided to stop breaking down tasks twice, from the release backlog to the tasks tab. Previously, I would break down the task into smaller pieces and then take the small pieces and throw estimates on them and assign people to them in the sprint tab itself. This was a little confusing to people who just wanted to see what tasks we had remaining in the project and grab something. Now I break all the tasks up in the Tasks tab and assign values, priorities, etc. I've also learned that Google spreadsheets allow data validation, so now people can pick a name or a sprint number from a list instead of typing it in themselves (anything to ease the process). So far the spreadsheet is really nice, but people seem very reluctant to actually use it. Today I'm trying again, now that the game design and direction has been worked out a little better, and hopefully I'll get better results.

All this process and you don't even know what the game is yet. For this last prototype, we have no client and not much direction. Here's what we have:

• Unity for development
• Game Jam/Indie game (no AAA tropes)
• Working in larger groups
• Producers can't design

So that's easy right? Engineers and artists have to do all of the design (and their normal duties), and producers do all of the process. Now you can see why I spent so much time working on my scrum doc, as I have taken the mantle of scrum master on the team. To be honest, it's been a little tough to keep busy with the way the engineers have wanted to design. There's been a lot of experimentation on their part, which scared me at first, but I trusted them to do their part and we've had a lot of success.

So what do we have? Our first day we had a great brainstorming session. We wrote down a bunch of ideas, figured out an interesting way to combine many of them, and then had everyone work on a sample idea or level that night. We met up the next day and pooled our collective ideas to make sure that everyone was on the same page, or if they weren't, what idea they had that led them in that direction. As a producer, my main goal early on is to get everyone personally invested in the project. The best way I've found to allow this to happen is to try to incorporate everyone's ideas, even if it's just a really small part of an idea or a slight twist on someone's idea. Oddly enough, this usually turns out the best games. With so many people bouncing ideas back and forth, and working through ideas together, my groups tend to get pretty interesting designs, and everyone is happy with at least a part of the concept. So our process this time involved a lot of brainstorming since there were so many people working on the project. After we somewhat cemented the idea, the engineers wanted to go make something in Unity. We decided that everyone would create something they thought would be interesting and bring it to our next meeting on Saturday. This worked out pretty well, and as of Saturday, we put down in writing exactly what everyone's tasks were, and what needed to be done. We mainly use our Google group to communicate all of this compiled information to the team, and we also have a wiki we're using.

During this process, the team felt to me like a real indie studio. We have lots of engineers, a couple people to run the process and make some decisions, and an artist (which we could probably use more of). The design was open-ended enough that people could etch out a niche for something they enjoyed, whether it was making a collection of tiny balls into a goo-like substance or designing an interesting trap for our game or laying out a level with a great flow. It was a great collaborative process that turned out a very interesting game.

However, all of that creativity and exploration has to have a downside right? For us, it's time. We have too many ideas and not enough time to implement all of what we want. So at some point, the producers (and the engineers to an extent as well) had to say, "Look, this is all great, but we have two weeks and no completely working builds yet." We're getting there now though. Unfortunately Unity as some terrible version control issues that have been a problem. We spent a great deal of time merging code together. It does feel that as we're learning how to wrangle Unity and a team of this size, the project (and the semester) is ending. That's probably the point of this exercise. The semester ends on a similar note to how it began: lots of confusion and figuring out things just as you stop working on it.

Next week: the end of a prototype and a semester, dealing with one less week.

Final Weeks, Prototype Done, Success

The final two weeks for our third prototype have come and gone, so fast that I forgot to update last week. To answer the cliffhanger from two weeks ago: yes, the playtest was very successful. We could have done more of course. We playtested among our team and came up with a great number of things we liked and didn't, but we could have had some other teams come over and playtest as well. However, that may have given us too many things to do in that final week. We ended up with a number of changes anyway and those kept us busy through the final pitch.

What we discovered in our playtest is that our initial design didn't take into consideration the feedback given to the player and how that affected the dramatic dynamics of the game. If the alignments of the choices weren't made clear to the player after the choice was made, she couldn't understand why her robot was getting nicer or meaner. We ended up adding a lot of user interface elements to make sure the player knew what was happening and how to deal with it. With the encourage and discourage mechanic specifically, we discovered that we needed to display the alignments and push the time the player had to encourage or discourage the robot's actions. This created a really great dramatic tension that drove the gameplay. This worked so well that if we had the time, or were working on this more outside of class, we would seriously consider removing the player's ability to assume direct control of the robot at all. That gameplay loop of letting the robot guess and then encouraging or discouraging to program your robot was very engaging and entertaining, while just selecting answers for the robot was fairly mundane. It felt like just selecting answers would be okay if there was a high level of polish, but the core mechanic itself wasn't very exciting.

After the third week we came back with a dry run and a few things to fix before Wednesday. We ran into some ridiculous tech issues that prevented our gameplay demo from functioning in our dry run. All of the presentations went really long, excluding ours since the gameplay demo was our main attraction, so by the time we pitched again everyone was ready to leave class and we received very little feedback. This made me a bit nervous going into the actual pitch on Wednesday. For the rest of the day the class was taken over by other miscellaneous business regarding degrees and Ubisoft competitions and whatnot so we didn't get much done. On the next day, we figured out what tasks were needed to make sure we had everything perfect (as possible) for Wednesday's pitch. Luckily, even with the crazy schedule and our gameplay demo issues, we were able to get everything ready for the final pitch to the client without a hitch. As a producer I focus on having playable things done, even if the first week is just an avatar walking around, so that attitude helped a lot in regards to always having something to show, even if it's not the final build. Fortunately our final build worked great for the presentation. Speaking of our final presentation, here it is:

And since the gameplay demo is not present in the actual presentation, here is the gameplay demo/trailer (although if you click on the picture in the Gameplay Demo slide in the presentation you will discover it is a link to the below YouTube video, which was my backup backup plan)

The presentation itself went well (I'll find out more tomorrow night in class when we go over all of the presentations). However, I don't think the client was entirely impressed with our game. They were taken by another game that is very clever and interesting (and shall remain nameless). It was a great idea for a great game. For what it's worth, our team was entirely behind our idea. We feel this game excels in places some of the others falter. For instance, we have actual conversations with real facial expressions encompassed in real life situations where these might occur. I'm not entirely sure the other prototypes hit those marks, and my team is really proud of what we accomplished in that regard. I also think the robot AI is a pretty clever way of learning through teaching in a way that isn't just giving the player lessons to tell the robot. To be honest though, my team focused on the process of coming up with a design, using physical prototypes early, moving on to digital prototypes, and then finally iterating a ton. As a team, we did an excellent job following through with our goals for this prototype, and I think everyone on the team is better for it. So we may not have won the hearts and minds of our clients, but we're all better prepared for what's coming up next in our careers, both in class and outside of it.

Well that's a lot of text, so let's break that up even more with a picture. Here's the picture of our postmortem whiteboard:

This time the sticky notes don't make a great curve or anything, but the process was very helpful. I was surprised to hear that some of my teammates hadn't really done an in-depth postmortem in their other groups, so this was a little new to them. So what did we learn?

First off, scrum was kind of a bust. And I agree. It was organized, always available, and had plenty of tasks with estimates which were all color-coded for priority and type of task. And it was completely unnecessary, or at least that's what everyone was feeling. At this point, the scrum process is just too much unnecessary headache for four people. The process is great to follow so that way next semester we can organize having had some experience in agile development. But try as a I might, scrum is too much for these prototypes. For my next group, I'm planning on just using sticky notes and doing it all manually. At this point, instead of refining my Google spreadsheet, I would be better served to just use a scrum program designed for this stuff. But that would be way too much process for four people. So I'm actually scaling it back, and we'll see how that works.

After the issues with scrum though, everyone was really pleased with how it turned out. I chided myself for not having the conversations in on time, but most everything else were either really good things, or things that maybe weren't great but we know how we would fix them for next time. And that's what's important: learning from the postmortem process and figuring out what to do better next time.

The major concern everyone had, and as the prototype process has continued to be refined by everyone in the class this has come up a few places, was the lack of an actual design document. Previously my groups didn't ever need one. We communicated so well and the projects were so well scoped that everyone knew what was needed from them, especially with the scrum document to back it all up. During this prototype, we basically took notes and used pictures for our design document, combined with the scrum spreadsheet of course. However, the entire team, myself included, expressed a desire to use a design document next time. Combined with the idea that I'll be scaling back the scrum spreadsheet to sticky notes, this seems like the perfect time to start a design document for our next prototype. I have a couple of avenues I'm looking down in regards to how to set this up and what to actually use, but I haven't decided on one yet. Tomorrow I'll discuss with my new team what they think will fit them best, and we'll go from there.

See you next time.

A new project, a new approach, a new outcome (?)

The first couple weeks have come and gone, and my new group has been hammering away. First off, my new teammates are:

• Sherly Yunita
• Cody Hansen
• Saurabh Pendse

The game idea pitched to us was that of a game to help autistic youths learn conversation patterns and social queues. A few ideas were tossed around, but we initially decided on a conversation game, such as Phoenix Wright or the conversation portions of Mass Effect. However, after some thought and deliberation, we brainstormed some more and came up with a rudimentary AI that the player would "program" through answering and correcting the AI's answers. Here is the initial pitch (this time with slideshare and not a YouTube video):

So why is this project different? Well, to start we used a physical prototype very early to figure out some of the more basic design issues. I cannot stress enough how helpful this process was. The group sat down in front of a white board, drew the game UI and we all walked through different game scenarios we were expecting to perform in the digital prototype. We did this during our second class as a group, and it helped to suss out so many issues we would have encountered very early into the digital prototype. Since we did this, we could get to the issue of "fun" in the prototype more quickly and more easily. Afterwards, we made up a scrum document (in google docs/drive again), and that can be seen here (click on the picture to check out the scrum doc):

The scrum didn't change a whole lot from the last group, but we did decide on a few things. First, we added a priority to each task. We also made tasks that were a little larger, so all of those one hour tasks that actually took 20 minutes would be weeded out. The biggest change was to make sprints for just two weeks, and to not actually create the second sprint until the first was over. This was mostly due to the plan of having and playing the digital prototype after our first week.

The entire idea of this new approach was to actually prototype multiple times and adjust the game until we hit on something that was fun. Most of us in this projects class, myself and my teams included, didn't actually get to prototype. We made cool, vertical slices of games that looked pretty and sold well to a potential client. And that was a good experience. But to be honest with myself, I love designing and I want to prototype. And I think a lot of other students have the same feeling. This time we're doing it differently. We made the plan to have a digital prototype done by the third Monday in the cycle, and we got it done. More on that playtest (and if it worked) next time.

Kinect Gardening Conclusion...or is it?

This week capped off the second prototype for the class and a great four week run. To get things started, here's the gameplay video for Kinect Gardening:

The prototype turned out great, and we barely had to cut any features (really just calibrating, somewhat unnecessary for the prototype). In fact, we even had time to add an additional feature, the gopher, at the end. All in all, things went smoothly throughout. The one minor set back towards the end was having to create a trailer and a presentation without the final art. Unfortunately, it just got done a little late. It made it into the final prototype, but not the presentation. As an artist, I'm sure Alice really wanted people to see all of her work, and I feel pretty bad about the entire thing. Definitely something to keep in mind in the future. Working on something and not having it shown to people can be pretty rough.

On the other hand, I think the project went incredibly smoothly and everyone was pretty happy with the end results, the client included. It was difficult to come up with negative things for the postmortem, but there are always things that don't quite work out. Here is the postmortem timeline:

Fairly sparse on the bottom, but we had some good discussion. I once again championed pair programming and the use of scrum. As a producer, these two tools were immensely helpful. We'll see about that in future projects.

I also changed up the one-sheet format a little bit, and I'm pretty happy with the results. Check it out:

Overall, it's somewhat of a mishmash of the first one sheet I used, based off of some resources I found online, and the template that another producer, Brianne, came up with. I like that it still has a decent amount of information, but also has a nice design to it as well. We'll see Monday how everyone else liked it.

On an incredibly positive note, Stacy seemed very excited about the prototype, and immediately asked if we would be interested in continuing our work should funding be secured. Every time we make a prototype we're hoping to get some work with it, and this seems very promising. Stacy is going to show the physical therapist she works with the demo, and try to secure some funding from there. If we could swing some research assistantships out of the deal, that would be great. Of course, a simple pay-for-work deal would also be great. Hopefully we hear some more soon from her. I plan on staying in touch and keeping my finger on the pulse of this.

Now all that's left is next week's prototype...and then the next prototype..and then a thesis project...and then an internship, etc. Piece of cake right? I'm looking forward to next week.

Week 3/Fall Break and Everything's Fine!

So week 3 went by pretty quickly. We're getting our work done, and the scrum process is going well. Alice has been doing great work with the art assets, and she's really digging in to the scrum process. As long as she has work on there she'll do it, and the work has been turning out great.

I've been keeping busy with audio work. I haven't really messed with sound design too much previously, and I possess a rudimentary amount of knowledge of audio and music in general. However, given my constraints, I think the audio turned out decent. It's really there to just add another layer of sensory input (input to the player not for the game), and since this is a prototype, if the audio isn't top-notch that's okay. I think it comes down to the fact that it's just nice to hear something while playing the prototype, and never underestimate the amount of  feedback from sound effects and how important it is to the player. This may be something I'd like to look at in the future a little more in-depth. I have some technical skill, but I usually just get in the way of the engineers, and I have no traditional art skills to speak of. But I enjoy audio, and this seems like a way to contribute concretely (and not just process and management) that most of the other students here have little to no experience with either.

Speaking of engineers, the pair programming work of our two engineers is turning out great. They sit down, work together, and just get things done with very little time spent debugging simple errors. Honestly, it's blown me away a bit with how effective a technique it is. I'll be recommending this technique for future projects without a doubt. However, I'm sure there are a few things to keep in mind. These two engineers specifically asked about working together to pair program. This implies they were at least on friendly terms beforehand, and that both were looking to give this technique a shot. They also have personalities that don't clash. As a group, we only have two engineers, since we have an artist. If my future groups have 3 engineers, pair programming might just get in the way, or it may seem like we're playing favorites. So there are lots of constraints, but I'll still recommend it in the future for anyone who wants to give it a shot. A side effect of this in a small group is that code dependencies are pretty much nonexistent. Estimation was difficult, but we actually hit most of our estimates, or adjusted to make things work. For instance, we dropped calibration since we can fake it pretty well. Overall the game is intact, the motion is fun, and it displays the basic game loop.

Right now we're looking at one more day of work, a short gameplay video demo, and making a wrap kit. The dry run went well, and we ironed out a few kinks, like trying to run a live gameplay demo (which worked okay, but I agree with the feedback that a video might work just as well and is easier to show to others).

Project Two, Weeks 1 and 2 get!

Weeks one and two went by pretty quickly for our next project. So, getting down to business, our team is:

• Myself - producer
• Alice Owens - artist
• Jason Thummel - engineer
• Jason Kanagaratnam - engineer

We are part of the 3 groups that were chosen to work on the educational games (as opposed to the TreadPort physical therapy games). Oddly enough, we actually chose a physical therapy game to work on! Stacy Bamberg is a professor on campus working in the bioengineering department on a few projects involving physical therapy for stroke victims. Out of the two presented projects, my team and I decided on the Kinect game for arm range of movement therapy. Initially, we were going back and forth from this to the thermodynamics game presented by another professor, but we eventually decided on this due to the excitement of working with Kinect.

Quite honestly, I pushed fairly hard for the Kinect game as I recently had a close family member suffer through a stroke and the rehabilitation required afterwards. I just thought how great it would be do to something to help people through that process. Seeing it first hand really showed how difficult it is to stay motivated and to keep watch on the patient's progress. Progress is slow, and having a visual way to display to the patient/player the improvement he/she is making and an engaging method of encouraging therapy could be so important to the well-being of the patient. To be a little selfish, the family member who suffered a stroke has done so much for me growing up that I couldn't help but jump at the chance to give back to him in a meaningful way. On the other hand, I thought it would be interesting, and motivating, to be personally invested in a project like this.

The team went through myriad design ideas before we came to our current gardening concept. Since a somewhat simple game had already been developed for this, we at first thought of ways to basically skin the same concept with things like bingo, mazes, or word-finds. That just seemed too simple and too boring still. That's when we came up with the idea of some sort of consistent narrative arc, albeit simple, tying the separate levels together. For me, gardening immediately sprang to mind. There are many stages of gardening, from tilling the soil to harvesting your fruits, that we could design multiple stages easily. Combined with a sort of narrative (watching your garden grow) that keeps the player engaged from level to level, we hoped to engage the player with the outdoors aesthetic as well. Since most physical therapy is done indoors in sterile environments, we hope that this aesthetic allows the player to escape the sterile hallway if even just a little.

From there we hammered out some details, involving figuring out how to perform the actions with the Kinect, what levels to use, how to work in breaks, and how to bring players back to do more physical therapy. I made a short video of our initial pitch (unfortunately with no audio) that should give a basic understanding of our original concept.

From here we got to work immediately, scrumming out our project and deciding on what to prototype and what to leave out. Below is a thumbnail showing the basic layout of our task pane for our scrum. Click on the picture to actually check out the scrum, and be sure to check out the different tabs at the bottom!

As we moved past pre-production and entered into our first week of working on the game itself, things have been coming together quite nicely. The engineers have been working hard pair programming. At first I thought this would create some issues with scheduling tasks and estimating hours, but it has actually gone quite smoothly. They've been churning out excellent work, and since both of our engineers have been working together, there hasn't been any conflict regarding duplicate work or people waiting on prerequisite features to be completed. Our artist Alice has really embraced the scrum process and has been super productive. As for me, I've been scrambling to keep up with their work flow a bit, and trying to learn a little about audio so we can add sound effects and background music. This seems relatively simple to code in XNA, but my utter lack of sound design knowledge might hold me back a bit. I'm going to keep trying to get that done, and we may actually get to add some more features into our prototype given our rate of completion. Our estimates may have been too high. That's not a problem though (or should I say if you're going to have a problem, this is the best kind to have) as we'll just add some of the features we took out and use that time to polish the levels. Things are looking promising, and by next week we should have a mostly complete prototype.

Pitch and Postmortem (with video!)

We wrapped up this week with, what we felt, was a successful pitch. Monday's pitch felt a little flat, so we went and improved on a few of its deficits over the next couple days. In the end, our game showed much better in prototype then it did during the initial pitch, which is something I need to work on (more on that below). However, without further ado, here is the trailer I cut together for our game:

Afterwards we held a postmortem to ascertain where we ended up. Here's how our timeline ended up:

It takes a fairly obvious shape (almost a sine wave) when you think about it: hitting a few lows before achieving a decent number of highs. It also turns out I learned a few things talking about the project. Something I thought we did very well with (and the rest of the team agreed) was our design meetings. Design needs to be done quick in this format, but we all felt that we were able to be flexible, compromise, and combine our respective ideas in something that was tailored to the client. No one felt like they were slighted by design decisions or left out of the loop. Our Facebook group probably went a long way in helping communication, especially early on when we weren't sure who had texting or a chat client.

After the design highs we hit a few lows. Looking back, we all severely underestimated the difficulty of the project. Initially, we felt that, at tops, a week would be needed to get the basic prototype together. However, the engineers felt flustered by the lack of documentation for Moai, and it took a week just to get ducks in a row. Something to look at in the future would be to schedule smaller tasks the first week so as to allow the engineers to grow accustomed to the engine and learn some basics while churning out a few easier tasks. This might allow us to prioritize a little better as well. Tasks we thought would take a few hours ended up taking a couple days, so knowing what those are and tackling them early would save some stress later on. As a producer, I definitely need to attack issues with art outsourcing (or sound outsourcing) earlier. It seemed like I would have plenty of time to get some things done, but there were always unexpected road blocks. It turned out alright this time, but next time it might not, and having a few extra days to get things in order might make all the difference.

Towards the end, everything came together. We got things we needed done as the engineers worked with a better understanding of the engine, and art finally came together thanks to Sagar. I made an initial pitch that swung far too plain on the pendulum, but came back pretty well (with the help of the team) for the final pitch on Wednesday. We got a playable demo working, on both pc and iOS. Once we got a firm grasp on the project the last week, while hectic, was much better planned out. In the future, I'll be looking to get that mountain climbed a little earlier. Crunch time isn't fun for anyone.

The last thing I'll say is that I'm sorry to see the team break up. As a first experience, I don't think I could have asked for a better team than Sagar, Triston, and Yuntao. All of them are very capable engineers and good designers. At least now I'll have some engineers to ask for second opinions (and maybe snag some artwork from Sagar if I need to).

Week 3: Setbacks and Hitting Goals

We started week 3 off a little behind. Unfortunately, engineering hitting a couple snags over the long weekend and we didn't quite hit our projections. I went in and reworked the upcoming week's sprint, accounting for extra tasks and re-configuring estimates. We did have to drop a few things into the backlog, but they were all window dressing and not any core gameplay functionality.

As the week went a long, we picked up steam, knocking out tasks fairly quickly. The holiday threw us off a bit as well, but we made up for it by meeting on Tuesday and Thursday for the afternoon. At the end of the week, we had a working prototype that met or exceeded our expectations and didn't drop too much functionality.

Art has been somewhat of an issue. Originally we were looking to outsource to a friend of Triston, but after discussing the ramifications of that we decided to stay in-house. However, by the time I reached Mark to discuss in-house outsourcing, he was in China for a week or so with no internet access. I spoke with Roger, and he passed along an email to his undergrads. As of now, we may be able to grab a couple pieces of concept art from an undergrad I've been in talks with, but given the short notice, understandably, I'm not expecting him to be able to produce anything. We did manage to get a couple pieces of customer art together thanks to Sagar, and it seems that those will be plenty sufficient if all else fails.

With time running out, our team managed to keep cool, get the work done, and turn out a quality prototype in the face of a few setbacks. The team did great, and if everything goes according to plan, our work should reflect this. Pitches are this week, and we have a fair understanding of what's expected. Hopefully all goes well and we can actually produce a fully realized game.

Week Two, Going Strong

Week two is just about over, and the project is going well. A couple set backs with outsourcing, but we made a little headway. Thursday was our planned meeting day with Triston's friend regarding some outsourced sound, but due to the extreme nature of parking on campus during a football game, we had to reschedule. We also ran into some issues with getting sound into our game using Moai. According to the engineers, it requires a decent amount of legwork to get operational. Even if we don't get sound into the prototype, we could always show a video of the prototype and just add sound in video post-production. Another team is also working on sound, and we're hoping to combine our collective knowledge and maybe cobble something together.

In regards to outsourcing, I've found the Creative Commons license to be an excellent resource, especially for a prototype. The Creative Commons website is easy to use and gets the user a license in a few minutes. The license is easily configurable and allows for a decent amount of customization. We will be looking into some concept art outsourcing this week, but that will be through the University. Unfortunately, Labor Day is setting that back a bit, but our team is meeting Tuesday to do some work anyway, which will be a great opportunity to figure out the art outsourcing.

By Tuesday the team should have a pretty decent working prototype. It does look like programmer art and white boxes will be the de facto aesthetic for our prototype. We're okay with that though. It is a prototype, and we don't have an artist easily accessible. That should complete the first sprint in our scrum, which I created last week. The second sprint is mostly user interface, and if our estimates are correct, we should have a little extra time to tidy things up and maybe add a start screen (or work on sound).

To get started with the scrum process I used a spreadsheet in Google docs. Mostly it was creating user stories and sprints, and putting that information into a visually discernible format. It was also pretty easy to create a burndown chart. Although with a 2-3 week project a burndown chart feels a bit overkill. It was good for the practice though, and it can't hurt the project. Overall, I think the scrum documentation turned out well, and next week we will actually get into using it to assign work.

Going into the last full week of work (and being halfway done), I'm feeling good about the project. Everything is on schedule and the engineers are getting even better with Lua and the Moai engine.

First Week

The first week is over and we've made some decent progress. The game is fairly fleshed out and the engineers are getting the engine up and working on basic functionality that we can hopefully port right over to our prototype. Right now we're doing a lot of groundwork just getting what we need in order and figuring out how we can do it. I anticipate a lot of work the next few weeks.

Our advantage may be the simplicity of our game. It doesn't involve a lot of moving parts, uses a static background, and the core mechanics are basic. Other than some simple sounds and artwork, the legwork should be pretty quick.