Previous Blog Next Blog
Prev/Next Blog
by date

PyTNL

PyTNL
Name:Prairie Games
Date Posted:Aug 01, 2006
Rating:4.5 out of 5
Public:YES
Comments:YES
RSS Feed:GarageGames Blog feedor Subscribe with .
Profile Page:View profile page for Prairie Games

Blog post
I've been working on Python bindings for the Torque Network Library and also integrating it with the very powerful Twisted Framework.

The Twisted Framework is a major reason why MoM 's server architecture was possible for one programmer to write (and rewrite)... it's blazing fast to code client/server logic with it. I have found the Deferred Class to be especially useful.

What I'm looking for with PyTNL is reliable/unreliable UDP, ghosting, and raw performance combined with the rapid development of Python and Twisted. So far, the marriage is a happy one :) PyTNL is a component in our next generation of technology, Mythos. It's also possible that it will replace some networking code in Minions of Mirth.

Awesome work on TNL guys... it rules!

Here's some sample PyTNL code. Python can really save you a lot of typing :)


#PyTNL - Python Bindings for Torque Network Library (with a dash of the Twisted Framework)
from pytnl import NetConnection,NetInterface

#A role defines the what a given user can do based on authorization
#We have fine control of which methods can be invoked remotely with a quick (and powerful)
#naming convention. Notice that we're able to subclass from TNL's NetConnection class here
#(we actually use GhostConnection behind the scenes)
class PlayerRole(NetConnection):

#we can remotely invoke methods that begin with remote_!!!
def remote_shootGun(self):
print "bang!"
return 42

#this method cannot be called remotely!

def cannotBeCalledRemotely(self):
x = 1

#A client once again subclassed

class MyClient(NetConnection):

#this function gets called upon successful authorization on the server[/b]
def loggedIn(self):
#We're logged in and can now call remote methods and do other interesting things
#remote calls return something called a deferred
d = self.callRemote("shootGun")
#we can register any number of callbacks to occur once the function has completed and
#returned a value from the server
#the really powerful thing about this is that we don't need to closely couple
#client and server logic!
d.addCallback(self.gotResult)

def gotResult(self,result):

#this will print 42, see the remote_shootGun method up in the PlayerRole class
print "The result is, of course:",result


#Create a server listening on 25001
server = MyServer(25001)
#Add the Player role to the server
server.addRole("Player",PlayerRole)
#Add Josh user with password "Mythos"
server.addUser("Josh","Mythos")
#Allow Josh to connect as a Player
server.grantUserRole("Josh","Player")

#Create a client
client = MyClient()
#Connect with username,password,role, and address (it would be trivial to encrypt the user/pass)
client.connect("Josh","Mythos","Player","ip:127.0.0.1:25001")

#Go!
while True:
server.tick()
client.tick()


-Josh Ritter
President
Prairie Games, Inc

Recent Blog Posts
List:03/29/08 - TGEA 1.7 Build System and Embedded Python
03/14/08 - MegaTerrains - TGEA Update
01/18/08 - Minions of Mirth: Undead Wars Expansion
01/04/08 - Physics Overhaul - Video
12/26/07 - Web Integration - Video
12/21/07 - New MMO Client - Trees - Day/Night Video
12/18/07 - Minions of Mirth - 1.26 - Holiday Edition!
11/28/07 - TGB/TGEA integration first pass

Submit ResourceSubmit your own resources!

Randel Reiss   (Aug 01, 2006 at 13:58 GMT)
u da man

Phil Carlisle   (Aug 01, 2006 at 14:49 GMT)
I like the idea, I just hate python.

I've been looking at Ice as a similar sort of glue.

In the end, I think we're likely to be looking at a mixture of ICE, Java (possibly JSP) and some other client end code.

There are a lot of things to help you out there, you just have to be open to using them. I just wish I actually liked Python enough to try this stuff.

James Urquhart   (Aug 01, 2006 at 16:57 GMT)   Resource Rating: 3
Interesting project - looks like it would be quick and easy to develop with (well, if you knew python of course).
The only thing i'd worry about is the overhead in having most of your logic, as well as the tick calls, in python.

Still, keep up the good work! :)

Prairie Games   (Aug 01, 2006 at 18:16 GMT)
@Phil: Hey, so let me get this straight you don't like Python and you don't like RPG? But you do like saying that you don't like Python and don't like RPG in my .plans? ;) I have looked at ICE and couldn't really see us using it. I've also never been a fan of companies who require you to "contact us to discuss licensing fees". TNL is really, really nice and relatively small... and it's made by GG.

@James: EVE Online and MoM are both primarily written in Python.

Premature optimization is the devil and is one of the reasons why so many projects never get done or take forever to complete. Make it fast, make it fun, and then optimize it. Also, Programmer Time is often much more important than CPU Time.... I couldn't care less if most of the functions execute in .001 seconds versus .0001, they aren't called frequently enough to make an ounce of difference. What I do care about is that it takes me 1 minute vs 10 minutes to write a debug these functions. That's why I like Python, it's amazingly fast to code in.

If you're talking about performance it's mostly about distributed server design, which I was just able to introduce to MoM. I couldn't have totally changed the server layout had it been written in C++. It would have taken too long, been far too error prone, and would have had a premptive testing period.
Edited on Aug 01, 2006 18:35 GMT

Brian Jones   (Aug 02, 2006 at 04:26 GMT)
Very cool stuff Josh, I've really enjoyed following your progress all these years.

Slightly off topic, but I finally got your pytse code running under OSX, and have been breaking out the client and server into different programs while eliminating all the TorqueScript. Yesterday I decided to see how things would work building against Stackless, but have run into some problems (OSX specific in regards to loading a dynlib, might be an easy fix).

Seeing the fact that you have created PyTNL, it seems to simplify a lot of issues. One of the things that was bugging me about running the server with the torque engine code was all the useless graphics, audio, and whanot code also built into it. I'm tempted to try and follow in your footsteps, now that I've learned a few things from your previous efforts :)

Johan Carlsson   (Aug 02, 2006 at 06:58 GMT)   Resource Rating: 5
Hi Josh,
A PyTNL has definitely been on my wish list for a while, so thanks for the work you do and that you publish your stuff :-)

The example above shows RPCs, but will PyTNL be able to do other things like networking objects?
(Im not totally sure what I'm asking for here so please be gentle :-)

Regards,
Johan

Prairie Games   (Aug 02, 2006 at 07:42 GMT)
Hey guys...

Yup, NetObjects and Ghosting will be supported. You'll be able to use PyTNL under the terms of the GPL or if you purchase a license of TNL from GG, you can use it under that license :)

-JR

Johan Carlsson   (Aug 02, 2006 at 09:28 GMT)   Resource Rating: 5
Smashing :-)

I'm pondering, if I own Torque (as one does) is that license enough to use TNL in a commercial app?

Johan Carlsson   (Dec 30, 2006 at 15:28 GMT)   Resource Rating: 5
Hi Josh,
What's the status of PyTNL?

You must be a member and be logged in to either append comments or rate this resource.