We’ve released our new creation tools in Flash!

We are really excited to announce the launch of our new game creation tools in Flash! As we’ve talked about many times before, we’ve been striving to improve your user experience within the browser. With Flash, you now have a seamless launching and syndication experience, plus a snazzy user interface!

The port of our browser player from Java to Flash went relatively quickly. However, in the case of the creation tools, we took the opportunity to step back, identify, and eliminate many of the points of friction that made it difficult to reuse components in the community.

We love reuse at Sharendipity. We think that is the key to making it easier for everyone to enjoy the process of creating and sharing interactive applications with their friends. And our new creation tool has taken huge strides toward making this a snap!

For example, you can display Flickr photographs on any object by simply dragging a Flickr feed component onto the object. You can incorporate the profile data of your Facebook friends into your games through multiple Facebook services. Perhaps more exciting is the ability to create templates from these user generated components. For example, the Scramble template provides a mechanism for anyone to customize their own photo scramble game. All of these elements are created by users in the community and shared without requiring the respective consumers to understand how the underlying objects are programmed.

If you’d like to build your own logic, we provide object oriented programming tools for you to use. Once you’re finished, you can share it with others in the community. Whether it is a set of actions, a game actor, a scoring system, a web service, or your own artwork.

To help celebrate this event and help you get acquainted with the creator, we’ll be hosting a game jam Tuesday, June 23rd at our Sharendipity offices from 5-11pm. If you can’t make it in person, please join us online through our Twitter account and we’ll work hard to support you remotely.

We believe in your creativity so come join the fun and show off your talents today! We are in the process of turning over the tutorials and wiki to match the new tools. If you need anything feel free to contact us through our Get Satisfaction page!

Supporting our local gaming community

We’re excited to be hosting this month’s IGDA chapter meeting in Madison. It will be held on May 19th at 7:00pm at our downtown office.

In addition to some chapter announcements, we’ll talk a bit about our technology and do a quick demo. Ray Ratelis of Guild Software will also be giving a talk on designing and building games for mobile platforms. Afterwords, the party will move to one of the local watering holes around the square.

The Madison gaming community is growing. With the recent release of X-Men Origins: Wolverine by Raven Software, there has been even more awareness of Madison and Wisconsin as a great community that includes Human Head Studios, Filament Games, Guild Software and Frozen Codebase. In addition to these studios, the University of Wisconsin, Madison is the home of the Games, Learning & Society group that is internationally recognized as a leader in the application and study of games in how we all learn.

We’re thrilled to be able to support the local gaming community through this event and we hope to see you on the 19th!

Official IGDA posting : http://www.igda.org/madison

User-generated Software and Education

I recently read Disrupting Class by Clayton Christensen, Michael Horn, and Curtis Johnson. As I’ve discussed previously, we’re big fans of this book and Dr. Christensen’s insights on disruptive technology.

One of the authors, Michael Horn, attended the recent Hacking Education meeting hosted by Fred Wilson at Union Square Ventures. We were able to follow along on Twitter. While the full transcript is not yet out, Fred Wilson’s summary makes clear that students will increasingly drive their own education: “Learning is bottom up and education is top down. We’ll have more learning and less education in the future.”

Kids and adults learn at different rates and have different preferred learning styles. One student may learn algebra based on the equations, while another may understand only by viewing spatial representations of the underlying concepts. Imagine the permutations, even within a single classroom, of learning styles, rates, and topics to be taught. And ideally the presentation of a topic would be highly engaging, so the learning experience is intrinsically motivating for the student. It would be impossible for a teacher to deliver customized instruction to each student in a learning style appropriate for that student and subject material and in an engaging manner.

Disrupting Class concludes that the classroom of the future will be student-centric rather than teacher-centric, with self-guided learning, largely computer-based, and the teacher acting as a moderator and coach. User-generated software is a key component of this future classroom - it is the only way that this huge set of specialized instructional modules can be created. And standard social community tools like ratings, tagging, recommendations, etc. will allow students to find exactly the module they need.

When nothing is available, the student may create his/her own learning aid. And in creating this tool, the student may in fact master the material. From Disrupting Class (p. 141)

We learn material much better when we teach it than when we’re sitting passively in a classroom listening to someone explain it to us. That’s why technologically enabling students to create content for this second stage of disruption will be so healthy for student-centric learning.”

Is all of this far fetched or way out in the future? Well we’re seeing examples of this already with Sharendipity.

Here is a Spanish study tool created by 10-year-old Emma Tracy. (Emma is the daughter of Greg Tracy, our president.)

Let’s step through how this application came about.

Sharendipity is a general platform for creating software. It allows sharing at any level from code snippets to objects to templates to full applications, all in an intuitive drag and drop, fully live, engaging environment. Sharendipity itself has no explicit support for flashcards or matching games - it also doesn’t provide support for the object dragging paradigm used in the Spanish study tool. But it allows these behaviors and templates to be created and shared by users - the community can evolve the platform at multiple levels.

Here is how Emma’s game, Spanish face parts, evolved:

1. The Decimal Sort educational game incorporated a drag and drop paradigm. This drag and drop capability was shared.
2. A match game was created for putting planets in the correct order: Planet Challenge. It re-used the drag and drop behavior.
3. Planet Challenge was generalized into a template, allowing anyone to create an image-to-image matching game: Image Match Template. A similar template using words was also developed: Word Match Template
4. Emma created Northeast States using the template. (In the course of creating the tool she mastered the Northeast states, and made a confident prediction in the comments section: “I’m going to ace that test tomorrow!”)
5. Emma created the Spanish face parts match game. Greg helped her add some Spanish audio.
6. The Spanish match game was turned into a template, Spanish Match Template, so now other students can easily create Spanish study tools.

This process is exactly what excites us about the potential of Sharendipity. Emma preferred to match the Spanish terms to an image of a person’s face - that’s her learning style for Spanish. Another student might prefer to match the terms to English words. Who knows how different students might want to learn this material - we don’t, just like we didn’t know that someone would develop a drag and drop UI behavior. Sharendipity has the power and extensibility to allow this evolution to occur in the community.

We’re looking for more people to experiment with Sharendipity for educational applications. If you’re interested, get in touch with us. Or just go to Sharendipity and build whatever you need!

Speaking at GDC later this month

Sharendipity is really excited to be presenting at the Game Developer’s Conference this year. We are teaming up with some of the other vendors building game creation communities to talk about our respective experiences. It is part of the Worlds In Motion Summit on Monday and Tuesday. Here are the details:

Date/Time: Monday (March 23, 2009)   5:00pm — 6:00pm
Location (room): Room 132, North Hall
Experience Level: All
Track: Worlds in Motion Summit
Format: 60-minute Lecture

We’re looking forward to some terrific dialog. Please stop by for a visit!

Simple Pseudo-threading in ActionScript

This post could be considered an addendum to our moving to flash series.  I decided to post it because of the lack of good examples out there.  I hope it helps out.

In moving from a multi-threaded environment to a single-threaded one you will commonly have to address how to handle long-running tasks in Flash.  Since ActionScript is single-threaded, this means that we can’t just put the task on a background thread and handle it when it’s complete.  If I had a feature request for the ActionScript language, it would be to make some of this easier (although I do understand why it isn’t there now, and I’d rather have real Abstract classes…).

If you happen to be looking for a way to do this, you might have run across a few other posts.  All of them will tell you that you have to figure out how to break up your task into smaller bits that can be handled one frame at a time.  They’ll probably also tell you that doing this for hierarchical tasks is really hard.  I couldn’t find anyone that actually shows you how to do it though, so here goes:

The Hierarchical Operation

We do a lot of operations on XML hierarchies.  Some of those hierarchies are fairly deep as well, so we need to be able to break up the task into multiple, smaller tasks.  Let’s say that you have a function that looks like this:

public function runActionOnHierarchy(tRoot:IXmlNode, tAction:IXmlHierarchyAction) {
    try {
        tAction.nodeEncountered(tRoot);
    }
    catch (tEx:Error) {
        // handle error
    }

    var tChildren:IObjectArray= tRoot.getChildren();
    if(tChildren != null) {

        var iSize:int= tChildren.size();
	var tChild:IXmlNode;

	for (var i:int=iSize-1; i>=0; --i) {
	    tChild = IXmlNode(tChildren.get(i));
	    runActionOnHierarchy(tChild, tAction);
        }
    }
}

