As you might have noticed by reading this blog, a little hobby of mine is to play around with software, with a specific interest in casual game development. For quite a long time, I used a free tool called "Game Maker" for this purpose. It's a free (the lite version anyway) tool to make games for windows. It's really simple to use; Most of the work can be done by clicking and dragging - there's absolutely no low-level programming required. But recently, I moved on and started focussing on XNA game studio instead. Read on to find out why.
As with many drag and drop type tools, development speed and quality are very closely related to project size. For smaller games, Game Maker might be the top of the bill. You click "new game", and your rendering system, collision detection, level editor and whatnot are all in place. What better start could you wish for?
But then, after creating some smaller games, you move on to the real work. You want to create a game with multiplayer capabilities, a physics engine and a custom level editor. And you want to work cooperatively with a team of say 5 persons. *Dang*. The streamlined tool starts getting in the way. It's perfectly understandable; you can not logically expect a large game to sit comfortabely in the simple architecture of a tool that's designed to appeal to beginners. Whether you want to do one tiny thing that the built in level-editor does not support or you want to use complex inheritance trees or do advanced AI debugging... You'll collide with the boundaries sometime. And if you do, there's not really a way back (see point 3 below).
I know very well that creating advanced games is possible with tools like GM - Perhaps a thousand times cooler than anything I'll ever manage to put together. But from a coding/architecture point of view, I still say no. Full-scale projects require a different approach. Although you CAN make them with a tool like game maker, you're better off using something more custom. Because at one point, development will slow down, and you'll pay the price.
With XNA, I'm using C# and all possible tools to make coding easier, faster and more robust. I can architect the game code the way I want it. And if it turns into a mess, it's my own responsibility.
2) Gap between GML and professional experience
In my day job, I develop business applications in C#, using Visual Studio and Resharper. For game development, I use exactly the same toolset. I already had many moments at work where I could use something I learned during game development, and vice versa. I really like this interaction; it's nothing I'd easily give up. And if I'd choose to work with game maker and its scripting language (GML), that's exactly what'd happen.
You might say "It's better to know many different languages/environments". In another context, I might agree. But the gain of learning a specific scripting language that is used nowhere else is rather small. It's like learning a new language that you can speak only to one person.
3) No way back
Additionally, I find it hard to accept the fact that once you choose to use game maker, you're bound to keep using it. Once you start dragging and dropping and scripting, there's no possible way you can say: "Let's extract the code and move to [some completely other platform]". You have a bunch of scripts that are not meaningful in another environment. Most likely, they're not really clean and well tested either. You'll just throw them away and start from scratch, instead of converting them. While I'm quite confident that I can do exactly that last thing with XNA. Converting C# code to Java for example, is not that hard...
So let's wrap this up. In it's own way, game maker is a brilliant piece of software. Brilliant in the way it allows people with little experience to create games, have a lot of fun and learn many things about game development. Really, there's not one tool I'd rather recommend to people who are new to programming but want to create their own little game from scratch. But as any other tool, game maker needs to be used in the right perspective.
I used the learning perspective, but now I'm ready to move on. For actual development, that is. Because recently, I discovered another perspective to use GM... I still use it to create prototypes for my games. This requires some more explanation - I'll talk about this practice in a later post.