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
_______________________________________________
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
