Look around you for new game inspirations

Scratching for a new game idea? The “The Pickford Paradox”: Between Silent Film and New Media from Henry Jenkins does a nice job of getting you to look around your physical world to find new inspirations for games.

Update: Another great source, GamePlayGag, for examples between silent movies and new media.

Using Yammer to Communicate Effectively in a Startup

Communication is incredibly important in a startup.  Every member of your team needs to be aware of what everyone else is doing, the direction the company is going in, funding status, you name it…  As soon as the lines of communication break down, chaos ensues.  People start thrashing, productivity plummets and you have to work to regain a decent level of efficiency.

At Sharendipity, we’ve tried just about everything we can to open up those lines of communication.   As a technology-driven startup, a lot of this focuses on communicating information about the product such as code changes, feature requests, the roadmap, etc.  Regardless of the company’s focus and what information needs to be communicated, Yammer provides a great way to keep the ball rolling.

Early Attempts at Communication

BugZilla

In the beginning we thought that BugZilla would help track a lot of the discussions.  At the time, we were coding in Java and there was a nice Eclipse plugin called Mylyn that integrated with BugZilla.  But when it came down to it, BugZilla is just clunky and didn’t fit into our workflow very well.  We’d have to go back to the BugZilla web page constantly to run reports and prioritize and assign bugs.  And it didn’t really help with planning out our roadmap.

An Internal Wiki

We thought that we’d just do away with BugZilla and keep track of everything ourselves on an internal wiki.  This way we could maintain pages for the wiki, keep bug lists and feature requests, and cross-reference things when necessary.  It worked fairly well for a while but gradually became less effective.  Again, maintaining the wiki didn’t fit into our daily workflow.  In addition, communicating updates wasn’t as easy because it would come through your email.  As a result, the wiki would grow out of date or get messy and someone would have to take some time to fix it up.  This was never fun.

An Internal Blog

The blog was a lot easier to manage and fit into our workflow better.  When someone made a checkin, we would duplicate the checkin note to the blog so that people could see it.  We were edging ourselves towards the real-time communication that we didn’t really know we needed.  The problem with using the blog was that, even with RSS feeds, it was still out of your normal workflow.  You’d have to make an effort to go check up on what had been done.  It did let us integrate all types of communication in a single environment though.  The wiki achieved this as well, but we didn’t see the information as a stream like we did with the blog.

What this ultimately comes down to is a problem of interfacing with the blog.  If we had a desktop client like Yammer’s, the blog would have worked a lot better.  Sure, we could have written a little desktop app that would notify us when there was a new post.  But this was before Yammer and before AIR.  More importantly, we didn’t know that it was a problem.

Why Yammer Solves the Communication Gap

Yammer provides a stream of information that is easily accessible.  It’s also in reach of everything that I do as a coder, but unobtrusive enough that it doesn’t distract from a task at hand.  If something urgent comes up, I can address it.  Otherwise, at least I know that I need to address it when I get a chance.

The important point is that Yammer fits into our workflow incredibly well.  I don’t have to go to a webpage to see what’s going on; the yammer client is always running on my desktop.  Nor do I have to make an attempt to see if something was posted recently; it pops up automatically.  In addition to fitting into my daily routine, Yammer also provides some nice features that make my life even easier.

Threaded Communication

I love that Yammer solves the problem of having to dig through BugZilla to find comments about a bug.  In Yammer, I can just look at the thread and see what someone had to say about it.  It also solves the problem of adding comments to a wiki (there are a few that do this but you can’t follow comments about updates or individual items on a page).  The important part though, and I can’t stress this enough,  is that Yammer facilitates a discussion around everything that is going on in our company.

Using Hashtags Effectively

One of my favorite features of Yammer (and Twitter) is the use of hashtags.  There are primarily five types of information that I’m concerned with on a daily basis: checkins, bugs, feature requests, roadmap discussions, and general office information (e.g. “Out of the office until 10 this morning”).  When posting to Yammer, we can communicate the type of information in a hashtag by applying any one of #checkin, #bug, #feature, #roadmap, or #office.  Furthermore, we can call attention to a post by appending #urgent to it.  We can also add other differentiating tags such as #client or #server.

