Saturday, 30 October 2010

Towns design notes

Uploaded notes i took regarding how towns were designed and operated and how the CD32 version will be laid out. I also decoded the remaining unknown informations about characters generation and market management that was left.

On the code side i started the layout of the towns menus (modifying the gfx lib for greater flexibility in real use conditions), i think i should have the complete towns/characters management done & running soon, I'll then have enough data to create the game loading/saving handler before moving to the wilderness part.

I also uploaded the original Phantasie I PDF manual (which was identical to the Phantasie II manual).

Thursday, 28 October 2010

First CD32 test

Today, I tested the whole framework on the console, everything went fine except that i didn't know the CD32 ISO9660 file system doesn't implement the AmigaDOS Examine functions so it returned a 209 each time i needed to know the size of a file (in fact, each time i needed to load one) an issue which didn't occur as i was running the code from an hard drive, programming the API of an ancient operating system like AmigaOS requires some more discipline.

I improved the framework and the title menu is complete so now i can focus on the core parts of the game, I'll start with the code handling the towns as everything starts in PIPPACOTT...

Wednesday, 27 October 2010

Saving games

The CD32 only have 1024 bytes of non-volatile RAM for saving purposes that's a really tiny amount of memory to store the data of a Role Playing Game such as Phantasie II.

During the game, the save command is available when the party is located in a town and when it's getting out of a dungeon, so for the party location a single byte will be sufficient (with a bit to specify the saving type (town/dungeon) and an index to determine the actual dungeon's or town's number (or just a simple index into a table).

Towns items stocks need to be saved as well, they take 180 bytes and there's 9 towns so 180 * 9 = 1620 bytes, we already exceeded the amount of memory we have at our disposal !

Most characters data need to be saved, if we avoid the calculated values and use bit fields for spells and runes we can have approximatively 109 bytes per character which gives 654 bytes for a whole party of 6 characters.

Discover the world by stepping on it

The original Apple II version had the wilderness & dungeons tiles hidden until the party stepped on them, in order to save the progression of the player the OUTTx & DNGx were updated with all the values of the tiles (including the newly uncovered ones).

While this is a nice feature I'd like to keep as it adds a real sense of discovery to a game i can hardly save all the states of all the wilderness & dungeon tiles with the rest of the data.

Assuming i'll use bits to save each state i would have to cram 2359 bytes of data (with possibly high entropy later in the game when many of the locations would have been visited) together with the rest of information inside the saving slot, which could be a problem.

