Denial

Continuing to work on the combat engine. This is how the combat menu looks like for the individual character:



Basically, whoever is highlighted in the party list below you get to choose the action for.

If you choose an action that is not available to that character, then an error message appears (like "CAN'T DO THAT!"). Only thieves and monks can backstab, and cast spell can't be done by fighters, monks and thieves.

There are 70 monsters in this game, here is the monster list (presented from least to most powerful):
Normal melee and missile combat has been completed from the player side and I implemented the GREET pre-combat option (basically, only works against intelligent monsters and it's a CHARISMA check against the active character). You can also view your character stats from combat (and you don't lose a turn doing so) and you return to the combat screen without disrupting the display (took quite a bit of memory to do this but the result is worth it)

Things for combat I still have to do:

-RUN away (pre combat round option, will be a DEXterity check on the active character). If the active character dies during combat, then this option will no longer work.
-BACKSTAB
-CAST
-DRINK potion
-USE magic item
-monster attacks
-monster special attacks
-check to make sure that water-based monsters can't attack on land and vice-versa

Of course there is a lot overlap of the above with normal non-combat options (like CAST, DRINK and USE) but so far I'd say that combat is about 33% done. So far, combat has taken about 1300 bytes of memory and hopefully, I can keep it below 4000 bytes in total.

Today I worked on the standard monster melee attack part of the combat engine. Now the monsters can damage and kill members of the party.

And when the monsters attack, the image of the monster is flipped vertically to give combat a sense of animation.

As well, if you kill more than half the monsters during a battle, a check against their morale is made--so monsters have the option to flee.

Combat engine is now about 1700 bytes big, which is not too bad. Hopefully the other aspects like adding XP for killing a monster, special attacks and collecting treasure do not use too much memory.

Hey guys, do you think this is a fair encounter for a first level party?



(I'm just playtesting the encounter generator -- I purposely rigged the program for testing 2-row encounter generation, these don't come until the party reaches an average character level of 3 or 4)

Mmh, this could be a close fight

Schlowski wrote:Mmh, this could be a close fight

Heh, yeah.

The encounter generator now makes sure that no sea monsters appear on land. Land monsters do appear on the sea if the encounter generator produces a pirate ship (pirates in the back, and xorns in the front line for example).

I'm thinking of making a picture of a PIRATE SHIP, but with only 7400 bytes free or so, "feature creeping" is eating away all of my free RAM.

Now that the Mega-Cart has been put out, is 32+3K RAM the new standard for VIC-20 memory? That extra 3K looks more and more tempting every day

I think I'll stick to 32K expansion -- if need be, I'll make it a multi-file disk loading game. Each monster portrait is 200 bytes and it would be easy enough for the game to load these into memory as they're needed (you only face 2 monser types with every encounter) and it would only take about 3 seconds of loading time for every encounter (maybe even less--save game and load game from a real disk, which is about 420 bytes of data or so only takes about 2 seconds).

I could save 6600 bytes of memory with this method or so. Other portraits like the throne, castle, pub, etc. would always be kept in memory of course.

With that, I could use those 6600 bytes to move the map data from the main program area (2000 bytes) over there as well use all that extra space for music data, and maybe for even more in-game portraits. The monster names which take up well over 500+ bytes of memory would be moved there as well.

Of course if I go with this, I can no longer make this a cartridge based game (and I would get rid of the option to save/load to tape). But with a multi-file loading game, I can put in a multi-color graphic screen and game instructions won't have to be part of the main game program (I was planning to cut these out anyway with the single loading game to save memory).

This is just me thinking out loud, of course. But it is an option that I've been thinking about for a while.

Schlowski wrote:Mmh, this could be a close fight

Quite considerate of the monsters to queue up to fight light that, one after the other though, isn't it?

Ghislain, have you researched anything about runtime compression? I think some people here on the forum might help you get pointers, e.g. Macbeth, a1bert and others. Without studying how your images and other data is stored, it appears to me you might come up with a compression algorithm to fit even more into memory, at the cost of a generic decompression routine. Well, that is unless you already have compressed the data a lot.

I was thinking the same thing since memory is becoming an issue now - you will need some form of compression on top of what you already have (I believe you're doubling the pixels to make a larger image at the expense of resolution right?)
I'm certain there is a few routines floating around that you can make use of...looking good man...love the screenshots on the actual TV....looks cool.

carlsson wrote:Ghislain, have you researched anything about runtime compression? I think some people here on the forum might help you get pointers, e.g. Macbeth, a1bert and others. Without studying how your images and other data is stored, it appears to me you might come up with a compression algorithm to fit even more into memory, at the cost of a generic decompression routine. Well, that is unless you already have compressed the data a lot.

No, I've not researched runtime compression. The thing is, is that my compiled code will probably take up all of the 32K of space -- what will I use to 'decompress' my game into? Anyway, if I'm wrong -- then that is something that I would definitely consider.

Macbeth's Minima game was limited to 2K and it 'decompressed' itself into a Commodore 64 with 64K of RAM. I'm not so sure how this would work in the context of my game.

I'm already using my own forms of compression that I created on my own:

-the 64x64 map of 4096 locations only occupies 2048 bytes of memory because each location uses 4 bit nibbles

- the 9 dunjons are being mathematically generated by a line feed shift register (0 bytes of storage)

- my images are doubled vertically -- 200 bytes to 'double' into 400 bytes on the screen.

I've been very diligent in trying not to waste memory.

I think going the disk drive route will be the best way to go in this case. The only downside is about 2-3 seconds of disk access before every encounter.

As well, I'll probably create an IRQ music player and I will use a single byte to store musical note information:

bits 0-4 : values 0-31 for a 2 1/2 octave scale. I'll have a table that will have the proper POKEs for 36874-36876
bits 5-7 : 8 possible values for the length of the note.

So a 150 note tune will only use 150 bytes and so on.

I had 192 bytes of empty space in BLK 5 left and I figured I should use them for the following graphic:



When this game finally comes out, it's gonna be rated AAARRRRRRRR

darkatx wrote:I was thinking the same thing since memory is becoming an issue now - you will need some form of compression on top of what you already have (I believe you're doubling the pixels to make a larger image at the expense of resolution right?)
I'm certain there is a few routines floating around that you can make use of...looking good man...love the screenshots on the actual TV....looks cool.

Thanks! I kind of like the double height pixels -- they look proportional to the wide pixels in multi-color mode.

Ghislain wrote:bits 0-4 : values 0-31 for a 2 1/2 octave scale. I'll have a table that will have the proper POKEs for 36874-36876
bits 5-7 : 8 possible values for the length of the note.

Ah, I'm doing something similar in my music player except that 111xxxxx is treated as an escape code to read another byte which allows me to use any duration 1-32, codes to mark end of track and so on.

If you make very specialized songs you don't even need a full 2.5 octave note table. You could pull out the notes you actually use and re-encode the offsets bringing it down to ideally < 16 values.

darkatx wrote:looking good man...love the screenshots on the actual TV....looks cool.

Ditto. I tried it in VICE fullscreen @1280x768 (vertically stretched), and it looks much more readable and clear than in the screenshots posted here .

i pray for a 16k version because that is all i have....