adamantyr

Congratulations! Perceiving the difference between design and the code itself is an important step in any software development. Adamantyr

Looks cool! Adamantyr

I looked into this myself, RESTORE works with line numbers only, and they have to be statics, it won't accept variables or logical statements. The technique I used was the following: 1000 ON L GOSUB 20000,20100 1010 REM LEVEL BUILDING CODE HERE . . . 20000 RESTORE 30000 20010 RETURN 20100 RESTORE 30100 20110 RETURN . . . 30000 REM DATA FOR LEVEL 1 30100 REM DATA FOR LEVEL 2 Adamantyr

Wow, I had no idea I planned 30 levels. (Need to clean up the quotes there, dude!) Adamantyr

Some BASIC programming tips: - One or two letter variables - Subscripted variables are noticeably slower to work with. Better to move subscripted values into placeholders in a loop - ALWAYS declare your subscripts in a DIM statement, otherwise BASIC will default-reserve 10 entries for each one - Type up your code in a text editor first. This works way better than BASIC, which has lousy line number management tools - Numeric variables consume 4 bytes each, try to reuse them as much as possible - You can use this technique to set a lot of variables to the same value in one line: "A=B=C=0" But it's not stable... I had times when the first variable was initialized to -1 - DATA statements with RESTORE and loops is the most efficient way to initialize graphics, color, sound, and other data - You can do some clever math tricks in IF/THEN statements, but the bigger they are the slower they will be. Keep the logic simple if you can Cmon, let's see some BoCC projects announced, even if it's just a game idea without a screenshot! My intention with my game post was to inspire, not demoralize! Adamantyr

And now... vertical portals! To set a portal in any direction, you press the fire button (or Q) and then push a cardinal direction. (Diagonals are ignored) I threw a cube back into test chamber 1 to do some testing with. Feel free to try and get it over on the other side of the chamber. Or up next to the exit. The cube will no longer displace one square after being pushed through.. a limitation of going to a two-axis portal system. This can create some complicated puzzle issues, as you may have to get creative to get the cube into another area and then right behind it. (You'll portal in on top of it, but don't worry, it's there) Next steps are inclusion of dynamic and event-based features: - Triggers to use with the cube - Energy balls flying around (and potentially through portals) - Electric beams - Areas that can open/close based on trigger state (Need a nice door graphic other than the exit I think...) - Moving platforms (probably more like an elevator that's triggered) Adamantyr

Good to know... I didn't think that would change much. With TI-BASIC, just cutting down on the number of lines of code between loops is a big help. For example, I broke the game loop for falling out from the general movement loop because I didn't want it going through and validating a bunch of stuff that you couldn't even do WHILE falling. (Yeah, you can't "steer" while falling. That's intentional; the screen is too small and the math too tight to do complicated physics.) Adamantyr

Okay, made some changes to the controls... I decided I wanted to use a joystick instead, and the fire button to do portals. You no longer directly control which portal is fired. It starts with one, then alternates between them. I was hoping that going to joystick would speed things up a bit, with less key tracking. No such luck... I think the main slowdown is the GCHAR to check that you got floor underneath you. Not much I can do about that; it's a side-game and gravity matters. On the PLUS side, my new control system actually brought a feature back I'd cut, jumping! I only discovered it because of another state check that allowed you to push up when a ladder was underneath you, but it was easy to extend it to be implemented all the time. Next step is to investigate vertical portals... Adamantyr

Here's a good thing to try: 1) Step away from the computer 2) Get a nice pad of graph paper... 4-5 squares an inch is ideal 3) Draw your 32x24 size border area, a 8.5x11 sheet of paper is well big enough for this 4) Start designing an "ideal" dungeon, one that you want your program to make 5) Look at what you drew, and start asking why you drew this chamber here, that passage there, etc. Basically, what you're looking for is the PROCESS of maze development. Then you just write down the code to support it. Adamantyr

Oh yeah, I forgot I set it on Level 2 so I could check the screen building was good. It's possible to get to the door. Right now, I'm considering if I want to add vertical portals. That totally changes the game dynamics, though, and I'll have to do a "button+direction" combo to indicate where you want to shoot the portal. Tracking two different keys may also be part of the cause of the drag on the controls. If I reduced it to one and just had it alternate between orange and blue, it may be faster. Adamantyr

Yeah, that's probably best... Adamantyr

Ah HA... yeah, everyone's got the same problem. The paste function on Classic99 isn't translating the ASCII character right. You'll have to enter it in by hand. These lines: 20000 DATA "4=2b;;4=3a5L4B>a6544La323B=c634Kc>16N™0" 20101 DATA "[email protected]`22;=`217J™0" Go to the TM character in TI BASIC and press CONTROL+SHIFT+Y That will insert character 153. Adamantyr

Another quick update... I have two test chambers designed using my new "encoded" system. It took about 120 bytes to define the second one, so I feel pretty good about getting at least 15 chambers into the game... I will have to focus on making levels that compress more easily into this system. Also need to create a spreadsheet to generate them more easily... I fixed the controls so you can do something new... I am noticing that the player is slowing down inch by inch as I add more functionality. That's the problem with TI BASIC, tracking more than a few things starts to really impact it. I think it's still playable in its current form, and most of the code to do stuff while you're moving is done. The game WILL crash on level 3, because of a lack of data. Adamantyr

