It’s been a while since we’ve posted any news updates here (though we have kept the progress chart up-to-date.) Besides finally getting a working (Ogg Vorbis enabled) sound engine, there haven’t been many coding breakthroughs to report on. For the most part, we’re still just chugging along.

However, we do have some big news for today. After some consideration, we decided to finally release our engine code under the GNU LGPL. We had been discussing the possibility of open-sourcing it for many months, but today we took the plunge.

Having an open-source engine means that we can take advantage of free development tools like Sourceforge.net’s project hosting and version control systems. We decided to use Subversion, and we did the initial import of our code today. In accordance with our original plan from last year, we have dubbed the project SPECTRE, which stands for “Simple, Progressive, Easily Customizable, Tricked-out (alternatively, ‘Two-dimensional’) RPG Engine.”

Here’s what this means for Project Aqua:

1. Our engine development will benefit from using special tools such as Subversion, and possibly garner feedback or perhaps even patches from developers who decide to use SPECTRE for their games.
2. Project Aqua itself will still be freeware, but not open source. It will instead be a closed-source game that uses the SPECTRE engine, unless there is a change of plan later on down the road. In any event, the artists will not have to relicense their work.
3. SPECTRE can bee seen as an “open-source component” of Project Aqua. Conversely, Project Aqua can be seen as the flagship game made with SPECTRE. Any publicity one recieves will be transfered to the other, so both will benefit from the mutual assosciation.

Interested parties should visit the brand-new SPECTRE website at spectre.sf.net, where you can find our Subversion repository if you wish to check out our latest code.

If you have access to the forums, you may also read about our decision in more detail here: “The SPECTRE Project: Finally, some Version Control.“

News from the coding team:
RenderLine GL is now “Slightly More Than Barely Functional™”.

This means that we can start working on ‘everything else’, and actually test it. Robert says that we will now have near-monthly builds that show visible progress.

So, hoo ray.

The hot topic at today’s Aqua meeting was the graphics engine. A good chunk of the development work is dependent on having a solid graphics framework to work within. Once we have a mostly functional graphical implementation we can test out different functional elements of the game (collisions, battle transition, etc) that are at the moment entirely hypothetical. It’ll also allow us to produce a series of demo platforms for implementing the battle system, which will require a lot of hands on testing and tweaking.

My understanding is that the graphical portion of the engine is being concurrently developed in OpenGL and in pure Software rendering. I would like to prioritize the Software rendering at this time.

OpenGL is fantastic but requiring our gamers to install any packages to run the game properly is a big nono, and frankly M$ is trying to kill off OpenGL on Windows by forcing it to run emulated in DirectX in the Vista operating system.

Hopefully the coding team will concentrate on the implementation of Software rendering (This means you!) so that the rest of the development can go forward and we can start putting these scenes together.

Thank you all,
F34rl3ss L34d3r

Hey all, It looks likes our graphics engine will be able to support both pure java graphics AND openGL thanks to the great effort of Roman Tetleman!
I’ll mostly be taking a back seat to Graphics programming for now, and even more so when i hammer out Text and TextPipe classes, and add a few essential display algorithms to SpritePipe. With this in mind I think im going to make Roman our official Graphics Programming leader from now on if he accepts it.

In light of the speed up in music composition (good job TILT!) I had tried to assign a programmer(Johnathon Kurniawan) to work on sound programming with ogg vorbis support. But there is a real snag, the java ogg vorbis libraries are GPL. If it was LGPL then we wouldn’t have a problem. So we have a few options…

1. WAV: approx. 10MB per minute of music. Eats more memory and harddive space than Bob Marley w/ the munchies.
Zipping the wav file has an average of 8% compression. Practically does nothing.

2. MP3: approx. 1MB per minute. JMF now supports mp3 so implementation would be relatively easy. The downSide is the licensing. If we distribute more than 5000 copies of the game then we have to pay a flat royalty fee. Which SUCKS!!!

3. Ogg Vorbis: approx. 1MB per minute. No royalty fee is involved as it is patent free compression scheme. But there is basically only one full Ogg library and it is very confusing, and it is GPL. Meaning we would have to release our source code as well… not an option. Roman has suggested we could use a loophole which would have to be researched but might provide a way around the constraints of GPL. I’ll say right now that making our own Vorbis decompression audio library is NOT practical and NOT being considered.

4. MIDI: approx. 50KB - 150KB per minute. By far the easiest to implement and distribute. I don’t deny that midi songs can’t sound good. But they are very very limiting for musical expression. Using midi for the game has pretty much been ruled out.

So those are our options. Other, more nefarious, methods of getting around copyright and licensing issues, have been considered But I’d like to explore more legal options for now. If you have any suggestions including libraries you knows of, or alternative audio formats please comment.