A problem which will be eliminated simply by not saving the states (although I'll need to perform some more accurate tests i don't think there'll be enough room left to save them).

So a restored game will have all it's tiles covered again, while this may sound unfair (maybe it is) i always found that roaming a place or level which was already visited and which topography is all uncovered spoils a bit of the fun & beside: the only other solution would be to play it with WinUAE & use states files (talk about spoiling the fun).

Another small issue concerning the covered tiles was the water ones, on the Apple II there was no way to know (or maybe i missed some extra feature) when a newly uncovered part of the wilderness would be the ocean & that was kinda frustrating as characters could sink and die (or manage to swim) when moving onto one, to avoid that i think the best way is uncover the tile & ask the player if the party should go ahead & try to swim or just stop moving when the party is about to step on such tile.

So now we're left with approximatively 1+1620+654 = 2275 bytes for a game save which is more than the 1024 bytes that we don't even have because there's an overhead of 24 bytes for the NVRAM header and 7 for our entry so 993 bytes it shall be...

Obviously, the game needs to include it's own packer and depacker which needs to be good & fast enough to fit our requirements, a primary test i did with packfire (tiny model) showed that default data for the towns and 6 characters with random names pack into approximatively into 523 bytes, i assume it will grow but probably not beyond 993 bytes (crossing fingers there) otherwise I'll have to ditch the towns items infos (which could lead to a major cheating issue).

Greetings to Commodore.

Demo mode

Added another file which describes the original demo mode which was present in the Apple II version. I may add one too (probably using LUA scripting) which would be triggered at title screen (after a short period of not receiving any input from the player).

Tuesday, 26 October 2010

Taking shape

Found the time to do more work on the gfx system, everything is in place to create flexible menus and lists, main structure of the game is ready too, title screen and main menu are done (although i'd like to add some animation effect on the title itself, just don't know what yet).

Most of the time was spent on optimizing the display functions (they use the AmigaOS ROM which i had to fight against) to make them relatively fast enough to be bearable because the whole game will run in 256 colors (i don't think the gfx will reflect that fact ;D).

I'm considering using some graphics from the X68k version of Phantasy IV (mainly the town stuff) and opening a googlecode project so i can have a more practical (& probably safer) place than just my HD to store all the files.

Saturday, 23 October 2010

Where do we go from here ?

Made some decoding today and since i mapped the biggest parts of the program I started a framework for the Amiga version, currently it can open & display IFF files and perform most graphic operations like displaying objects or text, fading palettes & handling user input, I still have to implement the sound code & bind the LUA interface to the code as i think I'll use that, at least for the dungeons scripting; Talking about scripts, some new Ruby ones will be needed to convert the original data into more suitable (and cleaner) formats.

There's a lot of decisions to make concerning the final shape of the game, i'll probably re-use the same gfx (with at least some small improvements as even the palettes aren't pleasing to the eye) and add some new ones for the towns & dungeons.

I don't want to use drop down menus like in the ST version as i think it wasn't really a fitting interface for such medieval fantasy context (I'd rather like something more "integrated" to the mood), I'm considering a more Japanese interface style too (to play the game with a joypad).

Dungeons should have a more closer view and scroll in the height directions (the older view only used as some auto mapping feature), that's clear for me, i didn't find the older view involving enough for the player.

I was also wondering about the sound scape like having ambient nature sound while being in the wilderness and steps sound and echoing, dripping water in dungeons etc. or just some contextual tunes playing in the background (or both ?), ambient sounds could help for the immersion but i fear the visual could be dwarfed by such "grand audio scheme" & would look a bit ridiculous.

Should it have a day/night cycle with obvious consequences on encounters like monsters strength lowered a bit (and night creatures not appearing) during broad daylight making the game a bit easier (the original one was rather tough especially for starting adventurers) ? I'd like to reproduce the original game play balance as close as possible while improving it whenever it's possible.

I haven't decided much yet and the moment to implement all these elements is far away from now anyway.

Friday, 22 October 2010

The map and the territory

Completed the MN2X files structure cartography that's an important step (although i may have wrongly interpreted a few values I'll fix that as I'll uncover the ways they're used thorough the program).

I found several discrepancies between the manual and the actual code which confused me at first about the nature & use of the monsters data (as i was blindly thrusting the code), like spells not really acting according to the book, for example it would be more logical that CONFUSION should be acting on monsters' "Magic User" and "Accuracy" attributes, BINDING on "Dexterity" and WEAKNESS on "Physical damages booster" which wasn't the case in the original program.

Also DISPELL UNDEAD seems to be partially wrong as i don't think it acts on zombies creatures (dunno if there's a way in the game code to recognize those).

And I don't know yet if the friendliness value have to be cleared before each encounter or not.

I consider those to be bugs from the program that would need to be addressed during the porting process.

Monsters files

More code decoding done (completed to map the CHAR2 structure) and added a first draft of the MN2x files structure, that is a rather tricky one as it's like used inside the mother of spaghetti code (aka the combat system).

Dungeons files

Most of the code driving the dungeons is the same as in the wilderness part (save a few additions like traps) which good (& was expected), but i'll check more thoroughly to see if the combat system is exactly the same as the other one, i worked on the dungeons files today and decoded them.

Thursday, 21 October 2010

More work done...

Started to decode the monsters data & have done a lot of cartography/decoding of the code today, especially the combat system which is the biggest block of the game.

I also have aligned the monsters and heroes graphics on grids for easier display.

The FAQ i've read is mostly wrong about the monsters attributes (although it was valuable to understand the maps even if they're from the rotated C64 version ;)) thanks must go to Andrew Schultz for that.

I also found a pdf manual of Phantasie I which apparently was the one included with the second opus too, i devised some infos from it as well(also it contains some interesting tips about the variations of the C64 version)

The combat system is a quite complex piece of spaghetti code and as soon as I've got it the rest should be a walk in the park (dungeons are using the same system, of course).

The music and sound of the ST version are using the stand DOSOUND XBIOS API (which seems to be described here) so maybe it'll be relatively easy to convert that to a friendlier format.

Wilderness files

Decoded OUTTx files but the global map will have to be remade so these files will only be used as reference.

Wednesday, 20 October 2010

Towns files

The decoded town files structure is available to download. I didn't investigate the 2 extra entries spotted in the ST version yet (dunno if i will).

Characters file

I started to reverse the files used by the game and i have most of the towns code decoded as well (i'll start the port by that part), i'm starting with the characters one which structure is available to download.

Welcome

Hi,

I opened this blog to use it as a development journal for a port to the Amiga CD32 consoles platform of the role playing game Phantasie II which had never been available for Amiga or even PC (while episode I & III were), the console itself only had maybe 4 or 5 Role Playing Games ported or made for it, this would even be (as far as i know) the first homebrew game ever made for that platform.
I started some days ago, basing my port on the Atari ST (for the gfx & sound) and the Apple II (for the code) versions.

So far, i've extracted all the gfx from the ST version and started a decoding/analysis the Apple II source code and the structure of the data files (i'm using the Apple ones with some spelling corrections taken from the ST)

I intend to rewrite the engine in C (so maybe, if the occasion arises it could be ported to other platforms) and to improve it from the ST version in every way (i don't like the menu driven interface to begin with), ultimately i'd like it to be a bit more console rpg like but i haven't really decided anything about that.