Monkey Island for CPC - Is it a fake?

[CPCIak]

Please have a look at this link:
http://cpcrulez.fr/forum/viewtopic.php?f=6&t=4271&start=0

[fano]

As i said on CPC rulez , i think it is a fake.
Maybe some interesting mockups but not real + screens.

[Xyphoe]

Please have a look at this link:
http://cpcrulez.fr/forum/viewtopic.php?f=6&t=4271&start=0

Spoiler: ShowHide

Yes it's a fake!

Sorry just had to use the new spoiler function again!
The screens have been mocked up in photoshop, reduced down to the Plus pallette.

[fano]

lol Xyphoes , nice usage of the spoiler function 

[CPCIak]

it's a pity

[Gryzor]

The resolution is correct, colors are correct, but it's OBVIOUS those are 16-bit screencaps that have been re-rendered. Not with Photoshop but with the tools we already have - don't you recognise the dithering? In any case, this is 100% modern-day rendering techniques.

Still, nice mockup...

[Trebmint]

Yeah its a fake, but there is no reason why it couldn't be real other than it would take somebody talented, dedicated, and with a lot of time. The Plus, 128k and a Disk is perfectly capable of doing such I reckon.

[MacDeath]

As I told, the Atari ST or PC EGA versions of IndianaJones 3, Loom, Monkey Island or ZakMacKracken and maniac mansion, even leisure suit larry...
Can be achieved on a 6128+, as some of those were even released on C64...

Or with a 320x200x16 (ST and EGA).

If I could get my hand on the graphical datas, getting it on a mode0 PLUS can completely be achieved.

Of course animation would be a bit reduced and you'll get shitton of Disk access... or have to manage memory extensions too...

But not that much different to an Orion Prime like game.


Monkey Island 2 was VGA from the start, and used more advanced PC configs at the time... the 320x200x256 is not that easy to put on CPC...
But 320x200x16 can really be modified to be 160x200x16 on CPC..

[Cholo]

Those shots really looks nice, but the fact that Monkey 2 is one of the largest amiga games of 12-13 floppies its kinda obvious that it must be a fake. Also the game was one of the first games to support hdd install. Not a impossible feat but close to impossible as the game is just so large.

Monkey 1 however was just the 4 floppies i feel is much more do-able. Most of the time you just walk around picking up stuff or talking to people, and the no of actual animations are few and small. Like being shot out of the cannon is seen from "bird" view on the island screen. The first "fight" against a pirate is cleverly happening in the next room over .. so you dont actually seen the fight but just the speechbubbles with "crash" "boom" and similar. The later fight against the sword master is speech based too. Even "complex/time"-based puzzles like you have to wait for the chef to exit the kitchen before you can enter .. seems quite do-able (and quite few of them). Still even with some sort of orignial source code/script its a massive job to do.

Still, if they could do BAT then it should have been quite possible to make some of the smaller point and click games. Like early Space Quest/Universe/Larry etc.

[Pentagon]

Its possible to do, thats a fact.

But ;-)

you need BDos and a Symbiface to do that. Timo and me we had that idea years ago and we started to write a new adventure engine and i was working at new ideas and converted some screens too.

If you install that game on a harddisc, its would be working ultrafast and fine with a CPC Plus or a normal 128 KB CPC, its not possible to play that from standard 3,5 Discs. But BDOS could handle such files and such huge Adventure Engines.

Kindly Regards
Tom

[MacDeath]

Also we have to remember that graphicall datas are quite big on a CPC compaired to most other 8 bits...

But when compaired to any 16bit, it is a small dick actually.

16K is a lot for a 64K (or even 128K) computer, yet for a 512K computer (PC, Atari, Amiga) or even 1024K Ram (or simply 640)its really nothing.

The average Atari ST 320x200x16 use twice more bits...
And an amiga despite the numerous specialised Hardwares, had music  with lots of sampled sounds and 32 colours modes... this do a lot of additional bits... and as those were a lot more animated too...

A CPC can give a decent result IMO, even with only 128K, it just need shitton disk access but then a memory upgrade enable to pass through that.

So not a symbiface, just a +512K and 720K 3"1/2 disks...

The GUI can be bypassed a bit with shortkeys and joystick.
Limiting the Point and click only to the game's window, while the actions or objects are selected only with the keyboard :
F1-F9 : the 9 action.
Arrow : search inside the bag.
1-8 : select said object...

