SLUDGE - The Wishlist

[Trumgottist]

As you know if you've followed the big SLUDGE thread, work on the SLUDGE engine is currently mostly small tweaks and bugfixes to get it ready for a non-beta 2.0 release. (I have no time table for that, and don't feel a rush to get there either, since as far as I know only one person besides myself is currently working on a SLUDGE game, and Erwin's Bad Timing isn't about to be released any time soon.) That's all good, and I'm making progress steadily. (If someone were about to release a game, I would be able to fairly quickly fix enough things to be able to remove the beta label and feel good about it.)

But my to-do list is very short. Besides small tweaks and bugfixes (see the big progress thread for details), there are only two items on it:

* Allow launching of another SLUDGE game from within a SLUDGE game.
* Movie support.

So this thread is for discussion of possible future features. Feel free to add your own, particularly if you consider using the engine in the future, but outsiders are also welcome to comment.

[Trumgottist]

I'll follow up on my own post by thinking about what form movie support could take. This is what I'm thinking (keep in mind that I'm not even close to start implementing it right now, so these are only thoughts thrown out there to get comments):

* It's enough to support one movie format: Ogg Theora.
* Sound is not to be supported in a movie file. It's easily played separately if needed anyway.
* Movie framerate must be the same as the game's framerate. (If they differ, the game engine will simply ignore the framerate set by the movie.)

The movie is loaded by a function similar to addCharacter:

addMovie (thisObject, atX, atY, 'moviefile.ogg', width, height, loopIt);

It is given an object type, so that it can be handled in mostly the same way as characters.
atX and atY specifies where the bottom centre of the movie is located. (It can be floated with the floatCharacter function.)
width and height are maybe unneeded? The alternative would be to simply use the size of the video.
loopIt is a flag that defines if the movie should be looped or not. Maybe it should also offer an alternative to freeze the last frame or remove the movie when it's played through?

Then it can be treated much like a character. It can be scaled (or not), moved around, partially obscured by characters and z-buffers, …

What other functions would be needed? A pause function seems natural. Anything else?

[Trumgottist]

Another feature I've thought about that might be neat would be vector graphics (SVG) support. But for that to be useful, those graphics should be handled internally as vector graphics too (otherwise they could just as well be converted to PNG or TGA anyway and there'd be no difference), and that might be too difficult to pull off without making it way too slow to be useable.

[ad7venture]

I guess the main thing I would look for would be 2.5 d, but that would be very hard to do I'm sure.   If you were thinking about it, there's a pretty cool model loader in beta right now called Assimp that has a flexible license.   Possibly particle effects, and shaders would be cool.  I think they would be all right for this type of engine, but it still would cut some people out of the loop.  There are a lot of computers that don't support them.  Maybe more focus on 1st person games.  I think with a lot of engines it's just a throw in.  You can do it if you do all these convoluted schemes.   I really haven't had time to look at it since I'm working with Flash right now.  There are a lot of ease of use things that can really help a beginner write an adventure game and I think are quite important.  That's really the main reason for the popularity of AGS.  Sometimes those things can also be annoying to advanced users, so it's a little tricky to do.

[Trumgottist]

I guess the main thing I would look for would be 2.5 d, but that would be very hard to do I'm sure.

Assuming that you by 2.5d mean adding 3d models to the mix, yes, it would be hard, but maybe not for the reasons you think. Getting the actual models in should be pretty straightforward (it is after all already built on OpenGL), but getting that to play nicely with the existing ways to put graphics on the screen… It would require a big redesign of many things, and doing that while keeping backwards compatibility… I think someone wanting to do that would be better off making a new fork off the SLUDGE source and make a new thing with it.

(If someone wants to prove me wrong, please do. The source is freely available, but I'm not about to spend time adding 3d models to SLUDGE. It is a really good 2d adventure game engine, but it doesn't make much sense to try and make it do everything. It's a great hammer, but not every problem is a nail.)

Or better yet, just use a real 3d engine. Grim Fandango was made over ten years ago. Computers can handle full 3d now, and the game would probably be easier to make that way anyway than going the 2.5d route.

Possibly particle effects

There's been a lot of hype regarding particle effects in the past. There's nothing magical about it - it's just a bunch of (small) objects. That being said: If anyone has a concrete suggestion on what they'd like to be able to do with it, I'm listening. (I'm not interested in coding up something just to be able to add a cool buzzword to the feature list.)

and shaders would be cool.

I've started on a journey to learn shader programming (GLSL) for use in the SLUDGE engine, (I hope to be able to pull off better antialiasing and new special effects with it, as well as fix a small graphical bug) but I don't see how exposing that beast directly to game authors would be helpful. Or was this a part of the 3d-character suggestion? If so, I see your point.

Maybe more focus on 1st person games.

In what way? Panoramic views like Pipmak is something that's clearly out of scope for SLUDGE, and better handled by something else. If you're thinking of something else, please elaborate.

[Erwin_Br]

Something I could really use is more control over playing sprite animations. More concrete: It would be cool if I could specify (in the anim function) a range of frames that only plays once (or an x amount), while the other frames keep looping normally.

When would I use this? Well, sometimes my ego makes gestures while talking. I don't want to repeat these gestures all the time, because that looks silly. (Currently I "fixed" that with a really loooong anim command)

So it would be nice if I could play the gesture once, and after that the ego continues his normal talk animation.

But I see other possibilities too, when certain animations need to start with an intro. Of course I can just play the intro frames using another anim command, but still. When talking and walking your character this is not possible, so there is the value of this proposed feature.

[Erwin_Br]

And here's another one. Lip sync. I have no idea how hard this is to implement, but maybe it's a nice challenge.

This never was a huge deal for me before, but I can see the added value of realistic mouth movement today. It still is not *that* important to me, but I would certainly use it if it was available, and it would definitely contribute something to the game. Think about it

[Erwin_Br]

Is it already possible to fade sprites in and out? That would be a big thing for me. I seem to remember this is already possible, but I'm not sure. 

[Trumgottist]

Something I could really use is more control over playing sprite animations. More concrete: It would be cool if I could specify (in the anim function) a range of frames that only plays once (or an x amount), while the other frames keep looping normally.

Good idea. Do you have a suggestion for syntax?

And here's another one. Lip sync. I have no idea how hard this is to implement, but maybe it's a nice challenge.

That would be cool, yes. The question here is how to implement it in a useable way. Playing back an animation that is lip-synced is easy, but how do we create that animation? I don't have a clue.

Maybe these two animation things are related. If we have a new tool (or a new function in the sprite bank editor) to make and preview animations, and then add a way to play a predefined animation that could make things easier. Creating all animations with the anim() commands often take a lot of trial and error to get right . (I'm just thinking out loud here.) The speech function could also take an animation file as an extra argument.

I still don't know how to create the lip-synced animation in an easy way, though. (Easy for the game maker, I mean. Theoretically, you can already lip-sync your talk animations, but that's far from feasible to do with the current tools.)

Is it already possible to fade sprites in and out? That would be a big thing for me. I seem to remember this is already possible, but I'm not sure. 

You can do that with setCharacterDrawMode(). (But it would be easy to create a more flexible version of that function that takes a numerical parameter instead of fixed constants. Five levels of visibility? Internally, there are 256. Same with the various fog and shadow things.)

[Erwin_Br]

Good idea. Do you have a suggestion for syntax?

How about:

anim (spriteBank, frame, frameLoopStart);

Where frameLoopStart is the frame number when, once reached, the animation starts looping from.

I don't think it's necessary to specify a number to play the first frames (before the loop), but you could always do something like:  anim (spriteBank, frame, frameLoopStart, loopAfterX);. It might confuse users, though.

That would be cool, yes. The question here is how to implement it in a useable way. Playing back an animation that is lip-synced is easy, but how do we create that animation? I don't have a clue.

Maybe these two animation things are related. If we have a new tool (or a new function in the sprite bank editor) to make and preview animations, and then add a way to play a predefined animation that could make things easier. Creating all animations with the anim() commands often take a lot of trial and error to get right . (I'm just thinking out loud here.) The speech function could also take an animation file as an extra argument.

I still don't know how to create the lip-synced animation in an easy way, though. (Easy for the game maker, I mean. Theoretically, you can already lip-sync your talk animations, but that's far from feasible to do with the current tools.)

Hmm, sounds like a lot of work. I'll have a look at how AGS handles this. And I believe Wintermute also has this feature, but I'm not sure.

Maybe these engines implemented a really simple and basic system where it just looks at the letters in the string, and display the associated animation frame at a given (setup-able) duration. This is of course not the most ideal way, but it's not ridiculously time consuming either. But again, I'll check it out.

You can do that with setCharacterDrawMode(). (But it would be easy to create a more flexible version of that function that takes a numerical parameter instead of fixed constants. Five levels of visibility? Internally, there are 256. Same with the various fog and shadow things.)

Yeah, I was aware of setCharacterDrawMode(). I would love to be able to set it numerically to create more fluid transitions.

[ad7venture]

For lip sync, you might want to look at some software like Magpie Pro.  I think that most of them work along those lines.  You can download the trial version.  Basically it's a timed version of the wav file that shows which mouth positions to play at a certain time. 

Particles are usually used for smoke and fire effects, but that would only be useful for 3d rendered models, which might be questionable since most people have used this engine for hand drawn games.  It might be better to just specialize for hand drawn games.  Shaders are generally used for bump mapping on 2d objects, again it's a 3d type behavior that might not work out.

Yeah, I guess I was thinking of a Pipmak type deal.  That probably wouldn't be a good idea either since it would be better to start with another engine.

Mostly, I guess ease of use would be the best way to advance, but I haven't used the engine at all.

[Erwin_Br]

Thanks for the link, ad7venture. Looks like Magpie is doing exactly what I had in mind. I realize it's rather complex, though.

It would already be awesome if Sludge automatically detects pauses in the speech audio file, so it can display a closed mouth.

[ad7venture]

It would already be awesome if Sludge automatically detects pauses in the speech audio file, so it can display a closed mouth.

I had thought about something like that also, mostly just doing a volume level test during the playing of a sound file, but I couldn't find a sound library that really did that.  If it's not possible that way, you could break the sound files up at the pauses and add them in manually. 

[Squinky]

Here are some things I'd like to have -- not all are engine-related, but they're definitely SLUDGE-related.

- An online version of the SLUDGE manual for cross-referencing, perhaps in wiki form. I haven't used SLUDGE regularly in years until working on my latest baby, so I keep booting into Windows just to read the help file. (I'd offer to set this up myself if I had time, but sadly, I don't.)
- A separate forum on AD for all SLUDGE-related posts. (Erwin, could you implement this?)
- A Linux port of the engine, perhaps even the dev kit.

[Kieran Millar]

- An online version of the SLUDGE manual for cross-referencing, perhaps in wiki form. I haven't used SLUDGE regularly in years until working on my latest baby, so I keep booting into Windows just to read the help file. (I'd offer to set this up myself if I had time, but sadly, I don't.)

Hungry Software actually has a wiki which you can find here:
http://editthis.info/hungrysoftware/Main_Page
(I had to dig through old news posts on the site to find it)

I'd be up for copying the Sludge manual into the wiki there (seems the best place for it). I don't know if anything has changed from the "old" SLUDGE as far as the manual goes, so I'll just copy the old manual in and then we can change it as necessary.