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
Here is a brief list of what must be done before the release of the first preview of Calliope:
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!
Before going further, let’s recap what data the application has to deal with during its operations:
*/turns/{number});*/actions?pivotOnly&turn={turnNumber});*/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
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
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:
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…
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.
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.
Today I decided to publish the source of my Sproutcore-Raphael integration framework – called RaphaelWrapper – so that others can exploit it and hopefully help me extend it. I posted it on github, you can find it here: https://github.com/demerzel3/RaphaelWrapper.
RaphaelWrapper basically gives access to Raphael functions through a Sproutcore-friendly view called CanvasView. I’m using this framework as the basis for my bigger project Calliope, but since it is a completely independent component of the application I thought it could have been useful to make it public.
In the next days I will publish an usage example, and hopefully a little online demo as well.
If you don’t know what Calliope is, please read this other post before continuing on.
Understanding the game
The first step I took in building the data model for Calliope was trying to figure out how a game was structured, keeping in mind that a game is meant to be played in real time by different persons on different machines, and that the whole state of the game must be persisted in order for a player to be able to shut the game and go back to it anytime.
Obviously there are two or more players taking part in a game, and the game itself can be split into turns in which players interact. But what are the building blocks of a turn? During a turn a player can pick letters from the sack to put them on his/her rack, move letters around (between his/her rack and the board), chat with the opponents, and pass the turn. Each of these steps must be recorded by the system in the current player’s machine, in order to be reproducible on the other connected machines. I decided to threat the above steps all in the same way and to call them actions.
Update (19/4/2011): New screenshots and Todo list of first preview
In the last post I introduced my latest effort: Calliope. As a further step I want to share with you a little more about the challenges and problems of the project, and about the solutions I came up with. Here is what I am going to write about:
I am going to publish one post (or more) for each point in the list, about once a week. If you have preferences about what topic I should cover first or questions about the project, just let me know in the comments (or even in private if you prefer) and I’ll do my best to answer.
