Re: [pygame] GSoC: Improved Sprite and scene system
On Thu, Mar 19, 2009 at 10:39:23PM -0300, Erisvaldo Junior wrote: Hi Peter, Thanks for your feedback. I'll add the collision improvements in my proposal. Do you people agree that Sprites should be removed from Pygame? Absolutely not! That would totally break a large number of older pygame games if one tried to run them with a newer spriteless version of pygame. --- James Paige
[pygame] gsoc idea sqlite db for pygame
I have an idea for a proposal for gsoc.My interest in game development is with games with deep datasets(RPG,strategy games,etc)These projects tend to be intensive, which is why I haven't posted a game project myself (yet). One of the major problems I have encountered in development is an effective way of dealing with the massive amounts of data these games need.When you need to deal with, in a RPG for instance, player and npc hitpoints, experience points, items etc, handling all the data can get difficult. While looking for a solution to this data situation, I recently started experimenting with the pySqlite wrapper for the sqlite databases.It has some good qualities that could be useful in Pygame.Its relatively small.It's serverless, so problems with setting up a server and client system would be mitigated.The pySqlite wrapper around Sqlite is solid, and full-featured. A class could be built around pySqlite to help abstract some of the data,so you wouldn't necessarily have to know SQL to add and retrieve data from the database(i've built a module to do that already). I'm interested if anyone thinks this would be a good addition to Pygame, and whether this would a good GSoc project. Thanks John Robinson
[pygame] GSoC Proposal: Basic gui system
Hi, I would really like to have a pygame.gui module. Many/all pygame programs need to have a user interface and often it's more than two buttons. Thats always the same and why always reinvent the wheel? There are some pygame guis but I neither like dependences nor I want to redistribute external modules. In addition, I haven't yet found the ultimate pygame gui (if there is one, include that). So, I think it would be cool to have a well thought out, easy extensible gui system within pygame including some basic elements like button, label, entry, etc. and a kind of geometry manager. Of course you can write that yourself every time you need it but (i think) its not fun but only waste of time. Regards Jug
Re: [pygame] GSoC Proposal: Basic gui system
On Sat, Mar 21, 2009 at 1:39 PM, Jug j...@fantasymail.de wrote: Hi, I would really like to have a pygame.gui module. Many/all pygame programs need to have a user interface and often it's more than two buttons. Thats always the same and why always reinvent the wheel? There are some pygame guis but I neither like dependences nor I want to redistribute external modules. In addition, I haven't yet found the ultimate pygame gui (if there is one, include that). So, I think it would be cool to have a well thought out, easy extensible gui system within pygame including some basic elements like button, label, entry, etc. and a kind of geometry manager. Of course you can write that yourself every time you need it but (i think) its not fun but only waste of time. Regards Jug Yes, a good GUI module included by default sounds nice. I have used Ocempgui but it was too slow for my purposes.
Re: [pygame] GSoC Proposal: Basic gui system
On, Sat Mar 21, 2009, Jug wrote: Hi, I would really like to have a pygame.gui module. Many/all pygame programs need to have a user interface and often it's more than two buttons. Thats always the same and why always reinvent the wheel? There are some pygame guis but I neither like dependences nor I want to redistribute external modules. In addition, I haven't yet found the ultimate pygame gui (if there is one, include that). Which is why a GUI backend within pygame was never realised. There is no ultimate design approach and having just a bunch of abstract base classes for users to implement is not worth the work :-). So, I think it would be cool to have a well thought out, easy extensible gui system within pygame including some basic elements like button, label, entry, etc. and a kind of geometry manager. If you can find some good reasons, why that system would be better, easier and more extensible than all the solutions available, go ahead. Be aware however, that this will probably cause a lot of discussion about the pros and cons. Regards Marcus pgppnuV8p77ZX.pgp Description: PGP signature
[pygame] Searching for a mentor
Hello all! Firstly, let me introduce myself - my name is Ivan Popov and I am a PhD student in Bioinformatics. However, I have the hobby of writing Python programs and as a home project I have created my own RLRPG. You can find some information about it on http://artisan.hit.bg. I'd like to enter the Google Summer of Code as a student with one of the Pygame projects. Unfortunately the project in question - Improved sprite and scene system still doesn't have a mentor assigned. Thus I am writing to ask if there is anyone willing to be my mentor for the project. I haven't used any graphics in a game, so it will be interesting to do. Conversely, if no mentor is available, I'd like to work on the pgreloaded example suite. I'll be happy to study pgreloaded and build a set of helpful examples. I am very comfortable with writing Python code, and have some experience in C++. I am looking forward to hearing any suggestions and advice and working in the Pygame community! Ivan
Re: [pygame] Re: a gsoc idea: networking
You need a centralized server ... even if all it does is provide the addresses of several hosts. How else would you find even one host? On Thu, Mar 19, 2009 at 7:27 PM, Michael George mdgeo...@cs.cornell.edu wrote: Tyler Laing wrote: Haha, point taken. Sorry about that. As a student, I think that one or the other would make a good project, as both would be too much work. -Tyler I totally agree. --Mike
Re: [pygame] gsoc idea sqlite db for pygame
On, Sat Mar 21, 2009, John Robinson wrote: I have an idea for a proposal for gsoc.My interest in game development is with games with deep datasets(RPG,strategy games,etc)These projects tend to be intensive, which is why I haven't posted a game project myself (yet). One of the major problems I have encountered in development is an effective way of dealing with the massive amounts of data these games need.When you need to deal with, in a RPG for instance, player and npc hitpoints, experience points, items etc, handling all the data can get difficult. Massive amounts of data to deal with means usually to deal with them fast. This in turn means to have fast data request handlers, low response times and so on. While looking for a solution to this data situation, I recently started experimenting with the pySqlite wrapper for the sqlite databases.It has some good qualities that could be useful in Pygame.Its relatively small.It's serverless, so problems with setting up a server and client system would be mitigated.The pySqlite wrapper around Sqlite is solid, and full-featured. A class could be built around pySqlite to help abstract some of the data,so you wouldn't necessarily have to know SQL to add and retrieve data from the database(i've built a module to do that already). I'm interested if anyone thinks this would be a good addition to Pygame, and whether this would a good GSoc project. Data storage layers of that kind lack two things: a useful reason about why that should take three full months of development and not just a week and how to keep them reasonably fast for situations where a database keeping lots of information is needed. If I have 5 different tables (let's say n:m and 1:n relations), keeping queries over all or a combination of a few of them fast enough is mostly done by performant, optimised queries on filtered and joined subsets. How would such situations be realised by that abstraction layer you think about? What other features except for hiding SQL would the layer offer? Regards Marcus pgpD1ObRhIuHl.pgp Description: PGP signature
[pygame] Re: GSoC Proposal: Basic gui system
On 21 Mrz., 16:48, Marcus von Appen m...@sysfault.org wrote: Which is why a GUI backend within pygame was never realised. There is no ultimate design approach and having just a bunch of abstract base classes for users to implement is not worth the work :-). Then it should be a GSoC task to search for it. Surely the existing GUIs (or some of them) are not completely useless, but some are not supported/developed any longer, some are in an pre-alpha stadium, some work fine but have defects in their concept so that extending/writing own widgets is very difficult. If you can find some good reasons, why that system would be better, easier and more extensible than all the solutions available, go ahead. Be aware however, that this will probably cause a lot of discussion about the pros and cons. If there were a pygame.gui module, it would be developed faster, programmers could help with posting new widgets they made and bugs and ideas could be handled faster. If you think it's too much work, call a vote, take the best pygame gui, put it into pygame and start helping to develop and improve it. But I think most of the work will be to think about an easy but powerful concept for a game gui. The implementing part should be less work and less difficult. Regards Jug
Re: [pygame] Re: a gsoc idea: networking
True, but if the named server was a seed rather than the whole service, than it could be hopefully hosted cheap (maybe even sf or pygame would be willing to host it). --Mike Forrest Voight wrote: You need a centralized server ... even if all it does is provide the addresses of several hosts. How else would you find even one host? On Thu, Mar 19, 2009 at 7:27 PM, Michael George mdgeo...@cs.cornell.edu wrote: Tyler Laing wrote: Haha, point taken. Sorry about that. As a student, I think that one or the other would make a good project, as both would be too much work. -Tyler I totally agree. --Mike
Re: [pygame] GSoC Proposal: Basic gui system
On Sat, Mar 21, 2009 at 8:48 AM, Marcus von Appen m...@sysfault.org wrote: Which is why a GUI backend within pygame was never realised. There is no ultimate design approach and having just a bunch of abstract base classes for users to implement is not worth the work :-). I completely agree. Arguably, making a GUI from scratch can be time consuming, but GUI's tend to differ a lot. For example, some games, such as asteroids and other arcade games, need simple centered menus. My new image filtering program has a GUI that emphasizes linking windows and other stuff. It would be hard--in my view impossible--to generalize all the possible needs down to a few classes and have it still be easier to use than an improvised solution. Ian
Re: [pygame] GSoC Proposal: Basic gui system
Having written a few pygame guis, I agree with Marcus and Ian. But, having said that, it would be possible to make a powerful enough gui that is rather abstract, but still is useful, you just need to do it correctly. A basic gui that fits in with the event system (to get, suppress, and return), with app and widget classes that can handle every kind of input/rendering would suffice for the extensibility. Then you can add simple things like buttons/labels/etc. I am sure a lot of people would use it - which may be reason enough to do it. But personally I still don't think it will be worth it - simple widgets are trivial to write... Cheers On Sat, Mar 21, 2009 at 4:08 PM, Ian Mallett geometr...@gmail.com wrote: On Sat, Mar 21, 2009 at 8:48 AM, Marcus von Appen m...@sysfault.orgwrote: Which is why a GUI backend within pygame was never realised. There is no ultimate design approach and having just a bunch of abstract base classes for users to implement is not worth the work :-). I completely agree. Arguably, making a GUI from scratch can be time consuming, but GUI's tend to differ a lot. For example, some games, such as asteroids and other arcade games, need simple centered menus. My new image filtering program has a GUI that emphasizes linking windows and other stuff. It would be hard--in my view impossible--to generalize all the possible needs down to a few classes and have it still be easier to use than an improvised solution. Ian
Re: [pygame] GSoC Proposal: Basic gui system
On, Sat Mar 21, 2009, Jug wrote: So, I think it would be cool to have a well thought out, easy extensible gui system within pygame including some basic elements like button, label, entry, etc. and a kind of geometry manager. You might like to take a look at Albow and see whether it would meet any of your needs: http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/ -- Greg
