[My Profile] [My Settings] [Exit]  

Home Blog My Games Reviews Friends Exit
bloomer Visiting my blog, eh? Wise move. I think we should all try to understand other people, no matter how stupid their beliefs.

Title: Adventure game development progress (contains detail that may be too much for the passerby)
Posted: July 21, 2009 (11:17 PM)
In the way that cars immediately fill any new road you build, any resources you add to a computer tend to be immediately drained by any new game. Still, the resources were drained a lot faster in the old days, and sometimes there was no roadwork for years. The Commodore 64 came with 64kb of RAM, and that's what it shipped with for about a decade. The Apple IIe had 64kb as well, later 128kb, and had a production run of eleven years, which I think is the world record for any PC.

If I had even the 64kb available for programming my Apple II adventure (let alone a mouth-watering 128kb), I'd be totally sorted. But if you use BASIC at all, as I am, the BASIC code can't access the second bank of 64kb. Then, after the OS and BASIC interpreter are in memory, what you've really got is about 35kb tops. Even if I run this thing on an emulated IIGS with several meg of RAM, I'm still stuck with 35kb of working space. Even when the game data and code take up almost two 140k floppy disks, only 35kb can be in memory at any one time.

If you're wondering, 'Why are you using BASIC?', it's because this is an EAMON, so I'm using the EAMON engine as a base, and it's in BASIC, so this is how its gotta be.

I realised a few days ago that the game was in jeopardy of running out of working memory before being completed. Compared to most EAMONs, it has a massive item inventory, and I've also developed some nice synonym and disambiguation code for the parser that I think modern gamers would not tolerate the game without. The synonyms and item/enemy data loaded on their own take up about 60% as much memory as the entire game code.

EAMON's main trick to be able to do what it does in the first place is to keep all static text content in random access text files on the disk. You can pluck one paragraph at a time out of these, print it and then forget about it. So if I have scores of room descriptions taking up 6kb, I can 'get' the whole lot at the price of only 1kb of working memory - the size of the file read buffer - and at the speed cost of a brief read from the drive each time the player enters a room.

To make my game have a chance of fitting in memory, I've palmed off nearly every single piece of text in the game, no matter how small, to such disk files. Even 'You see nothing special' is no longer a string stored in memory, it's part of a random access file on the floppy disk, and I have to keep an index of the 500+ paragraphs and messages needed by the game. The disk drive light will be on about 90% of the time while playing.

Another thing I did when I saw the memory danger coming was to prioritise game features. A bunch of verbs and their consequences went onto a luxury list that may never get implemented. I have to make sure the core stuff fits in first.

Nearly ever gesture you make to save memory is at the cost of execution speed. After programming and testing the game in an unlimited speed IIGS emulator, my first test of how it played back at real Apple II speed, 1 Mhz, freaked me out. The datacrunching pauses seemed huge. So I compared my game's execution speed to that of Infocom's Wishbringer as it would have run on a 1 Mhz Apple II. I was relieved to discover that my game is only marginally slower than Wishbringer, so I feel cool about that now. Besides, the pauses seem to add atmosphere, and make the action easier to follow as it scrolls by.

When the game is online, it may be able to run at 2Mhz, but any faster than that currently causes a sound bug in 'Apple II GO', though all other emulation would be fine.

So there's still the 'out of memory danger' ahead, but I feel moderately confident I can get this to work. Primary completion of the game code is still probably at least a week away. Then comes full playtesting, editing, debugging, and the biggest task of all, balancing all the weapon and monster stats. Combat is fully coded already, but everyone and everything has the same stats.
[reply]

honestgamerUser: honestgamer
Title:
Posted: July 22, 2009 (03:46 AM)
Interesting stuff. I understood way more of that than I probably should have as a result of working with PHP/MySQL... which I know isn't the same thing as BASIC at all, but it's interesting how the logic is so similar.
[reply]

aschultzUser: aschultz
Title:
Posted: July 22, 2009 (07:47 AM)
I remember writing a first-person RPG(without graphics, just said "walls to left/right/etc") and it ran out of memory near the end of what I'd programmed.

I probably could have used more text files, now that you mention this. I think I ran into a problem of my own with some text adventures, too. The tradeoff of time vs memory used is an interesting one. I'd forgotten how long even text games took to load on the Apple--for the various Infocom games I used WinFrotz, which is of course super fast.
[reply]

sashananUser: sashanan
Title:
Posted: July 22, 2009 (11:51 AM)
"Commodore 64 Basic V2 - 38911 basic bytes free." as the startup screen used to go - definitely a lot less than the 64k technically available for those sticking to the Commodore's version of assembly.

I remember when our first Commodore 64 broke down, much of the memory had become unusable, and the starting screen reflected this by showing a much lower four digit number of available memory. As I recall, it was able to take about a 30 line Basic program for me before the Out of memory errors cropped up, the poor thing.

