next »

[Paul Eres]

languages themselves are not "powerful" or "unpowerful", computers or engines are. languages also aren't "hard" or "easy" -- some might just take more memorization than others, or be higher-level than others (which gives you less control at the expense of less code required to do the same things)

and gm's engine is in some ways faster than adobe flash. as3 only has partial hardware acceleration for instance, whereas gm has full hardware acceleration

still i would not recommend gm over as3 or vice versa, i think both are good choices depending on your needs/desires. if your goal is just to learn to program, then learn c or basic, they're the best starting points. if your goal is to learn how to design games, use engines which don't require much programming, such as rpgmaker, or make mods of existing games

[Darren_D_Daley]

For learning programming I think C is a bit too steep for someone starting out, especially if you plan to make a game in it as it's takes quite a bit of work to get something up and running.

[Paul Eres]

that's how my generation learned programming. again i think the idea that some languages are "harder" than others is ridiculous. it's all imaginary perception, like those people who are afraid of math and then make it difficult for themselves through the fear

i found as3 much more time-consuming to learn than c, for instance. but that was mainly because i was used to procedural programming languages and found object-oriented languages bizarre and weird. as a side note i definitely think that someone's first language should be procedural, not object-oriented; not because one is easier than the other, but because one teaches you better programming practices than the other, and has fewer concepts to learn at once

and i don't think it's any harder to get a game up and running in c as in any other language. the only thing that helps with that are pre-made libraries and engines, and there are plenty of those in c too (e.g. allegro, fastgraph). it's not the language that matters, it's how much pre-built stuff you use with a language, and most languages have some pre-built stuff that you can use

i also think it's a bad idea to try to learn game development and programming at once; learn one and then learn the other. you learn programming by programming, and you learn game development by making games (usually in engines or by making levels/mods of existing games); it's too much to try to learn both at once. programming is also much easier to learn, it takes a few months, whereas game development takes much longer to get good at

[MoOshiCow]

Kind of going on another tangent here, but learning programming, asset creation, game design, etc is one thing..but working with other programmers/artists is a whole new world, in my opinion.

The main concern I have when I see these "12 year old needs help making his/her dream game", is that working with one other person is no small task, let alone working with "2 programmers and 2 artists". And if this is really "your" dream game, then you'll probably have to do a rather good job leading this team of people to the end goal.

