next »

[Gold Cray]

I spent years in DarkBasic (shudder) and BlitzBasic. Don't think I'm a terrible coder now. In terms of game coding they definitely helped me to learn, especially when I only had occasional dial-up internet so I was mostly self taught, but really if you can learn to make global variables and functions in them, you can do the same in C++ (or indeed any language).

I don't understand what you're saying, are you promoting functions-and-globals as a good programming style, or are you saying you can make an ugly mess in any language?

This reminds me: whatever language you end up picking, stay away from global variables at all costs. If you start relying on global variables you'll end up regretting it in the form of hours of debugging.

As for a game making program, if you're willing to wait a little while, I believe there is a cross-platform program in development right now. I don't actually know how far away it is, but I got the impression that it was getting close. There should be a topic on it somewhere.

[Dacke]

For me programming is like... super fun. I recommend choosing a language that gives you what you need and want. As long as you have fun programming you will get generally better, no matter the language.

Sorry, not everyone can be good programmers, no matter how hard they try (this corresponds to my experiences and observations as well, having taught programming as well as worked with it. However, for some interesting discussion and critique of this paper by Alan Kay, see here).

Programming may be hard for some people. (Though even dyslectic people can learn to read.) But I dare you to find anyone who has fun programming who doesn't get better while coding.

C# is probably a decent choice for a starting language. But in the long run, it may go up in flames when Microsoft crashes and burns. (Though that may be wishful thinking, from my part.)

[muku]

C# is probably a decent choice for a starting language. But in the long run, it may go up in flames when Microsoft crashes and burns. (Though that may be wishful thinking, from my part.)

C# is now an ECMA standard, so I think that's unlikely. (Nor do I think that Microsoft crashing and burning is a very likely proposition...)

By the way, for whoever thinks that C++ is the language that gives you the most freedom, I suggest taking a good look at Lisp. As for multiple inheritance, it creates a whole world of pain and is better avoided;  favoring composition over inheritance and using interfaces usually eliminates any need for it.

[Dacke]

C# is now an ECMA standard, so I think that's unlikely.

Yeah, I know. But without Microsoft putting it's weight behind it, I think it would grow stale over time. I think Virtual Machines need to be constantly updated to make use of new hardware and operating system features. But it's quite possible I'm completely and utterly wrong about this

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

Programming may be hard for some people. (Though even dyslectic people can learn to read.) But I dare you to find anyone who has fun programming who doesn't get better while coding.

C# is probably a decent choice for a starting language. But in the long run, it may go up in flames when Microsoft crashes and burns. (Though that may be wishful thinking, from my part.)

Not everyone can find programming fun, though. I've programmed for about 15 years now and finished tons of games, and programmed a great deal, and I *never* find it fun. It's always very tedious and boring. I find making games fun, but programming itself I could do without.

[Hajo]

Not everyone can find programming fun, though. I've programmed for about 15 years now and finished tons of games, and programmed a great deal, and I *never* find it fun.

I want to second this (although I didn't finish a lot of games, but I feel the same about programming).

[muku]

C# is now an ECMA standard, so I think that's unlikely.

Yeah, I know. But without Microsoft putting it's weight behind it, I think it would grow stale over time. I think Virtual Machines need to be constantly updated to make use of new hardware and operating system features.

True, but since there already is an alternative and open-source implementation, Mono, I think we can bet on C# being around for a while.

[Ishi]

I spent years in DarkBasic (shudder) and BlitzBasic. Don't think I'm a terrible coder now. In terms of game coding they definitely helped me to learn, especially when I only had occasional dial-up internet so I was mostly self taught, but really if you can learn to make global variables and functions in them, you can do the same in C++ (or indeed any language).

I don't understand what you're saying, are you promoting functions-and-globals as a good programming style, or are you saying you can make an ugly mess in any language? I also started with BASIC (and Pascal), and when looking back at my old Java and C++ source now I can see how much those languages damaged me.

Just pointing out that to achieve the same things that you can achieve in BASIC in C++, the syntax isn't really any harder, so you may as well just use C++. Not advocating it as a good way of doing things or anything.

I don't think doing things badly to start with is gonna permanently damage someone's programming skills, if anything getting tangled up in a spaghetti of code is gonna teach you to avoid that in the future.

I think just use any language you like

[Mikademus]

Hah, I can't believe you used multiple inheritance as the primary argument for C++. Shame on you!

Templating can be more or less simulated in Java with generics, although not entirely. And while I do admit there's a few things missing in Java (you can't take functions as parameters, for one thing), I do think it gives you about the same level of freedom as C++. As for the other things; there are plenty of libraries to allow scripting for Java as well, and library availability is good.

