This post originated from an RSS feed registered with Ruby Buzz
by James Britt.
Original Post: Wii talk prep II
Feed Title: James Britt: Ruby Development
Feed URL: http://feeds.feedburner.com/JamesBritt-Home
Feed Description: James Britt: Playing with better toys
I’m putting together a sample app, trying to pay attention to all the little steps, all the things that need to be in place if you want a Wii-enabled Monkeybars app.
I’ve written a few small such apps, but each time there was some variation. Over time I’ve sort of settled on Here’s How You Do It, but, sadly, the reference for this is the set of previous examples. What I really want, at some point (if not by the time of my talk, then soon after) is that creating a basic Wii app is reasonably stupid simple. Getting started so you can play around should not be a pain in the ass, or no one (i.e. me) will do it.
For example, after you generate the basic Monkeybars app layout you need to have the WiiUseJ jars in place. Where do they come from? Well, right now, it’s “one dir up and two dirs down”, as I snag them form a previous project. I’m not so sure that’s a long-term solution.
Should these jars (and .so and .dll files) by in the git repo? I first though not, since those things are not my code, and folks would be better off grabbing whatever is the current version from wherever they call home.
But, seriously, what a pain in the balls. I have some idea what I need and I find it annoying to have to go find the right project with the right files. Now I think I’ll push then up with the Ruby code, ensuring that the all the files are right there, and that they are compatible. I could then go a git pull to slurp down the files and have them dropped off where they need to be. Or make a gem that provides a script for copying over all required files from a common local directory.
When a program wants to talk to a Wiimote it first needs to connect to it over Bluetooth. The Java code throws an exception if it doesn’t catch a connection signal coming off the Wiimote. To send that signal a user needs to press the Wiimote 1 and 2 buttons at the same time. You can watch for a (vague) message at the console telling you when to do this, but for a real application you really want some sort of message box.
My programs so far were having the controller kickoff the Wiimoting, with a signal to the view to toss up a “spinner” dialog box asking the user to hit 1+2. I used a retry loop to allow for some number of attempts before giving up should no signal come.
Some of this code is in a module that is part of WiiUserJRuby, but you still have to wire a few parts up. Writing yet another program, I’m wondering how to make this easier. My current inclination is to write a generator that gives you a controller and view with the default Wiimotable code in place. As part of my explorations with Jimpanzee (AKA my fork of Monkeybars) I added, in addition to code to allow an inline Swing DSL, some extra generators to take advantage of the inline Swing option.
I ended up taking that out and putting it into a tool called Rhesus (it made Rhesus pieces; assorted MVC tuples for use in Monkeybars).
Rather than keep adding a series of Groovy Cool Monster features to Monkeybars, I’d rather see a set of optional tools. <stong>Rhesus, for example, could provide a generator for kick-starting Wii Monkeybars projects.</stong>
This would allow me to keep the core code in WiiUseJRuby from being Monkeybars-centric. I saw how ingrained things were when I tried to hook my Wii code into a Gemini game. Among the assorted issues I ran into was the realization that it made zero sense to have core Wii Ruby code trying to signal a view; none of that exists in Gemini. I settled for just writing to the console. It’s hacky, but the Wii code was not set up for flexible notifications.
Now, I don’t want to spend that much time trying to account for numerous what-if’s, but I do want to encourage people to try things, and that means making things inviting. Make basic things simple, interesting things possible, keeping the barriers low.
Previous Topic