Directed Communication

Oftentimes, I want to communicate something only to one person.  As long as it isn’t private, my post can call that person’s attention by simply appending the @ symbol to their username.  Oddly, in contrast to the way Twitter is used, most of our communication isn’t person-to-person.  But when it is, I can simply ask someone a question on Yammer, or answer theirs.

Distributed Communication

One of the other important aspects regarding our usage of Yammer is that it enables distributed communication incredibly easily.  It’s pretty common that we aren’t all in the office at the same time.   Someone will be meeting with a potential investor, someone will be in Germany, or someone will be at the coffee shop.  If we aren’t in front of our laptops, most of us have iPhones so we can check in on what’s going on using the Yammer app from just about anywhere.

What We’d really like to see from Yammer (and the Yammer community)

Better Search

The truth is that we still have to maintain some documentation outside of Yammer.  We still have to know which bugs are outstanding or which discussions involving the roadmap aren’t complete.  I want a way to search all threads that have been tagged with #bug, but haven’t been tagged with #complete.  Or if I want to see all of the client-side checkins in the past two days, show me everything tagged #checkin and #client for that time period.  Broadening search capabilities is a great place to start expanding the functionality.

A Better Desktop Client (this may have happened)

This topic may be a little late.  I just updated to the most recent one yesterday and it’s working very well.  Previously however, stability and bugs have been a big problem.  Here’s hoping that it continues to improve.

Third-party integration

I know that there’s an API.  But I don’t have time to implement anything with it.  If there were a few smart people out there though, they’d start integrating their applications with Yammer.  Take BugZilla for example.  How amazing would it be if BugZilla integrated with Yammer?  Every time I posted something to Yammer tagged #bug, a new one was created in BugZilla.  If a reply to that post was tagged #complete, BugZilla would mark the bug as closed.  You can take this further to assign bugs, set priorities, etc.  This would solve my problem above of requiring better search capabilities, and I wouldn’t have to go replicate content already posted to Yammer myself.

I’m guessing that there are a lot of similar applications that could benefit from this.  What about CMS apps?  Salesforce?  Imagine a few hundred people generating leads for your company, communicating progress and updating your company’s records at the same time.  How huge would that be…

So Go Use It

If you aren’t using Yammer, you probably should be.  It’s incredible what happens in a startup when the founders aren’t communicating well.  At that point, you become as effective and mobile as the Big Blue’s you’re trying to compete with.

How-to: Creating a new web service component

Several web service interfaces have been built and shared within the Sharendipity community including services for Facebook, Twitter, Flickr, Posterous, and Google Docs.  Using these components you can quickly and easily access the data from these sites/services.

But what happens if you can’t find the service you’re looking for? Or if you want to improve on one of the existing services and make a better one yourself?

This post is here to help. We’ll walk you through some of the basic elements for building a new component that interfaces with an external web service. To get started, first launch the Sharendipity editor.

Create new object type

Creating a new type provides you with the ability to define custom assets that perform a particular job or store specific data. They don’t necessarily have to be a displayable actor inside your World. The definitions for these new assets are entirely up to you.

In the case of a web service, you’ll define the location of the service, describe inputs, and then define custom actions that let the users of your service interact with it.

1. Open the Explorer dialog and select New from the Types tab.
2. Name your new type. For example, “Twitter Service – public timeline”
3. Declare that your new type “is a REST Web Service” by clicking the + sign next to its name, and selecting the is a button. You can find the REST Web Service type by selecting Other… and navigating to the Local->Types tab in the Explorer that is launched. The following diagram highlights this navigation.

Default properties

Once you have the REST Web Service type defined, you must specify the details of your web service by initializing a couple of parameters.

• URL : This property defines the location of the web service. You will need to consult the API documentation for the respective web service to find the URL for your respective web service type.
  • For example, Twitter’s public timeline is

  http://twitter.com/statuses/public_timeline.xml

