Creative Programming for Young Minds

[+OLD CS1]

Not trying to split hairs, just a thought. In many of my non-structured BASIC programs I use a "jump table" for sub-routines built from GOTOs at the beginning of the program. This mimics assembly vectors where, in 6500, you can do a JSR (VECTOR) and such construct is not available in BASIC. Such a program essentially starts like this:

10 GOTO 1000 : REM COMMODORE BASIC SYNTAX
20 GOTO 1510 : REM GET USER INPUT
22 GOTO 1630 : REM DRAW MAIN SCREEN
24 GOTO 1680 : REM UPDATE PLAYER SCREEN
26 GOTO 1703 : REM PLACE SCORES
 ...
 
10 GOTO 1000 ! REM TI EXTENDED BASIC SYNTAX
20 GOTO 1510 ! GET USER INPUT
22 GOTO 1630 ! REM DRAW MAIN SCREEN
24 GOTO 1680 ! REM UPDATE PLAYER SCREEN
26 GOTO 1703 ! REM PLACE SCORES
...

The idea is that within the program I can ALWAYS issue a GOSUB 24 to update the player screen, and GOSUB 20 to get input from the user, and 10 is always the jump to the main entry point of the program. If I resequence the program then I always start at 1000. It also means I can save a couple of bytes here and there as line numbers are not tokenized but are instead stored in their ASCII representation.

 

Obviously, using a structured BASIC interpreter or translator one can use labels instead of a jump table. But in this scenario I see no reasonable harm for using GOTO.

[Opry99er]

Owen, your menu complexity problem is the design. However, you had to solve the problem once to know what you wanted to do, now you have to figure out how to really solve the problem. Basically you have to solve the problem to know how to solve the problem. That is part of learning though. I, or any number of other people here on the forum, could have handed you a menu solution, but this is your project and you would not have learned anything from that.

 

Very true... Nor would have I asked anyone to write it for me. I have learned a TON in the process and it has been alot of fun overall.

 

To me it looks like you are stuck in what I call the "TI Trap". It is a way of presenting a menu that requires many levels and lots of text. Like TOD, "now type the name of the character to receive the ...". Ugh. Painful. While the old systems are restrictive for sure, there are better ways. Look at games like the Classic Zelda and other such games on other systems. You will find that interacting with merchants and such in the game is all done very quickly and efficiently through pop-up menus that let you make selections with the controller, etc.

 

 

Yes, some of this stuff will be implemented as well... But for the main menu, in exploration, there is really only presentation that was acceptable to me. The chore has been coding it effectively.

 

Separating your "data" from the "presentation" is also important. Your menu code should not have anything hard coded into it, otherwise expanding it or using it for another project will be difficult. This idea is typically known as MVC (model, view, controller) and can be put into practice on any platform and any programming language. You might want to try writing just a menu system as a stand-alone program.

I had thought about that.

 

Issue is that as many times as the exploration menu is accessed, the main.program would have to save a huge chunk of data to disk, load the menu program which would have to.import all that data, run the menu screen, update the data, save all data back to disk, re-load game file, reinuput all the new data, and continue. I use MENU in RPGs like 2-3 times a minute sometimes.

 

Unless your point was that I should DEVELOP it separately, then integrate/merge it with the main game program once fully tested. That is certainly plausible.

 

It was all working swimmingly until I made a few changes to improve the flow/interface of the SPELLcasting portion... Now I have a little crappy bug I am having trouble nailing down. I have a few ideas on how to fix it.

 

Anyway, I would like to send you my TIdBiT source via PM for the menu code. Another set of eyes could only help, and maybe you can help me with a.concept or two to improve the style.

Edited April 18, 2015 by Opry99er