Re: [pygame] recommended reading for organizing code / project
Sean Wolfe wrote: > I'm looking for something to read about organizing one's code. I'm > working on a final fantasy-type game, and as the project gets more > complex I'm starting to think about best practices for development, > code patterns, code organization and project organization, etc. I'm > pretty much self taught on python and programming so I missed out on a > bunch of that I'm sure would be covered by say a CS degree. > > I know there are some great books out there, for example Code Patterns > and Antipatterns. I personally own 'Game Coding Complete' by Mike > McShaffry and I'm going to take another pass through that. > > Any recommendations? Anything that's particularly useful for game > development? Thanks!! The issue of code organization is one of the core challenges facing the modern programmer. Object Oriented Programming is a paradigm more or less explicitly dedicated to managing the level of complexity that a programmer has to understand to accomplish a discrete task. It does this by providing useful abstractions that allow large sections of the entire codebase to be understood at a level sufficient to work outside of them at a minimal cost to the programmer's brain. Modern applications (game and otherwise) are far too complex to hold in one's head all at once, no matter how able a programmer and designer one is. So I would answer that the first step in fixing your problem is working on your grasp of object-oriented design principles.
Re: [pygame] Scrolling background
Samuel Mankins wrote: > Forgive me if this is a trivial question. > What is the nicest way to go about having a background which moves at a > constant speed in one direction (as in a side-scrolling shooter)? Right now, > I draw all the sprites onto the background image, which is moving, and then > draw that onto the screen, but is there a neater way? You have a background that you want to scroll, so it's bigger than the screen, right? However it pleases you to do so, determine which subsection of the background you want to display that frame, then draw that onto the screen, then draw the sprites on top of that.
Re: [pygame] Creating sprites on the fly?
Julian Marchant wrote: > Hi, I'm somewhat new to Python and very new to Pygame, so please bear with > me if I sound like an idiot. > > Is it possible to create sprites on-the-fly? > > In my load image function, I would like to add an option to create a simple > back-up sprite (a black rectangle will suffice) on-the-fly if the requested > sprite is unavailable, to allow the game to still run. Couldn't you just load a black rectangle at startup and use that in place of whatever sprite failed to load?
Re: [pygame] Communicating with an event queue
Tyler Laing wrote: > For the movie module, I need to be able to communicate with a process > programmatically. > > The video player in discussion is ffplay(because its the smallest), and it > has an internal event loop around the SDL event loop. When I use > subprocess.Popen to open up the video player running a file, with the PIPE > arguments to all std*'s, only the window spawned responds to commands from > the keyboard, indicating that the event loop doesn't listen on stdin. > > Is there a way to cause events to be pushed onto the process's internal > event loop? I'm not sure what the question is? I may just be missing data due to unfamiliarity with the structure in question. Shouldn't you, as the developer, be able to insert a method into the movie subsystem wrapper object that takes a command and places it in queue to be processed by the subprocess' loop?
Re: [pygame] GSoC Proposal: Basic gui system
Frozenball wrote: > Yes, a good GUI module included by default sounds nice. I have used > Ocempgui but it was too slow for my purposes. I went back to school for my degree, so I haven't had time to pursue game programming (as opposed to homework programming >_< ). But in my idle times, I've thought about using one of the established Python gui toolkits in combination with pygame/SDL. I mean, if one is going to want to avoid reinventing the wheel, let's just do it and use TkInter or WxPython or whatever? This theory was assuming that I could implement an extension of a basic GUI panel widget from whatever library I was using that would just take a surface and display it. Then I could have all the buttons and charts and widgets I wanted, with the layering and click handling all done for me. And my game programming would be limited to rendering and game engine. Which would be nifty.
Re: [pygame] Pathfinding
> it seems to me that A* only works on tile-based games. > What if my game isn't tile-based? A* works on 'nodes', where a node is just some location defined in the game space. Tile-based games have a very obvious node structure to them, and so A* is very easily adapted to them. But, really, there's not necessarily a lot of difference between applying A* to a tile-based game on the one hand and a network of location-nodes in a 3d space on the other.
Re: [pygame] Help Starting/doing The Main Code
Guilherme Seilá <[EMAIL PROTECTED]>: > Just a player that has animation frames, can jump, walk, shoot a > projectil... I need enemies that are static and dynamic too, and if not too > hard, that can shoot at you. > Also, a demo would be good to learn from... Well, as an abstract matter, while there is a big difference between projectiles and enemies from the player's perspective, they are really very similar things on an abstract level. They are graphic objects that moves (or don't) and when they touch the player, the player takes damage. Player projectiles would operate in the same way. So theoretically, any platform game that has collision detection leading to mobile object interactions (damage dealing or whatever) could have a range of projectiles added to it fairly straightforwardly.
Re: [pygame] I'm loving wills book :)
Wayne Koorts <[EMAIL PROTECTED]> wrote: > > I'm having a friend convert it to chm because pdf is slow:(, my friend > > bought me the ebook version off apress, > Probably much less trouble to just get a better PDF reader. "PDF" > itself isn't necessarily slow, it's just a file format. If you use > Windows I can recommend Sumatra: > http://blog.kowalczyk.info/software/sumatrapdf/\ FoxIt is also about a million times faster than Adobe's bloatware.