I'm not saying Java is better than C++ for everything - I'm just saying that C++ isn't better for everything either. There are plenty of options, and saying that C++ is what will give you freedom in the end and that you *will* move towards it is not something I approve of.

MI isn't an Alchemist's Stone, but when used properly it simplifies the life of a programmer tremendously. Java's ( and C#'s) interface system isn't a sufficient MI replacement. MI with templates is perhaps one of the most powerful programming tools in any existing language. Also, there's a reason why most interpreted languages support MI-like functionality (such as mix-ins).

Java's generics aren't templates. They represent a limited subset of generic programming called "Containers-of-type-T", which is the very least aspect of generic programming. C++'s templates are infinitely more powerful and there is no way to simulate or emulate their behaviour in Java.

I agree that all languages are suitable for different tasks, and it is important to recognise that Java and C++ are intended for different purposes. That said, while there aren't anything you can do in Java that you can't do in C++ there are many solutions and idioms you can do in C++ you can't do in Java. C++ *IS* a freer language than Java, but all freedom comes at the price of responsibility and competence.

Sorry, not everyone can be good programmers, no matter how hard they try (this corresponds to my experiences and observations as well, having taught programming as well as worked with it. However, for some interesting discussion and critique of this paper by Alan Kay, see here).

Programming may be hard for some people. (Though even dyslectic people can learn to read.) But I dare you to find anyone who has fun programming who doesn't get better while coding.

Absolutely. However "better" does not imply "good". However, let's not forget that "good programmer" does not imply "good game designer".

Not everyone can find programming fun, though. I've programmed for about 15 years now and finished tons of games, and programmed a great deal, and I *never* find it fun. It's always very tedious and boring. I find making games fun, but programming itself I could do without.

This is one of the most honest posts in this thread. Rather than silly Internet wars about who's language is the bigger daddy, which is silly, this is an argument I can respect. I don't share the sentiment, but I can understand it, and for people that have to work through code to create rather than create by working with code, talk about language features and language X > language Y is quite a waste of time.

I don't think doing things badly to start with is gonna permanently damage someone's programming skills, if anything getting tangled up in a spaghetti of code is gonna teach you to avoid that in the future.

I think just use any language you like

I do think there is a risk of being semi-permanently damaged. If first getting proficient in a language that hides critical stuff like dynamic memory it will be difficult to move on. When moving from BASIC to Pascal I stayed away from pointers and classes (yes, Borland Pascal supported those) for years, just because they weren't in my existing comfort zone. And when moving from Pascal to Delphi and then C++ I tried to keep coding like in Pascal. Don't forget that even programmers professional since decades have a hard time leaving their old habits. COBOL and FORTRAN programmers will keep trying to program as they always have in whatever language they use (to the great dismay of their colleagues). The Linux big-wigs have an illogical hatred of C++ and only use ANSI-C. Etc ad absurdum. And of course, in any debate like this there is always the mandatory post that Lisp > all (and then someone claiming that Haskell > Lisp):

By the way, for whoever thinks that C++ is the language that gives you the most freedom, I suggest taking a good look at Lisp.

There is also a popular myth always rearing its head in these debated:

As for multiple inheritance, it creates a whole world of pain and is better avoided

This has been most popularly promoted by Sun and part of the Java marketing. It has been frequently challenged and there is no data backing it up whatsoever.

[muku]

And of course, in any debate like this there is always the mandatory post that Lisp > all (and then someone claiming that Haskell > Lisp):

I would never claim that "Lisp > all", I also didn't claim that "Lisp > C++" (I don't believe in the existence of a total order over the set of the programming languages, if you catch my drift). I'm not even that much of a Lisp fan, having studied it only for the intellectual pleasure and never having written much real-world code in it. I just said that Lisp gives you more freedom than C++, which is hard to dispute since it gives you more programming paradigms to work with, and frees you from having to manage your memory manually. (Which is another can of worms entirely that we can please leave unopened, yes?)

