One little thing; as far as item 9. goes, this might be implied, but it would be great if it was set up to easily handle subsurfaces (ie spritesheets) as well as individual images.
On Sat, Jun 2, 2012 at 1:08 PM, Sagie Maoz <sa...@maoz.info> wrote: > Hi all, > > Thanks so much for all of the comments and suggestions. This is extremely > helpful for my project at this stage. > > I admit I'm not too educated about the whole subject, so let me know if > any of my answers below need further research in your opinion. > > Regarding adding GUI elements (David's suggestion) - I can see how > important that would be, but I'd like to focus on basic game graphics for > now. Also, there's another GSoC project by Sam Bull that approaches a GUI > framework for Pygame. > > As for collision detection (Nicholas' and DR0ID's emails): I agree with > DR0ID's concerns about maintaining a clear scope for the project, and I can > understand that collisions are more the engine's job than the sprite > classes. However, as the current Sprite module includes many of the > functions related to that, I thought I could get into that as part of my > work. > I'm guessing that implementing a basic and naive code wouldn't be too > hard, but the question remains would doing that be an elegant design. > I want to research how this kind of features is done on similar libraries. > I would also love to get your thoughts on that. So this is still an open > question for now. > > Aggregated sprites: I think the use case DR0ID has mentioned is good > enough for implementing that. I'm thinking about writing the aliens.py game > so that the aliens are a group of sprites moving together, while each one > could have a different behavior when needed. > > Dirty rendering: Again, this doesn't seem to me as something that's too > difficult to implement, and would definitely help any non-scrolling game, > which I think is a pretty solid use case. > > I gather that the most requested features are probably: > > 1. Better positioning, particularly using float values. > 2. Anchor points. > 3. Visual attributes. > 4. A smarter layers system. > 5. Sprite picking. > > I will research each of these during the week. > > If you have any more comments or additions please do reply to this thread. > I'll also be idling in #pygame most of the time and would love to chat. > > DR0ID - I'll be happy to set a time to chat and learn more about all of > your suggestions. > > Thanks again, > > -- > Your friend in time, > Sagie Maoz > sa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339 > http://sagie.maoz.info/ http://n0nick.net/ > > /* simba says roar! */ > > On Saturday, June 2, 2012 at 5:46 PM, Christopher Night wrote: > > On Fri, Jun 1, 2012 at 2:29 PM, DR0ID <dr...@bluewin.ch> wrote: > > On 01.06.2012 15:29, Sagie Maoz wrote: > > 2. Setting a sprite's anchor points for handling in movement, animation, > collision etc. > 5. New visual attributes for sprites: > - Rotation angle > - Scale > > 2. the sprites anchor point should be just an offset, not limited to > 'topleft', 'midtop', 'topright',... and the other rect attributes > > > I want to be able to specify "center" or "midbottom" for the sprite anchor > without knowing the image's dimensions. And I want that anchor point to > remain in the appropriate place even if the image is rotated, scaled, or > flipped. I'm not sure that an offset would accomplish this, but if so, then > that's okay. > > -Christopher > > >
