Should I write a parser?

Hey there, here's my dilemma: i have to write a small, web based, multi player game. The technology is not yet decided but it will either be (php+some c++ daemons) or (java).
What is special about this game is that will have to run a lot of programmed tasks. For example, at the hour 14pm it will have to:
- grant all players 10gold
- move them 1 square to the left
- bla bla
These tasks have to be highly customizable, so I'm having some trouble trying to find a suitable storage method for them.

I then thought that writing a language + interpretor/parser for it it will solve a lot of problems and it will offer considerable advantages not only for programmed tasks but also for gamemaster usage etc, player defined triggers and maps etc.

But a parser is a big task and will drive me deep into Automata theory. I want to ask you if it's worth it. I would be willing to make the efforts if it will help me in the future (lets say... for bigger games).

How about the quick method? Have you cammed across this problem? How have you solved it?

I'm eager to hear your opinions.

You say "These tasks have to be highly customizable", I do not think you'd be able to find a premade system designed to store this type of info, if it were up to me I'd write a small parser, it doesn't have to be very large, you can make it accept x amount of different types (of actions) or an unlimited amount, but then the user has to create a schema for it, or something along those lines. The easiest way would be to just do a simple one at first and see where it gets you.

I dissagree with Viper. PHP and C++ are very versatile languages. I'm sure you can accomplish what you need with them.

I started wring a compiler, which, of course, includes a parser, 3 years ago!! I still have 2 years to go (in my estimate). Now, I'm not as smart as most people, but never the less, it's an involved task. I wouldn't recommend it unless there's an absolute need for it.

I never said they weren't versatile languages, where did I even mention the language type?

I am just going to make some assumptions here, so if I am wrong let me know. Since it is an online game, it will be using some kind of database. If this is true, then no matter what language the server is written in, you will be able to modify the database. This assumes the server is using apahce; I would would write a php script and attach it to a cronjob for each of the tasks you described. When the database gets updated, no matter what language the client is written in, will also be updated, if you design that way.

EDIT: I just noticed the date of the original posting. Chances are, this issue is long dead. Oh, well.

It should be pointed out that there are any number of parser generators for both Java and C++, and the parsers they generate are likely to be more efficient than a hand-rolled one for any but an expert on the subject.

Or you could use an embeddable scripting language like Lua, Guile or Jython and not have to worry about writing the interpreter yourself. While I personally like Guile (or rather, Scheme, which is the language Guile is based on), I expect that Lua would be the best choice, since it is already widely used for game scripting. The main advantages of Jython are that a) a lot of programmers already know Python, and b) it can (IIUC) run inside a Java applet on the client side, whereas the other two would be server-side only.

However, this whole issue doesn't really address some important questions. You may wish to have a scripting language for the game (that's a really good idea, in fact), but you still need to provide the primitive game elements which the scripts perform. Scripting means that you don't have to build as much into the game engine itself, but you still need the basic operations which the scripts use. From what you've said, it sounds like most of these are in fact in place already, but you do want to give some serious thought as to what has to be primitive and what can be scripted out of those primitives.

It also occurs to me that of the two implementation strategies you've mentioned, one of them (PHP and C++) is entirely server-based (unless you use an ActiveX control or something similar), while the other could be either entirely server based (servlets and/or JSP) or have an active client as well (applets). Is there anything which you may need an active client for in this game? That is to say, are there any parts of it that should run independently from the server, or for which messaging from the client to the server and back would present a considerable overhead and lag?

To give you an example of what I mean, most games involving any animation - moving an icon around a map, for example - would want some sort of client to perform the animation, rather than have to refresh the entire page just for a single move. The usual method would be to have a standing socket between the client and the server, which they can pass messages through without going through the HTTP server. On an action, the client sends a message to the server informing it of the intended action, then the server sends back a message either confirming or denying the action. In the meanwhile, the client will usually go ahead and render the updated action (though if it is a turn-based game, it may wait for the confirmation to go ahead and display the new screen). If it is denied, the client can back out of the action and give the appropriate response instead. This means that only those smaller messages are passed over the network, rather than a whole updated screen, and the client scan actually do much of the work rather than overburdening the server.