Re: Multiplayer capability
On Jun 30, 4:17 am, "Drew Smathers" <[EMAIL PROTECTED]> wrote:
>
> Personally, I find Twisted *far* easier than working directly with
> sockets - but of course, many people will reply telling you otherwise.
> You might also consider looking at something like eventlet
> (http://wiki.secondlife.com/wiki/Eventlet), [...]
Sounds interesting, only I can't make heads or tails of the
documentation. It probably doesn't help that I've never done anything
with threads or stackless python. Tbh I probably should pick up the
basic, socket-type stuff before jumping into all these abstractions.
Twisted at least sounds like it could do anything I could possilby
want.
On Jun 30, 8:47 am, "John Lehmann" <[EMAIL PROTECTED]> wrote:
> Or you could try something like pyro
> (http://pyro.sourceforge.net/index.html) if you were after something
> even more abstract and didn't feel that networking was likely to be a
> performance critical part of your application
Now there's something... I like the idea of calling methods on local
proxies that affect remote objects. That pretty much gets rid of
networking altogether, doesn't it? =D I don't think I'll be too
worried about performance, although it'd be nice to go with a method
that has the best mix of simplicity, flexibility and speed, since I
don't know any of them yet. Of course that also means I don't know how
simple, flexible or fast they are.
> Out of interest, what would you have in mind when you sat
> "multiplayer" module? What kind of functionality would you imagine?
I tend to imagine things as ideals, so this may well be not even
remotely possible. I hadn't actually thought about it, but now that I
have a little it would be like a pyglet.app.mp_run() kind of loop (or
just a flag to turn MP functionailty on in the run() loop). There's
some little call you can make where you enter another (or multiple) IP
address(es) and when you both connect to each other (this would of
course be something impossibly simple like
pyglet.multi.connect('IP')), I guess you could specify some variables/
classes that are 'linked' - they'd be like PYRO's proxies, hosted on
the server but able to modified by the client. Any changes the host or
client makes to these is updated in the mp_run() loop.
This would all be like a basic game-multiplayer setup - think good old
RA1: you click the connect button, they click receive, you both
connect, and off you go. If you imagine multiplayer Pacman with 1
different player as each entity (5 players), just be flagging the
pacman and 4 ghosty things as linked, along with a list containing the
states of each little dot, they would update each frame, the same for
both players. The local stuff like the background and score would be
updated and redrawn, then the states of the linked objects would be
requested, received, updated locally, and redrawn. All this would
happen in the mp_run() loop, I guess with some kind of scheduler.
I can always dream ... :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to pyglet-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~--~~~~--~~--~--~---
Re: pyglet , new user
Thanks Drew, Yes, it requires pyglet version 1.1. Thanks, Keivn On Jun 28, 8:19 am, "Drew Smathers" <[EMAIL PROTECTED]> wrote: > On Sat, Jun 28, 2008 at 7:43 AM, [EMAIL PROTECTED] > > > > <[EMAIL PROTECTED]> wrote: > > > Hi ! > > I'm new user for pyglet. > > I have one error , when i run Heffalump.py: > > " > > python Heff*.py > > Traceback (most recent call last): > > File "Heffalump.py", line 49, in > > from pyglet import graphics > > ImportError: cannot import name graphics > > " > > The pyglet working on my system , see: > > " > > Python 2.5.2 (r252:60911, May 28 2008, 08:35:32) > > [GCC 4.2.4 (Debian 4.2.4-1)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > import pyglet > from pyglet import * > dir(pyglet) > > ['__builtins__', '__doc__', '__docformat__', '__file__', '__name__', > > '__path__', '__version__', '_enable_optimisations', '_option_types', > > '_read_environment', '_require_ctypes_version', 'options', 'os', > > 'sys', 'version'] > print pyglet.version > > 1.0 > > " > > You need version 1.1 > > -- > \/\"/\\\ > / // //\/\\\ > \\\/ \\// /\ \/ > \\/ /\/ / /\/ /\ \\\ > \/ / /\/ /\ /\\\ \\ > / /\\\ /\\\ \/\ > \/\/\/\\ > d.p.s --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
Re: Multiplayer capability
Or you could try something like pyro (http://pyro.sourceforge.net/index.html) if you were after something even more abstract and didn't feel that networking was likely to be a performance critical part of your application (c.f. http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing) (not that pyro is known to be a poor performer per se, but just that using an abstraction layer will make it more difficult when you find you need to get your hands dirty). Out of interest, what would you have in mind when you sat "multiplayer" module? What kind of functionality would you imagine? John --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
Re: Multiplayer capability
On Sun, Jun 29, 2008 at 2:29 AM, Pie21 <[EMAIL PROTECTED]> wrote: > Thanks Drew. I was hoping pyglet had something I'd missed, but I guess > it makes sense that it wouldn't. I've had a read about the socket > module and it doesn't actually look too difficult. Still, a > 'multiplayer' module would have been awfully nice =P This seems kind of arbitrary to me. Networking is a separate problem domain. > So, would 'socket' be an obvious choice for this kind of task > (basically sending player states back and forth)? Or if you had to > design a (synchronous) multiplayer game, would you go for something > else? I read a little about Twisted but it all sounded very... > advanced for what I'd need. Hehe. Well you're definitely asking the wrong person then ;) Personally, I find Twisted *far* easier than working directly with sockets - but of course, many people will reply telling you otherwise. You might also consider looking at something like eventlet (http://wiki.secondlife.com/wiki/Eventlet), which purportedly "achieves high scalability by using non-blocking io while at the same time retaining high programmer usability by using coroutines to make the non-blocking io operations appear blocking at the source code level." -- \/\"/\\\ / // //\/\\\ \\\/ \\// /\ \/ \\/ /\/ / /\/ /\ \\\ \/ / /\/ /\ /\\\ \\ / /\\\ /\\\ \/\ \/\/\/\\ d.p.s --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
Re: Pyglet, Sockets and Threads
I'd like to second the request for a small tutorial about integrating pyglet with stackless. It would be great to hear your experiences trying to integrate the two, and any pitfalls that may arise. Thanks. Naveen On May 28, 9:58 pm, "Adam Bark" <[EMAIL PROTECTED]> wrote: > 2008/5/29 Alex Holkner <[EMAIL PROTECTED]>: > > > > > On 5/29/08, Javier Garcia <[EMAIL PROTECTED]> wrote: > > > Offtopic: > > > > May I suggest a pair of tutorials > > > > 1. Using pyglet with stackless , like the Actor tutorial which uses > > > pygame, simplified if its possible > > > I've not played with stackless before, but I understand it's an > > experimental patch only, so a tutorial for using it with pyglet is not > > really appropriate (of course, please supply and publish your own!). > > Just thought I'd say stackless is a fork of python but is extremely stable > and is used in EVE online for one. Also I currently use pyglet in stackless > and it works perfectly. The code is all main branch python apart from > a few things rejigged and inserted to allow tasklets and channels etc. > Anyway just thought I'd throw in that opinion, I could possibly look at > writing a tutorial if there's enough interest. > > Adam. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
Re: 1.1 release date?
ok, thanks for the explanation! enrike Alex Holkner(e)k dio: > On Sat, Jun 28, 2008 at 4:30 PM, altern <[EMAIL PROTECTED]> wrote: >> hi again >> >> been reading the 1.1 documentation and new features, sounds quite nice. >> Any estimations on when would it be ready for development? i read its >> still unstable. > > 1.1 has been in Beta for a few months now. In pyglet parlance, a Beta > release has a (near) guarantee of API stability, and so is "safe" for > development. API changes are made only if they are needed to avert > major design catastrophes. > > The Beta release has not been tested enough among various hardware > configurations; and there are known issues with certain video cards > that have not yet been resolved (see the issue tracker). There's a > long Beta period to enable more hardware testing by users such as > yourself. > > I don't estimate release dates, as pyglet fits into my spare time > only, which I seem to have been lacking recently ;-). > > In short; if you're doing development with a non-immediate need to > release software to end users, use pyglet 1.1. Even if you decide to > develop against pyglet 1.0, you should be periodically testing your > code base against 1.1 to check for backward-compatibility errors > (pyglet 1.1 is fully backward compatible with pyglet 1.0). > > Cheers > Alex. > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
Re: 1.1 release date?
On Sat, Jun 28, 2008 at 4:30 PM, altern <[EMAIL PROTECTED]> wrote: > > hi again > > been reading the 1.1 documentation and new features, sounds quite nice. > Any estimations on when would it be ready for development? i read its > still unstable. 1.1 has been in Beta for a few months now. In pyglet parlance, a Beta release has a (near) guarantee of API stability, and so is "safe" for development. API changes are made only if they are needed to avert major design catastrophes. The Beta release has not been tested enough among various hardware configurations; and there are known issues with certain video cards that have not yet been resolved (see the issue tracker). There's a long Beta period to enable more hardware testing by users such as yourself. I don't estimate release dates, as pyglet fits into my spare time only, which I seem to have been lacking recently ;-). In short; if you're doing development with a non-immediate need to release software to end users, use pyglet 1.1. Even if you decide to develop against pyglet 1.0, you should be periodically testing your code base against 1.1 to check for backward-compatibility errors (pyglet 1.1 is fully backward compatible with pyglet 1.0). Cheers Alex. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~--~~~~--~~--~--~---
