[Scummvm-devel] ScummVM 1.0.0 release schedule

[Travis Howell]

Eugene Sandulenko wrote:
> On Sat, 11 Jul 2009 13:26:10 +1000
> Travis Howell <kirben at optusnet.com.au> wrote:
> 
>> I'm really starting to get tired of this, where was any recent 
>> discussion about making the next release ScummVM 1.0.0?
> We discussed it only with Max.
> 
> * The manual seems never will be finished, our attempts to make anybody
>   work on it failed. 
> 
> * Majority of our engines, SCUMM included were stable
>   for years. 
> 
> * Our product has been used in several commercial releases
>   quite successfully:
> 
>   - GOG.com
>   - SoldOut for Broken Sword 1&2
>   - Snowberry for Gob1-3
>   - Atari for HE games <cough>

Our public testing is unfortunately more lacking with each new release 
cycle. With nasty regressions still passing through our testing stage, 
and only found later (often too late). I expect this will continue, 
until most game engine are complete, and no longer in such active 
development.

The game engines from Revolution Software, were all based off the 
original source code, so able to offer much better support.

Atari clearly didn't test the Wii ports of their HE games well, or they 
would have noticed our bugs, or maybe even that ScummVM was been used.

>> Considering the initial focus of ScummVM has always been on SCUMM 
>> engine, I still think it would be better to wait until all SCUMM
>> games (except Moonbase Commander) are supported. The remaining HE
>> games are mainly a case of bug fixes and additional u32 code, with
>> the addition of 16bit color support in the gsoc2009-16bit branch.
> There is nobody working on PCE Loom, Sega MI, MM NES, MM C64, MM Apple,
> FM-TOWNS games.
> 
> This goal is just unrealistic.

I only meant support for all games (except Moonbase Commander) based off 
the SCUMM game engine. Not all ports of those games, which is completely 
unrealistic, I agree.

With 16bit color support progress through GSoC 2009, and more progress 
on u32 code been made, it seems worth the longer wait.

The recent progress on MM Apple/C64 (see patch tracker item), and on 
sound support for Amiga version on the Secret of Monkey Island would be 
well worth waiting longer for too.

>> For ScummVM 1.0, I think we should really considering dropping
>> support for older saved games in the SCUMM engine, and starting fresh 
>> (Supporting saves from ScummVM 1.0 onwards) too. Several code changes
>> in the SCUMM game are limited, due to continued support for older
>> saved game.
> In any case we will have to provide backwards compatibility. Thus, time
> of this change (I hear about it for the first time) does not affect our
> release cycle.

Actually I meant to completely break compatibility with older saved 
games in SCUMM game engine, in order to clean up and improve the code of 
the game engine.

>> Before the ScummVM 1.0 release cycle, we could compile a list of
>> planned changes, drop save game compatibility for short time (few
>> weeks?), make the required changes to SCUMM engine, and only offer
>> saved game compatibility from that point onwards.
> You can easily do it for 1.5, 2.0, whatever.

No, my idea was to make the following changes to SCUMM game engine, if 
agreed to:
* Completely drop compatibility for older save games
* Take time (few weeks?) to clean up and improve code of the game engine 
(without the current limitations, imposed by keeping compatibility with 
older saved game).
* Only offer save game compatbility from that point (ie ScummVM 1.0) 
onwards. Maybe start with save game version 100, and display GUI message 
if person attempts to load an older saved game.

Completely breaking compatibility with older saved games in SCUMM game 
engine, should be made during the beta stage. Making that change after a 
major release (ie ScummVM 1.0) would not be a good idea.

>> Another important point, the tools are still lacking a decent GUI,
>> which I think would be essential for a non-beta release too.
> Tools never were a priority for us. Usually they're one shoot usage per
> game. GUI is nice and desired, but so far even command line utilities,
> being decently documented served its purpose.

Many people are unable to use a simple command prompt, let alone more 
complex command line tools.

With the GUI wizard interface task of GSoC 2009 progressing well, it 
seems well worth waiting for the results. Which will make it much easier 
for users to use the features (especially sound compression) offered by 
our various command line tools.

> Besides, which makes me wonder, what will happen with our tools builds
> for other platforms once GUI is there? Will command line utilities stay?

The last blog entry mentioned command line options will still be 
available, although I'm not sure whether through separate tools.

> Adding DW support is pretty big milestone. With 1.0 we will also have:

Adding any complete game engine is a big milestone in my opinion.

>   - GMM

Which still isn't quite complete, or completely handled by all game engines.

>   - Faithful Adlib emulation

Which has not been tested (at least not through our release cycle), and 
still not enabled by default.

>   - MPEG2 support dropped

Still exists in code, and might be used again, since it is required by 
port of game used by another game engine.

> We were not beta for a long time now. Thus, we decided to change the
> numbering scheme. And yes, it is just numbers, nothing will change in
> our release cycle.

Whether we are still beta quality is debate, with many of our game 
engine based off reverse engineering in many ways. It is difficult to 
know what still could be missing, or isn't quite right, and what bugs 
may still have not been found (even after all this time).

Our core is quite good, along with many game engines (especially those 
based off original source code). But I still think it would be better to 
wait longer for the first major (1.0) release.

> Perhaps for 1.5 we will have 16-bit support, DW freewared. SCI support
> for 2.0, etc.

No, those version jumps, sound too high, for too little changes.