SCUMMC and AGS Conversion

Started by subspark, Wed 23/04/2008 08:09:06

Previous topic - Next topic

subspark

From a technical standpoint, has anyone tried converting their AGS game to SCUMM C and what challenges lie ahead for somebody willing to try?

I'm hoping to test the two systems together with a friend to see how much work is invloved. Has anyone done this?

http://alban.dotsec.net/Projects/ScummC

Cheers,
Paul.

DoorKnobHandle

Well, the SCUMM engine format is completely different to the AGS engine, so I guess there just isn't a way to "port" them. With games it's not like going from .wav to .mp3. It probably be the easiest to rewrite the game if you want it in both formats. But why do you even want that? What advantage does it give you? What can the SCUMM engine do that AGS can't replicate?

Khris

It allows to run the game on almost every computer... :)

DoorKnobHandle

Well, as far as I know, AGS does run on win32-emulators on Linux, right? So that just leaves the Mac-snobs and... really... who wants them to play your game? :p

Anyways, I'd be very surprised if "porting" was possible there, so there really isn't any other option than to write for two formats if you must.

Khris

Exactly, there's really two challenges here: mastering the almost assembler-like SCUMM language and mustering the will to do a game twice.

subspark

I guess. It's an interesting test we are doing anyway. Not so much a full blown game but rather a simple experiment that can be run on ScummVM on a PSP.

Cheers guys and thanks for sharing your thoughts,
Paul.

Radiant

Quote from: subspark on Wed 23/04/2008 08:09:06
From a technical standpoint, has anyone tried converting their AGS game to SCUMM C and what challenges lie ahead for somebody willing to try?

It's not that hard to write AGS code that compiles in regular C, or C++ for that matter. It depends on how diverse SCUMM C is.

naltimari

I guess the real issue here is that for a AGS -> ScummC integration to really unfold, it would be up to CJ's shoulders to carry, since he is the only one that knows the inner workings of AGS.

I would be really happy if we could 'port' our games over to ScummVM, because this engine has been ported to practically anything, including iPhone. As soon as a J2ME port is done, it will cover the entire spectrum of platforms. This is not to be neglected.

However, ScummVM was made to support pre-existing (i mean 'frozen') games, and not to be used as a platform to build new games. I wonder how it would hold up against an engine like AGS, which was built to be as flexible as possible.

So, while I think this AGS->ScummC->ScummVM thing is really really cool, I don't know if it would be a good strategic decision. The guys at ScummVM are the first to state that in their FAQ (see 'can this be used to build new games?'). Actually, that was the first thing that went through my mind, the very first time I played 'indiana jones' in it, so I turned to AGS.

But I would love to see my game next to 'Indiana Jones and The Fate of Atlantis' in the list... ;)

subspark

Well if you want an example take a look at OpenQuest. It's on the SCUMM C downloads page too. That was originally an open source AGS game that has since been rewritten in SCUMM C and can be played on ScummVM. Also take a look into the .scc and .sch files of the converted game's source. The language is not that dissimilar from AGS'.

Cheers,
Paul.

SSH

This is interesting. One thing that could be done is write some functions (or macros?) with the same name as AGS functions that call all the underlying SCUMM functions required to do it.
12

subspark

Thats a good point there SSH! I wonder how far you could take this idea. A whole game perhaps?

Paul.

G33K

Glad to see some interest in ScummC. Yes, sorry, the term "port" is probably misleading. It's really more of a reimplementation.

The hard part is that there's little documentation on SCUMM function semantics. And the language is pretty verbose, which makes the code messy.

As SSH states, the next logical step in the ScummC project would therefore be to provide some higher-level API, like the verb and dialog scripts. This refined API could be implemented either with functions, macros, or maybe compiler support.

It'd be really cool if some AGS developers could participate in (re)implementing the next game. Perhaps we can make the ScummC API align with a subset of the AGS script language...?

subspark

Wow that would be fantastic! I'd like to hear CJ's opinion on this. Would a windows toolset be far off the production line, G33K?

Many cheers,
Paul.

Pumaman

Well, this has some striking resemblances to the "universal script language" thread we had a while back whilst discussing ScummVM. Rather than go over it all again, I think we can summarize that it'll never be possible to write a game that will compile under both systems, but if the ScummC guys decided to align their API with AGS's, it would certainly make things simpler.
But if that happened, you potentially get into trouble if I change something in AGS and then the game stops working on ScummC.

subspark

I suppose it depends on who's going to give way. Would SCUMMC be easy to align to major changes in the AGS codebase? This doesnt happen too often and for every incrmental change a number of workarounds could be used until a revision.

Cheers,
Paul.

G33K

What's meant by "windows toolset"? There are Windows binaries for download, although you'd still have to install some make support to use the makefiles...


As to the universal API: Neither the engines nor the compiler projects are comparable. SCUMM is not only different to AGS, but overall less advanced in terms of functionality and language features. And ScummC is still alpha stage. I think it's evident who'll give way. ;)

ScummC simply needs a better programming interface, and I think it's practical to look at AGS as a good standard for orientation. We're just talking basic stuff like naming conventions here. I think there's no chance that a script will some day compile on both systems, sorry.

Rather, I'm just looking for game developers who'd like to assist in creating the next experimental ScummC reference game, or maybe "donate" an existing game. There's little to gain except for those few extra platforms, but maybe there are some of you who are into the technical challenge?


On a side note: I've done animation in a former life, so if you're not too particular about your graphics, I might throw in a few character animations as a bargain. :)

SSH

12

subspark

#17
I'm interested in creating a small to mid scale prototype for use with SCUMMC.
I have game design documents written up and I am an artist by trade.

Cheers,
Paul.

Edit:
QuoteWhat's meant by "windows toolset"?
Forgive me if I sound stupid but I meant tools that don't run in dos like costview.exe or scc.exe.
Are you planning anything like a unified program like AGS, with all these mini tools combined?

Cheers,
Paul.

G33K

The box editor and costume viewer are currently the only GUI components. An IDE isn't planned, and Alban (the ScummC creator) is probably more of a command-line guy anyway. Right now, the makefile would be the unifying "program" that combines the various compilers.

But one of the merits of command-line compilers is that you can easily invoke them from external programs. So, theoretically someone could create a ScummC IDE as a different project. It's just not advisable right now, as the ScummC syntax isn't stable yet, i.e. Alban might change it as we run into problems with the prototype games.

...And thanks for the offer! I'll contact you via mail/PM on that.

subspark



Quote
But one of the merits of command-line compilers is that you can easily invoke them from external programs.
That sounds interesting. I'm sure that somebody will take to it as there is usually a high call these days for IDE class tools.

QuoteIt's just not advisable right now, as the ScummC syntax isn't stable yet
That's fair enough. Thanks for explaining it all to me.

QuoteAnd thanks for the offer! I'll contact you via mail/PM on that.
The pleasures mine, G33K.

Cheers,
Paul.

SMF spam blocked by CleanTalk