My newest project, Webventure, is an adventure game engine with a simple browser interface. The engine is written in PHP, uses XML for game data, and includes a rudimentary scripting engine. There's one game online right now to demonstrate how it works. There's also a form to publish your own games. If you're interested, feel free to register and give it a try. I'm still working on the documentation, but you can see the XML file for the demo game here. Let me know what you think! [edited by - DaTroof on March 7, 2004 6:02:02 PM]

I must say that''s interesting..

Is it multiplayer capable?

quote:Original post by Game_Dude_man
I must say that''s interesting..

Is it multiplayer capable?

Unfortunately, no. I''m not sure I''ll be able to make it multiplayer easily. It''s turn-based and there''s no framework to allow for round-robin action or anything like that.

Ahh, that''s too bad.

But still interesting, non-theless. :D

Bumped to say that the first drafts of the gameplay instructions and the development manual are online.

couldn''t you use webservices to build in mp features?

quote:Original post by Themonkster
couldn''t you use webservices to build in mp features?

It might be possible, but that opens up lots of other cans of worms.

If the game is real-time:

* If two players are in the same room, how to update one''s screen when the other leaves? You could use meta refreshes to collect new messages, but...

* How often should the page refresh? Too slow, and the player might try to interact with a player that already left the room. Too fast, and the screen spends a lot of time blinking. Either solution could lead to a frustrating game experience.

If the game is turn-based:

* What should be done if a player leaves the game or goes idle? How long should the server wait before cancelling their action and/or removing them from the game?

* If a player moves out of turn, should his action be queued or ignored? Neither answer is completely satisfactory.

If the game is tick-based:

* How often should the ticks occur? Too quick, and the game might as well be real-time. Too slow, and the game gets boring.

* There''s the same issue regarding page refreshes as with real-time, only they need to be synchronized with the game ticks.

* What to do with multiple commands between ticks? Put them in a queue, or throw them away? If queued, the player could get annoyed by errors from obsoleted actions, same as real-time. If thrown away, the player would have to enter them again, which is at least as annoying.

For mp games that work through HTTP, turn-based or tick-based action is probably best. Unfortunately, neither works well with this type of game, since the multiplayer aspect isn''t nearly as fun without real-time interaction. If I were to make a browser-based mp game for the Web, I''d prefer to make it a Flash or Java program that maintains a persistent connection to the server. That eliminates most of the state synchronization nonsense that exists with an HTTP version.

Side note: I do have a multiplayer project in the works, but not browser-based. It''s a graphical MUD with a stand-alone client. I had it online for alpha testing a few weeks ago, but I had to take it down temporarily until I find a new home for the server.

yeah some good points.

I think maybe a mass trading game would be viable with webservices with an email clone messaging service instead of an instant message system.

turn based would work but as you said there couldn''t really be a chat system. but saying that you can get flicker free browser based chat sessions going with a little work.