Team 2 Proposal

Jesse Watts-Russell, Phil Davis, Nick Carter, and Andrew Michaud

Abstract

The teacher we are consulting with teaches a lesson on finite state machines. The teacher has suggested that it is difficult to give middle school students a firm understanding of what, for example, a DFA is, and how it works in an abstract sense. In order to supplement this lesson, we are proposing a game to teach to middle schoolers the creation of simple deterministic finite state automata (DFAs) through an engaging game like environment.

In terms of UX (User eXperience), the game needs to be able to engage middle school (grades 6-8) students so that they will enjoy working through levels and retain something. The basic design has predefined states ("islands") with two possible exits, state transitions ("trade routes") students define transitions ("courses") between islands, and an accepting state ("treasure island"). Since our game is graphically simple, we are largely iOS version-agnostic (we don't need Sprite Kit, but would be happy to use it).

Background and Learning Objective

The teacher we are supporting, Nathaniel, has been using a CS curriculum called CS unplugged. He has noticed his students have particular difficulty with the FSM unit, and would like a game to supplement his lessons. Based on the content of the lesson and Nathaniel's advice, we have narrowed in on simple DFAs as our primary target. Our primary goal will be to reinforce basic understanding of what a DFA is, and help students build their DFA-reasoning skills by allowing them to build simple DFA constructs such as loops.

Requirements Analysis

  1. Functional requirements
  2. Create and explore DFAs
  3. Each puzzle can be done in a few minutes by a student
  4. Increasing level of difficulty for advanced students

Nonfunctional requirements

  1. Support and supplement lesson
  2. Target audience is middle school-aged children (grades 6-8)
  3. Easy for students to understand and engage
  4. "Thick" wrapper around DFAs. It should be much more engaging than an implementation of JFLAP with some sort of achievements.

Game Design

Each level of the game presents a student with a set of islands which function as the DFA states. The level will give either a specific input sequence or, in more advanced levels, a type of input string (a language) that their path must accept in order to reach treasure island safely. In the earlier levels, penalties for accepting incorrect strings will be small. In higher levels, accepting an incorrect string will likely constitute a level failure.

An island will have 2 outputs, called either routes or trade routes. Each can be mapped to any input of another island. All input strings will be a binary sequence (probably Ns and Ss, representing North and South, because one route will originate on the North side of the Island and one on the South side, but these labels could just as easily be something else). When the student feels they have a correct machine (path) for their pirates to navigate, they will hit a button. It will cause ship(s) representing different strings to attempt to navigate the route. Ships that end up places other than the accepting state will suffer various unfortunate fates such as scurvy, mutiny, the british navy, ship wrecks, and zombie fish attacks.

Players will be rewarded for using a fewer number of states (don't want to give other pirates a chance to beat you to the treasure!).

Risk Assessment

We plan to keep our graphics fairly simple, so Sprite Kit isn't a requirement. As such, we're perfectly happy to work in iOS 7 if the school updates its iPads, although we are biased slightly toward iOS 6 because it is more time-proven.

Our design assumes that students will find the pirate theme interesting and engaging. We find risk in this assumption to be minimal.

Development Plan

We plan to use the Agile development method. We will attempt to complete a full iteration every other week, giving us sufficient time to make major changes in a single iteration even when several team members are busy.

We also plan to focus very heavily on keeping a coherent UX. We will evaluate our overall UX weekly and if we feel that there are significant conflicts in it we will focus our next iteration on resolving them and reunifying the experience. Ideally, this process will be driven by user stories and use cases.

Something went wrong with that request. Please try again.