Because just having one mouse like pointer to selct on the game and actions and objects is too...slow.


Perhaps concerning Monkey Island 2... the lack of tile based graphics means it gets a bit bigger.

That's also why I suggested to dither a bit less and simplify the textures, so you can re-use a bit of tiles.

Simply because despite the sweet looking mockups, a CPC/Plus is clearly not as powerfull as a HDD VGA 386 PC with 1meg RAM.

[fano]

Speaking about games using a lot of storage space, the way the HXC SD floppy emulator is taking is very impressing.With a software selection of the HFE image , that would be possible to manager multi disc games without manipulations with a "simple" floppy emulator.No need a HD , just the emulator and a SD card 

[TFM]

Its possible to do, thats a fact.

But ;-)

you need BDos and a Symbiface to do that. Timo and me we had that idea years ago and we started to write a new adventure engine and i was working at new ideas and converted some screens too.

Well, FutureOS and a 3.5" floppy is enough ;-) Even if I'm busy with some small projects and even in Tolkin and me will finish Giana maybe not so quick, this doesn't mean that Gerelakos is forgotten.

[MacDeath]

Sorry but I can't se why an OS+Game is better than a purely assembler game ?

[Pentagon]

BDOS is a pure Harddisc OS and games loaded with BDOS can be load in under 1sec. So its also possible to save extreme huge data. (Like *.wav files or very Huge Picture Data) - the file size could be tons of Mbytes.

So if you code an Adventure Engine wich is using the advantages of a pure harddisc, the result is an ultrafast loading game wich is running from the "unlimited space" of you r harddisc drive.

We tried some nice things with that, like really huge wav files or big picture data. I think Prodatron did the same, but with SymbOs.

FutureOS is nice and can load fast too. But it have the Disc Limitation (a Dobbertin Disc is not avaiable anymore - so nobody can use it). I am talking about a modern solution who is usable to anybody.

Personally i would prefer a Monkey Island from SD Card. But Harddisc is so much faster thats impressive. I can load a 128Kb *.SNA File in just 2 seconds. Its "The Data Pump" for any CPC.

So anybody with a Symbiface can try that too. Monkey Island on a CPC6128 PLUS with a nice Adventure Engine (scumm like) and a overscan Plus feature graphics, running from a Harddisc. Well, sounds great and its really fast.

The solution for anybody would be the SD Card like fano told about. FutureOS could be used too, but then you need to juggle with Discs, cause nobody have an ultrarare Dobbertin Disc at home. To be honest that vintage MFM Monster.....i wouldnt trust my data on it.

I am using a 1gigabyte Seagate 2.5 Inch IDE Harddisc and its full working since 6 years now, without any issue. If you code in purely Assembler and use the Harddisc power, well it should be a fine and ultrafast game.

Kindly regards
Tom / Pentagon

[Targhan]

I don't see why a LucasArt type game couldn't be done on CPC. Sure it would load a bit between the screens, but it's perfectly doable.

... And please, don't even consider using extra hardware or more than 128k because no one will ever be able to play the game (except 20 people).
Good loader + good compresser (Exomizer, MegaLZ), and that's it.

Trg.Aks

[arnoldemu]

I don't see why a LucasArt type game couldn't be done on CPC. Sure it would load a bit between the screens, but it's perfectly doable.

... And please, don't even consider using extra hardware or more than 128k because no one will ever be able to play the game (except 20 people).
Good loader + good compresser (Exomizer, MegaLZ), and that's it.

Trg.Aks

I agree that it is possible, and of course ram decides how much can be done in each location. Then disc size decides the number of locations.
I also agree with Targhan about 128k. This kind of game really is only suited to 128k + disc. I would say really impossible to do for cassette so not worth thinking about.

This game would also be good for cpc+, the only thing to consider is that the man can walk behind some parts of the scenery, so that if sprites are used, then these must be masked in some way so that this works correctly.

My thoughts are that this game is really nice, but really I still think that first making a smaller adventure would be the better idea but using a similar game engine.

Keep the adventure small and then when it is completed, the team who made it would easily know the limitations they have to work with and then they could try a bigger game.

[MacDeath]

