Another Day of Flex 3 XIFF Coding

I realized yesterday morning that I had been developing this multi-user game engine the wrong way, which I kinda felt from the beginning, by using the IM system of communication as opposed to the conference room system.  The new switch over to the conference room system is perfect for what I needed, but be forewarned, what a pain in the ass it was to get a conference room up and running.

What I didn’t realize is that there are quite a few properties needing to be set when creating or
joining a conference room:

room = new Room(kernel.connection);

room.setRoomJID(
  "myroomname@conference." + 
  kernel.connection.server +
  "/Game%201");

room.roomName = Kernel.formatIncomingName(
  kernel.connection.getBareJID());

room.nickname ="Game 1";

room.conferenceServer = "conference." +
  kernel.connection.server;

room.enableAutoUpdate();
addRoomListeners();
room.join();

You need to set the room’s JID, roomName, nickname, and conference server.  The other thing to note is that the conference server seems to need the conference. at the beginning of the URL, it seems to not work at all without it.  The JID needs to be formatted as such as well:

{roomName}@{conferenceServer}/{nickname}

Without these set properly it will not even attempt to create a conference room.  Once this was done the rest was a breeze.  I’ve created the ability to search for all available games, create a game, join a game, leave a game, end a game, display all game players, message all game players, and for the user who created the game to be able to move a box that then refreshes its location on each of the other players screens.

The known errors in my code are exceptions that occur when a connection times out and that the app does not reset itself when a disconnection occurs, a game is left, or a game is ended.

As usual the latest code can be downloaded from:

git clone git://github.com/mbrio/xiff-game.git
git checkout post-three

Jabber Client Screencast 2

So I’m getting used to this screencasting business, and since I felt as though I should continue my divulgence of Flex 3 Jabber client education I’ve added another screencast, this time with audio, describing the latest build of the application.

In this build I’ve re-factored much of my code into components, making the code much clearer then before. As in my previous post I’ve added a git tag that can easily align the code base with the screencast.

git clone git://github.com/mbrio/xiff-game.git
git checkout post-two

I’m now looking into how to separate the controller from the view via org.deepend.game.core.Kernel, this I believe will clean up the code a great deal and separate the business logic from the presentation. Once I have this completed I believe I’ll begin writing my tutorial on how to build the application yourself.

Chat Source

So I’ve decided that I’d start posting some open source code and screencasts as I do some development in light of all the trouble I had trying to get my apps up and running with a lack of tutorials.

To download the source code you will need git:

git clone git://github.com/mbrio/xiff-game.git
git checkout post-one

I’ve tagged my source code specifically for use with this post, as I continue my updates to the code base you’ll still be able to get the source code at the point of this post via tag post-one; I’ve added a screencast to demonstrate what this version of the application is capable of as well.

The Safari window on the right houses the Flex 3 Jabber client logged in as user theanyx; while the left contains the two iChat buddy lists, one for user mbrio and one for user thembrio, as well as the chat window.

You will see that iChat has combined the received messages into one window, I’m not totally happy with this as it is not clear that the single iChat window is receiving messages for both mbrio and thembrio, you will only notice a grey message stating which user is currently active.

Another note to keep in mind is that this application is able to send and receive messages from multiple buddies through a tabbed display. The code is clearly not cleaned up in anyway and is meant only for my own technical advancement, though it may be a little clearer then looking at some of the larger XIFF applications.

The XIFF API I’m using can be downloaded from Ignite Realtime.

XIFF AS3 Library

So a week of playing with a lot of new technology and almost all of the new APIs I’ve worked with have one thing in common, no good step by step tutorials on getting the simplest of applications running. This in no way means I didn’t enjoy the possibilities of these APIs it just means I didn’t have the easiest time getting up and running.

I must say that I have had the most luck and enjoyment out of the XIFF API. After initially trying out the packaged version of the API attainable from Ignite Realtime and utterly failing, I found myself speeding away quickly after correcting my mistake in trusting a release package and downloading the development version from their SVN repository. I beleive the error had to do with how FLEX was passing the message termination characters to ejabberd.

In about an hour I had a feature rich Jabber client communicating with other clients on a private server. It contained a login panel, a buddy list, a messaging window and a console containing a log of the session.

I’m incredibly excited about this as I now have a basis on which to build my XIFF multiplayer gaming engine.

Testing of SproutCore

Now that MobileMe has launched I noticed that SproutCore has been getting a lot of publicity as Cocoa for web browsers. As an avid web developer I was quite intrigued at the promises of such an API, therefore I took it upon myself to give it a try.

Let me say that prior to today I only knew of SproutCore by name and only roughly that it was a JavaScript framework for developing applications, I most closely thought of it as another prototype or MooTools, I had no idea there was any dependency on Ruby or that it was written as an MVC framework.

At Deepend we have been designing an HTML interface that contains two lists, a user must have the ability to drag an item from one list to the other, when an item is dropped on the other list that item must be removed from it’s original list and added to the dropped list. This was clearly the perfect test.

I begun my development and I must say coding of the models, views, and controls was quite east; but applying stylesheets ended up being a little confusing for me. Objects weren’t appearing properly or in any specific order, I am going to equate this to my clear lack of experience with SproutCore. I eventually got my lists looking relatively correct but still had problems binding filtered results to my lists.

I ran out of time trying to complete my experiment and left off with two lists containing the same data. I believe part of the reason I have had problems with the API is the lack of good step by step tutorials, unlike my experience with Django.

I am clearly going to keep playing with SproutCore as I am quite excited about it’s capabilities and it’s architecture, hopefully I’ll have some better experiences with it in the future.