Cubist writes,
sez [EMAIL PROTECTED]:
It seems to me that as the language grows it will get
progressively slower if I'm just continually adding IF-THEN
statements or adding to one large CASE statement.
Exactly how many language-tokens are you going to *need* for this thing?
Hmmm... in no particular order:
.
.
.
That's twelve different language tokens you'll need, IMAO. Can anyone else
think of any others?
Well, I could use just 12 or so language tokens as you state. Then, I
have to provide a lot more functionality to make this work, such as
ways of chaining those together with various kinds of programmatic
logic. Otherwise, I have simply created a very specific purpose
descriptive language that doesn't allow a whole lot to be automated.
You seem to have a good handle on what kinds of games I want to
implement and the difficulties involved. If I go this route, rather
than adding more commands, each command gets more and more complex as
I want to add features.
For example, DefineThing makes sense to define a game element, such
as a card. But then, I need to define details of that card, such as
suit, value, color, etc. And I need to be able to combine that card
with others to become a deck. And the deck needs to have details such
as number of cards, number of cards remaining before reshuffle,
played cards, discarded cards, etc. That is mostly meta-data. What
happens when I get to the token for DefineRule? These are so broad
that allowing implementation of auctions and scoring, as just two
examples, would both be very different rules.
It seems that a better approach as I've been discussing this is to
create a library of commands (basically scripts) that can be called
to build a script. Ideally this would be Transcript calling the
scripts rather than my parsing through a file and calling each script
myself. That allows easier transition for game developers to move
from simple implementations to more involved ones.
I suspect that each game component should also have scripts specific
to those components. For example, a deck of cards can deal to a
player's hand, play a card face up to a spot on the board, or discard
a card. There are more behaviors, but this is a few simple examples.
It seems easier to me that the deck knows how to do this rather than
have a big command that has to know how to deal with all kinds of
game components where possible.
Naah. Rev is a consideration regardless, because somebody has to do the
hard work of writing the code which implements all the commands in
the library. Rev is way-cool for that hard work.
I agree. That is why I'm asking on the Rev mailing list. ;-)
Naah. The command file is just a list of character strings which trigger
various pre-written handlers. The 10-line limit isn't a factor, becuase *you*
(the developer) are the only one who ever has to deal with *scripts*.
Basically, load a command file into a field or variable, and let
your handlers massage said file; no problem.
As I've stated, this approach works for very simple implementation of
a game where the users have to handle all of the rules. As soon as
people want to get beyond this, either I write a full-fledged
scripting language or the game developer does this in Transcript (or
Python or...). Without coding logic of some sort, the game developer
would be very limited as to what they can do. I can then focus on
adding common functionality and people designing specific games can
focus on the one-off rules.
German-type games are a *mess*, as far as conversion to a machine-friendly
form is concerned. There's far too many conditional rules and arbitrary
thises & thats.
It is pretty hard to generalize, but I have a few pages just listing
common game mechanisms and meta-data for components that games need.
This includes random number generation (dice usually, but spinners
etc. also), card handling, auctions, betting, etc. I'll pick a
starting point and go from there. I'll probably deal with simple card
games (Lost Cities) and tile-laying games (Carcassonne) first, then
proceed from there. Doing this will progressively build up a library
of functionality which will then be added to on an ongoing basis. Of
course, there are a lot of infrastructure pieces such as broadcasting
and receiving moves, matchmaking, chatting,etc. that have to
implemented as well. I will never implement every possibility, which
is why I want developers to have access to a full-featured language
if possible. When the developer wants to go beyond using simple logic
to hook these pieces together, then they would need a license for
DreamCard, etc. to go farther.
Thanks for the input and feel free to find problems with what I'm
saying here. It definitely helps me get this stuff figured out.
-Rodney
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
