Confused. Can I use PHP to make a game?

Started by
18 comments, last by fastcall22 9 years ago

I was wondering if I could use PHP to make a game. Is it possible?

I searched online, and I found very vague responses. By vague, I just mean people say "sure, you can use it", mention SQL for saving data...and that's all. How can I use it? I know Flash and JavaScript are popular right now for browser-based games--and I've made a JavaScript mini game on my own computer with a character walking around the HTML5 canvas--but honestly, I'd rather use PHP. In what ways can I do so in an online turn-based game? By the way, I am aware of the snake/tictactoe/other basic game tutorials that are out there, but these aren't really the kinds of games I'm referring to.

If I can use it for modern browser games, which webhost should I use? After a bit of research, I came across x10hosting. Is that a good site to use for now? I did install WAMP on my own computer, but I can't keep it online 24/7 at the moment (and I don't have a domain name yet).

*Note: If this topic is in the wrong section, please let me know.

Advertisement
PHP runs server-side only, not client-side. So you use it for the server-side half of the game, and something else for the client-side half.


{ PHP on server machine } <-> { data (json, html, etc) over internet } <-> { HTML/JS/AS3/Unity/etc on client machine }

PHP runs server-side only, not client-side. So you use it for the server-side half of the game, and something else for the client-side half.

Right. That's why I need a webhost that supports PHP. So I can run code on the server. Something like JavaScript is typically used for the client half, but I was wondering if that's really necessary. Can I make a pure php game (ex. a text-based game that accepts input via HTML properties, handles it, and writes new information to the browser using HTML tags)?

Yeah, you can make a game where the only client-side stuff is plain old HTML. Game actions can be made using form posts. The downside is that this typically results in a game where taking a turn completely reloads the whole page on the browser.

An incremental improvement from that is use javascript to communicate with the server and update only a portion of the HTML instead of reloading the whole page.

And then the extreme form is to do as much as possible in javascript and only communicate with the server when necessary (passing just game data back and forth).


You can choose to implement your game anywhere along that spectrum.

As for x10hosting, I haven't had any complaints with it as long as you log in every month or so, whatever the requirement is. Any issues that came up I put in a ticket and they responded quickly.


An incremental improvement from that is use javascript to communicate with the server and update only a portion of the HTML instead of reloading the whole page.

How can I do this? That seems like a good way to go. Can I use something like this:


showInventoryMenu.onclick() = function(){ guiElement.innerHTML = "<?php /*retrieve data from database*/ ?>"; }

I'm not sure how I can use Javascript to communicate with the server in any other way.

I'm not sure how I can use Javascript to communicate with the server in any other way.


Requests can be done with XHR and you can use a cross-browser library such as jQuery, AngularJS, or some other lightweight XHR library. Async processes are a pain in Javascript, since you can only nest async functions, but Promises make things a bit better.


Client:
# sample.coffee
# for the compiled javascript, see: http://pastebin.com/0di9bsVs
game_state =
	player_id: null
	last_update_ms: 0
	score: 0

do_update = ->
	defer = $.Deferred()

	$.ajax # nake XHR request
		url: '/update.php'
		method: 'POST'
		dataType: 'JSON'
		data:
			last_update: game_state.last_update_ms
			score: game_state.score
	.success (response) ->
		if not (response and response.success)
			defer.reject response.message or 'Unknown error occured'
			return

		defer.resolve response.payload
		return
	.error (response,code) ->
		defer.reject "Server returned #{code}"
		return

	return defer.promise()


disable_ui()
do_update()
.always ->
	enable_ui()
	return
.done (payload) ->
	update_game(payload)
	return
.fail (error) ->
	alert "An error occured\n#{error}"
	return
Server:

<?php
# update.php
$response = [
        'success' => false,
        'message' => null,
        'payload' => null
];
 
/*
# capture PHP errors and warnings, if desired
function hook_error() {
        global $response;
        $response['debug'][] = func_get_args();
}
set_error_handler('hook_error');
*/
 
$request = $_POST; # or json_decode php:?//input
try {
        # fill sample data
        $game_data = Game::update();
 
        $response['success'] = true;
        $response['payload'] = $game_data;
} catch ( Exception $ex ) {
        $response['message'] = $ex->getMessage();
}
 
 
header('Content-Type: application/json');
print json_encode($response);
EDIT: Stupid editor ate my post :?(
EDIT2: OMG
EDIT3: IPS PLS
EDIT4: FINE, I'LL USE PASTEBIN
EDIT5: NEVERMIND, I'LL JUST STICK IT TO THE MAN

Right. That's why I need a webhost that supports PHP.

Not necessarily. Well, you'll need one once you've finished your game. smile.png

Until then, you may want to consider running a PHP server directly from your machine using EasyPHP or run a full-fledged web server in a virtual machine with Ubuntu Server or some other Linux distro.
I use UniServer: http://www.uniformserver.com/
It is dead simple. I prefer to run my webserver locally instead of in a virtual machine.
The built-in php webserver is good, but you would definitely want something better.

I have tried x10hosting and I didn't like it, but you generally get what you pay for.
Dreamhost is a good option - have been a happy user for years.

Don't mess around with an external webhost while you are developing your game, at least not until a later stage.
It sucks having to sync local and remote constantly. Especially when you are just starting out and a lot of files/directories gets shuffled/changed/moved/deleted..

If you are interested in the web why PHP?
Since you are going to be using Javascript anyway, why not pick one of the many html5/javascript game engines?
You can use PHP, but there are better options today: local storage and cloud sync.

Too many projects; too much time

If you are interested in the web why PHP?
Since you are going to be using Javascript anyway, why not pick one of the many html5/javascript game engines?
You can use PHP, but there are better options today: local storage and cloud sync.


Local storage and cloud sync are not appropriate replacements for server back-ends. You could use local storage, if the game runs locally and doesn't require communicating with anybody else, including the game's server.
If you're looking for alternative, more responsive back-ends, then look into using websockets with a nodejs server or separate php process dedicated to listening to websockets on a separate port.

This topic is closed to new replies.

Advertisement