This code uses some of our own interfaces but you should get the idea. This method just takes an action and applies it to every node in the hierarchy. Ideally, that action doesn’t take longer than a frame, or about 1/30th of a second (depending on your desired framerate, you can change this). If it does, you’ll have to break up the action itself but we’ll address that a little later.

The Pseudo-thread Task

Since we aren’t dealing with threads, we will refer to the operations we want to perform as tasks. Think of them as the separable operations that would have been part of a larger thread. Here is an interface for a task that will be run as part of a Pseudo-thread:

public interface IPseudoThreadTask {

    /**
     * Run the task.
     * @return whether or not the task is finished.
     */
    function run(tManager:PseudoThreadManager):Boolean;
}

Obviously, a pretty simple interface. The only part that might get confusing is that the run() method takes the PseudoThreadManager. This is actually pretty important. I don’t like that we have to inject this dependency into our core tasks but if this task is going to spawn other tasks, as will be the case in a hierarchical one, then you’ll need this so that you can add the new tasks to it (unless it’s a singleton and globally accessible, but some people don’t like using those).

The Pseudo-thread Manager

The pseudo-thread manager is pretty simple as well. We’ll use a stack to manage the tasks that need to be executed. As a particular task is running, it may spawn other tasks that will be added to the manager, but the original task itself may not have completed, so we’ll always use the top element of the stack when determining what to execute. A small note however: if the task does complete, you need to be using a data structure that is capable of removing an object from the middle of the structure and compressing the other elements. We do this through our own IMutableObjectArray interface. A linked list is another, potentially better, option.

public class PseudoThreadManager {

    private static const THREAD_ALLOTMENT:Number = 1000 / 30; // 1/30th of a second.

    /**
     * The array of pseudo-thread tasks.  This will be used as a stack.
     */
    private var mtTasks:IMutableObjectArray = new MutableObjectArray();

    /**
     * Constructor.
     */
    public function PseudoThreadManager() { }

    /**
     * Add a task to be managed by the task manager.
     */
    public function addTask(tTask:IPseudoThreadTask):void {
        mtTasks.add(tTask);
    }

    /**
     * Run the Pseudo-thread task.  This will execute tasks for an allotted amount of time.
     */
    public function run():void {

        var iTasks:int = mtTasks.size();
        if (iTasks == 0)
            return;

        var iStartTime:int = getTimer();

        // Loop while there is time left.
        while (!((getTimer() - iStartTime) < THREAD_ALLOTMENT)) {

            // Start with the last task.
            var tTask:IPseudoThreadTask = mtTasks.get(iTasks-1) as IPseudoThreadTask;

            var bComplete:Boolean = tTask.run(this);

            // Note that we need to remove the specific task in some way, we can't
            // just pop the task off the end because other tasks may have been added.
            if (bComplete)
                mtTasks.removeIndex(iTasks-1);
        }
    }
}

When I originally created our version of the Pseudo-thread manager, it actually operated independently of most of the codebase through the use of the callLater() method, which would call back into the PsuedoThreadManager every frame. I never found out why, but in doing so this would interrupt execution of other parts of the codebase that were listening for ENTER_FRAME events when interacting with other UIComponents. Instead, I just had our main update thread call the pseudo-thread manager’s run() method.

Implementing the Hierarchical Task

Now that we have a task manager, a task interface, and an operation we want to break up, we just need to implement our hierarchical operation as a task.

public class XmlHierarchyTask implements IPseudoThreadTask {
    /**
     * The root node being operated on.
     */
    private var mtRoot:IMutableXmlNode;

    /**
     * The action operating on the hierarchy.
     */
    private var mtAction:IXmlHierarchyAction;

    /**
     * Data members for the current state of the task.
     */
    private var miChildIndex:int =  0;
    private var miChildren:int = 0;
    private var mtChildren:IObjectArray;

