Why do you want to create a MUD-like RPG? LambdaMOO and other MUD's are only enjoyable if you have other people playing, which isn't really practical or even possible on a TI calculator. If you are set on making a MUD-like RPG, this might help (it was taken from The 1337 guide to TI-BASIC):

**Quote:**

Objects in TI-BASIC

One of the main qualms programmers used to higher level languages (especially Java) will have with BASIC is lack of support for objects. However, you can simulate objects fairly well if you know what you are doing using complex numbers and lists. A complex number has the following properties (also listed are their equivalents in a higher level language):

-- Positivity/Negativity of real number (boolean)

-- Integer part of real number (unsigned int)

-- Decimal part of real number (unsigned int)

-- Positivity/negativity of imaginary number (boolean)

-- Integer part of imaginary number (unsigned int)

-- Decimal part of imaginary number (unsigned int)

As you can see, one complex number can hold quite a bit of data (six instance fields, to be precise). Now, considering that you are programming on a calculator running at 6 MHz, that is quite a bit of flexibility and power if you know how to unlock it using the real(, imag(, iPart(, and fracPart( commands. Think of how many classes you can emulate with six instance fields; there are quite a few! For example, you could have an enemy spaceship that has an x and y coordinate (determined by Integer & Decimal parts of real number), a directional heading (Integer part of imaginary), a health amount (Decimal part of imaginary), a boss indicator (postivity/negativity of real), and some other indicator (positivity/negativity of imaginary). One could create quite a complex and memory-efficient game following this plan. Unfortunately, this approach is not very fast at all. It takes quite a bit of work to compress/decompress a complex number, making this implementation of objects impractical for games that are in real time. There is however, a solution that sacrifices memory-efficiency for more flexibility and speed.

The other way you can implement objects is through parallel lists. In this approach, you create a series of lists, each one representing one instance field. For example, you might create LX, LY, LDIR, and LHEA if you were trying to create a game similar to the one described above. An object is represented by the values of the lists at a specific index. For example, the object with value one would have an x value of LX(1), a y value of LY(1), etc. As you can tell, this approach is much more memory-hogging, but it is worth it if you are more concerned about speed than memory-efficiency. Another advantage of this approach is that you are not limited to the number of instance fields you can have or their type. You simply create a

new list for every variable you want to have.