Developing Games with Perl and SDL 248
segphault writes "Andy Bakun has written an excellent 20 page guide to game development with SDL_Perl for Ars Technica. The tutorial, which includes extensive code examples and plenty of screenshots, walks readers through the process of building a clone of the original Atari Kaboom! game." From the article: "One of the biggest benefits of using SDL is that it allows portable media applications to be written without having to be concerned with specific implementations of media libraries for each target platform. Bringing Perl into the picture takes the portability one step further, allowing media-rich applications to be written in a high-level language that can be targeted to a number of platforms. While programming using SDL requires knowledge of C and access to a C compiler, using SDL_perl does not. This greatly decreases the amount of time it takes to get something up on the screen and working."
Well, duh! (Score:3, Insightful)
Yet, it does need knowledge of Perl, another programming language, and access to a Perl interpreter. So, indeed, in the end it needs the exact same thing that is needed to write a game in C or C++. A person needs knowledge of a programming language, knowledge of an API and access to software which will make the program happen. So, having this in mind, wtf is that intended to mean? Sheesh....
Hmm (Score:2, Insightful)
Tetris puzzle games, or c64 style games. (Score:3, Insightful)
SDL+PERL can be thought of a 'flash killer' hack.... with enough specific libraries for sdl in perl, they
could do extra tricky bits animated mpeg1 in a sprite with one command.
Re:Hmm (Score:1, Insightful)
Re:Fine for simple games but... (Score:4, Insightful)
What about all the libraries SDL is missing? (Score:5, Insightful)
1) drawing functions
2) fonts
3) openGL
4) file formats
5) game GUI
6) sound formats
7) networking
8) configuration
etc?
there are various SDL-derived libraries that implement, more or less, the above, but they are C/C++ libraries, and the quality varies. Does Perl make it easy to use those libraries?
Finally! (Score:4, Insightful)
Re:Well, duh! (Score:2, Insightful)
While programming using SDL requires knowledge of C and access to a C compiler, using SDL_perl does not. This greatly decreases the amount of time it takes to get something up on the screen and working.
Yet, it does need knowledge of Perl, another programming language, and access to a Perl interpreter. So, indeed, in the end it needs the exact same thing that is needed to write a game in C or C++. A person needs knowledge of a programming language, knowledge of an API and access to software which will make the program happen. So, having this in mind, wtf is that intended to mean? Sheesh....
Because, well, C and Perl are the same level of complexity. All this superficial nonsense like garbage collection, not having to worry about memory allocation etc. won't save any time whatsoever.
Easy (Score:5, Insightful)
For the remaining non-performance-critical stuff, Perl is often MUCH easier to develop with.
And in many cases, keep in mind the 80/20 rule of thumb. 80% of the time is spent in 20% of the code. This does vary, but in many cases the amount of highly optimized code needed for good performance is very little.
Many years ago, I was writing a program in Perl. I knew that there was a good chance I'd have to rewrite some of it in C eventually for decent performance, and this turned out to be true. In the end, I obtained 20-40 times the performance (and most likely 95%+ of the performance I would have obtained using C only) by rewriting approximately five lines out of 100-200 lines of Perl in C. The time it took me to figure out how to interface C and Perl (doing so was not documented very well then, it took me 2 weeks to find SWIG) was still far less than the time it would've taken me to write the entire program in scratch using straight C.
Re:It'd be nice if there was just an OS C/C++ "bas (Score:4, Insightful)
how the hell are users supposed to fix bugs that annoy them if they can't get the build environment right for the existing code?!
Re:Hmmmm.... (Score:4, Insightful)
I would ask yourself, "why do you care what it is written in?". The whole point of playing a game is that its supposed to be enjoyable. The fact that it is written in Perl, C, BASIC, Java or Cobol is immaterial if you enjoy the game.
Would you suddenly consider Half-life 2, GTA or any other game "rubbish" just because you found out that it was written in a programming language that you didn't like or didn't think would be suited to the task?
I see a similar thing with people who snub Visual Basic applications. Yes we all know how good or bad VB is at development but if someone has produced a tool using it which does what you want, quickly, easily and at the right price, why does it matter what it was written in?
Re:Python has been used for this. (Score:3, Insightful)
Re:Well, duh! (Score:2, Insightful)
Oh, and scripted languages' memory management saves exactly zero development and testing time over non-memory-managed languages, too, while simultaneously not helping you at all to avoid memory leaks and other nasty hard-to-debug errors. And CPAN stores phenomenally huge amounts of pre-written plug-in-and-go code for both Perl and C/C++, right? And...
Either we haven't ever written a line of code in C/C++ or Perl, or we didn't think before we posted...
Disclaimer: I first learned to code in C/C++, so I harbour it no ill-will at all. Nevertheless, anyone seriously suggesting that Perl won't save you time over C/C++ in the short-term is insane. Of course, a non-trivial project where C/C++'s strict typing and formal style produces big wins is another matter, but when the context's "getting something up on the screen and working" it's simply no contest.
Re:Python has been used for this. (Score:3, Insightful)
They are both excellent languages, and if you're of the ill-informed opinion that one or the other does not serve well for large, highly strucutred projects, then I suppose our experiences simply differ.
Re:Hmm (Score:3, Insightful)
Perl itself is slow....
I keep seeing statements like this, and I wonder what they mean.
I have used Perl fairly extensively in data mining and format conversion work, sometimes using the Tk extension to provide a GUI front end, but I don't do real time applications or games. However I expect Perl would be adequate for many games, because I think that a lot of people are not recognizing the difference between a scripted language and an interpreted language.
Perl is a script language that is compiled on the fly, before processing starts: there is no Perl interpreter. My understanding is that the resulting code runs at the same speed as an executable from a C compiler: that it is in fact an executable from a specialized C compiler. My experience is that large, complex Perl scripts will exhibit a noticeable delay on start-up (during the compilation phase), but are indistinguishable in performance from any other executable once data crunching begins.
IME, any noticeably slow performance in Perl scripts can be traced to inefficient uses of regular expressions or string evals (both of which see heavy usage in the kind of work I've been doing). But these are program design issues, not inherent in the Perl implementation itself, and I doubt that either of these techniques would be used much in games. Obviously Perl isn't a good choice for 3D games with Shrek level animations, but I don't think you could do that kind of thing with any of the common C or C++ packages.
So am I missing something here? Is Perl really too slow for game development, or are people thinking that since it is scripted, it must be implemented like a Basic interpreter? Or are people overly concerned about the start-up delay of the compilation phase (which can be gotten around for Windoze/Wine by using something like perl2exe to precompile an executable for distribution).
What's PERL stand for? (Score:1, Insightful)