PHP and HTML for games?

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.

sounds interesting. What is needed first is a really decent game framework that can be used for many sorts of games (along the same lines)

I've been thinking about this for a while. PHP would be good for some types of games - maybe a pokemon card game with chat, etc. AJAX also offers new possibilities.

Add http://www.imagemagick.org to the mix, and you can do some nice things with graphics too, at the cost of a bit of extra processing time.

I guess it could work for a relatively static game, like a turn based thing or a point and click adventure game. I actually had an idea for an adventure game in PHP (which I'm not going to share, as I think it's brilliant and it's mine mine MINE! :-P ). Hehe...anyway. You could always combine it with some Java if you need more interaction on the players side, the down side being that the players will actually need to have a browser that supports Java.

As a side note. If the layout of the game is compact enough, you could make it so it can be played on PDAs and mobile phones that have web browsers.

Ragnar

The interesting thing, Grey, is that PHP with mySQL is already perfectly set up for games. Games have 2 parts that make them a game rather than just some application, code wise at least. The graphics end, and the gameplay through input. Both are done for you already in HTML, with forms and tables.

You can set up tiles, or even individual pixels in tables and assign them values in a session var. and you can place the sprites on the upper layer. Both the BG and foreground can have animated graphics and you could use rollovers to highlight things (wouldn't do more than that, since it might effect playability if it is turned off) then you make the tiles around the character sprite a link, and when clicked it changes data that in turn changes the location of the PC.

Most actions would be issued by clicking on the graphical field, or you could use traditional forms like pull downs and such also. Maybe you have a conversation engine in the game, and you give the player his choices of what to say in a pull down.

Basically, you don't need a game framework, because each game can have a totally different way to interact with the system. Each game can have a totally diff system to use what the interaction method gives it.

That's the problem up to now, everyone instantly notices how totally modular PHP and HTML are and wants to build an engine, then they get caught up in making it as useful as possible and you wind up with a some kind of duplicate of all the other PHP engines out there. On the other hand, the people who know little about PHP and started to use it in the hopes of creating 1 game, get lost in trying to just get the darn thing to work, they might try to bodger in mySQL later... They take forever to finish, and create crap products with limited abilities.

The way to go is to use PHP EXACTLY like you would an already existing games centered code language like our beloved blitz.

The framework is already there, it's just not what we are used to. Tables, Forms, and gifs.

using just those simple constructs you can make infinitly complex turn based games. Down to pixel perfect calculations if need be. (imagine a circle based movement that is pixel perfect where you click exactly where in the circle you want your sprite to move)

The only framework needed is how to represent the tiles. Their links would be submit buttons on <form> tags, with hidden X Y values, as well as any other value you want to give it... such as, isAttack = 0 or 1, when the tile happens to be an enemy, it turns to a 1, so it calcs the attack rather than a movement, or returns that you are too far away to attack. The <form> tag is in a table cell, and the table defines the location of each part, and could even support non-standard tile configurations with colspan and rowspan. (such as half offset to make a hex grid) All of this is created by the PHP code, which does all the calculations.

The framework is so simple, its stupid.

If the cell or PDA has a TRUE web browser that reads plain old html files.. it should be able to play a game... might have wild scroll bars if the game isn't designed for it tho.


This seems to be going over quite well, anyone who wants to work on the project I am, shoot me an e-mail. I could use a second set of hands, or a better artist...

your sound fired up about this, good for you. I look forward to seeing a web-based MMORPG next week then ;-)

haha..

next week? a mmo would take a lot longer than a week... not for the engine, for the content. I could prolly have an MMO engine built in a month or so. Anything you'd like to see included in that? or just a turn based MMO with shops, and tactical battlefields all across the world? the issue is conversation, I haven't ever done a chat system, specially one that shows new msgs without a reloading of the page... if someone showed me how that worked, and it works on any broswer, I could do it... otherwise, I'd stick with a see what was said when you post or when you reload it.

I don't really want to make an MMO yet tho. I want to test the concepts on a single player game first, then move into the whole multiplayer mmo thing.. not cause it is harder, because it really isn't, but because it is longer.

I'm going to hold all the data in databases, such as Sprites, Tiles, Equipment Spells Items and so on.. and lets take items for example, they will have a graphic assigned to them when they are made or edited, so they will chose from the list of Sprites, and it will all work together to form the content for the game.

The engine will read that it needs lets say a Potion from the items table then the Potion says it needs the Potion_003 from the sprites table, it will display the info in the inventory, and lets say the player clicks Use next to potion, then it will look and see the party members of the PC's team, he picks someone to use it on, then it looks up what Potion does and so on.

all the maps and npcs and everything will be held like this, so it will be very natural when coding the engine. I might make it more OO or maybe not. but either way there will be things like item_sprite_name(item's name); which returns that item's sprite's name. which can then be used in sprite_url(sprite's name); to return the URL for use in an <img> tag.

so the code might end up looking like

echo "<img src = "";
echo sprite_url(item_sprite_name("Potion"));
echo "">";

this would be, obviously, for the Item list in an inventory screen, which wouldn't use the table scheme I described before, but sprite_url(); would be used in that too, to call any of the sprite's urls based on their name as given by anything else... Like maybe.... npc_sprite_name(Bob,left); which returns Bob's left facing sprite's name. so now.

echo "<img src = "";
echo sprite_url(npc_sprite_name("Bob","left"));
echo "">";

That will show bob facing left or maybr current direction of the NPC's facing will be stored in the database, so it will automatically be changed when bob decided to move left in the last turn.

I was kidding! you know that don't you? Make something very simple just to prove it works!!!

Just thinking. Is there anyway around having to reload the page when you move, while still using plain old HTML and PHP. Say Bob is on square one and you tell him to move to square two, you want him to move but not reload the page. Of course, it would be quick with all the images cached, but still.

What I was thinking with PHP and HTML was a more text based kind of thing. For instace, it could work great for a Football Management game with multiple players or text adventure, both with some graphics, but not your typical tile map game. But I guess anything is possible.

Ragnar

well... no, you couldn't move things around without re-loading the page with just php and html....

and anything else will require the user's computer to process the code. The whole point of doing it this way is so the user doesn't ave to have anything but a browser.. so that if they can use amazon they can play the game... otherwise, why not code the whole game in Flash.

Why not use PHP / MySQL for the multiple connections and macromedia flash for graphics & sound. That'd be my first port of call for multi-user browser based games. I know some people hate flash with a fiery passion, but flash in the right place is not bad at all.

*edit*

If you were using browser technology for games and serverside PHP /MySQL for multiple connections then you better make sure you have root access to the server so you can set up a proper socket server. If you use PHP and MySQL on the average virtual host then expect things to drag when you've 20/30 users sending and receiving data all at once to each other.

I know you said you're against flash, but atleast that way you could take alot of CPU stress off the server when dozens of people are playing and you can scale flash to fill different browser resolutions.

If you want to learn about PHP/MySQL connecting to flash and setting up socket servers to handle 100's of connections without being a huge drain on your host then for $5 you can buy flashchat from tufat.com - it comes complete with full source code and from that you'll be able to gain ideas. Granted flashchat is a chatroom app, but the basics of a realtime turn based multi-user game are there.

own the server, so no worries. and I don't want to use flash at all for 3 reasons. it won't work on ALL browsers like this will... meaning, anything that can look at html and have graphics will be able to play these games. Not true with flash.

secondly... Flash is not cheap.

and 3. I'd have to learn it.. and I wasn't able to the last time. AS just illudes me. Not sure why.


Though, I do agree that flash in the right places is good. I wouldn't have any problem using flash for say. Cutscenes that could be skipped if you don't have flash (or would display a text or screen cap comic like ver. of the flash animation as an alternative)

I can also account for several display types, You pick a look in the settings you like, small, medium, large, type deal.

Your graphics and UI won't look good/work on all browsers without a lot of pain. Have you ever tried to make something cross-browser? Getting the same results in the last few versions of IE and Firefox is difficult enough! Flash would be ideal for this type of web game.

I played around with a (free) Perl module which generated flash movies a few years ago when I was interested in making an online PerlRobots game: battles between bots would be simulated nightly and flash animations would be posted to the site to showcase the results.

course they will... you just gotta be flexible and detect what browser they are using... the only important bits are the tiles and thats as simple as a couple changes to the table tag.

EDIT
it only matters that the tiles tile, everything else will be spaced out enough not to matter greatly. Honestly, people are total control freaks, web design is all about being flexible in your design, to have it look good most of the time, and work the rest.

i have done a game in plain php&mysql. it took me many many hours to create. www.pimpomania.de you can have a look if you want to.

Battle Empire uses php/mysql for player list and some other stuff. Also I made a little php generated map preview system (only works with IE at the time).

Actually you can. By using the AJAX method, you can use JavaScript and XML to have live feeds on your browser to the server. This would avoid having to refresh the page and could allow any type of PHP game to be created - not just turn based ones.

Game Boy, problem with Jscript is people turn it off or sometimes don't even have access to it... and XML is going to work on even less systems, so for a chat system, it might work well, if it degrades nicely into what I described before, but it couldn't possibly work for a game and degrade well...

I'm sure there is another way, some kind of old old old school vintage 1994 chat tech.

@Game Boy: thanks for 'AJAX'... I was going nuts there racking my brain to try and remember what that was called.

I forsee 'lag' being a significant issue for any type of 'mm' game that tries to go down this route. If 5~50 millisecs is an issue for RT games, how much of an issue will 1~10 mins turns be ?

I don't think it is going to be a problem. I guess we'll see. If it becomes a problem, that means it is very popular, which in turn means I can afford to buy new servers and set them up and then give people a server choice. People will migrate away from the crowded server and then I'll have 2, or 5, or 10.

And should it become unplayable when there are 1000 people playing it all at the same time, well, I guess I'll just have to put that on my resume.

Use the DOM to redraw the page without reloading and RPCs (Remote Procedure Calls) to send data / request updates from the server. That's pretty much how GMail works.

I would say that most people have JavaScript enabled these days. If they haven't, just place a notice to say that they should.

I don't want to require anything other than the most basic of browsers to play these games. I really can't say why yet. Just trust me.