Comments on: Blender Game networking test

By: mikepan

mikepan — Fri, 07 Aug 2009 05:12:27 +0000

yeah well, ‘hacking’ is certainly possible given how primitive my approach is. Although I could just release the compiled python file and never show anyone the source code. Disassembling a pyc file might still be possible(is it?), but at least it’s security through obscurity. I learned that last bit from Microsoft :D

By: AniCator

AniCator — Wed, 05 Aug 2009 13:55:08 +0000

Your P2P approach sounds very interesting. I’d love to mess with your game’s scripts when it’s released. :P
Change the way it parses the data.
Then play with a friend and beat the crap out of him.

By: mikepan

mikepan — Thu, 23 Jul 2009 07:24:02 +0000

I have the source code here: http://blenderartists.org/forum/showthread.php?t=161961

A server-client approach is even easier, i think. And moving data seems easy enough, cPickle can serialize any object into strings, but is a bit too bloated since it packs in a lot of ‘useless’ structural stuff. For what I am planning to do, I will manually concatenate everything into a single string and parse it on the other side, error prone, maybe. But a lot less data.

By: Dalai

Dalai — Wed, 22 Jul 2009 02:03:32 +0000

Nice implementation. I would like to see the files later, to try to make a more server-client solution. (smart server – dumb clients)

A thought on multiple displays with network (or how I’m planning to use it :) ):

We could have a camera in the server with an empty parented to the camera (+ copy locrot constraint). This would be the server

In the client we take the original camera and move/rotate according to the display, parent the camera to the empty and sync the empty with the server. That would be a dumb camera.

I think that could be used to for panoramic/cylindrical surfaces or multiple projector domes.

It made me think (:

Best regards,
Dalai