Looking for suggestions/advice

[Rodney Somerstein]

Thanks to everyone for the suggestions so far. Robert's suggestion 
about requiring anyone who wants to create game modules to purchase a 
Dreamcard license won't work. This is an open source/free project I'm 
embarking on. Using Revolution makes the open source aspects less so 
as fewer people will have access to the source since it requires a 
commercial tool. However, I'm willing to live with that if I can work 
around the other limitations. Requiring people to have a copy of 
Dreamcard to write a game AI is probably feasible as few people will 
likely do that anyway.

Xavier's suggestion to write an interpreter is pretty much what I 
expect would be required if I do the project in Revolution. Yes, a 
highly structured language where each command consists of a verb 
followed by arguments doesn't seem that tough to write. Two issues 
with this for me, though. First of all, I know there are such things 
as grammatical parsers that make this kind of work easier. Though I 
have no idea of the methodologies involved in creating/using such a 
thing. This is a little bit of a barrier for me. Simply using a 
series of if-then-else statements to parse a command file will likely 
be slow and I need to find a better way if I go this route. It seems 
that XML might be viable as Rev has built in functionality for this 
and I am already familiar with XML. Being able to use a DTD or schema 
to validate a command file would greatly simplify my work by 
eliminating the need for me to write the code to do so. The problem 
with this approach is that it is limited to what features I can 
support in the language/XML application. I expect I would never write 
a language capable of creating a game AI and would have to fall back 
on people creating such in Transcript, requiring them to at least 
license Dreamcard.

Now on to Alex's reply

