Posts tagged SWFConduit
Make no little plans: Why you should explore the improbable & impossible
4“Make no little plans. They have no magic to stir men’s blood and probably will not themselves be realized.”
Daniel Burnham
As many of our readers know, Double Cluepon is based here in Chicago, home to the late Daniel Burnham. We tend to take the spirit of the above quote quite seriously. What’s the point of doing the insignificant or the mundane?
Yet, for all our technological advances, for all the wonder and “what if?” that brought us here there is but one thing in the game industry that is really truly unsettling. The people who find reasons, fair or foul to say “can’t” instead of “can”. We have personally encountered this behavior from the very people who we think should know better. We have encountered teachers and professors who cast a disdainful eye at us when looking at StoryTeller, because we feel that an artist, or a writer should not be *required* to always seek out a programmer to create. We have encountered so called peers who look at us with skepticism and outright scorn when we enthusiastically talk about some of the things we are attempting, and would like to attempt.
There are naysayers in any business. But nowhere can they be so heartbreaking and frustrating as in the game industry. What shocks us more is that these people show a scornful eye at anyone who is enthusiastic about this business’ stock in trade: the ability to imagine a “what if?”. They disdain the very core element of the trait without which they wouldn’t even be here.
Recently, a fellow over on gamedev.net posted this rather silly and contrived article. One of the folks we follow, Over00 made a post on his blog commenting about it. But, I wanted to really address it a bit more point by point. Because this kind of behavior among developers needs to stop. It’s truly bad for business. Game developers, and especially the ones who have a title or two under their belt and thus represent a kind of ambassador for this industry need to shape up or shut up. They need to learn to stop saying “can’t” when “can” will work just as well.
One of the things my dad used to tell me was, when someone begins a debate using semantics, he’s already lost the argument. No place is this truer than with ApochPiQ opening:
MMOs are expected to host dozens of servers running thousands of players apiece. Successful games may be played by over a million people; some notable ones are played by far more than that. Even a low-grade MMO serves a few hundred thousand players.
[..]
This is the root of the problem, here, this “massively” multiplayer business. Because going from just “online” and “multiplayer” all the way up to “massive” is a huge deal.
For one thing, I never realized MMO was an industry standardized term based on actual hard numbers. (READ: It’s not) Massively is a pretty subjective term in and of itself. But, let’s just get down to brass tacks here. A term in many ways is defined by it’s usage. By this definition, only WoW or Everquest (or similar titles) qualify for that supreme monkier “MMO”. But the facts just don’t bear that out. MMO is a generic term, and not a specific one. At it’s peak, the most I ever saw Sage Ocean on Puzzle Pirates hold was about 1100 users. I would also say, Three Rings is an established boutique/niche MMO developer. I mean, the ARPU metrics alone say so. So, I would say that Puzzle Pirates from Three Rings is an MMO, after all…it would seem Google, that barometer of what is and aint seems to think so. As a game designer, one would think you would understand a bit about Dunbar’s Number. I would say as a human being who can keep track of about 148 people…1000 is pretty massive.
So really, the MMORPG moniker is nothing more than a bit of semantics. “Massively” and “scalability” in this sense are not in any way the same thing. In reality, the scalability of any online game is something every aspiring developer should be thinking about in the early stages regardless of the genre he is heading into.
But, let’s get into a few of the other “you can’t do this” arguments…
I will bet you a beer (or suitable beverage of your choice) that you can’t find an MMO with over a million players with a development team of less than 100 people.
See how this fell into the scalability argument…again? In this case, it’s “You can’t do this because you have no scalable staff”. This renders the argument moot, really. Because not every MMO needs to be WoW. Sacred Seasons, Puzzle Pirates, Fairyland..the list goes on. This again is a semantic argument about scale.
I will bet you a second tasty beverage that the average developer working on an MMO has shipped at least 2 games prior to shipping a successful MMO. Many successful MMO titles are even the results of collaborative efforts from dozens of people with prior MMO experience.
Ahh, here we go. We here have seen this one before, many times. You can’t do this because you haven’t paid your dues. That’s what it boils down to. This kind of garbage argument does not belong anywhere in our industry. Not with the technology we have available these days. I can even name an MMO designed by a person who seems to have no prior games: Sacred Seasons, it’s even a flash based MMO.
As incredible as it seems, the semantics, along with the argument get more ridiculous…
Running an MMO is immensely expensive. Internet hosting and server costs alone can be in the tens of thousands of dollars a month range. Buying all the hardware you need to run the game up-front can be well into the millions. You need a dedicated datacenter for the endeavor, with redundant power, fire safety systems, industrial cooling, and hundreds of miles of both copper cabling and fiber optics. A single network switch capable of running an MMO backbone can cost ten grand by itself. And if you want a global reach, you’d better roll out a datacenter on every major continent, at the very least. Three or four per continent is more like it.
Let’s break this down by rejecting his straw man argument of “An MMO is only for millions of users”. Once we get that fallacy out of the way, the rest of this is a great deal of scare tactics. Further diminishing the credibility of the argument being presented. It makes you consider the source. Double Cluepon has created a Flash Socket server that runs and scales pretty well in FreeBSD machines hosted on Xen. Anyone not dealing with virtualization now is already behind the curve. Our server costs right now? About $500 a year. It will go up. We know this, and have planned for it. Not just in the code either. In the budget. Indeed, in our chosen technology, there are even folks who will do a lot of the hosting for you. Sites like Kongregate. The rest of this is just silly. Blizzard may need to run an “MMO Backbone”, but I can tell you right now, there are plenty of boutique and niche MMO’s that don’t need an “MMO Backbone”.
But, let’s go on…
Graphics are amazingly critical. If you don’t have a great looking game, don’t expect to attract too many players. The MMO space more than any other genre is dominated by players who are into aesthetics and first impressions. A great game with bad graphics might still get some hardcore fans, but it’ll never compete with a great game with great graphics.
With this statement, he loses any credibility he may have had left. As he seems to be of the mind that “I work for ArenaNet, makers of Guildwars” so you have to listen to me, let me just deflate that a bit…First off, in my opinion, calling him a game designer might be a stretch. He may write code, but my best guess is, it’s probably in a cube farm. That’s all well and good. But to see the complete fallacy of the above…replace “Graphics” with “Gameplay”….and any real designer will tell you right now the above is a bunch of malarkey. It’s also one of the biggest problems facing the game industry today: shiny vs gameplay. When I look at successful, money making MMO’s…sure, WoW is there. But WoW is a roll up of a lot of other games that came before it. Let’s look at Minecraft, let’s look at Puzzle Pirates, let’s look at the sheer number of isometric MMO’s still rolling out of Asia. I’m still seeing a lot of MMO’s that don’t require serious graphic cards. Many of them which don’t even come close to photo realism. This incessant need for picture perfect graphics is a fallacious argument. It is about, what it’s always been about: the game play. Double Cluepon chose isometric because we could still produce quality looking stuff, but focus more on the game play.
But, it’s par for the course. Just like saying “can’t” where “can” will do nicely.
And we haven’t gotten to the networking side of things yet.
The client side is pretty easy; it just has to connect to a server and spam some packets back and forth. But the server itself is a place of truly dark voodoo.
…and again with the scale argument. It’s really the central idea of his whole post.
At this level, everything becomes important.
…more technical talk, which really is just about establishing his “authority” than actually saying anything useful.
Every single “You can’t make an MMO” article, post, tweet, blog, I have ever seen…seems to come from disillusioned cube farm residents. I am not discounting that an MMO like Guild Wars has millions of lines of code. But just because it does, does not exclude the possible success of others. In other words, just because you did it that way, does not automatically mean someone else CAN’T. Want to play a sharp MMO in 15 seconds? Try Sherwood. (Shockwave based If I recall…perhaps we should ask them about their MMO Backbone?)
This attitude among developers needs to stop. The article by ApochPiQ could have been much more constructive, and still conveyed a bit of the same message. Had he called it “Planning for Scale in online games”, perhaps he would have gotten a bit farther. At the end of the day, the MMORPG, the Persistent World, the MMORTS…they are becoming tangible targets for underground and indie game developers. The numbers (read: facts on the ground) seem to bear out that small MMO’s are collectively bigger than any of the AAA’s. But addressing the game development community as a whole in this way, as if they were a bunch of 16 year old kids on a basement computer with a warez’d copy of RPG Maker is insulting at best. It’s a black eye to our industry at worst.
It needs to stop. This continual attitude of “you cant”, or outright derision toward the dreamers in this industry needs to stop.
Perhaps instead, we should be trying to feed each others dreams. Perhaps instead we should be honestly trying to help each other realize new things, and new ways to play and have fun. Perhaps we all need to do our part to help creative people channel their creativity into works that are fun, works that inspire. You do that not by telling someone you cant, but by telling them how they can.
When it comes to an MMORPG, it does take a lot of hard work. It does take a great deal of creativity. Not always from one person, but certainly a strong and fiercely creative mind. It takes scale, and organization. But it does not need to require 200+ people.
You can make a smaller game, or an MMO, or an RTS. Create! Fill the world with content! But if you want to shout anyone down…shout down the ones telling you something can’t be done. Those people are not patriots of our chosen profession. The designers I admire most are the ones who use “can”, the ones who plug away every day in the trenches of their own code and dog food. The ones who keep trying, and learning, and refining.
If you’re one of these people who feel that it’s your job to do nothing but deride, cop an attitude, and subtly discourage people, do us all a favor: get the hell out of this business, and please don’t look back. You don’t belong here. Your attitude is the antithesis of what brought us all here today: the ability to ask “what if?”, dream of new ideas, and trying like hell to make those ideas come to fruition. People worthy of praise make no little plans, because they don’t stir the blood.
Don’t worry, we will be just fine without you.
SwfConduit Tutorial: A Simple Chat Server
0NOTE: The permanent version of this tutorial, updated as SwfConduit develops, is located at our project wiki: https://github.com/doublecluepon/SwfConduit/wiki/A-simple-chat-server. You can ask questions about this tutorial in our SwfConduit Forum.
As part of the first stable release of SwfConduit, Double Cluepon’s free, open-source flash socket server written in Python, I’ve prepared a simple example to show how to get started writing your own servers.
In this example, we’ll create a very simple chat room. Users will join the room by launching a swf file and then they can talk with all the other users in the room.
Installing SwfConduit
Server Requirements
First, we will need to install the server’s requirements:
- Python 2.6+ (Python 3 will not work)
- Twisted
- PyAMF 0.6
Twisted and PyAMF can both be installed using Python’s easy_install:
$ sudo easy_install twisted $ sudo easy_install pyamf
Finally, we can get the latest SwfConduit from https://github.com/doublecluepon/SwfConduit/tarball/master
Client Requirements
Using Flash Builder
If you’re using Flash Builder, you should have everything you need to create SwfConduit projects.
Using any editor
If you want to use another editor, you can download the free Adobe Flex 4 SDK from http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4. Once you’ve downloaded the Flex SDK, you’ll want to make sure you can run “mxmlc” from your terminal.
Running the Example
Start the server
Start the chat server by invoking twistd from a terminal:
$ cd examples/chat $ sudo twistd -ny chat.py
A bunch of text should scroll onto the screen, resembling the below block
2011-05-28 22:42:31-0500 [-] Log opened. 2011-05-28 22:42:31-0500 [-] twistd 11.0.0 (...) starting up. 2011-05-28 22:42:31-0500 [-] reactor class: twisted.internet.selectreactor.SelectReactor. 2011-05-28 22:42:31-0500 [-] swfconduit.socketpolicy.SocketPolicyFactory starting on 843 2011-05-28 22:42:31-0500 [-] Starting factory <swfconduit.socketpolicy.SocketPolicyFactory instance at 0x10196eb48> 2011-05-28 22:42:31-0500 [-] swfconduit.server.Server starting on 8000 2011-05-28 22:42:31-0500 [-] Starting factory <swfconduit.server.Server instance at 0x10196eab8>
If there are no error messages, the server is running. Leave the terminal open while you start the client.
Start the client
Using Flash Builder
First, we need to create a new Flex Project. We’ll call our new project Chat. Give it an Application Type of “Web” and click Finish.
Next, we need to import the swfconduit libraries. Right-click on the “libs” folder in the Package Explorer and choose “Import…” from the pop-up menu. In the dialog box, open the General folder, choose “File System” and click Next. Choose the swfconduit/flex folder and make sure it’s checked in the box on the left. Then click Finish to import the files.
Finally, we need to import the files from the swfconduit/examples/chat folder. We follow the same procedure as we did when we imported the swfconduit libraries. Right-click on the “src” folder in the Package Explorer and choose Import… from the pop-up menu. In the dialog box, open the General folder, choose “File System” and click Next. Browse to the swfconduit/examples/chat folder, make sure it’s checked in the box on the left, and click Finish to import the files.
Now, we can open our chat.mxml file and Run it. Your browser will open and the chat window will appear. If the server is running (it should be), you’ll be able to chat.
Using any editor
Compile the chat.swf by invoking mxmlc:
$ cd examples/chat $ mxmlc -l+=../../flex chat.mxml
Then, open the chat.swf file and try it out.
You can use /nick NEW_NICK to change your nickname, and opening the chat.swf multiple times will allow you to talk to yourself without danger of people thinking you’re weird or sending you to therapy.
Creating the Example
The Server
The SwfConduit server handles messages using Event classes. The client sends events to the server, and the server sends events to the client. All the communication is asynchronous, so the server doesn’t have to wait for the client to make a request.
So, the first thing we need to do to build a chat server is create the ChatEvent class. First we import the swfconduit Event base class and create our subclass.
# Create our event class from swfconduit.event import Event class ChatEvent( Event ):
Next, we add the properties of the event. ChatEvent needs a nickname of whosent the message, and the actual text of the message.
# The nickname of the user sending the event nickname = "" # The message text = ""
Finally, we need to describe what to do when the server recieves a ChatEvent. SwfConduit events have a fire() function that gets called when the server recieves it. fire() recieves the swfconduit Server object for the current server, and the swfconduit Session object which is the session that sent the event.
In our fire() function, we’re going to loop over all the other connections to the server and forward the event to them.
def fire( self, server, session ): # We recieved a chat event, send it to every other person for session_id in server.sessions: s = server.sessions[session_id] if (s is not session): s.sendEvent( self )
Once we’ve built our event class, we need to register the class with PyAMF in order for it to be correctly serialized. We’ll also need to register the ChatEvent class we create on the client, later. The server and client will both share the ID string “swfconduit.chat.ChatEvent” to know what they’re serializing.
# Register our ChatEvent class. the first argument is the same as the # registerClassAlias string in the client import pyamf pyamf.register_class( ChatEvent, "swfconduit.chat.ChatEvent" )
With the event class created and registered, we can create our server using the swfconduit Server class. Our server will use the TCP protocol on port 8000, so we’ll pass that into the server’s configuration dict.
# Create the SwfConduit server
from swfconduit.server import Server
server = Server({ "proto" : "tcp", "port" : 8000 })
Now, we’ll load up the application that twistd will execute for us using the swfconduit Loader. The Loader will also handle the socket-policy.xml file for us, which is placed in the same directory as our server program.
# Load and run SwfConduit from swfconduit.loader import Loader loader = Loader() loader.servers.append( server ); application = loader.get_application()
That’s it! We can now run our server:
$ twistd -ny chat.py
The Client
Now that we have our server, we need something to connect to it. We’ll create a simple MXML component that will take input from the user and display the incoming chat messages.
First, like our server, we need a ChatEvent. On the client, swfconduit events extend the swfconduit.Event class.
package swfconduit.chat {
import swfconduit.Event;
public class ChatEvent extends swfconduit.Event {
We make the same public attributes as the server’s ChatEvent. If the two disagree, the flash client will warn you about the attributes it can’t find.
// The person who sent the event public var nickname:String; // The message being sent/recieved public var text:String;
Finally, we’ll make a constructor that makes it easier to create ChatEvent objects. If we override the constructor for an Event, we must provide defaults. When the Event is sent by the server to the client, Flash will use the constructor, but will not pass any arguments to it.
public function ChatEvent( nickname:String="", text:String="" ) {
this.nickname = nickname;
this.text = text;
}
}
}
And that’s all our ChatEvent needs to do. Notice how the client doesn’t do any handling of the Event. Unlike the server, the client’s handling of the event is done using event listeners.
But before we can listen for ChatEvents, we have to build a form. We’ll create a Spark Application that has an area for the chat, an input field to type into, and a label for the user’s current nickname.
<?xml version="1.0" encoding="utf-8"?>
<s:Application width="400" height="300"
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx"
>
<s:layout><s:VerticalLayout /></s:layout>
<s:RichEditableText editable="false" id="chatbox" width="100%" height="250">
<s:text>*** Type /nick NEW_NAME to change your nickname</s:text>
</s:RichEditableText>
<s:TextInput id="input" width="100%" height="25" />
<s:Label text="You are {nickname}" height="20" />
</s:Application>
We’re using RichEditableText so that we get scrolling automatically, but we’resetting editable to false because users should be typing into the TextInputbelow it. Finally, a Label with text bound to the “nickname” field (that wehave yet to create).
So now that we have our form, we’ll add our script. First we need to import the swfconduit libraries and our ChatEvent. Since we’re also going to be working with keyboard events (pressing Enter to send text), we’ll import the flash KeyboardEvent class.
<fx:Script><![CDATA[ import swfconduit.Socket; import swfconduit.chat.ChatEvent; import flash.events.KeyboardEvent;
Now, we'll need to keep some data around, like the hostname and port to connect to, the connected socket to the swfconduit server, and the user's nickname.
public var hostname:String = "localhost";
public var port:uint = 8000;
public var socket:swfconduit.Socket;
[Bindable]
public var nickname:String;
Next, we’ll need to connect to the server. We’ll create an init function that will register our classes and connect to the server.
public function init():void {
// Register our event class
registerClassAlias( "swfconduit.chat.ChatEvent", ChatEvent );
// Connect to the server
socket = new swfconduit.Socket( hostname, port );
}
We’ll need to call our init() function when our application is completed, so add ‘applicationComplete=”init()”‘ to our <s:Application> tag.
<s:Application width="400" height="300" applicationComplete="init()"
Next, we need to handle incoming ChatEvent messages. As they come in, we need to add the text to our chatbox text area.
public function handleChat(event:ChatEvent):void {
chatbox.appendText( "\n" + event.nickname + ": " + event.text );
}
We add our event listener in our init() function, after we create our socket.
public function init():void {
// Register our event class
registerClassAlias( "swfconduit.chat.ChatEvent", ChatEvent );
// Connect to the server
socket = new swfconduit.Socket( hostname, port );
socket.addEventListener( "ChatEvent", handleChat );
}
Now, as ChatEvents come in, they’ll be added to the chatbox. Finally, we need to send out ChatEvents of our own. We’ll add a handler for the Enter key so that it sends out the message.
public function sendChat(event:KeyboardEvent):void {
if ( event.keyCode == 13 ) {
We also want to allow users to change their nickname, so we’ll do that first.
// Let the user change their nickname using /nick NewName
if ( input.text.match('^/nick') ) {
nickname = input.text.substr(6); // Everything after "/nick "
}
If they’re not changing their nickname, they’re trying to talk, so we’ll create a new ChatEvent object and send it out over the socket. We also add their text to the chatbox, because we won’t get our ChatEvent back.
else {
socket.writeEvent( new ChatEvent( nickname, input.text ) );
chatbox.appendText( "\n" + nickname + "> " + input.text );
}
Last, we clear out the input so the user can chat more.
input.text = ""; } }
Again, we add the listener in our init() function.
public function init():void {
// Register our event class
registerClassAlias( "swfconduit.chat.ChatEvent", ChatEvent );
// Connect to the server
socket = new swfconduit.Socket( hostname, port );
socket.addEventListener( "ChatEvent", handleChat );
// When enter is pressed, send the event
input.addEventListener( KeyboardEvent.KEY_UP, sendChat );
}
And that’s all the script we need.
]]></fx:Script>
Now we can compile our swf file and try it out.
$ mxmlc -l+=../../flex chat.mxml $ open chat.swf
That covers the basics of how to use the SwfConduit server.
How To Do Anything
Server Side
At its core, SwfConduit is a very thin wrapper around Twisted and PyAMF. The swfconduit Server class is a Twisted Factory, the swfconduit Session class is a Twisted Protocol that handles encoding and decoding the AMF. You can extend the Server and Session classes to track more data, such as database connections and player information.
But the grunt work is really done in your Event classes. By registering your event class with pyamf.register_class(), any event that comes in will have its fire() method called. Your events can log a user in, retrieve and update objects from the database, or just pass events along to other people (like theChatEvent did).
Client Side
SwfConduit is merely the transport and dispatch layer. Your Event classes just send and recieve data, all the real work is done by your event listeners. By passing the SwfConduit socket around, you can build ORMs, game clients, editors, and anything else you want.
The Future
SwfConduit is the beginning of a platform for multiplayer game development in Flash. As more pieces are developed, we’ll release them as SwfConduit plugins. Simple things like an ORM based on SQLAlchemy, users and profiles, or a chat system that can be quickly integrated with your own projects.
SwfConduit will always be free and open source. Game development should be more accessible to beginning programmers, and SwfConduit will be one of our tools to make that happen.
Livestream Today. 2:30 PM CST. Come watch!
1EDIT: Livestream is over. You can catch the replay here. A few other things not mentioned, so I will throw them out for curious folks.
StoryTeller is ActionScript3, built in Flex. It makes use of the fantastic as3isolib. It’s packaged and distributed as an AIR Application. Never doubt the power of Flash. =)
—-
I’ll be doing a livestream today at 2:30 PM. In this livestream, I’ll be demonstrating our tool StoryTeller.
StoryTeller is our toolkit for Emerald Kingdom. I have said many times, you don’t really “write an MMO”….you write tools to create an MMO. StoryTeller is our tool, and our take on how to create worlds. StoryTeller will eventually be Open Sourced, and available to everyone. Combined with our server, SWFConduit (which is already Open Sourced, you can find it here) it will allow people with creativity to develop virtual worlds and games without necessarily needing a programmer, an artist, etc. While those things are surely helpful, they shouldn’t be a an insurmountable barrier to entry.
We here at Double Cluepon think there are a great many creative types who would be doing more in the gaming sphere…if they had tools which allowed them to express their creativity. It’s our hope that SWFConduit and StoryTeller will eventually allow people with creativity to worry less about needing a programmer so they can focus on creating. We are not looking to re-create other servers or other tools. We’re looking to demystify some of the more technical back end elements that keep people from creating…and do so without needing a small fortune to do so.
So, while StoryTeller is still in development, and rough…it’s stable enough that we are using it to create the Alpha world of Emerald Kingdom. That said, we also feel it’s stable enough to show people who are interested in what we are doing. While our developers are working on the Alpha client for the beginning of Alpha Testing….now is the time to give you a peek into our world.
See you there!
One year of the rollercoaster!
0Double Cluepon is one year old this month.
What better birthday present for a company than to learn that one development avenue which was originally closed off to us is now open. Apple recently announced that they are loosening the restrictions on development for the iPhone and the iPad.
What does this mean? Well, for us it means we can make stuff like WireWorks available on these platforms. That alone is great. I know I personally would love to see Emerald Kingdom on an iPad at some point.
Another great thing about being one year old is, we are actually still quite alive and kicking. Many businesses do not make it to the one year mark.
Aside from all that, we have been busy busy! We have recently added another artist, who is hard at work getting Twin Perennial into a working process for publication, among other things. We are also searching for a couple of new Developers, and hope to have that secured in the next couple of weeks.
Which will bring Double Cluepon to about 10 people. Not bad considering in the beginning, there were simply two.
Emerald Kingdom is slowly but surely approaching its Alpha point. That said, all of us here get more excited with every new build we see and play with. StoryTeller is coming along quite nicely, and the asset buildup is proceeding on schedule.
So, here’s to another year of fun. The next 12 months is going to be even more fun. Emerald Kingdom, and more quickplays are in the delivery chute. =)
Update with a side of Open Source Goodness.
0Wow, we have been away from our public lately. We’re sorry about that. All of us are working hard on getting Emerald Kingdom ready for Alpha and Beta. Not to mention, we have been busy preparing for the 3g Expo at Columbia College. We will be showing off a special version of WireWorks, as well as talking to young women in high school who are interested in games and game design. One of the things folks may not realize is that Double Cluepon has two women registered as owners!
Emerald Kingdom progresses. Samael has been a coding madman; StoryTeller now has the base sprite functions it needs, and Sandalphon, our Animation Director has been doing run/walk animations. Uriel, the Art Director has been cranking out Player Character parts, clothes, hair, eyes…she is also working her magic with monsters, Gremmies, buildings and tiles. StoryTeller is nearly to the fork point. When I say point: I mean the point at which we fork it off so that StoryTeller goes one way, and Emerald Kingdom (the client) goes the other.
All of which is great, but without a way to talk to a server and a database…would be pointless. When Raguel and I started looking at servers for Emerald Kingdom, we lamented that there were no free, or at the very least, solutions which were cheap enough for an underground game company like ours. The most widely known solution was expensive: $5000.00 USD just to get started.
We elected to write our own. To that end, Raguel has now finished the first version of our centerpiece for a true AS3/Flash socket server. We call it: SWFConduit.
Here is the official release statement:
—-
Announcing SwfConduit! An event-driven, bidirectional Flash socket server written in Python using Twisted and PyAMF.
- Python 2.6
- Twisted
- PyAMF 0.6 (available from http://pyamf.org)
- AMF3 (AMF0 does not support full object serialization)
- Flash clients require AS3 (AS1/2 do not support raw binary sockets)
- Content Encryption
- Rich set of default events
- Server and Session objects to cover common tasks
- More documentation on how to write clients
- Server Clusters
- Inter-server communications
- Connection negotiation (choose the least busy server to connect to)
- Swapping active sessions between servers in a cluster (each server can handle a geographic area in a game, spreading load while maintaining communications between friends)
- UDP support
- Speed at the expense of reliability
—-
And there you have it. SWFConduit is the centerpiece for Emerald Kingdom’s server, it’s support for modules means that the modules make the server. So, Raguel will be writing the modules for Emerald Kingdom to work with SWFConduit. The beauty of this is, SWFConduit is a bit like Zombo.com. You can do anything, anything at all with it. Write a module for a simple high score tracker database in SQL, or write a multiplayer server for a Flash game. THE ONLY LIMIT IS YOUR MIND.
It’s free, and licensed under the GPLv3. Which means, if you use it, or modify it….it gets better as we go along. You can get SWFConduit from github. Be sure to let us know if you use it!