    /**
     * Constructor.
     */
    public function XmlHierarchyTask(tRoot:IMutableXmlNode, tAction:IXmlHierarchyAction) {
        mtRoot = tRoot;
        mtAction = tAction;

        mtChildren = tRoot.getChildren();
        if (mtChildren != null) {
            miChildIndex = mtChildren.size();
        }
    }

	/**
     * Run the task.
     * @return whether or not the task is finished.
     */
    public function run(tManager:PseudoThreadManager):Boolean {
    	var bReturn:Boolean = false;

    	try {
            mtAction.nodeEncountered(null, mtRoot);
        }
        catch (tEx:Error) {
            // handle error
        }

        // We will only process a single child at a time.  This is
        // effectively a depth-first processing of the hierarchy.
        if (miChildIndex < miChildren) {
            var tCurrentChild:IMutableXmlNode = IMutableXmlNode(mtChildren.get(miChildIndex));
            tManager.addTask(new XmlHierarchyTask(tCurrentChild, mtAction));

            ++miChildIndex;
        }

        if (miChildIndex == miChildren) {
            bReturn = true;
        }

        return bReturn;
    }
}

Take some time to compare the XmlHierarchyTask with the original hierarchy operation that we started with. Notice that for the most part the same structure is there: we invoke the operation on the specific node and loop over the children. The only difference is that the children are being operated on through successive calls to the run() method. Once the final child has been operated on, the task can return true so that it will be removed from the PseudoThreadManager.

Breaking up the Action

So what if the action that you’re using to operate on the hierarchy takes a long time? Well, you already have an interface for the task, so just implement the action itself as a task. Here’s a quick example of how an action that has three separable operations might be implemented:

public class XmlHierarchyAction implements IPseudoThreadTask {
    /**
     * The node the action is operating on.
     */
    private var mtNode:IXmlNode;

    /**
     * State variables.
     */
    private var mbCompletedFirstPart:Boolean = false;
    private var mbCompletedSecondPart:Boolean = false;

    /**
     * Constuctor.
     */
    public function XmlHierarchyAction(tNode:IXmlNode) {
        mtNode = tNode;
    }

    /**
     * Run the task.
     * @return whether or not the task is finished.
     */
    public function run(tManager:PseudoThreadManager):Boolean {
        var bComplete:Boolean = false;

        if (!mbCompletedFirstPart) {
            // Do the first part of the action

            mbCompletedFirstPart = true;
        }
        else if (!mbCompletedSecondPart) {
            // Do the first part of the action

            mbCompletedSecondPart = true;
        }
        else {
            // Do the third part of the operation.

            bComplete = true;
        }

        return bComplete;
    }
}

The XmlHierarchyAction could just create one of these instead of calling nodeEncountered() as it did before. The pseudo-thread manager is unused here, but again, if this action spawned other tasks, it would be required.

Wrap Up

So that’s all we really use to manage our long running operations. It’s not a lot of code, but getting into the actual implementations of some of the actions can get confusing. Refactoring that functionality to work in a pseudo-threaded environment can be difficult for a lot of reasons. You may need to use listeners to know when a particular task has been completed, for example. We do this in Sharendipity so that we know when an entire Application has been initialized, displaying a spinner or progress bar that is updated while the initialization is happening.

I hope that this gives you an idea of how to break up operations in ActionScript. There may be other solutions out there but I wasn’t able to find them. If you have any suggestions, please leave them in the comments.

Merging accounts

You asked for it… and now we are happy to deliver!

We’ve just deployed a new tool that will help you merge your Sharendipity account on Facebook with the account you use to access sharendipity.com. Once merged, you’re Sharendipity identity, which includes your created assets, scores, achievements, ratings, and comments, will travel with you whether you access the platform within Facebook or sharendipity.com. (if you’ve never logged into Sharendipity from outside of Facebook, you can safely ignore this feature)

When you’re ready to merge your accounts, follow these simple steps…

1. Access Sharendipity from within Facebook.
2. Go to your Sharendipity profile page by clicking the “Your Profile” link at the top of the Sharendipity application page.
    
    
3. Edit your profile by clicking the “Edit Profile” link next to your profile picture.

 


 

