WebFWD

Gameleon and the map editor – a WebFWD project

More than 9 months ago, we were working on a web game, having all the nice HTML5 stuff like Canvas, WebSocket, CSS3. We were playing a lot with experimental code in NodeJS and Redis. We had all the nice scripts and plugins and quite a good architecture to make the game possible.

We lacked one thing though: a powerful editor. Since we had 8 years of nothing but web development experience, we were keen on making this web too. We didn’t like Flash though or anything which isn’t a web standard or open technology, because it was restricting us from using what we made on all the devices we had through the office, in the same way (tablets, phones, laptops, desktops).

Creating an editor

So, we’ve started making Gameleon for Shay, our game architect. He did quite a lot of Dungeons and Dragons and played with many of the RPG editors out there. We thought that he was good just like that, without any programming knowledge, and we wanted to give him the means to make anything in our game, without coming to us.

The first thing we made was the map editor. One thing was sure about this: we didn’t want to have any kind of limitations, such as tiles. What we love doing is drawing the maps ourselves, in any way we see fit. The one thing you can never know about a random picture is where the obstacles are. For that, we made a polygon editing tool, which can define just that. It is like a mesh applied on top of the map, giving it the logic for collision detection later.

Probably this video demonstrating how a map is built will be of more help:

Processing a map

In this article i’ll try to discuss a bit about how the map is processed and turned into a walkable, obstacle friendly surface.

When it comes to making a friendly way to define areas, using vectors is the way to go, as you probably saw in the above video.

A map is defined by vertices and points. They are sent to the server via WebSocket, in JSON format.

The struggle when having a good map is to have that good mixture between freedom to create as much content as you want, yet be able to determine what surface is an obstacle and have a very fast collision detection system and path finding.

image

The best mix of these two we’ve found to be in a grid. Using A* and QuadTree to determine the shortest route and the collisions between objects, no matter what size, became a lot simpler. By the way, all objects defined on a map, are treated as circles. When we determine if an object collides with another (in a combat situation for instance), we can make one of the objects move to the nearest empty area, while still being in range of the target.

So, this is why we are going to transform the vector map we’ve just received, into a grid, having a square of the size of 8 x 8 points. Experimentally, we’ve determined it is a small enough square to have a small number of collisions, and yet be effective when searching across long distances (for instance, searching for the shortest path between two points A and B on a map of 3200 x 2000 points).

Determining the squares

To determine the squares a polygon is going to cover, we use a brute force technique. Yes, it may sound crude, but it is quite effective. First, we determine the rectangle covered by the polygon.

enhance.prototype._determineRectangle = function( points, poly )
{
    var minX = null, minY = null, maxX = null, maxY = null;
 
    for(var j=0;j<poly.coords.length;j++)
    {
        var currentPoint = points[ poly.coords[j] ];
 
        if( minX == null || currentPoint[ 0 ] < minX )
        {
            minX = currentPoint[0];
        }
 
        if( maxX == null || currentPoint[ 0 ] > maxX )
        {
            maxX = currentPoint[0];
        }
 
        if( minY == null || currentPoint[ 1 ] < minY )
        {
            minY = currentPoint[1];
        }
 
        if( maxY == null || currentPoint[ 1 ] > maxY )
        {
            maxY = currentPoint[1];
        }
    }
 
    return { minX: minX, minY: minY, maxX: maxX, maxY: maxY };
}

image

Checking point positions

Once we have that, we start going through each point of that rectangle and check if the point is inside or outside the polygon. The theory behind this is to draw a horizontal line passing through that point and check the number of intersections with the polygon’s vertices. If the number of intersections is odd, then the point is outside. If the number is even, then it is inside.

