Space Trek: TI-99/4a version

[+Vorticon]

Really close now The torpedo course function works great now even with border decimal values. I can no longer seem to replicate my LRS issue.

A couple of remaining issues:

• Sometimes when entering a quadrants with Klingons in it, the red alert does not go off. This only happens with the next command. A minor point, but it is important to the general feel of the game.
• When moving from one quadrant to another under impulse power, the coordinates of the new quadrant do not get reflected on the left hand side panel, although the LRS displays correctly the ship's location.

Other than that, it's really looking good now!

[+adamantyr]

Really close now The torpedo course function works great now even with border decimal values. I can no longer seem to replicate my LRS issue.

A couple of remaining issues:

• Sometimes when entering a quadrants with Klingons in it, the red alert does not go off. This only happens with the next command. A minor point, but it is important to the general feel of the game.
• When moving from one quadrant to another under impulse power, the coordinates of the new quadrant do not get reflected on the left hand side panel, although the LRS displays correctly the ship's location.

Other than that, it's really looking good now!

 

Working on 1.4! Fixing the course calculator was a major pain... I should paste out the original Coco code just to show what a nightmare it was, and why I just decided to roll my own instead.

 

I noticed that problem with movement via impulse, it wasn't refreshing the quadrant status. I also need to make sure it shuts off cloaking; if Klingons cloak at the moment, only warping in and out will force the flag to reset. (Could be worse, for a bit the Klingons could still attack you while cloaked! That's just unfair...) The ship also appears in the old position briefly before resetting to the correct one.

 

Torpedo courses for Klingons is also broken, I have this fixed in my working version now. For a bit, it was even giving you their positions if they were cloaked! I considered leaving that in as an advantage of using the main computer over manual targeting, but since you can't use phasers while they're cloaked, it doesn't seem right that the computer can "see" where they are.

 

Adding warp drive to the game definitely changes the gameplay from the original... I usually find myself using warp to move more quickly from quadrant to quadrant, and never using impulse at all. Part of it is that impulse movement is so SLOW... I can speed it up a little at the cost of some weird behavior while moving; if I just use straight values for the sprite it will move it as fast as a torpedo but it will also not make it quite align to the grid, which means the ship will "adjust" back to a grid position when it stops. I've found using custom functions is a HUGE drag on calculations in this manner...

 

One aspect I haven't tested against the original is how fast the game clock moves... currently it ticks a time variable to 500 on every key scan, which seems to give plenty of time... maybe too much? I need to play a game to completion and see.

 

Beyond these, it's mostly tweaks to menu displays, timing of information, little details to get it just right.

[Fredrik Öhrström]

If you use "Paste XB" instead of "Paste", Classic99 will tweak the internal pointers to allow for those longer lines (as well as stripping unneeded spaces to make the lines shorter to enter). The only caveat is if you aren't actually running XB, it might do bad things

 

I discovered accidentally that TI-BASIC allows for very long lines (perhaps unlimited) because it seems to ignore the byte that tells the length and just looks for the eol null byte.

You can create such lines from my editor here: http://nivelleringslikaren.eu/ti994a_basic

Is it a feature or bug? :-)

 

However Extended Basic does truncate the line. Since it is TI-BASIC, the only lines relevant are probably DATA lines. I just tested this line and it worked fine in MESS.

100 DATA 0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF,0123456789ABCDEF

Edited November 17, 2014 by Fredrik Öhrström

[+OLD CS1]

Holy crap, that editor and tape generator is bad-ass (runs right from the browser, ya'll!) I am curious about the line-length, though. In the old days we could exceed the four-line entry limit by entering a full line, then using FCTN-E, FCTN-X, or EDIT line-number. TI BASIC would then display one more blank line to be filled. You could do this a limited number of times. IIRC, the tape format for programs has a limited record length (168 bytes?) Perhaps that is the extreme limit for line-lengths using any trick.

[Fredrik Öhrström]

Holy crap, that editor and tape generator is bad-ass (runs right from the browser, ya'll!) I am curious about the line-length, though. In the old days we could exceed the four-line entry limit by entering a full line, then using FCTN-E, FCTN-X, or EDIT line-number. TI BASIC would then display one more blank line to be filled. You could do this a limited number of times. IIRC, the tape format for programs has a limited record length (168 bytes?) Perhaps that is the extreme limit for line-lengths using any trick.

 

I do not think there is a limited record length in the actual file format, the PROGRAM format is just a dump of the memory, I think.

However the in-memory format (which is interpreted and dumped) has a leading byte that indicate the line length but also an ending null byte.

Apparently the interpreter ignores the length byte and only looks for the terminating null....

 

And I just discovered that this is true for XB as well! Ie you can create arbitrary long lines in XB! You just cannot list them, the listing routing does look at the length byte, but not the actual execution!

 

I created this program in my editor:

100 A=A+1 :: A=A+1 :: ...repeated 106 times, a pretty long line.

110 PRINT A

 

Downloaded the bin, stored in to dsk, loaded into XB in MESS, run prints 106. :-)

[+OLD CS1]

Yet another neat way to "hack" TI BASIC. This could have been a poor-man's copy protection (still could be, I guess, except that we are not so concerned about copying these days.) I must be thinking about the media record, then, not necessarily BASIC's record limit.

[RXB]

 

I do not think there is a limited record length in the actual file format, the PROGRAM format is just a dump of the memory, I think.

However the in-memory format (which is interpreted and dumped) has a leading byte that indicate the line length but also an ending null byte.

Apparently the interpreter ignores the length byte and only looks for the terminating null....

 

And I just discovered that this is true for XB as well! Ie you can create arbitrary long lines in XB! You just cannot list them, the listing routing does look at the length byte, but not the actual execution!

 

I created this program in my editor:

100 A=A+1 :: A=A+1 :: ...repeated 106 times, a pretty long line.

110 PRINT A

 

Downloaded the bin, stored in to dsk, loaded into XB in MESS, run prints 106. :-)

XB has a tokenized buffer for storing programs..

That limit is buffer is called the CRNBUF (Crunch Buffer) and starts at >0820 and ends at >08BE (CRNEND) thus is 159 bytes long.

As your line is longer then the limit of the buffer to run that line the rest is ignored and not used.

 

Personally I always thought it was odd that XB did not have a 250 byte Crunch Buffer and 5 bytes for line number, memory location and length byte.

 

But then VDP memory in the TI99 is limited and that would create more problems with program space.

[+Ksarul]

Rich, the odd thing is, it IS reading the whole line, otherwise it wouldn't come up with the correct result of all of the addition that is going on in that line. The only way for it to come up with 106 for the answer is if it reads all 106 instances of A=A+1

 

There is something fishy going on with the crunch buffer here. . .as it isn't responding the way you would expect it to.

[+OLD CS1]

Considering most everything is word and not byte, my guess is the buffer counter is 16 bits and the line is just over-flowing the buffer. What sits directly above the crunch buffer? It should be easy enough to test by checking the contents after the end of the buffer for expected data.

[Iwantgames:)]

Finally got around to playing this on my TI, seems pretty cool. Haven't found any klingons yet but when I tried going into Warp (course 6, warp factor 7) the game crashed. Error line not found in 5220

[+adamantyr]

Finally got around to playing this on my TI, seems pretty cool. Haven't found any klingons yet but when I tried going into Warp (course 6, warp factor 7) the game crashed. Error line not found in 5220

Ah, interesting bug, I'll investigate! Version 1.4 should be up today. Thank you for finding it!

 

UPDATE: Found the bug, had a bad line number in the routine where on occasion, your warp drive has a flux which damages it and throws you into a random quadrant. Fixed!

Edited November 20, 2014 by adamantyr

[RXB]

Rich, the odd thing is, it IS reading the whole line, otherwise it wouldn't come up with the correct result of all of the addition that is going on in that line. The only way for it to come up with 106 for the answer is if it reads all 106 instances of A=A+1

 

There is something fishy going on with the crunch buffer here. . .as it isn't responding the way you would expect it to.

Ok change A=A+1 to A=A+6 and see if you get the correct answer.

 

Now the interpreter might read the entire line as no special look up words are in that line so it does not crash the interpreter.

 

So A=A+1 :: are all tokens that take a single token, even :: is converted to a single token >82 in hex within the interpreter.

Edited November 19, 2014 by RXB

[+adamantyr]

Version 1.4 is out! Besides bug and UI fixes, I made a few changes:

• I changed the time counter so it's longer for stardates to advance due to inactivity. Moving around quadrant to quadrant burns up time the most
• Removed the time-consuming rounding effect on using impulse drive, the ship zips along quite nicely now! (In case you were wondering, yes, I did try doing torpedoes with MOTION, Extended BASIC isn't fast enough to catch every affected square)
• Klingons now move towards you to try and close the distance, making their attacks more effective against shields

Please let me know if you find any additional bugs and issues!

[+Vorticon]

Well congratulations I was not able to detect any issues with the latest version.

It is pretty darn hard though at even level 3: It's a large map, and there does not seem to be an easy way to achieve the objectives in a timely manner no matter how hard I tried. One improvement I would recommend would be the ability for the computer to fire multiple photon torpedoes at multiple Klingons once it has computed the torpedo course to each. Otherwise, if there are 4 or 5 Klingons in the quadrant, you will get hammered and the shields will fail very quickly thus leading to substantial damage, and the only option will be to run away in search for a starbase. More time lost...

Good game!

Edited November 20, 2014 by Vorticon

[+adamantyr]

Well congratulations I was not able to detect any issues with the latest version.

It is pretty darn hard though at even level 3: It's a large map, and there does not seem to be an easy way to achieve the objectives in a timely manner no matter how hard I tried. One improvement I would recommend would be the ability for the computer to fire multiple photon torpedoes at multiple Klingons once it has computed the torpedo course to each. Otherwise, if there are 4 or 5 Klingons in the quadrant, you will get hammered and the shields will fail very quickly thus leading to substantial damage, and the only option will be to run away in search for a starbase. More time lost...

Good game!

 

Thanks!

 

The original game did not have difficulty levels, so level 1 is the best "baseline" against the original. I may need to adjust that; it may not be possible to WIN the game at higher levels. One thought is to have stardates equal to number of Klingons regardless of level, and just increase the number of Klingons to hunt down... their relative power levels are already unadjusted; with phasers being insanely inefficient to use, it didn't seem fair to give them even stronger shields.

 

The main issue I think is that you lose a stardate of time for every quadrant traversal. That means you NEED to destroy 2-3 Klingons in a quadrant to get ahead of the curve, and you can't waste any time dallying around in empty quadrants. Adding the warp drive (which allows you to jump over multiple quadrants at the cost of only one stardate) actually makes the game more winnable than the original, which forced you to traverse quadrants in order.

 

One strategy that is not readily apparent is you can just wait in a quadrant, and there is a percentage chance per stardate cycle that they will warp in from another quadrant... hard to rely on it though.

 

I'm past the idea of maintaining the game as an exact gameplay replica of the original CoCo version, now I'm looking to make it a balanced fun game that isn't impossible... Ideally you should be able to win the game at level 1 without too much trouble, and 5 should be a real challenge but not IMPOSSIBLE...

 

One thought is to instead of automatically advance a stardate for quadrant travel, just increment the timer counter for every sector move. I'd probably keep warp drive to a full lost stardate though for balance; zipping around comes at a cost!

 

I like the multiple torpedo idea, but I'd probably want to redo the computer commands to be, well, a heck of a lot BETTER. The original required you to compute course for most everything, and guided torpedoes only worked for one Klingon at a time. I'll give that some thought... I'd probably also advance the time counter for computer usage to reflect the additional time needed.

 

One final feature thought I had... why not give Klingons photon torpedos as well? They'd only fire them once in a long while (Like, 4% + difficulty level in %) but they'd be a devastating attack that could knock your shields out in one punch OR destroy the ship.

[+Vorticon]

 

 

One final feature thought I had... why not give Klingons photon torpedos as well? They'd only fire them once in a long while (Like, 4% + difficulty level in %) but they'd be a devastating attack that could knock your shields out in one punch OR destroy the ship.

 

Now that would really suck if you end up facing the last Klingon only to be blow away by a single torpedo!

BTW, is there a way to indicate how many Klingons are left on the main display? It will help with time management.

[+adamantyr]

 

Now that would really suck if you end up facing the last Klingon only to be blow away by a single torpedo!

BTW, is there a way to indicate how many Klingons are left on the main display? It will help with time management.

 

Well, the original game only showed that information on the Status Report in the main computer... The fact the time clock starts at a random stardate and so you don't really know when it runs out kind of adds to the fun.

[+adamantyr]

Okay, I did a bunch of revisions to the game, enough that I'm advancing this one to 2.0 status... principally because I altered the main computer options!

 

This version features:

- Much smarter computer interface, which allows you to just specify the place you want to get to via impulse or warp, and it moves you there

- The guided torpedo option now fires torpedoes at every Klingon in the quadrant until torpedoes run out or all are destroyed!

- Made substantial changes to how time is calculated; instead of advancing time only when switching quadrants, every action increments an internal counter that eventually forces a stardate rollover. I haven't fully tested this change out, so let me know if you're still running out of time before you can get every last Klingon!

- Some new animations on Klingons firing at you

- Klingons now have torpedoes too! They don't fire often, but when they do, they pack a punch! If you are hit with shields down, you're destroyed, game over!

- I adjusted the base placement slightly; it seems like the game really is too sparse with them. (The original actually could make a game that had NO bases)

 

New Computer Command Menu Options:

1 - Status Report

2 - Mission Record

3 - Guided Course

4 - Warp Course

5 - Guided Torpedo

 

Space Trek version 2.0: SpaceTrek2.zip

[MrGonker]

I have space trek on tape made by Parco Electrics in the UK. Is this the same game?

[+adamantyr]

I have space trek on tape made by Parco Electrics in the UK. Is this the same game?

I don't think so, this game was originally published in Color Computer magazine in March of 1983.

 

It's possible that Jake Commander was influenced by a different version of Space Trek, but then again most everyone was in that era.

 

I am intrigued by the version you mention, do you have a listing, screen shots?

[MrGonker]

This is the game by Parco Electrics. Looks very similar to the screen shots of your game.

[+adamantyr]

This is the game by Parco Electrics. Looks very similar to the screen shots of your game.20141123233445.jpg20141123233541.jpg

 

Hmm... their game looks like a direct copy of TI-Trek, with some minor changes.

[+adamantyr]

FYI to all...

 

I played a complete game tonight of v2.0. Ironically, EXACTLY what Vorticon predicted could happen, happened!

 

I was in the last quadrant with the last Klingon, when the little sucker cloaked. So I ducked out of the sector and back in to force him back into visibility. I was about to fire a torpedo to end the game when the star date advanced, giving the Klingon his turn. Instead of firing disruptors, he shot a torpedo at my unshielded ship and destroyed me.

 

Some other observations:

- The new time system looks pretty good, maybe TOO good, I had over 15 stardates left out of 28 when I was destroyed at level 1. I may need to adjust some numbers slightly... I'd like to make using the main computer for guided torpedoes more expensive in time than manual aiming, for example.

- Guided torpedoes still has some bugs; it was firing torpedoes after all Klingons were destroyed. Some kind of array clean-up issue...

- Damage Control (when systems are repaired, go offline, or are upgraded) doesn't seem to trip very often, I didn't get one all game. I should up the percentage chance of that occurring...

- I need to adjust the algorithm for base placement; the original just used a 2% chance of every quadrant having a base. This can result in NO bases, and I originally just added a correction algorithm to the original code. Instead, it makes sense to place bases after Klingons and stars have been determined.

- I'm also going to adjust the maximum number of Klingons possible in a quadrant by level, I was noticing that if they get close to you, even full shields will go down fast, and with adding torpedoes, they are far more deadly than the Klingons from TI-Trek!

[Iwantgames:)]

FYI to all...

 

I played a complete game tonight of v2.0. Ironically, EXACTLY what Vorticon predicted could happen, happened!

 

I was in the last quadrant with the last Klingon, when the little sucker cloaked. So I ducked out of the sector and back in to force him back into visibility. I was about to fire a torpedo to end the game when the star date advanced, giving the Klingon his turn. Instead of firing disruptors, he shot a torpedo at my unshielded ship and destroyed me.

Haha, serves you right for allowing the klingons to get ahold of the photon torpedo technology

[+Vorticon]

This game is looking better by the minute

Since you are still doing some tweaks, perhaps you can consider the option of disabling ships instead of destroying them outright? A computer option would calculate the amount of needed energy to fire a phaser for disabling an enemy ship. The ship could then be towed to the nearest starbase and the reward may be extra time? Towing a ship will preclude warp drive, and thus comes at increased risk.

This would add an extra tactical option to the game and make it even more interesting...