Arcadia Preview 2 (version 1.0.489.0) is finally here!

I’m really pleased with Arcadia’s progress.  Arcadia’s features currently include selecting repositories (where game files are kept), scanning for games (based on a user-editable vocabulary of platforms), and (most importantly) searching for and running ROMs in your favorite emulators of choice.

Thanks to FlotsamX for his usability feedback for Preview 1.

Download Arcadia Preview 2 here.

Arcadia, my emulator frontend that manages a wide variety of classic gaming system files, is just around the corner!  I have a stable version right now, and am looking for beta testers.  (Contact me if you’re interested!)  Once I give Arcadia the ability to check for update to itself I’ll release it publically, but for now email me and I’ll give it to you.

I’m not sure why I instinctively personify computers as needy and with low self esteem, but anyway…

In rewriting Roomie, I built up the infrastructure in the core engine to allow me to easily add commands.  In the old Roomie, I tried to organize commands’ code as best I could, but I still ended up with big files with lots of functions, and a hulking switch statement at the top.

Here is the switch statement for the Z-Wave commands code file:

There was also another junction point higher up the line that would decide which kind of command was being called.  In RoomieRemake, I do things a bit more generically.  Every command is represented by a class, which all derive from a “Command” class.  That means I can just have this:

As I continue development I will optimize things like command selection, but the point here is that I don’t have a whole bunch of special cases for different kinds of commands.  This is just part of the code that makes a command run, of course, but part of the redesign included breaking up functionality into neat, orderly bundles.  The master list of commands is populated dynamically with reflection.

A big time-waster in the old Roomie was validating variables, so in my new approach that is all handled in the definition of a higher-level “Command” class, while subclasses of Command register what arguments they expect, their types, and even default values if applicable.

Here is the old code for the ZWave.PowerOn and ZWave.PowerOff commands.  Look at all of the duplicate code.  Several times after redesigns I would have to go and manually change many lines of very similar code.

Comparing that to the new approach, here is the ZWave.PowerOn command:

By the time the command class is actually defined, Command has been abstracted into ZWave command, which has been further abstracted to SingleZWaveDeviceControlCommand.  Verbose, sure, but by the time I get to defining the command, I know that all of the validating of variables and finding of the device and connecting to the ZWave controller have already been taken care of.  Plus, if I ever want to add functionality to a group of similar commands, I can just write in the code in a parent class’s definition.  That’s inheritance and type safety at work.

You might have noticed that I didn’t include the whole method signature in the above screenshot.  That’s because it’s reaaallly long.  Some might see this as a disadvantage, but a big problem I had with the old Roomie is not having enough information to work with to make the proper decisions.  Basic commands recieve as arguments the CommandInterpreter that is calling them, a Scope object that represents the nested scopes containing variables, and an XmlNode containing the original command XML.  (Did you remember that RoomieScript is an XML based scripting language?)

That Z-Wave command was already really abstracted, with arguments defined in higher abstract classes, so here’s an example of a command that derives directly from Command:

Here the constructor calls a method defined in the Command class that defines an argument of type String.  By the time Execute_Definition is called, the engine has already verified that the Text argument is specified.  If there’s a problem, the engine reacts appropriately.  The CommandInterpreter, which represents a thread, doesn’t care about all of these extensions to Comamnd, of course.  It simply calls the selected command’s “Execute” method, which is concrete in the base Command class.

Finally, here’s a shot of the two Solution Explorer windows.  On the left is the old Roomie, and on the right is RoomieRemake.  You can see that in the remake, extra functionality is in other projects, which RoomieRemake hooks into as plugins at runtime.  That way, anyone could write a pluggin for Roomie.

SO that’s what I’m working on.  I hope to release this sometime in the near future.  If you’re interested in testing, either Roomie or Arcadia, shoot me an email.  If you think I’m a huge nerd, well you’re wrong.  I’m more accurately a gigantic geek, but you could call me a dork anyway.

With Arcadia I have committed to research everything that I suspect will make for a better design. Because of this, Archaida’s backend is shaping up to be elegant and efficient. I researched how to do inheritance in C#, and have used that to save myself from writing a lot of code. This has drastically decreased development and testing time. I learned how to use basic regular expressions over the summer, and have used them in some areas (more on that later). For the frontend I decided to switch from WinForms to WPF. All I can say is that databinding is epic, and I still have a lot more to learn about it.

Here’s a shot of Arcadia in its current form:

I’ll hopefully release an alpha soon.

edit October 12, 2009 at 10:57am:

Also generics. Generics are amazing. (More on that later, too.)