[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pygame] Hi, I'm new...
> > I've been told to develop a game, and have been given very detailed
> > specs. My first inclination was to do it with tkinter, as I had done
> > all my previous python games.
>
> well i would definitely promote using pygame. the one advantage
> tkinter has is the nice widgets. in pygame its easy enough to do
> pushbuttons and simple things, but to do more complex controls
> like listboxes, sliders, dropdown submenus, you'll need to implement
> those by yourself.
>
Nothing I didn't expect :) I've implemented them before, and in much
nastier languages than python :)
> there is a project named pyui which offers some of these controls
> under pygame, but it may be a little work to get it working smoothly
> inside your own game engine.
>
Hmm I did see that, I'll be sure to check it out.
>
> > The first thing I'll need is a relatively big
> > resolution, say eg 1024x768. Also, the main area where all the
> > action takes place would be lovely as a changeable camera angle
> > in a 3d world - but I think I'm dreaming there. I'll probably
> > end up with something ala Diablo I&II. If I did have the time,
> > could I develop a 3d engine for pygame? Or (even better) is
> > there one already available?
>
> here's my honest opinion. SDL is an awesome tool for working with
> 2d software surfaces and effects. it also is unbeatable for getting
> raw access to hardware framebuffers. the one thing it doesn't give
> you is a lot of fine control over hardware surfaces. this is because
> it must generalize the hardware devices across many architectures
> and drivers.
>
> to get a full animated screen at 1024 resolution can really only
> be done with hardware support or hand-crafted assembly.
*ugh* /me dislikes assembly
> this is
> going to be really hard to do in pygame, but could be doable with
> a small amount of C extension modules to handle the intensive parts
> of the render.
>
Hmm well then I'll have to dirty my hands with C again :) Although I will
try to avoid it...obviously I'll have easy-to-fix bottlenecks in my code
simply because I'm a green newbie w/r to pygame - once I get it going though
it should be simple enough to implement some of the game into good ol' C.
> as for 3d, there is full support for pyopengl, which works nearly
> as well as using straight 3d with opengl. both c and python can
> feed buffers of data to opengl at comparable speeds. unfortunately
> a state of the art game engine won't be that simple. you'll need
> to get into things like bsp trees, portals, raycasting, collisions.
> those types of things are much better handled in C than in python.
> the good news would be that, again, it is straightforward and easy
> to create C functions that are called from python code.
>
Well, as I said in my other mail, I've decided to not go with the whole 3d
engine idea - I figure that first I should become proficient with pygame,
and second I should do it as a more personal project where I have much more
time :)
> there's my opinion about where things are. it seems to me like
> your going to need to get some C code in there to support the
> graphics requirements. if you lock your code into using hardware
> support for blitting you can likely get the 2d rendering speed
> you will need.
>
Good good, that's good news - speed is very important :)
>
>
> > I have plenty of other questions, but I'm almost 90% sure they
> > can be done so I'll just ask this one - how well does pygame support
> > threads? One major problem with tkinter is the fact that you can't
> > have threaded operations which all update the GUI - tcl crashes,
> > every time. And the workaround is not pretty.
>
> SDL does a good job at being threadsafe in all the event handling,
> music processing, and timers. it does not offer any sort of thread
> safety on the display and surfaces (mainly because there is not a
> single way to handle that, so it leaves it up to the game).
>
> pygame does a good job at maintaining the thread safety of SDL,
> so you shouldn't have a problem with that.
>
> as for the graphics, it is generally a good idea to have only a
> single rendering thread. only one thread should have access to
> the graphics. if you really want each thread to be able to handle
> its own rendering, make simple use of a semaphore or mutex to
> make sure only one thread is rendering at a time.
>
Hmmm I'm left thinking do I really need more than say 2 threads? Like one
for 'object' animation (warriors, monsters, etc) and another for ui
animation, which will probably handle alot of the output to the user.
> for a small example of pygame threading, you can look at my
> solarwolf game. it loads all the game images and sounds on a
> background thread while the main thread animates the starfield
> and draws a progress slider. the same thing happens as the game
> downloads news information from the internet. the http is handled
> in a background thread, while the main thread keeps the game running.
> this worked very well for me, but i spent a bit of work making
> certain the image loading didn't cause any problems with the main
> graphics thread. it was a bit more work than i would have liked.
>
I did try to download the Solar Wolf game because it looked like a good
example of a pygame game, and I had heard good things about it - however,
the link was broken. Is this fixed now?
Do you think it would be more or less work to implement a multi-threaded
or a minimal-threaded model? From my experience threads do create alot of
hassles, although they also solve problems nicely.
>
>
> > Say eg that 4 warriors were standing in a dungeon room. I
> > would like them all to be doing something each - breathing,
> > reading a scroll, playing with magic in the air, practising
> > swings etc. My solution would be to use a seperate thread
> > for each warrior - would this work in pygame, and if not how
> > would you approach it?
>
> i don't know of any games that really handle game objects on
> their own thread. the standard method is each object (or warrior)
> has a function that is supposed to run in a small timeslice.
> basically the function updates what variables it needs to and
> returns quickly. the main gameloop then calls this function
> for all objects in the game, and then renders all the objects.
> if one of these functions takes too long, the game appears to
> lockup briefly while that object makes its calculations.
>
> giving each object its own thread solves the problem of each
> object 'hogging' the timeslices, but introduces a ton of
> synchronization issues. for example, what if one of the warrior
> threads is in a small animation loop like this...
>
> for step in self.path:
> self.walk_to(step)
>
> this simple loop just animates the character to a list of
> positions. but what if some other warrior thread kills this
> walking warrior halfway through his path? how do you switch
> the walking warrior to his dying animation? you need to have
> one warrior thread break the walking warrior thread out of
> its walking loop and start a different loop.
>
> this becomes an absolute nightmare, and just doesn't work.
> using threads for all the objects gets too out of control.
> going with the timeslice functions ends up working out much
> better once you have it implemented.
>
You know, I've never used this timeslice thing before. It probably sounds
crazy, but I haven't - and I have done several games. I've always just done
workarounds. But, reading what follows...I believe the timeslicing method
is much much better :)
> basically each warrior becomes a "state machine". which
> basically means a big sack of variables that describes
> everything about the object. it is easy to create a single
> function that quickly looks at this state machine, updates
> a few of the variables, then returns. it doesn't need to
> worry at all about rendering the warrior, just updating
> the state of the warrior. for example, the function may
> work something like this...
>
>
> def warrior_timeslice(self):
> if self.mode == WALKING:
> self.direction = self.target - self.position
> self.direction.adjust(self.speed)
> self.walkframe += 1
> self.image = self.images['walking'][self.walkframe]
> if self.position == self.target:
> self.warrior_startbreathing()
> elif self.mode == BREATHING:
> self.breathframe += 1
> self.image = self.images['breath'][self.breathframe]
>
> def warrior_walkto(self, position)
> self.walkframe = 0
> self.target = position
> self.mode = WALKING
>
> def warrior_startbreathing(self)
> self.breathframe = 1
> self.mode = BREATHING
>
>
> hopefully this crude little example shows what i mean. this is
> the method used to handle pretty much every game out there. the
> game simply calls warrior_timeslice() once per frame. the game
> then renderer can simply draw each object using a predetermined
> method. in this example here it would likely look at the warriors
> "image" and "position" variables to blit an image on the screen.
>
>
> whew, this got long. hopefully it all wasn't too obvious. if you
> end up going with pygame, you can always get help form here while
> getting up to speed. :]
>
After reading this and other posts, I will go with pygame. Don't expect
me to be silent though, I'll probably be asking silly questions for quite
some time yet :)
Also, this game which I(+team) am developing will be turn-based, not
realtime. I imagine this is a great boon to me being the main programmer.
Being turn-based, I imagine the various complexities of the graphical
representation and speed are much simpler - right?
Hmmm, thinking about this isometric diablo-esque engine, would I treat
this as a whole bunch of cells that are basically squashed-diamond in shape?
Scrolling...that could be processor-intensive. Perhaps it should
jump-scroll, instead of smooth scroll. Hmmm.
Thoughts?
Thanks alot guys,
Glen.
____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org