Insomnia sucks. Especially the night before a final exam.

On that note, sorry I haven't posted any news as of late. Been busy with the last week of school, finals week, and finding housing in Silicon Valley for the summer at Netscape. Luckily, everything seems to be winding down.

Silicon Valley is expensive. Extraordinarily expensive. This summer will be quite the learning experience.

Work on Acoustique is progressing. I've done some modifications to the API so that it can support memory-mapped file I/O (read: efficient). I plan to add support for MP3 first, since libmad's API appears to be easier than the others. Once that is complete, I will actually have a concrete library, and I can begin its integration into Sphere.

Thanks to the advice of a friend, I have seen the true light of game engine design. Because I have seen How Much Better It Can Be, it's very hard to work on Sphere anymore. I'm going to do what I can for 1.0, and then begin work on the next engine. The new system will even support the possibility of a Sphere compatibility layer. This is a good thing, as I can justify spending more time on the ideal engine design. I'll throw out some thoughts on the engine now.

In order to explain some of the new engine's design, let's investigate some problems with the current design. First of all, using JavaScript as a scripting language seemed like a good idea at the time. However, its lack of structure proved to be crippling as the size of a project increases. I got to thinking that having an object model like COM or CORBA or Java (not the language, the object model) or .NET would be quite nice. Garbage collection would be a necessity. The interface should also be low-level enough to support low-level networking operations, like sending an array of bytes on a socket. Implementing this in JavaScript involved some major kludgery and serious pain.

The second major problem with the current system is how inflexible it is. Sphere is designed to create RPGs, and it does that relatively well. However, it's currently a pain to create sidescrollers or any other type of 2D game. I started thinking about tilesets and maps one day, and I got an awesome idea. Why define a map as an array of tiles, when there are much more flexible and easier to code ways! For example, imagine this... You have a collection of images as part of your game: tiles/grass.png, tiles/water.png, and tiles/tree.png. Those will do for now. Conceptually, a map is a collection of 2D regions (usually rectangles). There would be a few basic types of regions: solid colors, images, maybe things like graphical primitives (lines, triangles, etc.). However, the real beauty of this system would be the ability to combine regions to make new objects. You could make a TiledRegion object and stick the grass image in it to have an area of grass tiles. Then you could build a Tree region and put some images in it however you like, and then place trees on top of the map. Need a pond? Just make a new type of region that contains the water image, and place it on the map. This system would make map creation a breeze, and it would work fine for any type of 2D game. It also allows for more efficient rendering techniques, and more potential for hardware acceleration. Sphere's design simply doesn't stand up to its hypothetical competition.

The third major problem with Sphere's design is how much it really sucks to maintain the editor. It was okay, for a while (I suppose I learned MFC from the whole deal, but that's of questionable value). But now, when it's time to implement new functionality, oh how I would kill for automatic garbage collection... Not having to worry about what objects own which, etc... It would also be nice to have a portable editor so that the Linux crowd will stop complaining to me. :)

Sphere's file formats are definitely less than ideal. I wish they were XML so I could modify them easily. The concept of spritesets and tilesets don't belong in the engine, either. They're necessary for good performance in the current system, though.

Basically, all of these issues piled up and forced me to consider a new 2D game engine design. I thought and thought and thought, and a solution to every one of those problems fell into place. First of all, the engine needs a new general scripting architecture. Java is perfect for this task. It provides garbage collection, static typing, a nice object model, and portability. It's also easily fast enough for low-level operations, and it supports atomic data types like bytes and ints. I have decided that my next engine will base its whole architecture around Java's object model. The engine will provide interfaces to native objects for rendering, sound, input, and anything the engine itself should take care of. Everything else will be built in Java. "*whine* But I don't want to script in Java!!!" Fine, use one of the many superb scripting language implementations for Java (i.e. JavaScript, Python, or Scheme). The only problem with this system is that the user would have to have a modern version of the Java Runtime Environment (5 MB or so) installed. I'll have to investigate the possibility of including the JRE with the engine installer.

I hope you could follow that. It's 5:00 a.m. and my head isn't working too well. :) Keep in mind, this doesn't mean I'm going to drop Sphere. I *will* release 1.0. After that's done, though, I want to spend my time working on an easier, more flexible engine with much greater potential than Sphere.