Home

Drugwar//e - The Classic Game in Applesoft BASIC

Welcome to the Drugwar//e Project Page.

Drugwar//e is a recreation of the TI-82/83 game, which is itself based off of John E. Dell's 1984 PC-DOS game; coded entirely in Applesoft BASIC by a guy who really doesn't know Applesoft BASIC.

The goal is to release the first version that stays very close to the original. I have made some changes during the inital write that are largely just interface and display changes. All game logic, number generation, events, locations, and other details are true to the "original" (In this case, the TI-BASIC version.) Once this intital version goes final; I will begin expanding and modifying the game to better represent modern times.

Coding Applesoft BASIC on Windows 10.

** Current Status:**

VERSION 1.01 RELEASE!

This is the first non-beta release of Drugwar//e. Compared to Beta9, it has text formatted properly as well as numerous other small optimizations.

You can grab the ZIP package on the files page. Thank you to everyone who tested and the Apple2 subreddit (/r/apple2).

TODO:

80 Column for V 1.5

Start writing/working on Drugwar][ Enhanced.

Dev Log:

How did I get here? Seriously. I went from the crazy idea of wiriting this thing in Applesoft, to randomly reading about the GOSUB command, to actually sitting down and writing code. I expected development to go much slower and require more testing. But as I began typing in code and testing even small segements directly into an emulator, next thing I know I'm actually marking big sections of stuff off the map. I hit a point yesterday where the three things I had left to code; I could just put up a bypass screen to take care of it. I'd written literally a whole bunch of code and I wasn't sure if it'd run.

It didn't. It crashed right off. So I started chasing things and updating my Virtual Basic source code so they wouldn't happen in the future. They did..I kept missing stuff. Finally got the code running to the point you could play what was coded. I got excited, rushed it to beta; was unaware there was at least one massively huge bug waiting me.

# So Maybe I Was On The Wrong Track

Right before the "big" Beta 9 release with it's police; I did some "code" cleanup. After getting one memory full error, I got to thinking I maybe needed to reduce memory use overall. I started by re-using temporary variables where I could and using as many single-character labels as possible. I also decided to try and reduce the line count; but there's a lot I don't know about Applesoft, and it seems from the perspective of disk space; I was on the wrong track.

During the clean-up I removed a number of single-line sub-routines and just duplicated that line. From an execution standpoint, this is great; you lose some cycles to jumping around the code. But I really wasn't worried about execution time. I really just wanted to get it's size on the disk down first...so that I'll have more room to expand. Turns out that removing a single line sub-routine and duplicating that line actually uses more storage space.

When stored on the disk, a BASIC program is stored in a tokenized format. Your code is not stored in raw text, but all the BASIC keywords/commands are represented by a one byte character. Realizing this...cutting a commonly used single line as a sub-routine is a bad decision.

For example, the game titlebar in Drugwar is generated by a subroutine, which would look something like this in basic:

30 PRINT " DRUGWAR//E"
40 RETURN

and every time I clear the screen for some reason, I would just call it as a gosub:

560 GOSUB 30

From a number of lines perspective, this actually just adds two lines to the code as well as use some execution time to jump around; you have the line calling the subroutine, and then 2 lines for that subroutine. But from a storage standpoint, this SAVES you space. When tokenized, you're using just a couple of bytes to call the subroutine, a couple of bytes plus our text, and another byte (or two since line numbers may be tokenized?) to call the return.

So, it actually seems to make more sense for me to subroutine lines of text or other things I use over and over if I want to make the program take up the least amount of storage space.

I've been doing a lot of reading on Applesoft in the last few days...since I seem to absorb it better after coding for a while and keeping it fresh. I was halfway trying to work out how to format text easier as well as how to optimize things. I'm going to try and compact the code as much as possible since I have ideas for a LOT of additions.

*** When your wallet overflows, literally.***

So as I was testing the just released Beta2, I came across a problem I thought I'd fixed. I had some issues with the translation between Virtual Basic and Applesoft, even worse was that loading the BASIC on to the disc from a text file with CiderPress was giving me errors. Like I got a syntax error on this line when code was directly imported:

40 ?"SOME STRING OF TEXT"

The problem is looking at this, I can't see a syntax error. Applesoft doesn't care about spaces, and using a question mark is a perfectly valid shortcut for print. But the game hung up on it. So I typed literally the same thing back in, and it started working. So I started going over these as I found them as just a stupid conversion error. But every time there was a coke bust, I'd get an "ILLEGAL QUANTITY ERROR". At this point my brain was slightly frazzled and I wasn't sure what was going on. I could generate the number to the prompt using the print command...so it wasn't a problem with the things ability to do it.

Turns out it boiled down to a very very old habit I learned as a child from whatever book I was reading; I was declaring all the variables that weren't text strings as integers. Now, this seemed like a very good idea since I'm dealing with numbers; and you might be wondering how did declaring the variables screw me up.

Integer variables can only store a range from -32768 to 32768

So, when I delcared them as integers, I basically limited them to a signed 16-bit space. This doesn't work well when you have a coke bust in the game and you're multiplying the random number by 60000, let alone the fact you're adding 80000 to that! So the solution was to just not declare the variable, which let's it hold a 40-bit floating point value. Thankfully, this bug was a simple as doing a "find/replace" for "%" in the code and replacing it with...nothing. The only place % was used in the game was to declare the variable as an integer. So far cocaine busts were the only thing that triggered this problem, though it was going to happen the moment your wallet went over 32768.

Rround Those Numbers

I thought about this briefly when I started but decided I'd work on it later; but I don't generate the numbers exactly as the original TI did.

The problem is the TI has a round() feature which will round a number to a specificed number of decimal points. That's becuase it uses floating point for everything. So anytime a number was generated, it also rounded it to a whole nuimber. My solution, for the time being, was to use the integer variables which have no decimal points. This causes the problem above but also meant the rounding was incorrect. Actually, there is no rounding, it literally just cuts off the decimal points, so 5.0000004 and 5.9999994 would both "integer out" to 5. It affects the game logic in what felt like a big way as I was playing it.

But the Apple doesn't have a round feature. So we either have to code one, track one down and instert it in to the code, or find another solution.

In looking online, one easy solution that was mentioned was to just add .5 to any number you wanted to round, and then use the int function to truncate the decimal points. It sounds cheesy, but it actually would perform rounding in just the way I want to accomplish. If I have 5.34 for example, and I add .5 to it, I get 5.84; which still comes out as 5 when using the int function. If you have say 6.78, and you add .5 to it; it will int() out to 7. It's a simple and elegent solution if you want the number to round up at the halfway point, which is essentially I what I want. It's not much extra code and will probably be more efficient than writing a subroutine to round eveything.

Old Status

Beta 7 is up! It's closer to completion!

Loan shark has been programmed. I'm sorry, but you gotta have something else to get your ass moving.
Bank has been programmed.
Game Over scoring has been programmed.
I fixed a couple of syntax errors, though some of them were from the loan shark and bank code.

(10 OCT 2018)
Beta 6 is out! It seems to be the most stable/functional build yet.

The major bug resulting from my use of integer variables has been resolved. Fixing it wasn't the hard part, but going back through the code to manually integer numbers to drop decimals took some time. I also modified random equations to better match how they would have been rounded on the TI-82/83. This baiscally boils down to adding .5 to everything. The int() function literally just truncates at the decimal place; meaning 5.001 and 5.999 would return just 5. The simple addition of .5 to everything mimics "proper" rounding technique of everything .5 or above getting rounded up, while everything below gets rounded down. This was an idea I found when I went looking for ways to round numbers.

My next steps are to work on the bank, loan shark, and scoring for game over. Those are much less involved than the police.

Project Members:

• Jay Moore (admin)