Calliope First Run

In past weeks I put online an experimental version of Calliope and tested it out by playing real games with friends. Unfortunately, it didn’t performed that well. I identified a set of technical problems, and a set of design ones.
Continue reading

Calliope – Preview 1 ToDo

Here is a brief list of what must be done before the release of the first preview of Calliope:

  • Fix some bugs in the board related to z-order and overlapping;
  • Redesign the game-choosing screen; (see screenshot below)
  • Provide a button to create a new game;
  • Provide a simple registration interface for new users.

I am going to document every step forward in this post, adding short comments and striking off items as soon as I implement them.

Update 12/6/2011 – Online preview of Calliope has been delayed after a set of private tests gave not-so-encouraging results, read here for more.

Update 9/5/2011 – The new front screen of the application:
In a future version, the icons on the left will depict the current progress of the game.

Would you like to join development? Let me know!

Building Calliope – Sproutcore data sources (Part III)

« Go to Part II

Game (aka Local) data source (..continues from Part II)

Before going further, let’s recap what data the application has to deal with during its operations:

  1. The last turn of the selected game, along with its letters’ configuration (service */turns/{number});
  2. The list of pivotal actions belonging to the game and to its last turn (service */actions?pivotOnly&turn={turnNumber});
  3. Periodically, the list of new actions to perform (service */actions?afterAction={actionId}).

where * stands for /me/games/{id}.

The first item – related to the current turn and letters – has been pointed out in Part II. In this part I’m going to dig deeper into the last two points.
Continue reading

Building Calliope – Sproutcore data sources (Part II)

Game (aka Local) data source

In the local scenario the user has logged in, has selected one of its open games (which list if handled by the global data source) and is taken to the board in order to be able to play the game. In this scenario, the application must load the current game state (that is, the position of all the letters in the game), present it to the user and update it continuously, replicating the actions of the other players.

Notice that this task is more complicated, and cannot be solved using the “load-all-retrieve-by-id” approach used previously: the data involved is potentially quite big (imagine a game with a hundred turns, for example) and could take more than a while to load; actions are pumped in continuously, and as such cannot be loaded once and for all, but must be refreshed constantly.
Continue reading

Calliope – New Screenshots

Today I fixed a couple subtle bugs in Calliope core, and I am one step closer to releasing the first preview. To celebrate I’m going to publish some screenshots of the main interface in action, and a todo list of what is missing before the first preview/demo, hoping that will help keeping me on track.

Here comes the first screenshot:

You can already notice a couple differences here from the first screenshot:

  • Buttons are labelled in English;
  • The graphics of the letters has changed slightly;
  • Rack has been redesigned too, and own letters have been highlighted in dark gray.

There are also some new elements: first of all there is a simple label on the top of the screen, indicating what the turn number is and what the current player is; there is also a green frame surrounding the word “preview”. That, as you can easily guess, means that the word is correct.

Now, if I move the letter “S” from my rack up into the board…

Continue reading

Building Calliope – Sproutcore data sources (Part I)

If you don’t know what Calliope is, please read this other post before continuing on.

In this post I’m covering the problems I encountered while implementing data access in the client-side of Calliope using Sproutcore data sources. If you are starting now to have a look at Sproutcore way of handling data, I suggest you have a look at these pages in the official documentation:

The official documentation is well written, but it uses very simplistic examples that fall short in real word applications (even a simple one like Calliope) and it is missing the “big picture” of how things work. These, I think, are the main reasons why I – and I am not the only one – had such a hard time figuring out how to use the data store effectively.

With this post I hope to fill some of the gaps of the official documentation, by showing what problems I faced and how I resolved them.

Continue reading

Building Calliope – Services Design

If you don’t know what Calliope is, please read this other post before continuing on.

In this post I’m going to describe how the web services forming the backend of Calliope have been designed and built. I didn’t concentrate much on designing them because I was eager to reach a visual result, so I know they’re not the best possible; I’m open to criticism and I hope with your help to improve the design.

Continue reading