Final Project Planning

Published November 08, 2017

On Planning

How do we allow creative flexibility into a project timeline while recognizing the logistical needs of getting it done?  This question comes up at some point in any project’s maturation from idea to mockup to fully realized creation.  How do we maintain a flexible and evolving understanding of the project’s goals throughout a planning process which by design tries to ‘nail things down’?  Personally, I find that planning – specific and tedious planing – is not a limiting activity, but raises questions which ultimately lead to a greater understanding of the project and how to execute on it.  The act of pre-visualization demands a more rigorous mental model of the project than I would otherwise develop and forces decisions to be made.   As long as planning is done early and often, and as long as you are willing to to discard previous plans, you will have a greater conceptual and logistical understanding of your project.

Final Idea

For our final Physical Computing project, April and I are planning to continue our midterm project of an interactive ball-tossing game.  After combining feedback we received from our class following last week’s proposal with feature ideas we have been developing, we are left with a outline for a game with a rather broad set of features and challenges.  Narrowing this feature set down into a manageable project will be our goal for the coming week.  There are aspects of the interaction we know we need to improve upon: improving ball-return, increasing goal size, and balancing difficulty for players of different skill sets.  There are features which we would like to see implemented: increasing number of goals from two to six and dynamic goals (which turn on and off).  Finally, we have several questions we would like to answer through user testing: how do players interact with the projection-based scoring system we currently have in place and could this be improved upon?  Could we / should we incorporate a storyline element in the style of pinball storylines (i.e. the storyline does not affect gameplay, but it visually interesting)?  Would it be possible to develop a single-player mode?

One of the comments we received in last week’s feedback was that the game is sufficiently complex with only two goals.  We believe, however, that having each goal have two or more “modes” taps into an exciting vein of potential interactivity between player and player, as well as between player and game.   Physically, each goal would have a ring of lights around it which indicates its current mode: active (lights on) or inactive (lights off) as well as which team it belongs to: blue (blue lights) or red (red lights).  When a goal is “active-red”, any balls which are scored through it increase the red team’s score and visa-versa.  When a goal is inactive, no scores are counted.   This allows the possibility of a single player mode in which the game responds to the player – i.e. the active goal changes every time the player scores.  It also allows for the possibility of increasingly complex and  interesting scoring mechanisms: a blinking goal doubles score, etc.  In short, we feel that this added complexity in hardware design would be well worth the potential increases in interactivity.

Nothing to it but to do it…

Of course that isn’t quite true, and because we are adding a level of complexity to the goals and are still unsure of the scoring system, I think it behooves us to build soon and use a working model for playtesting.   While I would like to playtest with a cardboard model for longer, build another model, and properly nail down the interactivity before the final project is built, our shortened timeframe doesn’t necessarily allow for that and I believe our current model is a step too far removed from what we’d like to see to use as a proper play-testing model.  Because interaction depends so much on specifics (of timing, physical spacing, and subtle allowances in the goal-lighting), it is difficult to bring our idea forth without fully building it.  That said, much of the coding work is less vital to playtesting, and can happen relatively later in the process.

Below is a preliminary bill of materials and a very preliminary timeline.

Bill of Materials: