Random IRC joke got me thinking

[Kawa]

<Kawa> https://logopending.tumblr.com/post/163366276108/codename-ouchman
<Screwtape> Kawa: So what you're saying is, Sierra should retroactively hire you.
<Kawa> no lol
<Covarr_Work> he's saying telltale should ditch their shitty crashy engine, switch to SCI, and hire him in the present.
<Kawa> SCI64?

It was at this point my thoughts ran away, thinking back to the Monkey Island remakes.

High-resolution widescreen graphics with alpha channels on views and background layers seems like an obvious feature, probably by leveraging PNG somehow. Rotating views, as per Phil's custom SCI0 terp, to go along with the existing zoom feature from SCI11, but with proper blending. Scrolling areas, as per the later games. Vorbis/FLAC background music, possibly on separate channels for volume control trickery...

And all that still with the lispy scripting language we know and love, and the same basic resource file style, extended where needed. I'd play it. I'd use it...

...as long as it's not Unity, because I'd rather like to play for more a minute or two at a time.

But yeah, wouldn't that be a cool hypothetical thing to have?

Inevitable mockup screenshot:

(click for bigger)

[MusicallyInspired]

I've had thoughts like this for ages. One think MI2SE has that MI1SE didn't have is extra frames of animation in between the standard cels.

One feature in the audio department that would be nice is loop begin and end points in samples (not bloody milliseconds, AGS made that mistake and now proper music control is exceedingly frustrating).

Or hey, integrated MUNT support. Right in the engine.

Something else would be to somehow replicate the function of palette cycling but in 24-bit colour. Obviously you can't have millions of colours in an indexed palette, but perhaps the engine could interpolate all the left out colours in between the gradient indexes of a standard 8-bit palette and fill in the gaps?

/dreams(?)

[Kawa]

I can confirm that FMOD doesn't support loop information in Vorbis files, but it does let you detect and parse arbitrary tags and set your own loop points, so you can detect and apply the LOOP_START tag, which is in samples. I shold know, I've done it.

I love FMOD, really.

[lskovlun]

<Kawa> SCI64?

High-resolution widescreen graphics with alpha channels on views and background layers seems like an obvious feature, probably by leveraging PNG somehow. Rotating views, as per Phil's custom SCI0 terp, to go along with the existing zoom feature from SCI11, but with proper blending. Scrolling areas, as per the later games. Vorbis/FLAC background music, possibly on separate channels for volume control trickery...

And all that still with the lispy scripting language we know and love, and the same basic resource file style, extended where needed. I'd play it. I'd use it...

Are you proposing we skip SCI32 entirely? Yeah, from what I hear of the ScummVM efforts these days, there are some thorny parts in it, but not having a look at its features seems a waste.

[Kawa]

Are you proposing we skip SCI32 entirely? Yeah, from what I hear of the ScummVM efforts these days, there are some thorny parts in it, but not having a look at its features seems a waste.

You may have misunderstood me a little. The idea here is an all-new 64-bit SCI engine, and to discuss what kind of features it would have that are enhancements of what the old versions have.

When I first pondered out loud about this, I mentioned scrolling backgrounds like in the later games. I could've listed those in the post, but I couldn't find a good way to enhance the idea. Though, looking at the Torin backgrounds and comparing them with other SCI32 games that have scrolling screens, I think "parallax without using weird stripe hacks" might do.

[MusicallyInspired]

Of course, Phil can attest to my craziness in this manner, but in my perfect world I'd like to be able to run, open, edit, make new games in, and have HD packs akin to something Kawa is talking about, for any version of SCI. Like a source port. If we're talking about making just a new version of the interpreter with modern features then I don't see why looking at each version of SCI and its functions (including SCI32) wouldn't be beneficial to that end nor would I imagine it not be done.

EDIT: Ninja'd

[Kawa]

It's like, if one were to make an all-new SCI engine, how would one take what the old versions had and update them? For example: from SCI0's 16-color views that couldn't scale to SCI1's 256-color views and SCI11's scaling, to SCI2's color remapping to approximate shadows at characters' feet... having hicolor view cels with an alpha channel seems like an obvious "next step", even if it's missing one or two inbetween.

[troflip]

Nothing SCI does is very complicated these days. This sounds like pretty much any engine or framework today. Unity, Unreal, Monogame, SDL, AGS, etc...

[Kawa]

Let me put it this way.

With a game like Thimbleweed Park, a player would recognize it as SCUMM (or "like the old Lucas games" at least). It is not actually SCUMM, though. Monkey Island SE was, quite ironically, more SCUMM than that. With the various VGA remakes of Quest games like KQ2/3, a player likewise recognizes it as SCI. It's actually AGS. A programmer (not just a player) with any historical interest can clearly see that it isn't.

Compare that with games like Sierra's own VGA remakes. Most of them may have been from AGI to SCI, but then there's Quest for Glory 1, and if you look at both games' files, just the names of them, you recognize them as basically the same engine. A player can make that judgment. *.DRV, RESOURCE.*, everything about the two versions screams "we are both SCI, but one's a later version".

If you were to acquire the script code for Thimbleweed, I guarantee you it won't look like SCUMM. Oh, it'll probably look like something in the same family, sure, but that's like saying C# is like C++ or Java. I'll bet it doesn't have costumes either, and a wildly different asset storage scheme. Especially if it's made in Unreal or Unity.

The idea with SCI64 is to have it actually be something that players and programmers alike could say "yes, this is a modern SCI engine" about. Sure, you wouldn't need DRV files, but that leaves RESOURCE.* and its actual internal format. And the actual script code? The kernel calls look different, but that sure looks like SCI to me.

[lskovlun]

Compare that with games like Sierra's own VGA remakes. Most of them may have been from AGI to SCI, but then there's Quest for Glory 1, and if you look at both games' files, just the names of them, you recognize them as basically the same engine. A player can make that judgment. *.DRV, RESOURCE.*, everything about the two versions screams "we are both SCI, but one's a later version".

People used to try to use SCI tools to open Dynamix games for this reason. It doesn't work. AGDS (the Dynamix engine) is boring from a systems perspective, btw. I remember interviews with the devs saying that they tried to make the system useful to nonprogrammers. That goal has been tried before (Cobol, anyone?), and it just isn't feasible at scale.

If you were to acquire the script code for Thimbleweed, I guarantee you it won't look like SCUMM. Oh, it'll probably look like something in the same family, sure, but that's like saying C# is like C++ or Java. I'll bet it doesn't have costumes either, and a wildly different asset storage scheme. Especially if it's made in Unreal or Unity.

They used Lua for scripting, afaik. As do Telltale.

EDIT: Nope. Thimbleweed is Squirrel. Still a third-party solution.