|
On December 03 2011 06:32 Fandango wrote:Show nested quote +On December 03 2011 05:46 CecilSunkure wrote:
You actually do learn to code in Assembly here at DigiPen, in order to appreciate and understand C better. Then by extension, do the same with C to C++. It's fine if you disagree, though you're argument is kinda lacking against mine.
You haven't argued anything at all, you've literally just said that this is the way it is without any justification, I provided reasoning behind why that approach is flawed and you didn't refute any of it and again just assumed you're right. There's really no reason to continue to argue with you either because you seem to think you know everything about game development when you're still at college and apparently not that far along from your outlook. I'm not suggesting that my outlook is definitively the best or anything i'm just saying that your approach to learning is flawed because you don't really know what you're arguing.
Sorry I should clarify. By "mine" I meant what I've been taught here. I'm merely quoting people more experienced that me that tell me these things. For example the guy in the podcast in the OP, he's a huge proponent of the philosophy I've cited. I understand what you are saying and why you are saying it, but I just disagree since I trust these people here more than you. Sorry for being a bit unclear on "the argument", as again it isn't mine, just one I trust.
|
I've got a bachelor's in CS and have been working in software development for three years now. I do some kernel-mode and some user-mode system stuff - while I'm not on the bare-bones hardware like many of my colleagues, I'm closer than you would need to get for modern game development.
Don't worry about C. There are a lot of things that are bad about C and a lot of practices you'll pick up from starting in C that'll you'll need to unlearn when you move on to more mature languages. There's a reason we don't write software using the same tools that were used in the 1970's and that's because there are a lot of better tools out there today.
Skip C. It's not like a prerequisite, like C is your 101 level class that you have to take before the 102 of C++. It's not like C is arithmetic and C++ is calculus. It's not part of some progression you need to follow. C is different. It's old. There are a lot of ways to do C wrong and only a few ways to do it right. While there are some limited scenarios where it's the proper tool for the job, those are few and far between. And OOP is important. Start learning how to think that way now. When you're learning to be an architect, you don't start designing your first building to be built without hammers. Don't do the same when you're learning to be a developer.
C++ still gives you all the cool ways to shoot yourself in the foot and waste your weekends that C does. It has enough low-level power to prime you for that world but enough high-level expressiveness to get you used to working in that world as well. And if there ever comes a time when you need to fall back and learn C, your exposure to C++ is going to make that easy.
Sure there will be classes which require you to do some ASM and some C and whatever, and that's fine. It's good to have exposure. OCAML was cool to learn in school but fuck if I can even imagine what I'd do with it now. But on your personal projects, the stuff where you get to call the shots and where you get to really pour your heart and soul into it, don't take on this needless restriction of doing C first. For most purposes, C++ offers a *better* way to solve problems and one that your future employers are going to expect you to understand.
TL;DR: There are *drawbacks* to C. It's not a right of passage... in many cases, C is just wrong  . Skip it!
|
On December 03 2011 06:48 CecilSunkure wrote:Show nested quote +On December 03 2011 06:32 Fandango wrote:On December 03 2011 05:46 CecilSunkure wrote:
You actually do learn to code in Assembly here at DigiPen, in order to appreciate and understand C better. Then by extension, do the same with C to C++. It's fine if you disagree, though you're argument is kinda lacking against mine.
You haven't argued anything at all, you've literally just said that this is the way it is without any justification, I provided reasoning behind why that approach is flawed and you didn't refute any of it and again just assumed you're right. There's really no reason to continue to argue with you either because you seem to think you know everything about game development when you're still at college and apparently not that far along from your outlook. I'm not suggesting that my outlook is definitively the best or anything i'm just saying that your approach to learning is flawed because you don't really know what you're arguing. Sorry I should clarify. By "mine" I meant what I've been taught here. I'm merely quoting people more experienced that me that tell me these things. For example the guy in the podcast in the OP, he's a huge proponent of the philosophy I've cited. I understand what you are saying and why you are saying it, but I just disagree since I trust these people here more than you. Sorry for being a bit unclear on "the argument", as again it isn't mine, just one I trust.
You should be aware that he's only referring to the studios that stick to the old model of physical media and consoles releases and so on, what i'm referring to is the other side of the industry that makes web games, mobile games (including but not limited to iPhone/Android) and other contracted works where ultra high performance is needed. It's a whole different kettle of fish and there's even parts of big studios that focus on small projects that operate in the same manner and hire the same people. You should always be wary of anyone telling you that the industry is like this or this, it's almost always all of the above it's just whoever is saying it hasn't necessarily been exposed to that side of things.
I've worked at a big studio, ran a small studio that was based on contract work and been to quite a few developer conferences and depending on who you talk to, everyone is wrong and everyone is right. As a student you should just look what you want to do and go about doing that, for you it sounds like big studio development and you're on the right path for that so great. I'd also like to add that at no point am I condoning not learning anything you want to learn about just what is considered a requirement. Although i'd still skip C because it's not going to be relevant to anything but embedded systems programming and unless you want to work on robots or custom peripheral hardware it's probably a waste of time.
edit: Listen to the dude above too he's a cool cat
|
|
|
On December 03 2011 07:01 Fandango wrote:Show nested quote +On December 03 2011 06:48 CecilSunkure wrote:On December 03 2011 06:32 Fandango wrote:On December 03 2011 05:46 CecilSunkure wrote:
You actually do learn to code in Assembly here at DigiPen, in order to appreciate and understand C better. Then by extension, do the same with C to C++. It's fine if you disagree, though you're argument is kinda lacking against mine.
You haven't argued anything at all, you've literally just said that this is the way it is without any justification, I provided reasoning behind why that approach is flawed and you didn't refute any of it and again just assumed you're right. There's really no reason to continue to argue with you either because you seem to think you know everything about game development when you're still at college and apparently not that far along from your outlook. I'm not suggesting that my outlook is definitively the best or anything i'm just saying that your approach to learning is flawed because you don't really know what you're arguing. Sorry I should clarify. By "mine" I meant what I've been taught here. I'm merely quoting people more experienced that me that tell me these things. For example the guy in the podcast in the OP, he's a huge proponent of the philosophy I've cited. I understand what you are saying and why you are saying it, but I just disagree since I trust these people here more than you. Sorry for being a bit unclear on "the argument", as again it isn't mine, just one I trust. You should be aware that he's only referring to the studios that stick to the old model of physical media and consoles releases and so on, what i'm referring to is the other side of the industry that makes web games, mobile games (including but not limited to iPhone/Android) and other contracted works where ultra high performance is needed. It's a whole different kettle of fish and there's even parts of big studios that focus on small projects that operate in the same manner and hire the same people. You should always be wary of anyone telling you that the industry is like this or this, it's almost always all of the above it's just whoever is saying it hasn't necessarily been exposed to that side of things. I've worked at a big studio, ran a small studio that was based on contract work and been to quite a few developer conferences and depending on who you talk to, everyone is wrong and everyone is right. As a student you should just look what you want to do and go about doing that, for you it sounds like big studio development and you're on the right path for that so great. I'd also like to add that at no point am I condoning not learning anything you want to learn about just what is considered a requirement. Although i'd still skip C because it's not going to be relevant to anything but embedded systems programming and unless you want to work on robots or custom peripheral hardware it's probably a waste of time. edit: Listen to the dude above too he's a cool cat
Yeah I understand. In the podcast he even himself says that if you're just interested in Flash development that strong foundation in C/C++ isn't really necessary. Nothing was said on mobile development though. From people I've heard talk it sounds like heavy optimization is important in mobile development as well due to limited hardware power. It's just a matter of goals of the target audience.
|
On December 03 2011 07:27 CecilSunkure wrote:Show nested quote +On December 03 2011 07:01 Fandango wrote:On December 03 2011 06:48 CecilSunkure wrote:On December 03 2011 06:32 Fandango wrote:On December 03 2011 05:46 CecilSunkure wrote:
You actually do learn to code in Assembly here at DigiPen, in order to appreciate and understand C better. Then by extension, do the same with C to C++. It's fine if you disagree, though you're argument is kinda lacking against mine.
You haven't argued anything at all, you've literally just said that this is the way it is without any justification, I provided reasoning behind why that approach is flawed and you didn't refute any of it and again just assumed you're right. There's really no reason to continue to argue with you either because you seem to think you know everything about game development when you're still at college and apparently not that far along from your outlook. I'm not suggesting that my outlook is definitively the best or anything i'm just saying that your approach to learning is flawed because you don't really know what you're arguing. Sorry I should clarify. By "mine" I meant what I've been taught here. I'm merely quoting people more experienced that me that tell me these things. For example the guy in the podcast in the OP, he's a huge proponent of the philosophy I've cited. I understand what you are saying and why you are saying it, but I just disagree since I trust these people here more than you. Sorry for being a bit unclear on "the argument", as again it isn't mine, just one I trust. You should be aware that he's only referring to the studios that stick to the old model of physical media and consoles releases and so on, what i'm referring to is the other side of the industry that makes web games, mobile games (including but not limited to iPhone/Android) and other contracted works where ultra high performance is needed. It's a whole different kettle of fish and there's even parts of big studios that focus on small projects that operate in the same manner and hire the same people. You should always be wary of anyone telling you that the industry is like this or this, it's almost always all of the above it's just whoever is saying it hasn't necessarily been exposed to that side of things. I've worked at a big studio, ran a small studio that was based on contract work and been to quite a few developer conferences and depending on who you talk to, everyone is wrong and everyone is right. As a student you should just look what you want to do and go about doing that, for you it sounds like big studio development and you're on the right path for that so great. I'd also like to add that at no point am I condoning not learning anything you want to learn about just what is considered a requirement. Although i'd still skip C because it's not going to be relevant to anything but embedded systems programming and unless you want to work on robots or custom peripheral hardware it's probably a waste of time. edit: Listen to the dude above too he's a cool cat Yeah I understand. In the podcast he even himself says that if you're just interested in Flash development that strong foundation in C/C++ isn't really necessary. Nothing was said on mobile development though. From people I've heard talk it sounds like heavy optimization is important in mobile development as well due to limited hardware power. It's just a matter of goals of the target audience.
Well the issue with mobile development for iPhone and Android (and I believe the old Samsung OS that failed), is that they don't allow you to program in C++ properly anyway, it's either Obj-C or Java. Optimising is far far far far far more down to code design than language speed anyway, compilers (including the JIT ones used in C# or Java) are very good at optimising these days. The biggest thing is always going to be how you've programmed it, removing unnecessary loops, avoiding costly operations and so on. Hardcore optimisations that rely on language speed differences or knowing how to use the different programming caches are like the last resort that rarely need to be done outside of engine development.
|
On December 03 2011 06:27 Fandango wrote:
You're talking about big studio development, precisely the opposite of what I'm referencing and precisely where C++ is treasured.
On December 03 2011 04:22 Fandango wrote:
Knowing C++ is great and all and it's good to have on a resume and so on, but if you want to work on actual gameplay development these days, even at the largest of studios, it's going to be in an interpreted language.
|
Yeah in retrospect that was a dumb thing to say, it's probably the majority of gameplay development these days but when UnrealScript is so poor compared to working with full source for UE, that's going to take up a lot of people so i'm not sure if that's true. There's definitely been a huge shift towards fast scripting languages for full engine middleware though, from Gamebryo (glad that's gone) to Unity to Blitztech and so on. It's not like the Id tech based approaches have done well in the last decade or so as middleware though, both Source and IdTech4 are really short on licensed titles. Plus if you were seriously doing the majority of gameplay programming in C++ I can't imagine how Rage ever got finished with all that compile time.
I mean you didn't address any of the other points though so I guess you agree with me on those?
|
Thank you so much for posting this
|
On December 02 2011 23:26 BisuDagger wrote:
I'm a video game developer, woot! Great article, glad your trying to get more people interested. It's a wonderful field to be in. Anyone who needs help or has questions about getting started feel free to pm me.
Btw, this article reminded me of when I wrote my first Gameboy Advanced game which was, oh so much fun :/
Who let you out of your hole?
Also about the whole c/c++/c#/cwhatever argument, if you learn the lowest level it will help you greater to understand the higher levels. The curriculum at my school (Full Sail in Florida) starts off with the most basic things and slowly works its way up so that you learn the "hard" way and the "easy" or convenient way to do things.
For example, we learned how to store data in a fixed size array, then a dynamic array, then how to use the STL vector. Each getting progressively easier to use but the knowledge of the previous helps a lot.
With the array knowledge we were able to learn how to construct basic strings before learning the STL string class.
I would highly suggest starting as low as possible and working your way up.
|
I think that this is just a list of things that you like to do because you think you're good at programming, AKA you're showing off.
|
On December 03 2011 09:36 RayGay wrote:
I think that this is just a list of things that you like to do because you think you're good at programming, AKA you're showing off.
Then don't read it. No need to make a new account just to tell me that 
|
On December 03 2011 08:28 Fandango wrote:
Yeah in retrospect that was a dumb thing to say, it's probably the majority of gameplay development these days but when UnrealScript is so poor compared to working with full source for UE, that's going to take up a lot of people so i'm not sure if that's true. There's definitely been a huge shift towards fast scripting languages for full engine middleware though, from Gamebryo (glad that's gone) to Unity to Blitztech and so on. It's not like the Id tech based approaches have done well in the last decade or so as middleware though, both Source and IdTech4 are really short on licensed titles. Plus if you were seriously doing the majority of gameplay programming in C++ I can't imagine how Rage ever got finished with all that compile time.
I mean you didn't address any of the other points though so I guess you agree with me on those?
Not necessarily I mostly just have work to do so I have to pick my battles .
To address a few more of your points:
I will agree that the most important things are language agnostic. For example solid OO design, task driven parallelism, algorithms, data structures, agile process.
I will still contend that you need to have a solid understanding of what your code actually does. This includes having a solid understanding of the target machine architecture and at least a working understanding of any language your code is compiled down to (IL, x86, ARM, etc). Knowing what the high level code you're writing is actually doing is important even in high level garbage collected managed languages. And while you don't need to always think about what your code is doing at the hardware level, being able to do that analysis makes you a more valuable coder and will subconsciously lead you towards better design.
The ability to learn new things quickly is important but somewhat misleading. Really it's the ability to apply existing knowledge to new circumstances.
Compile time is not an issue if you architect your code properly. Make use of components in separately compiled libraries and compilation firewalls. In lieu of good architecture you can always just throw money at the problem and use IncrediBuild.
|
On December 03 2011 09:21 Phrost wrote:
Also about the whole c/c++/c#/cwhatever argument, if you learn the lowest level it will help you greater to understand the higher levels. The curriculum at my school (Full Sail in Florida) starts off with the most basic things and slowly works its way up so that you learn the "hard" way and the "easy" or convenient way to do things.
For example, we learned how to store data in a fixed size array, then a dynamic array, then how to use the STL vector. Each getting progressively easier to use but the knowledge of the previous helps a lot.
That's always what bothered me about the CS major, which I am still working on. It seems like every time you struggle through some difficult class you're told at the end to not worry about how hard it was, you'll probably never have to do anything like that again. Then you move on to another class that ends with a similar process. It's kind of disheartening, especially since I love the C and assembly that I have done, and I feel like I thrive off of all the frustrating bit twiddling that I get sucked into all the time.
|
On December 03 2011 09:36 RayGay wrote:
I think that this is just a list of things that you like to do because you think you're good at programming, AKA you're showing off.
... and you're doing what, here?
Irony: kind of like iron.
|
On December 03 2011 10:10 Jaeger wrote:Show nested quote +On December 03 2011 08:28 Fandango wrote:
Yeah in retrospect that was a dumb thing to say, it's probably the majority of gameplay development these days but when UnrealScript is so poor compared to working with full source for UE, that's going to take up a lot of people so i'm not sure if that's true. There's definitely been a huge shift towards fast scripting languages for full engine middleware though, from Gamebryo (glad that's gone) to Unity to Blitztech and so on. It's not like the Id tech based approaches have done well in the last decade or so as middleware though, both Source and IdTech4 are really short on licensed titles. Plus if you were seriously doing the majority of gameplay programming in C++ I can't imagine how Rage ever got finished with all that compile time.
I mean you didn't address any of the other points though so I guess you agree with me on those? Not necessarily I mostly just have work to do so I have to pick my battles . To address a few more of your points: I will agree that the most important things are language agnostic. For example solid OO design, task driven parallelism, algorithms, data structures, agile process. I will still contend that you need to have a solid understanding of what your code actually does. This includes having a solid understanding of the target machine architecture and at least a working understanding of any language your code is compiled down to (IL, x86, ARM, etc). Knowing what the high level code you're writing is actually doing is important even in high level garbage collected managed languages. And while you don't need to always think about what your code is doing at the hardware level, being able to do that analysis makes you a more valuable coder and will subconsciously lead you towards better design. The ability to learn new things quickly is important but somewhat misleading. Really it's the ability to apply existing knowledge to new circumstances. Compile time is not an issue if you architect your code properly. Make use of components in separately compiled libraries and compilation firewalls. In lieu of good architecture you can always just throw money at the problem and use IncrediBuild.
My issue with the assembly/hardware architecture thing isn't that it isn't worthwhile or isn't valuable to know, it's that utility of that information when you're writing flash games or android games or really anything that's expected to run in a VM on a huge range of hardware setups is pretty minimal. Given the generally unspecialised nature of the work you'd be more efficient at what you do by learning how to do a wide range of game elements from physics engines to GUI systems to general good code architecture.
On the apply existing knowledge thing you're right that's a better way to put it and the above knowledge will certainly help with that. I keep wanting to say that C++ will inherently teach you most of the things you'll need to know but i'm wary since I did computer science so who knows what I take for granted.
|
Nice post, I actually just finished a 32 week diploma here at Media Design School in NZ that focused on game programming. I loved it, and would recommend the school to anyone in NZ or even in the general oceanic area that wants to do game dev stuff (either programming or art, you'll see why in a second), as the school is great. I'm actually going back next year to do the graduate diploma of game dev, where they mix programmers and artists together for some portions of the course, and all end up working together in teams a six month game project.
On my course, they assume you have no previous programming knowledge, and start teaching C++ from scratch. Our first assignment was actually a text based battleships. From there, we moved onto the Windows GDI and made some sprite games. Before we moved onto DirectX, they actually taught us how to do all the 3D maths, matrix transformations and projections etc manually, supposedly so we'd have a better understanding of the pipeline, but I have no idea if that helped. 
We actually ended with an 8 week team project, where we designed and then built a 3D game from scratch. Our class ended up with a Wipeout clone(my team), a Plants vs Zombies clone, and a more traditional tower defense game.
For me personally, I'm definitly going to use the break to work on some stuff before going back. Given that alot of the studios locally here, both game and non-game seem to be mobile/web focused, going to be looking at creating a mobile game or two. Also plan on fixing our collision detection based assignment (a pool game!), as I screwed it up.
|
On December 03 2011 11:04 Fandango wrote:Show nested quote +On December 03 2011 10:10 Jaeger wrote:On December 03 2011 08:28 Fandango wrote:
Yeah in retrospect that was a dumb thing to say, it's probably the majority of gameplay development these days but when UnrealScript is so poor compared to working with full source for UE, that's going to take up a lot of people so i'm not sure if that's true. There's definitely been a huge shift towards fast scripting languages for full engine middleware though, from Gamebryo (glad that's gone) to Unity to Blitztech and so on. It's not like the Id tech based approaches have done well in the last decade or so as middleware though, both Source and IdTech4 are really short on licensed titles. Plus if you were seriously doing the majority of gameplay programming in C++ I can't imagine how Rage ever got finished with all that compile time.
I mean you didn't address any of the other points though so I guess you agree with me on those? Not necessarily I mostly just have work to do so I have to pick my battles . To address a few more of your points: I will agree that the most important things are language agnostic. For example solid OO design, task driven parallelism, algorithms, data structures, agile process. I will still contend that you need to have a solid understanding of what your code actually does. This includes having a solid understanding of the target machine architecture and at least a working understanding of any language your code is compiled down to (IL, x86, ARM, etc). Knowing what the high level code you're writing is actually doing is important even in high level garbage collected managed languages. And while you don't need to always think about what your code is doing at the hardware level, being able to do that analysis makes you a more valuable coder and will subconsciously lead you towards better design. The ability to learn new things quickly is important but somewhat misleading. Really it's the ability to apply existing knowledge to new circumstances. Compile time is not an issue if you architect your code properly. Make use of components in separately compiled libraries and compilation firewalls. In lieu of good architecture you can always just throw money at the problem and use IncrediBuild. My issue with the assembly/hardware architecture thing isn't that it isn't worthwhile or isn't valuable to know, it's that utility of that information when you're writing flash games or android games or really anything that's expected to run in a VM on a huge range of hardware setups is pretty minimal. Given the generally unspecialised nature of the work you'd be more efficient at what you do by learning how to do a wide range of game elements from physics engines to GUI systems to general good code architecture. On the apply existing knowledge thing you're right that's a better way to put it and the above knowledge will certainly help with that. I keep wanting to say that C++ will inherently teach you most of the things you'll need to know but i'm wary since I did computer science so who knows what I take for granted.
FWIW I just finished working on a Flash game for facebook using AS3, PHP and Javascript and I'm currently working on an iOS game using C# in Unity so it's not like I don't have perspective on the kinds of projects you're talking about.
I find that knowledge valuable and very useful.
|
C++ is a terrible language (even compared to C), but it is absolutely necessary if you want to work for a large games studio.
Knowing C will hardly help when it comes to C++ either, it is completely different, only that C++ is backwards compatible with C, so you can write C and claim you are doing C++  . The only areas C will help is with learning basic programming concepts like functional decomposition and memory management, after that, everything is different.
Its also important that you know assembly language, as with working with huge games, it is vital for debugging.
I originally wanted to become a games programmer. Although I know C++ as well as a ton of other languages, I won't be doing games programming simply because I hate C++ . I worked on phone and facebook games for a while in Obj-C and Ruby (I love Ruby!) but everyone was really stressed out and I didn't like working there.
On December 03 2011 04:05 iPAndi wrote:
By the way, im wondering why don't you use something like Microsoft Visual C++ to learn C++ coding instead of DevC++? I mean, dont get me wrong, i loved devc++, but i think Microsoft has such an awesome tool its not even worth digging into devcpp.
Windows is a terrible platform for doing Dev work. I love working on Linux, and its so easy and quick to set up and isolate dev environments. Mac is ok simply because of Bash, but apart from that, its still Windows as far as developing is concerned. I do all my dev work in Xmonad, I am 100x more productive in a tiling window manager, than a crappy point and click one.
|
On December 03 2011 11:48 sluggaslamoo wrote:
Knowing C will hardly help when it comes to C++... it is completely different...
The whole point of learning C, according to the professionals at my school, is that it is different from C++.
|
|
|
|
|
|
EPT