My suggestion would be to work on something much smaller, possibly something you can do on your own or with maybe one more person to help out. Along the way, hopefully you will find others who work well with you (and a lot of times you'll find out the opposite as well), so that you can work on bigger stuff, towards your "dream" game.

But then again, these are just polite suggestions.
Probably the best way for you to actually find out is by experiencing this by yourself. So good luck.

[Tumetsu]

@Paul
Just because you did something in certain way back in the days doesn't mean it would be best solution nowadays. Today there is much more choice to make and many languages really make it easier to get something running. Also C++ for example has shit-load of "traps" which programmer has to learn to avoid. High-level languages are usually a bit more lenient and therefore easier to learn, which in my experience is good thing. It is easier to learn the "idea" of programming in easy environment. After you have done it, it is far more easier to pick low level language and concentrate on learning the more tricky stuff.

Also, since this is in game making context, I don't see why one couldn't learn both at the same time. Also, actually getting something visual to running is at least to me was very encouraging. This depend on the definition of game development. I understand it as just making games, which is fine practice to learn programming IMO.

Bu in the end, one can definitely pick a low level language and pull through, but I think it requires more sheer will and endurance.

[Paul Eres]

i didn't say it was the best way because i did it, i gave reasons other than that

also i wasn't recommending c++, i agree that c++ is a bad language to start with, i recommended c, not c++

[kamac]

i recommended c

Not that I am some big, great programmer, but there's slight difference between C and C++ to me   . Only that C++ has classes, nicer libraries... That's all I can spot. (I program in C++ daily, not in C)


But if you want to make a game, and want to use free tools, go with some BASIC language. (I always recommend them, because they're easy and powerful)

For example, cs2d was written in BlitzMAX/Blitz3d or one of them. Which is BASIC language. (Expensive one!)

There's also Malevolence: The Sword of Arkhanox being made in DarkBASIC Professional, which is free, and as you can see on the game, it's powerful. (But, yay, FREE). I started with it myself. (There's no ads or things like that)

Using plain languages, instead of Game Maker will ready you for the next step. (You will learn how to load maps made in your own map editor/other editor etc., nothing's built-in like in GM)


That's it from me.

[Moczan]

@Paul, please don't participate in programming conversation when you don't have a fucking clue what you are talking about. You are really causing more harm than help.

You are a well known and respected person on TIG, so newbies will naturally believe when you say crap like "languages can't be powerful or hard".

[thatshelby]

I disagree with Paul too; compare C++ with Java: In java, memory is managed for you automatically.

[Paul Eres]

if anything i said is incorrect, you could correct it, but you didn't do that, so it's safe to ignore comments just saying i'm wrong without explaining why

memory management has nothing to do with "power" though -- power is cpu cycles. game maker running on a pentium will still be faster than assembly running on a 386, what matters most with power is the hardware, the engine, and how it's coded, the language used itself is almost never a speed bottleneck. interpreted languages are slightly slower than compiled ones, but not enough to be noticeable on modern computers unless what you coding a 3d engine or something similarly intensive. when you're writing game logic (which is most of what you're going to write if you're programming games), on modern computers the difference won't be noticeable between any language

and memory is managed for you automatically in c too, you just use malloc() and free()

[Ashkin]

@Paul, please don't participate in programming conversation when you don't have a fucking clue what you are talking about. You are really causing more harm than help.

You are a well known and respected person on TIG, so newbies will naturally believe when you say crap like "languages can't be powerful or hard".

Agree. Languages get harder and more powerful as they get closer to manipulating the machine language of the computer or something- when you put layers and layers of helpful stuff in between the two like Game Maker does, it's inevitable that you should get a little less power.

[thatshelby]

if anything i said is incorrect, you could correct it, but you didn't do that, so it's safe to ignore comments just saying i'm wrong without explaining why

memory management has nothing to do with "power" though -- power is cpu cycles. game maker running on a pentium will still be faster than assembly running on a 386, what matters most with power is the hardware, the engine, and how it's coded, the language used itself is almost never a speed bottleneck. interpreted languages are slightly slower than compiled ones, but not enough to be noticeable on modern computers unless what you coding a 3d engine or something similarly intensive. when you're writing game logic (which is most of what you're going to write if you're programming games), on modern computers the difference won't be noticeable between any language

and memory is managed for you automatically in c too, you just use malloc() and free()

I'm not addressing the more-power/less-power argument, I'm addressing your easy/difficult argument. And good if it's automatic in C too, but there are still languages that don't.

[EddieBytes]

Wow, this thread's really gone off topic ) But in a good way I guess, the OP needs to learn programming. So here's my take on this.

Language options
- pascal - good for learning and getting started in programming but not anything else
- C - just as good as pascal for learning, with the advantage that you can after this easily transition to languages like C++ or java or C# or Objective-C or whatnot. Not that good for making large scale apps/games due to not being OOP
- C++. The de-facto these days in gaming industry. Can get quite complex with templates, but if you ignore that, can be just as easy as java. Downside is poor and few free libraries to help you make games, and those that are, are pretty low level. There are lots of commercial ones though.
- C#. I never used this one personally, but for that, there's the famous XNA to help you make games, and I'm sure lots of other libraries too.
- Game Maker. Never used this one either. I know and heard it's easy to make games with it, but I see it like a trap. You learn it fast, you make some games with it, then you hit its cap and need to go back to square 1 and learn a real language so you can do really cool really tricky really custom stuff. That's why I personally never bothered with it. And I doubt anyone will ever hire you for your skills with Game Maker )

TODO list
So my advice? Start with C. Learn the basics:

- backtracking, divide et impera, dynamic programming, greedy, the bunch
  and
- learn data structures: basic data types, vectors, structures, lists, trees, graphs etc.
(if you're weak, you'll stop at these two, and programming was never for you to begin with. Go do some art instead: GIMP, Photoshop, whatnot, Blender, Max, whatnot). Else, you're just a few steps away from making your first game. Go on.
- learn the runtime API: string functions, math functions, input/output functions, etc.
- solve related programming excercises as you go
- use a third party library to make yourself a small fun little game

Next step, learn an OOP language. I'd go with C++:
- classes, inheritence, the bunch
- templates. I think java has something similar, but I forget the name
- programming patterns: observer pattern, visitor pattern, factory, etc.
- start learning new things on your own. For a programmer, the learning never stops
- make a real game.

That's only a stripped down version of the stuff you have to learn, there's still the Windows API, OpenGL/DirectX, shaders, etc. Be prepared.

Remember to learn to read and understand code. Best and fastest way to learn, by learning how others do things.

My two cents, hope it helps.

[Desert Dog]

- Game Maker. Never used this one either. I know and heard it's easy to make games with it, but I see it like a trap. You learn it fast, you make some games with it, then you hit its cap and need to go back to square 1 and learn a real language so you can do really cool really tricky really custom stuff. That's why I personally never bothered with it. And I doubt anyone will ever hire you for your skills with Game Make

...'real language'...  What's fake about GML?  

Well, anyway, this depends on what sort of skills we are talking about.
When Nitrome are hiring for level designers, they often will cite experience using level editors like GM's as an advantage.

Although level design.. gah, such a lowly position, not worthy of mention!

For the 'ontopic' programming side, Yoyogames itself(the company who is producing GM) has hired several GM-users full-time, either to develop for them, or to help them design GM.

..and with the imminent release of GM-Studio, we do seem to have games companies looking to use it to develop for mobile.. and hiring. Surprising since it's not out of beta yet..!
One such company is HandyGames in Germany, looking to hire people with proven skills with GM.

I also know of a few instances of GM users who have cited the portfolio they built using GM helped snagged them jobs in respected games companies.

I'm a GM user myself, and I certainly hugely recommend GM. If you want to learn both programming, and game designing, GM-Gm-Gm.
If your more interesting in the programming side of things, C#, is a very comfortable language. And for an alternate view, Javascript is getting pretty handy at making games with, and the web is a BIG marketplace.

[EddieBytes]

@Desert Dog
Shouldn't have generalized that much when said no company will hire GM users.
To correct myself, i'll say 'most' companies won't hire you for that. Sure, they'll hire you for the experience you gained using GM, but they themselves won't be using it and won't be needing your skills with GM, but your skill with level designing, like you said.
Don't know much about GM like I said, so that's all I have the right to say about GM.

I'm a GM user myself, and I certainly hugely recommend GM. If you want to learn both programming, and game designing, GM-Gm-Gm.

I'm pretty convinced GM is the best prototyping tool out there, so I won't deny its usefulness. It's also probably the fastest way to get right down and dirty and make a game, if you know zero about programming.
I still prefer being unrestricted (don't know what restrictions GM imposes, but I'm sure it does, otherwise it wouldn't be easier to use than say C++), if you're real about game making, you can't have a tool hold your hand forever.