SLUDGE 2.0 - a work in progress

[Trumgottist]

As many of you know, I have been working with the SLUDGE source code for a while now, with the goal of getting it to run on Mac OS X. For the engine, that goal is very nearly there now, and I have started on the Development Kit. Today, Tim Furnish (the creator of SLUDGE as well as of the great game Out of Order) made me an official SLUDGE developer. Not only that, but since he doesn't have as much time for SLUDGE as he'd like, he also made me an admin of the project.

I've just completed a SVN commit of my working copy of the code, so now my changes are available at SourceForge. (I think I did it right, but if a Mac user wants to download it and try to build the engine to make sure I didn't mess something up, that'd be good.) It's currently only available in source form and in the SVN repository.

The purpose of this thread is to let you know that SLUDGE is now officially once more a work in progress, and is neither dead nor dormant, but also to start a discussion about where to take it. So, SLUDGE users, now is a good time to speak up! (Other people are of course also welcome to the discussion, if they want to.)

(I'll return tomorrow and post some more details of what I've done, and what I have planned, but for now this post is long enough.)

[Kickaha]

Well done Trumgottist! 

[NigeC]

Ditto what Kickaha said!
Shame I've never used SLUDGE or got a Mac otherwise I would of gladly had a go

[ad7venture]

Same here.  Great to see this project continuing, though. 

[Squinky]

I already knew what you were doing with SLUDGE, but I thought I'd pop in just to show my support.

[Trumgottist]

Time for details. This is what I've done, and what I have planned.

Additions and changes

While porting it to Mac OS, I've also changed the entire graphics system. It now runs through OpenGL, so a lot is done on the graphics card. Currently, full screen mode uses the same resolution as the desktop, and the game's aspect ratio is maintained by adding black bars if needed. That could of course easily be changed to be configurable, but I like it as it is now. One windowed mode and one fullscreen. Things shouldn't be made too complicated for the player.

The engine now also uses 32 bit graphics internally, including an alpha channel. This already makes the existing games, made with 16 bit graphics, look a little better - lighting and scaling works better, and I think all reasonably modern computers should be able to handle it anyway. I plan to let the dev kit take advantage of that, too, and allow (but not require) full colour graphics with alpha channels to be used.

The player can switch between full screen and windowed at any time. (Command+F, but Alt+Enter should be added too, since that's the standard on Windows.)

The Mac version looks for gamedata inside its bundle, so games can be distributed as a single app bundle (as it should be), and since app bundles are simply seen as folders in Windows, it's possible for people without Mac access to release their games for Mac too! (Are there any Windows installers that can be assembled on a Mac? If not, Mac users could always distribute the Windows version in a simple zip-file.)

A setup window (done natively in Cocoa on Mac, and should be in Win32 on Windows) is displayed when a game is started (sort of like in WME and AGS). Currently the options are full screen or not, and which language to play in. Since current games doesn't store the names of the languages they're translated to, it only lists "Language 0, language 1…". I want to add the language names to future versions of the dev kit. (The games will have to be recompiled to add that information.)

Saved games may be opened when the game is running in a different language than when the game was saved. This didn't seem to break anything.

I also want games to be able to specify better game icons. The current low res icons look a bit pathetic in a modern OS.

Missing Features

Backwards compatibility is important (I don't want to break the old games), and SLUDGE 2.0 will support almost everything the old SLUDGE did, but there are a few exceptions:

setBackgroundEffect and doBackgroundEffect are not yet implemented. That will be done.

Some transitions (disolve, TV and blinds) are not yet implemented. That will be done.

registryGetString is not implemented. I want to remove that function. A game has no reason to read from the registry. A SLUDGE game has never been able to write to the registry, and the registry is only available on Windows anyway.

launchWith is not implemented. launch is, so webpages and manuals can be opened, but launchWith is more problematic. It specifies which program should open a file. I don't see that as making sense in a cross-platform engine. Remove?

launch currently does not support opening SLUDGE games. Fix?

And finally, there's the movie functions. They're currently not implemented, and I don't think the old implementation is useful. (Play any format of AVI that happens to be supported on the computer.) I seem to recall compatibility problems with that already when the engine was Windows-only. As a result, I don't think the movie functions have been used by anyone. Do we want movie functions? If so, I imagine that sticking to Ogg Theora would be a better solution. But I have no use for the movie functions personally, so I won't be adding movie support unless it's requested.

The development kit

I've only just started on the dev kit, but my plan here is to integrate the tools into one IDE (integrated development environment). Main goal right now is just to get it running at all.

--

I think that's everything. Discuss!

[ad7venture]

Not sure if I understand the full screen mode, but if it maintains desktop res then it seems like it wouldn't be much purpose.  For instance, wouldn't a 640X480 just be a very small window with black all around if you were running a 1024X768?

Other than that, sounds great.  Opengl should make it a lot faster with more effects possible, like perhaps particle and full background sprites if desired.

[Trumgottist]

No, the graphics are scaled to fill the screen. Black edges only appear if they're needed to preserve the aspect ratio so things don't stretch in ugly ways.

[Erwin_Br]

Time for details. This is what I've done, and what I have planned.

Additions and changes

While porting it to Mac OS, I've also changed the entire graphics system. It now runs through OpenGL, so a lot is done on the graphics card. Currently, full screen mode uses the same resolution as the desktop, and the game's aspect ratio is maintained by adding black bars if needed. That could of course easily be changed to be configurable, but I like it as it is now. One windowed mode and one fullscreen. Things shouldn't be made too complicated for the player.

The engine now also uses 32 bit graphics internally, including an alpha channel. This already makes the existing games, made with 16 bit graphics, look a little better - lighting and scaling works better, and I think all reasonably modern computers should be able to handle it anyway. I plan to let the dev kit take advantage of that, too, and allow (but not require) full colour graphics with alpha channels to be used.

Whoo! This is my number-one wish coming true for SLUDGE: 32 bit graphics with Alpha Channels! 

The player can switch between full screen and windowed at any time. (Command+F, but Alt+Enter should be added too, since that's the standard on Windows.)

Neat!

The Mac version looks for gamedata inside its bundle, so games can be distributed as a single app bundle (as it should be), and since app bundles are simply seen as folders in Windows, it's possible for people without Mac access to release their games for Mac too! (Are there any Windows installers that can be assembled on a Mac? If not, Mac users could always distribute the Windows version in a simple zip-file.)

A setup window (done natively in Cocoa on Mac, and should be in Win32 on Windows) is displayed when a game is started (sort of like in WME and AGS). Currently the options are full screen or not, and which language to play in. Since current games doesn't store the names of the languages they're translated to, it only lists "Language 0, language 1…". I want to add the language names to future versions of the dev kit. (The games will have to be recompiled to add that information.)

Sounds good!

Saved games may be opened when the game is running in a different language than when the game was saved. This didn't seem to break anything.

I also want games to be able to specify better game icons. The current low res icons look a bit pathetic in a modern OS.

I agree.

Features to be removed

Backwards compatibility is important (I don't want to break the old games), and SLUDGE 2.0 will support almost everything the old SLUDGE did, but there are a few exceptions:

setBackgroundEffect and doBackgroundEffect are not yet implemented. That will be done.

Some transitions (disolve, TV and blinds) are not yet implemented. That will be done.

registryGetString is not implemented. I want to remove that function. A game has no reason to read from the registry. A SLUDGE game has never been able to write to the registry, and the registry is only available on Windows anyway.

launchWith is not implemented. launch is, so webpages and manuals can be opened, but launchWith is more problematic. It specifies which program should open a file. I don't see that as making sense in a cross-platform engine. Remove?

I see no problems in removing this.

launch currently does not support opening SLUDGE games. Fix?

Hmm, it's not a high priority for me, but I can see how this could be useful for people who might want to do exceptional stuff like episodic games that are linked together or something.

And finally, there's the movie functions. They're currently not implemented, and I don't think the old implementation is useful. (Play any format of AVI that happens to be supported on the computer.) I seem to recall compatibility problems with that already when the engine was Windows-only. As a result, I don't think the movie functions have been used by anyone. Do we want movie functions? If so, I imagine that sticking to Ogg Theora would be a better solution. But I have no use for the movie functions personally, so I won't be adding movie support unless it's requested.

The reason I've not been using movies is indeed because I want to avoid dodgy codec requirements. If a reliable and baked-in fuctionality would exist, without the need of downloading codecs and stuff, then I would very likely be using this functionality.

It would be great if I could not only play full-screen movies, but also play animations in smaller regions of the screen, for background animation for example.

The development kit

I've only just started on the dev kit, but my plan here is to integrate the tools into one IDE (integrated development environment). Main goal right now is just to get it running at all.

--

I think that's everything. Discuss!

I'm very excited! Thanks!

[Trumgottist]

The reason I've not been using movies is indeed because I want to avoid dodgy codec requirements. If a reliable and baked-in fuctionality would exist, without the need of downloading codecs and stuff, then I would very likely be using this functionality.

It would be great if I could not only play full-screen movies, but also play animations in smaller regions of the screen, for background animation for example.

Movie playback is now on my to-do list.

But if it's true that the movie functions are currently unused, this would be a good time to re-design movie playback completely. Let's remove the old functions and add brand new movie playback. (This means that I won't be able to add movie playback until I've got the Dev Kit up and running, but on the other hand the new movie playback will actually be useable.)

If a movie is playing already, the old movie will be aborted automatically and the new movie will start instead.

Movies are played in the centre of the screen. Don't play a movie wider or taller than your window. Any sound which is included as part of the movie file is ignored - instead, provide your own soundtrack using MP3s, WAVs or music - and the frames will run at the rate specified in the project manager rather than the rate specified in the movie file.

Movies will have to be rendered to an OpenGL texture (but that shouldn't be a problem - that's how Apple does their movie playing). Scaling it and placing it anywhere will be easy then. You say you want to use it in the background as well. My reaction to that is to handle it internally as a special case of a character that loads its graphics from a movie instead of a DUC file. That should give a lot of flexibility, and would even allow characters to move around it. The video could also be moved around, or locked into place like any other character. How does that sound to you?

Using the game's frame rate rather than the rate specified in the movie file still seems like a good idea though, and so is probably keeping any sound separate.

[Squinky]

No, the graphics are scaled to fill the screen. Black edges only appear if they're needed to preserve the aspect ratio so things don't stretch in ugly ways.

So, this is also true if, say, your game is created in a widescreen ratio and it's being played on a standard ratio monitor, right?

[Erwin_Br]

Movie playback is now on my to-do list.

WHOOO!   

But if it's true that the movie functions are currently unused, this would be a good time to re-design movie playback completely. Let's remove the old functions and add brand new movie playback. (This means that I won't be able to add movie playback until I've got the Dev Kit up and running, but on the other hand the new movie playback will actually be useable.)

If a movie is playing already, the old movie will be aborted automatically and the new movie will start instead.

Movies are played in the centre of the screen. Don't play a movie wider or taller than your window. Any sound which is included as part of the movie file is ignored - instead, provide your own soundtrack using MP3s, WAVs or music - and the frames will run at the rate specified in the project manager rather than the rate specified in the movie file.

Movies will have to be rendered to an OpenGL texture (but that shouldn't be a problem - that's how Apple does their movie playing). Scaling it and placing it anywhere will be easy then. You say you want to use it in the background as well. My reaction to that is to handle it internally as a special case of a character that loads its graphics from a movie instead of a DUC file. That should give a lot of flexibility, and would even allow characters to move around it. The video could also be moved around, or locked into place like any other character. How does that sound to you?

Sounds like a very elegant solution to me!

Using the game's frame rate rather than the rate specified in the movie file still seems like a good idea though, and so is probably keeping any sound separate.

Yes, this especially goes if you use these movies for backdrop animation purposes and not for FMV. (Even though as a developer I would make sure my FMV seq's would run in the same framerate anyway)

[Trumgottist]

No, the graphics are scaled to fill the screen. Black edges only appear if they're needed to preserve the aspect ratio so things don't stretch in ugly ways.

So, this is also true if, say, your game is created in a widescreen ratio and it's being played on a standard ratio monitor, right?

Yes. You can make your game in any crazy aspect ratio you want.

[TimFurnish]

Oh, hello. A few things...

1) YAY. I've wished for a while now that I had more time, and then just some time, to spend on SLUDGE, and on more adventure games, and other homemade stuff in general. Someone else spending time on SLUDGE isn't quite what I was hoping for, but given the alternatives, I'm over the bloody moon. Hoorah for Trumgottist!

2) Movies? Registry? Yeah, lose it. You're right - nobody seems to be using it, and it was... let's say "a first pass, early implementation" of support for both. I think that's a polite way of saying "half-arsed and a bit pointless as it stands". And, indeed, very platform specific.

3) Loading saved games which were made in one language when you're now playing in another language is an interesting one. Internally, strings in compiled scripts are stored with the data type 'String table entry' and the data being the string number. Once you load a string (e.g. run a function which mentions a string and then store the string in a variable) it stores the actual string contents instead. It's got to - you might have joined two strings together or chopped one into bits or built something up using any number of string-handling functions. So, when you save a game, playing in English, you could well get global variables, or even function-scoped variables, containing actual English-language text. Run the game in a different language and load the saved game, and you'll end up with a mix of English strings (contents of variables which were saved in the saved game) and the other language (functions which start running after loading the game will get strings from the new language table, not the English one). So you might see nothing bad happening, or you might see some interesting Franglais happening, or you might run into some code which says if globalVariable == "Hello!" and the two strings which would have matched if you'd stayed in the same language suddenly don't. Ouch. Who knows what the script's going to do in that case. Get into a no win situation? Possibly. Be afraid!

4) Rendering order. Or, in other words, "I want to use a movie as a background". I was, at one point, going to add a function with which a developer can specify the order in which to render things (parallax levels, background, characters, "on top" characters, text, mouse, movie... I think that's about all that should be reorderable). You should even be able to leave some bits out completely. Never got around to it, of course. It was one of those 'In the next big iteration' things after, it turned out, the last big iteration had ever emerged. Until now! Not that I'm saying it needs adding, but it was a think I'd thought once, so I thought I'd mention it aloud for the first time in case it's useful.

5) Did I mention hoorah for Trumgottist?

- Tim

[Trumgottist]

Thanks for the explanation of the language thing. Now I understand why you'd put that check there. I wondered about it a bit, but when removing it seemed to work, I just assumed that it was a leftover of something. Bad assumption. How about if the game were to switch to the language of the saved game and reload all strings? That should work, right? (That was my initial plan, but when removing the check seemed to work, that clearly was the easier solution to the problem.)

Oh, and I think a "hooray for Tim" is in order here. First writing a good game engine, and then letting us mess with it to improve on it is nothing less than awesome. *Plays a fanfare on my tuba.* Here, Squinky, you can play the third, bottom, part.