To my shock however, it seems the scummc website suddenly died sometime last year, so nobody was able to check out and learn from the only functioning third party SCUMM compiler.

Thankfully i was able to obtain a fairly recent copy of the files in the SVN repository, and coupled with the SVN commit logs on the mailing list i have been able to re-create the repository using GIT as far back as revision 359.

So what are you waiting for? Check it out on github!

That is the conclusion after spending most of my time on my last project writing a framework, in order to make the project “easier” to write.

The trouble is every minute you divert to the framework, half of your project dies. And since there is an inherent division between project and framework, by the time you have everything working you have lost your original train of thought.

Then you realize: the project is way behind schedule; there goes a cool feature that could gave landed you a multitude of sales. Or even worse, everyone has lost interest.

Instead, I suggest the following mode of thought:

• Find an existing framework that does most of what you require.
• If the framework falls short, rethink your approach.
• If you find your code has become a mess, re-factor it into a small library.

Don’t be tempted to spend time writing a monolith of a framework. And beware the trap of thinking you can turn it into a product in itself; after all, there is a reason why a large proportion of frameworks are free.

Anthony explains in great detail how he built the AT-AT, but i couldn’t help but think “I’ve got a better way of doing this!”.

Last year i made a CSS Transform Exporter for Blender, which can take any scene and generate a corresponding version in a nice and simple HTML page.

So it can take this:

And turn it into this:

Admittedly simple, but it does show off the potential power in adopting CSS3 and HTML5. After all, who needs to use Flash when you can make everything work in actual web browser instead?

Still, i learnt quite a lot about what is expected from a game development job interview. And i thought i’d list my top 3 points here, which are general enough to apply to any game development profession:

1) Bring a laptop to show off how good you are

This is perhaps the most important point. You cannot rely on thumb drives, cd’s, or the internet.

There is a high probability that your demos will not load properly on your interviewers systems. So be sure to show them on one that you know does work – yours.

In addition, the very fact that your demos are on your own hardware gives that extra inclination that you made them yourself.

2) Brush up on common knowledge pertaining to your profession.

Chances are that you will be given some form of test, either on paper or through meticulous quizzing. The aim of this is to weed out clueless candidates. Make sure you are not clueless.

3) Have something to say, questions to ask.

If you find that the interviewer is talking more than you are, then chances are they are more interested in themselves rather than who they should be interested in – you.

Have something well-formed to talk about. Don’t let the interviewer get carried away talking about some obscure technical concept.

The focus should be on you.

So after waffling on with the usual interview talk, your interviewer will usually ask “Any more questions?“. At this point, if you answer “No” then chances are you will fail the interview.

Why? Well, remember that there are two parties being interviewed. You and your interviewer. They are giving the reins over to you, in a sense.

So now is your last chance to stand out from the crowd (if you haven’t done so already). If you do not take it, then there will be little to distinguish yourself from the rest of the candidates.

To conclude

Anyone else have any more suggestions? Feel free to comment below!

While the process was relatively straightforward, i have decided to reproduce it here so anyone else in my predicament can get their applications up and running in RubyCocoa with the minimum of fuss.

Preamble

Firstly, open up the Project Info box by double clicking on your project in the tree.

Your project needs to use the 10.5 sdk, since that is the only version which MacRuby supports. If you are planning on targeting 10.4, then MacRuby is not for you.

In addition you need to make sure you enable the Garbage Collection for Objective C, otherwise the MacRuby framework won’t link. In case you have forgotten where this option is, go to the build tab, select “All Configurations” for the configuration, then look for “Objective-C Garbage Collection“.

I selected “Supported“, though you can use “Required” as well.

Spot the difference

While a MacRuby project is similar to a RubyCocoa one, there are a few differences. Obviously, they use different frameworks, the initialization in ruby is slightly different, and of course there are a few big differences in the interface.

1) main.m

RubyCocoa

#import <Cocoa/Cocoa.h>
#import <RubyCocoa/RBRuntime.h>

int main(int argc, const char *argv[])
{
    return RBApplicationMain("rb_main.rb", argc, argv);
}

MacRuby

#import <MacRuby/MacRuby.h>

int main(int argc, char *argv[])
{
    return macruby_main("rb_main.rb", argc, argv);
}

2) rb_main.rb

RubyCocoa

require 'osx/cocoa'

def rb_main_init
  path = OSX::NSBundle.mainBundle.resourcePath.fileSystemRepresentation
  rbfiles = Dir.entries(path).select {|x| /\.rb\z/ =~ x}
  rbfiles -= [ File.basename(__FILE__) ]
  rbfiles.each do |path|
    require( File.basename(path) )
  end
end

if $0 == __FILE__ then
  rb_main_init
  OSX.NSApplicationMain(0, nil)
end

MacRuby

framework 'Cocoa'

# Loading all the Ruby project files.
dir_path = NSBundle.mainBundle.resourcePath.fileSystemRepresentation
Dir.entries(dir_path).each do |path|
  if path != File.basename(__FILE__) and path[-3..-1] == '.rb'
    require(path)
  end
end

# Starting the Cocoa main loop.
NSApplicationMain(0, nil)

3) Framework link