enhance.prototype._pointInPolygon = function( x, y, poly, points )
{
    var j = poly.coords.length - 1, oddNodes = false;
 
    for(var i = 0;i < poly.coords.length; i++)
    {
        var pointI = poly.coords[i],
            pointJ = poly.coords[j],
            _pointIY = points[ pointI ][1],
            _pointJY = points[ pointJ ][1],
            _pointIX = points[ pointI ][0],
            _pointJX = points[ pointJ ][0];
 
        if(
            _pointIX == x &&
            _pointIY == y
        )
        {
            return true;
        }
 
        if(
            ( _pointIY < y && _pointJY >= y ) ||
            ( _pointJY < y && _pointIY >= y )
        )
        {   
            if(
                _pointIX + ( y - _pointIY ) / ( _pointJY - _pointIY ) * ( _pointJX - _pointIX ) < x
            )
            {
                oddNodes = !oddNodes;
            }
        }
 
        j = i;
    }
 
    return oddNodes;
}

This way, we mark the walkable and non-walkable areas of the map. However, there are those special situations when you want to mark an area as walkable or non-walkable dynamically.

image

Say you have some debris and you don’t want that area to be walkable, but once the debris are destroyed, that area has to be changed. So, we keep in a separate vector, the actual points covered by each polygon.

Setting names

In the map editor, you are being given the ability to name polygons, both for esthetic purposes – to notify the player that he is entering “The Killing Fields” for instance, and to lookup via scripting.

The scripting names are automatically given – ZP01, ZP02, etc. – to ensure their unique name.

In the script editor, you can use an action named setWalkableArea, and send as parameter the polygon name. When the action is executed, the server will broadcast to every member on the map, the points which are suppose to change their state, thus updating the map grid with ease. No additional processing will be done.

image

Say you attach this to the event of an object being destroyed, which was right on top of that area. This would create the illusion that the object itself was an obstacle and that it is now removed.

Neat, isn’t it?

Part of Gameleon

The code above is part of the editor and this coding standard can be found throughout the entire Gameleon code.

Hope you enjoyed this short intro into how we see maps and games being created. If you want to know more, have a look at Gameleon and follow us on twitter: @gameleonMain.

The complete source code is available on GitHub.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)

Notes on developing an API – Mobozi, a WebFWD project

HTML5 has made it easy to do a lot of really cool stuff on the mobile web, but one thing that is still pretty difficult is dealing with photos. Android has supported access to the device camera via the File API since version 3.0 and iOS opened it up last Fall with iOS 6. Allowing users to snap and upload photos in HTML5 is not as simple as just connecting a form to a database however. With a multitude of devices, OS versions, and browsers the image files come in different orientations, sizes, and with different encoding.

I frequently encountered this headache when developing HTML5 apps, which lead myself and my partner to create Mobozi. Mobozi is a front end library that optimizes and normalizes images across mobile devices, OSs, and browsers and also a simple API for photo upload and serving. This post is a brief overview of how we went about creating the API to to be functional and also easy and effort free for developers to use.

Planning

The first thing we did was map our all the functionality we would need and walk through the different use cases and flows from our users perspective. We thought about things like formatting and version control and how we could structure them to make it as developer friendly as possible.

We also considered data formats and decided to support JSON, XML and JSONP in order to keep the API as flexible as possible. We also made sure to model the API calls in a way that they were predictable and did not require the developer to guess. For example, to add an item, POST method is always used and to retrieve GET is used.

Security

