Slashdot Mirror
Is There Life Beyond DirectX?
Zangief asks: "Almost any gamer has, at some point, the idea of making their own game. I am no exception, so I've been playing around with SDL, which appears to be the logical decision over the craziness of DirectX. However I have also noticed that other alternatives, such as ClanLib. There is something else? Are there any other libraries, dev-kits, or tools that would be good for indie developers?"
check out http://crystal.sf.net its good library to start you on the road of game programming in 3D
AZTEK
Allegro Homepage
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Here is the mother lode: http://www.flipcode.net/
Really it depends on what sort of game you plan to be developing. If you are going to try out life as a small independant designer, you might want to try out some Flash stuff. I'm serious. Some people crank out a bunch of shareware Flash games. They're fun and easy to distro.
If you are looking at bigger projects, or trying to learn the coding side to things, you can pick apart one of the game engines in the above site. If you want to learn the real technique behind graphics, then you need to learn DirectX or OpenGL. That is where the real stuff gets done at the moment.
GG
As the sourceforge site says:
Check out Programming Linux Games, by a Loki developer by the name of John Hall.
It goes over SDL in depth, and shows how to integrate OpenGL into it as well. As well, it touches on some other APIs of note, such as SVGALib, GGI, ClanLib, OpenGL, Plib, Glide, Xlib (for video), GTK+, TK, Fltk, Qt, and SDL_gui (for menu widgets), OSS, ALSA, ESD, and OpenAL (for audio), and cl, Guile, and Scheme (for scripting).
No comment.
you might try getting strated with pygame, a wrapper to sdl for python.
obviously if you need every single cpu tick to count, you shouldn't use this. but, it can do 30 frames per second if you write good code.
There are engines already built and out there, completely open for your use. Some of the best-selling games over the past couple years have been Mods built onto existing game engines. Why fuck with SDL/DirectX/ANYTHING when you can start off building a game, instead of an engine?
-- 'The' Lord and Master Bitman On High, Master Of All
SDL seems like the only choice. Unless you specifically want/need DOS support, or a few other platforms other libs will get you, SDL supports a large number and has gone beyond the critical mass of 1) things that use it 2) developers interested in it and 3) employed developers who spend time caring about it (Even if it's in their off time :)
SDL has also of course been used for a number of commercial games, I've used it myself with regard to two ports - One from windows which already used SDL and was extremely easy to port, and the other from Mac OS (not X) that was difficult to port and we added SDL to that so it can just as easily go to windows, BeOS, etc.
Check out ioquake3.org for a great, free, First-Person Shooter engine!
Sun has recently started paying more attention to java as a gaming platform and has been pushing java along with OpenGL as their solution.
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
OMG IT DOESNT RUN ON LINUX1@#!@#$ HOW DARE YOU RECOMMEND IT, NOOB
Wine X post in 3.. 2.. 1..
"OMG IT DOESNT RUN ON LINUX1@#!@#$ HOW DARE YOU RECOMMEND IT, NOOB"/I.
I know you're joking, but Linux isn't the platform I'd develop an indie game on. It'd be kind of like advertising viagra on Slashdot. You have to think about how big your audience would be here...
"Derp de derp."
There's an SDL port to KOS, a small operating system which runs on the dreamcast. So most of your experience with SDL will translate into an easy path to developing for an actual console.
Everything will be taken away from you.
I'm sure other people have pointed it out, but pygame is an excellent choice to get started. Python is fun and easy (*criminally* fun and easy), and a lot of the wrapper classes will use similar names as the real-deal c/c++ libraries.
...*so* much is taken care of for you already. Don't trust my code, as I haven't untarred my 10gb home directory backup (and I'm not going to) in order to tell you how easy PyGame makes things. :^)
Seriously. I made a graphical mp3 juke-box player (like for drunk people at parties), and my code to keep music playing looked something like:
def keep_music_playing():
if !pygame.sound.is_busy():
song = get_song()
pygame.sound.play( song )
else:
pass
def main():
thread.start( keep_music_playing, 5000 );
--Robert
If you're looking for something better than Direct3D, you should check out the Q engine by Qube Software.
:)
Q 3D Engine
(FREE DOWNLOAD for Windows & Linux)
You may be interested to note that this is produced by some of the same engineers who produced Direct3D. Can't be that bad then eh?
PS I once worked for Qube, so I'm probably biased.
Depends. Linux might be a better market to develop games on. It has a bunch of users are might be interested in a game. The origional Galatic Civilizations was a good game, but wouldn't have gone near as far if they targeted Windows instead of OS/2. By targeting a small system you can get a large percentage of users, while targeting windows means you only get a small percentage of a large number. Depending on how things work our exactly the latter can be much less than the former.
Remember there are few linux games. Those who run linux may be willing to buy a few games, and they only have a few games total to buy, so they can buy most of them. With Windows you have many different games to choose from, so those willing to buy games only buy a small number.
If you are making the next doom or MYST (by which I mean a game that explodes and everyone gets it, not any partular catagory of game) then target windows because you will get more sales. If you are making a standard game you have to set realistic expentations. Why would a windows person buy your ok game vs some other ok game? With linux it is why would someone buy your ok game vs not buying a game at all.
This is a marketing decision. If your expectations are reasonable you can make better decisions than if they are wrong. Of course it goes both way. If you make a game that could explode except it is limited it to linux you just lost a lot of potential sales.
Cross platform development makes a lot of sense. You target one platform, and once the game is out you do market research. Find that something else would make enough sales, and you port to that. In theory it is easy, in practice a little more difficult.
Not well supported. Doesn't work on MacOS, PS2, or GameCube. That's millions more machines. Because it's proprietary, it's unlikely to ever be supported on those playforms.
Apples to oranges. That's like saying, "OpenOffice not only handles word processing, but spreadsheets and presentation graphics as well. It's just not something you get from Microsoft Word."
DirectX is just a big label covering a number of different technologies (DirectSound, DirectDraw, Direct3D, DirectInput, DirectPlay, and other). The ties between them are minimal. OpenGL's match is Direct3D. If you want a similar package that provides a wide variety of support, look to toolkits like the SDL.
DirectX on the whole has largely stabilized. This is actually good, it means that developers can spend less time worrying about the API of the week a focus on writing games. The only part that is in heavy flux is Direct3D. Direct3D's more open counterpart, OpenGL, is also in heavy flux and manages to keep apace of Direct3D's new functionality.
Ultimately, the big problem is that DirectX is proprietary. If you want move to another system (like the growing Mac market) your use of DirectX becomes a burden to rewrite.
Search 2010 Gen Con events