Happy 2018 everyone!
I didn’t get quite as much done as I’d hoped, but I did make some significant progress on the CRPG.
I finally finished the title screen! I may still go back and tweak it a bit later, but right now it looks good enough to ship with if needed.
I also completed the musical opening, although I still need to integrate it into the program. I’m still going to do some work there as well; there’s a bug where after the song is completed there is a last little “bing” of notes from a source unknown. I also want to soften the volume on it; it’s rather loud on the hardware even with the P.E. Box on.
Code-wise, I completed the Travel module, all that remains is the sailing portion which is tied into the manager module. I’ll no doubt have many bugs and issues to work through once I run it, but at least it’s code complete and it compiles without error.
The manager module is a bit of work, because I’m throwing out most of what I’d done previously and starting fresh. For statistics screens, I originally loaded screens from disk and then populated them with values. This time around, I’m generating the screens completely in code. (Yes, I COULD store them complete screens in memory, but see below on that.)
I’m hoping that transaction code will remain mostly the same with just some tweaks. I figure I have at least a couple multi-hour sessions ahead before I can call the Manager module code complete.
My goal is to keep the program file, which is loaded in chunks into the extended memory, at 128K. This is to keep the base disk size for the entire program at 180K, because there are still a LOT of 99’ers who lack disk controllers capable of more than that. Disk controllers are mostly TI on eBay these days, and if you don’t get an 80-track modification done to them they’re limited to 180k.
gorgeous title screen!
Thanks! I may still change some colors… I’ve discovered that luminosity matters almost more than actual color. So both yellows and the grey are actually SO bright that they don’t work for background very well.
Remember that you do not have to create the perfect game, but an exceptionally fun game. I follow your progress from the beginning, I hope that in 2018 I will finally be able to play with this little gem !!
You will be playing it THIS year. My goal is to have a playable form by Fest-West to show off, and possibly distribute.
I doubt all the game content will be completed by then (that’s where my perfectionist tendencies really rear up) but if the basic engine is more or less done, that part will be pretty easy anyway.
Playtesting and troubleshooting is going to take the longest. My plan is to get a small core group of testers to help with that, some of which will not be 99’ers because I want feedback from several directions.
What a great looking title screen.
It would be a lot of fun if we had access to a time machine, go back to the year 1982 and present our retrogaming RPG creations to the publishers back then. Imagine their reactions – these games would be *the* killer apps that encourage people to buy even more of those computers we’re developing for.
Indeed that would be fun! Mind you, mine would also require a card that didn’t exist until 1993… 😉
I’ve been asked to consider making my own CRPG as a purely plug-in cartridge game. I decided against it because of the difficulty in producing physical copies of the game — it’s much easier to release it on floppy disk to support legacy hardware while recommending that they play it on an SD card reader. The SD card reader with fastloading enabled on the VIC-20 loads the game already pretty fast. I’m sure that banking/swapping the game contents from cartridge into addressable memory would be faster, but the SD card is good enough in this case. And even for those who will play the game on floppy disk, I am mindful to minimize disk swapping as much as possible.
Technically speaking, Commodore never released an official 32KB RAM expansion cartridge for the VIC-20 but there were third party companies that did put out such cartridges (some that even provided 40KB of additional RAM) and you could combine two 16KB official Commodore cartridges together onto a port expander to give you 32KB.
But yeah, the conventional VIC-20 setup in the early 1980s was just the stock machine with no RAM expansion and a cassette drive. A lot of games were put out on cartridge (game ROM size was typically 4K, 8K or 16K) that made the issue of the 5K RAM available only to the stock machine moot. It was considered rare for a user to have RAM expansion and many VIC-20 users quietly abandoned the VIC-20 and moved on to the Commodore 64 (the latter machine was compatible with the VIC-20’s peripherals). Why spend money on expanding the RAM on the VIC-20 to use a limited software library that supported it when you could just pay only a little bit extra to get a brand new C64 that was the hottest thing around in 1983?
Yea, and I have to concede that my game’s system requirements for a VIC-20 with 32KB RAM expansion plus disk drive would have severely limited the customer base at the time. While these peripherals were available in it’s heyday, the vast majority of it’s users just had a stock machine (no extra RAM), a cassette drive and a joystick. And with the Commodore 64 coming out recently, why buy all that extra RAM (which was expensive) for a few games that required it when you can buy a C64 which was going to have a much larger software and games library?
I like the VIC-20 and I want to see mid-1980s style CRPG games made for it. It’s the canvas I choose to express my creativity. And the argument that I should develop the game for a modern platform is moot in that emulation has been available forever now.
In fact, I have a competitor in the VIC-20 CRPG dev arena: https://twitter.com/petrih3/status/897548652498923520 (I actually posted on his Twitter, calling him a “worthy adversary” in a funny and friendly way). Apparently, he wants to release the game in cartridge format. He’s using compression to fit everything into 32KB. While I concede that he is technically a better programmer than I, I get an advantage in that my game will have 600KB of content spanning four floppy disk sides and that I’m an OCD obsessive who wants to see this game I’ve always wanted to make since I was 14 years old finally coming to fruition.
I’ve been asked to consider making my own CRPG as a purely plug-in cartridge game. I decided against it because of the difficulty in producing physical copies of the game — it’s much easier to release it on floppy disk to support legacy hardware while recommending that they play it on an SD card reader. The SD card reader with fastloading enabled on the VIC-20 loads the game already pretty fast. I’m sure that banking/swapping the game contents from cartridge into addressable memory would be faster, but the SD card is good enough in this case. And even for those who will play the game on floppy disk, I am mindful to minimize disk swapping as much as possible.
Technically speaking, Commodore never released an official 32KB RAM expansion cartridge for the VIC-20 but there were third party companies that did put out such cartridges (some that even provided 40KB of additional RAM) and you could combine two 16KB official Commodore cartridges together onto a port expander to give you 32KB.
But yeah, the conventional VIC-20 setup in the early 1980s was just the stock machine with no RAM expansion and a cassette drive. A lot of games were put out on cartridge (game ROM size was typically 4K, 8K or 16K) that made the issue of the 5K RAM available only to the stock machine moot. It was considered rare for a user to have RAM expansion and many VIC-20 users quietly abandoned the VIC-20 and moved on to the Commodore 64 (the latter machine was compatible with the VIC-20’s peripherals). Why spend money on expanding the RAM on the VIC-20 to use a limited software library that supported it when you could just pay only a little bit extra to get a brand new C64 that was the hottest thing around in 1983?