This game would also be good for cpc+, the only thing to consider is   that the man can walk behind some parts of the scenery, so that if   sprites are used, then these must be masked in some way so that this   works correctly.

Animating well Hardsprites for the hero is not that interesting, on the other hand using said sprites to patch the background, hence some front sceneries... may be better perhaps...

Or some little additionnal special effects or animations...

That's why I suggested to start with less coloured backgrounds (= not a VGA original), because lots of sprites will have to remains softwared.

Yeah the result may be looking inferior, but on practical purpose this is optimisation for a realistic engine.

And the screen can still manage to feature more than 16 colours because you can put more Mode/Raster changes on a plus for the Actions and inventory parts of the interface.
(And Hardsprite patches, and Border...)

Also it is to notice that even with a 128K Ram version, a lot of datas remains from one location to another...
Hero's sprite, inventory and actions part, some script elements too...
You "only" have to reload :
--The graphics for the actual location : may be something like 2-4 screens...can actually be a bit compressed or include some re-used tiles if you dither a bit less/simplify a bit the graphics...
--Some few additionnal sprites : the peoples you may interract/chat with, or the objects you can tak/interract with.
--Scripts...

Monkey Island was very graphicall, a lot of special animations and so on...
But this can also be  lowered a bit without reducing the overall game's interest.

And, well... Porting an existing game is great, this eases the work to be done, yet an original game can also be achieved...
As you know, Georges Lucas is somewhat greedy and has a legion of Lawyers Jedi Clones...



Oh, reminds me of the game NightShift...
I had it on EGA PC yet the Speccy port on Amstrad seems somewhat shitty...

This kind of game really is only suited to 128k + disc.

Of course 128K may be enough to get it playable, but enabling management of more may not be that complicated then as it would just reduce the number of loading, so enable a smoother game experience, without needing a complete rework of the game's engine..
And perhaps more musics then...

[Cholo]

The good part of a game like Monkey Island is that it is devided up in parts. Monkey 1 has 4 parts and as the parts dont reuse much data its would be like programming 4 "mini" adventures.

Part 1: This is the major one with a lot of screens but few is used at the same time. The main screen is the Map screen .. used to get from one small location (2-4 screens) to the next small location (another 2-4 screens). The Amiga game loaded a LOT from disc. Even in the middle of town there is a obvious "halfway" where the game loads the next screens/data.

