Old skool coding tricks

[Nev]

That's a really interesting idea - make the game harder (but playable) if an illegal copy is detected.

[SineSwiper]

That's a really interesting idea - make the game harder (but playable) if an illegal copy is detected.

No, it wasn't really playable. You couldn't escape the battle (no running away), and the FBI Agents would definately kill you. I think they had some ungodly amount of HP that you couldn't reach, and they would usually kill you in 3-4 hits. The first copies of the game were actually bugged, and they forgot to add the bad sector, so those agents appeared on legit copies. (My parents got one of these, but they were able to mail the disks in and get a good copy.)

Another interesting character in the game:

The Devourer is one of the most famous (and feared) creatures in the game. It is also one of the most amusing, if you know it's story. You WILL get a visit by the Devourer if you carry too much different stuff (depending on how much spells you have and how much items are laying around in the game, it'll take about four or five full iventory screens). He will consume your things when you do encounter him, he will begin with the heaviest item first (and avoiding the one-of-a-kind items until last). Some things can however sometimes be retrieved from Master Thieves if you ever encounter one after having an encounter with the Devourer. The best way to deal with Devourers is, in my experience by using the Temporal Fugue spell.

Dan Pinal and Ken Jordan implemented the Devourer to deal with a memory problem they encountered. Since each item in the game (spells are also a kind of item) have alot of different properties, such as damage, weight and so on, it was quite memory consuming for a 48k or 128k computer. So, in order to limit the number of items that was in play at all times they invented the Devourer and made him come visit players with too much memory consuming items and lighten their load, and also the load on the memory.

Creative way of dealing with a memory problem, eh?

[Nev]

That's a really interesting idea - make the game harder (but playable) if an illegal copy is detected.

No, it wasn't really playable. You couldn't escape the battle (no running away), and the FBI Agents would definately kill you. I think they had some ungodly amount of HP that you couldn't reach, and they would usually kill you in 3-4 hits. The first copies of the game were actually bugged, and they forgot to add the bad sector, so those agents appeared on legit copies. (My parents got one of these, but they were able to mail the disks in and get a good copy.)

Another interesting character in the game:

The Devourer is one of the most famous (and feared) creatures in the game. It is also one of the most amusing, if you know it's story. You WILL get a visit by the Devourer if you carry too much different stuff (depending on how much spells you have and how much items are laying around in the game, it'll take about four or five full iventory screens). He will consume your things when you do encounter him, he will begin with the heaviest item first (and avoiding the one-of-a-kind items until last). Some things can however sometimes be retrieved from Master Thieves if you ever encounter one after having an encounter with the Devourer. The best way to deal with Devourers is, in my experience by using the Temporal Fugue spell.

Dan Pinal and Ken Jordan implemented the Devourer to deal with a memory problem they encountered. Since each item in the game (spells are also a kind of item) have alot of different properties, such as damage, weight and so on, it was quite memory consuming for a 48k or 128k computer. So, in order to limit the number of items that was in play at all times they invented the Devourer and made him come visit players with too much memory consuming items and lighten their load, and also the load on the memory.

Creative way of dealing with a memory problem, eh?

That is amazing.

I may have to use that. Cell phones have HORRIDLY low memory!

[SineSwiper]

That is amazing.

I may have to use that. Cell phones have HORRIDLY low memory!

I noticed that the items weren't lost completely. I'm guessing because they still saved the item in some sort of "lost items" stack, maybe with less information about them (like the weight, repair state, etc.). If you found the item again, the game probably just recreated the item and took it off the stack. More info about the enemy:

<i>"Dan and I thought that existing RPGs were extremely unrealistic in that you could carry (for example) eight items no matter if they are paper clips or boulders. We wanted to change this for the Dungeon. How much you carry in the Dungeon was determined by the weight and bulk of the items carried and your stats. The problem with this was that in the AR system each object was unique (except commodities like food, money, gems) and had a structure with attributes (like "spells" which were small intrepreted programs embedded in objects). Those data structures took up memory (16 bytes to about 64 bytes) and on an 8-bit 64K (or 48K) computer we had to limit the amount of items somehow. The way we came up with that was least artificial was to introduce a creature that would eat up objects when the object queue was getting full. Still I would be hard pressed to carry all the itmes in real life that characters can carry in the Dungeon. But when the number of large complex items becomes great the chance of meeting a devourer increases untill it becomes almost 100%. The AR system was not too graceful when memory actually ran out (since some partial objects may be left around with bad results) so the devourer must always be vigilant."</i>

From the Alternate Reality FAQ. (Might as well tell you what the game is called...)

