Looking for suggestions/advice

[Rodney Somerstein]

Cubist writes,

>sez rodneys at io.com:
>>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