Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Developing Games with Perl and SDL 248

Posted by ScuttleMonkey from the set-us-up-the-bomb dept.
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."
This discussion has been archived. No new comments can be posted.

Developing Games with Perl and SDL More

Developing Games with Perl and SDL

Comments Filter:

  • Hmmmm.... (Score:5, Interesting)

    by ObsessiveMathsFreak ( 773371 ) <obsessivemathsfr ... om.net minus bsd> on Wednesday February 15, 2006 @06:37AM (#14723329) Homepage Journal
    It sounds good as a learning tool. It would be great if budding game coders, especially younger coders, could be given a simpler enviornment in which to begin toying with graphics and sound coding.

    However, it's in Perl. And I really have to ask myself; Do I want to play games coded by people who started programming games in perl?

    But seriously, whenever you code a game, you always end up using a scripting language of some kind. Perhaps this just cuts out that virtual middleman that is c/c++?

    • Re:Hmmmm.... (Score:3, Informative)

      by bhima ( 46039 )
      As a embedded developer, I think the simpler development environment you are opining about is this: http://www.xgamestation.com/about_gamestation.php [xgamestation.com]

      Because much of the complexity new developers run into is baggage from the Operating System and the Development Environment.

      And YES Linux is just as guilty as Windows is these days.

    • Re:Hmmmm.... (Score:4, Insightful)

      by Mr_Silver ( 213637 ) on Wednesday February 15, 2006 @09:03AM (#14723826)
      However, it's in Perl. And I really have to ask myself; Do I want to play games coded by people who started programming games in perl?

      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?

      • 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?

        Maintainability. But you're right for a game that pretty much doesn't matter. For business applications, there's a point to not encouraging VB apps - who knows when Microsoft will discontinue various versions of the language.
      • Ah, but if it's written in PERL the programmer is probably really twisted and the last level will be absolutely impossible.
    • What's the matter? Perl is far better than BASIC, and whoemever ever played an MSX knows that Konami developed its many great classics for that platform in that damn language! Some of them were later ported to the Famicom/Nes by the names Castlevania, Metal Gear and the likes...
      • I never heard of MSX [wikipedia.org] until now. Very interesting.
      • wow, that was a flashback.

        I remember when I first learn Z80 assembler I wanted to move a sprite
        in screen 2 using the arrows keys, because it was too damn slow in BASIC.

        The result was that it was just too fast to follow.

        Good days
  • Python with SDL (pygame) has been used to write Dungeon Siege (I think that was the game, correct me if I'm wrong) and I liked the result a lot.

    • Re:Python has been used for this. (Score:5, Informative)

      by Haeleth ( 414428 ) on Wednesday February 15, 2006 @07:38AM (#14723474) Journal
      Python with SDL (pygame) has been used to write Dungeon Siege (I think that was the game, correct me if I'm wrong) and I liked the result a lot.

      I don't know what game you're thinking of, but it certainly isn't Dungeon Siege, which was written very conventionally in C++ with DirectX. (It was originally developed with OpenGL, but the developers switched to Direct3D later on, possibly because the game was being published by Microsoft.)

      At any rate, certainly neither Python nor SDL was involved at any stage.

      • Re:Python has been used for this. (Score:4, Interesting)

        by monopole ( 44023 ) on Wednesday February 15, 2006 @08:41AM (#14723684)
        The neat thing is that PyGame is very fast. I've used it to implement tricky realtime cluster rendering for 3d monitors as well as frame accurate animations for temporally multiplexed displays.
        The nice thing about Python is that since it is bound to just about everything it also supports some very fast and powerful 3d engines such as VTK, OSG, and Delta3d.
      • I also don't really know how anybody could actually *like* Dungeon Seige as a game. The thing plays itself, the bosses are lame, and the inventory system was a total pain in the ass. Not to mention it took like 5 minutes to herd your entire party onto an elevator at the same time, if you could pull it off at all.
    • Another game is OpenRTS [openrts.org], which is a realtime strategy game developed using Pygame.
    • Yes, yes, python is not less perfect than perl. We get it. I think the point to TFA was that high-level languages + SDL make a nice game development combination, not that [insert high level language] is special.

    • Panda 3D (Score:2, Informative)

      by albrnick ( 562907 )
      Actually, Panda 3D makes it even easier to use python for developing games! It is a beautiful engine closer to the Torque engine than a graphics API. Check it out at:

      http://www.panda3d.org/ [panda3d.org]

      And a little "Hello World" to show you the pwoer of it is at:

      http://www.panda3d.org/wiki/index.php/A_Panda_%22H ello_World%22 [panda3d.org]

      Peace,
      -Nick

  • Ideal. I always wanted my 4ghz pc to simulate the clock speed of a 286!

  • Wait a minute (Score:5, Funny)

    by eclectro ( 227083 ) on Wednesday February 15, 2006 @06:38AM (#14723333)

    I thought perl was already a game.

  • Well, duh! (Score:3, Insightful)

    by GreatBunzinni ( 642500 ) on Wednesday February 15, 2006 @06:40AM (#14723337)
    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....

    • Re:Well, duh! (Score:2, Insightful)

      by Jedi Alec ( 258881 )

      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

    • Re:Well, duh! (Score:2, Insightful)

      by Shaper_pmp ( 825142 )
      Yeah, this means nothing at all, right? I mean, everyone knows Perl's just as hard to learn as C/C++, right? And it takes you exactly the same amount of time to jump through all the hoops coding something in strictly-typed, anally-retentive, compiled C/C++ than hacking it together quickly in a loosely-typed Perl script.

      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 me

  • example game (Score:5, Informative)

    by falkryn ( 715775 ) on Wednesday February 15, 2006 @06:41AM (#14723343)
    http://www.frozen-bubble.org/ [frozen-bubble.org] example of a nifty game written with sdl_perl
    • well, actually perl-sdl 1.19, not 2.x, but still, shows some of what can be done.

    • Re:example game (Score:2, Informative)

      by lRem ( 914073 )
      Another nice one: SDL-Vexed [segfault.pl]
    • No, you almost certainly want to avoid that game. I'd be quite concerned about running code from someone who took programming quite that seriously. Some examples:

      If you only run a sucking proprietary OS like Windows, or if you use a lousy Gnu/Linux distribution for which there is no binary package available here

      Free software is a very interesting (and important) concept. It was brought to mankind by Richard M. Stallman, the founder of the Free Software Foundation. (no, actually, free software was a rath

  • Hmm (Score:2, Insightful)

    by darkmonkeh ( 953919 )
    While this may give a backbone for new programmers to get out their first game, the complexity of game making cannot be "simplified" more than it already is. Perl itself is slow, and not directly suited for making games. One would have to think carefully about what they wish to achieve before committing to making a game using SDL_Perl.
    • Think C64 games, but with true 24bit graphics at 640.

      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:3, Insightful)

      by mysticgoat ( 582871 ) *

      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

      • I have to agree with this. I have been doing a lot of data analysis with perl against large flat files (WordNet) and have been very impressed with the speed I got. Perl kicks mighty butt when it needs too.

        Frankly I am interested in trying out this new library. It would be pretty cool to get some graphic bang for my perl buck.

      • Perl itself is slow.... I keep seeing statements like this, and I wonder what they mean.

        That means for tasks that are computation intensive, Perl is something like 100 times slower [debian.org] than a natively compiled language like C. Now if your project is mostly I/O bound, then it might not really matter how fast your language is, since you spend most of the time waiting for disk or user input.

        Perl is a script language that is compiled on the fly, before processing starts: there is no Perl interpreter. My u

  • There's been SDL bindings around for a lot of languages for a while.
    Personally, I think lua would be a much more interesting choice than perl for this.
    • Anything would be better than perl :) C would be a particularly good... oh, wait.

      Lua would be a good one though. It's found quite a little niche for itself in games as it is so easily embedded into a parent program. Lua would be a more relevant skill than perl for somebody looking to get into working in games. (IMHO)

  • What's up next?
     
      Enhancing gui user experience with Oracle Forms
      HowTo: Brute Force numbercrunching in Visual Basic
    or
      Windows 98 Security 101
    • Please can I have a game written in Oracle Forms?

      Any game will do!

      In return, I will give you a number crunching program in Visule Basic. Unfortunately, the only number it crunches is '4' :-)

      • In return, I will give you a number crunching program in Visule Basic. Unfortunately, the only number it crunches is '4' :-)

        Do you have a copy in any linux compatible language?
        I had no idea how freaking many 4's I have. This could really get to be a problem soon....

        darby@gentoo_laptop ~ $ slocate 4 | wc -l
        74714

  • Low level 2d game libraries are so 1990's ... (Score:3, Interesting)

    by Lazy Jones ( 8403 ) on Wednesday February 15, 2006 @07:32AM (#14723455) Homepage Journal
    We had great game development libraries for stuff like that 10 years ago, e.g. Allegro [demon.co.uk]. While I appreciate the Perl support here, I don't think anyone would put more than a couple of hours' worth of effort into a game that doesn't support pretty 3D stuff on modern graphics cards. If you want to do such things, SDL_Perl isn't a viable option (look at the effort involved [bloodgate.com]).

    So, sit down on your bums and write a Perl API for DirectX with good WINE support, folks. ;-)

    • There are numerous cross-platform open source OpenGL 3D engines that have scriping hooks. OGRE, CrystalSpace and Panda3D spring to mind. I'd personally go with Panda3D and Python, if I wanted to create a modern-looking 3D game with minimal effort.

      Or invest in Torque3D.
    • While I appreciate the Perl support here, I don't think anyone would put more than a couple of hours' worth of effort into a game that doesn't support pretty 3D stuff on modern graphics cards.

      Okay:

      a) Not every game needs to be 3D. This attitude is why gameplay has languished in the name of pretty graphics.

      b) With the continued success of things like the GBA, it's clear that there's plenty of interest in 2D games.

      c) The general approach to making games is the same, whether 2D or 3D. Perl+SDL creates a low-
    • I don't think anyone would put more than a couple of hours' worth of effort into a game that doesn't support pretty 3D stuff on modern graphics cards.
      What makes you think that? Many (perhaps even most?) game concepts just aren't 3D.

  • PyGame (Score:2, Informative)

    by hwaara ( 226026 )
    Pygame is a really nice wrapper around SDL (http://www.pygame.org./ [www.pygame.org] There are plenty of guides and tutorials on the website.

    Why use Perl when you can use Python? :-P
    • Because Python has broken lexical scoping!
      • Because Python has broken lexical scoping!

        This is no longer true, and hasn't been for years.

        • I'm afraid it is still true. Lexical scoping has never been properly fixed in Python in relation to closures. See this link [python.org] for an excellent explanation. Perl does lexical scoping just fine, and I like explicit variable declarations, even in a scripting language.

          • Re:PyGame (Score:3, Informative)

            by arevos ( 659374 )
            That isn't a problem with lexical scoping; that's a problem with ambiguous assignments within closures. The lexical scoping problem was something else altogether. And whilst Python closures are read-only, this doesn't mean that they are broken; just incomplete.

            Whilst read-write access of closures would be nice, it's trivial to get around this. It's certainly not enough to get me to switch back to Perl - yuck! No thanks! I like my well-defined object model :)

            IIRC Ruby has read-write closures? Why not use tha

            • Re:PyGame (Score:3, Informative)

              by brpr ( 826904 )

              How is it not a problem with lexical scoping? The assignment is ambiguous because of the way lexically scoped variable declarations (don't) work in Python. Whether this is a problem with lexical scoping itself or the syntax of variable assignment in Python is really a meaningless question, since it's a problem resulting from the combination of the two. Definitional questions aside, I don't want to work in a language with "incomplete" closures when there are better alternatives.

              Perl has a perfectly well-de

              • Re:PyGame (Score:3, Informative)

                by arevos ( 659374 )

                How is it not a problem with lexical scoping?

                Because the scoping itself works fine. The problem lies with variable assignment and declaration in Python being ambiguous when dealing with multiple scopes. This means that closure support in Python is incomplete, in that closures are essentially 'read-only', in that inner assignments won't work. This can be overcome with mutable types, but I agree that this isn't a ideal solution.

                This is why I say incomplete, and not broken. By the same standards, I say tha

                • Because the scoping itself works fine. The problem lies with variable assignment and declaration in Python being ambiguous when dealing with multiple scopes.

                  But if the syntax for assigning variables doesn't work nicely with lexical scoping, I think it's reasonable to say that something to do with lexical scoping isn't working properly. If Python would change it's lexical scoping rules slightly, the problem would be fixed without changing the assignment syntax. (Essentially, you could have the system work

                  • True, but that basically amounts to saying "lexical scope isn't particularly useful". You have a point here I admit -- it's easy enough to get along in a language with little or no lexical scoping (e.g. C, prior to C99). But it's still anoying that closures are so limited in Python, if you like functional programming, as I do.

                    I think it might be a case of programming style. I used Perl for years before I discovered Python, and I find myself liking the latter a lot more. But then, I've always taken a very

                    • Given this, Python's very clean OO approach appeals to me greatly.

                      Python is my scripting language of choice but I would never claim that Python's OO approach is even remotely clean. Example:

                      class Bad:
                      a = "Who knows?!"

                      class A:
                      def __init__(self):
                      self.a = "Bad"
                      self = Bad()
                      self.a = "No, Good"

                      ob = A()
                      print ob.a

                      The result, of course, is that Python prints "Bad". Python has a prob

                    • Whilst Python is not without it's problems, in this case the problem lies with you misunderstanding how both Java and Python handle objects and references.

                      Let's take the following Python code:

                      ob = A()

                      The class 'A' is instantiated into a new object, which is placed on the heap. The constructor 'A()' returns a reference to this new object, which is stored in the variable 'ob'. Note that 'ob' stores not an object itself, but merely a reference to one. All variables in Python are references to objects, withou

                    • Your assumption that I don't understand the inner workings of either Python or Java is entirely incorrect. The code was written specifically to show how Python objects have a very sketchy grasp of object identity.

                      Object methods have complete lack of contextual identity within their instance. The same closure rule that causes problems with variable scoping extends in a non-sensical way to Python objects, such that Python never checks to see if a variable is outside a method's scope but inside the object's sc

                    • The code was written specifically to show how Python objects have a very sketchy grasp of object identity.

                      I have to disagree:

                      class A:
                      def foobar():
                      print "Foobar"
                      a = A()
                      b = a.foobar
                      assert a == b.im_self

                      The 'foobar' method knows exactly which object it belongs to. That seems a very solid grasp of object identity to me.

                      That's why "self" is an explicit parameter that is mutable and all references to class variables and methods must be prefixed with "self." That is

                • FWIW you can bless [perl.org] anything as an object. (Well, a reference to anything.) Scalar, hash, whatever. The key here is that it's optional rather than the default. (So, yes, perl isn't pure OO, but then again that's not really "broken" so much as "different design goal." ;))
                • Sigh. We still have to have a language hate-fest every time a language-specific article shows up?

                  "When last I looked, Perl didn't treat scalars, hashes and arrays as objects. Perl's incomplete object model is, in my view, a far bigger problem than Python's read-only closures. And on the subject of things Perl doesn't have, as far as I know, it has no metaclass support, either."

                  All true (except for the opinion about severity which is simply an opinion and neither true nor false).

                  While Perl 6 endevours to add

                  • Sigh. We still have to have a language hate-fest every time a language-specific article shows up?

                    Because arguments, when intelligently debated, often offer previously insight to both sides. It's a competitive exchange of ideas. Whilst I can't comment on what brpr thinks, his arguments have made me think more carefully about Python closures and scoping, and has opened up some fascinating avenues of thought.

                    True lexical scoping seems, to me, to blur the distinction between a function and an object. Such r

                • When last I looked, Perl didn't treat scalars, hashes and arrays as objects.

                  They are if you bless them. Perl's object stuff is weird, for sure, but with some stupid boilerplate code you can ignore most of it.


                • If you claim that Python's closures are 'broken', then you must also accept that Perl's object model is 'broken'.

                  Perl has a perfectly well-defined object model.

                  When last I looked, Perl didn't treat scalars, hashes and arrays as objects.

                  zzzz.... Thats the poorest argument I have ever seem about perl's OO implementation.

                  Why does an OO language needs to implement scalars, hashes and arrays as objects to be a trully OO language?!?

                  • Why does an OO language needs to implement scalars, hashes and arrays as objects to be a trully OO language?!?

                    I didn't say this. I said Perl had an incomplete object model. Since scalars and such aren't naturally objects in Perl, not all data types in Perl are objects. Therefore, Perl's object model is incomplete. QED.

  • What about all the libraries SDL is missing? (Score:5, Insightful)

    by master_p ( 608214 ) on Wednesday February 15, 2006 @08:01AM (#14723548)
    SDL is "a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer" (quote taken from the SDL web site). What about:

    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)

    by jalefkowit ( 101585 ) <jason@@@jasonlefkowitz...com> on Wednesday February 15, 2006 @08:04AM (#14723555) Homepage
    At last we can have Tetris with regular expressions.

  • PyGame, different language same idea (Score:3, Informative)

    by rtos ( 179649 ) on Wednesday February 15, 2006 @08:06AM (#14723561) Homepage
    If you are into Python rather than Perl, you might want to check out PyGame [pygame.org].

    It's basically a wrapper for SDL that makes it extremely easy to make games with Python. You could easily make a working 2D game with sound and decent physics in an evening if you are already familiar with the language. I'm a relative newb, and even I was able to make a basic pong/breakout type game in a few nights. :)

    Or use PyOpenGL [sourceforge.net] and you can make some 3D games.

  • [puts on flame suit] This is going to be controversial I know but has anyone tried developing a real game in Java? (by real I mean something that you don't play on a mobile phone) I realize that the GCing could be problematic but it is possible to minimize or even eliminate that problem. Other than that I think the language is probably fast enough now and I would have thought that the lower development time would encourage games houses. Perhaps it's simply that the tools aren't there for Java yet (maybe the

  • ...of 2D games can be done fairly easily and quickly in Flash. I'm really quite surprised there hasn't been more of an effort made for an Open Source alternative to Flash, maybe the reputation it has for being slow, evil and crap has too much of a foothold, but it's actually quite a nice environment to work in for testing some stuff.

    As for this, I suppose it's nice enough. I don't see what it brings to the table that hasn't been done many times before, in many different languages, but making games is fun en
  • Mildly interesting but in terms of modern games it won't cut the mustard so then you are looking at smaller games and a platform to learn on. IMO there is only one top platform to learn game programming for and that is the Java mobile phone platform J2ME [sun.com] that even comes with a standard (and pretty simple) 3D API [jcp.org]. Its also the fastest growing gaming market out there at the moment, and its still an area where mere mortals can break in and create the killer game and make money. Aiming at the PC market means
  • The author does a good job of introducing SDL and the mechanics of a simple game. Nicely done!
  • What platforms can the resulting games be run on?
  • Kaboom! ran on the Atari 2600. Kaboom! was written by Larry Kaplan and David Crane for Activision.

Slashdot Top Deals

When the weight of the paperwork equals the weight of the plane, the plane will fly. -- Donald Douglas

Close