• proxied : This property defines whether or not your web service calls will be routed through the Sharendipity server. You are required to turn this on for any web service that hasn’t granted domain access for your application. This is part of Flash’s security model, and you’ll find that some services like Flickr’s allow access, but others like Twitter do not.
• result : This property is not intended to be initialized. When the web service is called, the data returned from the call will be placed in this property.

Custom properties

Many web services have optional and required parameters. For instance, the Posterous API lets you specify the subdomain of the site you are reading from. In order to define parameters, you must define custom properties in your type that are of type REST Input.

Each REST Input has a name and value pair. The name value should be the parameter name as defined by the web service API you are trying to access. In the Posterous example, the name field is ‘hostname’. The value field carries your parameter value. When the web service is invoked, each REST Input is automatically appended to the end of the URL property.

If you were to look at the full URL when the service is invoked, you’d see something like the following:

http://posterous.com/api/readposts?hostname=gregtracy

As you are making calls to the web service, you can simply manipulate the value parameter of the REST Input to change your query to the respective web service.

Web service actions

By default, there is a single method defined for all web service types called invoke web service. This is the mechanism by which you initiate a call to your web service. It can be called internally as well as externally by users of your component.

Just like other objects in the system, you can create your own behaviors, methods, and properties for your new type. For instance, you may want to create your own invoke method which takes parameters that are passed to the web service. For example, passing in a user ID to a Facebook web service to specify the user whose profile you would like to access.

Referencing the service

Once you’ve defined your web service type, you can share it with the rest of the community with the Save option found in the object builder. Otherwise, the web service will be saved along with the application you’ve defined it in.

Whether or not you share it, the new type can now be accessed from anywhere else in the application.

• If you drag it into your World and drop it, you will be prompted to create a new custom property for the World.
• You can drag it into a behavior or method and drop it to create a local variable inside your logic.
• It will also be accessible from the Other tab when you define new properties anywhere within your application.

Just remember that if you don’t save the service by itself, you can only access is from the Local tab of the Explorer within the current application. If you do save it, it will appear in the Types tab for everyone.

Tips for better reuse

Creating an abstraction of the web services call is a nice feature by itself. However, it becomes most useful when you provide really easy access to the data that is returned. For instance, rather than simply providing the invoke web service call and letting the callers parse the data returned, try creating methods that do that parsing for them.

• The Twitter service has a method that returns an array of Twitter Status types.
• The Posterous service has a method that returns an array of Posterous Blog Post types.
• The Facebook User service has a method that returns an array of Facebook User types.

Each of these services define new methods that call the invoke web service method internally and parse the return data automatically. This way, users of the services don’t have to worry about how any of the data is formatted.

For more details, including specifics for the Facebook integration, check out the web services page on the wiki.

How-to: Pass Parameters to Your Application

One of the really cool ways that you can integrate Sharendipity into your own web applications is by passing  arguments into the Sharendipity player via the embed code.  This functionality allows you to incorporate data such as user session IDs or anything else managed by your own server into a running Sharendipity app.

Accessing Application Parameters

Accessing the parameters to your application is really simple.  There is a method on the Application called “Get Application Parameter.”  Access the Application object by clicking on the “Actors” tab in the Values section of the Behavior or Method Builder.  Click on the object called “Application” and scroll down to the section where the methods are listed.  Just drag the method into the right-hand panel and enter the name of the parameter that you want to access:

Setting up the Embed Code

Once you have implemented the Application action, you just need to pass the respective parameter(s) within the embed code.  For example, this is the embed code that is being used for the example application in this blog post:

<object width="300" height="200" data="http://static.sharendipity.com/player.swf?aid=3371&appParam=Sharendipity%20Rocks!!!" type="application/x-shockwave-flash">
<param name="src" value="http://static.sharendipity.com/player.swf?aid=3371&appParam=Sharendipity%20Rocks!!!" />
</object>

Every application comes with its own embed code. Note, however, that the default embed code will not include your custom properties. When you add your embed code to your website, you will need to add the list of parameters. In the example above, it is the section :

"&appParam=Sharendipity%20Rocks!!!"

