I keep hearing that once you learn one language, transitioning from one language to another becomes a snap.
I started out with C++ but switched to C# at a friends request, to get quicker results/work on games together.
If I remember right, the syntax for C++ really isn't all that different from C#.
Is transitioning from C# to C++ really THAT simple?
It's not necessarily super easy to switch languages. But when you learn your first language, you are also learning the concepts of programming at the same time. When you pick up your second language, you are only transferring your knowledge of how to program to that new language's syntax and ways of doing things. Because you should already understand how programming works at that point.
C++ doesn't have as nice of a system library as C#. You'll have to find your own for a lot of things that C# provides for you. You will also have to manage your own memory (easier said than done! Memory mismanagement tends to be the cause of most program errors), and put up with the header file system C++ uses.
But it's a lot easier than switching to another non c-like language.
C++ doesn't have as nice of a system library as C#. You'll have to find your own for a lot of things that C# provides for you. You will also have to manage your own memory (easier said than done! Memory mismanagement tends to be the cause of most program errors), and put up with the header file system C++ uses.
But it's a lot easier than switching to another non c-like language.
Quote:Original post by GraySnakeGenocideAre you referring to memory management? It's not that difficult until your program gets large in size.
Oh boy. I have a hard time with technical/mathematic junk as is >_>.
You have to erase everything you allocate with (new/delete). C# will automatically free up anything once nothing else is referencing it anymore.
In C++ you need to keep track of what everything is, and how many things might be referencing it. You call delete on things, but you have to make sure that anything else that might be pointing at that instance of memory doesn't ever try to access it again. If your program isn't that complex, then it's no big deal.
Author
As long as my goal (AAA games made for Sony/Microsoft) aren't as complex as I originally thought, I should be good then.
I transitioned from Java to C++ successfully.
It wasn't necessarily easy and I was aided by already knowing C.
Mostly it was looking through tutorials online, as well as manuals for standard library features like the stl::vector to see how things are done, as well as reading through Effective C++ by Scott Meyers a few times.
That last part is important. You don't know what you don't know. A good book or teacher does! Without it, and only by looking up C++ counterparts to Java components, I would've ran into all sorts of problems and also be completely ignorant of features and issues for which there are no Java counterparts.
I also strongly recommend that particular book.
C# to C++ is going to be a similar experience.
It wasn't necessarily easy and I was aided by already knowing C.
Mostly it was looking through tutorials online, as well as manuals for standard library features like the stl::vector to see how things are done, as well as reading through Effective C++ by Scott Meyers a few times.
That last part is important. You don't know what you don't know. A good book or teacher does! Without it, and only by looking up C++ counterparts to Java components, I would've ran into all sorts of problems and also be completely ignorant of features and issues for which there are no Java counterparts.
I also strongly recommend that particular book.
C# to C++ is going to be a similar experience.
You recently birthed a thread asking whether C# was leading you away from AAA Microsoft/Sony development, didn't you?
Look, you have completely the wrong idea on this one. I know it's natural as a newbie to place huge amounts of emphasis on the significance of the language to your end goal, and to an (ostensibly inflated) extent the more seasoned among us do debate the finer aspects of implementation language/platform details ad nauseam, as well. That's all fine (er, largely, anyway), and for the most part has it's place.
But actual game development, or indeed development of any complicated software product, isn't anything like that.
What you'll come to understand, is that the real meat of game development, the seriously hard problems, the stuff that'll separate you from the pack (or the pack from you if you don't recognise this at some point), are far deeper and rooted in far more immense and richer theory than meagre concerns like which language you're going to use to encode it in.
Take, for example, physics*. To even start to properly grasp the physical interactions a AAA studio attempts to simulate in a game, you're going to have to come to grips with a monumental, astonishingly perplexing mindfuck of a culmination of mathematical brilliance that is The Vector Analysis. Then, note that university physics students usually get to contrive their investigations and exercises into simplified scenarios and experiments - a physics programmer has to write procedures which handle every case, and maintain the brick-shithouse integrity of invariants, complicated conditions which must hold throughout the course of play (eg. stuff shouldn't go through other stuff). Many problems in the area - collisions, for example - are famous for being absolute nightmares to handle robustly. There are many important phenomena in games which you'd struggle to think how to represent, let alone simulate - how the friggen hell to you handle fluids? Air? Water? Deformable anything? How does it all interact? And how do you balance this stuff juice-wise with the rest of the demands on your chunk of CPU time?
Game physics is one of the genuinely, monumentally hard problems involved in AAA game development - but in among the several other monumentally hard problems in game development it's just another piece. Graphics is the "archetypal" example of a hard problem, and because I plainly know next-to-nothing about it I'm not even going to touch it, suffice to say many a game superprogrammer bases an entire career upon the field alone. What about AI? Audio? Networking? What about the infrastructural "kernal" of a game engine that ties all this stuff together? Ultimately, practically all of this stuff exists in and around the design phase, and by comparison implementation (that is, writing code) is intended to be a methodical and uninteresting by-product.
You should also keep in mind that you will require a strong education in theoretical computer science merely as a basis from which to properly grasp any of these fields.
The fact is, to be at all viable as a big-time game programmer, you need to be a veritable go-to guy on at least one of the big problems, and you need to have a reasonable understanding of what everyone else is doing, too. Attaining this level of understanding is brutally hard - learning a pissy little language like C++ is a friggen cakewalk in comparison.
If you want to do something significant to better your chances of making it into serious AAA game development, serously: go to university, take a computer science course, and don't be that kid who whinges about not doing things in C++.
And, seriously, if, after the immensity of these challenges truly sinks in, you have the mind, ambition, and stomach for these things: good luck. The world could always use more people so dedicated.
*Using this as an example because my interest is simulations and such.
Look, you have completely the wrong idea on this one. I know it's natural as a newbie to place huge amounts of emphasis on the significance of the language to your end goal, and to an (ostensibly inflated) extent the more seasoned among us do debate the finer aspects of implementation language/platform details ad nauseam, as well. That's all fine (er, largely, anyway), and for the most part has it's place.
But actual game development, or indeed development of any complicated software product, isn't anything like that.
What you'll come to understand, is that the real meat of game development, the seriously hard problems, the stuff that'll separate you from the pack (or the pack from you if you don't recognise this at some point), are far deeper and rooted in far more immense and richer theory than meagre concerns like which language you're going to use to encode it in.
Take, for example, physics*. To even start to properly grasp the physical interactions a AAA studio attempts to simulate in a game, you're going to have to come to grips with a monumental, astonishingly perplexing mindfuck of a culmination of mathematical brilliance that is The Vector Analysis. Then, note that university physics students usually get to contrive their investigations and exercises into simplified scenarios and experiments - a physics programmer has to write procedures which handle every case, and maintain the brick-shithouse integrity of invariants, complicated conditions which must hold throughout the course of play (eg. stuff shouldn't go through other stuff). Many problems in the area - collisions, for example - are famous for being absolute nightmares to handle robustly. There are many important phenomena in games which you'd struggle to think how to represent, let alone simulate - how the friggen hell to you handle fluids? Air? Water? Deformable anything? How does it all interact? And how do you balance this stuff juice-wise with the rest of the demands on your chunk of CPU time?
Game physics is one of the genuinely, monumentally hard problems involved in AAA game development - but in among the several other monumentally hard problems in game development it's just another piece. Graphics is the "archetypal" example of a hard problem, and because I plainly know next-to-nothing about it I'm not even going to touch it, suffice to say many a game superprogrammer bases an entire career upon the field alone. What about AI? Audio? Networking? What about the infrastructural "kernal" of a game engine that ties all this stuff together? Ultimately, practically all of this stuff exists in and around the design phase, and by comparison implementation (that is, writing code) is intended to be a methodical and uninteresting by-product.
You should also keep in mind that you will require a strong education in theoretical computer science merely as a basis from which to properly grasp any of these fields.
The fact is, to be at all viable as a big-time game programmer, you need to be a veritable go-to guy on at least one of the big problems, and you need to have a reasonable understanding of what everyone else is doing, too. Attaining this level of understanding is brutally hard - learning a pissy little language like C++ is a friggen cakewalk in comparison.
If you want to do something significant to better your chances of making it into serious AAA game development, serously: go to university, take a computer science course, and don't be that kid who whinges about not doing things in C++.
And, seriously, if, after the immensity of these challenges truly sinks in, you have the mind, ambition, and stomach for these things: good luck. The world could always use more people so dedicated.
*Using this as an example because my interest is simulations and such.
Very nice post Fenrisulvur.
I put massive emphasis on languages and 'where to start' etc. etc. when i first attempted to enter the world of programming and video game design/production. I started with a little of VB and was afraid to use anything else, seeing it as VB being 'my' language.
A year or two later i actually started a uni course, and pretty quickly you realise just how huge game production/development is as a whole. Languages become a very small factor in the long run. Once you begin to get your head around programming in general, and other features including maths, physics and everything else involved with how computers/technology works, then it almost begins to simplify with complexity.
You begin to realise how much there is, which at first makes everything seem complex, but at the same time it helps you to realise that decisions on things like programming language are much smaller choices than you would first think.
Im nowhere near an expert on the subject, but ive been doing my uni course for almost a year and it sort of 'clicked' a while ago how much is involved. Once you push through the barrier and understand it as a whole, it helps you to understand each individual concept. Pretty much how learning programming in any form helps your understanding when moving from language to language.
It's very very very difficult to find a good direction or 'order' to follow when learning without using some form of university course or something similar. I started with some simple downloadable courses, but without a truely structured flow of learning its hard to grasp each and every concept as you go.
You do have to be smart, and you do probably need to do some form of higher education within computing. Going back to what you said about changing languages though, if you do have a good understanding of programming in general, and especially if you are moving between two similar languages, it really isnt that difficult to change. :)
I put massive emphasis on languages and 'where to start' etc. etc. when i first attempted to enter the world of programming and video game design/production. I started with a little of VB and was afraid to use anything else, seeing it as VB being 'my' language.
A year or two later i actually started a uni course, and pretty quickly you realise just how huge game production/development is as a whole. Languages become a very small factor in the long run. Once you begin to get your head around programming in general, and other features including maths, physics and everything else involved with how computers/technology works, then it almost begins to simplify with complexity.
You begin to realise how much there is, which at first makes everything seem complex, but at the same time it helps you to realise that decisions on things like programming language are much smaller choices than you would first think.
Im nowhere near an expert on the subject, but ive been doing my uni course for almost a year and it sort of 'clicked' a while ago how much is involved. Once you push through the barrier and understand it as a whole, it helps you to understand each individual concept. Pretty much how learning programming in any form helps your understanding when moving from language to language.
It's very very very difficult to find a good direction or 'order' to follow when learning without using some form of university course or something similar. I started with some simple downloadable courses, but without a truely structured flow of learning its hard to grasp each and every concept as you go.
You do have to be smart, and you do probably need to do some form of higher education within computing. Going back to what you said about changing languages though, if you do have a good understanding of programming in general, and especially if you are moving between two similar languages, it really isnt that difficult to change. :)
Author
Well if it requires extremely complex algebra then I am screwed.
I struggle with somewhat basic algebra as is.
I struggle with somewhat basic algebra as is.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement