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

Fine for simple games but...

[Viol8]

... I can't see perl being fast enough for games that require
really complex physics or enviroment calculations , or sophisticated AI.

I do think this is a nice way of getting people started in games
programming though.

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.

example game

[falkryn]

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

Re:Fine for simple games but...

[Anonymous Coward]

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

Silly question.

[Anonymous Coward]

It's in Korea, isn't that obvious?

No, thats what flas is for.

[cheekyboy]

Flash achieves this easily, especially with the dancing frog.

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 [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:example game

[lRem]

Another nice one: SDL-Vexed [segfault.pl]

PyGame

[hwaara]

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

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.

PyGame, different language same idea

[rtos]

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.

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 [libsdl.org]

There is even an SDL based opengl render target.

Tommy.

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/ [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

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: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: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:Well, duh!

[Anonymous Coward]

>> Perl's just as hard to learn as C/C++, right?

Actually I find it much harder and even trying hard I never happened to learn it. Also code is almost unreadable. And anything loosely typed is inherently anal rententive.. and bug prone.
On the memory management issues you have a point, but then C# or Java or Python are just plain better.

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.