Codename: Junction

The first thing you should do is simply jump in. Stop reading a bunch of articles about doing a Kickstarter and just do it. You will learn a lot by doing. Then go back and read about it.

- You can fill out all the info for your Kickstarter project and then share a link with people to get feedback.

- It can take a few days to be approved. If you choose the fixed funding duration, then once you are approved you then get to choose when to launch. You don’t need to worry about it going live unexpectedly after approval.

- Signing up for Amazon Payments is a bit of a pain in the butt. Start that process well in advance of your launch because it can take up to a week. Companies need to use a fax machine (yuk) to fax a bank statement and EIN filing.

- Putting together a Kickstarter takes LOTS OF TIME. We have spent several man-weeks putting ours together.

- Study other similar Kickstarter projects. Most well funded projects have a great video, but if you are reading articles about Kickstarter you already know this.

- Contact people that have backed numerous projects in our category (some have backed several hundred projects). These people probably know better than you what resonates with the community. You are almost certainly too close to your project and there are probably things you assume people will know or figure out. You are probably wrong.

- I am no marketing expert, but I do know you need to market your Kickstarter. Do it any way you can. If you launch and pray you will almost certainly fail.

- Be reasonable with your goal. If you are raising several hundred thousand dollars for a game and you aren’t a major player in the industry, or have some massive following external to Kickstarter, then you will almost certainly fail.

We just launched our Kickstarter today… time will tell if this advice is worth anything!

Dec 11

A Free Game CAN Make it on Kickstarter - Congrats to Greed Monger!

Since I joined Void Star Creations to help with Junction back in March we have been keeping our eye on Kickstarter to raise funds and create a ground swell of support. Kickstarter is an amazing platform that provides exposure and funds to worthy (and some less worthy) projects that might ordinarily not see the light of day. There are many engineers, designers, film makers, etc out there that have amazing passion for their work, the ability to create something truly unique, and the drive to do it. But that isn’t always enough. Enter: Kickstarter.

We want to do a Kickstarter when the time is right. We thought this was several months ago, and we created a mockup Kickstarter page and video and got ready for a launch. Then we solicited some feedback from peers and the consensus was we weren’t ready. We just didn’t have the right message, and although our technology was significant, it didn’t look pretty yet. One of the major things we struggled with in this process was whether to make Junction a paid game for Kickstarter, or to keep it free like we originally intended.

On Kickstarter (and in life, in general) people like something tangible for their money. If people are going to pony up their hard earned cash for a video game, they want a copy. If the something is free, it is a tough sell to ask people to pay for it. That much seems obvious. To date, almost unanimously, successful video games on Kickstarter have offered a copy of the game as a reward to backers, most of the time at a discount. Seems perfectly logical, and it works very well. But what if you want to offer a free game? How can you offer people enough value to contribute funds?

Greed Monger has successfully answered that question, and definitely shown that a free game CAN make it on Kickstarter. Their goal was a modest $30k, but they were able to triple that number and raise $90k for a free game.

They had a very well thought out Kickstarter page, a decent video, and they kept people up to date on Greed Monger incessantly. But, in my mind, this wasn’t enough; they also needed proper incentives. Their incentives were very simple: they sold virtual real estate in their game. The more money you contributed, the more real estate you received. This is a concept very simple to understand, people understood where their money was going, and you can see in the numbers that people were willing to pay money for that real estate.

They had 243 backers at $25 to get one parcel of land, but then 122 backers at $100 for 4 parcels of land. One might expect (I certainly did) a heavy rate of decline in the desire to contribute additional money past the basic point of entry, but this did not prove to be the case. As a result, Greed Monger raised more money from the $100 tier than the two basic beta access tiers combined: $6675 for the $15 and $25 tiers vs $12,200 at the $100 tier. Amazing.

But then their $300 tier was even more successful. They gave out a disproportionate amount of land at that level (16 parcels of land at $300 vs 4 at $100) and they had 63 backers pulling in $18,900. WOW is all I can say. That incentive clearly works.

I have been studying Kickstarter for months and I have not seen such willingness to go beyond the basic tiers in any other game.

A free game can make it on Kickstarter. So that’s the route we will go, and now we can go confidently.

Oct 03

The Problem

We want people on the web to be able to see, in near real time, what players are doing in-game.

Intro

There are myriad ways of sending events of in-game actions server-side, so we won’t go into that. What we will go into is how we were able to store, query, and send these updates to a web page in an efficient, scalable manner. On the server side team we are more data experts and hackers than web developers, so there may be some more efficient ways to do little pieces of the puzzle. But, in general, we think this solution is simple, works very well, and should be very scalable.

Technologies Used:

EC2 - Virtual Servers (Please sir, can I have some more?)

Jetty - Java web service to collect events, serve data, and stream the events (we created an internal proprietary REST API)

Memcache - Store the latest events per user in memory in a scalable cluster

DynamoDB - Persistent storage of events, other data

Apache/PHP - Web server for presentation layer

JQuery/Javascript/HTML - Client side manipulation of the events

Part 1: Persistence of Events for Near Real Time Query

We had delusions of complicated grandeur when we first started thinking of an architecture to distribute events to the right place. Do we use a queue service? Poll our persistent store (DynamoDB)? Setup an in-memory MySQL cluster? Broadcast the event to all web servers? Keep track of all realtime streams and broadcast events to the appropriate server?

All are troublesome for various reasons. Some are complicated. Some require new dedicated servers. Some just won’t scale well.

Since we already make use of Memcache for other caching, and Amazon has a nice service to allow scaling Memcache without direct server management, we thought about ways to use Memcache for near real time events.

The actual solution was simple, whenever a new event is registered, we simple push it to Memcache with a key of lastevent|<userid>. A put to Memcache is very quick (~1 millisecond), so the amount of overhead to do this is negligible. We can expire these events very quickly too, we used a 2 second timeout.

Then to sense a new event all we do is simply poll Memcache every 1/2 second. Again, these operations are very quick, they take about 1 millisecond per query. Now if there were 10000 people online at once we might feel the heat, but if that were the case we could afford to throw some more Memcache instances at the cluster, and this is easy to do with Amazon’s ElastiCache.

So our methods of storage and query events are solved, on to streaming!

Part 2: Sending a Near Real Time Stream of Events

This part is easier than you think. Really all you need is a loop in a Java servlet to poll Memcache for new events, and if there is a new event you spit it out and flush the stream. There is just one little pitfall you need to avoid: endless loops. You will need to check the stream periodically to make sure it hasn’t closed, or else you could be just building up threads and eventually run out, not to mention do a lot more work than is necessary.

Here is the code for servlet:

String id = request.getParameter( "id" );
String lastEvent = "dummy";
int i = 0;
pr.append( "" );
while( !pr.checkError() )
{
	String event = getLastEvent( id );
	if( !event.equals( lastEvent ) )
	{
		pr.write( event );
		pr.write( '\n' );
		pr.flush();
		lastEvent = event;
	}
	Thread.sleep( 500 );
	if( ++i % 5 == 0 )//every 2.5 seconds put something out to the stream so pr.checkError() can know if it is closed or not
	{
		pr.write( '\n' );
		pr.flush();
	}
}

Obviously we paraphrased a bit here, but that is almost all of the code ofr our servlet. It works swimmingly.

The only problem with this methodology we see is that if events come in faster than every 1/2 second then we may not catch them. But we aren’t trying to be perfect here, so it was deemed an ok sacrifice. You can always poll faster/slower if necessary, or use that memcache grab to trigger more complicated logic, like a query to the persisted data layer for ALL new events in the last second or so.

Part 3: Getting Those Events to the Web Page

This is where we ran into issues. Stupid browser security!

Our first instincts were to use JSONP to output a stream of functions with json inside, so basically like this:

displaystuff( { "event": "kicked a box of donuts" } );
displaystuff( { "event": "ran into a donkey that he swears he knew from somewhere" } );
displaystuff( { "event": "read the lord of the rings trilogy backwards" } );

etc.

Have a function in the main page like this:

<script>
function displaystuff( json )
{
	//do something with the json to make it display in the webpage
	//something like 
	var html = processJson( json );//some function that does stuff with the json
	$("#liveevents").prepend(html);//need jquery for this one, this will prepend our html where we want it
}
</script>

And then include the url as a javascript include:

<script src="http://<server>/live?id=<userid>"></script>

It turns out that the browsers don’t want this to happen. The browsers wanted the entire file to be downloaded before evaluation would begin, and since we are streaming it potentially forever, the functions would never be run. Also, an even bigger issue is that javascript includes are no asynchronous, so the page would hang when it got to that javascript include. Booooooo.

So JSONP isn’t the way to go. And javascript includes aren’t the way to go either… so we thought we were in a pickle. Not the good kind of pickle either.

Iframes to the rescue!

Iframes load asynchronously. Yay!

Iframes can be invisible. Double yay!

If we change our include to an iframe like this:

<iframe height="0" width="0" src="http://<server>/live?id=<userid>" style="visibility:hidden;display:none"></iframe>

The page will load asynchonrously, so we can put that anywhere we like.

Ok that solves the page stalling problem, but what about an alternative to JSONP?

It turns out that because we are effectively streaming a webpage in the iframe, and the browser will render webpages as they stream, we can just put full fledged javascript in that frame like this:

<script>displaystuff( { "event": "kicked a box of donuts" } );</script>
<script>displaystuff( { "event": "ran into a donkey that he swears he knew from somewhere" } );</script>
<script>displaystuff( { "event": "read the lord of the rings trilogy backwards" } );</script>

As each line gets flushed, the javascript can be executed by the browser. We are winning!

Not so fast there partner. That function can’t be found, and even if it was, you don’t have permission to execute it anyways!

After a few hours of frustration, trial, error, and tears (not necessarily in that order) we found the solutions:

Because we are running Apache/php for our presentation layer, and Jetty as our data server (so both the game and the website have the same access to everything), they will need to be hosted on different servers, and some browsers are a bit picky about this to protect you against cross-domain javascript hacks.

Back in the servlet we need to add

pr.append( "<script type=\"text/javascript\">document.domain=\"yourdomain.com\";</script>" );

before the while loop.

And in the main html document we need to add

<script type="text/javascript">document.domain="yourdomain.com";</script>

Obviously substitute your actual domain for yourdomain.com. Unless that is your domain, in which case that is a pretty big coincidence.

Then for the output of the stream we just refer to the “parent” document like this:

<script>parent.displaystuff( { "event": "kicked a box of donuts" } );</script>
<script>parent.displaystuff( { "event": "ran into a donkey that he swears he knew from somewhere" } );</script>
<script>parent.displaystuff( { "event": "read the lord of the rings trilogy backwards" } );</script>

Codename: Junction

Feb 18

Things you should know when launching a Kickstarter project

Dec 11

A Free Game CAN Make it on Kickstarter - Congrats to Greed Monger!

Oct 03

More Junction Videos!

Aug 03

All Unsubscribe Links are Broken

Apr 20

Streaming (Near) Real Time Events to the Web for Junction

The Problem

Intro

Part 1: Persistence of Events for Near Real Time Query

Part 2: Sending a Near Real Time Stream of Events

Part 3: Getting Those Events to the Web Page

And we are golden!

More Screencaps of Junction!

Feb 06