Usage: 128kb ram, mode 0 & 2x 180kb floppies i guess. The good think is most of the locations are "locked" from entering at first so you  could add all the open areas on floppy 1 and the locked one floppy 2. One screen would take 10-12k raw ram (as the menu is the lower 1/3 of the screen). Largest panoramic view is 2 screens wide-ish and has very little action. Single (still) screens may have "taking to pirates"-pictures but these are few and must squeeze into nothing using a good screen archiver (as the pics are quite blank except for the pirate head). Leaving out audio but keeping the txt, scr, anim & engine and it might squeeze in there (or use 3 floppies, who cares when it loads so fast from 3" ).

Part 2: Very small part this one, might as well put this one on the same floppy as the 4th part. No map screen and perhaps just 4-5 actual screens to visit. Lots of talking and puzzle.

Usage: less than half a floppy.

Part 3: a bit like the first part but smaller. Much less puzzles. still a good handfull of screens and small animations.

Usage: Need another 2 floppies i think. Again some parts are locked at first so having the "open" parts on the first floppy and the rest on a second makes sense.

Part 4: this is a extremely small version of part 1 (graphics/maps/screens reused, but recoloured), but as the whole thing is quite limited only a few screens are accessible. Very little talk and puzzle.

Usage: half a floppy?

If you cant remember how Monkey1 goes there is a quick 4 min flash animation here (dont watch it if you havnt finished the game or dont want to remember):

Spoiler: ShowHide

http://www.youtube.com/watch?v=MXoO9JslgBk

[TFM]

Sorry but I can't se why an OS+Game is better than a purely assembler game ?

If your OS is in the ROM, then the game can use the OS routines without wasting RAM for this kind of routines. For example load file, save highscore, manage expanson RAM, screen decompression etc...

And like Targhan said 128 KB is the standard today. Now subtract 32 KB screen RAM. So 96 KB remain for the game. That's just not much.

If your OS is quick, then it _will_ be used by game developpers.

If you have a relatively slow OS like AMSDOS or CP/M developpers use it only to start the game.
(see Orion Prime).

Edit: If a hard-disc shall be used, then todays solutions (SF-II and the IDE8255) must be used (there I agree with Tom) with at least FAT32 format (or higher).
Any kind of propietary format provides too much work for the user. And somebody who wants to play a game (from hard-disc) can't be forced to reformat his hard-disc first!

This means finally, in this moment there is not one suitable system, if you think about it.

[Pentagon]

Bdos could be mounted at any DOS / Windows PC too. Timo wrote a native support for that. FAT32 is not the advantage Format for a CPC. But thats an OT Discussion. Fact is, BDOS can handle it and its very stable and safe to use.
I bought a normal harddisc just for cpc. Formated to BDOS format and i can use the same disc in a DOS / Windows PC too. BDOS can handle long *.wav Files and superhuge files to stream relative into the memory of CPC. So its here, just download and use it. Give it a try and you will see its easy to use, and can do that.

I dont know nobody who is using FAT32 at the cpc for serious working. Sure it would be easier to transfer the data from PC. But since Timo wrote BDOS Driver for PC its not an argument.

But hey, thats okay, i respect your opinion very much. I just want to explain what would be possible with that system, if the people would understand and use it.

Kindly regards
Tom

[MacDeath]

Monkey 1 has 4 parts and as the parts dont reuse much data its would be   like programming 4 "mini" adventures.

Same engine, different datas...

Even a disigner kit could be achieved...this would indeed be the best choice...
Enabling scripts AND screen designs/graphics integration...

Spoiler for Hiden

Fuck years...reminds me a lot...

If your OS is in the ROM, then the game can use the OS routines without   wasting RAM for this kind of routines. For example load file, save   highscore, manage expanson RAM, screen decompression etc...

Ok, then OS ROM means you need other hardware than disks and Basic Cartridge...so not the average 6128+ config... Yes, additionnal routines means a lot of cool stuff with no RAM wastes... but...well... while you're at it, why not simply a ROM+Disk game then ?

IMO the best a 6128+ could offer would be a 512K cartridge + a 3"1/2 with 720K disk (or even more than one...).
But hey...the problem remains... this is actually extra hardware...
And the 512k ROM would actually include quite few routines, and a lot of...graphics and stuffs...


But I aggree the PLUS range lacked a proper ROM/cartridge based OS... Loco 1.1 basic was quite not good no more...

Perhaps we'll do some hardware tests this weekend with my brother... (now he has his FPGA board...)he told me so, but I have to organize my birthday party for saturday...
Massive hangover and left foot (the broken one) pain incoming...

[mr_lou]

Anyway.... instead of all these threads about old games, that everyone has already played, being ported to CPC, why not focus on creating a new game for multiple platforms instead?

[Trebmint]

The problem with threads like this is not the impossiblity of being able to implement on the cpc, but more the improbability of somebody spending the time and effort to do so.

Clearly the way forward for this is for somebody to make a game designer, able to do a monkey islandish game, and others similar. This is basically a way that allows the non programmer types to get involved in a way they just cant at the moment.

I think as a group we need to look at ways to actually work as a community to get projects designed, and built, not just talking about it. Orion Prime possibly shows that sales can actually be fairly high (around 200). This though not a commercially viable level its a higher amount than I would have expected, and actually given the modern tools and PC based development it might be expected that a 1984/1990 3 month amstrad project might take half that time.

For instance is it possible that as a community we might develop and publish games? Some of the Revelo big box games are lovely and desirable in themselves.
And that development is shared out, and people add as much or as little as the want, including a full design doc.
That we as a community develop a number of standards formats for mapping, engine and characters so that all routines become freely available to anyone and are fully documented, and to a large part interchangable.
That existing coders should release interesting code to the community
A pool of graphics and sprites should be harvested from the thousands of existing software.

[Targhan]

>This though not a commercially viable level its a higher amount than I   would have expected, and actually given the modern tools and PC based   development it might be expected that a 1984/1990 3 month amstrad   project might take half that time.

Yes, but we all have day-job and things to do besides CPC. That's why games that should have been produced in 1 month has been done in 10 years (Color lines...).

Just so you know, Orion Prime disc system code takes a bit more than one KB in memory, so it really doesn't take a lot. 128k + floppy is the way to go if you want people to play your game...