>btw - I don't know what you mean by European-style modern games. 
>I've previously thought about some of these issues specifically for 
>card games (see RevOnline under user alextweedly for TriPeaks - this 
>includes a PlayingCard library which you are welcome to use or take 
>bits from as you wish). I've also done, but not yet posted, a 
>Cribbage game - and it's definitely in the future plans to extend 
>the number of games handled, and to make them networked so multiple 
>people can play against each other and/or user-written stacks and/or 
>the built-in rather basic game play). [ but I haven't resolved the 
>questions I raise below about allocation of intelligence and game 
>knowledge between the server and client - so that's on hold for now ]

I will definitely take a look at your PlayingCard library. I suspect 
it would save me a lot of work in implementing this kind of thing 
myself. What I mean by "European-style modern games" is a kind of 
game that is called by many names. They are also known as German 
games, designer games, and family strategy games. They tend to be 
about 2 hours or less in length, focus on non-war based strategy, 
have a theme of some sort, and use custom playing components. They 
can be card games, board games, a combination of the two, or other 
things such as dice based games. They are not the stereotypical 
American roll the dice and move the marker around a track kind of 
game. There is a strong and growing group of hobbyists who play these 
kinds of games in Europe (primarily Germany), the US, and throughout 
the rest of the world. In Germany, the premier annual game show in 
Essen draws well over 100,000 people to attend.

>>I know that Revolution can easily handle the multi-player aspects 
>>via communication with a central server that broadcasts the 
>>information to everyone involved in the game. I'm not sure if this 
>>server should be written in Rev or something else such as PHP.
>
>I'd do it in Rev - and probably use socket communication rather than 
>http. That will make it easier to handle the asynchronous nature of 
>some games.

When I brought this up previously, someone suggested that I use a 
central server for communication rather than peer to peer. Using 
something such as PHP would save me a lot of implementation work. I 
don't really need the server to maintain the game state in such a 
case, the clients can do it. The server would be primarily to allow 
people to connect and then broadcast the game information. Each 
client would need to have a copy of the game module for the game 
being played. Obviously there are a lot of design considerations that 
need to be thought through regardless of whether I use an existing 
server technology (I'm definitely looking for suggestions) or roll my 
own. I don't know that using sockets for communication necessarily 
means creating my own server.

>A large design decision is whether to make the server generic, or 
>make it be scriptable for each game. Indeed, you could go to the 
>other extreme and make *only* the server be scripted, and use a 
>general purpose client. In that design, the client has no knowledge 
>of the game being played - it simply receives commands from the 
>server
>  - here a list of named positions, and co-ords
>  - put these pieces at these co-ords (visible or not)
>  - enable these positions for user input
>  - etc.

This is an approach that I haven't considered before and I'll have to 
think about it. With a system such as you are creating using generic 
playing cards, this is easier. With the system I'm thinking about, 
there is a large amount of custom graphics and such required for each 
game. A purely generic client might not work because of this. But it 
might be possible. Again, I'll have to think about it a little bit.

>I also decided that I would have no reliance on information hiding 
>in the client - if a card is "face down" for a client, the server 
>does not say
>  - 3 of spades, face down on the heap
>it simply says
>  - a card face down on the heap
>
>This prevents anyone from writing (or modifying) their client to 
>give them an advantage.
>
>Note this means the server does not broadcast info on what is 
>happening - it must either customize the info for each client
>  - deal 3 spades to player A    [to player A]
>  - deal a card to player A   [ to players B, C, D]
>or use an encoding scheme to limit information visibility. (I'm 
>going to do the latter, to simplify the server).

I'm not too concerned about people cheating in this way. People doing 
so would quickly get a bad reputation and would likely be shunned by 
others. I will try to build in at least some simple safeguards. Given 
how much more complex these games can possibly be than standard card 
games, I'm not sure that having the server handle everything is the 
best way to go. This is especially the case since I don't want to 
have to modify the server to handle each game. Also, it would be nice 
if when an AI is added to a game, people could play it standalone, 
such as on an airplane, without an Internet connection. Requiring the 
server to handle all playing logic would eliminate this possibility.

>>I know that Revolution can make the graphical aspects of the 
>>program much easier than more traditional languages. I'm still not 
>>sure about being able to easily zoom in and out (scaling) the view 
>>of the game board, but I suspect it can be handled dynamically in 
>>Rev as well.
>>
>No reason why it shouldn't be.

I agree it should be possible to do. I don't think I've seen any 
examples of this in Rev, though. It is very common in computer games, 
especially strategy games. I would ideally like the user to be able 
to use the scroll wheel on a mouse, for example, to zoom in and out 
on the playing area within their client.

>Again, I'm not sure about the kinds of games you want to allow. But 
>for card games, it is not at all trivial to codify the rules and 
>actions needed for a game. If you have a narrow range of games 
>(analogous to "only whist family" or "only rummy games") then I 
>think it would be feasible (and easier for your users to add a 
>plug-in) with a task-specific language. But if you want to handle a 
>wider range (e.g. points scoring in Cribbage) then I think you'd 
>want a general purpose language such as Transcript.
>
>And given that anyone writing such a game is going to put in tens or 
>hundreds of hours doing so, I'd suggest that they should accept the 
>cost of a DC license. This will also give them an IDE and debugging 
>environment, which is likely to be valuable, if not necessary, for 
>any real game. For you to provide an IDE/debug environment for a 
>task-specific language would be difficult.

I agree that codifying rules and actions for games is far from 
trivial. I have spent several years thinking about the various kinds 
of rules and actions needed for such a system. I need everything from 
moving pieces, dealing cards, rolling dice, to controlling areas of a 
board and scoring. Handling the variety of standard card games seems 
much easier to me than what I am proposing. Being able to handle 
traditional card games is actually a subset of what I want to do.

Having a general purpose scripting language would make all of this 
much easier. There will inevitably be concepts that I miss or won't 
have implemented yet. If someone else could relatively easily do 
this, it makes things much simpler and much more flexible.

>>I would like to allow the games to have computer players as well as 
>>human. That ratchets up the requirements for a scripting language 
>>even more. Is this something that Revolution is well suited to? Or 
>>should I really be looking at other languages such as Java? I could 
>>let users script things via Python or Ruby if I used Java. I know 
>>the downsides of developing in a language such as Java rather than 
>>Revolution. I just have this nagging feeling that it may actually 
>>make for a better cross-platform development system than Rev for 
>>what I want to do. I'd be happy to be disabused of this notion.
>>
>I'd design the client-server protocol carefully to be language-neutral.
>And the people can code up "players" in any language they like - and 
>indeed you'll be free to make this decision for yourself independent 
>of what you decided for the server and/or GUI client.
>
>Personally, I'd only consider dynamic languages - Transcript, Python 
>maybe Ruby. I don't see advantages for this purpose for Java or C# 
>or others.
>
>If the idea of requiring a DC license would be a big problem, then 
>I'd consider doing the server (including the rules-interpreter) in 
>Python, and the client / GUI in Rev. But I think some people who 
>could readily learn enough Transcript to write a plug-in will find 
>it harder or impossible to use Python - so that might cut down on 
>your plug-in developer base.

As you've probably seen from my discussion above, I much prefer not 
to require a Dreamcard license. For the average person, they wouldn't 
even consider creating an AI player or players for a game. They 
shouldn't need to know much programming at all. I would provide 
commands for standard functionality such as rolling dice, dealing 
cards, etc. Designers would have to specify how many dice, how many 
sides the dice have, what image files their cards are in, how many 
cards per deck, how many to deal, whether dealt cards are public or 
private knowledge, etc. I saw someone else start designing such a 
system once in Visual Basic. They had a very simple language that 
allowed users to build a surprising variety of games. It was up to 
the players to handle most of the rules during the game. 
Unfortunately, this person disappeared and no one has been able to 
track him down. Something like this would be the early releases of my 
system.

The average game designer would not need to learn 
Transcript/Python/Ruby. Only people wishing to extend the game 
language or write a player AI would need to do so. If I use Java, it 
would have embedded Python or Ruby interpreters (Jython or the Ruby 
equivalent) in all likelihood. I'm more familiar with Python but have 
started reading about Ruby recently. Even something like Lua could 
work, but why not have the flexibility of the other two more powerful 
languages that I mentioned? I see a need for a language such as Java 
or an environment like Rev as the base for the client program because 
it allows creation of cross-platform UIs. While it is possible to do 
this with both Python and Ruby, neither have standard UI systems in 
the language. Simply creating a standalone application in either of 
those languages requires somewhat cumbersome installation procedures 
at this time. (Though how cumbersome this is depends on the 
individual deployment platform.) For this to work, it has to be very 
simple for me to supply an installer for at least Windows and Mac OS 
X. Supporting Linux as well makes sense to me. Hmmm... maybe someone 
should create an environment or language to facilitate this? ;-)

I'm more interested in creating a system to make it easy for creating 
such games rather than a generic server system for people to use when 
writing game programs. So it isn't a problem making the server a 
little more specific to what I'm doing. I will try to have the server 
protocols be language neutral just to provide flexibility in being 
able to replace the server with something better in the future with a 
minimum of effort.

Thanks for the input from everyone and I look forward to seeing more 
discussion from anyone interested in contributing ideas. If this 
moves very far away from how to do this in Rev, then I'll remove the 
discussion from the list. I'm really hoping that I will be convinced 
by people that what I want to do can be accomplished fairly easily in 
Revolution.

-Rodney