Next we thought security, one of the most important parts of any public facing API. We decided to serve our API from a subdomain (https://api.mobozi.com) and allow CORS (Cross Origin Resource Sharing) on this domain only (our main domain and all other sub domains don’t entertain any request that originated from a different domain). Additionally, CORS on Apache is a great resource.

Developer Experience

Once all the nuts and bolts of the domain had been decided upon, we had to think about how developers would actually get access to and implement our API. We decided to provide an API key and use an HTTP token authentication in order to authenticate them. We also spent a lot of time refining our docs and are continuing to listen to feedback in order to get them as streamlined as possible.

Technology

Once we decided on the functionality the API would need to provide, as well as how it would be implemented, we had to choose a stack to build it on. We chose PHP/MySQL because it’s stable, scaleable, and most importantly because our team was very comfortable and familiar with it. Next we began searching for a framework that would keep our API lightweight but also offer our users a very quick response time.

After researching and testing out different API frameworks we found two that met our needs – Limonade and Slim. Limonade is a PHP micro framework for rapid web development and prototyping. Slim is also a PHP micro framework that helps you quickly write simple yet powerful web applications and APIs.

We eventually decided on Limonade because it was easier to implement and provides functionality we needed like clean URLs and cross origin request handling. Slim was powerful and light as well but had issues with cross origin requests as well as with the auto loader.

Here is a brief example from our API. This code will allow you upload an image from any device and get back the URL where it is being stored.

Include this snippet in your page’s head

<script src="http://zeptojs.com/zepto.min.js"></script>
<script src="//js.mobozi.com/v1/mobozi.js"></script>
mobozi.init('123456789');
function uploadImage(){    
    var myFile = document.getElementById('idimage').files[0];
    var imageData = {
        "file": myFile 
    };
    mobozi.image.uploadGetUrl(imageData,function(response) { 
        if (response.status == 201){
            $('#imgUrl').html('URL: ' + response.data.imageUrl);
            $('#upImage').attr('src',response.data.imageUrl);  
        } else {
            alert (response.error);
        }
    });
}

Include this snippet in your page’s body

<input id="idimage" name="idimage" type="file" accept="image/*"/>
<button type="button" id="btnup" onclick="uploadImage();">Upload Image</button>
<div id="imgUrl"></div>
<div><img id="upImage" src=""></div>

A working example

Outreach

So the functionality has been hashed out, the plan of attack decided, and the code written; what next? Get developers to use the thing! And hopefully get feedback from them on how to make it better. This is what we’re currently doing at Mobozi by holding a Hackathon (awesome HiFi speaker for the winner). More details in that page and feel free to ask any questions at founders@mobozi.com.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Wercker – Continuous Delivery Made Easy – a webFWD project

There is a great quote by Marc Andreessen who said that “software is eating the world”. What Marc means by this is that software is defining every industry we know; we’re no longer buying records at our local retailer but stream them via Rdio or Spotify. Skype is now the largest telecommunications provider and we’re even talking about the software-defined data-center.

The cloud has become the defacto distribution mechanism for these software services, but has also allowed for disruptive change in how these services are delivered and consumed. Whereas it used to be the case that you would have to purchase a new version of your favorite word processing software at your local retailer, with the cloud, updates can be pushed out incrementally.

Introducing wercker

The key enabler for this new way of developing software is continuous delivery. Software is eating the world, and wercker makes it taste better.

There are several successful companies out there which are big proponents of continuous delivery such as Netflix and Etsy. It is wercker’s mission to democratize continuous delivery for every developer and was founded on this very same premise in the beginning of last year by me, Micha Hernandez van Leuffen, and my cofounder Wouter Mooij out of frustration with existing solutions.

This video introduces wercker and presents our vision on the product:

How it works

Wercker’s flow is simple; it integrates with popular version controls platforms such as Github and Bitbucket on one end and Infrastructure-as-a-Service providers and Platform clouds like Heroku on the other end.

We run any unit tests you might have included in your project and subsequently present the results on a comprehensive dashboard.

You are able to define different environments or deploy targets for, for instance staging or production to which you can deploy your project with a push of a button.

Software is better developed together so wercker also captures the social dynamics that are paired with continuous delivery. The activity feed showcases who in your team broke the build or deployed to which environment. This increases transparency and trust within your team.

Open Source

Apart from offering wercker for free to open source projects we are also in the process of opening up wercker’s build environments. These environments are similar to Heroku’s buildpacks, allowing developers to define not only their own programming stack that they would like to use on wercker, but also the various build and test steps that they want to run.

New languages and frameworks can be integrated with ease as we’ve built these environments upon Chef cookbooks which can subsequently be used for both provisioning and deployment as well. Cookbooks and recipes are already a very big open source movement, which we’re stimulating even more.

The Future

We’re very excited that we’ve raised a seed round led by Shamrock Ventures, Amsterdam-based MicroVC Vitulum Ventures and Greylock Partners. The funding will help us grow our platform and expand our operations.

If you are a developer, sign up for the beta at http://beta.wercker.com. We are also interested in hearing what programming stacks developers are leveraging for their applications and to which environments they are deploying.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Launcher.io – Launch and run free open-source web applications in just 30 seconds – a WebFWD project

There is no longer any doubt: web apps are the focal point of the cloud. From database-as-a-service to platform-as-a-service to security-as-a-service and beyond, the entire *aaS model has the web app as its center of gravity.

If you’re a full-fledged developer, then taking full advantage of an app-centric universe is no big deal. Creating new web apps from scratch using frameworks like Ruby on Rails, Drupal, Django, or hundreds of others and then deploying those apps in the cloud is part of your daily bread and butter.

The mission

The mission of Launcher.io is quite simply to make it vastly easier for developers and non-developers alike to create and deploy their own web apps with a single click of the mouse. Launcher was founded by me, former AppFog director of product Maciej Skierkowski, and I have taken what I have learned in my time in the platform-as-a-service (PaaS) space and used that knowledge to make app deployment even more dead-simple than a typical PaaS platform does.

How it works

So how does it work? Launcher enables you to deploy so-called “jumpstart” apps with a single click. If you’ve signed up for a Launcher account, all you have to do is click on a jumpstart’s button and you’ll be prompted for basic information, and Launcher will do the rest of the work.

From there, you can manage your app however you like. Frameworks like Drupal, WordPress, or Concrete5 provide you with an intuitive in-browser interface for modifying your app, whereas frameworks like Ruby on Rails, Flask, ActionHero.js, and others will require more in-depth web development knowledge.

Launcher: great for non-developers

The benefit for non-developers is that it makes using all of these platforms easier than ever before. Want to start a new WordPress blog? All it takes is signing up to Launcher and clicking a button, and your blog is up and running in the cloud. The rest is up to you. Are you starting a company and want to set up Drupal to run your content management system and ThinkUp for social media analytics? Also a click and a few keystrokes away.

Launcher: even better for developers

For developers, the benefits of Launcher involve speedier adoption of new apps and frameworks amongst potential users. Let’s say that I’m a Java developer and I just created the most bleeding-edge CMS currently available. If Drupal is a Cadillac, then my new CMS platform is a fresh-off-the-assembly-line Maserati: it’s blazingly fast, it has a wonderful in-browser console, and it has millions of useful plugins that Just Work.

If users wanted to use my CMS in a pre-Launcher world, they’d have to do it the hard way: download it onto their machine, run appropriate configs to make it cloud-ready, learn how to use a VPS (or a PaaS, which is a very recent development), and so on. But with Launcher, potential users can give my new CMS a spin in just a few seconds and have it running in the cloud, and making my CMS Launcher-ready provides little to no modification on my part.

The app landscape is extremely competitive, and anything that can speed potential adoption that quickly is a massive win for me as a developer. Launcher is simply an unprecedentedly direct pipeline to my new SaaS product.

Under the hood

Surprisingly enough, Launcher is amazingly simple in how it works behind the scenes. When an end user clicks on a jumpstart, the browser makes an AJAX request to a remote service kicking-off a Resque worker that deploys the app with AppFog or CloudFoundry.com. Setting up an HTML page to handle a Launcher jumpstart involves simply loading the jQuery and Pusher JavaScript libraries and inserting a few lines of JavaScript (check out the docs for more info).

Your app will, however, need to be registered with Launcher to be included in the Launcher App Store. If you’re interested in doing so, don’t hesitate to get in contact with me, as I am looking to expand the range of offerings in the app store in the coming months.

He’s also looking to expand the number of PaaS providers that support jumpstarts. At the moment, Launcher enables you to instantaneously deploy apps on either AppFog or Cloud Foundry, but Launcher is in principle compatible with any Cloud Foundry-compatible PaaS API. If you’d like to add a new PaaS, simply go to the Providers page, click “Add Provider,” and input a name, API endpoint, and other information.

More on the way

Launcher is a new project, and has a great deal more in store for both developers and end users. Jumpstarts for OpenPhoto, Redmine, and SugarCRM, to name just a few are coming soon.

If you’re a developer, startup, or enterprise looking to take advantage of Launcher, email maciej@skierkowski.com for more information.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Linklib – lets film lovers and filmmakers send time synced links from videos to phones – a WebFWD project

Have you ever googled films and TV-shows while you watch them? Do you think Youtube’s popup annotations in the middle of a video are distracting?

Having shot a documentary about the Pirate Bay for 4 years I wanted to embed links directly into the film to give the audience more nuances in the complex and bizarre story about the Swedish file-sharing site. I constantly google videos I watch.

What problem is Linklib solving?

Linklib lets filmmakers, film fans, journalists and bloggers send time synched links from a full screen video directly to their audiences’ phones. Instead of googling an actor, fact checking an election video or feverishly trying to find the soundtrack to that TV-series, just pick up the phone and the information is right there.

When I stumbled over popcorn.js in 2011 I realized the amazing potential of embedding time synched links into films, but I was still looking for a way to hide the hyperlinks from the fullscreen video.

So we built Linklib, a system that sends time synced links from streamed video to phones. That way you can read up on that actress, fact check that election video or follow that rapper on twitter while you’re watching the video. Without obtrusive annotations in the frame.

Linklib is a free and open library of time synced video commentary. Film directors, journalists and fan communities can add facts and comments to give films more depth and nuances. The system works just as well for feature films, documentaries, music videos, educational and commercical films. Linklib is an open source project that wants to tell better stories by using the open web.

How it works

The basic components of Linklib’s system are a remote, usually a smartphone or a tablet, and a video viewer, typically a computer. The remote shows synchronized links from the video viewer and can send and receive events such as play, pause, forward and rewind. To sync the phone with the video we show a QR code that you can scan with your phone. At the moment our video viewer can show youtube, vimeo and html5 video streams.

A lobby server handles the communication between the remote and the video. The remote uses socket.io to communicate with the lobby server and is written in JavaScript.

For users to be able to add videos and create link feeds of their own we’ve built a web based authoring tool focused on simplicity. The tool is built using Twitter bootstrap and jQuery. All links and account information are stored on a mysql database on Amazon AWS.

Components

  • Remote – shows synchronized links from the Video Viwer and can send receive events such as play, pause, forward and rewind.
  • Video Viewer – Shows a youtube or vimeo stream.
  • Lobby server – handles communication between Remote and Video Viewer
  • Authoring Tool – Web based system that allows users to add videos and create link flows for them

APIs and Libraries

  • Remote uses socket.io to communicate with Lobby server and is written in JavaScript.
  • Lobby server is based on node.js
  • Video viewer uses popcorn.js to play videos
  • All links and account information are store on a mysql database on Amazon AWS
  • Authoring Tool uses Twitter bootstrap and jQuery

Help us test out Linklib

Are you a filmmaker looking for a way to tie closer bonds to your audience? Or a Game of Thrones-fan looking for a way to fill your favorite episode with geeky references? Maybe you want to throw in a bunch of research that you couldn’t explain in your last conference video? Or you’re a fashion designer that wants to reveal the details of your catwalk? If you’re a film producer you could fill your youtube trailer with your characters’ social media and reviews, like the great documentary Indiegame: The Movie here beneath.

You can also add mashups and remixes to that banging new Outkast music video! And help activists worldwide spread information that doesn’t make the mainstream news! Linklib puts the web into videos without ruining the traditional viewing experience.

We just launched a beta and we’d love your feedback about bugs and features!

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)