Yeah, I'm probably worrying prematurely. I'm very easily influenced by FUD and there are a lot of messages floating around that Python (and Ruby) are too slow for making games.
yours truly armornick 2011/11/23 Christopher Night <cosmologi...@gmail.com> > I don't know why you would be concerned about performance in a visual > novel game. Aren't they pretty undemanding? I haven't played these games > very much, but isn't it just a series of still images (no animations) and a > simple GUI? > > You might want to look at a pyweek entry called Gregor Samsa. I know that > team put some effort into optimizing things and wound up with a respectable > framerate even on mobile devices running Android: > http://www.pyweek.org/e/tihoas/ > > But again, I feel like performance is the least of your concerns if that's > your kind of game. If there's some specific thing you're expecting to cause > low performance, maybe you can ask about it specifically. > > Good luck! > -Christopher > > > On Wed, Nov 23, 2011 at 11:46 AM, Nick Arnoeyts <nickarnoe...@gmail.com>wrote: > >> Alright. Thanks for your reply everyone. >> >> I'm currently still working on a Ren'py project, but I'm probably going >> to try pygame once that's finished. I'm mostly making visual novels, >> though, so it's possible that I'm staying with ren'py until I reach its >> limits. >> >> yours truly >> armornick >> >> >> 2011/11/23 stabbingfinger <stabbingfin...@gmail.com> >> >>> Hi, Armor Nick. >>> >>> Some common bottlenecks I've encountered: >>> >>> rendering many images per frame >>> brute force collision checking >>> computationally intensive logic and AI >>> real-time image transformation >>> heavy usage of images with SRCALPHA >>> 2D and 2.5D layering >>> particles >>> >>> These are easy limits to hit early on especially in scrollers, >>> platformers, and bullet hell type games, or when you start adding >>> environment and GFX. >>> >>> But there are clever techniques that pygamers have developed to deal >>> with them in the form of cookbook recipes, libraries, and modules. Many >>> issues can be easily mitigated by selecting a culling technique or two to >>> reduce the number of things processed each game loop. >>> >>> Some people popping into IRC lately seem easily frustrated by these >>> challenges, wanting an inefficient workload to just perform well. I can >>> understand the sentiment. But I personally get an immense amount of >>> pleasure from conquering these challenges. :) >>> >>> When I started pygame three years ago I was told you can't do a >>> scrolling action-RPG: it's too much work for the CPU. Since then, computers >>> became a significantly faster and several people have produced reasonably >>> impressive action-RPGs, as well as other genre. >>> >>> For some examples one only has to look among the top places at >>> pyweek.org, where pygame competes with the likes of pyglet, cocos2d, >>> and rabbyt, all of which have the proclaimed advantage of 3D acceleration. >>> It's become clear to me that for most hobby games the only real limitation >>> is the resourcefulness of the programmer. >>> >>> I personally haven't yet hit a wall with Python or pygame that forced me >>> to look at another framework or a natively compiled language, and I've done >>> a few relatively ambitious projects. >>> >>> That may seem like a biased representation of Python's and pygame's >>> capabilities, but I assure you it's not. A few times a year my eyes wander >>> to other game development libraries or engines, but I keep coming right >>> back to pygame. >>> >>> Hope that perspective helps. >>> >>> Gumm >>> >>> >>> On Wed, Nov 23, 2011 at 6:08 AM, Chris Smith <maximi...@gmail.com>wrote: >>> >>>> You can use Renpy for graphic novels. SNES RPG's would be no problem. >>>> For AI and other things, python might be slow but you will probably be >>>> surprised how far you can go with it. It'll certainly be easier than going >>>> the C++ route (although I'm not a C++ fan, to be honest... I'd use Lisp if >>>> I needed the code to be faster). >>>> >>>> >>>> On 23 November 2011 21:47, Nick Arnoeyts <nickarnoe...@gmail.com>wrote: >>>> >>>>> I'm actually not quite sure what I'm going to write yet. Either an RPG >>>>> in the style of SNES-era Final Fantasy, or a visual novel (if you know >>>>> Higurashi or Clannad). I'm not (yet) interested in 3D and I would >>>>> certainly >>>>> do something like that in C++. >>>>> >>>>> Pygame is probably fast enough for the graphics, but I was wondering >>>>> how performance would be for AI and other calculations. >>>>> >>>>> yours truly >>>>> armornick >>>>> >>>>> 2011/11/23 Chris Smith <maximi...@gmail.com> >>>>> >>>>>> You can't really compare the language C++ with the library Python. >>>>>> >>>>>> You could compare C++ / SDL with Python / Pygame, and probably C++ >>>>>> would be faster (but maybe by not as much as you think)... but it would >>>>>> certainly take a lot more time to write the code. >>>>>> >>>>>> As to what you can do with Pygame, well it is a 2D library that I >>>>>> find fast enough for most things. In some ways I think Pygame is a little >>>>>> 'old-school': Pygame does not do a lot for you, but it gets out of the >>>>>> way, >>>>>> and perhaps most importantly, it's small enough to fit in my mind but big >>>>>> enough to do what I want. >>>>>> >>>>>> Unless you develop as part of a team you need 3D, you are unlikely to >>>>>> choose a project that Pygame cannot handle in some way. >>>>>> >>>>>> Perhaps you could tell us more about what you wanted to write... that >>>>>> would make it easier to tell you if Pygame could do this for you. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 23 November 2011 21:07, Nick Arnoeyts <nickarnoe...@gmail.com>wrote: >>>>>> >>>>>>> Hey everyone >>>>>>> >>>>>>> I was wondering what the limits of pygame performance are. What is >>>>>>> the absolute maximum kind of game that can be written with it, and what >>>>>>> kinds of things are better done in pure C++ than python? >>>>>>> >>>>>>> This is probably a question that's asked periodically on the mailing >>>>>>> list, so I apologize in advance. >>>>>>> >>>>>>> Yours truly >>>>>>> >>>>>>> Armor Nick >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