You can see that we’re already passing the application ID to the Sharendipity player (”aid=3371″ in this case).  All we’re doing is passing the Flash application another parameter as part of the querystring that can be accessed inside Sharendipity.  This is the value that is pulled out when the “Get Application Parameter” method is called with “appParam” as the name of the parameter we want.  If you’re running a web server, you can set up your pages to dynamically write whatever value you want into the embed code.

The Final Application

Here’s the result of what we just made (click inside the app, press the “Esc” key, and rewind the app to see it run again):

New Developer Tools for the Editor

As Sharendipity continues to mature, we are beginning to add more advanced features to the editor that can aid the developer in building his or her application in a significant way.

Traditional programmers using professional development environments are used to having certain tools available to help them troubleshoot their applications. Creators in Sharendipity, including our non-programmers, also require methods for debugging problems and tracking down performance issues.  This post highlights a few of the features we’ve added that will help improve your development experience.

If you have any feedback about how we can continue to improve the tools please let us know.  We’re always listening.

The Console Window and Trace Statements

One of the more basic troubleshooting tools developers use is a console window that provides a simple way to display arbitrary information about the program.  Sharendipity now has a Console Window that can receive text output from an application.  The console can be accessed through the Director menu:

This will bring up the console window, shown here with output from the Teslaformer game:

You can display text on the console window using the “trace” action available in any Behavior or Method of a class in Sharendipity.  The trace statement can also take just about any type.  You can even concatenate values together using the “+” operator as shown here:

The console can be useful for monitoring all kinds of activity within an application. For example, you can print messages to the console simply to let you know when a particular behavior is running, or you can print out individual property values as they are changing.

The Problem Viewer

The Problem Viewer is a dialog that displays logic errors to the developer that prevent the application from running correctly.  When there is a problem in an application, a red notifier saying “Problems” will appear in the top-left corner of the editor.  Clicking on this will bring up the Problem Viewer dialog.

The viewer displays basic logic errors that prevent applications from starting (e.g. forgetting to assign a value in a property set action) as well as errors that occur while the application is running (e.g. your logic is expecting objects to be present and they aren’t).

Double-clicking on an item in the Problem Viewer will take you directly to the location of the problem.  You don’t need to go searching around for the location of the error.

Below is a view of the Problem Viewer in an application I set up to be broken intentionally.  You can see that there are a lot of issues and the Problem Viewer allows me to see exactly which classes and methods they’re coming from.

The Profiler

The Sharendipity editor also includes some new functionality that lets you analyze which parts of your application are taking longer to execute.  Similar to the Console Window, the profiler can be accessed from the Director menu:

Clicking on “Performance…” in the director menu will bring up the Performance Management dialog, which looks like this:

In this view, Profiling has already been enabled and data is being collected in the running application.  From the menu you can view the current profiling data, and you can also clear the profiling data.  Viewing the profiling data will give you a view similar to this:

Similar to the Problem Viewer, double-clicking on one of the rows in the Profiler will allow you to see exactly which calls are taking all of the time, including breakdowns by constructs such as “if” statements:

Breakpoints

Like most debugging tools, Sharendipity also offers a way to halt execution of a thread to examine the current variable data.  The current implementation uses a “Breakpoint” statement.  Under the hood, this throws an exception that will show up in the Problem Viewer, preventing following statements in the behavior or method from running.  Opening the problem viewer and double-clicking on the Breakpoint exception will bring you to the Behavior or Method where the breakpoint was hit.

The really handy part is that now you can mouse over variables in the Method Builder or Behavior Builder to see their values:

The Sharendipity Wiki

I’ll also take a second to mention that a lot of information is documented over at the Sharendipity wiki.  If you happen to get stuck, this is a great place to start.  There are also forums there that allow you to ask questions about any of the topics on the wiki and we’ll respond as soon as we can.

The Complete Picture

With the addition of these new developer tools, the platform is really starting to display its true potential.  Not only is Sharendipity a complete authoring environment for Flash games and applications, it provides distribution as well as monetization opportunities for the developer, all built on a platform designed for sharing and extensibility.