yeah many people tend to judge the book by its cover. There are also the people who label a game as horrible, bad and not worth the download if it's large in size, even if it should be the opposite for many games

yeah many people tend to judge the book by its cover. There are also the people who label a game as horrible, bad and not worth the download if it's large in size, even if it should be the opposite for many games

yeah especially for RPG, you can't expect to get really good game if the game size is less than 10k. Especially if they claim it to be graphic, which will probably be because it's graphic opening screen and text game play. Well, I at least try to optimize the code as much as possible, so that I wouldn't need to make the game 50 subprograms and 1 main program. After I'm done with the main engines, like walking and recognizing events, battle engine, and some other quest-related things, it would be fairly easy to finish, just entering some data, like map, weapons, etc...

BTW, the battle system will be totally different from what I was thinking before ^^

Well, I at least try to optimize the code as much as possible, so that I wouldn't need to make the game 50 subprograms and 1 main program.

Sub Programs are evil!
Not really, but I try not to use them.
However, I don't care about everyone else.  I will play almost anything, and I have games with sub programs on my calc that I use often.  If people woln't play games with subprograms or if thier huge, it's thier loss.

There's a way to have subroutines inside the main program instead of subprgms in large games. You can use Lbl/Gotos for that or even just set a variable just for the routine to execute. Like, for example, when game starts, variable is set to 1, then it enters the main loop, which loops until that var = 0. If var = 1, it runs the title screen then main menu routine, then selecting an option changes the variable value to something else, causing the menu selection loop to be exited, and other things like walking engine and battles are entered and exited through a similar way. If a routine is used many times, like a big menu routine, just set to which value each options changes the variable into a list, and the menu choices into a string, then have that subroutine be ran.

However, by doing this, you limit yourself to 24 KB of RAM. For larger games, you have to either divide your game into chapters or use an ASM lib. Celtic can work, but it's harder to work with, since you always need to know at whcih line of code number the code you need to copy to another temporary program starts and make sure to remember when its location change (for example, if you updated the huge program).

Illusiat doesn't use Celtic III because first, when Celtic, Omnicalc, Symbolic or xLIB are installed, TI-BASIC runs slower in overall, especially For( loops, and I try to get as much speed as I can from the game (altough I'm sure Builderboy could maybe improve that). Another reason for not using Celtic is that the game was planned to fit very tight into a regular 83+ archive. The 83+ archive would not be enough to fit a full version of Illusiat 13 and Celtic III at once. Celtic II could have been an option, but it takes a lot of RAM, so it would have felt more restrictive in overall, not to mention I couldn,t really get used to its syntax and how it works.

Hmmm a simple and effective way in speed and readability that I personally use is:

in a separated program:
PRGM:ROT
:Ans->R
:If R=1
:Then
/subroutine one
:End
:If R=2
:Then
/subroutine one
:End

Say you have 20 subroutines. Split them in two parts to extra speed:

:If R<20
:Then
/all the subroutines before 20
:Else
/all the subroutines after 19
:End

Now from the main program to call a subroutine just:
:2
:prgmROT

TI-BASIC Developer has other ways. Some really mess with the TI-BASIC interpreter in tricky ways that even I am scared to use them.
http://tibasicdev.wikidot.com/subprograms
Oh, I discover on there that While is better than If:Then... Time to change stuff.

And others pages, if I remember right. In UnitedTI and stuff. I have to found them again...
(http://tibasicdev.wikidot.com/recursion)

I use the...

:Goto S
:Lbl A
sub routien stuff here
:End
stuff here
:Lbl S
stuff here
:If something
:Then
:For(I,0,1)
:If not(I
:Goto A
:End
:End
rest of code here

...approach. It works very well, but it isn't as fast as external subprograms.

If I want my 84+se to run faster than an 83+, I have to uninstall like 7 Apps (Including Celtic III and Calc Util). lol

Hmmm a simple and effective way in speed and readability that I personally use is:

in a separated program:
PRGM:ROT
:Ans->R
:If R=1
:Then
/subroutine one
:End
:If R=2
:Then
/subroutine one
:End

Say you have 20 subroutines. Split them in two parts to extra speed:

:If R<20
:Then
/all the subroutines before 20
:Else
/all the subroutines after 19
:End

Now from the main program to call a subroutine just:
:2
:prgmROT

i agree with this way i think it would be the eisiest(i know i spelt that wrong)