4. At the bottom of your profile’s edit page, enter your Sharendipity login credentials.
    

   
    

5. You’re done!

Note that your merged account will use the display name you used in your Sharendipity portal account. If you’d like to change it, you can do so from the “Edit Profile” page.

Hello Flash!

As we started talking about a month ago, we made the decision to port the Sharendipity platform to Flash. We’re really excited to announce that the Flash version of our game player is officially released!

There has been some great discussion both on this blog as well as other places about the decision we made. Now that we’ve made it here, we love it. It opens up so many possibilities for you as players and developers.

• Syndicating games is a snap. Just add the embed code for any application you create.
• Performance is smooth and consistent for every user playing the games.
• Game creators not only get achievements, challenges, and high score management for free, but now you can easily add your great games to any number of other Flash gaming sites in addition to Facebook.
• Games are even more portable then they were before. They’ll go everywhere Flash goes!

Our creation tools are still running via a Java applet for now. We’ll keep you posted on our progress as we make that transition. In the mean time, enjoy the new Flash player!

Gone fishing

As part of the Lost Garden prototype challenge for Fishing Girl, we’ve started some work on the behavior of the game’s fish. According to the specification, the fish in this game are defined by the following properties…

Fish are objects in the sea that move back and forth in predictable patterns. Fish come in different sizes, rarity and movement patterns.

• Movement: Back and forth. There are others patterns such as circles or swarms, but that would be extra.
• Size: Small, Medium, Large, Extra large.
• Rarity: Common, uncommon, Rare, Very Rare. This is used during “Scoring the Fish”

Fish are spread throughout the water with more valuable fish located further from shore. Try to have a good mix of big fish and small fish. You can start testing with one fish, but ultimately, you should have 10 to 20 or else the game won’t be very interesting.

All three of the bullet items have been implemented. We’ve also implemented the “attraction” behavior when the fish approaches a lure. However, the integration with the scoring system will come when the fish are added to the actual game. We decided to create a new Fish Tank application as a playground of sorts to experiment with ideas outside the scope of the other game mechanics. We did this for a couple of reasons.

1. Isolation of the fish behaviors makes debugging a lot easier and faster.
2. It provides a nice way to spotlight this single element of the game and rapidly iterate based on feedback. We can also experiment with some of the “hooking” elements of the game in an easily controlled environment.
3. The power of sharing means it doesn’t matter where we create the fish. Once we’re happy with their behavior we can simply share them back to the community and re-use them in any other application! All we need to do is drag and drop them into our game.

Go check out the fish tank and send us your feedback!

Next up…. implementing the lunge.

Game Prototyping in Sharendipity

I’ve always advocated for Sharendipity as a great platform for rapid prototyping of games. Now, I’m going to try to put my money where my mouth is and create a game based on someone else’s design.

Daniel Cook over at Lost Garden does some really fun game prototyping challenges.  In providing all of the artwork, he really allows the game designer to focus on the actual design rather than the implementation.  The most recent challenge is for a game called Fishing Girl.  My interpretation of the game can be found here: http://beta.sharendipity.com/assets/1900/.

As of the writing of this post, only the casting mechanic is finished.   In creating the early prototype, i just love how easy it is to adjust game play in real time.  In continuing work on our port to flash, I’m constantly annoyed by how often i’m making small changes in the application that require a complete re-compile and re-launch of the project.  When creating something in Sharendipity, there isn’t any of this.  I get to play around with the gameplay, moving around images and tweaking parameters, seeing them take effect immediately.

If you’re interested, I invite you to create your own prototype in Sharendipity.  We’d love to hear what your experiences are as we continue to improve the editing tools.

Moving to Flash, Part 5: Network Communication

This is part 5 in a series of posts that address the issues involved in porting a large Java RIA to Flash. I recommend reading the previous posts as well:

Part 1: We’re Moving to Flash. Here’s Why
Part 2: Important Differences Between Java and ActionScript 3
Part 3: Beginning the Actual Port
Part 4: Anonymous Classes and the Adapter Pattern

Another main difference between Java and ActionScript is in how data is communicated to and from the server. In just about any Rich Internet Application this is going to be an important part of your architecture, so it’s important that it is handled correctly.