Also, another interesting read: AR on Wikipedia.

BTW, on the subject of copy protection, I do remember a game that let you continue to play even if the game was pirated. I had a pirated copy myself (which apparently wasn't cracked), and it would randomly kill my party for no reason. I also noticed the random disk reads when it didn't need to. (The game only needed to read the disk when you went up or down stairs.)

I defeated this by ejecting the disk when I noticed the disk reads, and only put it back in when I needed it. However, I'm not sure if this worked. I just read up on the copy protection, and it's regarded among crackers as the most sophisticated copy protection ever created. It worked by putting in "weak bits" on a sector of the disk. On an original copy, reading these weak bits would produce random data. On a pirated copy, the data would be the same every time. The game would read the disk at random, and after several tries, it would kill your party if the reads were all consistant. The programmers deployed many ingenius tricks to confuse crackers from bypassing the checks, and it took several months before a crack was made.

[Kupek]

I noticed that the items weren't lost completely. I'm guessing because they still saved the item in some sort of "lost items" stack, maybe with less information about them (like the weight, repair state, etc.). If you found the item again, the game probably just recreated the item and took it off the stack.

The data was probably kept entirely intact. But the "lost items" stack was probably where the program went first when memory was dangerously low. Linux (and probably most other OSes) keeps a list of <i>active</i> and <i>inactive</i> pages. When Linux needs to swap memory pages to disk, it chooses pages off the <i>inactive</i> list. (How pages migrate from <i>active</i> to <i>inactive</i> is a long discussion.) This was probably the same basic idea. If it was possible to store the items in some format that took up less memory, they probably would have used it throughout the game.

[SineSwiper]

Kupek, you're not thinking old skool enough. There's no such thing as HDs back then (or at least not something you could rely on everybody having). You had whatever memory you had, and that's it. The character disk was used for saving, but it's not in the drive all the time. Most of the time, it's using one of the (many) game discs for loading map data.

(OS? We're talking machine code here. There is no OS, except for the ATARI ROM chip, which probably gets bypassed in this case.)

It's possible to store the items with less memory, but that would strip away the weight, repair state, and other stats that were put into the game. I figured that since the item was already considered lost, there was no need to keep these stats in that stack. The game could recreate the item as a fully-repaired weapon, look up the weight in its table for that type of item, etc. if the player happened to grab the item from a Master Thief. It's possible that the lost items stack only stored one-of-a-kind items, and any common items ate by the Devourer were lost forever (or until you bought a new one).

[Kupek]

Kupek, you're not thinking old skool enough. There's no such thing as HDs back then (or at least not something you could rely on everybody having). You had whatever memory you had, and that's it. The character disk was used for saving, but it's not in the drive all the time. Most of the time, it's using one of the (many) game discs for loading map data.

I'm fully aware of that. I'm simply pointing out that it's a common memory management technique.

[SineSwiper]

Oh, I know about swap files and how programs use them. Though, if Mental was going to use ideas like this for cell phone programming, he wouldn't have the benefit of a swap file, either.

Mental, how much memory you got to work with?

[Nev]

Depends on the phone. Newer ones can have upwards of 4-8MB heap, but there are still a lot of older phones out there and I wouldn't want to try to make a game that couldn't be ported so it would run on less than 512K - well, I might up that to 1MB if could, but the Motorola T720 is 512K I think and that's a phone with hella market penetration.

[SineSwiper]

Pssssha! If they could do it with 48K, you can do it with 512K. It seems like a device with a 100x100 pixel screen (or so) can get away with a lot. Audio seems to be the hard part, since you can do a lot with it and probably play 44.1KHz stuff with no problem. Taking avantage of that, of course, chews up a lot of memory.

Maybe you should talk to Phillip Price about porting AR to the phone. Or at least some of the older 8-bit games. It seems that a lot of those games used so much with so little memory, and you could pull it off the same way, even with upgrades to the video/audio.

[Nev]

AR?

[SineSwiper]

Alternate Reality, the game we've been talking about. Sorry.

[Kupek]

Oh, I know about swap files and how programs use them. Though, if Mental was going to use ideas like this for cell phone programming, he wouldn't have the benefit of a swap file, either.

You misunderstood me. The simalirty in the techniques has nothing to do with "swap files" but with seperating memory into "important" and "not important" categories.

[SineSwiper]

You misunderstood me. The simalirty in the techniques has nothing to do with "swap files" but with seperating memory into "important" and "not important" categories.

Yes, and when that piece of memory is marked as "not important", the OS will usually cram that into the swap file/partition as soon as it starts to need more real memory.