Other people have had pets as a kid and learned the concept of death and loss when their pet died. I didn't have one, but the loss of that Commodore had enough of an impact for me to remember the above. As did the saving up for a new one, which my dad had me buy from pocket money this time. Pedagogically sound, in hindsight.
[reply]

bloomerUser: bloomer
Title:
Posted: July 22, 2009 (08:13 PM)
RIP Sash's C64...

38kb of BASIC bytes - sounds like the Commodore's OS and basic interpreter took up a few kb less than the Apple II's.

The Commodore's problem in the adventure and RPG genres was its disk drive system, which was pretty awful. This didn't matter when usually the computer could load an entire arcade game in one hit, or only have to load more data once per level if at all. But most RPGs need constant microscopic disk access with no read errors. The Apple II drive was excellent at this, so that's where most of the 8-bit RPGs were made. Every time you would read from the C64 drive, it felt precarious, like there was always a chance it would fail.

ASchultz, I'm not sure how you programmed your game, but under DOS 3.3, the theoretical max BASIC program size is about 120 sectors (it wiggles depending on how many strings and variables the program uses. If you use hundreds of big arrays, useable program size may become just a handful of sectors)

If the game doesn't use any hi-res graphics, you can actually try to use the whole 120 sectors. BUT... if you use hi-res graphics, your BASIC code will begin to march right through graphics memory after 20-24 sectors of program size. This causes no explicit error messages, but as the program grows, BASIC code begins to manifest as glitches and lines on the hi-res display. What inevitably happens next is that your program issues some kind of graphic drawing instruction, and the resulting pixels are written as bytes over the tail of your basic program. This is the point at which the BASIC code and line pointers are corrupted and destroyed, and either the tail of your program or the whole thing suddenly appears to be garbage when you list it, or it may just vanish.

One way around this was to move the pointer to the start of the basic program to just above the hi-res screen. This reduced the active memory available to the game, but certainly meant you could load code that was bigger than 24 sectors - but obviously not as big as 120, either.

There must have been other hacks around this. I was just looking at Fortress of the Witch King. It's written in BASIC, is 76 sectors long and uses the hi-res screen. I don't think that could be achieved using only the method I just described.
[reply]

zippdementiaUser: zippdementia
Title:
Posted: July 22, 2009 (10:32 PM)
Kudos to you for putting so much work into your project. If you make it available for MAC, I'll gladly play and revie it once finished.

Of course, I could probably just set up a DOS application on a linux machine using ubuntu and do it that way.
[reply]

bloomerUser: bloomer
Title:
Posted: July 22, 2009 (11:07 PM)
Thanks Zipp. Good news is you shouldn't have to worry about any of these platform issues. From the start, I've aimed to have this game run in a browser-based java Apple II emulator. So anyone will be able to boot the game through any OS and web browser simply by visiting the URL. I wanted to remove any need to download or fiddle with anything emulator related, or even to know anything about an Apple II, that might be a barrier to playing.

The one hit I've taken is you can't save the game for another day in this emulator, only within sessions. But I've even tried to design the game with this limitation in mind. It's not of Zork like complexity, it's fast to replay, and in many instances you can go back a move if you die.

There's actually a just released version of a IIGS browser-based emulator that has added save states, but its newness seems to spark browser and OS compatibility issues, plus users must download a plugin to be able to use it. So at the moment, the 'super convenience and ease of use and no need to download anything' option is still winning as the venue for the game.

Of course, people who like it, or do pine to be able to save the game between days, will be able to download the floppy images and run it in any Apple II emulator they like.
[reply]

aschultzUser: aschultz
Title:
Posted: July 23, 2009 (10:08 AM)
Oh wow. A bug in the programming language itself. I rarely mixed hi-res graphics and text, so I never saw that. Would've sucked to lose that work.

I forget if I actually programmed in the feature where I would load in a text file with the map for each level. But I remember feeling it was something for the pros, as I noticed when I played Bard's Tale. I forget if that intimidated me or spurred me on.
[reply]

bloomerUser: bloomer
Title:
Posted: July 23, 2009 (07:48 PM)
Hm, there may be some other buffer or trap you ran afoul of. Your text files would have to be absolutely monstrous in size to get 'out of memory' with a text only game.

In more info nobody else can use, re: the hi-res graphics bug, I learned just yesterday from a book that it doesn't happen under PRODOS. You still lose lots of working memory from your BASIC program if you use HGR, but once the graphics are on, the OS is nice enough to split your BASIC code around it automatically.
[reply]

eXTReMe Tracker
2005-2012 HonestGamers
Opinions expressed in this blog represent the opinions of those expressing them and do not necessarily reflect the opinions of site staff, users and/or sponsors. Unless otherwise stated, content above belongs to its copyright holders and may not be reproduced without express written permission.