If you think in Perl, it's not a bad language for most light-weight games. Look for the http://sdl.perl.org/ project which gives Perl bindings for everything SDL offers in terms of graphics and sound.
--
[ e d @ h a l l e y . c c ]
| [reply] |
Warning -- SDL is not a game engine by any means. It currently lacks basic primatives and things that keep programmers from expressing ideas such as "draw a square" simply.
Having written a few games in the past (experience in QBasic, Pascal, Assembler, C++ w/ Allegro, Tk, and OpenGL), SDL is a horrible place to throw a beginner. Once you feel up to the task (and provided you run something that has good/better SDL support) -- Perl + SDL may be ok. Until then, Perl + OpenGL may be a better option, or even C++ and OpenGL. Or Python + PyGame.
This is meant to dissuade gaming-beginers, not gaming experts. Those who want can make all of these work in Perl, it just won't be as easy as picking up PyGame or using C++ and OpenGL.
Game programming is quite fun, and I love doing it when I can find time... I'd just say that saying "SDL is what you want", well, it's misleading. SDL is a framework (and a hard to compile one when we are speaking of Perl bindings), it's prone to crashing/locking-up if not done right, etc...
This isn't a failing of SDL, it's just to say that SDL is nothing more than a hardware abstraction layer and a few other things. A quality game/sound library it is not.
| [reply] |
I didn't say it was a beginners' library, but it IS a graphics library, and a good portable one at that.
You might want to see frozen-bubble for a good and complete 2D graphics game implemented entirely in a few hundred lines of Perl, using SDL with Perl bindings.
--
[ e d @ h a l l e y . c c ]
| [reply] |
I should add the following recommendations to game design quests:
- Run Linux -- libraries are free, compilers are free, help is usually free ... on Windows, it's more likely you'll be stuck with DirectDraw and cryptic documentation.
- If you want to try OpenGL, it's not great, and it is hard, but you can do stuff that will work in Windows & Linux this way. Get a generic OpenGL book that does not pose as a "games programming" book -- these books typically use a lot of prewritten engine code, have bad examples, and only run on Windows.
- I'm not a huge Python fan, but PyGame looks pretty sharp in comparison to what is available in Perl for making simpler games. I'd rather work with OpenGL myself, but that is because I like C and C'ish kinds of things.
- Graphics are 'hard' to do in a whiz-bang way, but this is what most corporate games spend money on. As a stylistic tip, gameplay is sooo much more important, which is why Atari 2600 games are still fun today -- remember to spend time on gameplay before you worry about graphics!
I should also add, that graphics programming, 3D modelling, and game/level design are traditionally done by seperate people in the real world, and it's hard to find jobs in any of these... but it's a great hobby, so explore, have fun, and enjoy it.
| [reply] |