Synchronous vs. Asynchronous Communication

In Java it is possible to make a blocking call when requesting data from the server. Typically this will happen on a background thread and the programmer handles the returned data in the same thread. In ActionScript, it is not possible to block while data is being requested from the server. This can cause some challenges if you’re trying to port a project to ActionScript.

Java Threads

Fundamentally, the only real difference here is where the threading happens. This exact same functionality could be implemented in Java as well, you just need to manage the data yourself. In Java however, there is no guarantee when the remote call will return. The thread on which the request occurs will continue processing in parallel with your main event thread, so you may want to implement a task queue that guarantees that the handling of returned data happens at a particular time. If you don’t do something like this, you will probably have to handle synchronization issues because you will now have two threads running simultaneously. This will be covered in a bit more detail later in the post.

Because of these issues, if you’re using a programming language that has a threading model similar to Java’s, you may want to rework a few things before starting into the port, but it isn’t necessary. We did it afterward so it’s clearly possible.

ActionScript Data Requests

In ActionScript, data can be requested using many different methods. With all of them, you handle returned data by adding event listeners to the object. For example:

public function executeRequest(tHandler:Function, tErrorHandler:Function) {

	// Create the URL loader which will perform the actual communication with the server.
	var tURLLoader:URLLoader = new URLLoader();

	// Register an event listener that will respond to the completion event
	// and notify the response handler.
	tURLLoader.addEventListener(Event.COMPLETE, function completeHandler(tEvent:Event):void {

            // Instantiate a new response object which makes retrieving data
            // from the response simple.
            var tResponse:ServerResponse = new ServerResponse(tURLLoader.data);

            // Pass the response to the handler.
            tHandler(tResponse);
        });

	try {
            // Execute the load.  A successful callback will be passed to the
            // handler, and any Error will be passed to the error handler.
            tURLLoader.load(tURLRequest);

        } catch (tEx:Error) {
            if (tErrorHandler != null)
                tErrorHandler(tEx);
        }
}

This little piece of code actually has a lot going on, and is indicative of the model we’re using for communicating the server response back to the client. Let’s look at the completeHandler() function first.

When the data is returned to the client, completeHandler() creates a ServerResponse wrapper around the data and passes that off to the handler that was passed in. The URLLoader’s data property holds the byte array that was returned from the server. The ServerResponse is what is used to unwrap that data. It contains functions such as nextInt(), nextString(), etc. that will pull the values out of the array and return them to the caller.

There are also two different anonymous functions passed in to the executeRequest() function. I’ll note that there are much safer ways to do this. In my last post, I described a DynamicImplementation class that would be perfect for passing in data handlers to this method. The handlers are currently very simple only because we know that there is a single parameter to each one.

The important point here is that we are providing the data handler to the exceuteRequest() function so that we can process the returned data when it is returned. In Java, the model was that the ServerResponse itself would be returned as a result of the executeRequest().

Using a Task Manager

I’ve also mentioned in previous posts that you may want to use Runnables for posting tasks to a global task manager. One problem with moving from a multi-threaded to a single-threaded environment is in determining when exactly the data is being processed. If your communication was happening on a separate thread in Java and you were using the above model, then you may need to perform synchronization in your response handler. However, if you guaranteed that data manipulation never happened on any thread other than the event queue you could forget about this.

Using a task manager would allow you to pass in a Runnable to the executeRequest() function which can be posted to the task manager to be processed during the start of your main event thread. This is very similar to the model that Flash uses for when the events are processed as the result of the remote call.

Conclusion

Now that we have our communication architecture in place, we’re pretty much finished. This series of posts describes just about everything that we needed to do in order to get a working prototype up and running and it only took two weeks, including learning ActionScript. There are a few things that I didn’t mention in this series, such as the differences in drawing objects in Java and Flash and our underlying physics engine. If there’s interest, maybe we’ll post some information about this in the future.

We’ve described the big pain points that we’ve encountered along the way and the solutions that we’ve come across. It’s been a very interesting process and really makes me appreciate the work that we did up front to enable this port. If you’re thinking of moving to Flash, hopefully some of these posts will help you save some time yourself.