If you haven't yet seen my first game programming post, go check it out! Here's the second one.
I've been as busy as ever learning all I can while attending my CS degree, and I'd love to share what I learn for free with people that want to better themselves. Don't know programming much, but interested? Anyone can learn, it's not some difficult or far away unacheivable goal that only genius can reach (see below section for absolute beginners). I know of three different ways to program video games for new developers that I can recommend*: C, Flash, and Python.
*Can't recommend anything I haven't tried! There are definitely other options out there, these are just what I have personal experience in.
Python Lets face it, Python has some very clean syntax. It also has some extremely newcomer friendly features such as dynamic typecasting -this means all variables are typeless to the programmer. You can assign a string to a variable, then an integer without compiler errors. There are wonderful resources like PyGame for developing games within Python. All around programming with Python is always extremely fun for me, and so I recommend it to new programmers looking to try out different things.
Flash Flash doesn't have as awesome of a syntax as Python, in my opinion, but it's also very easy to use and learn to develop with. ActionScript is the name of the language used to develop Flash applications. ActionScript 3 is what is currently released to develop in.
There are immense amounts of documentation out there for anyone to get going on developing games in Flash, and due to the easy access of such resources and easy-going nature to get projects up pretty quick I highly recommend flash to anyone wanting to learn to program video games as a hobby.
There are even awesome places like Kongregate, or the iPhone app store that allows Flash games to have immense potential in generating revenue!
C Now for C. Why C? Why not Java, or C++? Well I recommend C for those who have a desire to eventually work in a professional setting for game development in C++. Grounding yourself in C first gets you accustomed to working in a language that gives you complete access to everything you want. Langauges like Python hide a lot of low-level interaction from the developer to make things easier or more time-efficient. However, in real-time applications that are demanding on hardware require a much more fine-tuned and optimized structure to function well. C++ lets professionals do this, and it is the industry standard. However, I'm a strong proponent of learning C before C++. Learning C first lets you understand the limitations of C on an intimate level, and by learning of these limitations you learn to make highly effective use of the features presented in C++.
I'm currently at that stage of transitioning from C to C++, and so I'll be writing about this subject next. There will be a detailed post about object orientation within C, with regards to inheritance and especially to polymorphism, although I've written a short version here.
In C you can make use of structs and function pointers in order to emulate the class system within C++. If you've read my state manager post and understand the benefits it provides, then you can easily incorporate class-like objects in your C code. Each object is simply a structure. Each object holds the following function pointers:
Construct - Allocation and loading of any required space or data to attach onto the object via pointers. This would include AI data, animation sequence, etc.
Initialize - Initialize allocated space from the Construct function, and initialize all data to prepare for use.
Update - Uses delta time to update all of the object's data and perform all behavior logic.
Draw - Render object and other effects from object to screen.
Destruct - Deallocate all space allocated involving the object.
The object struct also has a tag inside of it (just an integer will work, preferably an enum value) to determine what type of object your struct is. Then when the object is allocated through your memory management system, you initialize these function pointers to point to a set of functions corresponding to the type of object you are creating. For example I could have a file called Bat.c to create a bat object. Inside of Bat.c I have functions BatInit, BatDraw, BatUpdate, etc. When I allocate my object structure and want to create a new bat object, I initialize the function pointers within this structure to the ones in Bat.c. This then allows you to easily loop through a list of all live objects during your update/draw states, and make appropriate function calls to all your different types of objects!
The way this works is by making use of the void pointer. By using a void pointer as your function arguments within your objects, you can create classes, and even emulate inheritance with those classes. If all you do when you inherit from one class to another is extend the structure, then you can make use of simple inheritance. For example say you have a Structure.c file with the corresponding Structure functions to Construc, Destruct, Init, etc. Then, you copy/paste the Structure struct definition into a new header file called GoblinStructure. You then add in same data members to the struct. You can still pass your GoblinStructure to the Structure functions and all will be well. This is because the same data members will be accessed at the same points in memory with the Structure functions no matter if a GoblinStructure is passed or a Structure is passed. If this is confusing, wait for the better-documented post!
I've been keeping a personal blog chronicling the steps taken to become a professional game programmer, as well as attempting to provide a free resource for anyone wanting to learn to program games.
As such, I'd love to share some excerpts from my recent posts with you all! Lets start with a continuation from where my last TL post left off. The last post was about the painter's algorithm, though the more recent ones were more generalized to apply to any coding project.
Excerpt: Variable Sized Struct: In the previous post I had talked a little bit about image ordering, and image transparency. The way the image data was held in memory was very quirky! We had to create an entire header file for each image, and each image had to be an entirely different structure definition due to arrays of data being different from image to image.
I'd like to show you a method that makes use of some clever macros in order to achieve an interesting variable-sized image structure! The idea was actually brought to me by a friend of mine named Malcolm Smith. Here's the structure design for an object to be dynamically sized during run-time, in our case for images:
typedef struct _Image { int width; int height; unsigned char *chars; unsigned char *colors; } Image_;
In the above structure we have two pointers, one to chars and one to colors. These pointers will point to arrays of unsigned characters, which is the datatype that represents both colors and characters for the Window's console. In order to access these arrays, you should recall that the name of an array can be treated the same as a pointer to the first element in the array. So after we allocate space for our arrays we'll need to initialize chars and colors properly by setting them to point to the first element in our arrays.
In order to go about allocating our space properly we need to allocate the space of the Image_ structure, space for the width * the size of our character array * height, and finally space for our color array * width * height. Here's a call to malloc to this in one single swoop:
The nice thing about this sort of allocation is that it isn't broken up into separate allocation calls, which speeds up the process since allocation is slow. This also keeps all the parts of memory in the same location in memory all adjacent to one another, as opposed to who knows where in memory when malloc is called multiple times, thus lessening memory fragmentation.
...
I plan to continue on my series of creating Windows console game to the point where someone can pick up programming without any experience, and finish a fine product in C from scratch! I can remember back in highschool when I first decided I wanted to program for a living and had no idea where to start. Especially for game programming. Back then I wished I could stumble onto someone's blog and find good, concise explanations and answers, as I had nobody I could directly talk to about the subject. Hopefully I can help to solve that predicament for anyone here interesting in learning to program!
Recently I've had the chance to apply some of the concepts I've written about, such as Vector Physics and Program Structure/Design, in a game of Asteroids! Check out a video I made showing some ridiculous particles flying all over.
http://www.youtube.com/watch?v=zDdKNJnv_VQ
If you're the straightforward type, you can take a look at the pseudo code involved in the physics of the video above. It's actually extremely simple, and anyone with an understanding of basic algebra can achieve some very cool physics effects from very simple code:
// Find current direction vector dirVect.x = cos( radianOrientation ); dirVect.y = sin( radianOrientation );
// Add a value scaled by dt to rotate orientation if(keypress( LEFT )) radianOrientation += ROTATION_SPEED * dt; // Bound checking for pi and -pi if radianOrientation > PI radianOrientation = -PI else if radianOrientation < -PI radianOrientation = PI
// Subtract a value scaled by dt to rotate orientation if(keypress( RIGHT )) radianOrientation -= ROTATION_SPEED * dt; // Bound checking for pi and -pi if radianOrientation > PI radianOrientation = -PI else if radianOrientation < -PI radianOrientation = PI
// Update position with our new calculated values pos.x += vel.x * dt pos.y += vel.y * dt
However, what if you're completelynew to programming and know really just about nothing? Well, I've written a nice post about getting started with the C language, and I don't assume you know anything! In about an hour you can be well on your way to writing programs that deal with simple mathematical statements, and even print output of those statements onto the screen! Here's an excerpt from the blog post I wrote called I Want to Learn Programming, but I Know Nothing!:
CecilSunkure wrote on his Blog: So you want to learn to program. Great! So you're reading this article, and here you'll learn to start with C on a Windows Operating System. Starting with C is an excellent place to start, as it grounds you with a very solid base of understanding for programming in general, that of which I feel is easily transferable to other languages! I even feel that once you learn the basics of C and transfer to another language (I recommend Python!) you'll be better off in the long run than if you started with another language and then moved to C (perhaps start with Java and move to C). I won't get into deep details about this point as that's out of the scope of this article, but you should definitely take my word on the matter!
...
You can write your C code in any text editor you like. You can just simply use notepad (to open hit windows key+r and type notepad, then hit enter), though I recommend using the IDE apart of Visual Studio. Once you write some C code, save your file as a .c file and then use a compiler to turn it into a .exe file.
Now what about this compiler business. You might have already googled for a C compiler by now and noticed that there is a multitude of compilers out there. Luckily I have one to recommend to you! Download and install Visual Studio 2010 Express.
When installing you'll be ask if you have a CD. Just say no and download the installation from online. Once you see this screen (mine is reinstalling however):
Be prepared to restart your computer in the middle of the installation. For some reason this installation took a long time, so be patient! After you restart, at the end of the installation it says: requires a key. Go ahead and hit the button to acquire one; you'll need a microsoft address from something like live.com. Once you fill out this lame questionnaire with fake answers copy/paste your key into the box and continue! You're now ready to code your C programs, and compile them! ...
There's also a sneak peak preview of a game I'm constructing with a team of 3 other members for our second semester project... Prepare to be in awe of our awesome pixel art madness! The idea of the game is you play as a Forest fighting against a faction of Grumpy Monsters who are corrupting the land. Game concept was inspired by this unfinished Flash game I found one day: link. The cool thing about the project is that it applies most of all the topics I've been writing about lately, especially the soon-to-come topic of Object Oriented C. How else would you make an RTS without object orientation?
Sneak peak screenshot of semester project!
I know you'll all feel at home playing an RTS game, which is what the above screenshot will be. I'll likely make a blog post about it when the time comes and hopefully have all you RTS pros playtest the game ^^
On February 28 2012 15:14 Rayeth wrote: I think you have some good idea here, but I want to put forward that the C++ vs C argument changes when you don't want to work in a games setting. For example, I work in embedded systems and use C almost exclusively for various reasons (very low level access to things like timers, registers, or other hardware; need to save cycles due to low power processors; and the compilers aren't standard and therefore limit our language choice). So the choice you make on what language to use is really dependent on what situation you're in. Gaming on a modern PC is one thing, but there are TONS of systems out there that don't have gigabytes (or even megabytes) of memory for you to use, and in these cases C (or sometimes even assembly) are pretty much all you've got.
This changes the game completely, of course. Everything becomes about how to optimize memory usage and how to do more with less. Making things work in confining situation is an altogether different type of skill from the creative impulse (IMO) needed to develop games. There is often time very little visual feedback when things are broken, which makes for fun times figuring out bugs. I like to think it makes me very good at spotting and fixing memory leaks, but I can't say that for certain
Anyhow, that isn't to say C++ or things like Python, etc don't have their places in embedded designs too. There are LOTS of different systems out there. Most can be done in many languages and are relatively fast and easy to use. For anyone interested in doing (or even trying out) embedded stuff, I find the MSP430 from Texas Instruments a great starter. Plus at only $4.30 its pretty damn cheap and has a wide array of hardware for you to mess around with. Plus there is a great community that uses that processor family if you need basic help.
Anyhow. Good blog! And remember there are lots of things to do with programming besides gaming. Computers really are EVERYWHERE these days.
as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
My anger at you recommending flash was cooled off by your description of C, though. But i think you exaggerate how much more helpful it is to start with C just so you understand the benefits and additions of C++ better; its not a huge deal; to me C and C++ are very very very similar and there is no disadvantage of simply learning C++ first, as the usefulness and proper applications of the additional functions of c++ over c can be intuitively learned rather than directly learned by having used pure c.
I would agree with you on learning pure c if you are going to use objective-c for iphone/ios development and don't already know c++. even so in that case, provided its not your first programming language, just learning objective-c and working out proper usage of the features through usage and intelligence/knowledge that grows while you learn, is probably the more efficient route. I firmly believe in separating the learning of concepts and languages, rather than thinking purely in terms of using a specific language to learn a specific set of programming concepts and then moving on to other languages..
It also has some extremely newcomer friendly features such as dynamic typecasting -this means all variables are typeless to the programmer. You can assign a string to a variable, then an integer without compiler errors.
Holy crap I never knew that. That's just like Game Maker. It's an awesome feature ^^
I think I'm pretty similar to you, as I also want to be a game programmer and I am currently in high school. I'm learning Java in my AP CS class (Java is the only language they teach), and I'm pretty good at it as I already knew some basic stuff going into that class from messing around with Game Maker and the BW map editor (triggers require some programming-like logic).
Next year I'm doing an independent study in CS, in which I plan to go even further in Java, whilst learning C. I know that Java and C have a lot of similarities, so it shouldn't be too messy of a transition.
I enjoy reading your posts, even though I don't understand some of them due to not knowing C's syntax. But I wish you the best of luck as you continue to program your games!
...And also that is some sexy pixel art. I'll play any game with good 2d pixel art, even if it's a shit game. I just love pixel art (even though I suck at it).
Please don't recommend Dev-C++. It's out of date and buggy as hell. The express versions of Visual Studio are a much more solid choice.
Something like the Unity game engine would also be a great thing to point out to beginners. It uses C# and / or a variant of Javascript, both of which are probably much easier to learn than either C or C++. There's also no faffing around with setting up an environment or compiler (which I think for me was one of the most problematic and time-consuming things about learning to program).
I think Unity gives a nice top-down view of what actually goes into making a game (art-assets, scripts, textures, shaders and such), and how it fits together, as opposed to starting right at the nitty details in C. I suppose it depends somewhat on the end goal - learning to program, or making games.
On February 23 2012 08:15 netherh wrote: Please don't recommend Dev-C++. It's out of date and buggy as hell. The express versions of Visual Studio are a much more solid choice.
I completely forgot there is the express version. I'll download and try that out, then re-write the post. I wanted to write it about Visual Studio but didn't want to recommend something that wasn't free. Thanks!
This is bad advice imho. There are good and bad reasons for learning C. Learning C to write C-code is fine but learning C to write C++ is just not very smart. Great C programmers make bad C++ programmers and vice-versa.
C++ especially now with C++11 being finalized is becoming a whole different beast than C. I can clearly see the appeal of C. It doesn't have as many complex elements and corner cases but C++ for while now has been a lot more than "C with classes". Mixing modern C++ with "malloc", "memcpy", "free" and the like is just asking for trouble, Many people (including Bjarne Stroustrup the original developer of C++) even discourage using "new" and "delete" in modern C++.
For some examples of modern C++ look at these talks from the "Going Native 2012" conference
Regarding your little C class-like structs. They are more inefficient than C++ classes. Essentially they are the C++ equivalent of virtual functions and those are discouraged in performance-critical parts of the code. They use more memory per object and prevent optimizations like in-lining.
A very useful advice that netherh kinda mentioned is to learn C#. With XNA, you'll be able to program games in no time. For someone that "only wants to program games" this is the best advice one can give imho
I also don't really agree on C being more professional, there really is no significant difference in that regard. If anything, C libs/content is getting outnumbered by newer C++ stuff.
Other than that, nice blog. I always enjoy your blogs.
On February 23 2012 10:48 KeksX wrote: A very useful advice that netherh kinda mentioned is to learn C#. With XNA, you'll be able to program games in no time. For someone that "only wants to program games" this is the best advice one can give imho
I also don't really agree on C being more professional, there really is no significant difference in that regard. If anything, C libs/content is getting outnumbered by newer C++ stuff.
Other than that, nice blog. I always enjoy your blogs.
I'd recommend C#, but I haven't used it, so I cannot. I also don't think "C is more professional" than C++. I just really liked learning it and its limitations before moving on to C++. I'm also told by a lot of respectable professors here that it's a very good approach in learning.
On February 23 2012 07:29 nath wrote: as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
Haha don't forget I said as a hobby. You know, for fun. A side project.
This is bad advice imho. There are good and bad reasons for learning C. Learning C to write C-code is fine but learning C to write C++ is just not very smart. Great C programmers make bad C++ programmers and vice-versa.
I didn't really intend to say you should learn C to write C++. I just meant I think it's proper to learn C and it's limitations before learning C++. Note that I implied you still have to learn C++ after you learn C, as in I implicitly acknowledged that they are different, or as you stated different beasts.
On February 23 2012 09:53 Bigpet wrote: Regarding your little C class-like structs. They are more inefficient than C++ classes. Essentially they are the C++ equivalent of virtual functions and those are discouraged in performance-critical parts of the code. They use more memory per object and prevent optimizations like in-lining.
Me and my little C class-like structs aren't claiming to be efficient or all-powerful. The point in me using and writing about them, is in their organizational advantages. I'm just a Freshman student writing about my learning experiences hoping to share them with others.
This is bad advice imho. There are good and bad reasons for learning C. Learning C to write C-code is fine but learning C to write C++ is just not very smart. Great C programmers make bad C++ programmers and vice-versa.
C++ especially now with C++11 being finalized is becoming a whole different beast than C. I can clearly see the appeal of C. It doesn't have as many complex elements and corner cases but C++ for while now has been a lot more than "C with classes". Mixing modern C++ with "malloc", "memcpy", "free" and the like is just asking for trouble, Many people (including Bjarne Stroustrup the original developer of C++) even discourage using "new" and "delete" in modern C++.
For some examples of modern C++ look at these talks from the "Going Native 2012" conference
Regarding your little C class-like structs. They are more inefficient than C++ classes. Essentially they are the C++ equivalent of virtual functions and those are discouraged in performance-critical parts of the code. They use more memory per object and prevent optimizations like in-lining.
You're making the assumption that he plans on using C style and functions in future C++ programs. It's nice to learn C first because you can learn the syntax and basic usage without jumping straight into the added complexity of objects, references, virtual functions, etc.
It's also good to know the subtle differences between C and C++ in case you ever find yourself needing to write a C program.
On February 23 2012 08:15 netherh wrote: Please don't recommend Dev-C++. It's out of date and buggy as hell. The express versions of Visual Studio are a much more solid choice.
I completely forgot there is the express version. I'll download and try that out, then re-write the post. I wanted to write it about Visual Studio but didn't want to recommend something that wasn't free. Thanks!
Hm I remember when I was learning programming everybody recommended me to go straight to C++ because if I learned C then C++ I would get bad habbits from C. I remember asking it on a popular programming forum that I can't remember for the life of me lol. So I disagree with you on learning C first.
On February 24 2012 17:06 blade55555 wrote: Hm I remember when I was learning programming everybody recommended me to go straight to C++ because if I learned C then C++ I would get bad habbits from C. I remember asking it on a popular programming forum that I can't remember for the life of me lol. So I disagree with you on learning C first.
You definitely learn habits from C that don't apply to C++, and vice versa. I think that's pretty minor compared to the advantages though. But I can totally understand, you stand by what people told you and so do I.
On February 24 2012 17:06 blade55555 wrote: Hm I remember when I was learning programming everybody recommended me to go straight to C++ because if I learned C then C++ I would get bad habbits from C. I remember asking it on a popular programming forum that I can't remember for the life of me lol. So I disagree with you on learning C first.
You definitely learn habits from C that don't apply to C++, and vice versa. I think that's pretty minor compared to the advantages though. But I can totally understand, you stand by what people told you and so do I.
Learning C before C++ is good advice. C is a nice little language. Once you're familiar with it, take a deep breath and start a never-ending process of learning the mess that is C++.
The problem I have with advising to learn C before C++ is it implies there's some underlying benefit or advantage when, in my experience, there isn't any. Not to mention it looks like you're using Visual Studio so you're learning C89, which is quite out-dated and you'll never be exposed to much of the stuff you'll see in modern C compilers (there's a C99 and C11 standard of which VC supports nothing beyond that which happens to exist in both C & C++).
I can't think of what magic tricks you're expecting to learn by learning C before C++, so I can't think of why you'd actually want to learn C before C++ except in the case that you're going to write C code and not C++. The earlier you expose yourself to "complex" (they aren't by the way) topics like objects, relationships, generic programming, and what-not the easier it will be for you. Not to mention it's a lot easier to jump down a level from C++ to C than it is to go up a level from C to C++ in terms of abstractness.
Plus learning C++ you'll learn quite a few basic C concepts. Even if you don't plan to use them, you'll have to learn about char, etc. You can't work with the Win32 API and live in a pure C++ world unfortunately.
No. Learn C++ first. The C subset of C++ is easier to learn for C/C++ novices and easier to use than C itself. The reason is that C++ provides better guarantees than C (stronger type checking). In addition, C++ provides many minor features, such as the `new' operator, that are notationally more convenient and less error-prone than their C alternatives. Thus, if you plan to learn C and C++ (or just C++) you shouldn't take the detour through C. To use C well, you need to know tricks and techniques that aren't anywhere near as important or common in C++ as they are in C. Good C textbooks tends (reasonably enough) to emphasize the techniques that you will need for completing major projects in C. Good C++ textbooks, on the other hand, emphasizes techniques and features that lead to the use of C++ for data abstraction and object-oriented programming. Knowing the C++ constructs, their (lower-level) C alternatives are trivially learned (if necessary).
Python: I've never really used it, seems simple enough. Not needed as much as you think. Although getting a feel for a basic-like syntax might help with beginners. Flash: Ew, game programming with Flash is lame, more for non-programmer people. C: I learned C++ "before" C and I wouldn't say it was any harder. I'm not going to nit-pick what pro and cons of learning each language is, just want to say that C++ is more modern and the benefits of learning C++ is that C knowledge comes free with it, otherwise you will have to go out of your way learning C++ after learning C.
I think it's awesome that you want to share information. But I think you can do it in a more structured style. This post seems to have several directions and bombards with information. If this for beginners like you say, then you should fully type out the syntax in your sample code, (like using curly braces and following coding standards). Also there is no way a beginner will understand complex syntax and terms so don't even bother. Bringing up void pointers and vectors in a introductory thread is too much for complete noobs, there are other things they need to learn first.
On February 26 2012 08:47 emucxg wrote: Nice blog man. I have done a lot small programs with different kind of algorithms(I love math-like challenges xD), but never done any games yet.
But,ya im definitely interested
I have one question, when i start coding a game, for example tic tac toe, should i always start from GUI first or not?
Nah I think you should just work in a windows console. Check out my series on creating a Windows Console game after you make a few programs in C.
For C reference, I suggest C Programming a Modern Approach 2nd Edition by K.N. King. That books absolutely rocks.
Flash is great if you want to make some quick cash on the side, easily. But if your looking to make a larger, deeper game, or get into a big or independent company you'll want C++ or C#, or maybe even LUA depending on the game.
Knowing C is never a bad thing simply because (obviously) its a faster language that has some pretty good usage. But with classes it makes transitioning to or from C an awkward experience as well as alloc commands that are wildly different from just using deconstructors.
objective C is a good language that will look good on a resume as well if you want to branch out.
On February 28 2012 13:46 Warpath wrote: Knowing C is never a bad thing simply because (obviously) its a faster language that has some pretty good usage. But with classes it makes transitioning to or from C an awkward experience as well as alloc commands that are wildly different from just using deconstructors.
I don't think any learning programmer will feel transitioning to or from C to be so awkward as to think it would have actually been better to not learn C at all. I consider transitioning to/from C to be very trivial in terms of syntactical awkwardness, or even awkward in terms of switching to/from a procedurally oriented language like C.
I think you have some good idea here, but I want to put forward that the C++ vs C argument changes when you don't want to work in a games setting. For example, I work in embedded systems and use C almost exclusively for various reasons (very low level access to things like timers, registers, or other hardware; need to save cycles due to low power processors; and the compilers aren't standard and therefore limit our language choice). So the choice you make on what language to use is really dependent on what situation you're in. Gaming on a modern PC is one thing, but there are TONS of systems out there that don't have gigabytes (or even megabytes) of memory for you to use, and in these cases C (or sometimes even assembly) are pretty much all you've got.
This changes the game completely, of course. Everything becomes about how to optimize memory usage and how to do more with less. Making things work in confining situation is an altogether different type of skill from the creative impulse (IMO) needed to develop games. There is often time very little visual feedback when things are broken, which makes for fun times figuring out bugs. I like to think it makes me very good at spotting and fixing memory leaks, but I can't say that for certain
Anyhow, that isn't to say C++ or things like Python, etc don't have their places in embedded designs too. There are LOTS of different systems out there. Most can be done in many languages and are relatively fast and easy to use. For anyone interested in doing (or even trying out) embedded stuff, I find the MSP430 from Texas Instruments a great starter. Plus at only $4.30 its pretty damn cheap and has a wide array of hardware for you to mess around with. Plus there is a great community that uses that processor family if you need basic help.
Anyhow. Good blog! And remember there are lots of things to do with programming besides gaming. Computers really are EVERYWHERE these days.
On February 28 2012 15:14 Rayeth wrote: I think you have some good idea here, but I want to put forward that the C++ vs C argument changes when you don't want to work in a games setting. For example, I work in embedded systems and use C almost exclusively for various reasons (very low level access to things like timers, registers, or other hardware; need to save cycles due to low power processors; and the compilers aren't standard and therefore limit our language choice). So the choice you make on what language to use is really dependent on what situation you're in. Gaming on a modern PC is one thing, but there are TONS of systems out there that don't have gigabytes (or even megabytes) of memory for you to use, and in these cases C (or sometimes even assembly) are pretty much all you've got.
This changes the game completely, of course. Everything becomes about how to optimize memory usage and how to do more with less. Making things work in confining situation is an altogether different type of skill from the creative impulse (IMO) needed to develop games. There is often time very little visual feedback when things are broken, which makes for fun times figuring out bugs. I like to think it makes me very good at spotting and fixing memory leaks, but I can't say that for certain
Anyhow, that isn't to say C++ or things like Python, etc don't have their places in embedded designs too. There are LOTS of different systems out there. Most can be done in many languages and are relatively fast and easy to use. For anyone interested in doing (or even trying out) embedded stuff, I find the MSP430 from Texas Instruments a great starter. Plus at only $4.30 its pretty damn cheap and has a wide array of hardware for you to mess around with. Plus there is a great community that uses that processor family if you need basic help.
Anyhow. Good blog! And remember there are lots of things to do with programming besides gaming. Computers really are EVERYWHERE these days.
Oh interesting response! I actually took a class where I had to program on a microcontroller chip in Assembly. We had to create a program to automate a robotic car. Had to use analog to digital converters to read the voltage from the car's sensors. I was talking to one of my professors today about programming on some very old console in Assembly, he didn't mention what it was, but it was extremely interesting to hear about.
Thanks for another blog... In regards to the various language discussions going on:
I work in insurance as a developer and i have to point out that it is much more important to learn decent programming fundamentals than to focus on language specifics in any given situation! I will often find myself using 3 or 4 different languages every day, and aside from the occasional key word confusion (use? Import? Include? Gah what language am I in again?) It's fairly easy to work across a broad spectrum of tools and systems if you have decent fundamentals.
Obviously some languages are better suited for dev in some situations than others, but in regards to game programming, OpenGL feels the same no matter what you code it in!
You must include Quad- and Octrees - for culling and collision detections. Yes, I know there are better methods, but these 2 are the simplest to implement, but still effective. Oh, some general guide on AI would be good, although it is a big topic and in the different situations the inner working of the AI would be different.
Nice blog. As a fairly veteran game programmer, I find it interesting that you find C easier as a stepping stone to C++. Out of the two, it is by far easier to write larger games using C++ because of the structure lent by the language. However, C is slightly superior when it comes to tweaking performance, especially when you become conscious of performance bottlenecks such as cache misses and memory fragmentation. You'll find that a lot of game code is written in C++ because of the scalability, but a lot of game engine code is tweaked in C or even assembly if it comes to that.
But that aside, as a learning language, anything flies. Even things like Flash are not useless. A lot of game companies use Flash for their UI through products like Scaleform or GameSWF. What matters is learning how to structure code efficiently, as well as developing a sense of design and flair.
I really like the .NET XNA Framework as a way to try game development.(http://msdn.microsoft.com/en-us/aa937791)
It uses C# built on top of the .NET Framework, uses DirectX and even supports the XBox as a target to play your own games. C# is a very open to beginners but it is also based on C (C++ is the most used language in professional gaming development) There are a lot of examples and tutorials directly from Microsoft.
The development environment is Visual Studio, and the very good Express Version is free for personal use!
I am a professional developer and working with C# most of my time at work. So it was a really cool way to try and get into game development. For me the barrier to get more into game dev is not the Language or it's framework. It is... MATH : (
On February 23 2012 07:54 ClysmiC wrote: I know that Java and C have a lot of similarities, so it shouldn't be too messy of a transition.
??? Java and C are about as different in programming languages as you can get.
If you want to make games you should learn Java, C# (XNA 4.0) or Python.
In fact, C# and Java are so similar in syntax and design you can barely tell the difference.
If you want to be a programmer, learn C/C++ as well.
Are most or a significant portion of commercial high end games coded in C/C++? Yes.
How many programmers? A lot.
What do they do? They debug and "glue" together a pre-existing Engine with pieces artists and designers make. They develop tools for their designers to easily and more efficiently use the Engine. They don't make games.
The only interesting part of learning C/C++ is being able to use Game Engines that require its proficiency. Game engines that usually cost a lot of money to use and takes a lot of time to learn.
Want to make games? Learn Java or Python. C# with XNA 4.0 is really awesome too ( You might need to registerwith a 1 year fee of 99$ to microsoft to sell your games ).
If you get more interested in programming and how computers work in general rather than making games, learn C/C++.
- If someone wants to try out game design, but don't know/don't want to know a lot of programming, Construct 2 is a good place to get your feet wet. This just came out earlier this month, and is a great little visual editor.
- I'll also echo the C#/XNA recommendation for people getting started. It's a great language that can do simple things easily, but can also scale to professional projects (like Terraria, or Bastion). Microsoft also has some great tutorials (more in the MSDN).
- If you're going to do something in flash, also consider the wonder Flixel library.
I know that going straight into C++ might be more flexible, but a lot of people want to do some game design without spending all their time implementing their own physics and graphics engines. Using libraries and editors like these will be a fun way to start learning the game design concepts without nearly as much tedious overhead.
Use Java/C++ for heavier weight stuff. There's also always the option of Python and friends compiling down to C. If you're going to use OpenGL in a practical level outside of the default imperative mode(I think its called that) you'll have to get fairly low level with GL pointers, byte array serialization, and mem copies so you are a bit SoL unless you can find a really good library for it.
On February 28 2012 15:14 Rayeth wrote: I think you have some good idea here, but I want to put forward that the C++ vs C argument changes when you don't want to work in a games setting. For example, I work in embedded systems and use C almost exclusively for various reasons (very low level access to things like timers, registers, or other hardware; need to save cycles due to low power processors; and the compilers aren't standard and therefore limit our language choice). So the choice you make on what language to use is really dependent on what situation you're in. Gaming on a modern PC is one thing, but there are TONS of systems out there that don't have gigabytes (or even megabytes) of memory for you to use, and in these cases C (or sometimes even assembly) are pretty much all you've got.
This changes the game completely, of course. Everything becomes about how to optimize memory usage and how to do more with less. Making things work in confining situation is an altogether different type of skill from the creative impulse (IMO) needed to develop games. There is often time very little visual feedback when things are broken, which makes for fun times figuring out bugs. I like to think it makes me very good at spotting and fixing memory leaks, but I can't say that for certain
Anyhow, that isn't to say C++ or things like Python, etc don't have their places in embedded designs too. There are LOTS of different systems out there. Most can be done in many languages and are relatively fast and easy to use. For anyone interested in doing (or even trying out) embedded stuff, I find the MSP430 from Texas Instruments a great starter. Plus at only $4.30 its pretty damn cheap and has a wide array of hardware for you to mess around with. Plus there is a great community that uses that processor family if you need basic help.
Anyhow. Good blog! And remember there are lots of things to do with programming besides gaming. Computers really are EVERYWHERE these days.
Oh interesting response! I actually took a class where I had to program on a microcontroller chip in Assembly. We had to create a program to automate a robotic car. Had to use analog to digital converters to read the voltage from the car's sensors. I was talking to one of my professors today about programming on some very old console in Assembly, he didn't mention what it was, but it was extremely interesting to hear about.
TI-83 assembly is also fairly simple, produces immediate results, and the likelihood of having a TI-83 calculator is usually quite high. I used to write random games and apps on it throughout college.
Pro-tip: never test your game less than 1 hour prior to a big math test
On February 28 2012 20:28 iNViCiOUZ wrote: I really like the .NET XNA Framework as a way to try game development.(http://msdn.microsoft.com/en-us/aa937791)
It uses C# built on top of the .NET Framework, uses DirectX and even supports the XBox as a target to play your own games. C# is a very open to beginners but it is also based on C (C++ is the most used language in professional gaming development) There are a lot of examples and tutorials directly from Microsoft.
The development environment is Visual Studio, and the very good Express Version is free for personal use!
I am a professional developer and working with C# most of my time at work. So it was a really cool way to try and get into game development. For me the barrier to get more into game dev is not the Language or it's framework. It is... MATH : (
From personal expecience, I'd recommend XNA as well. The logic is really easy to understand there and C# feels more intuitive to me, and is also easier than C/C++ imo. We had to create a video game last year at school. We were a group of 6 students (4 ppl on the dev part, 1 on the map creation and 1 on the design) and we managed to make something really pleasant to play and also really evolved for the time we were given (more or less 4 days). Also, none of us did know anything about XNA before this project, we were only used to C# due to previous projects. This year I managed to implement some advanced features on it like pathfinding so there are plenty of possibilities.
Good blog, keep up the good work The most fun you will have is branching out and starting to develop in other languages, I have fond memories of my first haskell game.
And C++ before C if it's self learned but C before C++ when starting studying CS for example at the university, but I am biased towards learning it imperativ->objectiv->functional->logical
On February 29 2012 10:31 King K. Rool wrote: ah nice!
tbh 3-d graphics programming sort of killed my passion for writing any code for games. Hope you don't have the same problem.
How? 3d programming is awesome fun and extremely simple once you know it, there's a lot of reading required (FBO's, VBO's, atlas-ing and the like) but you don't really need to think when you are 3d programming and can produce lots of cool stuff. Writing shaders is cool too.
On February 29 2012 10:31 King K. Rool wrote: ah nice!
tbh 3-d graphics programming sort of killed my passion for writing any code for games. Hope you don't have the same problem.
How? 3d programming is awesome fun and extremely simple once you know it, there's a lot of reading required (FBO's, VBO's, atlas-ing and the like) but you don't really need to think when you are 3d programming and can produce lots of cool stuff. Writing shaders is cool too.
Saying something is extremely simple once you know it is a bit ridiculous :p. OTOH 3D/graphics programming is a lot of fun if you can learn the math needed and deal with the debugging tools available.
On February 29 2012 18:24 cowsrule wrote: Sounds like you're having a lot of fun! Hope you continue being as excited about this as you have been so far.
On February 29 2012 10:31 King K. Rool wrote: ah nice!
tbh 3-d graphics programming sort of killed my passion for writing any code for games. Hope you don't have the same problem.
How? 3d programming is awesome fun and extremely simple once you know it, there's a lot of reading required (FBO's, VBO's, atlas-ing and the like) but you don't really need to think when you are 3d programming and can produce lots of cool stuff. Writing shaders is cool too.
Saying something is extremely simple once you know it is a bit ridiculous :p. OTOH 3D/graphics programming is a lot of fun if you can learn the math needed and deal with the debugging tools available.
Yeah but it makes sense in programming. There are some things that take a long time to learn, but once you know it, its simple, so its really just a time investment. Other things take a long time to learn, and even when you have read everything, you still feel like you don't understand it.
I still have trouble with TDD/BDD and the best way to write something with functional programming and I've got a zillion books on it, there are also so many practical uses for genetic algorithms which you wouldn't think of (learning from customers). With 3D programming because its so straightforward, stateful and imperative, its really just getting into the zone, code cutting and reading up on how to do things. If lego was programming, it would be OpenGL.
On February 23 2012 07:29 nath wrote: as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
My anger at you recommending flash was cooled off by your description of C, though. But i think you exaggerate how much more helpful it is to start with C just so you understand the benefits and additions of C++ better; its not a huge deal; to me C and C++ are very very very similar and there is no disadvantage of simply learning C++ first, as the usefulness and proper applications of the additional functions of c++ over c can be intuitively learned rather than directly learned by having used pure c.
I would agree with you on learning pure c if you are going to use objective-c for iphone/ios development and don't already know c++. even so in that case, provided its not your first programming language, just learning objective-c and working out proper usage of the features through usage and intelligence/knowledge that grows while you learn, is probably the more efficient route. I firmly believe in separating the learning of concepts and languages, rather than thinking purely in terms of using a specific language to learn a specific set of programming concepts and then moving on to other languages..
I sort of agree. Flash is already outdated and death is waiting for it. HTML5/JS is basically removing it from the market. Steadily.
Python is excellent language and there are many examples of software written in C/C++ that can be extended with Python so it's worth to take a look.
As for C and C++. I disagree that there is no disadvantage in learning C++ first instead of C. For the following reasons: 1. C++ is fast. C is faster! At least that's how Visual Studio makes the end code - not sure about gcc/g++ 2. If you learn C++ you won't learn C specific approach to programming. Namely you will focus on creating/removing objects instead of allocating/freeing memory. That's actually significant difference in terms of performance. Also you won't be that used to using pointers. C background may very well let you implement algorithms more efficiently. 3. If you start with C++ you will probably never revert to pure C - in some way you will never know C. The other way around is not true - however - as surely (especially in programming games) you will want to start using OOP - so C++. 4. Finally - C is easier. There is less stuff to learn. If you want to learn some architecture specific stuff (like parallel programming) you should go with C. Once you are proficient with C you can expand with C++ - this way you can always fall back on C experience.
I've been coding in the games industry for about 6 years now, and it's almost exclusively C++. Yes, you lose out on the nuances that C gives you, but call it laziness or whatever, it's just not done that much any more (also if you end up coding cross platform, you will possibly be using the platform specific functions for creating/freeing objects masked away inside some C++ wrapper anyway). It's also good to know some C#, as if you end up wanting to do some tools, or just feel like making some handy day-to-day things, it is quick and powerful. The third language I would recommend is Python. It can be used similarly to C# to make some quick tools and it is arguably even more powerful than C#. This is mainly due to the plethora of add-ins you can get for Python that extend its use. PyQT is a great designer that turns Coding in Python to something similar to C#, but with all the benefits of using Python. Also check out Iron Python, as it gives you the ability to cross-develop with Python/C#/C++
The most important tool to have is passion, though. You've got to want to do it. Even outside of work I like to code. I have made some casting tools. One that allows you to draw on whatever's on the screen and a live-capture analysis tool for Starcraft. If you have the desire and the drive to do something, it's less important the road you take to get there.
A wealth of information on the Starcraft 2 forums of all places o.O Unexpected, but definitely awesome. I'm a Computer Engineering (specializing in software applications) major that's looking to eventually go into the games industry as a Software Engineer. I'm a freshman in college currently taking my first programming class (thankfully in C++) but I have been finding it a bit hard to get the motivation to go out and program some stuff. Reading all the replies to this blog and your last one is proving to be an inspiration and information overload. I've been messing with a game programming library called Allegro that works with C++ and I'm going to take a look at your tutorials and some others I've found to try to really begin making progress on my own game ideas. Thanks for the awesome post and blog!
On March 02 2012 21:58 KaiserJohan wrote: I'm a software developer toying with making a game engine and then a game. My question is, how do you actually do the 'artistic' stuff?
For example;
How do I make textures? How do I make models?
Is stuff like this possible for someone who sucks at drawing by hand? lol
Unless you generate your models procedurally through OGL or DirectX then you pretty much need an artist who can makes the models for you. But making textures is your skill in photoshop, not your ability to draw with your hand and making models is your ability to create objects in 3D-max or maya. I am not at all artistic but both or doable by the average person if you take your time to learn the artistic techniques for both of those softwares. I recommend having a friend do it for you.
Your only tasks should be to make the game and just use placeholder art to see that functionality works. (ex. just load in basic geometry for now to simulate visual feedback. Then convince a very kind artist that the work on the game is there and you just need the art to make it complete.
I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
On March 05 2012 01:32 PaqMan wrote: I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
If you are new to programming in general, stick to one language and learn it. The most important thing is to learn one language well enough to make it relatively easier learn others. Switching languages at the beginning won't help.
For the start - especially if you are going to learn on your own - you should start with one of the more popular languages so in general one of the: C, C++, Obj-C, C#, VB.NET, Python, PHP, Perl, Java
That said not all are equally games-friendly. Generally speaking the more popular language the more tools you will find, the more tutorials are out there, the greater is the community etc. Easier. Also - unless language is created for specific purpose (like PHP and Perl from this list) you will probably discover a wealth of resources which will aid you in coding games. Lua is scripting language so in essence you probably won't be able to code a game in it. You can - however - work on a game based on specific game engine in Lua.
For example Spring - http://springrts.com/ - is open source RTS engine. Written in C++ but it is more complicated
On March 05 2012 01:32 PaqMan wrote: I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
I'd recommend Python and PyGame, as I've used it before and loved it. I have never used Lua, but from what I know it's not commonly used on it's own to create games.
I've been on the big programming thread and met quite a few python fanboys here and there but I don't know what everyone's fascination with python is, most if not all people who love python have also not been very knowledgeable programmers in my experience. Most python fanboys don't even know how the GC works, which I believe at least understanding the cyclic referencing problem is important (although no longer a problem apparently). I mean its alright but I just see Python as pretty weak with nothing really special about it, it barely even classifies as a multi-paradigm language these days.
I would prefer to write in any other dynamic language over Python. Haskell, Ruby, Lisp, Smalltalk, Lua, Javascript, any. Okay maybe not PHP but you get the picture.
Though I see Coffeescript (using V8 Javascript engine) as the best language for making games in this day and age. V8 Javascript is very very VERY fast compared to other dynamic languages, and Coffeescript is like Ruby syntax with Python-style context sensitive whitespace and Javascript's beautiful functional paradigm at the core. Just seems like a language with a lot of potential.
On March 05 2012 01:32 PaqMan wrote: I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
I'd recommend Python and PyGame, as I've used it before and loved it. I have never used Lua, but from what I know it's not commonly used on it's own to create games.
Lua is a great language, I don't see anything wrong with it for hobby game making. Its is widely used for non-performance-intensive stuff, and not for core engines because 1. C++ libraries already exist for it and 2. its slow compared to C++. If you are not coding Mass Effect 3, then Lua is definitely a viable option.
On February 23 2012 07:29 nath wrote: as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
My anger at you recommending flash was cooled off by your description of C, though. But i think you exaggerate how much more helpful it is to start with C just so you understand the benefits and additions of C++ better; its not a huge deal; to me C and C++ are very very very similar and there is no disadvantage of simply learning C++ first, as the usefulness and proper applications of the additional functions of c++ over c can be intuitively learned rather than directly learned by having used pure c.
I would agree with you on learning pure c if you are going to use objective-c for iphone/ios development and don't already know c++. even so in that case, provided its not your first programming language, just learning objective-c and working out proper usage of the features through usage and intelligence/knowledge that grows while you learn, is probably the more efficient route. I firmly believe in separating the learning of concepts and languages, rather than thinking purely in terms of using a specific language to learn a specific set of programming concepts and then moving on to other languages..
I sort of agree. Flash is already outdated and death is waiting for it. HTML5/JS is basically removing it from the market. Steadily.
Python is excellent language and there are many examples of software written in C/C++ that can be extended with Python so it's worth to take a look.
As for C and C++. I disagree that there is no disadvantage in learning C++ first instead of C. For the following reasons: 1. C++ is fast. C is faster! At least that's how Visual Studio makes the end code - not sure about gcc/g++ 2. If you learn C++ you won't learn C specific approach to programming. Namely you will focus on creating/removing objects instead of allocating/freeing memory. That's actually significant difference in terms of performance. Also you won't be that used to using pointers. C background may very well let you implement algorithms more efficiently. 3. If you start with C++ you will probably never revert to pure C - in some way you will never know C. The other way around is not true - however - as surely (especially in programming games) you will want to start using OOP - so C++. 4. Finally - C is easier. There is less stuff to learn. If you want to learn some architecture specific stuff (like parallel programming) you should go with C. Once you are proficient with C you can expand with C++ - this way you can always fall back on C experience.
You don't use a lot of the OOP features of C++ for games unfortunately because of performance, every nanosecond counts, and that includes micro optimisations.
Really you are writing uglified C in C++, purely for speed reasons. I love C, but I really don't like C++ heh.
On March 05 2012 08:54 sluggaslamoo wrote: I've been on the big programming thread and met quite a few python fanboys here and there but I don't know what everyone's fascination with python is, most if not all people who love python have also not been very knowledgeable programmers in my experience. Most python fanboys don't even know how the GC works, which I believe at least understanding the cyclic referencing problem is important (although no longer a problem apparently). I mean its alright but I just see Python as pretty weak with nothing really special about it, it barely even classifies as a multi-paradigm language these days.
I would prefer to write in any other dynamic language over Python. Haskell, Ruby, Lisp, Smalltalk, Lua, Javascript, any. Okay maybe not PHP but you get the picture.
Though I see Coffeescript (using V8 Javascript engine) as the best language for making games in this day and age. V8 Javascript is very very VERY fast compared to other dynamic languages, and Coffeescript is like Ruby syntax with Python-style context sensitive whitespace and Javascript's beautiful functional paradigm at the core. Just seems like a language with a lot of potential.
On March 05 2012 01:32 PaqMan wrote: I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
I'd recommend Python and PyGame, as I've used it before and loved it. I have never used Lua, but from what I know it's not commonly used on it's own to create games.
Lua is a great language, I don't see anything wrong with it for hobby game making. Its is widely used for non-performance-intensive stuff, and not for core engines because 1. C++ libraries already exist for it and 2. its slow compared to C++. If you are not coding Mass Effect 3, then Lua is definitely a viable option.
On February 23 2012 07:29 nath wrote: as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
My anger at you recommending flash was cooled off by your description of C, though. But i think you exaggerate how much more helpful it is to start with C just so you understand the benefits and additions of C++ better; its not a huge deal; to me C and C++ are very very very similar and there is no disadvantage of simply learning C++ first, as the usefulness and proper applications of the additional functions of c++ over c can be intuitively learned rather than directly learned by having used pure c.
I would agree with you on learning pure c if you are going to use objective-c for iphone/ios development and don't already know c++. even so in that case, provided its not your first programming language, just learning objective-c and working out proper usage of the features through usage and intelligence/knowledge that grows while you learn, is probably the more efficient route. I firmly believe in separating the learning of concepts and languages, rather than thinking purely in terms of using a specific language to learn a specific set of programming concepts and then moving on to other languages..
I sort of agree. Flash is already outdated and death is waiting for it. HTML5/JS is basically removing it from the market. Steadily.
Python is excellent language and there are many examples of software written in C/C++ that can be extended with Python so it's worth to take a look.
As for C and C++. I disagree that there is no disadvantage in learning C++ first instead of C. For the following reasons: 1. C++ is fast. C is faster! At least that's how Visual Studio makes the end code - not sure about gcc/g++ 2. If you learn C++ you won't learn C specific approach to programming. Namely you will focus on creating/removing objects instead of allocating/freeing memory. That's actually significant difference in terms of performance. Also you won't be that used to using pointers. C background may very well let you implement algorithms more efficiently. 3. If you start with C++ you will probably never revert to pure C - in some way you will never know C. The other way around is not true - however - as surely (especially in programming games) you will want to start using OOP - so C++. 4. Finally - C is easier. There is less stuff to learn. If you want to learn some architecture specific stuff (like parallel programming) you should go with C. Once you are proficient with C you can expand with C++ - this way you can always fall back on C experience.
You don't use a lot of the OOP features of C++ for games unfortunately because of performance, every nanosecond counts, and that includes micro optimisations.
Really you are writing uglified C in C++, purely for speed reasons. I love C, but I really don't like C++ heh.
What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.
Most game engines are written in C++ with some of the more performance critical parts written in ASM or C as is required. E.g. Source, Unreal Engine, Unity, etc. There are very few engines still written entirely in C and more engines are farming off the less critical pieces to C# and other more RAD oriented languages (LUA and Python also very popular I hear - not sure on that one).
On March 05 2012 19:01 nimdil wrote: What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.
C unquestionably becomes a lot harder to read as compared to other languages as the complexity of the application increases and the efficiency increase is not necessarily always even there. The whole reason C++ was invented has to do with improving maintainability while representing a business problem with a higher degree of accuracy. In general, outside of specific circumstances that should be obvious, C and C++ are basically around the same performance level. On a Desktop PC you're not exactly dealing with a situation where a template class or something is appreciably killing your machine.
I mean, compare the Quake 2/3 (written in C) source to the ID Tech 4 (written in C++) source code.
On March 05 2012 08:54 sluggaslamoo wrote: I've been on the big programming thread and met quite a few python fanboys here and there but I don't know what everyone's fascination with python is, most if not all people who love python have also not been very knowledgeable programmers in my experience. Most python fanboys don't even know how the GC works, which I believe at least understanding the cyclic referencing problem is important (although no longer a problem apparently). I mean its alright but I just see Python as pretty weak with nothing really special about it, it barely even classifies as a multi-paradigm language these days.
I would prefer to write in any other dynamic language over Python. Haskell, Ruby, Lisp, Smalltalk, Lua, Javascript, any. Okay maybe not PHP but you get the picture.
Though I see Coffeescript (using V8 Javascript engine) as the best language for making games in this day and age. V8 Javascript is very very VERY fast compared to other dynamic languages, and Coffeescript is like Ruby syntax with Python-style context sensitive whitespace and Javascript's beautiful functional paradigm at the core. Just seems like a language with a lot of potential.
On March 05 2012 01:32 PaqMan wrote: I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.
I'd recommend Python and PyGame, as I've used it before and loved it. I have never used Lua, but from what I know it's not commonly used on it's own to create games.
Lua is a great language, I don't see anything wrong with it for hobby game making. Its is widely used for non-performance-intensive stuff, and not for core engines because 1. C++ libraries already exist for it and 2. its slow compared to C++. If you are not coding Mass Effect 3, then Lua is definitely a viable option.
On March 01 2012 23:47 nimdil wrote:
On February 23 2012 07:29 nath wrote: as someone who's been programming most of his life, and is very in-tune with the industry (game industry, enterprise software, and startups) I have to disagree with using Flash.
My anger at you recommending flash was cooled off by your description of C, though. But i think you exaggerate how much more helpful it is to start with C just so you understand the benefits and additions of C++ better; its not a huge deal; to me C and C++ are very very very similar and there is no disadvantage of simply learning C++ first, as the usefulness and proper applications of the additional functions of c++ over c can be intuitively learned rather than directly learned by having used pure c.
I would agree with you on learning pure c if you are going to use objective-c for iphone/ios development and don't already know c++. even so in that case, provided its not your first programming language, just learning objective-c and working out proper usage of the features through usage and intelligence/knowledge that grows while you learn, is probably the more efficient route. I firmly believe in separating the learning of concepts and languages, rather than thinking purely in terms of using a specific language to learn a specific set of programming concepts and then moving on to other languages..
I sort of agree. Flash is already outdated and death is waiting for it. HTML5/JS is basically removing it from the market. Steadily.
Python is excellent language and there are many examples of software written in C/C++ that can be extended with Python so it's worth to take a look.
As for C and C++. I disagree that there is no disadvantage in learning C++ first instead of C. For the following reasons: 1. C++ is fast. C is faster! At least that's how Visual Studio makes the end code - not sure about gcc/g++ 2. If you learn C++ you won't learn C specific approach to programming. Namely you will focus on creating/removing objects instead of allocating/freeing memory. That's actually significant difference in terms of performance. Also you won't be that used to using pointers. C background may very well let you implement algorithms more efficiently. 3. If you start with C++ you will probably never revert to pure C - in some way you will never know C. The other way around is not true - however - as surely (especially in programming games) you will want to start using OOP - so C++. 4. Finally - C is easier. There is less stuff to learn. If you want to learn some architecture specific stuff (like parallel programming) you should go with C. Once you are proficient with C you can expand with C++ - this way you can always fall back on C experience.
You don't use a lot of the OOP features of C++ for games unfortunately because of performance, every nanosecond counts, and that includes micro optimisations.
Really you are writing uglified C in C++, purely for speed reasons. I love C, but I really don't like C++ heh.
What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.
If OOP was necessary in game development then people would have done it with C as well using ADTs (abstract data types).
Typecasting for Polymorphism and passing a pointer and lookup every time you wanna call a method on an object, you are not going to use Iterators and ArrayLists (or any design patterns) for instance because they are slow to build and you would be creating one 60 times a second when you could just save all that time and memory by iterating through an array. Objects also just take up a lot more memory than primitive types. So you are mostly going to stick with primitive data-types and data-structures, writing code in terms of functions and data, aka structured programming.
I'm not a huge performance nerd so I don't know the exact details. This is also only for core components though like AI, animation and graphics, it is more common to have less CPU intensive stuff to be written in OO or even in scripting languages like Lua. You can look at the api (blizzard calls it a language -_-) Galaxy, where you have the ability to script triggers using code in the SC2 Map Editor, there's no OO in there at all, the api calls have a very C-like naming convention.
There may be some games that will be a bit more OO than others, but the bigger and older the game is the less OO it is because optimisations are more important than maintainability. Remember games usually run on a single release cycle, so maintainability is much less of an issue compared to having a wider customer base because the CPU specs can be lower. Balance patches never involve code, the only time it does is for a bug fix.
C++ is just used because it is the de facto standard for making games, why? I have no idea, probably because C++ came out at just the right time, when game companies were agile enough to shift to new languages and most code was done in-house. But now we are stuck in a vicious cycle, because all the good game libraries are now in C++, people keep developing more game libraries in C++, and almost nobody makes their own large scale game engines anymore. Now the fastest compilers are for C++ too so nobody is going to go back to a pure C compiler, because you can just write C using the C++ compiler.
On March 06 2012 08:44 ShadowWolf wrote: Most game engines are written in C++ with some of the more performance critical parts written in ASM or C as is required. E.g. Source, Unreal Engine, Unity, etc. There are very few engines still written entirely in C and more engines are farming off the less critical pieces to C# and other more RAD oriented languages (LUA and Python also very popular I hear - not sure on that one).
On March 05 2012 19:01 nimdil wrote: What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.
C unquestionably becomes a lot harder to read as compared to other languages as the complexity of the application increases and the efficiency increase is not necessarily always even there. The whole reason C++ was invented has to do with improving maintainability while representing a business problem with a higher degree of accuracy. In general, outside of specific circumstances that should be obvious, C and C++ are basically around the same performance level. On a Desktop PC you're not exactly dealing with a situation where a template class or something is appreciably killing your machine.
I mean, compare the Quake 2/3 (written in C) source to the ID Tech 4 (written in C++) source code.
I haven't looked at the code, but I would presume that the code is much better mostly because ID just had better developers. It is much harder to work on old C++ than C code in my experience because of how badly designed the language is, its just so inconsistent and if you get one bad programmer you are pretty much screwed.
C++ is a powerful tool and like all powerful tools it has the potential to let yourself walk in to huge pitfalls - incidentally C and C++ share common ground here. I personally believe that C++ makes it a lot harder to shoot yourself in the foot as long as you're familiar with how a language that isn't pure works - i.e. careful use of overloads, RAII for life, sensible design patterns, thought about the direction of your systems. Admittedly, a the worst examples of C++ are far more obtuse than the worst examples of C, but that's because there's nearly no limit to how many coding patterns you can combine together at any point in C++. I mean, you can (to some extent) see this if you follow a lot of C# code - between LINQ and some of the new stuff plus the DLR you can do some pretty nonsensical stuff. But I mean, I don't think there's anywhere near sufficient evidence to say that the language is designed poorly. There are features of the language that are designed poorly, e.g. Exceptions; however, I don't feel that's sufficient that you can paint a broad brush.
C++ became the de-facto standard in many places because it's easier to make sense of than C code. I'm not sure your source of experience, so I'm not going to comment about your specific situation; however, in general it stands that C++ code is more maintainable and more accurately represents in a clear-cut manner the problem being solved as compared to straight-C. That said, there are several modern, maintained compilers that support C99 and some even already adding support for C11.
C was used in games for quite a long while after C++ was standardized. The reason I suggested you to compare is because the Quake2/3 source code is messy and repetitive whereas the ID Tech 4 source code uses OO concepts to eliminate and specialize classes - you should see some of their internal helper's migration to use of templates and what-not. The point was it's a decent example of how migration helped clean up their code. It's not like it's a pinnacle of quality - there are classes with over 100 members in there, but it definitely does the job at a level that most games cannot.
Also, if you look at basically any commercial game's source you'll see design patterns all over the place. Dynamic Arrays (you used ArrayList, I think you meant this?) are commonplace anymore with specialized allocators for the objects that require them. A lot of times you'll see re-implmenetations of STL library stuff because the STL can be a little too heavy-weight for many types of games (or you need more granular control).
The major reason that all the APIs might look C-like in Galaxy is because C-style functional syntax is arguably easier to create. I know if I were creating a scripting engine then emulation of either C or Javascript is where I would start just cuz it's simple, bare-bones, and the few commercial lexers I've seen come with support out of the box. But I'm not familiar with Blizzard's development on Galaxy so I'm guessing here.
The point I'm trying to make is that C++ isn't a panacea but it's not a pox either. C and C++ both suffer from many of the same pitfalls, but I (and many others) feel that the increased type-safety, objects, and generic programming concepts improve the design of your code and help express your concepts in a more robust, maintainable, and functional way. And, really, that's what it's all about because even in a single-release game cycle you better believe at least some components of your code are going to be re-used - especially as models like F2P and whatever you call "social media" style games like the ones you see on Facebook become more profitable. Or even just consider franchises like Call of Duty and whatever - those games aren't made from scratch every time. Going back to my own example: There's holdovers from ID Tech 3 in ID Tech 4.
That said, some really interesting insight on the topic can be gleaned here: http://www.team5150.com/~andrew/carmack/ Though I don't think he ever did write his .plan on migrating from C to C++.
On March 06 2012 13:21 ShadowWolf wrote: C++ is a powerful tool and like all powerful tools it has the potential to let yourself walk in to huge pitfalls - incidentally C and C++ share common ground here. I personally believe that C++ makes it a lot harder to shoot yourself in the foot as long as you're familiar with how a language that isn't pure works - i.e. careful use of overloads, RAII for life, sensible design patterns, thought about the direction of your systems. Admittedly, a the worst examples of C++ are far more obtuse than the worst examples of C, but that's because there's nearly no limit to how many coding patterns you can combine together at any point in C++. I mean, you can (to some extent) see this if you follow a lot of C# code - between LINQ and some of the new stuff plus the DLR you can do some pretty nonsensical stuff. But I mean, I don't think there's anywhere near sufficient evidence to say that the language is designed poorly. There are features of the language that are designed poorly, e.g. Exceptions; however, I don't feel that's sufficient that you can paint a broad brush.
C++ became the de-facto standard in many places because it's easier to make sense of than C code. I'm not sure your source of experience, so I'm not going to comment about your specific situation; however, in general it stands that C++ code is more maintainable and more accurately represents in a clear-cut manner the problem being solved as compared to straight-C. That said, there are several modern, maintained compilers that support C99 and some even already adding support for C11.
C was used in games for quite a long while after C++ was standardized. The reason I suggested you to compare is because the Quake2/3 source code is messy and repetitive whereas the ID Tech 4 source code uses OO concepts to eliminate and specialize classes - you should see some of their internal helper's migration to use of templates and what-not. The point was it's a decent example of how migration helped clean up their code. It's not like it's a pinnacle of quality - there are classes with over 100 members in there, but it definitely does the job at a level that most games cannot.
Also, if you look at basically any commercial game's source you'll see design patterns all over the place. Dynamic Arrays (you used ArrayList, I think you meant this?) are commonplace anymore with specialized allocators for the objects that require them. A lot of times you'll see re-implmenetations of STL library stuff because the STL can be a little too heavy-weight for many types of games (or you need more granular control).
The major reason that all the APIs might look C-like in Galaxy is because C-style functional syntax is arguably easier to create. I know if I were creating a scripting engine then emulation of either C or Javascript is where I would start just cuz it's simple, bare-bones, and the few commercial lexers I've seen come with support out of the box. But I'm not familiar with Blizzard's development on Galaxy so I'm guessing here.
The point I'm trying to make is that C++ isn't a panacea but it's not a pox either. C and C++ both suffer from many of the same pitfalls, but I (and many others) feel that the increased type-safety, objects, and generic programming concepts improve the design of your code and help express your concepts in a more robust, maintainable, and functional way. And, really, that's what it's all about because even in a single-release game cycle you better believe at least some components of your code are going to be re-used - especially as models like F2P and whatever you call "social media" style games like the ones you see on Facebook become more profitable. Or even just consider franchises like Call of Duty and whatever - those games aren't made from scratch every time. Going back to my own example: There's holdovers from ID Tech 3 in ID Tech 4.
That said, some really interesting insight on the topic can be gleaned here: http://www.team5150.com/~andrew/carmack/ Though I don't think he ever did write his .plan on migrating from C to C++.
In terms of background, I'm not a game developer but I have acquaintances who work at a very high level in games development, EA games, Eidos, etc. Ironically speaking to these people and hearing stories completely halted my passion for wanting to become a games developer, and now I'm reserved to spending a lot more time in computer sciency stuff and hobby games development. I get paid a lot more and get to work in an easy going environment.
I will reserve my judgement on the source code until I see it, but I really can't believe someone would use a List and pass through them using an iterator in a high-spec game heh , however if it was going to run on low specs anyway then I can see people going for more maintainability. I'm really talking about games in the top tier.
Although
A lot of times you'll see re-implmenetations of STL library stuff because the STL can be a little too heavy-weight for many types of games (or you need more granular control).
I can definitely believe this at least for "lower tier" games.
The major reason that all the APIs might look C-like in Galaxy is because C-style functional syntax is arguably easier to create. I know if I were creating a scripting engine then emulation of either C or Javascript is where I would start just cuz it's simple, bare-bones, and the few commercial lexers I've seen come with support out of the box. But I'm not familiar with Blizzard's development on Galaxy so I'm guessing here.
I thought you might say that.
Not all APIs are C-like like Galaxy. A lot of them are often sorted into classes as globally accessible class methods using very basic OO, like SFML (obviously not a real game engine but just to give you an example). To me Galaxy almost appears to be a direct port of the basic AI triggers, but then again its only an assumption and that's as far as it goes.
Javascript also runs on a functional paradigm so that is certainly not how I would do it in JS, its just that there is a lot of bad Javascripters out there .
Admittedly, a the worst examples of C++ are far more obtuse than the worst examples of C, but that's because there's nearly no limit to how many coding patterns you can combine together at any point in C++. I mean, you can (to some extent) see this if you follow a lot of C# code - between LINQ and some of the new stuff plus the DLR you can do some pretty nonsensical stuff. But I mean, I don't think there's anywhere near sufficient evidence to say that the language is designed poorly. There are features of the language that are designed poorly, e.g. Exceptions; however, I don't feel that's sufficient that you can paint a broad brush.
If you have become proficient in tonnes of different languages and paradigms and even like to create your own grammars from time to time its just so easy to say C++ really sucks and not think twice about it, even worse is that a lot of people of my type agree with me which means I never end up coming up with any great reasons for why haha.
There are definitely poorly designed languages and well designed ones. There's no arguing about this. There are certain conventions in creating languages which should be thought of. Things such as POLS (principle of least surprise), facilitating the developer in his use of the language paradigm, the ability to be DRY (don't repeat yourself), conciseness, readability, etc. This is just off the top of my head. C++ fails in many of these aspects, find new things about C++ 5 years down the track, some things require braces, some things don't, an interface method requires an abstract class method that is assigned a value of 0, etc. PHP is also a "bad" language in my books, such as arrays actually being hashes causing all kinds of weird shit, the loosest typing known to man, etc.
My favorite language is Ruby, and the reason is that it follows many of these principles and implements them extremely well. It is fully object-oriented (even nil [NULL] is an object), I can just take glances at blocks of codes and immediately understand what it does, it solves cyclic inheritance with mixins, it has open classes which allows for really elegant library implementations, duck-typing, there are hardly any keywords instead they are methods on Object (foreach X in Y becomes Y.each |X| {yield x to the iterator block}), you can pass blocks of codes as an argument and yield objects to them, dynamic typing but alleviates the type-safety issues with strict typing instead of the more common loose typing. It has a great amount of flexibility, but unlike C++, its still hard to write bad ruby code. Its a very great implementation of a language of the OO paradigm, of course you can also do a lot of functional stuff too, but not Haskell tier functional.
Carmack will always be a hero in my books, but he wasn't known for being the most academic programmer. I really enjoyed his rants about the earliest DX's vs OpenGL.
I don't know why you can't believe a list wouldn't be the proper choice. I'm not sure what you're imagining, but a vector that's sized out is quite efficient and access to items on the vector are quite reasonably fast. I think you're imagining a lot of complexity to exist that doesn't actually exist. The list is a perfect choice and optimizing it to be effectively just as fast is trivial in the gaming domain. The impression I get from your writing is the last complete exposure you had to C++ was circa Visual C++ 6.0, which, if true, totally justifies your views. If that's the case then they are dated and should be updated. If that's not the case then you seem to have a lot of misguided impressions about how inefficient C++ really can be, which totally makes sense because most people don't re-check their assumptions - especially if you're talking to game developers. I know and have discussed with a few of them myself and a lot of times they do the things they do because they know they work, they have worked in the past, and they (basically) always will work. It's a completely sensible viewpoint, but in terms of discussing with people just learning you'd probably want them to learn the new skill set in additional to familiarizing themselves with the old one so they have a more marketable set of skills.
I think you misunderstood my point about Galaxy. Functions that look and feel like C functions are just plain easier to write. Arguments are more simple, there's no real complex data structures that need to be passing, and you're probably going to be able to augment the language more easily. I didn't mean to suggest that they used C or even C-interfaces. Just that using things that look similar to C is extremely common in my experience. SMFL is a library and doesn't seem to be relevant to proprietary external scripting interfaces and why they might look very C/JS-ish. That said, a couple of google searches confirmed Galaxy is 100% based on C style syntax.
Eh, I mean, Ruby is a cool language. It also has limitations. It's probably a superior entry-level language to C++. It's also unquestionably slower, less flexible, and possibly has fewer core-language enhancements in its future. From what I've learned of Ruby, it's probably one of the better languages (up there with Python) in terms of getting stuff done well in not a lot of time with decent quality. That said, I'm not sure what you mean by your complaints about C++.
I mean, I have a million gripes about the language of C++, but some of that stuff you listed off is naught more than personal preference and doesn't make a strong argument for why C++ is awful, just why C++ is worse than Ruby in some specific areas. And that's fine - I mean, the fundamental concept of application development and improving hardware is that we can abstract ourselves from low-level concepts like what C++ requires that you focus on.
But that's neither here nor there. The exception I had to what you posted was that C++ produces generally inefficient code when put side-by-side with C and is harder to maintain than C. I'm interested in demonstrating that neither of those, again emphasizing the "in general" part even in a game - you'll probably have some straight-C code around very select portions of your engine for a while longer, is true. There's a sort of weird C > C++ perspective that I don't quite understand and it seems to be based on things that haven't really been true for a while.
Also side-note: if you're developing on MSVC then that's the equivalent of saying "I know car engines really well because I work on a '94 civic." Yeah, it's definitely still a Car (C89/90) and you'll probably pick up the necessary bits to figure out an '09 Civic (C11), but it's so old and dated that you're missing a lot of cool stuff.
On March 06 2012 15:32 ShadowWolf wrote: I don't know why you can't believe a list wouldn't be the proper choice. I'm not sure what you're imagining, but a vector that's sized out is quite efficient and access to items on the vector are quite reasonably fast. I think you're imagining a lot of complexity to exist that doesn't actually exist. The list is a perfect choice and optimizing it to be effectively just as fast is trivial in the gaming domain. The impression I get from your writing is the last complete exposure you had to C++ was circa Visual C++ 6.0, which, if true, totally justifies your views. If that's the case then they are dated and should be updated. If that's not the case then you seem to have a lot of misguided impressions about how inefficient C++ really can be, which totally makes sense because most people don't re-check their assumptions - especially if you're talking to game developers. I know and have discussed with a few of them myself and a lot of times they do the things they do because they know they work, they have worked in the past, and they (basically) always will work. It's a completely sensible viewpoint, but in terms of discussing with people just learning you'd probably want them to learn the new skill set in additional to familiarizing themselves with the old one so they have a more marketable set of skills.
I think you misunderstood my point about Galaxy. Functions that look and feel like C functions are just plain easier to write. Arguments are more simple, there's no real complex data structures that need to be passing, and you're probably going to be able to augment the language more easily. I didn't mean to suggest that they used C or even C-interfaces. Just that using things that look similar to C is extremely common in my experience. SMFL is a library and doesn't seem to be relevant to proprietary external scripting interfaces and why they might look very C/JS-ish. That said, a couple of google searches confirmed Galaxy is 100% based on C style syntax.
Eh, I mean, Ruby is a cool language. It also has limitations. It's probably a superior entry-level language to C++. It's also unquestionably slower, less flexible, and possibly has fewer core-language enhancements in its future. From what I've learned of Ruby, it's probably one of the better languages (up there with Python) in terms of getting stuff done well in not a lot of time with decent quality. That said, I'm not sure what you mean by your complaints about C++.
I mean, I have a million gripes about the language of C++, but some of that stuff you listed off is naught more than personal preference and doesn't make a strong argument for why C++ is awful, just why C++ is worse than Ruby in some specific areas. And that's fine - I mean, the fundamental concept of application development and improving hardware is that we can abstract ourselves from low-level concepts like what C++ requires that you focus on.
But that's neither here nor there. The exception I had to what you posted was that C++ produces generally inefficient code when put side-by-side with C and is harder to maintain than C. I'm interested in demonstrating that neither of those, again emphasizing the "in general" part even in a game - you'll probably have some straight-C code around very select portions of your engine for a while longer, is true. There's a sort of weird C > C++ perspective that I don't quite understand and it seems to be based on things that haven't really been true for a while.
Also side-note: if you're developing on MSVC then that's the equivalent of saying "I know car engines really well because I work on a '94 civic." Yeah, it's definitely still a Car (C89/90) and you'll probably pick up the necessary bits to figure out an '09 Civic (C11), but it's so old and dated that you're missing a lot of cool stuff.
Hey, not trying to be an ass or anything, and I've probably mis-interpreted a couple of your points too, but yeah I'm gonna avoid addressing a few paragraphs because I believe you mis-interpretted what I was saying, but lets leave it at that.
I dunno why you lump C and JS together, C is based on the structured programming paradigm, JS is based on an imperative functional programming paradigm o_O. The only reason JS would look anything like C is if the programmer isn't well versed in functional programming. For example if you are doing Server side stuff, you might write using Concurrency Driven design, such as what you'd see in NodeJS. You would have a lot of trouble doing something like this in C.
I don't do a lot of C++ because I don't like it very much, so feel free to enlighten me on any cool features that I might be missing out on. Very recently I was re-learning C++ using the plain old g++ because I selected some comp-sci electives (I chose to do business and IT in University instead of comp-sci). That said I didn't attend any lectures or tutes and just did the required lab tests and exams, I just flicked through the slides and if I saw anything I didn't know I did some learning on it in the library and watching recordings of the lecturer slide show presentations. Your right on point that before I did that, I was using MSVC++ 6.0. I probably wouldn't dare touch that with a 10-foot pole now, although I do everything in Linux so I'd be using GNU now if anything.
The reasons listed weren't that great as I said, If I actually had a think about it I'd probably come up with better reasons. The main thing is unlike the differences between Ruby and C++, I don't believe C++ has that many advantages over C when it comes to pure programming. I don't feel like there are many things I could do better in C++ than in C. You can still do OOP in C using ADTs and you will have much more organised C code than bad OOP in C++. Even bad OO in Ruby still looks good and won't cause many issues.
Like I implied in my first post though, developing C++ on your own isn't that bad, its having to rely on other developers to be immaculate. Issues like cyclic inheritance (or the diamond problem) are a very real possibility. The other problem being that it has good intentions, but multiple substitution is very poorly designed in C++ and can cause a lot of problems.
Java saw this as a really big problem but solved it in the stupidest way possible with multiple interface inheritance, because it completely eliminates one of the core advantages of OOP which is code re-use. And then people come out with idiotic books on Java about how to "write code in interfaces instead of implementations". Interfaces are useful, but they are a terrible substitute for implementation inheritance. Most other languages do this much better, e.g Scala with traits, or Ruby with mixins.
However there is also a "skill ceiling" that you hit with older languages, where you get frustrated because certain implementations would be soooo much better in another language, I don't get this feeling between C++ and C, one big difference between older imperative languages and new dynamic languages is the usage pf higher order functions. I still think there are certain principles which make for good and bad languages.
Consider quicksort in C, C++ and Haskell. (Mind you I tried to find the shortest variations of each one)
C
void swap(int *a, int *b) { int t=*a; *a=*b; *b=t; } void sort(int arr[], int beg, int end) { if (end > beg + 1) { int piv = arr[beg], l = beg + 1, r = end; while (l < r) { if (arr[l] <= piv) l++; else swap(&arr[l], &arr[--r]); } swap(&arr[--l], &arr[beg]); sort(arr, beg, l); sort(arr, r, end); } }
C++
<<partition>>= template<typename IT> IT partition(IT begin, IT end, IT pivot) { typename std::iterator_traits<IT>::value_type piv(*pivot); std::swap(*pivot, *(end-1)); IT store=begin; for(IT it=begin; it!=end-1; ++it) { if(*it<=piv) { std::swap(*store, *it); ++store; } } std::swap(*(end-1), *store); return store; }
Haskell
qsortOneLine s = case s of{[]->[];(x:xs)->qsortOneLine [y | y<-xs, y<x] ++ x : qsortOneLine [y | y<-xs, y>=x]}
Now imagine if every time you wrote something in functional declarative instead of imperative, how small your code base would be in comparison and how easy it would be to maintain because a lot of your processes will be stateless. Notice how C++ isn't actually that much better than C, but Haskell can be extremely concise. In Ruby I'm doing stuff like this all the time, although in a lot less cryptic manner.
With your points on Ruby, its definitely slower (although Mac Ruby will be a lot faster), but this is a non-issue as I'm not making a high-spec game. Which is why I mentioned Coffeescript (Javascript) with Google's V8 engine as a great contender for games programming. Its not as fast as C++ but it is pretty damn fast from what I've seen and is a great language.
I dunno what you mean by flexibility, limitations, and fewer core language enhancements. Ruby 1.9 is significantly improved over 1.8 in terms of performance, syntactic sugar for a lot more things, and just a lot more features over all. As for limitations do you mean low level stuff? Although unnecessary for the most part, I can write inline Java or C in Ruby. When I'm coding games I will import a lot of Java libraries (e.g JOGL) and do my implementation in JRuby. I can have a fast 3d game in OpenGL that is completely cross-platform and runs on a JVM written in almost pure Ruby. Can''t get more flexible than that.
As for performance, I'm not saying that C++ is slower than C. But conceptually abstractions have to be slower than primitive types. A lot of these are micro-optimisations that I wouldn't deem important at all and only slightly important if you are writing a top-level game. I guess the game programmers believe that if its simple enough to make that optimisation, that they are going to do it anyway. I'm sure for most they would rather maintain their sanity and at least keep their code maintainable.
Cecil do you recommend anything for python besides pyGame? I love python but pygame looks pretty ghetto (installing it for a 64-bit Mac OS is not elegant).
On March 07 2012 19:06 opsayo wrote: Cecil do you recommend anything for python besides pyGame? I love python but pygame looks pretty ghetto (installing it for a 64-bit Mac OS is not elegant).
Haha I don't know what you mean "looks ghetto". You just include it into your project, and then coding it from there looks like usual 'ol Python. And sorry nope, I don't have experience with other things to recommend.
On March 07 2012 19:06 opsayo wrote: Cecil do you recommend anything for python besides pyGame? I love python but pygame looks pretty ghetto (installing it for a 64-bit Mac OS is not elegant).
Most unix platforms come default with Python so I don't really understand this post. You can always write your own game-engine though, you'll learn a lot from it
Yeah, I'm sorry if I came across brash, I certainly don't intend it It's an interesting conversation for me, too, as I'm going through and re-checking some of my assumptions on the topic and what-not.
I work in kind of a C++/C#/Java primarily shop with quite a fair amount of legacy C/ASM code. I've been working here for going on 7 years now and have worked on several code bases whose inception occurred in the early 1990s - in fact, we have header files whose copyright information is dated 1990 :-D. I feel like I've seen a gambit in terms of high quality and low quality C and C++ code since I've had to maintain and enhance quite a few projects. Incidentally, bad code is bad code and I feel like I've been too busy trying to "defend" (if you will) C++ against C and not really focusing on the fact that bad code is more or less unsalvagable regardless. To the point: we actually had a C# class so complex, so poorly written, and so buggy that I had to work an entire weekend just to rewrite the whole thing. And C# generally keeps you from screwin' stuff up! :-\ At work, we have some legacy VB6 code that someone spent 2 weeks attempting to migrate before entirely giving up and the project being canned.
But, anyway, to address your points:
I don't believe your analysis of the C and C++ code was entirely fair or accurate. The primary reason why I feel that is that the C++ is reusable while the C code is not. Anything that supports iterators or std::begin/end can be passed as parameters to that sorting algorithm and it will be successfully sorted. This is extremely powerful and so much better than the C algorithm! I mean, I think you would agree with me based on your perspective and enjoyment of Ruby. Granted, the Ruby code is more compact, tells the story, and is just as useful, but I have conceded that point already.
But in the end, no - if you do C with ADTs you'll have far, far more code than a decent implementation of C++ and you'll have the added disadvantage of now using C with ADTs combined with the fact that you're now limited in how you can pass things around - C with ADTs tends to fall down unless you basically pass everything by void*, which means you cannot enforce a lot of the nice behaviors and you certainly will not get any modern C++ design patterns such as RAII. As an example, look at this sample code implementing a container in C using an ADT: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=4550&lngWId=3
I did a fairly poor reinterpretation of that for C++ here. You'll have to excuse passing everything by-val instead of by const-reference; I had some time to do this at work waiting for something and kinda got in a rush at the end. http://pastebin.com/VNHhg8Ht
Keep in mind I did it with slightly fewer lines of code (I checked removing the C code's comments fwiw), it's actually typesafe (the C version is 100% not typesafe!), and it works with various types. E.g. the following code compiles against it fine:
You've used some terminology that's not clear to me. What do you mean by "pure programming"? And also, what do you mean by "multiple substitution"? These are terms that are foreign to me, so I'm afraid to comment further on those. I don't want to talk past you, but I'm not finding anything you've mentioned to back up that it's somehow worse to work with C++ on a sizable team and my experience has been that it's absolutely not.
Coffeescript is an interesting language - I was reading about it a few days ago and it's something I've thought was a nice new way of approaching some problems. Otherwise, I take back my statements about Ruby. I know I wanted to touch on a point there but I can't, for the life of me, remember what it was or how it was relevant so I think I was just posting nonsense. Ruby definitely has come a long way, though looking at the Ruby2C stuff I'm not entirely sure it's gonna get you the performance you're desiring without a lot of extra leg-work, but it's a step and something interesting that definitely adds some as-needed flexibility. I'm not sure it gets anywhere near the level of low-level functionality I'd want in a situation like that, but I think it's probably good enough.
The final point: Abstractions only have penalties for the times you pay for them. For example, virtual method invocations only affect those objects that actually have a v-table and not every object is required to have one. That's where C++ is really nice: you only pay the price for features you actually use. So while a std::vector has an abstraction layer around it, the standards writers usually make the elements involved as pass-through as possible so the penalties you pay are quite minimal. So yes, absolutely abstractions have costs, but, generally speaking, these abstractions are often highly optimized for the library writers (and even some subtypes; e.g. several containers are optimized to the point of being basically straight Win32 CRT calls in the VC2010 STL implementation).
In the case of that study, I don't see how a stack-allocated array of integers is in any way comparable to a repeated heap-allocated array of integers. I'd be interested to see which compiler he uses and whether new'ing the array of integers has any affect. That said, there again is why C++ can be better than C at times: if you need the performance of a C-style array then you have it and it's actually 100% compatible with the STL using std::begin and std::end (and there are absolutely times when a C-array is the better choice for solving a problem)! Also, the guy is wrong in one of his premises: std::vector is guaranteed to be contiguous memory. It was, as the result of an oversight, missed in C++98, though, so that's probably why he had the misconception that it was not guaranteed. (http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/)
Perhaps you could provide a sample of the really unmaintainable C++ code you're thinking of when you write that and it might help me understand your point of view better than discussing in abstracts?
I'd pretty much agree with you. For those starting out, it doesn't matter what language you pick, be it C, C++, C#, Java, Python or whatever. You can write, object-oriented C, or non-object-oriented C++. It's up to the programmer how he executes his algorithms. Much like how exact build orders don't matter all that much to bronze leaguers, if the code is bad enough, the nuances of language architecture don't matter.
However, that being said, it's pretty obvious you're not a beginner, but are nevertheless looking for something more to chew on. Game programming, as opposed to application programming, largely focuses on how much performance you can eke out, oftentimes at the cost of convenience for the programmer or elegance of the code. The way modern computer architecture has been progressing, the main bottlenecks we generally face are not the speed in executing algorithms (cpus are quite fast), but memory accesses and management.
If you are writing for the PC, it doesn't really matter because gamers have humungous amounts of memory and caches the size of whales. It only becomes more of a concern when dealing with consoles, or mobile devices where the hardware is much more limited.
The reason why game developers are not the biggest fan of STL is because it does a huge amount of alloc/deallocs on the heap during runtime. I've seen a single std::string initialization make 20 small allocations at once! This causes memory to fragment and results in less memory being available. Imagine memory pockmarked with 16kB holes while trying to allocate 4MB. All that memory in the holes aren't available because they aren't big enough to accomodate the new allocation. We much prefer pre-allocated fixed-size memory pools/containers when possible.
Lately, there's also been a movement against inheritance in general. The strength of C++ has always been that it naturally causes data that gets used together (i.e. in an object) be located close together in memory. However, when working repetitive operations on a set of many objects (e.g. updating the x, y, z position of all game objects), it thrashes the cache with all the superfluous data. Instead of one memory fetch retrieving 16 sets of useful coordinates, it now only retrieves one, simply because of the way memory is arranged.
The name of this new movement is dubbed data-oriented programming (as opposed to object-oriented though they are not mutually exclusive), and is by and large championed by a fellow called Mike Acton. Google him to find out more, but just be warned he can be a wee bit overzealous. It just so happens that straight C lends itself more to this style of programming, though there's no compelling reason why it can't be accomplished in C++ as well. It is a non-intuitive approach though, which can be unsettling for a generation of programmers brought up on pure OOP, myself included.
I hope that gave you some food for thought. Programming is like a never-ending learning adventure!
On March 08 2012 19:17 e-Goh wrote: Hi ShadowWolf,
I'd pretty much agree with you. For those starting out, it doesn't matter what language you pick, be it C, C++, C#, Java, Python or whatever. You can write, object-oriented C, or non-object-oriented C++. It's up to the programmer how he executes his algorithms. Much like how exact build orders don't matter all that much to bronze leaguers, if the code is bad enough, the nuances of language architecture don't matter.
However, that being said, it's pretty obvious you're not a beginner, but are nevertheless looking for something more to chew on. Game programming, as opposed to application programming, largely focuses on how much performance you can eke out, oftentimes at the cost of convenience for the programmer or elegance of the code. The way modern computer architecture has been progressing, the main bottlenecks we generally face are not the speed in executing algorithms (cpus are quite fast), but memory accesses and management.
If you are writing for the PC, it doesn't really matter because gamers have humungous amounts of memory and caches the size of whales. It only becomes more of a concern when dealing with consoles, or mobile devices where the hardware is much more limited.
The reason why game developers are not the biggest fan of STL is because it does a huge amount of alloc/deallocs on the heap during runtime. I've seen a single std::string initialization make 20 small allocations at once! This causes memory to fragment and results in less memory being available. Imagine memory pockmarked with 16kB holes while trying to allocate 4MB. All that memory in the holes aren't available because they aren't big enough to accomodate the new allocation. We much prefer pre-allocated fixed-size memory pools/containers when possible.
Lately, there's also been a movement against inheritance in general. The strength of C++ has always been that it naturally causes data that gets used together (i.e. in an object) be located close together in memory. However, when working repetitive operations on a set of many objects (e.g. updating the x, y, z position of all game objects), it thrashes the cache with all the superfluous data. Instead of one memory fetch retrieving 16 sets of useful coordinates, it now only retrieves one, simply because of the way memory is arranged.
The name of this new movement is dubbed data-oriented programming (as opposed to object-oriented though they are not mutually exclusive), and is by and large championed by a fellow called Mike Acton. Google him to find out more, but just be warned he can be a wee bit overzealous. It just so happens that straight C lends itself more to this style of programming, though there's no compelling reason why it can't be accomplished in C++ as well. It is a non-intuitive approach though, which can be unsettling for a generation of programmers brought up on pure OOP, myself included.
I hope that gave you some food for thought. Programming is like a never-ending learning adventure!
Pretty interesting post, thanks for taking the time to write this!
Sorry, I lost track of this thread - if CecilSunkure hadn't responded I probably wouldn't have remembered to reply.
Interesting thoughts e-Goh. While (ignoring VC6 cuz it's terrible) I'm not specifically familiar with an implementation of STL that would allocate 20 small 4kb pieces for a string, I know that some consoles, my understanding is that especially the PS3, don't really handle heap allocations very well and you have to be super-careful and micro-manage every single access to the heap regardless of how big or small it tends to be.
There was an interesting push for data-oriented programming when I was in college, too. It really was lead by people whose ideas were terrible, so I had some natural bias against it but I did look around a little bit and I see some areas where it could be of great assistance. I read this PDF, which really seemed to do a good job: http://www.rti.com/whitepapers/Data-Oriented_Architecture.pdf.
To be honest, I think this is where a multi-paradigm language such as C++ really shines because you can have segments of your application using a more traditional OOP style mixed with areas of your application that focus on the data-driven design and then use more of the functional/template driven design patterns as the glue to bring the worlds together in a generic way without either having to be exposed to the nasty bits of the other. For example, I really like how DDP aligns better with parallelism and alleviates some of the nastiness and slowness that constantly handling concurrency can cause you but I would be apprehensive to say that it's a superior overall architectural design. However, the nature of C++ allows you to use the best parts of each from a pure point of view and really put together a strong architecture.
Your point about inheritance is interesting to me because I find it hilarious how often (especially games) misuse or overuse inheritance where even basic composition would make things so much easier to understand. For whatever reason, application and game developers seem absolutely obsessed with enormous inheritance chains that accomplish little beyond making things almost impossible to understand and removing any semblance of type safety. The Half-Life SDK is a great example of this phenomenon. I've always chatted with coworkers and discussed their use of inheritance and whether they consider other techniques to build what they're trying to build that would reduce those chains and possibly even provide opportunities for further growth. It's almost ironic that inheritance chains seem to end up a funny way that code becomes coupled.
At any rate, yeah - I always love learning new things. I've built a few games in the past, but never been happy with them. It's one of those things I've always been interested in doing but something I've never been interested in completing I guess. After I kinda build up the core systems I seem to lose interest really fast for whatever reason.
But I mean, the code I work on has either dealt with huge data structures or had very narrow windows in which action was possible. I've always enjoyed trying to squeeze every bit of performance out of something and try to make it fit in a tiny window, which is why I'm looking forward to hopefully receiving my raspberry pi sometime in the near future. I wrote a horrible shell of an OS a long time ago, so I was thinking about giving that another go just on a hobby level :-D
EPT![[image loading]](http://2.bp.blogspot.com/-JhTvVg8kFFY/Tt1BaivtNhI/AAAAAAAAAC4/BK9XEz-jTsc/s1600/Capture.PNG)
![[image loading]](http://4.bp.blogspot.com/-ZMoWUR-Ydbc/T0cDj7I-A-I/AAAAAAAAADQ/ucO3WxbkKQw/s320/Capture.PNG)
![[image loading]](http://i.imgur.com/qQw2b.png)
