ANN: super star trek game
Krishna Myneni
I've been working on an ANS Forth port of a classic, nearly 30 year-old game,
called "Super Star Trek". It was originally written in BASIC in the late 70's by
Mike Mayfield, and subsequently enhanced by others. This game has been ported to
many different languages, but I did not find a version in Forth. A "beta"
version of my port to ANS Forth may be found on the kForth Programming Examples
Page:
http://ccreweb.org/software/kforth/kforth4.html
See the file strek.4th.
Very simple modifications need to be made to the first two lines of code to run
on a vanilla ANS Forth system. For example, see the file strek.fs in
ftp://ccreweb.org/software/gforth/
I've already spent more time on this than anticipated. At this stage, the only
way to shake out bugs is for people to try it out!
Cheeers,
Krishna Myneni
Marcel Hendrix
[..]
> Very simple modifications need to be made to the first two lines of code to run
> on a vanilla ANS Forth system. For example, see the file strek.fs in
> ftp://ccreweb.org/software/gforth/
> I've already spent more time on this than anticipated. At this stage, the only
> way to shake out bugs is for people to try it out!
| variable fdum
| : ran0 ( -- f | apply the logistic map with r=4 )
| fdum f@ fdup 1e fswap f- f* 4e f* fdup fdum f! ;
This won't work on normal Forths. Make that FVARIABLE fdum :-)
Global comment: A pity that you left the ALL UPPER CASE help
and abbreviated commands in. It may appeal to people who remember
this game from their youth, but IMHO it unnecessarily blemishes a
rather nice looking game for first timers.
Don't ask me how it plays, I have absolutely no patience for games :-)
-marcel
Krishna Myneni
>
> | variable fdum
>
> | : ran0 ( -- f | apply the logistic map with r=4 )
> | fdum f@ fdup 1e fswap f- f* 4e f* fdup fdum f! ;
>
> This won't work on normal Forths. Make that FVARIABLE fdum :-)
It *shouldn't* work on any Forth where 1 FLOAT is not equal to 1 CELL, which
includes kForth! I guess it takes a while to cause a problem... Thanks. That
certainly needs to be fixed!
>
> Global comment: A pity that you left the ALL UPPER CASE help
> and abbreviated commands in. It may appeal to people who remember
> this game from their youth, but IMHO it unnecessarily blemishes a
> rather nice looking game for first timers.
>
Actually, the help is not upper case; only the short list of command
descriptions. And, yes, I left it like that for historical reasons.
Marcel Hendrix
[..]
> It *shouldn't* work on any Forth where 1 FLOAT is not equal to 1 CELL, which
> includes kForth! I guess it takes a while to cause a problem... Thanks. That
> certainly needs to be fixed!
Meanwhile, I might have found another one:
command> com
Computer active and awaiting command (0 TO 5, OR -1) ?
Caught exception 0xc0000005
( I pressed "?" for help )
-marcel
Krishna Myneni
I guess you do have patience to play the game :)
This error is a result of the way that I coded "#in" so that it would be
portable. If a non-number is entered, it leaves the stack empty instead of
returning zero or something else. Need a portable "#in" with this behavior.
Krishna
Krishna Myneni
The random number generator has been changed out entirely. In order to use the
logistic map properly, I have to generate one bit for each iterate by comparing
whether fdum < 0.5. This is too cumbersome, and I switched to a simpler one that
is known to have fairly decent pseudo-random properties (discussed a few years
ago in c.l.f.).
Krishna
Ian Osgood
Wow, that's certainly a blast from the past! I remember playing a
similar version of this when I was a kid. A housemate had an IMSAI-8080
with MBASIC, and aside from Conway's Game of Life, this was the most
interesting thing on there.
I don't envy your task, reverse engineering line-numbered Basic. I
found some of my earliest Basic programs (including an early attempt at
my own Trek game and chess), and Boy! was it bad code! I'd probably be
a better programmer today if I'd started with something structured like
Forth or Lisp instead.
Ian
Krishna Myneni
> I don't envy your task, reverse engineering line-numbered Basic. ...
Well, it's essentially done. The game plays fairly well. There may be a few
rough spots in the code, where the output needs tweaking. Otherwise, the task is
just about finished.
I'm glad the program brought back memories. I was never much into computer
games, but I remember having played this one a few times in my younger days.
Krishna
Ed
"Krishna Myneni" <krishn...@bellsouth.net> wrote in message news:IicYg.28023$zF5....@bignews1.bellsouth.net...
>
> ...
I've been working on an ANS Forth port of a classic, nearly 30 year-old game,
> called "Super Star Trek". It was originally written in BASIC in the late 70's by
> Mike Mayfield, and subsequently enhanced by others. This game has been ported to
> many different languages, but I did not find a version in Forth. A "beta"
> version of my port to ANS Forth may be found on the kForth Programming Examples
> Page:
>
> http://ccreweb.org/software/kforth/kforth4.html
I notice that the kforth Win distribution contains no executables
and the user is required to recompile from source.
IMO, that's a big ask. Win users are unlikely to know anything
about Cygwin, or gcc, or Linux, or the specific tools and libraries
needed to do the job. When even the first step fails (running
the downloader from www.cygwin.com and crashing) then it's
clearly time to give up :)
Tester
>
>I notice that the kforth Win distribution contains no executables
>and the user is required to recompile from source.
>
>IMO, that's a big ask. Win users are unlikely to know anything
>about Cygwin, or gcc, or Linux, or the specific tools and libraries
>needed to do the job. When even the first step fails (running
>the downloader from www.cygwin.com and crashing) then it's
>clearly time to give up :)
>
Of course, compiling packages is typical in *nix and certainly anyone
involved in something as geeky as progranning in Forth would be
expected to know how to do it. This isn't true in Windows.
If you DID distribute a binary version of kforth you'd have to
distribute at least somr of the Cygwin DLL's which it uses.
IIRC when I DL'ed kforth I had CYGWIN installed but I needed one more
Cygwin package to get it to compile, readline.
--
Posted via a free Usenet account from http://www.teranews.com
Krishna Myneni
Unfortunately, installing cygwin and necessary tools [to build kForth] is not a
small task. There are very explicit instructions in the online user's manual for
kForth, listing all required packages necessary for building and patching.
There are a couple of reasons why I do not provide a binary distribution, the
main reason being that I no longer keep my (now obsolete) Windows machine up to
date with the latest anti-virus/anti-spyware patches. Therefore, I cannot
release a binary package with a high-level of confidence that it doesn't have
malware attached to it (although my lack of use of the Windows system probably
helps). The other reason is that the bundle of required .dll libraries occupy
some space, and they may cause conflicts with an already existing cygwin
installation if the versions are different. For these reasons, I avoid
distributing a binary.
Having said that, if you need a binary distribution, and have confidence in your
Windows protection software, I will be happy to send you a binary package by email.
As far as the star trek game goes, one should be able to run it under any
ANS-compatible Forth system (having fp). I took pains to make it portable.
Cheers,
Krishna
Ed Beroset
> Ian Osgood wrote:
>
>> I don't envy your task, reverse engineering line-numbered Basic. ...
>
>
> Well, it's essentially done. The game plays fairly well. There may be a
> few rough spots in the code, where the output needs tweaking. Otherwise,
> the task is just about finished.
I think I found and fixed a bug. In the KlingonsShoot routine, if the
ship is destroyed, you need to call UNLOOP before you EXIT:
s @ 0 <= IF END_SHIP_DESTROYED EndOfGame UNLOOP EXIT THEN
Otherwise, you don't know for sure where you'll end up.
> I'm glad the program brought back memories. I was never much into
> computer games, but I remember having played this one a few times in my
> younger days.
Me too. Thanks!
Ed
Albert van der Horst
It looks as if the floating point could easily be replaced
by fixed point, making it more Forthish.
Something like using doubles where the decimal point is between
cells.
There is considerable cleanup possible in the logic.
(I fully understand that you stick to logic that closely
adheres to the original game.) But now we have your
debugged version to fall back on, I think it should be
done.
There could even be a comprehensive test set because it is a text
based game. Fixed point would be an advantage because it eliminates
round off error differences between Forths it runs on.
It would benefit from some OOF thrown in.
I would think it interesting to put on source forge, and then
have a Forth OOF shoot out, where everybody tries to show off
his favorite Forth OOF and maybe other extensions.
(I found it very interesting how many different Forth ways
the bottles of beer verse can be programmed.)
Examples of logic cleanup:
------
: CheckEnergy ( -- )
s @ e @ + 10 > IF
e @ 10 > d{ 7 } f@ f0= or IF
EXIT
THEN
END_SHIP_STRANDED EndOfGame EXIT
THEN
;
-------
: CheckEnergy ( -- )
s @ e @ + 10 >
e @ 10 > d{ 7 } f@ f0= or
AND IF
END_SHIP_STRANDED EndOfGame
THEN
;
-----
=============================================
-----
THEN
GameEnded? IF EXIT
ELSE CheckEnergy GameEnded? IF EXIT THEN
THEN
AGAIN
------
THEN
GameEnded? 0= IF CheckEnergy THEN
GameEnded? UNTIL
------
Are there any players out there who would be willing
to spend some evenings with a logging version, and
collect a couple of megabytes of test data?
>
>Cheeers,
>Krishna Myneni
>
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Krishna Myneni
> ... I think I found and fixed a bug. In the KlingonsShoot routine, if the
> ship is destroyed, you need to call UNLOOP before you EXIT:
>
> s @ 0 <= IF END_SHIP_DESTROYED EndOfGame UNLOOP EXIT THEN
>
> Otherwise, you don't know for sure where you'll end up.
> ...
Thanks Ed! I'll update my posted version with your bug fix.
Krishna
Krishna Myneni
>
> It looks as if the floating point could easily be replaced
> by fixed point, making it more Forthish.
> Something like using doubles where the decimal point is between
> cells.
>
I was thinking the same thing, but also the effort required to do this appears
to be substantial. If some one has the patience, this will be a good thing to
do, and will allow the game to run on more systems.
> There is considerable cleanup possible in the logic.
> (I fully understand that you stick to logic that closely
> adheres to the original game.) But now we have your
> debugged version to fall back on, I think it should be
> done.
Agree.
> ...
Good examples. I'm sure the code could use further scrubbing. And OOF is
well-suited for an application like this.
I've added some new logic to the game to prevent shields from being activated
while docked at the starbase. Another I want to implement is that if the ship
fires a photon torpedo into the starbase (accidentally or on purpose) while it
is docked, it should be destroyed as well!
Krishna
Doug Hoffman
Krishna Myneni wrote:
[snip]
> Good examples. I'm sure the code could use further scrubbing. And OOF is
> well-suited for an application like this.
After taking a quick glance I think most of it seems fine without. But
the klingon ships handling seems better done as an array of ship
objects. Perhaps there's more that could be done. Anyway, I threw in
one way to do the ships as objects. Not a very difficult object
programming task. But I think the klingon ship handling is clearer
this way.
See files at:
http://members.talkamerica.net/douglas...@talkamerica.net/
You will need my revised object extensions:
CLASS12A or CLASS12A.zip (CLASS12AMF or CLASS12AMF.zip for Macintosh)
The revised file is STREKDBH1.F or STREKDBH1.F.zip
Doug Hoffman
Krishna Myneni
> ... Examples of logic cleanup:
>
> ------
> : CheckEnergy ( -- )
> s @ e @ + 10 > IF
> e @ 10 > d{ 7 } f@ f0= or IF
> EXIT
> THEN
> END_SHIP_STRANDED EndOfGame EXIT
> THEN
> ;
> -------
> : CheckEnergy ( -- )
> s @ e @ + 10 >
> e @ 10 > d{ 7 } f@ f0= or
> AND IF
> END_SHIP_STRANDED EndOfGame
> THEN
> ;
> -----
Albert,
After another look, it turns out that both my original version and yours for
CheckEnergy do not have the correct logic. Going back to the original BASIC
code, I believe the proper logic (which also makes sense) is
: CheckEnergy ( -- )
s @ e @ + 10 <= \ Total energy <= 10 ?
e @ 10 <= d{ 7 } f@ f0< and \ Energy <= 10 and shields damaged?
or
IF END_SHIP_STRANDED EndOfGame THEN
;
I've updated the code with this and your other cleanup suggestion, as well as
Ed's fix for KlingonsShoot, and a couple of other minor enhancements, including
a fix for non-numeric handling for "#in".
If you want to place this on sourceforge for community development, it's fine
with me.
Cheers,
Krishna
Krishna Myneni
Hi Doug,
I was wondering why you didn't make "move" and "shoot" methods of the
KlingonShip class.
Krishna
--
From STREKDBH1.F:
------------------
:class KlingonShip \ 10/22/06 dbh
var x \ location
var y
var power
:m !loc: ( x y -- ) put: y put: x ;m
:m @loc: ( -- x y ) get: x get: y ;m
:m .loc: get: x . ." ," get: y . ;m
:m !power: ( p -- ) put: power ;m
:m @power: ( -- p ) get: power ;m
:m +power: ( dP -- ) +: power ;m
:m print: .loc: self space @power: self . ;m
;class
Doug Hoffman
Krishna Myneni wrote:
> I was wondering why you didn't make "move" and "shoot" methods of the
> KlingonShip class.
I didn't take the time to analyze the entire program. All I did was
replace any uses of the matrix "k{{ i j }}..." with a message to
object. One could likely go further and add the methods you suggest.
Once all of the behaviors and data of the klingon ships are represented
as objects it might then be easy to make subclass ship objects such as
Romulan ships that respond somewhat differently to the same messages.
Doug Hoffman
Albert van der Horst
Krishna Myneni <krishn...@bellsouth.net> wrote:
>
I downloaded it, and tried it on gForth.
In my experience it is virtually unplayable, because with each typing
error you are thrown out of the game.
Seriously. I don't think you can do
( -- n )
: #in $input EVALUATE ;
in a game.
Games require due attention to the user interface, or
nobody will want to play it. (Normally computer application are
forced upon you, but games in general are not.)
See also games.html on my site below, for more classical games
salvaged.
winston...@yahoo.com
Albert van der Horst wrote:
Very reminiscent of a version of Super Star Trek for UCSD Pascal I came
across. It relied on read(numvar), and if you accidentally hit a
non-numeric - whamo! Game blows up, and you have to start all over.
I was really surprised that they didn't input into a string so they
could check for non-numeric or at least turn off error checking and
check IORESULT after the reads...
I still am interested in this program. I remember starting to translate
the TI-99 version of Super Star Trek to UCSD Pascal - graphic oriented,
using sprites and sound effects. Such a version for TI Forth would be
nice.
Krishna Myneni
> ... I downloaded it, and tried it on gForth.
> In my experience it is virtually unplayable, because with each typing
> error you are thrown out of the game.
>
> Seriously. I don't think you can do
> ( -- n )
> : #in $input EVALUATE ;
> in a game.
>
> Games require due attention to the user interface, or
> nobody will want to play it. (Normally computer application are
> forced upon you, but games in general are not.)
>
Feel free to provide code improvements. That's why I posted the code in the
first place.
Apparently you didn't read my other post, in which I announced a fix for this
problem. You are using an earlier version (from a couple of days ago). The
modified "#in", in the current version is
: #in ( -- n | positive integer or -1 )
$input over c@ [char] 0 [char] : within IF
evaluate ELSE -1 THEN ;
Krishna