Last month I started working on EtherQuest again. It is a project that I started a few years back and work very casually at. It is a curses based RPG game written in Ruby. I started out by writing a somewhat MVC based, high end, curses wrapper in ruby called Scill, and that right now is almost done (about 90%). On top of that I’ve begun work on the etherquest engine, but have just started on it so it is only about 10%. I’m optimistic about this iteration of etherquest. This is the third time that I’ve completely rewritten the code from the ground up. There are some issues with scill that I need to work out before it is going to be done (and I think it will take me a couple of months to get there). I’ve also got a nice website keeping updates on the progress with screen shots and such. Check it out:

http://etherquest.rubyforge.org

About a year ago, I had an idea for a simple ruby project that would be used to make a form of animated movies. The concept was simple. You would create a ruby class as such:

class Tree

def pos

[Math::sin(@ticks)*3,Math::sin(@ticks)*5]

end

end

Then the program would run and for every class you define it would call as needed. It would set the @ticks instance variable each round and call the methods to figure out the position, size, rotation, and layer for this frame, then once it has gathered all of the information for a frame, it would paste them together, thus generating the frame. Once completed, it would use an external tool to glue the frames together into a video, and would most likely leave audio up to the user as well. There are also some other classes such as a main class the sets the size of the video, fps, etc, and also a glob class in case you want to encapsulate many objects to be treated as one, such as the many objects making up a person or a forest. Commands would look something like:

• ruvie new
• ruvie frame 400
• ruvie frames 1-399
• ruvie render
• ruvie package

Some other objects that I was considering adding support for would be sounds (but then I’d have to add support for sound mixing, fading, etc) and fonts (which would be doable). I came up with this idea about a year ago and haven’t even attempted it yet, and don’t plan on any time soon, but it would be fun to work on if I do ever get around to it.

I mentioned in a past post, that I am working on a ruby curses application framework. At this time, I am about 1/3 completed with it, and it looks very promising so far. I am calling it “Scill” which is an acronym for “Simple Curses Interaction Layout Layer”. I’ll try and give a brief summary of what it is going to be like.

require 'scill'
$scill.start

That is a sample of a very simple scill application. When you require scill it initializes itself and also sets up a basic scaffolding making application development easier. You then just replace the scaffolding one piece at a time till you application fully replaces it. It is not going to be one of those great window based curses libraries, in fact, it doesn’t really have any kind of windowing. That is what I mean when I say simple. Their are four parts to the scill screen.

There four parts of the screen are the header, footer, root, and dialog. These four parts are all rendered and handled by a more general root class but the root class that you would use only allows drawing in the root area. The header and footer are pretty easy to see where they are and what they do. At all times there is a header, a footer, and a root. They can be interchanged to draw different screens and such. A dialog (not implemented yet) will sit ontop of the root window in the middle. There can only be one dialog on the screen at a time and while a dialog is present, the root can’t draw onto the area that is being covered by the dialog. Dialogs can be chained so that you can have submenus and such. I plan on implementing a rich suite of dialogs including confirm, menu, progress, text entry, text editor, and file selector.

The design is very modular and threaded. When it starts up (at this point in development) it splits up into 6 threads. Each thread handles some different aspect of the program so that tasks like input or networking don’t stall screen updates, or virual world persistance. In the center of the framework is a messanging system, and you communicate to the rest of the program via these messages. Each thread sets a list of messages that it can handle and when a message of that type is at the front of the queue it is popped off and passed to that thread.

Just as soon as things begin to get solid and stable, I’ll will port my “Plauge and Pestilence” game over to it as well as write a number of other nice games. I will then release the whole lot for all to play with, though you may not find curses based games all that fun. I on the other hand do and that is why I am creating this, because there are no good modern curses based games out there.

In reference to which Desktop should be used in Rubuntu, I think that it ought to be gnome. First of all there isn’t all that grand of support for ruby in either Gnome or KDE, but Gnome seems to have just a little bit more. There are a few interesting applications writting in ruby for gnome such as gnome-art. In addition to this, I think that editors such as cream, scite, gedit, and freeride ought to be included. Documentation is a must too. Ri, fxri, the pickaxe, and why’s book all must be included too. At this point, there aren’t that many games written in ruby, but we’ll have to dig and see what we can find to include because we must have games as well.

About two weeks ago, I wrote a ruby version of the card game “Plague and Pestilence”. It is currently console based with AI’s too. I haven’t released it to anyone yet, because I am currently working on a game wrapping library built around ruby curses. I haven’t had much time to work on it yet, but when I get some more of the details about it, I’ll be sure to post them. Also, once I get that library done, I’ll be sure to write a number of games for it as well!