Thursday, 28 July 2016

Back from the void

Hi, long time no see, i decided to resume this project after a 5 years hiatus, i'll have to analyse the whole code again as i don't remember what i did and how far i went back then, so it's going to take some times before any update is published.

Sunday, 8 May 2011

First early preview

Nothing much have changed since my last post, i restarted the work on the port and i now publish the first (very) early preview of the game which only contains most part of the towns, game saving and characters generation/handling.

I was thinking that perhaps the dungeons should be handled in 3D a la Wizardry or Might & Magic games with some auto-mapping feature, dunno if it's a good idea yet. I'd need several types of materials for the different walls of the different locations (the orientations and zoom of those walls could be calculated with a self made tool using HW acceleration and integrated inside the build chain), another solution would be to use the Phantasie IV dungeons gfx from the X68000 which are still in 2d but look quite good (a bit like Ultima VI/VII).

Saturday, 20 November 2010


Converted all Atari ST graphics and i started to improve them (adding more colors, better palette & anti-aliasing), for the tiles I'll use a subset of Phantasie III ones. On the code side, i nearly completed the spells system, all that is left to complete the towns are the transactions between characters and the armories.

Also I planned to add proper intro and ending sequences displaying some text and an effect covering (and uncovering at the end of the game) the wilderness in shadow (or something like that).

I uploaded the Ruby script i used to convert the graphics to raw Amiga format.

Sunday, 14 November 2010

More precision

I discovered that some of the values i thought were meaningless in twn2x files were in fact used to randomize the stock of items in towns (to simulate some market activity), so i updated the conversion script and file format description to reflect that.

I also noticed that i was saving approx. 100-140 bytes of extraneous data inside the NVRAM, so maybe there'll be enough room to save the player's progression on the wilderness map after all (which would be more satisfying)...

I had the time to complete the items using function (also the scrolls reading sequence) and started the spells casting part (the manual contains some errors about spells types and i changed some of them to have less restrictive use like VISION which will be usable in dungeons as well as in wilderness), i think i could publish a first preview with the towns part completed in about a week but i don't see much reason to rush it and do that yet, I'd rather wait until i have all parts completed and a more or less playable game before releasing any binary (unless someone's willing to beta test). This should probably take a couple of months to have everything implemented and put in order so stay tuned, at worst I'll release something if i feel a drop or loss of motivation.

Wednesday, 10 November 2010

Work in progress...

A quick report, I've been working on the towns and characters managements mechanisms and they're almost completed. The commands not implemented yet are: casting spells, giving or using items, buying or selling items to shops and burying dead characters, after that I'll be done with that big part of the engine.

Doing the parts of the game which interact with the data is relatively easy; Most of the work goes into figuring how to show the data on the screen or into the layout the various menus to make the interface intuitive enough, also each time i have to mess with the operating system API is a painful experience mainly due to cryptic documentation (thankfully that part is almost over as only the interrupt to drive the internal audio chip that I'll use for the SFX is left to be implemented, for the music I'll use CD tracks, which reminds me that I'll have to find someone willing to compose probably 6 of those soon enough).

I also modified/improved several parts of the original game design and behavior like the spells learning (a character will be able to learn several spells in one go) or the gold, experience points and characters "levelling" (which will be calculated after each combat like in Final Fantasy games).

There's still a lot of work to be done, 3 big parts remain: The tiled map system, The combat engine and The dungeons scripting (plus the minor game over and game winning parts), several months of work in sight i guess.

Wednesday, 3 November 2010

CD32 bootable discs

The console uses a special format for CDs that can automatically boot at startup, when inquiring about the method i would have to use in order to create such CD i stumbled upon the most widespread method which consist of using an old Amiga tool called "IsoCD" made by Carl Sassenrath which was part of the official Commodore CD32 Developers kit back in the day, since I'm developing the game from Windows that tool was kinda cumbersome to use (plus it have some quirks like the trademark file which needs to be reloaded each time an iso file is generated), i couldn't integrate it inside my compilation scripts.
For the conveniency of the project it was obvious that i had to determine what made a CD bootable on the console and make some tool that would convert standard ISOs to those CD32 bootable ones so i could use mkisofs to create the files.
After a quick look i noticed that there's actually 3 locations where data differ from standard ISOs:

- 17 extra bytes in the application data field containing pointers to the path table block and to a trademark file block looking like this:

   <path table block byte>
   <trademark file block byte>

- A 2048 bytes trademark file (mostly containing garbage but it have to be present)
- System ID have to be "CDTV".

Both blocks byte pointers are multiplied by the blocks size (2048 bytes) to determine the offset of the relevant informations inside the file, i choosed to put the trademark file right before the path table at block 18 (offset 36684) (the path table created by mkisofs is located at block 19) as there was enough empty room there (for some reasons putting it in the boot sectors before the ISO header wouldn't work).

The command line to use with mkisofs is quite specific and goes like this:

mkisofs -quiet -V <cdname> -copyright <yourcopyright> -publisher <publishername> -o <name.iso> -relaxed-filenames -d -input-charset ASCII -output-charset ASCII -iso-level 3 -A "" -sysid CDTV <directoryname>/

It won't work with anything else than a CDTV system ID, i guess they were lazy and re-used the code they made for their CDTV product.
So, i made another Ruby script which does the dirty conversion job (see related files section for download), burned a CD with the ISO and it worked like a charm.

On the other news, I also had the time to implement the game saving & the characters creation process.

See you soon.

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.