If you are interested in programming abstract strategy games, puzzles, and a variety of other related applications (or you are just interested in novel Forth applications), you might be interested in "Axiom". Axiom is a universal game development system that works in conjunction with the "Zillions Of Games" (tm) product. It is in the form of a plug-in DLL engine for Zillions. Axiom has its own complete Forth based scripting language as opposed to the built-in Lisp like language included in the Zillions product. Axiom provides its own search engine, allows the game AI to be customized, supports math, and in general, allows a high degree of customized programming. Due to the full power of Forth being available for game programming, Axiom extends the range of games possible with the Zillions product.
You can find the Axiom development kit (which includes documentation) along with several Axiom based games at:
The Zillions of Games (tm) product is a commercial product, however you can download the development kit and the Forth based Axiom games for free. You need to purchase the Zillions product in order to play these and Zillions games, however if your interest is limited to examining the game programming, then you can look at the included *. 4th files.
Due to the fact it is Forth based, it may not be for everyone. In the yahoo group, there has been some backlash to using Forth (e.g. "Why didn't you use Java?). However, my personal experience has been that Forth is an excellent language for this purpose.
I am not affiliated with the Zillions product in any way. I'm a Forth enthusiast and Axiom has been a hobby project which I am offering to the public for free. I've been working on Axiom and the current set of Axiom based games for the past 1-1/2 years in my 'spare' time.
> If you are interested in programming abstract strategy games, puzzles, > and a variety of other related applications (or you are just > interested in novel Forth applications), you might be interested in > "Axiom". Axiom is a universal game development system that works in > conjunction with the "Zillions Of Games" (tm) product. It is in the > form of a plug-in DLL engine for Zillions. Axiom has its own complete > Forth based scripting language as opposed to the built-in Lisp like > language included in the Zillions product. Axiom provides its own > search engine, allows the game AI to be customized, supports math, and > in general, allows a high degree of customized programming. Due to > the full power of Forth being available for game programming, Axiom > extends the range of games possible with the Zillions product.
> You can find the Axiom development kit (which includes documentation) > along with several Axiom based games at:
> The Zillions of Games (tm) product is a commercial product, however > you can download the development kit and the Forth based Axiom games > for free. You need to purchase the Zillions product in order to play > these and Zillions games, however if your interest is limited to > examining the game programming, then you can look at the included *. > 4th files.
> Due to the fact it is Forth based, it may not be for everyone. In the > yahoo group, there has been some backlash to using Forth (e.g. "Why > didn't you use Java?). However, my personal experience has been that > Forth is an excellent language for this purpose.
> I am not affiliated with the Zillions product in any way. I'm a Forth > enthusiast and Axiom has been a hobby project which I am offering to > the public for free. I've been working on Axiom and the current set > of Axiom based games for the past 1-1/2 years in my 'spare' time.
> Thank you for your interest.
> -- Greg Schmidt
Outstanding work Greg! Forth will certainly benefit from your project.
dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System [..]
> I am not affiliated with the Zillions product in any way. I'm a Forth > enthusiast and Axiom has been a hobby project which I am offering to > the public for free. I've been working on Axiom and the current set > of Axiom based games for the past 1-1/2 years in my 'spare' time. > Thank you for your interest.
Great idea! You paid attention to doumentation too, and your Forth seems to really deserve that name (being interactive). Do you care to discuss why it has <BUILDS, and why there's a unified stack?
BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't even know when the game is over (I took its king after only 3 moves, but it pretends not to notice).
It does know how to play tic-tac-toe, though (unfortunately, I do too).
On Aug 27, 1:00 pm, m...@iae.nl (Marcel Hendrix) wrote:
> dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System > [..]
> > I am not affiliated with the Zillions product in any way. I'm a Forth > > enthusiast and Axiom has been a hobby project which I am offering to > > the public for free. I've been working on Axiom and the current set > > of Axiom based games for the past 1-1/2 years in my 'spare' time. > > Thank you for your interest.
> Great idea! You paid attention to doumentation too, and your Forth seems > to really deserve that name (being interactive). Do you care to discuss > why it has <BUILDS, and why there's a unified stack?
ForthScript is subroutine threaded and implemented in C++. I couldn't see any way to implement CREATE ... DOES> without dropping into assembly which I didn't want to do.
Andrew Haley wrote: > and the thunk is a magic bit of machine code, usually a single > instruction, that is placed in the threaded code immediately before > the DOES> action. This works with any kind of threading.
As far as a unified stack, I'm not sure what you mean. ForthScript has both a data stack and a return stack. It supports words such as (>R, R>, R, R@ etc.). Was there something you found in the documentation that lead you to believe there was a single stack?
Please let me know if I'm missing something on either one of these points.
> BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't > even know when the game is over (I took its king after only 3 moves, but it > pretends not to notice).
Hmm... It's Chess is pretty strong, especially considering it's a general game playing program. If you are able to make this happen again, please save the game (in a *.zsg file) and send it to me. I can then post it and have the Chess Guru's examine it.
> It does know how to play tic-tac-toe, though (unfortunately, I do too).
> -marcel
Thank you for your comments and thanks to everyone for the kudos.
dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
> As far as a unified stack, I'm not sure what you mean. ForthScript > has both a data stack and a return stack.
[..]
But floating-point numbers are on the data stack, as 32-bit numbers. IMHO, these are very unfortunate design decisions.
>> BTW, strange game player, Zillion :-) I tried it's chess, but it doesn't >> even know when the game is over (I took its king after only 3 moves, but it >> pretends not to notice). > Hmm... It's Chess is pretty strong, especially considering it's a general game playing > program. If you are able to make this happen again, please save the game (in a *.zsg file) > and send it to me. I can then post it and have the Chess Guru's examine it.
I only tried the Demo version and didn't realize the best it can do is play 'Loser Chess'. Apparently the rules are quite different. Probably a great idea in the context of a demo for an extensible system.
On Aug 27, 11:41 pm, m...@iae.nl (Marcel Hendrix) wrote:
> But floating-point numbers are on the data stack, as 32-bit numbers. > IMHO, these are very unfortunate design decisions.
Pardon my ignorance on this, but besides less stack juggling, what do you see as the main advantages of having a separate floating point stack? So far, in my limited applications to game programming, I haven't run into difficulties, but then I don't typically perfrom extensive mixed mode calculations.
> I only tried the Demo version and didn't realize the best it can do is play > 'Loser Chess'. Apparently the rules are quite different. Probably a great > idea in the context of a demo for an extensible system.
Right, I forgot that the demo is 'Loser Chess'. I agree with your rationale, although some objected to putting a 'Loser' game in the demo.
dreamwa...@yahoo.com wrote: > On Aug 27, 1:00 pm, m...@iae.nl (Marcel Hendrix) wrote: >> dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System >> [..]
>> > I am not affiliated with the Zillions product in any way. I'm a Forth >> > enthusiast and Axiom has been a hobby project which I am offering to >> > the public for free. I've been working on Axiom and the current set >> > of Axiom based games for the past 1-1/2 years in my 'spare' time. >> > Thank you for your interest.
>> Great idea! You paid attention to doumentation too, and your Forth seems >> to really deserve that name (being interactive). Do you care to discuss >> why it has <BUILDS, and why there's a unified stack? > ForthScript is subroutine threaded and implemented in C++. I > couldn't see any way to implement CREATE ... DOES> without dropping > into assembly which I didn't want to do.
Other people have done it. It's far from being impossible. I don't know enough about exactly how your threading scheme works to comment on how exactly to do it in your system.
> This was discussed in the following thread: > http://groups.google.com/group/comp.lang.forth/browse_thread/thread/4... > The gist of it is: > Andrew Haley wrote: >> and the thunk is a magic bit of machine code, usually a single >> instruction, that is placed in the threaded code immediately before >> the DOES> action. This works with any kind of threading. > As far as a unified stack, I'm not sure what you mean.
Your question was re "history and rationale for CREATE vs. <BUILDS" and had nothing at all to do with unified stacks.
On Aug 28, 11:29 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote:
[On supporting CREATE .. DOES>]
> Other people have done it. It's far from being impossible. I don't > know enough about exactly how your threading scheme works to comment > on how exactly to do it in your system.
dreamwa...@yahoo.com wrote: > On Aug 28, 11:29 am, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: > [On supporting CREATE .. DOES>] >> Other people have done it. It's far from being impossible. I don't >> know enough about exactly how your threading scheme works to comment >> on how exactly to do it in your system. > For details on ForthScript's threading, see section 5 "Internals > within "ForthScript.pdf" that is part of the Axiom development kit at: > http://www.zillionsofgames.com/cgi-bin/zilligames/submissions.cgi/161...
OK, that all looks pretty conventional. To implement CREATE .. DOES>, your DOES> should modify the CFA of the most recently created word. As as example, consider something like
: const create , does> @ ;
DOES> makes the CFA of the most recently created word point into the middle of the list of CFAs inside CONST, and then DOES> exits from CONST.
The list of CFAs in CONST looks like this, with "&" meaning the CFA of the following word:
& CREATE & , & DOES> & (DODOES) & @ & , & EXIT
So, when you do
CONST FOO
you create a new word whose CFA points to the address of (DODOES) within the body of CONST. The action of (DODOES) is somewhat system dependent, but it needs to get the address of the parameter field of the current definition.
dreamwa...@yahoo.com writes Re: Announcement: Axiom, a Forth Based Universal Game Programming System
> On Aug 27, 11:41 pm, m...@iae.nl (Marcel Hendrix) wrote: >> But floating-point numbers are on the data stack, as 32-bit numbers. >> IMHO, these are very unfortunate design decisions. > Pardon my ignorance on this, but besides less stack juggling, what do > you see as the main advantages of having a separate floating point > stack?
Is less stack juggling not compelling enough?
Source code clarity: with a unified stack, you are never completely sure that there is not a float involved somewhere, whereas with a separate stack you simply write : x ( adam bertha -- xantippe ) ( F: r -- cos{r} ) ... ;
Then there is efficiency: a separate stack works much faster when you use the hardware FPU or SSE2 unit. Most fast Forths use a separate FP stack, so your code can never be directly used on/ported to/checked through them.
With a separate FP stack you switch to double or quad precision without rewriting any code. (Say you want your Fractal generator upgraded to 256 bits with Julian Noble's ideas.)
