I know what is AGI, I read the queues Adventures, Sierra, should be obvious where this lead. But my mind went to "oh, thanks to LLM coding agents, they massively ported every Sierra Adventure to C64".
Only with some serious downgrading of the assets. I remember playing SCI games on an 8MHz XT class PC and everything ran dog slow. Some SCI games had optional animations that didn't play on a slow machine.
AGI is here and its first task is obviously completing the C64’s game library.
Not really. AGI is a game interpreter, like LucasArts’ SCUMM or Infocom’s z machine. Games are shipped as portable code and a machine specific AGI interpreter runs them. Looks like they’re preprocessing the graphics first, though. https://en.wikipedia.org/wiki/Adventure_Game_Interpreter
Sierra released most of their AGI games on the Apple IIc/IIe. Given C64 is a roughly equivalently specced machine, there is no reason in principle why they couldn't have ported AGI to C64 as well – it just, for whatever reason, never happened. (One AGI game, "Donald Duck's Playground", was originally developed as a native C64 game, then AGI was used to port it to other platforms.)
Also, given different AGI platforms had different graphics capabilities, I expect even the original Sierra AGI games had somewhat different graphics assets on different platforms – so whatever preprocessing of graphics they are doing to make them C64-friendly, Sierra quite possibly would have done something like that anyway had they made a C64 port back in the day.
If I recall correctly, the art is done with a form of early vector drawing so that they can use one set of assets on all platforms. They're designed to 16 colors but get downsampled for 4-color CGA mode or monochrome mode.
I've always imagined it to be first and foremost about storage savings. Although, come to think of it, an RLE-encoded bitmap might be comparable since we're talking about images with large areas of so few colors. Might be interesting to do an empirical test.
But, yes, it's all a bunch of vector draw/fill commands. The first few AGI games showed that process happening; and, as a little kid having one of their first encounters with a computer, I found it fascinating to watch. Later games drew it in an offscreen buffer and showed it all at once, which looked more "professional" but took away some magic.
EDIT: I had an agent make a guess and it came up with reasonable looking numbers that said an RLE bitmap would be a small handful of times larger. But it also interestingly pointed out that the vector commands encoded priority (i.e., what you can walk behind/through) whereas that'd have to be a second data set for a bitmap approach.
> Given C64 is a roughly equivalently specced machine, there is no reason in principle why they couldn't have ported AGI to C64 as well – it just, for whatever reason, never happened.
I think the first instance of games being separated from the "engine" so that you could make the game and it would run on all platforms that the engine ran out without porting was Infocom's Z-machine. http://maher.filfre.net/if-book/if-4.htm
There was an interesting article which I read a long time. It's linked to from the post above called "How to Fit a Large Program into a Small Machine" published in 1980.
AGI, SCI, Scumm etc. were all larger and more capable versions of this.
Impressive fitting into the machine. I wonder if SCI would be possible?
Not really. AGI is a game interpreter, like LucasArts’ SCUMM or Infocom’s z machine. Games are shipped as portable code and a machine specific AGI interpreter runs them. Looks like they’re preprocessing the graphics first, though. https://en.wikipedia.org/wiki/Adventure_Game_Interpreter
Also, given different AGI platforms had different graphics capabilities, I expect even the original Sierra AGI games had somewhat different graphics assets on different platforms – so whatever preprocessing of graphics they are doing to make them C64-friendly, Sierra quite possibly would have done something like that anyway had they made a C64 port back in the day.
But, yes, it's all a bunch of vector draw/fill commands. The first few AGI games showed that process happening; and, as a little kid having one of their first encounters with a computer, I found it fascinating to watch. Later games drew it in an offscreen buffer and showed it all at once, which looked more "professional" but took away some magic.
Here's a video showing the drawing process: https://www.youtube.com/watch?v=v5DSFvWrNWA. Magic!
EDIT: I had an agent make a guess and it came up with reasonable looking numbers that said an RLE bitmap would be a small handful of times larger. But it also interestingly pointed out that the vector commands encoded priority (i.e., what you can walk behind/through) whereas that'd have to be a second data set for a bitmap approach.
Agreed about the issues not being (completely) technical. <https://np.reddit.com/r/c64/comments/1r8hgwk/kings_quest_i/o...>
There was an interesting article which I read a long time. It's linked to from the post above called "How to Fit a Large Program into a Small Machine" published in 1980.
AGI, SCI, Scumm etc. were all larger and more capable versions of this.