Ben and I gave a presentation at JavaOne on what’s new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the “Java crashing the entire browser” problem.
Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.
Wouldn’t it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.
It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.
A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won’t even have to use it. We can just point out to the crowd.
Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.
We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.
At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.
Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.
The video below shows you a demo of the application, the source code with an explanation, and more details.
XSketch is “a multiplayer word sketch game. It is programmed in Adobe Flash, Java, Ajax, and GWT. Gameplay is similar to Pictionary where you sketch a picture with the goal of having other players guess your word and vice versa.”
Ryan Dewsbury creator this game, which he adds to his collection of GPokr and KDice.
One of the examples shown is a pretty cool Tetris game:
As Orto simulates the multithreaded nature of Java with yields and timeouts this is of course hard-core simulation (read: hack), but the benefit are that you could Java Games on non-JS devices, like the iPhone.
Orto also seems to try to simulate the Java UI conventions, thus making it easy to convert existing applications (to a certain degree as there is no equivalent in HTML for the richness of Java UIs unless you build them yourself as libraries ike Dojo or Quoxdoo did).
Sometimes you want Monday to be a Friday, so we have ProtoRPG, a role playing game written by Pierre Chassaing in JavaScript using Prototype and Script.aculo.us.
Walk around, add to your inventory, and feel like you are playing your first RPG many moons ago, on a Friday.
Jacob Seidelin is doing great work, and for something fun, he build a piece of Super Mario in just 14KB of JavaScript:
Here's an experiment in keepings things small and confined to one Javascript file. There are no external image files or anything, everything is rendered with Javascript using either canvas elements or old fashioned div-making tactics (for IE). The sprites are stored in custom encoded strings in a format that only allows 4 colors for each sprite but in turn only takes up around 40-60 bytes per sprite.
We also have MIDI music embedded as base64-encoded data: URI's. No music for IE, though, and it seems all the other browsers each have different, minor problems with it, but it sort of works.
In this chapter, we took the languages of CSS and JavaScript well beyond the tasks for which they were intended?the presentation and basic behavior of HTML documents -- and used them to create an interactive 3D maze.
First, we looked at the basic principles by which triangles can be displayed using only CSS. We then extended that concept to render a perspective view, creating the illusion of three dimensions. Next, we established a convention for specifying floor plan data, and for dynamically translating that data into a perspective view. By adding listeners for user events, we successfully created an interactive maze that can be completely customized and extended. To top things off, we added some usability aids, such as a top-down map, and accessibility aids including keyboard navigation and captions.
While I haven't delved into the details of every method that comprises the game script (there are plenty of comments, so I'll leave that for you to pursue in your own time), I hope this chapter has convinced you to look at JavaScript in a new light. The possibilities really are only limited by your imagination!
The goal of the KDice is to win all territories. At the end of each turn the number of new dice randomly distributed is based on the largest number connected territories for that player.
I've never played Kdice but considering that there are over 30,000 registered players on the site, this game must be a blast!
In the "I-can't-believe-it's-not-Flash" category, Robert Schultz pointed us to his amazing World of Solitaire website, implemented with YUI, MochiKit and PlotKit:
It's hard to single out a favorite feature, from it's ability to rescale the size of the cards when you resize the browser window to its impressive animations and smooth drag-and-drop. Definitely worth a look!
Bryan Brunton has created Empires, a game of expansion and conflict set in an alternate history prior to World War II. You and your opponents are leaders of the most powerful nations in the world. Empires was based upon the board games Attack! and Axis and Allies.
Dojo, DWR, and JavaServer Faces are the weapons of choice.
The Opera folk have released an API that allows you, the developer, to be able to monitor all of the remotes that are connected with The Wii Remote API.
This means that you can watch up to four people buzzing around the screen:
Polling the status of a remote
The Wii Remote data is accessed through the opera.wiiremote object. This object offers a single method opera.wiiremote.update(n) which is used to obtain the status of an individual Wii Remote. The method expects a single parameter; the Wii Remote number. The number is zero-based, so it starts at 0 for the first remote, and ends at 3 for the fourth remote. The method returns a KpadStatus object, which has several properties that give information about the remote.
This update method can be called as often as is needed to obtain a fluid response, but note that the Wii is not as powerful as most desktop computers, so it is important to make sure that it is polled only as often as the script that uses that data can process it. For example, if a script uses the Wii Remote status to update the display of a canvas element, and that update will take perhaps 50 ms to update in Opera on a desktop computer, it may take over 100 ms on a Wii. Attempting to use a polling interval of less than 100 ms will cause the response to appear very sluggish.
Note that the opera.wiiremote object only exists in Opera on Wii, so it is important to check for its existence, as well as the existence of the opera object, before attempting to use it.
, Showcase
