Hi Ken, I wish you luck in your journey. I'm still learning a lot of this myself, but I would be happy to help in whatever way I can.
You're right about Sound RTS slowing down with big, laggy maps, but I believe that's more a matter of the way the game was coded. If the developer used a module like numpy, I think he'd have better luck. At the same time, though, keep in mind how slow games like ToC get when you have them running with lots of units at once, especially if you try to throw in Braille support. Keep in touch. I'd love to keep up with how you're faring in your practice. Best, Ryan -----Original Message----- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of The Addictor Sent: Saturday, April 23, 2011 12:11 PM To: Gamers Discussion list Subject: Re: [Audyssey] Python resources, possibly somewhat o/t Wow! Well-done Ryan! You must have spent all day writing that! I'm just learning Python myself, and my intention is to pick up some of the slack in NVDA. I'm starting out with simple things, like learning to move the focus to specific coordinates to make apps like Paltalk easier to use. Later I'd like to learn how to get it to recognize graphics, and label those graphics like I used to in Jaws. After that, I might start taking Moosik apart and rewrite for the new python libraries, since I really want more games to play with my sighted kids, but that's way beyond my abilities at this point. I still think that speed is a major issue though. Have you tried playing SoundRTS on the big maps, with 4 or 5 computer opponents? My computer just can't do it. Other than that though, there are a lot of things I like about python, especially its interactivity and load time. NVDA can shut down and restart in just under two seconds, and Moosik doesn't take much longer. Ken Downey The Addictor www.TheAddictor.com ----- Original Message ----- From: "Ryan Strunk" <ryan.str...@gmail.com> To: "'Gamers Discussion list'" <gamers@audyssey.org> Sent: Saturday, April 23, 2011 10:01 AM Subject: Re: [Audyssey] Python resources, possibly somewhat o/t > Hi Tom, > > As a budding game developer, I want to respond to your below email to > paint > what I feel is a more accurate picture of the python language. I think > there > are a few additional points everyone really should consider before jumping > headfirst into C#.net as I tried to, especially when that jump can meet > with > some pretty spectacular failures. > I will proceed our statements and responses with initials. > > TW: On the plus side Python is easy to learn, is cross-platform, and there > are a number of simple APIs like PyGame available to help you quickly get > up > and running with game programming. ... All of this makes Python look good > on > the surface. > > RS: This is exactly why Python *is* good, not just on the surface, but > deeper down. Imagine being able to program a game right out of the box > that > will reach not only the Windows community, but the Mac community as well. > How many of you out there are Mac users who lament the fact that you don't > have any games to play on your computers because they've all been designed > for windows? Python can fix that for you. > > Additionally, because Python is easier to learn, it's also easier to > debug. > It's a given that programmers spend far more time reading their code than > they do writing it, and Python gives you the 1UP on that too. It's the > difference between > C# > void main(string[args]) > { > System.Console.WriteLine("Hello world"); > } > > And Python: > print "Hello world." > > Even those of you who have never programmed a day in your life can see the > difference. > > TW: On the down side Python is still a runtime language that requires an > interpreter or runtime environment to run. > > RS: c# is compiled to MSIL, Microsoft Intermediate language. This is a > type > of Byte code. In other words, C# is also Interpreted. If you want more on > the subject, check this out: > http://en.wikipedia.org/wiki/Common_Intermediate_Language > > TW: ... if you are thinking about creating high performance games that > have > to update 40 to 60 times a second Python is going to exicute and run very > slow. It was never designed to handle high performance applications like > Shades of Doom, Mysteries of the Ancients, etc. For something like that > you > really need a triditional language like C++ to get the most performance > out > of your CPU power and memory. > > RS: Python was considered slow when it was first conceived nearly twenty > years ago, back when engineers flatly rejected the idea that we could ever > break the 1 gigahertz threshold on a computer's processor. Today our > processors run far upwards of 1.0GHZ, and they often do it on multiple > cores. > While I will not dispute that there are speed advantages to running > C-based > languages, I also think it's important to point out that our accessible > games will likely not reach the constraints of what Python is capable of > any > time in the near future. The boxing game I am currently developing updates > its calculations 250 times a second with absolutely no slow-down. > > TW: Second, some of the APIs like PyGame aren't the best APIs available > for > game developers. PyGame is decent if you are going to produce a football > game like Jim's NFL, Star Trek Final Conflict, or something like that ... > > RS: What about Sound RTS? That's far more advanced than either of those > games. > > TW: but if you are thinking of something like Shades of Doom or Mysteries > of > the Ancients forget it. ... If you want only keyboard access PyGame is > fine, > but if you want advanced Joystick support like force feedback and things > like that again no go. PyGame just doesn't have that kind of support yet. > > RS: PyGame does have joystick support. It has mouse support as well. And > while the sound mixer may be lacking, there are other libraries that can > pick up the slack. Libraries like those found at > http://hg.qwitter-client.net. It's also worth pointing out that all of > these > libraries, like the Python language itself, are free to use. Developers > don't have to shell out any expense for third party libraries or the > development environment itself, for that matter. > > TW: Finally, there is the issue of using Python as a springboard to other > programming languages. ... The problem is that you are going to have to > start over from scratch if you use Python and switch to Java, C#, C++, > whatever because you didn't learn much as it relates to other programming > languages. In fact, it has been my personal opinion for a long time Python > teaches programmers bad habits that make it difficult to adapt to other > languages later on. > > RS: You're welcome to your personal opinion, but I want to give a few > others > for sake of balance: > > Peter Norvig is an American computer scientist. He is currently the > Director > of Research (formerly Director of Search Quality) at Google Inc. He > writes: > Several people have asked what programming language they should learn > first. > There is no one answer, but consider these points: > > Use your friends. When asked "what operating system should I use, Windows, > Unix, or Mac?", my answer is usually: "use whatever your friends use." The > advantage you get from learning from your friends will offset any > intrinsic > difference between OS, or between programming languages. Also consider > your > future friends: the community of programmers that you will be a part of if > you continue. Does your chosen language have a large growing community or > a > small dying one? Are there books, web sites, and online forums to get > answers from? Do you like the people in those forums? > Keep it simple. Programming languages such as C++ and Java are designed > for > professional development by large teams of experienced programmers who are > concerned about the run-time efficiency of their code. As a result, these > languages have complicated parts designed for these circumstances. You're > concerned with learning to program. You don't need that complication. You > want a language that was designed to be easy to learn and remember by a > single new programmer. > Play. Which way would you rather learn to play the piano: the normal, > interactive way, in which you hear each note as soon as you hit a key, or > "batch" mode, in which you only hear the notes after you finish a whole > song? Clearly, interactive mode makes learning easier for the piano, and > also for programming. Insist on a language with an interactive mode and > use > it. > Given these criteria, my recommendations for a first programming language > would be Python or Scheme. But your circumstances may vary, and there are > other good choices. If your age is a single-digit, you might prefer Alice > or > Squeak (older learners might also enjoy these). The important thing is > that > you choose and get started. > > With that in mind, here are 3 great articles > Teach Yourself Programming in Ten Years: http://norvig.com/21-days.html > Python as a First Language > http://mcsp.wartburg.edu/zelle/python/python-first.html > Why Python is a great language for teaching beginners in introductory > programming classes http://www.stanford.edu/~pgbovine/python-teaching.htm > > TW: If you want to be an amateur game developer go with Python. However, > ifyou want to be a pro, write really pro level games, then you have got to > take the bull by the horns and learn something a bit more advanced than > Python. > > RS: I'm going to come out directly and say that the previous statement is > rather insulting. The language does not make the programmer, just as the > tools don't make the carpenter. If you want to be a pro and write > pro-level > games, then learn to be a programmer and stick with what works for you. > There are a number of languages out there, each with their own advantages > and disadvantages. Saying that one can't be a professional developer > unless > one learns language X is wrong on so many levels. It's like saying you > can't > play chess properly if you can't speak Russian. > And if anyone still needs more proof that Python can be a viable language, > consider that Qwitter-client and the NVDA screen reader have both been > developed in that language. > > Ryan > > > --- > Gamers mailing list __ Gamers@audyssey.org > If you want to leave the list, send E-mail to > gamers-unsubscr...@audyssey.org. > You can make changes or update your subscription via the web, at > http://audyssey.org/mailman/listinfo/gamers_audyssey.org. > All messages are archived and can be searched and read at > http://www.mail-archive.com/gamers@audyssey.org. > If you have any questions or concerns regarding the management of the > list, > please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
