Gentlemen, which Bard's Tale engine did we want to ultimately work with here?
I'd like to get a consensus on this.
Well, which engine?
I can't really say what I am in favor of at this point.
* The BT I is to 90% documented and is the only engine we currently can work with. Still, some vital parts of it is set in concrete in the main engine. If we'd like to change stuff like items and monsters, a big part of the engine will need to be disassembled or manually modified in memory.
* BT II is very much alike BT I. If we manage to access it like we now can access BT I, that might be a better option. This looks like it might limit the cities to a 16x16 grid though, which is a bit small. Nicer in all other aspects though.
* BT III is no doubts the best engine. According to sources, everything uses scripting, meaning that everything (monsters, maps, items, dungeons, etc.) is independent of the engine. It can use Skara Brae-sized maps and wilderness. Everything doable in BT I and II can be done in this one. This is Prodos protected though, and have - unlike the other two - resisted all our attempts of decoding any filestructure.
* The BT I is to 90% documented and is the only engine we currently can work with. Still, some vital parts of it is set in concrete in the main engine. If we'd like to change stuff like items and monsters, a big part of the engine will need to be disassembled or manually modified in memory.
* BT II is very much alike BT I. If we manage to access it like we now can access BT I, that might be a better option. This looks like it might limit the cities to a 16x16 grid though, which is a bit small. Nicer in all other aspects though.
* BT III is no doubts the best engine. According to sources, everything uses scripting, meaning that everything (monsters, maps, items, dungeons, etc.) is independent of the engine. It can use Skara Brae-sized maps and wilderness. Everything doable in BT I and II can be done in this one. This is Prodos protected though, and have - unlike the other two - resisted all our attempts of decoding any filestructure.
/Twoflower
As for BT 3... I got the confirmation from someone we all admire, that the BTCS uses the BT3 engine to run it's scripts... So for BT3 there already is a construction set. If we decided to go for BT3, and if we can leave the CBM64 alone, then we could make a better, modern interface for the BTCS. For that all we need to do is, to analyze the file types it creates. The pictures it creates are probally a STAD pic.pac format, which, I think, was an ATARI ST format, but on the PC it splits it into two files... it also has some SCR files, which probaly contains some animation info (#0 d30: could mean frame 0 for 30 time units?).
Some of the sound file formats are well known, others I don't know.
The rest should be poc.
Some of the sound file formats are well known, others I don't know.
The rest should be poc.
I'd like to point something out here...
The whole reason why I decided to attempt this project was because the 8 bit Bard's Tale lacked a way for people to create their own adventures.
The BTCS as it currently exists sucks hardcore, and I believe practically everyone who has used it would agree.
If the idea now is to forget about the C64 system and just concentrate on updating the MSDOS version, I will terminate my involvement forthwith.
The whole reason why I decided to attempt this project was because the 8 bit Bard's Tale lacked a way for people to create their own adventures.
The BTCS as it currently exists sucks hardcore, and I believe practically everyone who has used it would agree.
If the idea now is to forget about the C64 system and just concentrate on updating the MSDOS version, I will terminate my involvement forthwith.
Whatever platform we want to use, and as for BT 1 / 2 we lack the ability to create/modify spells, monsters and items, the C64 itself will not be the right machine to create the construction set on. It just lacks the abilities for such a big task.
Anyway a construction set can create disks for the C64, even if the campaign is not created on the C64 itself.
And I am too long out of programming the C64 to try to make a constrcution set on the C64. It probably CAN be done, the question is just, at what quality and comfort for the user.
As for the BTCS on the PC, another project was started in 2000 and seems having died in 2007, the "bt builder", see
http://www.identicalsoftware.com/btbuilder/
It seems those people gave up even on a more sophisticated platform than the C64 is.
We proved, that we can do a LOT, but how far is everyone willing to go with this?
Anyway a construction set can create disks for the C64, even if the campaign is not created on the C64 itself.
And I am too long out of programming the C64 to try to make a constrcution set on the C64. It probably CAN be done, the question is just, at what quality and comfort for the user.
As for the BTCS on the PC, another project was started in 2000 and seems having died in 2007, the "bt builder", see
http://www.identicalsoftware.com/btbuilder/
It seems those people gave up even on a more sophisticated platform than the C64 is.
We proved, that we can do a LOT, but how far is everyone willing to go with this?
ZeroZero wrote:Whatever platform we want to use, and as for BT 1 / 2 we lack the ability to create/modify spells, monsters and items, the C64 itself will not be the right machine to create the construction set on. It just lacks the abilities for such a big task.
Anyway a construction set can create disks for the C64, even if the campaign is not created on the C64 itself.
And I am too long out of programming the C64 to try to make a constrcution set on the C64. It probably CAN be done, the question is just, at what quality and comfort for the user.
As for the BTCS on the PC, another project was started in 2000 and seems having died in 2007, the "bt builder", see
http://www.identicalsoftware.com/btbuilder/
It seems those people gave up even on a more sophisticated platform than the C64 is.
We proved, that we can do a LOT, but how far is everyone willing to go with this?
I'm going to guess you never bothered with my dungeon editor, which I wrote IN BASIC on the C64 itself.
Who cares if you can't edit items or spells or monsters? The game is dungeon driven. If you can create your own towns and dungeons then in my opinion that's 90% of the game right there.
My opinion:
* Make an editor on the C64 makes little sense.
* Making an editor for the C64 makes a lot of sense.
Making a town editor is no problem. Making an event editor is a little problem, but no doubt doable. Making a dungeon-editor is no problem. Importing and choosing which graphics you'd like to use is no problem. Changing the title-graphics is no problem. But this means for BT 1.
What is a problem right now is editing the items, the monsters and the event/monster graphics. Otherwise everything is fine. Accessing any engine save for BT 1 is a problem.
* Make an editor on the C64 makes little sense.
* Making an editor for the C64 makes a lot of sense.
Making a town editor is no problem. Making an event editor is a little problem, but no doubt doable. Making a dungeon-editor is no problem. Importing and choosing which graphics you'd like to use is no problem. Changing the title-graphics is no problem. But this means for BT 1.
What is a problem right now is editing the items, the monsters and the event/monster graphics. Otherwise everything is fine. Accessing any engine save for BT 1 is a problem.
/Twoflower
Being able to add your master nemesises and quest items is perhaps not vital, but definitly desirable. The crystal sword, the keys and the EOA symbols plays quite central parts in BT I. We should atleast find out how to hex-edit them, methinks. An editor is doable, and the flick of a couple of bytes would make a BT I editor into a BT II editor, incase we can lock-up that engine.Darendor wrote:Is it vital that the monsters and items be editable?Twoflower wrote:What is a problem right now is editing the items, the monsters and the event/monster graphics. Otherwise everything is fine.
/Twoflower
Alright, you and ZeroZero are the hexadecimal master programmers. Me, I'm just an expert on the game. Or something.Twoflower wrote:Being able to add your master nemesises and quest items is perhaps not vital, but definitly desirable. The crystal sword, the keys and the EOA symbols plays quite central parts in BT I. We should atleast find out how to hex-edit them, methinks. An editor is doable, and the flick of a couple of bytes would make a BT I editor into a BT II editor, incase we can lock-up that engine.Darendor wrote:Is it vital that the monsters and items be editable?Twoflower wrote:What is a problem right now is editing the items, the monsters and the event/monster graphics. Otherwise everything is fine.
I almost said the same as Twoflower:
an editor FOR the C64 is alright,
but ON the C64 is imho too much of work, unless Darendor himself wants to try to create it, once we deciphered the essential parts.
Alone to design the city of 30 x 30 squares would be a challenge on the C64.
You mentioned graphics, Twoflower, did you find out the bitmap and animation packing?
As long as the master nemesis and the main game items do not have special abilities like a spell or ac reduction or something, we could probably get away with simply renaming them in the main file. Afai have seen it, that special items are only tested for presence in the events, and that we can mimic in our own events. But as for the main villains, we can rename them, however, they remain the type they are. I.e. if we rename "Mangar" to "Meany" and the monster type "Mangar" to "Meany" then we have a new villain Meany, who anyway has the same abilities as Mangar. Not to forget: the bard songs. Even if we can change the melody, we don't know where it's effects are defined to edit them.
an editor FOR the C64 is alright,
but ON the C64 is imho too much of work, unless Darendor himself wants to try to create it, once we deciphered the essential parts.
Alone to design the city of 30 x 30 squares would be a challenge on the C64.
You mentioned graphics, Twoflower, did you find out the bitmap and animation packing?
As long as the master nemesis and the main game items do not have special abilities like a spell or ac reduction or something, we could probably get away with simply renaming them in the main file. Afai have seen it, that special items are only tested for presence in the events, and that we can mimic in our own events. But as for the main villains, we can rename them, however, they remain the type they are. I.e. if we rename "Mangar" to "Meany" and the monster type "Mangar" to "Meany" then we have a new villain Meany, who anyway has the same abilities as Mangar. Not to forget: the bard songs. Even if we can change the melody, we don't know where it's effects are defined to edit them.
You mentioned Bard's Tale III being protected by this Prodos thing.
Have a look at track 15, sector 4 of the BTIII boot disk. You can see the various error messages stored there which seem rather...weird:
- INVALID PATHNAME SYNTAX
- NONEXISTANT PATH
- VOLUME NOT MOUNTED
- BAD PRODOS VERSION
- NOT A PRODOS DISK
And so on. Track 15, sector 14 has the text: "PRODOS ERROR # [...] HAS OCCURED!"...
It seems to me PRODOS isn't a copy protection or code scrambler but rather...the DOS from the Apple systems.
Also...track 13 and 14 look suspiciously like city layout bytes.
Track 15, sector 10 has "BURGER".
Have a look at track 15, sector 4 of the BTIII boot disk. You can see the various error messages stored there which seem rather...weird:
- INVALID PATHNAME SYNTAX
- NONEXISTANT PATH
- VOLUME NOT MOUNTED
- BAD PRODOS VERSION
- NOT A PRODOS DISK
And so on. Track 15, sector 14 has the text: "PRODOS ERROR # [...] HAS OCCURED!"...
It seems to me PRODOS isn't a copy protection or code scrambler but rather...the DOS from the Apple systems.
Also...track 13 and 14 look suspiciously like city layout bytes.
Track 15, sector 10 has "BURGER".
Right, consider this article:
http://en.wikipedia.org/wiki/Apple_ProDOS
Specifically:
Now, look at a section of the BTIII boot disk:
Bard's Tale III is "encoded" using Apple Prodos V2.0. I think that rather conclusively proves it, although I'm open to reasons why I'm wrong.
http://en.wikipedia.org/wiki/Apple_ProDOS
Specifically:
Note the ".SYSTEM" I bolded above.With the release of ProDOS came the end of support for Integer BASIC and the original Apple II model, which had long since been effectively supplanted by Applesoft BASIC and the Apple II Plus. Whereas DOS 3.3 included built-in support for BASIC programming, under ProDOS this job was given to a separate program called BASIC.SYSTEM, which one launched to run and write Applesoft BASIC programs. BASIC itself continued to be built into the Apple ROMs; BASIC.SYSTEM was merely a command interpreter that allowed BASIC programs to access ProDOS by means of the same "print Control-D" method they had used under DOS 3.3. BASIC.SYSTEM alone required about as much memory as the whole of DOS 3.3. Since the ProDOS kernel itself was stowed away in the "Language Card" RAM, the usable amount of RAM for BASIC programmers remained the same under ProDOS as it had been under DOS 3.3.
Now, look at a section of the BTIII boot disk:
Bard's Tale III is "encoded" using Apple Prodos V2.0. I think that rather conclusively proves it, although I'm open to reasons why I'm wrong.
This actually sounds quite reasonable to me; according to Pete Rittwage's site, the only copy-protection present on the BT III disks should be the codewheel. All the disksides should be copyable. What sense does it make to do two different versions, when you could make an interpreter for almost everything in the Apple II version?Darendor wrote:Track 15, sector 14 has the text: "PRODOS ERROR # [...] HAS OCCURED!"...
It seems to me PRODOS isn't a copy protection or code scrambler but rather...the DOS from the Apple systems.
I'm pretty sure that you can find the exact same datastrings you find on the C-64 disk on the Apple II disk. This might also give me an opening to the images? Are these stored in some kind of native Apple II graphics format?
So far i've managed to find out that the images are stored as sequential commands, not as a bitmap image. I believe the image is plotted in vertical sequences from the upper left corner, and all these sequences are ended with byte #$FF. Removing parts of the image (counting the divider #$FF bytes) from the end causes the image to lose animation-frames and if you continue - parts of the image. I will investigate this more thoroughly later.
/Twoflower