mugle-dev team mailing list archive

[Matt Giuca <matt.giuca@xxxxxxxxx>]

On Thu, Mar 24, 2011 at 9:14 PM, Prageeth Silva <prageethsilva@xxxxxxxxx>wrote:

> But my confusion is, I'm not quite sure which parts are needed with high
> priority for the API.
>
> I think, if i can get a copy of the project spec sheet, then I may be able
> to figure it out and fill up the gaps.
>

The relevant section of the project sheet follows:

Software must be developed as an educational module for the MUGLE platform.
> This means it must be developed as a client-side only Google Web Toolkit
> application, and must use a number of features of the MUGLE platform:
>
>    - It must automatically save the student’s progress to the MUGLE server
>    (it doesn’t have to save all game state, but should remember which part the
>    player is up to).
>    - Upon completing a game or section, it must calculate a player’s
>    “score” and send it back to the MUGLE server (which automatically tracks a
>    player’s best score, ranks players, etc).
>    - You must design at least three “badges” to award the player for
>    special achievements or outstanding behaviour, and have the MUGLE server
>    “unlock” these badges when the player earns them.
>
> Full documentation for the MUGLE API will be available during the
> architecture phase.
>

The priority is getting the key/value store interface perfect. This means it
needs a basic underlying implementation which reads and writes key/value
pairs to the database (how that is implemented isn't terribly important), so
that we can ensure that the basic interface is sound. We can always change
the underlying implementation, but we can never change the interface.