I know it's been done, and in some rare cases with a minor amount of success, not in a game, but in game engines.
HOWEVER.
web pages are perfect to display static data and pregenerated motion (animated gifs), meaning, it should be possible to make ANY game that would have a static non-moving input and pregenerated animated parts like a walking sprite for example.. perhaps even rollovers that wouldn't effect the gameplay should they be turned off.
In other words. Turn based games, all the way up to multiplayer, or even MMO turnbased, or possibly asayncronus turn based games.
I don't want to get too far in, and I know my reputation around here so I won't start screaming like a maniac about it, but, if anyone is interested in PHP as a game language, give me a shout. I've already worked out all the conversion issues in my head. That is, converting a traditional 2d games creation mindset into one that works inside the website world.
The only aspects that change are how you go about the graphics and input, and the fact that it can only work for a turn based game.
There are some really great reasons to do it tho, like:
- Automaticly cross platform into ANYTHING that has a browser that can handle forms and graphics.
- Requires no minimum specs since all the processing is done on your server.
- Is already set up for online play.
- Can't be pirated.
- No download time for users.
All of those are also advantages over Flash.
the only real disadvantages would be:
- all the processing is done on the server, and could bog it down if lots of users/processing, is needed.
- Storing user data.
Both are actually very minor if your game is designed well, take a really hard single player tactical RPG, someone would spend a while picking the next move and in that time, not use any of the server's cycles, when they submit a change, it would process it only as far as the next movement the user need take, which wouldn't require much to do. And the user data will be tiny, perhaps a Mb per 10-100 users (depending on what you are mining) which means a game with 100,000 users might have a gig of user data stored, well withing the realms of manageable.
Like I said, if anyone is interested, I'll gladly tell em more about what I've been thinking. If anyone wants to work on a game using this, give me a shout too, I don't expect anyone to though. Nor am I counting on it. This is well within my own current abilities to do.
Just thought I'd tell you all about it, see what you think.
HOWEVER.
web pages are perfect to display static data and pregenerated motion (animated gifs), meaning, it should be possible to make ANY game that would have a static non-moving input and pregenerated animated parts like a walking sprite for example.. perhaps even rollovers that wouldn't effect the gameplay should they be turned off.
In other words. Turn based games, all the way up to multiplayer, or even MMO turnbased, or possibly asayncronus turn based games.
I don't want to get too far in, and I know my reputation around here so I won't start screaming like a maniac about it, but, if anyone is interested in PHP as a game language, give me a shout. I've already worked out all the conversion issues in my head. That is, converting a traditional 2d games creation mindset into one that works inside the website world.
The only aspects that change are how you go about the graphics and input, and the fact that it can only work for a turn based game.
There are some really great reasons to do it tho, like:
- Automaticly cross platform into ANYTHING that has a browser that can handle forms and graphics.
- Requires no minimum specs since all the processing is done on your server.
- Is already set up for online play.
- Can't be pirated.
- No download time for users.
All of those are also advantages over Flash.
the only real disadvantages would be:
- all the processing is done on the server, and could bog it down if lots of users/processing, is needed.
- Storing user data.
Both are actually very minor if your game is designed well, take a really hard single player tactical RPG, someone would spend a while picking the next move and in that time, not use any of the server's cycles, when they submit a change, it would process it only as far as the next movement the user need take, which wouldn't require much to do. And the user data will be tiny, perhaps a Mb per 10-100 users (depending on what you are mining) which means a game with 100,000 users might have a gig of user data stored, well withing the realms of manageable.
Like I said, if anyone is interested, I'll gladly tell em more about what I've been thinking. If anyone wants to work on a game using this, give me a shout too, I don't expect anyone to though. Nor am I counting on it. This is well within my own current abilities to do.
Just thought I'd tell you all about it, see what you think.