msdn c# video game development webcasts
December 30, 2005 5:27 AM Subscribe
"Video Game Development - Learn to write C# the fun way." is a series of 11 1-hour long msdn webcasts starting jan16th, needs registration (c# express is free, 430mb iso here)
What? What do you mean, "rpgmaker owns pygame?" Literally, as in it's not open source? Or figuratively?
Speak, damn you!
posted by JHarris at 8:22 AM on December 30, 2005
Speak, damn you!
posted by JHarris at 8:22 AM on December 30, 2005
The license page says it's LGPL. Is there something about it I don't know?
(Yeah, it doesn't take a lot to worry me.)
posted by JHarris at 8:24 AM on December 30, 2005
(Yeah, it doesn't take a lot to worry me.)
posted by JHarris at 8:24 AM on December 30, 2005
But yeah, c# sucks. Microsoft is trying to hook nerds early, like the cigarette companies! Evil bastards.
posted by delmoi at 8:26 AM on December 30, 2005
posted by delmoi at 8:26 AM on December 30, 2005
Ah. Well from doing a quickie search for it....
I'm not impressed. It looks more like the kind of thing one could use to reproduce old games, or new games that play an awful lot like old games, instead of creating unique kinds of play.
So, thanks but no thanks.
posted by JHarris at 8:28 AM on December 30, 2005
I'm not impressed. It looks more like the kind of thing one could use to reproduce old games, or new games that play an awful lot like old games, instead of creating unique kinds of play.
So, thanks but no thanks.
posted by JHarris at 8:28 AM on December 30, 2005
Bort writes "Why? Because Microsoft is evil?"
No, because its not based on any standards document, it's mostly a rip-off of Java (which is also flawed), and it's proprietary.
posted by orthogonality at 9:03 AM on December 30, 2005
No, because its not based on any standards document, it's mostly a rip-off of Java (which is also flawed), and it's proprietary.
posted by orthogonality at 9:03 AM on December 30, 2005
Its sole purpose is to lock in into other MS products. Don't know what the mono guys are smoking.
posted by roue at 9:09 AM on December 30, 2005
posted by roue at 9:09 AM on December 30, 2005
figuratively that would be.. rpgmaker is just pretty sweet and pygame has no advantages except the learning experience it gives you (rpgmaker is clickypointy and scripting)
posted by suni at 9:18 AM on December 30, 2005
posted by suni at 9:18 AM on December 30, 2005
I think C# is less a java rip-off than a Delphi iteration, given its pedigree.
posted by phearlez at 9:28 AM on December 30, 2005
posted by phearlez at 9:28 AM on December 30, 2005
Care to elaborate upon that sweetness suni? How can rpgmaker, which is ultimately a parameter-based fangled editor even if it does have a scripting facility, be sweeter than Python+pygame, which is an actual language (even if it is interpreted)?
Put it this way: my own game is unlikely to be possible in rpgmaker, so its sweetness seems lacking from my perspective.
posted by JHarris at 9:42 AM on December 30, 2005
Put it this way: my own game is unlikely to be possible in rpgmaker, so its sweetness seems lacking from my perspective.
posted by JHarris at 9:42 AM on December 30, 2005
c# sucks
Why? Because Microsoft is evil?
No, because it seems so unnecessary. I recently took over a .NET/C# project, and it's such a blatant rip-off of Java it's not even funny. Its sole purpose for existing is to get you to use MS products.
posted by mkultra at 9:48 AM on December 30, 2005
Why? Because Microsoft is evil?
No, because it seems so unnecessary. I recently took over a .NET/C# project, and it's such a blatant rip-off of Java it's not even funny. Its sole purpose for existing is to get you to use MS products.
posted by mkultra at 9:48 AM on December 30, 2005
It's only free if your freedom's worth nothing.
That's some puzzling logic. Also, didn't know Richard Stallman was a MeFite, cool.
posted by knave at 9:50 AM on December 30, 2005
That's some puzzling logic. Also, didn't know Richard Stallman was a MeFite, cool.
posted by knave at 9:50 AM on December 30, 2005
sweetness = making one-man-projects of gba/snes quality possible
posted by suni at 9:54 AM on December 30, 2005
posted by suni at 9:54 AM on December 30, 2005
sweetness = making one-man-projects of gba/snes quality possible
Right. You're arguing about tools for doing very different things. See below.
Also, didn't know Richard Stallman was a MeFite, cool.
Also, didn't know that wanting to be able to change the infrastructure one's game is written on makes one a raging overzealous GPL guy, the clear implication of your silly comment. Today is a day to learn things!
Seriously.
You're comparing two different tools with different applications. If I'm making a standalone game, which may or may not fit the assumptions one of the myriad of "game-maker" tools out there make, I want to be able to go in and change low level stuff if I need to. Maybe I want to hadle networking differently - maybe most of those kits won't even work for networked games. I can't do that if I don't have source - again, I don't need to if I want to make a standard Nintendo style RPG.
So you're arguing about, essentially, whether a spreadsheet program is better than C. If all need is a spreadsheet, you'd be a fool to write it in C. If you want to make an Application for filtering email, you'd be a fool to build it in Excel.
And lastly, if you wanted to write in C and only wanted to use libraries you could get in and tweak, anyone who called you Richard Stallman would be betraying their total misunderstanding of the fundamental issues involved in Software Development and Property Rights, Human Dignity and Hope, and indeed, the Future of Civilization As We Know It.
posted by freebird at 10:04 AM on December 30, 2005
Right. You're arguing about tools for doing very different things. See below.
Also, didn't know Richard Stallman was a MeFite, cool.
Also, didn't know that wanting to be able to change the infrastructure one's game is written on makes one a raging overzealous GPL guy, the clear implication of your silly comment. Today is a day to learn things!
Seriously.
You're comparing two different tools with different applications. If I'm making a standalone game, which may or may not fit the assumptions one of the myriad of "game-maker" tools out there make, I want to be able to go in and change low level stuff if I need to. Maybe I want to hadle networking differently - maybe most of those kits won't even work for networked games. I can't do that if I don't have source - again, I don't need to if I want to make a standard Nintendo style RPG.
So you're arguing about, essentially, whether a spreadsheet program is better than C. If all need is a spreadsheet, you'd be a fool to write it in C. If you want to make an Application for filtering email, you'd be a fool to build it in Excel.
And lastly, if you wanted to write in C and only wanted to use libraries you could get in and tweak, anyone who called you Richard Stallman would be betraying their total misunderstanding of the fundamental issues involved in Software Development and Property Rights, Human Dignity and Hope, and indeed, the Future of Civilization As We Know It.
posted by freebird at 10:04 AM on December 30, 2005
mkultra, Java is, lo and behold, a proprietary Sun product (mostly). As for C# versus Java, having developed in both of them, I think C# brings enough to the table that's different, like user created value types, that it wasn't a waste of effort. I'm hardly what you would call a Microsoft fanboy, but I think they actually did something pretty damn decent with C#.
posted by KirTakat at 10:04 AM on December 30, 2005
posted by KirTakat at 10:04 AM on December 30, 2005
I'm not impressed. It looks more like the kind of thing one could use to reproduce old games, or new games that play an awful lot like old games, instead of creating unique kinds of play.
It's actually a good way to learn. I learned a ton about Java (and more importantly, the geometry and trig necessary for 3D gaming) by writing an Asteroids clone, then enhancing it with all kinds of stuff (such as Sidewinder-like missiles that track targets).
It's not a study in gameplay, but in programming.
As for C#... we use it for interface stuff at work because it's easier than MFC. Overall I think I prefer it to Java, but there were some odd choices in there that piss me off (like any language). I'm more at home in C++.
posted by Foosnark at 10:07 AM on December 30, 2005
It's actually a good way to learn. I learned a ton about Java (and more importantly, the geometry and trig necessary for 3D gaming) by writing an Asteroids clone, then enhancing it with all kinds of stuff (such as Sidewinder-like missiles that track targets).
It's not a study in gameplay, but in programming.
As for C#... we use it for interface stuff at work because it's easier than MFC. Overall I think I prefer it to Java, but there were some odd choices in there that piss me off (like any language). I'm more at home in C++.
posted by Foosnark at 10:07 AM on December 30, 2005
sweetness = making one-man-projects of gba/snes quality possible
I don't want to make a one-man project of gba/snes quality. I want to make a one-man project of Rogue/Hack quality. You may consider that a step down, but I sure don't.
It's actually a good way to learn. I learned a ton about Java (and more importantly, the geometry and trig necessary for 3D gaming) by writing an Asteroids clone, then enhancing it with all kinds of stuff (such as Sidewinder-like missiles that track targets).
I got that kind of learning out of my system over a decade ago. My biggest development problem these days is connecting my ancient C64 coding skills (which included assembly and low-level hardware wrangling, but nothing object-oriented) with what's needed to make a game available to more than a handful of players today.
posted by JHarris at 10:21 AM on December 30, 2005
I don't want to make a one-man project of gba/snes quality. I want to make a one-man project of Rogue/Hack quality. You may consider that a step down, but I sure don't.
It's actually a good way to learn. I learned a ton about Java (and more importantly, the geometry and trig necessary for 3D gaming) by writing an Asteroids clone, then enhancing it with all kinds of stuff (such as Sidewinder-like missiles that track targets).
I got that kind of learning out of my system over a decade ago. My biggest development problem these days is connecting my ancient C64 coding skills (which included assembly and low-level hardware wrangling, but nothing object-oriented) with what's needed to make a game available to more than a handful of players today.
posted by JHarris at 10:21 AM on December 30, 2005
While I have a Genetic Predisposition to hate C# for any number of reasons, I have a couple friends whose judgement I strongly respect who say it's great. So, until I have a reason to actually do something with it, I'll remain agnostic at least.
Here's a big question - are these tutorials, and C# in general, as MS-Windows specific as I suspect they are?
posted by freebird at 11:03 AM on December 30, 2005
Here's a big question - are these tutorials, and C# in general, as MS-Windows specific as I suspect they are?
posted by freebird at 11:03 AM on December 30, 2005
Its sole purpose is to lock in into other MS products. Don't know what the mono guys are smoking.
I think they are smoking something that makes them want to make it more widely useful so it's not so much of a Microsoft lock-in.
posted by kindall at 11:17 AM on December 30, 2005
I think they are smoking something that makes them want to make it more widely useful so it's not so much of a Microsoft lock-in.
posted by kindall at 11:17 AM on December 30, 2005
If you know some C and want a game library to do all of the hard bits, check out ClanLib.
I once wrote a complete game in 3 hours using it.
I also endorse pygame for those people who don't know C. Python's a great language for learning to program games.
C#, on the other hand, is not. The list of webcasts here appear to be way more about writing engines and low level stuff then writing a GAME. And, if you're writing an engine, you shouldn't be doing it in C# ANYWAY.
posted by JZig at 11:32 AM on December 30, 2005
I once wrote a complete game in 3 hours using it.
I also endorse pygame for those people who don't know C. Python's a great language for learning to program games.
C#, on the other hand, is not. The list of webcasts here appear to be way more about writing engines and low level stuff then writing a GAME. And, if you're writing an engine, you shouldn't be doing it in C# ANYWAY.
posted by JZig at 11:32 AM on December 30, 2005
Also, I love how a one hour webcast teaches "game loop, input, collision, behavior, rendering, and sound" (the second one listed).
Oh, wait. Look at the bottom of the page. The advertised webcasts are the more advanced webcast sequels to some simpler ones they did last year. THOSE will be much more relevant to the type of games beginners make. They're all already available too.
posted by JZig at 11:35 AM on December 30, 2005
Oh, wait. Look at the bottom of the page. The advertised webcasts are the more advanced webcast sequels to some simpler ones they did last year. THOSE will be much more relevant to the type of games beginners make. They're all already available too.
posted by JZig at 11:35 AM on December 30, 2005
I make a living writing C# code, and I'll say that I like it quite a bit.
I will also say that its usefulness is compounded by the fact that C#/.NET/IIS/SQL Server all work together more-or-less seamlessly.
Some will take this as evidence of Microsoft lock-in. Those people would have a point - If you use one of those tools, chances are that you use all of them. However, I don't really mind the lock-in, and I think it's worth it to have a well-integrated environment.
Really, the only bad part about MS's development environment is that you have to pay for all the tools. Still, this is an up-front cost, and I would say that it's money well spent.
posted by Afroblanco at 11:40 AM on December 30, 2005
I will also say that its usefulness is compounded by the fact that C#/.NET/IIS/SQL Server all work together more-or-less seamlessly.
Some will take this as evidence of Microsoft lock-in. Those people would have a point - If you use one of those tools, chances are that you use all of them. However, I don't really mind the lock-in, and I think it's worth it to have a well-integrated environment.
Really, the only bad part about MS's development environment is that you have to pay for all the tools. Still, this is an up-front cost, and I would say that it's money well spent.
posted by Afroblanco at 11:40 AM on December 30, 2005
No, because its not based on any standards document, it's mostly a rip-off of Java (which is also flawed), and it's proprietary.
In point of fact, BOTH the C# language AND the CLI are fully described by ECMA standards. That would contravene the notion that it's "proprietary" (especially given the existence of a completely indepedent implementation). As for being a "rip-off of Java," that's laughable. Is any language with object-orientation and intermediate compilation a Java wannabe? C# is without a doubt the best language for building applications on Windows today.
posted by kjh at 11:42 AM on December 30, 2005
In point of fact, BOTH the C# language AND the CLI are fully described by ECMA standards. That would contravene the notion that it's "proprietary" (especially given the existence of a completely indepedent implementation). As for being a "rip-off of Java," that's laughable. Is any language with object-orientation and intermediate compilation a Java wannabe? C# is without a doubt the best language for building applications on Windows today.
posted by kjh at 11:42 AM on December 30, 2005
jh, don't be grumpy, i wish you fun and some good learning when working on your rogue game : )
posted by suni at 11:46 AM on December 30, 2005
posted by suni at 11:46 AM on December 30, 2005
c# sucks
Why? Because Microsoft is evil?
About a year ago, I set out to write a little screensaver for my own amusement.
The screensaver was to capture an image from an attached webcam, do some image processing and display it on the screen.
Since this was on a Windows platform and MS publishes an excellent API for webcam access (DirectShow), I naturally decided to use C# for the project.
Imagine my surprise when I found out that there was no simple way of accessing Microsoft's API using Microsoft's own language on a Microsoft platform. There was an ugly and combersome hack available, but basically any webcam access had to be done using C/C++.
Fortunately it turned out that Java (which, as you know, is not a Microsoft product) had no problems interfacing the API and the webcam.
So, as far as C# is intended to bring the Microsoft APIs and the ease of use of Java together, it's a miserable failure.
To be fair, it does have some nice features.
posted by spazzm at 1:11 PM on December 30, 2005
Why? Because Microsoft is evil?
About a year ago, I set out to write a little screensaver for my own amusement.
The screensaver was to capture an image from an attached webcam, do some image processing and display it on the screen.
Since this was on a Windows platform and MS publishes an excellent API for webcam access (DirectShow), I naturally decided to use C# for the project.
Imagine my surprise when I found out that there was no simple way of accessing Microsoft's API using Microsoft's own language on a Microsoft platform. There was an ugly and combersome hack available, but basically any webcam access had to be done using C/C++.
Fortunately it turned out that Java (which, as you know, is not a Microsoft product) had no problems interfacing the API and the webcam.
So, as far as C# is intended to bring the Microsoft APIs and the ease of use of Java together, it's a miserable failure.
To be fair, it does have some nice features.
posted by spazzm at 1:11 PM on December 30, 2005
So, as far as C# is intended to bring the Microsoft APIs and the ease of use of Java together, it's a miserable failure.
And you're basing this on your single experience of trying to get your webcam thing to work?
posted by Afroblanco at 1:29 PM on December 30, 2005
And you're basing this on your single experience of trying to get your webcam thing to work?
posted by Afroblanco at 1:29 PM on December 30, 2005
Afroblanco: I'm saying that, based on my experience, someone who wants to use Microsoft's DirectShow API on a Microsoft platform has to find some onther way of doing it than using Microsoft's own language, unless they want to apply some dodgy hack.
If you have information to the contrary, please show it to us instead of making snarky comments.
posted by spazzm at 1:36 PM on December 30, 2005
If you have information to the contrary, please show it to us instead of making snarky comments.
posted by spazzm at 1:36 PM on December 30, 2005
I don't think I was being snarky. You made this rather general statement :
So, as far as C# is intended to bring the Microsoft APIs and the ease of use of Java together, it's a miserable failure.
And I was asking you if you formed that opinion soley on the basis of your experience with your webcam project.
Where's the snark?
posted by Afroblanco at 3:15 PM on December 30, 2005
So, as far as C# is intended to bring the Microsoft APIs and the ease of use of Java together, it's a miserable failure.
And I was asking you if you formed that opinion soley on the basis of your experience with your webcam project.
Where's the snark?
posted by Afroblanco at 3:15 PM on December 30, 2005
...Microsoft...evil...assorted hatin'...etc...
Did I click the link for slashdot by mistake? Get over it...
posted by Artw at 3:35 PM on December 30, 2005
Did I click the link for slashdot by mistake? Get over it...
posted by Artw at 3:35 PM on December 30, 2005
C# is a solid language, and was designed by one of the top language designers in the world (his previous projects were Turbo Pascal and Delphi).
It's also, IMHO, the best choice for building GUI applications on Win32 that you intend to redistribute. If you don't choose C#, consider your alternatives:
Visual Basic or maybe Real Basic: eww, not for anything other than a prototype.
Java: hahahahaha. wait, wait. hahahahahaha
C++: a solid choice, but huge cost of entry and can be a debugging nightmare compared to managed code with garbage collection.
Perl/Python/Ruby no way, not for a native GUI app being redistributed to the general public.
posted by Bluecoat93 at 7:02 PM on December 30, 2005
It's also, IMHO, the best choice for building GUI applications on Win32 that you intend to redistribute. If you don't choose C#, consider your alternatives:
Visual Basic or maybe Real Basic: eww, not for anything other than a prototype.
Java: hahahahaha. wait, wait. hahahahahaha
C++: a solid choice, but huge cost of entry and can be a debugging nightmare compared to managed code with garbage collection.
Perl/Python/Ruby no way, not for a native GUI app being redistributed to the general public.
posted by Bluecoat93 at 7:02 PM on December 30, 2005
C#'s problem: Not easily cross platform (I'd have to go Mono, and I've not even begun looking into that).
Visual Basic: Same, and worse.
Java: Being used in surprising places these days, remember, the coolest bittorrent client in existence is written in it....
C++: Possible, but for a return to development after a long period I'd like to go with something in which I can get code written quickly. And you already mentioned the garbage collection problem, although I kind of like the rigor required from discarding all your own memory.
Perl/Python/Ruby: You lump these three together, when to my eyes it is not necessarily true that they are lumpable. There are some pygame games that look a fair bit better than they have any right looking. An example.
In any case, games don't have to use the native GUI. And I'm writing mine in Python because it's quick to get something down in code, and if I don't get something going quickly I tend to lose momentum fast in the face of my master's degree studies.
posted by JHarris at 7:17 PM on December 30, 2005
Visual Basic: Same, and worse.
Java: Being used in surprising places these days, remember, the coolest bittorrent client in existence is written in it....
C++: Possible, but for a return to development after a long period I'd like to go with something in which I can get code written quickly. And you already mentioned the garbage collection problem, although I kind of like the rigor required from discarding all your own memory.
Perl/Python/Ruby: You lump these three together, when to my eyes it is not necessarily true that they are lumpable. There are some pygame games that look a fair bit better than they have any right looking. An example.
In any case, games don't have to use the native GUI. And I'm writing mine in Python because it's quick to get something down in code, and if I don't get something going quickly I tend to lose momentum fast in the face of my master's degree studies.
posted by JHarris at 7:17 PM on December 30, 2005
C#'s problem: Not easily cross platform
Y'know, I'm always hearing people say this as a big detractor for C#. Seriously, though, how often do you really want to port an application? While there are notable exceptions, I would say that this is something that doesn't really effect the large majority of developers.
posted by Afroblanco at 9:21 PM on December 30, 2005
Y'know, I'm always hearing people say this as a big detractor for C#. Seriously, though, how often do you really want to port an application? While there are notable exceptions, I would say that this is something that doesn't really effect the large majority of developers.
posted by Afroblanco at 9:21 PM on December 30, 2005
Bluecoat93, why would you say Perl/Python/Ruby are bad choices for GUI apps being redistributed to the general public?
posted by parallax7d at 9:32 PM on December 30, 2005
posted by parallax7d at 9:32 PM on December 30, 2005
[inhales deeply]
NEEEEERRRDDDDSS!!!!!
[runs away]
posted by phylum sinter at 3:38 AM on December 31, 2005
NEEEEERRRDDDDSS!!!!!
[runs away]
posted by phylum sinter at 3:38 AM on December 31, 2005
Y'know, I'm always hearing people say this as a big detractor for C#. Seriously, though, how often do you really want to port an application? While there are notable exceptions, I would say that this is something that doesn't really effect the large majority of developers.
It effects me though. You know, the one who's writing a game. I'd like for it to be playable by Linux-speaking friends. So, yeah, it's important.
posted by JHarris at 6:31 AM on December 31, 2005
It effects me though. You know, the one who's writing a game. I'd like for it to be playable by Linux-speaking friends. So, yeah, it's important.
posted by JHarris at 6:31 AM on December 31, 2005
Afroblanco writes "Seriously, though, how often do you really want to port an application? "
What apps are you writing that would be useful to a Windows user, but not to a Mac or linux usr? Unless your app is a Windows maintenance utility (Windows registry editor, etc.) shouldn't you assume that portability is a consideration?
That said, C# can be written portably, but only if you isolate all system calls in classes that each have a sibling class implementing the same functionality on the other OS. And if you're planning to do that, why not just use something like wxWindows, which provides that out of the box?
posted by orthogonality at 10:41 AM on December 31, 2005
What apps are you writing that would be useful to a Windows user, but not to a Mac or linux usr? Unless your app is a Windows maintenance utility (Windows registry editor, etc.) shouldn't you assume that portability is a consideration?
That said, C# can be written portably, but only if you isolate all system calls in classes that each have a sibling class implementing the same functionality on the other OS. And if you're planning to do that, why not just use something like wxWindows, which provides that out of the box?
posted by orthogonality at 10:41 AM on December 31, 2005
orthogonality - I'm talking about market share. Linux and Mac have very small market shares when compared to the PC platform. I'm not saying that it isn't worth it to develop for these platforms. I'm just saying that it's such a small factor, that I can't see it significantly tipping the scales towards Java for most people.
But yes, if you are really concerned about cross-platform compatibility, you may want to consider Java a bit more.
(Although I don't have much experience with Mono, and for all I know, it could be quite good. Also, for a long time, Java had a "Write once, debug everywhere" reputation, although things could have gotten better since then.)
posted by Afroblanco at 12:17 PM on December 31, 2005
But yes, if you are really concerned about cross-platform compatibility, you may want to consider Java a bit more.
(Although I don't have much experience with Mono, and for all I know, it could be quite good. Also, for a long time, Java had a "Write once, debug everywhere" reputation, although things could have gotten better since then.)
posted by Afroblanco at 12:17 PM on December 31, 2005
For cross-platform GUI applications, Java is the popular answer BUT you quickly discover that "write once, run anywhere" is more like "write once, debug everywhere". The user experience is also almost always nowhere close to following the UI standards of the various platforms (Java apps on Mac don't feel "Mac-like", etc.) without a LOT of work building platform-specific front-ends.
If I were building a true cross-platform (win32, mac, maybe Linux) native GUI app I actually WOULD probably choose Real Basic, since in my experience it does a pretty good job of delivering a native look and feel on both Mac and win32.
However, the original focus of this post was on win32 applications. I excluded (and lumped together) Perl, Python, and Ruby mainly because it's an extremely non-trivial exercise to build an application in those languages that my mom could download and run. I don't want to have to tell her "ok, now go to www.python.org, download and install Python. Now go to (pygame web site) and download that. Now go to (some other dependency) and download that. ad infinitum, ad nauseum). It's true that there are workarounds (py2exe and the like) that attempt to build a single .exe containing the Python runtime and all dependent libraries) but in my experience they're quite difficult to get right, especially for something like a game where you're likely to have quite a few non-core libraries (pygame, SDL, etc.). They also build monstrously huge executables.
For "serious" native win32 development, I still don't see any real alternatives to C# or C++. Of those two, C# seems to be the more attractive option, particularly since you can build the 99% of your application that isn't performance intensive in C#, taking advantage of all the language's features for rapid and high-quality development. Then, once you start profiling and find the tiny bits of your code that actually are performing poorly, you can drop down to C++ and optimize.
posted by Bluecoat93 at 1:36 PM on December 31, 2005
If I were building a true cross-platform (win32, mac, maybe Linux) native GUI app I actually WOULD probably choose Real Basic, since in my experience it does a pretty good job of delivering a native look and feel on both Mac and win32.
However, the original focus of this post was on win32 applications. I excluded (and lumped together) Perl, Python, and Ruby mainly because it's an extremely non-trivial exercise to build an application in those languages that my mom could download and run. I don't want to have to tell her "ok, now go to www.python.org, download and install Python. Now go to (pygame web site) and download that. Now go to (some other dependency) and download that. ad infinitum, ad nauseum). It's true that there are workarounds (py2exe and the like) that attempt to build a single .exe containing the Python runtime and all dependent libraries) but in my experience they're quite difficult to get right, especially for something like a game where you're likely to have quite a few non-core libraries (pygame, SDL, etc.). They also build monstrously huge executables.
For "serious" native win32 development, I still don't see any real alternatives to C# or C++. Of those two, C# seems to be the more attractive option, particularly since you can build the 99% of your application that isn't performance intensive in C#, taking advantage of all the language's features for rapid and high-quality development. Then, once you start profiling and find the tiny bits of your code that actually are performing poorly, you can drop down to C++ and optimize.
posted by Bluecoat93 at 1:36 PM on December 31, 2005
« Older BBC Open News Archive | Sand, Hell and Kittens Newer »
This thread has been archived and is closed to new comments
posted by JHarris at 6:01 AM on December 30, 2005