I'm working on that now. I had never intended to use static HCHAR and VCHAR to build each one. Instead, I'm encoding the data to build each into strings stored in DATA statements. For example: 20000 DATA "493a5L4>Da654>:a344A:x243>Hc61=L€0" 20010 DATA "=3a=La" The first string stores screen build data. The first value is the type of action, the following is data. Breaking one down: 4 = Draw Block 9 = Row 3 = Column a = Character to draw 5 = 5 Rows L = 28 Columns (ASCII value of 'L' minus 48) The second string is coordinates for the player and cube. I will probably have a third string to store dynamics like buttons, power emitters, etc. The only tricky bit is printing characters above 127. The TI console does have some shortcuts; you can press CONTROL+SHIFT to add 64 to the targeted letter value and print it. So CONTROL+SHIFT+A prints 129 (65+64). The 128 character is an oddball, though. To get 128, you do CONTROL+SHIFT+, instead. So, using this technique, I should be able to keep each level very tight. Level design is going to be a challenge; I'll want each successive chamber to be slightly more difficult. Each one is a puzzle, so I could spend quite a bit of time there. Adamantyr

Yeah, got it now... you have to be right up against the wall for it to fail. And I know why... the player graphic and block graphic weren't considered viable empty spots for determining orientation. A single line fix and it's good: 1170 AD(PO)=ABS((G=97)+(G=99)+(G=128)+(G=146)+(G=147)) Adamantyr

Ah, small bug with the portal orientation... plus I had to make it so ladders and empty area were legitimate exit points, may still be some bias against non-empty in there. Thanks for catching it! Adamantyr

Yeah, keeping things fast in BASIC is really tough... I'm trying to have it so you can shoot off a portal while falling, but it seems the key responses aren't quite fast enough to catch it... or maybe you just need to fall further. There are a few events I need to track. My plan is to have them complete a whole cycle, rather than try and move with the player, because generally, BASIC sucks at doing more than one object at a time. So the "energy balls" will basically emit and travel their entire length before expiring. (No bounces) Adamantyr

Did some work on this tonight... So far my program is around 3500 bytes in size. I'm not sure how many "test chambers" there will be yet, as many as I can squeeze in to memory. As a short sneak-peek, here is my code so far. This allows you to move around, go up and down a ladder, fire orange and blue portals and traverse them, and move a cube around. KEY COMMANDS: E - Up S - Left D - Right X - Down O - Create orange portal on acceptable surface in facing direction B - Create blue portal on acceptable surface in facing direction Adamantyr (Edited to correct bug described in below responses)

See a bunch of lurkers tonight... anyone else working on their BASIC contest entry? Adamantyr

Super Extended BASIC has several very useful line number management commands. It was sold from the Triton catalog and was developed by Millers Graphics, I believe. COPY, MOVE, and DEL commands will let you copy, move, or delete whole sections of code by line number ranges. RESEQUENCE (shortened to RES, who types out the whole thing?) has the ability to renumber a range of lines rather than the entire program. Adamantyr

Tursi can chime in on this, but I think Classic99 does give us the disk drive in BASIC with the amount of memory that a TI could have without the DSR's taking up room. On the TI itself, you can also do a CALL FILES(1) followed by NEW to reduce the number of DSR files from the default (3) to 1. That will get you a bit more space to work with. Adamantyr

Thing to remember, you got the same code space as Extended BASIC... it's just not as compact. On the plus side, it's way easier to follow. Worst problem I'm running into is a lack of good line number management tools. I may need to load this up into Super Extended BASIC and use the advanced RES command to reallocate the line numbers in a slightly better way. Thanks for the vote of confidence, but the game's not finished yet... I'm working out the gravity and controls right now, which are tricky because I'm trying to make the looping as tight as possible so I get the most speed. Adamantyr

Normally I keep my projects under wraps until they're closer to completion... but the lack of posts and stated entries for this truly CHALLENGING contest requires a little preview. I plan on entering three games, if I can find the time to fashion all three. One will be turn-based strategy, another a side action style, a third a top-down action style. So, here's the name and a mocked up screenshot for what the final game will HOPEFULLY look like... it depends on how much memory I got to spare on features, and how much drag tracking multiple objects creates. Synopsis: You are test subject #99 of the Aperture research and development program, providing quality assurance for new military products. Your most recent acquisition is the Aperture gun, a device capable of creating a twin pair of gates in the fabric of the universe, allowing instant travel between two points. Unfortunately, the base you're working in has suffered a serious malfunction brought on by a power surge. The main computer responsible for maintaining the complex has sealed the entire complex from the outside and closed itself off from access. The other personnel are dead or trapped... only you can reach the central processing unit and shut down the computer! Requirements: TI Console, cassette player. (POTENTIALLY the Terminal Emulator II... I'd call that a special edition) UPDATE: Finished ZIP file containing both cassette and diskette versions of Aperture, as well as a DSK image for MESS and CF cards: APERTURE.zip

That's why it's a contest. Prove what you can do DESPITE the limitations. Adamantyr

A few points... TI BASIC is really slow. It is not designed for fast action gaming. Focus on turn-based games over fast arcade action. At the least, keep your number of objects moving to a maximum of three There is no command to display text anywhere on screen. Focus on display updates that use symbols and graphics over text You got two extra character sets in BASIC over Extended BASIC. Use 'em! While you can USE cassette to store data files (Not Polyoptics Hordes game did this), let's not get into that with this contest. Keep all the data local Color set changes are probably the best way to have the ILLUSION if not the reality of speed As a rules addendum, let's allow for key commands or instructions to be kept OUTSIDE the game itself. You are not required to provide in-game instructions or on-screen controls. Old BASIC games usually came with decent instructions and manuals so that the code could focus solely on the game. Adamantyr