RubyCocoa

Located in /System/Library/Frameworks/RubyCocoa.framework

MacRuby

Located in /Library/Frameworks/MacRuby.framework

4) Generally speaking

Ignore the OSX module, use framework instead of require for frameworks, and don’t use ib_outlet or ib_action.

RubyCocoa

require 'osx/cocoa'

class MyClass < OSX::NSObject
  ib_outlet :myOutlet
  ib_action :myAction do |sender|
  end
end

MacRuby

framework 'Cocoa'

class MyClass < NSObject
  attr_writer :myOutlet
  def myAction(sender)
  end
end

In addition, since MacRuby is based on Ruby 1.9 (as opposed to 1.8.x) it would be a good idea to check for incompatibilities in your code which arise from changes in Ruby 1.9.

Celebrate

With any luck, provided you have followed the above and managed to convert all of your RubyCocoa code over, your app should now run with MacRuby!

Fortunately there is another way to use web apps offline on the iPhone. It turned out to be so simple i wondered why i didn’t think of it before. Well, here is how you do it:

EDIT: also downloadable as Using_iPhone_Web_Apps_Offline

Hey presto! While you do get a warning, you can still use your lovely web app offline. Unless of course, you restart your iPhone or close the window. If that happens, your data will still be safe if your web app uses the database api to store it. Just hope you get your signal back so you can start working again. :)

(Not to mention that Flash 10 is supposedly going to be able to compile C code, thus making my complete port more or less redundant)

Now i would have stopped there, if i hadn’t noticed that haXe targets multiple platforms, including every web developer’s best friend, JavaScript. Thus i thought, “Would it be possible to run SCUMM games in Javascript?”. For the answer… well, take a look!

Yes, that is an image of OpenQuest running in a web browser, specifically Firefox. It can run in other browsers too, though to date i have only tested Firefox and Safari, the latter of which mysteriously crashes.

And if you want, you can try it yourself by clicking here. A word of warning though, it is highly recommended that you use Firefox to run it. Otherwise you might get a nasty crash, or a big disappointment.

As previously, just about enough is implemented to get the first room of OpenQuest loaded. Actors, verbs, objects, and sounds are not implemented, though it would certainly be possible. However the engine runs much slower than in Flash, so i doubt anything that could be considered to be “playable” could be implemented with it.

Still, i feel I’ve now accomplished what i set out to do when writing this interpreter – that is to push haXe, Flash, and JavaScript to the limit and see what i can get out of them. And of course, learn a bit more about SCUMM too.

Again, i would like to congratulate the ScummVM team for their SCUMM interpreter and Alban Bedel for his scummc compiler. Without their efforts, i wouldn’t have had any code or references from which to base my haXe-based SCUMM interpreter.

Edit: Source code available from github.

Edit: No longer crashes in Safari provided you are using Safari 3.1.2 or later.

While i did get it working as a proof of concept, there was a really off-putting bug in the image decode routines which meant that any displayed room graphics were a jumbled mess.

Recently though i decided to do a bit of intensive debugging to try and solve the problem. To sum it up, after:

• Turning on the trace output in the Flash debug player
• Telling scvm and hiscumm to dump crucial info their trace logs
• Comparing the output of scvm and hiscumm using diff to see where the differences were
• Modifying the trace output to pinpoint the problem while dealing with script timeout errors.

I managed to fix the decode routines. Now instead of a jumbled mess like this:

You get something more like this:

Which safe to say is much nicer to look at. It’s also as far as i am willing to go with this SCUMM implementation.

With a lot of work put into it, i’m sure it could run Day of the Tentacle or Sam N Max Hit the Road. But there would not be much sense in doing that, except for that 5 seconds of awe after seeing it running in a web browser.

As previously, you can download the hiscumm code for reference here.

Safe to say, i ended up with this rather odd Flash-based app written in haXe which when provided with the ”.000” and ”.001” files of any unencrypted V6 SCUMM game will be able to load and play it. Or rather, attempt to.

Sadly i bumped into a problem in the image decode routines, so what is displayed isn’t pretty. But it is quite capable of executing enough opcode’s to get to the input event loop in Alban Bedel’s road example for his scummc compiler, which is great.

As for other games, i would doubt that they would get very far. A lot still needs to be implemented in the runtime.

In any case, if you dare you can try out my Flash-based SCUMM interpreter by downloading and extracting this archive. Simply load “test.html” into your web browser. Note though that you will need Flash 9 in order to run the interpreter.

In addition i also decided to open up the code for everyone to look at. It’s a mess, but it works. You can grab it from here.

Finally i would like to congratulate the ScummVM team for their SCUMM interpreter and Alban Bedel for his scummc compiler. Without their efforts, i wouldn’t have had any code or references from which to base my haXe-based SCUMM interpreter.

What is amazing about it is that it uses the original data files – something which i never considered would have been possible with flash. But then again i’ve not quite been keeping up with all of the technical advances in flash over the years, so it is really no surprise.

The demo is available here. For those of you who might have checked out the pre-release versions of Doom, the demo plays very much like them – as in you can’t shoot anything and there is no AI. Hopefully in the future these issues will be resolved and it’ll be that much more interesting to play.