I have a really cool suggestion to make, If its possible that is.
Ryan Brady from the playerIO tutorial says that it is impossible to run AS3 directly on the server, right? So as a result, Multiplayer Game developers using playerIO tools are forced to learn a completely new language, C#, just to make their game multiplayer. Ryan said that not many people have the time nor want to take the effort to learn a completely new language, and as a result, many multiplayer games dont get published successfully, or they would base their multiplayer games on a simple P2P framework, using C# only as a bounce server, which isnt very efficient nor secure.
But I have an idea. What if developers could somehow develop an SWF representing the game as it would work on the server (server-client model) in Flash, upload it to your servers, and have an instance of the swf started using C# on the serverSide code. I've already found an example where you can do this:
- Code: Select all
using System;
using System.Diagnostics;
namespace startProgram
{
/// <summary>
/// Demonstrates how to start another program from C#
/// </summary>
class ProcessStart
{
static void Main(string[] args)
{
Process swf = new Process();
swf.StartInfo.FileName = "D:/Game.swf";
swf.Start();
}
}
}
Using this code in C#, I successfully launched my own flash game from the command prompt.
If playerIO could somehow nest this block of code inside a gameStarted() function, whenever a room is created, the swf could be opened, and act as the "Host" from within the server.
From the on, the "Host" swf would act as a client, except that the client is persistent as long as the room remains open, and remains on the server, so it is totally secure. Messages can be handled or sent by using the AS3 PlayerIO.connection or client API. The C# code would continue to accept messages coming from the player Clients, and send them into the "Host" client, and vice versa. Nothing more complex than a simple bounce server shall suffice.
And when the room is closed, process.Kill() can be used to terminate the Host Client.
There are a lot of benefits to developers should you guys adopt this idea over the current method. For once, the generateDebugView on the development server isnt very productive. The C# drawings API is far less user friendly and less flexible than the flash display list; and it would be very difficult for developers to see what is going on inside their game without seeing any graphics.With this method, the development server would be very much redundant, developers can simply test their Host SWF on their computer.
Secondly, flash is tailor made for games, whereas C# is more for applications. It is alot more verbose to create a game in C# than in AS3.
And thirdly, developers who already have a single player version of their game and wish to turn their game into a multiplayer version would have to rewrite their entire game in C#, which is prohibitively daunting. If the Host client runs on AS3, it would be far simpler, the mechanics of the game can be left intact, all that needs to be done should be change the Mouse input listeners into Message input listeners, and display rendering functions into Display update message functions.
And finally, for new developers, they wont have to do double work, i.e write the client side code using AS3 and then write the serverside code using C#.
I am sure that should playerIO take up this idea, it would eliminate most of the obstacles towards making a multiplayer flash game, and playerIO will be used by a whole lot more developers.
Cheers!