[ milestones ] [ key technologies ] [ design process ] [ lessons learned ]

MILESTONES  
CYCLE 1 - MIDCYCLE
HIT?
profiency of old tools
100%
technology solidified
100%
interaction methods determined
100%
1/2 of prototypes demonstrated
100%
testing schedule/structure
100%
legacy docs and handoffs
100%

CYCLE 1 - FINAL
HIT?
proficiency of new tools
100%
all interaction prototypes completed w/ test
100%
user tests complete
100%
test results compiled
100%
2nd cycle high level goals/objectives certain
100%
mocap bible 1.3 completed and published
100%



View the cycle calendar.


View the cycle GANNT.
 
CYCLE 2 - MIDCYCLE
HIT?
IRB recertification submitted
100%
EMU: 4 games complete internal
100%
VEELOM: prototype complete
100%
DDA 2.0: game design and concept complete
100%
DDA 2.0: rudimentary pose-matching
100%
DDA 2.0: LT mastery of tools
100%
DDA 2.0: models and paints 70% done
100%

CYCLE 2 - FINAL
HIT?
EMU: user-tested and lessons learned
100%
VEELOM: prototype user tested and LL
100%
DDA 2.0: expanded version in LT complete
100%
LT: multiple body, real-time low latency Lith
100%


Download the Mocap Bible,
ver 1.3 now!

"It's Docutastic!"
available in PDF format

"It's docutastic!"

 
[ milestones ] [ key technologies ] [ design process ] [ lessons learned ]

KEY TECHNOLOGIES  

Mo'jox makes use of the legacy MasterMotion codebase and extends its functionality with support for both the new LithTech Jupiter engine, as well as the PyGame rendering environment. Extensive support for the Python language at all phases of iteration allows for more code reuse, and clearer rapid prototyping. In some situations, the prototypes are developed entirely in Python and its access to the SDL, allowing support for multimedia and input parsing more extensive than that which Alice can provide.


LithTech Jupiter 3D system.
 
PLATFORM EVALUATION - Development
Language Iteration Speed Tools Reliability Maintainability
Alice Jython Fast Good Poor Poor
Python Python Fast Good Good Good
Panda3D Python Fast Scarce Good Good
LithTech C++ Moderate Very Good Excellent Moderate
 
PLATFORM EVALUATION - Performance
Execution Speed 2D Capability 3D Capability Scene Complexity
Alice Slow Direct3D/OpenGL Direct3D/OpenGL Poor
Python Moderate Pygame OpenGL Poor
Panda3D Fast Direct3D/OpenGL Direct3D/OpenGL Good
LithTech Very Fast Direct3D Direct3D Excellent
 
PLATFORM EVALUATION - Motion Capture
Existing Support Extensibility Latency (ms)
Alice Tarsus Moderate 51-87
Python Tarsus, Saul Moderate 39-51
Panda3D None High (VRPN) N/A
LithTech Tarsus, Saul High 133-152
 


Test configuration total system latency analysis.


Code makeup.

 
[ milestones ] [ key technologies ] [ design process ] [ lessons learned ]
 


Iterative design process.


Volumetric pose-matching.

 
[ milestones ] [ key technologies ] [ design process ] [ lessons learned ]

LESSONS LEARNED  

Learning in rapid prototyping environments always comes blessedly on a two-fold level, most visibly in user interface improvements, but observations about what worked and what didn't in the development process is just as valuable. Here are some things perceived during the course of the cycle.

  1. rely on other group members to know the things you don't
  2. new code will never be ready when we say it will
  3. making code simple to work with and extend will make it all that much better as time progresses and more is demanded of it
  4. if someone else is running a prototype test, good code comments are immensely helpful (ie: "this is exactly what you need to change for it to work in this case")
  5. documenting programmatic procedures and protocols is as important as documenting class interfaces and algorithms. design ideology is helpful, too.
  6. investment in designing tools at the beginning of the project will no doubt make your like easier later.
  7. backwards compatibility is important, but it can also be a time investment. choose wisely.
  8. premature optimization is never optimal (Jon, corr to #9)
  9. the final product is usually the first prototype, so do your best on the first prototype (Elan, corr to #8)
  10. make prototypes as easily "tweakable" as possible.
  11. always look for existing code or references before developing something original. someone has almost always written it first, and they probably did it better.
  12. no matter how well you plan things, sometimes a prototype will just take a lot longer to get working than you ever expected. leave wiggle room.
  13. conversely, if one component of your software is taking a lot longer than every other piece, you're probably doing it wrong.
  14. just because a piece of software works doesn't mean you should reuse it. if your requirements change your old code might not be appropriate any more.
  15. the more parameters you can take out of the compiled code and into easily changed text files, the better.
  16. it may seem to be overkill to properly engineer a small prototype project, but it saves a lot of pain in that it keeps different developers from inadvertently working at cross purposes.


Jon gives Bob Python support.


Jon and Bob discuss
spatial manipulation theory.


Bob and Dave power-up
for a night of debugging.