Hi everyone. I'm developing a strategy game in LISP. For purposes
of disucssion just think of it as a very simple version of chess.
I want to somehow seperate the game/strategy core engine from the
event handler front-end and the graphical backend.
I want to later be able to switch from a command line
ascii event input, to a text file replay file, or a Tk
graphical input, or a web interface input.
I realize this is partially a problem/question of software
programming approach, but if there is some concept in
LISP which makes it much easier i'd love to take advantage
of it of course.
For the output i want to be able to first display simple
ascii output to stdout, but later possibly implement it
in Tk, or openGL, or some sort of java display.
does anyone have any advice about how to approach this so
i do not really wish later that i had done things very
differently?
I'd be very happy to discuss more details with anyone interested
either on this newsgroup or private.
Jim Newton wrote:
> Hi everyone. I'm developing a strategy game in LISP. For purposes
> of disucssion just think of it as a very simple version of chess.
>
> I want to somehow seperate the game/strategy core engine from the
> event handler front-end and the graphical backend.
>
> I want to later be able to switch from a command line
> ascii event input, to a text file replay file, or a Tk
> graphical input, or a web interface input.
>
> I realize this is partially a problem/question of software
> programming approach, but if there is some concept in
> LISP which makes it much easier i'd love to take advantage
> of it of course.
I think mostly this is not a Lisp issue. As you probably know, the
strategy bits of the game should not know anything about the input
foramt or presentation method. Then whatever user interface you come up
with just feeds the strategic engine and does what it wants with the
output it gets back.
You /might/ want to get fancy with a generic function which takes two
parameters, one the object to be presented and the other an object
representing the output. You /might/ get some reuse out of presentation
code which does not care about the output type, such as one which
iterates over a sequence recursively calling the output function on each
element.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Jim Newton wrote:
> > Hi everyone. I'm developing a strategy game in LISP. For purposes
> > of disucssion just think of it as a very simple version of chess.
> > I want to somehow seperate the game/strategy core engine from the
> > event handler front-end and the graphical backend.
> > I want to later be able to switch from a command line
> > ascii event input, to a text file replay file, or a Tk
> > graphical input, or a web interface input.
> > I realize this is partially a problem/question of software
> > programming approach, but if there is some concept in
> > LISP which makes it much easier i'd love to take advantage
> > of it of course.
>
> I think mostly this is not a Lisp issue. As you probably know, the
> strategy bits of the game should not know anything about the input
> foramt or presentation method. Then whatever user interface you come
> up with just feeds the strategic engine and does what it wants with
> the output it gets back.
>
> You /might/ want to get fancy with a generic function which takes two
> parameters, one the object to be presented and the other an object
> representing the output. You /might/ get some reuse out of
> presentation code which does not care about the output type, such as
> one which iterates over a sequence recursively calling the output
> function on each element.
I think the problem is more complex at the level of the control
flow. Even for a game such as chess, where a-priori the user interacts
only when it's his turn, you may want to provide a user interface
where the user can command the program even when it's "thinking", for
example, to see what the program is "thinking", or to save the game
for later, or to force it to play its best move found up to now, etc,
and even worse for other more real-time games.
So either you have to structure your "thinking" algorithms so as to
process small chunks and return to the caller to give it the
opportunity to process user input or you have to use threads or at
least coroutines, all of which does not exist in Common-Lisp and can't
be implemented easily over Common-Lisp. (You have to rely on the
extensions of a given implementation). That's the same problem with
the inversion of control for web applications discussed in other
threads. (We really need threads or continuations be put in the standard).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Jim Newton wrote:
>>
>>>Hi everyone. I'm developing a strategy game in LISP. For purposes
>>>of disucssion just think of it as a very simple version of chess.
>>>I want to somehow seperate the game/strategy core engine from the
>>>event handler front-end and the graphical backend.
>>>I want to later be able to switch from a command line
>>>ascii event input, to a text file replay file, or a Tk
>>>graphical input, or a web interface input.
>>>I realize this is partially a problem/question of software
>>>programming approach, but if there is some concept in
>>>LISP which makes it much easier i'd love to take advantage
>>>of it of course.
>>
>>I think mostly this is not a Lisp issue. As you probably know, the
>>strategy bits of the game should not know anything about the input
>>foramt or presentation method. Then whatever user interface you come
>>up with just feeds the strategic engine and does what it wants with
>>the output it gets back.
>>
>>You /might/ want to get fancy with a generic function which takes two
>>parameters, one the object to be presented and the other an object
>>representing the output. You /might/ get some reuse out of
>>presentation code which does not care about the output type, such as
>>one which iterates over a sequence recursively calling the output
>>function on each element.
>
>
> I think the problem is more complex at the level of the control
> flow. Even for a game such as chess, where a-priori the user interacts
> only when it's his turn, you may want to provide a user interface
> where the user can command the program even when it's "thinking",..
Good idea. So far the only spec is to handle different UIs, but your
ideas might reasonably also end up as RFEs. It occurs to me the best
guidance seems not to be necessary: use Lisp, it makes refactoring easy.
Just dive in (keeping model and view distinct, of course).
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
yes it would be great if the computer could recognize when
we are waiting for the user input, and spend that time by
thinking. it could predict the most probably input from
the user and begin condidering the propery response.
If indeed the user makes the predicted choice, it will
already be finished calculating the response or
well underway of calculation and we want to continue
the calculation.
Pascal Bourguignon wrote:
>
>
> I think the problem is more complex at the level of the control
> flow. Even for a game such as chess, where a-priori the user interacts
> only when it's his turn, you may want to provide a user interface
> where the user can command the program even when it's "thinking", for
> example, to see what the program is "thinking", or to save the game
> for later, or to force it to play its best move found up to now, etc,
> and even worse for other more real-time games.
>
> So either you have to structure your "thinking" algorithms so as to
> process small chunks and return to the caller to give it the
> opportunity to process user input or you have to use threads or at
> least coroutines, all of which does not exist in Common-Lisp and can't
> be implemented easily over Common-Lisp. (You have to rely on the
> extensions of a given implementation). That's the same problem with
> the inversion of control for web applications discussed in other
> threads. (We really need threads or continuations be put in the standard).
>
Hi Jim,
> I want to somehow seperate the game/strategy core engine from the
> event handler front-end and the graphical backend.
>
> I want to later be able to switch from a command line
> ascii event input, to a text file replay file, or a Tk
> graphical input, or a web interface input.
CLIM was designed with this in mind.
Simply put, CLIM generalizes Lisp's textual read-eval-print loop to a
read-command evaluate-command present-result loop. Commands can be
read from a character-based input-stream but can also be "read" by
"parsing" events. The same principle goes for presenting results: you
can present a result by printing strings to a standard output-stream,
but you can also present results in a graphical way.
These different interaction models can co-exist: it's not unusual for
a CLIM program to have both a command-line interface and a
point-and-click interface. For your game, you could start with a
simple command-line interface to keep things simple. At a later
stage, you could add a graphical interface.
This is only the tip of the iceberg. There are many interesting
concepts in CLIM that are worth looking at. Most CL implementations
can be used with CLIM: there's McClim for the open source Lisps, but
Allegro CL, Lispworks and (I believe) MCL also have CLIM
implementations.
Arthur
Arthur Lemmens <········@xs4all.nl> writes:
> concepts in CLIM that are worth looking at. Most CL implementations
> can be used with CLIM: there's McClim for the open source Lisps, but
> Allegro CL, Lispworks and (I believe) MCL also have CLIM
> implementations.
Yes, MCL does have a CLIM implementation.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface