next »

[jmp]

You might also want to check out ZGameEditor.  According to the website, the editor itself is for Windows but the apps run on Linux and OS X as well.

If you decide not to use a game editor, then Python with a library like pyglet or Pygame is a great way to learn.  It’s a high-level language that is relatively easy to learn and, being a general-purpose programming language, much more powerful than any of the game editors I’ve seen.  The libraries provide all the necessary functions to load images, fonts, sounds etc. without limiting you too much.

[Taiko]

If you decide not to use a game editor, then Python with a library like pyglet or Pygame is a great way to learn.  It’s a high-level language that is relatively easy to learn and, being a general-purpose programming language, much more powerful than any of the game editors I’ve seen.  The libraries provide all the necessary functions to load images, fonts, sounds etc. without limiting you too much.

I'll second Pygame.  Python has a very clean syntax - very nearly pseudocode, at times - and in my experience is a great language to learn all the algorithm kinds of things that programmers need to know.  There are also numerous modules you can use like jmp said (I recommend PGU, personally).

Note though, that there are aspects of programming you won't learn with Pygame.  It's not going to force you to learn anything about memory management and pointers.  I would argue that you need to know that stuff, so eventually when you get more comfortable with programming check out C++ or Objective-C.

As for learning what constitutes good game design, I think the best way to learn is by doing.  Just make games and play games (checking out their source code if possible, most of the projects on the Pygame website allow you to do this).  Figure out what it is you like.  Have your friends play the games you make.  See what they like.  Eventually you will begin to understand what works and what doesn't.  Python again is useful here because it is wonderful for rapid development of prototypes.

[increpare]

Big problem with pygame is distribution of games - a lot of people have had headaches making binary versions, which is sad.

[Polly]

I'd recommend ZGameEditor as well. It is one of the few tools that lets you add / remove / modify assets & code while your game is running, which is ideal for rapid development / learning. Plus you can call OpenGL functions directly if you want to go low-level. Make sure to check out the video tutorials.

Edit - Fixed link

[Taiko]

Big problem with pygame is distribution of games - a lot of people have had headaches making binary versions, which is sad.

Py2exe isn't that hard to use.  Although I admit that creating a distribution script can be intimidating to someone new at programming, in reality you only need to find one for a game similar to yours and change a few variables.

But yes - I think the pygame devs need to consider rolling part of py2exe into their module or at least provide an extensive tutorial on their site.

[baconman]

Personally, I've had better luck starting with game engines. It gives you a better idea of the "logical flow" that programming naturally goes through; and without that insight, it's VERY EASY to get lost and/or overwhelmed at programming code. Programming code is so diverse it's feasibly impossible to "learn it all." And by that, I don't mean the commands, I mean the stuff you can make them do. I would much more prefer to "learn what code I need" as I go.

If you're grinding for better logic and self-improvement, programming code all the way; but if you're grinding and expecting some kind of tangible outcome; a project you can see progress with, use a game-builder like GM. If it fits within the scope of a particular genre or two; there's an even EASIER way about THAT, by looking up premade open-development engines (like StepMania, Frets Of Fire, M.U.G.E.N., RPG Maker, Fighter Maker, Zelda Classic, OpenSonic, Pinball Builder, etc.) that cater to the specific type of game.

Many kinds of games have easily-modifyable framework applications for GM/MMF as well. There's an absolutely insane level of irony in people "using a gamedev application like GM to make a gamedev application."

 

[Average Software]

There's an absolutely insane level of irony in people "using a gamedev application like GM to make a gamedev application."

 

As an April Fool's joke I once tried to get a devteam together to start writing Game Maker Maker.  It seemed like the next logical step.

[ஒழுக்கின்மை (Paul Eres)]

Now I'm curious about what famous games are made using GM, MMF, and even Construct.

no notable ones with construct yet that i know of, but for the other two, check out these lists:

http://tig.wikia.com/wiki/Category:Game_Maker_games
http://tig.wikia.com/wiki/Category:MMF2_games

most famous for gm are probably iji, spelunky, barkley shut up and jam gaiden, cactus's games, the jumper series, runman, messhof's games, seiklus, etc.

[Taiko]

Now I'm curious about what famous games are made using GM, MMF, and even Construct.

no notable ones with construct yet that i know of, but for the other two, check out these lists:

http://tig.wikia.com/wiki/Category:Game_Maker_games
http://tig.wikia.com/wiki/Category:MMF2_games

most famous for gm are probably iji, spelunky, barkley shut up and jam gaiden, cactus's games, the jumper series, runman, messhof's games, seiklus, etc.

My favorite game out of MMF2 (and possibly my favorite indie game of all time) is Knytt.  If you want to see what the software is capable of (and a great lesson in atmospheric game design), be sure and check it out.

[Dacke]

There are actually three levels you have to choose from:

1. Programming stuff from scratch.
Many programmers (me included) are very tempted by this. It can be extremely fun and educational. You seldom get anything to show for it, though.

2. Programming using a game library.
Good game libraries can give you a good feel for the flow of game design. People who fully embrace the use of a library tend to get actual games made.

Flixel (for example) is excellent at this. It gives you all the building blocks you need to slap a game together. But you get all the power of standard programming. That means you can use great IDEs, debuggers, code libraries and clever algorithms.

(But I wouldn't recommend using Flash, on the other hand.)

3. Using a game making program.
A good way to get games made fast.


People tend to bunch 1. and 2. together. But I actually think 2. and 3. are more closely related, in many cases.

Personally, I find Game Maker very confusing and messy. I don't understand how people manage to make anything sensible with it. (I guess this is how non-programmers feel about pure code.)

I think it takes quite a bit of time to learn to work with (and around) a system. If you already know how to program, I think it could be faster to to learn a good game library. The skills you acquire will probably be a bit more useful, too.

[Triplefox]

Personally, I find Game Maker very confusing and messy. I don't understand how people manage to make anything sensible with it. (I guess this is how non-programmers feel about pure code.)

I think there is more to this statement than meets the eye. As a learner, it can actually help to get away from the perfectionism and declare - to yourself, or to the world - "Yeah, GM sucks, what of it?" When you read programming literature you get fed a whole load of baloney about doing things "properly," not all of which is correct, and it comes up so often that if you are a sensitive person who cares about code quality, you'll end up saying to yourself, "OMG am I doing anything correctly?" It's meant to help, but it can end up being a huge distraction from more substantial lessons about programming. A lot of the rules people come up with are geared to a certain kind of application domain and make no sense outside of that domain, and game programming encounters that conflict all the time because the real-time, state-heavy requirements force them in quite a different direction from the commonplace GUI/Web/database apps.

Regardless of the environment you're building from, you're going to be facing the same kinds of technical challenges eventually, hence why experienced programmers tend to become pretty environment-agnostic. A messy starting situation like that of GM or Flash's timeline can end up being quite helpful in making you drop the presumptions and get to work. Appreciation of the industrial-level developer tools can come later, once you start seeing the kinds of solutions they can provide.

This form of argument - that the "best thing" isn't always the best - extends quite a long ways throughout technology. See the Worse is Better series for more in this vein.

So my vote is for the tool that gets you building stuff, or at least the tool with the documentation you like the most. Support resources can make all the difference.

[Dacke]

I guess that could make sense. I always get more done, when not worrying about clarity in my code. I'm not sure if using worse IDEs and languages would help too, though? But that's not really what I was talking about.

It's more that there are millions of little buttons and symbols that claim to do stuff in Game Maker. I try to use them, but very rarely get the result I expected. I try to input code, but can never make it do what I want.

Based on that, I made an unqualified guess:
"If you already are a fairly experienced programmer, a good game library will give you the same support, but confuse you less."

[ஒழுக்கின்மை (Paul Eres)]

most gm users don't actually use those buttons and symbols, you know. the only buttons and symbols i use in my gm games are 'creation', 'step, 'draw', 'alarm' events, and the 'run script' action. the rest is all coded. i don't really know of any major gm user who uses drag and drop rather than code except the early games of mr chubigans.

[Dacke]

Especially given that, I can't grasp why you would want to work in a program like that. It just seems like a homebrew language/library, wrapped in a strange out-of-date program. Which is why I call it confusing and messy. It feels like it would be much easier to work with, for example, Flixel.

[ஒழுக்கின்மை (Paul Eres)]

well, a lot of things are handled for you that aren't in libraries like flixel. these include:

a) resource handling. it has an easy way to add and take away graphical and audio resources, and an automatic system for keeping track of them (automatic enumerations). same thing for rooms, paths, timelines, and all kinds of other non-data resources. same thing for fonts. just being able to select a font from all your installed fonts and have it turned into a bunch of bitmap images automatically and then embedded into the game file and ready to be used in the game is convenient. i remember having to manually build images of letters in c and qbasic in the 90s if i didn't want to use the default dos font and it wasn't fun, nobody should have to go through that much work just to add a new font to their game.

b) it has a similar thing for object handling. instead of requiring you to make your own array of every instance of a particular object, it does it for you, and you can just do something like with(obj_goomba) instance_destroy(); to kill all the goombas. this is very effective and important, the with() statement was the major thing i missed when i tried to learn AS3. requiring that the programmer manually keep track of every instance in the game by adding each one to their own arrays is just cruel when it could so easily be automated. basically with() does 'take an object, and inside every instance of that type of object, perform the following code'. i haven't found any way to do that in any other language as easily. with() is like the crown jewel of gml.

c) in-built level editor. it's not the best level editor, but most game libraries like allegro and pygame and flixel and such don't include a level editor at all. so you'd either have to code your own or do without. sometimes the gm level editor isn't sufficient and often people build their own level editors in GM itself for their games (i've done this a few times) but it's still an important way to start creation on a game, a way to make the levels in a game until you code your own level editor, which is important when in the very early stages of making a game.

d) there are other things included that you don't have to code your own or find your own libraries for: particle system, collision handling, basic physics like gravity and friction and speed and direction, a* pathfinding, and so on. of course finding those each on your own is more customizable, but there's an advantage in just having a collection of such things ready to use. libraries like flixel include some of these things, but not all -- i don't *think* (i haven't used it in a while) flixel has a particle system or physics or pathfinding. you'd have to find libraries for those separately; gm covers the functionality of probably 20-30 libraries that you'd have to find on your own.

e) i think this is also true of flash and python (so isn't an advantage over them), but it's an interpreted language, which has some advantages and disadvantages: it's slower, but you can execute code while in the game itself: i can just press f11 in my game and type in some code, using actual function names and variables that i'd use anywhere else in the game code to create the game with, which has come in useful countless time. and it also makes it easier to debug when what's being run is the code itself rather than machine code.

[gimymblert]

Three things you don't want if you are a lone game maker (you do everything from art to code): Feature creep, low level coding and clean code. Trust me

[Dacke]

Thank you for the explanation. It makes a bit more sense now.

A small comparison of Flixel and GM, based on your points.

A) A good IDE can do some of that for you. But if done in a good way, that would seem like a good thing to have. I'm not a fan of how GM does it, though.

B) That sounds neat. But also like something pure library would be able to do, too. Not sure if Flixel does it, as I haven't used it that much (and never touched version 2)

C) There are several free level editors you can use. They export files, that can be natively used with Flixel.

D) Flixel has a particle system, collision handling, basic physics like gravity and friction and speed and direction. This is the important part to me, and why I think GM and Flixel are comparable.

On the other hand: With a bigger language, there are many more already existing libraries you can use for all sorts of things. That's especially interesting if you are writing a simulation or AI of some sort.

E) I would be very surprised if GM has better overall debugging than a modern IDE.

[fraxcell]

Three things you don't want if you are a lone game maker (you do everything from art to code): Feature creep, low level coding and clean code. Trust me

What's wrong with clean code?

[muku]

Three things you don't want if you are a lone game maker (you do everything from art to code): Feature creep, low level coding and clean code. Trust me

What's wrong with clean code?

Yeah, this. I've done several compo games under a tight deadline, managed to build up lots of low-level code (font rendering, no less) over the course of those mini-projects, and several people commented favorably on the cleanness of the code. So I think it's entirely possible. My Ludum Dare entry even did quite ok.

[gimymblert]

By clean i mean UBER CLEAN AND EFFICIENT.

Sometimes kitchen size project better have some hacks and shortcut left in inefficient jobs that does the jobs. Especially when your are not a coder (me!). Fun cannot always be plan ahead and small gameplay change can break your code, especially if you are new to a genre or do something completely innovative. Clean code come with safe design.