There is also a popular myth always rearing its head in these debated:

As for multiple inheritance, it creates a whole world of pain and is better avoided

This has been most popularly promoted by Sun and part of the Java marketing. It has been frequently challenged and there is no data backing it up whatsoever.

I'm sure you know about this, so I don't even know why I'm posting it: http://en.wikipedia.org/wiki/Diamond_problem. There are ways to deal with it, but none are intuitive or feel "right". I strongly feel that a good language design should have an overall coherence and feeling of "rightness" to it, which is why I'm bothered by these ugly things: whenever you have to remember some non-obvious way in which a language handles a corner case, that's a design flaw to me. (C++ is full of this stuff.)

I also still maintain that composition plus interfaces is a perfectly fine replacement for MI. Deep inheritance hierarchies are bad design anyway in most cases. (BTW, I strongly dislike Java, so saying that I'm tainted by Sun propaganda is off the mark.)

At any rate, you are quite right that bickering about these language issues is pretty much pointless, and I feel like an idiot for doing it anyway. But eh, I can't help it.

[Mikademus]

At any rate, you are quite right that bickering about these language issues is pretty much pointless, and I feel like an idiot for doing it anyway. But eh, I can't help it.

Yeah, don't I know, preach it, brotha! Also, it is the best topic for intentional misunderstanding, generalisations and recriminations. Still it is the proverbial train wreck one can't stay away from...

And of course, in any debate like this there is always the mandatory post that Lisp > all (and then someone claiming that Haskell > Lisp):

I would never claim that "Lisp > all", I also didn't claim that "Lisp > C++" (I don't believe in the existence of a total order over the set of the programming languages, if you catch my drift). I'm not even that much of a Lisp fan, having studied it only for the intellectual pleasure and never having written much real-world code in it. I just said that Lisp gives you more freedom than C++, which is hard to dispute since it gives you more programming paradigms to work with, and frees you from having to manage your memory manually. (Which is another can of worms entirely that we can please leave unopened, yes?)

Ok, with that context it is a much more interesting argument. I apologise for silently thinking "Lisp weenie" about you

There is also a popular myth always rearing its head in these debated:

As for multiple inheritance, it creates a whole world of pain and is better avoided

This has been most popularly promoted by Sun and part of the Java marketing. It has been frequently challenged and there is no data backing it up whatsoever.

I'm sure you know about this, so I don't even know why I'm posting it: http://en.wikipedia.org/wiki/Diamond_problem. There are ways to deal with it, but none are intuitive or feel "right". I strongly feel that a good language design should have an overall coherence and feeling of "rightness" to it, which is why I'm bothered by these ugly things: whenever you have to remember some non-obvious way in which a language handles a corner case, that's a design flaw to me. (C++ is full of this stuff.)

