The TI-85 Game

aka what I did my senior year of highschool

The first name given to the setting that would become Trisis was “The Island of Kalor”, and it had absolutely nothing to do with pen and paper. It was an RPG that I was creating in TI-85 Basic just to prove a point to my friends. Namely that a good game could be made using TI-85 basic, and the reason it hadn’t happened yet was because no one talented had tried. The initial plotline I took the first party through in 2003-5 was based upon the storyline I created for the RPG. Most of the main villains used were the same; Garrick as the main enemy, Ratnor, and <female> with Self named Osiris as the fake main enemy.

The TI-85 RPG was a marvel of some very tight coding I am proud to say. It started out as me trying to prove to my friends that a decent game could be made in TI-85 basic, and didn’t need to be written in machine code like most of the other games. Of course if I had done the latter I could have had some nicer graphics than our ascii based RPG. Really though I found the challenge of making a fun game with the not so friendly TI-85 basic engaging.

After my friends played my proof of concept game, and they enjoyed it we set to making revision 2 of the game. The main limitation I was running into was the very limited amount of memory available. My best friend Chris and I started working on trying to trim the fat and give us more space to work with. The map engine I have to give Chris props for designing, he used ATM packets as a design model and we stored the maps as one String variable instead of as separate sub programs as I had in the proof of concept. We also had a set area for story line variable checks. This limited the number events that could happen on any one screen to two (unless it was a town screen where 1 of the events was used to trigger going to town).

This shaved off a lot of bytes, but left us with a small problem. When I decided to change the map looks, or edit the quest variable section it was quite unwieldy to do it via the PC edit and transfer method Chris was using. Enter me once more as I wrote a map editing program to pull a map section and then insert it into the string. There was one problem though. To be able to edit and recreate the map data (which was the single largest file in the game) I had to basicly have two copies of the map data on the calculator at once. The main file and all of the smaller sections to rebuild into the main script file.

So we designated Chris’s calculator as the map editor and mine had the main game engines. I went on to shave more data space off by moving the player and monster data from variables to fields in matrices (this shaved off an impressive 10-20% of the memory usage). I then created sub programs to perform often used sections of code ala procedure calls in more powerful coding languages. This shaved off quite a bit more data.

Revision 3 saw me overhaul the combat engine into a D20 based system rather than the obtuse and silly one I had been using. Unfortunately this version has been lost for years in Vegas now. I had even revamped all of the menu screens and combat screens to look really pleasing to the eye with it’s sweet Ascii art/graphics.

This leads us to the short lived Java version.


Trisis dark3y3