Archive for November, 2009
So, mouse scroll wheel events still dont work  In browser [/edit] on osx! its hard to believe, but true. Luckily i found a great SWFObject plugin + as3 class from PixelBreaker in his blogpost :
It didnt take too long to port the code across to haxe in order to add the finishing touch to our latest haxe/flash website City on a Hill.
NOTE: You should run the test through a server (eg. apache) to avoid annoying security issues.
Download the Source and Demo here
I've been having a little play with creating multiplayer games in flash. Its kinda like that basic game - Gorilla, or was that Bannanas? hmm... not as chunky gfx yet tho ;P
It sounds pretty easy at first - but is getting a little complicated - even with my small test. The haxe mailinglist has been helpful in getting me started with some good advice.
One approach is to use an authoritative server - where the server runs a simulation of the game. Clients then connect & post their user input to the server. The server will make changes to the simulation and then post back updates to the client(s) about what has changed/is relevant to the user. This is a solid way to ensure that each client is getting the same experience. A major downside to this approach is the greater server load associated with running a game simulation. Especially if the game is planned to run a physics simulation (eg box2d), then the processing would be far too great - especially if a game only supports 2 players, and therefore the number of simulations/players will be extreme. A great upside of using haxe is that the game logic required to run the simulation on the clientside, can easily be compiled to the serverside target (neko, c++) to run the server. This will prove a MASSIVE bonus for creating authoritative multiplayer flash games.
The approach i've taken is to only run updates on the client side. There are 3 different systems running in the test:
Rotating a cannon
The keypress event is sent to the server with the new roataion, this new roataion is broadcast to all clients (including yourself) then the rotation is applied. This means that you should experience similar latency to the opposition. Which isnt great - but it is very simple. As it is linked to the 'cannon' update loop - events are fired to the server at the tick rate (60fps) which isnt great either - a 'rate' should be capped for updates.
The event to create a CannonBall is send to the server. This is so that the server can increment a 'count' of cannonballs. It is important the each client can identify each cannonball - for later destruction. This is the only authoritative part of the simulation. Each cannonball is also 'owned' by a certain player - meaning that that players simulation controls its motion. This is fine for the simple test, but i can see that if cannonballs 'owned' by one player needed to interact with balls owned by the other, then problems could arise.
So, each client updates the motion of 'its' balls, and boardcasts this to the other clients (via the server). This means that you have smooth motion of your own objects.
In a turn based game (what i'm looking at making) this switching of 'ownership' of the simulated objects should work reasonably well - the non dominant client will have a more latent, jittery simulation (as inaccuracies are fixed). Another option would be to run one of the clients as the 'dominant' or 'server' client all of the time. This would be similar to how quake runs when you run it on a local network (atleast how use used to run quakeworld - hah memories).
So now i'm loking at ways to reduce/account for latency - as i think that over the internet the test would run a little jumpy.
Running the test
compile the hxml file (install haxe/neko from www.haxe.org)
run the server.bat
open 2 instances of the bin/Gorillaz.swf