I also still maintain that composition plus interfaces is a perfectly fine replacement for MI. Deep inheritance hierarchies are bad design anyway in most cases. (BTW, I strongly dislike Java, so saying that I'm tainted by Sun propaganda is off the mark.)

The DDOI isn't really a problem (well, from a perspective of technical definition it is, but practically it is an easily manageable one). In most design situations it will never manifest, and when it does, well, all (useful) languages contains border scenarios. I don't think adding a "virtual" in front of certain base classes is much of a problem. Also (acknowledging that you're not a Java fanboi) Java has as many design inconsistencies (this is a huge can of worms - caveat emptor). Incidentally, a few days ago I had to accommodate DDOI for the first time in some years and I had no problem whatsoever with managing it.

From a software design perspective there is nothing wrong with MI that isn't also a potential problem with inheritance in itself. Any tool can be misused, and inheritance can most certainly be too, SI or MI. Inheritance, composition and multi-inheritance are all design choices. And the only true evil is NOT being allowed to use a certain design when appropriate.

There are other myths similar to the one that MI leads to bug-prone and difficult to maintain code, like that operator overloading does the same, another piece of FUD also liberally spread by Sun. I am not accusing you of arguing the Sun line, but I do think (at least in the case of MI) you may be "contaminated" by common myths that lack a real foundation. The basic truth is: senseless programmers will make hash of any language, while sensible ones will use features well.

[nihilocrat]

If you can survive 4 years of a CS degree, programming stuff that has nothing to do with games, you will develop the patience to like it in non-programming applications. Compared to game programming, the effort/reward ratio is much much much lower, but requires more abstract thinking on your part, as you will very rarely be able to create an OO class that directly represents something you see on the screen.

Still, you will be able to create an application that does something useful, however small, in the space of a few minutes. You will be amazed by how little effort you have to put in to get stuff done, and when you inevitably do web / database programming, you will be amazed that there is a single set of standards you can rely on (HTML, CSS, Javascript, SQL) and that the web is practically overflowing with tutorials and examples. Game programming, by comparison, feels like a death march, where most of the things you /know/ are basic, bread-and-butter operations you've seen in games everywhere (getting a vehicle to track a target, dragging a selection box to select several things in-game) have either no Google-able examples, or examples that are using a language/library so different that it's not very helpful. If you ever do learn a method, it is 90% of the time very complicated, involving complex math, at least compared to algorithms and operations you'd do in a web app or other non-game software. I guess the universe is just being consistent. High effort, high reward.

The biggest problem I have with doing non-game programming is that the result tends to be boring as hell. Massaging some data, parsing some text, maintaining cron scripts. There are armies of software developers around the world in polo shirts and khakis who are writing billing software, or package routing software, or other amazingly mundane things, and they manage to find some fun in the problem rather than the result. This is really the key of liking programming on its own, and it's honestly a really dry subject that not everyone is going to like, unlike, say, game design .

[Jared C]

Yeah... I just find game design so much easier.    But as of right now, I have no other choice but to learn programming.  I mean, what other 13 year old I know can do Java or C coding?

[Morre]

Game Maker, Construct, Processing or other more or less visual environments might not be such a bad place to start. It'll require less (or none) programming on your behalf, but will still give you a good idea of the core concepts.

I made my first games in Klik & Play. Feels like such a long time ago now...
Then I moved on to BASIC, Java, C/C++, a bit of Haskell, and I'm currently doing ActionScript.

It is true that once you've learned one language, it's much easier to learn a new one - especially if it uses the same paradigm. I find ActionScript pretty easy to work with despite not having read any tutorials. It's more or less the same as most of the other languages I've worked with.

[David Pittman]

This is really the key of liking programming on its own, and it's honestly a really dry subject that not everyone is going to like, unlike, say, game design .

This probably isn't the right place for it, but I contend that game design as a whole is itself fairly dry, problem-solvy, and left-brainy; far removed from the creative ideal that we so often make it out to be. The exhilaration of brainstorming eventually gives way to tedious number-tweaking; but the best games are the ones which have been meticulously tuned, not the ones with the coolest ideas.

[Kneecaps]

Flash is good at making quick money, so if you want extra benefits to knowing a coding language, I'd go with that.  I think I started learning Flash and AS2 at around 13-14, so it's not impossible.  Just make sure to learn AS3 and skip AS2 if you go with Flash.

Or learn Game Maker.  It's more fun.

[Mikademus]

This is really the key of liking programming on its own, and it's honestly a really dry subject that not everyone is going to like, unlike, say, game design .

This probably isn't the right place for it, but I contend that game design as a whole is itself fairly dry, problem-solvy, and left-brainy; far removed from the creative ideal that we so often make it out to be. The exhilaration of brainstorming eventually gives way to tedious number-tweaking; but the best games are the ones which have been meticulously tuned, not the ones with the coolest ideas.

I made a related argument and invited discussion about how to achieve real ("qualitative") differences and variety in games in this thread.

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

This probably isn't the right place for it, but I contend that game design as a whole is itself fairly dry, problem-solvy, and left-brainy; far removed from the creative ideal that we so often make it out to be. The exhilaration of brainstorming eventually gives way to tedious number-tweaking; but the best games are the ones which have been meticulously tuned, not the ones with the coolest ideas.

It's always the right place for interesting things. I disagree with this though, I don't think game design boils down to balancing numbers. Game design includes a lot more than designing the game mechanics and levels, it also includes things like designing the characters, story, world, plot, visuals, sounds, and all that. And that part isn't very left-brainy. That kind of stuff often takes much more design work than the mechanics, and are often more important to the user's experience.

[Ivan]