Developing Games with Perl and SDL

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."

Comments

Hmmmm....

[ObsessiveMathsFreak]

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....

[bhima]

As a embedded developer, I think the simpler development environment you are opining about is this: http://www.xgamestation.com/about_gamestation.php

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....

[Mr_Silver]

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?

Python has been used for this.

[Poromenos1]

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.

[Haeleth]

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.

[impossiblerobot]

Yes, but in the two hours I spent learning Python, I would have already finished writing the game in Perl (and would have been playing it for an hour and a half).

Re:Python has been used for this.

[monopole]

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.

Re:Python has been used for this.

[ajs]

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.

Re:Python has been used for this.

[ajs]

Anyone who has learned both languages does not agree, in my particular case. They're both powerful, highly flexible languages that have powerful constructs for managing high-level structures. Perl tends to have more varied facilities while Python tends to have fewer, but often more robust facilities (twisted comes to mind).

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.

A 286 Emulator?

[joevai]

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

Wait a minute

[eclectro]

I thought perl was already a game.

Well, duh!

[GreatBunzinni]

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!

[Jedi Alec]

        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.

example game

[falkryn]

http://www.frozen-bubble.org/ example of a nifty game written with sdl_perl

Re:example game

[lRem]

Another nice one: SDL-Vexed

Hmm

[darkmonkeh]

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.

Re:Hmm

[mysticgoat]

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).

Re:Fine for simple games but...

[Anonymous Coward]

Tim Sweeney had a talk about related stuff at POPL'06, you can check the homepage for his slides.

No, thats what flas is for.

[cheekyboy]

Flash achieves this easily, especially with the dancing frog.

Tetris puzzle games, or c64 style games.

[cheekyboy]

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:Fine for simple games but...

[rheum101]

...it's an oversimplification to state that perl cannot achieve the same performance as C/C++ ... where 99% of the time is spent deep within optimized libraries and perl (or any scripting language) is used to initialize and facilitate interaction, then it is quite possible that no material performance hit will result ... only profiling can really reveal this ... ...and perl / PHP / whatever is a MUCH easier on ramp than getting into deep C++ OO structures...

Games in Perl?

[cablepokerface]

What's up next?
 
  Enhancing gui user experience with Oracle Forms
  HowTo: Brute Force numbercrunching in Visual Basic
or
  Windows 98 Security 101

Re:Games in Perl?

[Anne Thwacks]

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' :-)

Low level 2d game libraries are so 1990's ...

[Lazy Jones]

We had great game development libraries for stuff like that 10 years ago, e.g. Allegro. 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).

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

PyGame

[hwaara]

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

Why use Perl when you can use Python? :-P

Re:PyGame

[arevos]

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 that over Perl?

Re:PyGame

[brpr]

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-defined object model. Not sure what you mean by that. If you just mean that Python has a nicer object model, then I agree up to a point, but Perl's is at least as powerful. I don't much like OO anyway, I'm more of a functional programmer.

Ruby's OK, but it's slower than Perl, and it can't get lexical scoping quite right either.

The thing is that it's really more-or-less impossible to have satisfactorary scoping rules without explicit variable declarations. Even ignoring Python's problems with closures, you still have the problem that whenever you write "a = b", you can't be sure whether you're binding a new variable, or assigning a new value to an existing variable. (Same applies to Ruby).

So overall, I prefer Perl. It might not be as buzzword-compliant as Python or Ruby, but it doesn't try to run before it can walk.

Re:PyGame

[arevos]

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 that Perl's object model is incomplete, rather than broken. 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. 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.

Even ignoring Python's problems with closures, you still have the problem that whenever you write "a = b", you can't be sure whether you're binding a new variable, or assigning a new value to an existing variable.

Only in the scope of a single function, and realistically speaking, if your functions are so long that you don't know whether a local variable has been assigned or not, then perhaps your function is too long, anyway. Certainly when I'm programming in Python, functions tend to be under a dozen lines long.

Re:Fine for simple games but...

[Vo0k]

Moreover, writting in Perl is fast and easy. You can test your ideas, check if the game would be playable at all, create a working mockup in Perl and finding "not enough raw horsepower" move to C with the "final product". Sure it will take longer than writing everything in C from scratch, but shorter than writing everything in C and then deciding it sucks and abandonning it.

What about all the libraries SDL is missing?

[master_p]

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?

Re:What about all the libraries SDL is missing?

[TommyBear]

There are other thirdparty libraries that offer this kind of support:

http://www.libsdl.org/libraries.php

There is even an SDL based opengl render target.

Tommy.

Finally!

[jalefkowit]

At last we can have Tetris with regular expressions.

PyGame, different language same idea

[rtos]

If you are into Python rather than Perl, you might want to check out PyGame.

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 and you can make some 3D games.

Easy

[Andy Dodd]

All that highly optimized C is part of a prewritten library (as is the case here).

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:Easy

[Junks Jerzey]

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.

That rule of thumb quite often doesn't apply to video games, at least high-end, complex video games. In such, you often see a flat profile, where the work is divided among a large number of functions, none of which stands out as a huge time sink.

(That said, I still think writing games in languages like Perl is a good idea.)

Re:Easy

[sbrown123]

I agree with you there. I wrote a Java wrapper around SDL and OpenGL a few years back. After doing that, almost all the rest of the code for a game (actually interactive applications in my case) could be written in Java using the wrappers. After presenting some examples to some hardcore C/C++ programmers, they stopped complaining about the "Java is slow" stuff. Ofcourse, they had to continue that C/C++ could make it go slightly quicker and take less memory. I couldn't argue with them there. But what they couldn't do with C/C++ was develop similiar apps/games as quickly. Now, someone who did not know these C/C++ programmers would argue that they just didn't know the languages that well. But for those who wonder I have this: how many times have you written a large C/C++ application and found yourself looking for some oddball memory leak?

Its a natual progress with languages. Languages like C and C++ are giving way to languages like Java and C#. But interestingly enough Java and C# will be replaced too: by scripting languages like Perl. As programmers, we just have to accept this and move with the tide or drown in ignorance.

Re:Easy

[Fizzog]

"keep in mind the 80/20 rule of thumb. 80% of the time is spent in 20% of the code."

But you also need to remember that the remaining 80% of the code takes the other 80% of the time.

Re:Other languages

[Tusaki]

Several games.

Jake2 (Quake 2 clone) as the AC already posted.
Puzzle Pirates
Tribal Trouble (good!)

check out javagaming.org for tons of discussions about the subject.

and tools? how about:

LWJGL: http://www.lwjgl.org/
JMonkeyEngine: http://www.jmonkeyengine.com/
Xith3D: http://xith.org/

And there are probably tons of other games and tools I'm forgetting.

And regardless what the trolls will say, it is perfectly possible to create a 2006-level game in java.

Re:It'd be nice if there was just an OS C/C++ "bas

[petermgreen]

what really gets me is when you wan't to make some changes to open source software (particularlly windows stuff) and sure you can download the source but you have to spend hours messing arround trying to get the build environment right.

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

Panda 3D

[albrnick]

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/

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

Peace,
-Nick