C/C++ more complex? The basic concepts are the same, I would say that C/C++ is actually easier as the high-level abstractions in languages like Java and C# can make it very hard for a beginner to grasp what is actually happening. I and other developers dislike it when people think they can program, yet do not even grasp what is happening with the code after you compile it, how it affects the hardware and why something is more efficient than something else, why a function call and the usage of classes is relatively expensive, and such.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Programming Language for Game Design
- Thread starter Guitarrasdeamor
- Start date
I agree with you a 100%, but I don't expect a non-programmer (OP) to think C/C++ is simple or else he wouldn't be stating it otherwise.
Also, C/C++ provides full control and power to the programmer that I don't agree to hand all that to a novice and creating security holes on the platform his/her app will run on.
Everyone starts of somewhere, mine was TI-BASIC for those TI-8x calculators.
If you say that your first ever language is C/C++, then my hat is off to you.
BTW, my language progression is BASIC, VB, VB.NET, C#, Java, C/C++, x86 ASM.
Call me backwards, but I manage to land a Tech Managerial position in a financial firm with my 10 years computing experience.
Last edited:
- Joined
- Sep 6, 2006
- Messages
- 8,821
I skimmed most of the posts and I saw C# was referenced a few times. This with the XNA framework is not a bad place to start. Tons of documentation.. free!... and it works great on Windows, XBOX, and Zune platforms.
It also has a lot of room for you to get a grip on concepts.
It also has a lot of room for you to get a grip on concepts.
Is your complaint really with the language, or more with the tool set being used to develop in those languages?
Identifying the current skill level and desired skill level of a developer is part of the industry. Incidentally the same could be said for any industry.
Yes, C/C++ offers one enough rope to hang oneself with many times over. Yes, it's harder to do certain things because one's hand isn't being held all the time. Yet, if you combine C++ with say the Boost libraries, it isn't so far removed from C# with its fancy libraries.
I started with QuickBasic, then VB and Java, C/C++ followed by an explosion including PHP, Perl, C#, Python, more Java, Ada, VHDL and more.
I'm complaining about the high-level datastructures Java for example uses all over the place. I'm sick of using Hashsets and all of those while a simple pointer or reference isn't allowed or anything else which isn't 'OO'. It doesn't teach one anything about the underlying hardware, won't give you any idea of what is efficient or what isn't and basically just isolates one from WTF the compiled (byte) code will do in the end.
When using C/C++ it matters to know how the registers are used, what happens when you call a function a particular way, use references or pointers in a particular way. With C#, Java and such languages one basically codes blind and I feel that this is a very harmful thing if one wants to learn to program. I sure as heck wouldn't hire one who only knows how to program in those languages, or still hasn't got the faintest clue as to how register allocation is affected by certain calls in one's code, how to use inline assembly, or how to unroll a loop.
Programming is programming. It's the same basic skillset, the same concepts. Just because one language decides to shield the programmer from all those 'icky' low-level things doesn't mean that they aren't important. It's what makes a programmer more than just 'decent'.
You're still bouncing around the point, and now it looks more like your complaint is with managed versus unmanaged code. And then your argument shifts toward your perceived importance of the educational order of computing topics.
I understand you have an opinion, but you're only providing niche examples that all fail to create any cohesive concept or exact statement. Perhaps listing what you perceive as specific skill sets and requirements would help clarify. Though I think it will still come back to simply spotting mature developers and assigning to the right job or project. And that in itself would eliminate any hobbyist developers from the scope.
Programming is programming, but your examples and complaints are getting to specific and are out of scope of the basic "Hello World" level applications of implied applications/concepts. Again, this comes down to identifying developer maturity.
Edit: The more I think of the wide array of complaints you've shared, the more I believe the expressed frustrations would evaporate by understanding concepts like: project management, developing solutions congruent for the client/user, and intermediate job/project interviewing skills.
Wow. I'm almost certain you couldn't have missed the point any farther than with that reaction to my posts. I'm going to suggest you research reading comprehension.
If that reading suggestion hasn't created a paradox, then re-read my posts given the context you've provided: You've presented opinions and comments on developer attitudes, preferred programming educational order, and language capabilities/levels (among other sub-topics). And each opinion/comment is supported by niche facts and/or gripes.
So to rephrase what I am wondering: Is there really some cohesive common denominator between these complaints that can be summarized, or is each complaint independent of the others?
Last edited:
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
A new programmer trying to figure out why their program is crashing at a certain point will have a much harder time doing so with C/C++. Moreover, pointer manipulation and its associated complexity can be a massive frustration to a starting programmer. "What's actually happening" (at the processor or assembly level) isn't as important to a programmer who is just starting and trying to get their head around basic concepts. You don't need to know what an ALU is, how a register functions, what a branch not equal command is, or anything like that in order to learn the basics of program flow.
Some prefer a high-level approach - take an existing program/framework, give it to the person, have them tweak and toy with it to start learning. Some prefer a low-level approach - get as close to the hardware as practically possible, and learn the basics of assembly, taking that knowledge and seeing what a compiled program spits out. I prefer something in the middle - start with a language that helps with type checking, boundary conditions, et cetera. Learn the basic constructs of programming - procedural and object-oriented, using the language as nothing more than a learning tool. Most of the syntax is shared (with minor variations), and I think writing a solid, dependable program is more important than learning how to write a fast one that uses amazing pointer hacks. I think it's easier to learn that kind of skill when starting with a higher-level language.
Sure, some of the code will be boilerplate to start, but the important thing is that the person learns how to read the documentation; understand conditional constructs, variables, loops, and methods/subroutines/functions; and be able to apply that without trying random changes of > < >= <= ++ -- in order to get to a non-segfaulting program.
Unless you consider what's actually happening a basic concept.
Learning what pointers do is easy. The fundamental concepts are just about memory addressing, data, data representation, and type size.
One of the problems with higher-level abstractions is that at a certain point, you're just learning the abstraction and you're not learning something that's applicable to a wide varaiety of subjects. Instead of learning the subtlties and unique features of one particularly language, or its implemnentation, why not learn how any language works, on any computer?
Last edited:
I was saddened by the personal attacks, but I do (obviously) agree that a lower-level approach is the way to go.Thank you for summarizing the point I tried to explain in my previous posts
I think that some people assume that lower-level languages, like assembler, end up giving the student useless knowledge. This is far from the case, as this level of knowledge can be learned by studying embedded application development. Such work almost always involves writing code in a low-level language and understanding the processors direct interaction with the peripherals and devices it controls. Embedded systems are the most common applications of microprocessors, and dwarf the sales and penetration figures of desktop machines and applications. It's really hard to support the argument that his knowledge is useless.
Useless knowledge would be knowing the year in which each MJ album was released
Embedded software engineering is indeed a huge market, and essential to learn if you ever want to become more than a programming monkey. Even for game design it is somewhat essential, as there's a lot to be gained if you understand exactly how an engine works, how OpenGL works, how hardware is addressed and why a particular routine is bloody slow
Embedded software engineering is indeed a huge market, and essential to learn if you ever want to become more than a programming monkey. Even for game design it is somewhat essential, as there's a lot to be gained if you understand exactly how an engine works, how OpenGL works, how hardware is addressed and why a particular routine is bloody slow
Well, useless knowledge is knowledge that doesn't propel you towards a goal. If your goal is to be the best MJ Fan Evar, then you need to know when those records were released.
If Guitarrasdeamor wants to be a professional developer, then he needs to know the fundamentals to be effective and competitive. If he just wants to make a game in his spare time and earn his living some other way, then he can follow whatever path he might like -- to minimize useless learning and therefore expedite his goal. Languages like C# with XNA, Scratch, or Alice appropriate for that case, I think.
If Guitarrasdeamor wants to be a professional developer, then he needs to know the fundamentals to be effective and competitive. If he just wants to make a game in his spare time and earn his living some other way, then he can follow whatever path he might like -- to minimize useless learning and therefore expedite his goal. Languages like C# with XNA, Scratch, or Alice appropriate for that case, I think.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Which I do!
Then I think it's a matter of deciding which order you want to do things in.
I think the fundamentals are important, and you're going to be less lost later on if you learn them early. Books like Code and Write Great Code: Understanding the Machine can help you get started. After that, you'll want to learn how to use a language like C++. Books like C++ Primer and C++ Primer Plus are good for learning C++, once you understand the fundamentals of how programmers view the computer.
Once you've got an understanding of C and C++, you'll want to start to understand the Windows API. Programming Windows has been the canonical reference for this, though there are many competing books. The only one I'd consider seriously (or recommend) is Programming Applications for Microsoft Windows.
With an understanding of the machine, the language, and the Windows API, you can move on to the game-specific code you want to write. You'll probably want to use DirectX, so get a book on that. Frank Luna's books, like Introduction to 3D Game Programming with DirectX 10 or Introduction to 3D Game Programming with Direct X 9.0c will get you on your way.
If you want to approach a different OS or a different language or a different game API, then you'll choose different books. Somewhere during the process, you'll want to understand algorithms and data structures. You can work through Introduction to Algorithms or The Sedgewick Books for that. A good reference is The Art of Computer Programming.
If you want to just jump in and start with one of the game books you listed earlier, I think you're going to end up lost in how C++ works, what the machine is doing (even superficially) under the hood, or what Windows is doing for your application. You won't know how to knit together abstract program structures into a tangible solution, so you'll feel like your actions aren't connected to your results. Since you don't understand these things, you can't expect to approach the DirectX API with any chance of success. I've neglected to mention any of the logic or math you might need along the way, as well.
Feel free to try it, but I think you'll just get frustrated.
I think the fundamentals are important, and you're going to be less lost later on if you learn them early. Books like Code and Write Great Code: Understanding the Machine can help you get started. After that, you'll want to learn how to use a language like C++. Books like C++ Primer and C++ Primer Plus are good for learning C++, once you understand the fundamentals of how programmers view the computer.
Once you've got an understanding of C and C++, you'll want to start to understand the Windows API. Programming Windows has been the canonical reference for this, though there are many competing books. The only one I'd consider seriously (or recommend) is Programming Applications for Microsoft Windows.
With an understanding of the machine, the language, and the Windows API, you can move on to the game-specific code you want to write. You'll probably want to use DirectX, so get a book on that. Frank Luna's books, like Introduction to 3D Game Programming with DirectX 10 or Introduction to 3D Game Programming with Direct X 9.0c will get you on your way.
If you want to approach a different OS or a different language or a different game API, then you'll choose different books. Somewhere during the process, you'll want to understand algorithms and data structures. You can work through Introduction to Algorithms or The Sedgewick Books for that. A good reference is The Art of Computer Programming.
If you want to just jump in and start with one of the game books you listed earlier, I think you're going to end up lost in how C++ works, what the machine is doing (even superficially) under the hood, or what Windows is doing for your application. You won't know how to knit together abstract program structures into a tangible solution, so you'll feel like your actions aren't connected to your results. Since you don't understand these things, you can't expect to approach the DirectX API with any chance of success. I've neglected to mention any of the logic or math you might need along the way, as well.
Feel free to try it, but I think you'll just get frustrated.
Last edited:
As an Amazon Associate, HardForum may earn from qualifying purchases.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Thanks a lot, I'll check out getting those books in that order.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
I base my recommendation on what I observed at university. I don't think learning what the assembler is doing to be useless knowledge, but I think it's knowledge that should be backfilled in. Yes, there are markets and jobs and such for embedded programming and its associated complexities. However, this person stated that he "wanted to get into the field of game design" and that he was "torn between languages." That indicates to me that he has no programming experience at all (as you know and have spoken before, right tool for the right job, and languages are often interchangeable).
Based on those statements and assumptions, I tend to follow the model I saw being taught (quite effectively) at Cal Poly: SLO. Start in the middle with a language that gives you useful error messages upon crashing and can be approached with either a procedural or object-oriented approach. We started in Java, but since using C# (and knowing that XNA exists, which looks better than the various java equivalents I've tried...), I now recommend C# instead.
After getting through the basics of program flow, learn data algorithms and how they function, conceptually. This gives you the basics to be a code monkey, but not much more. For many, this is all they want, and it's why I suggest starting there. You and Elledan clearly push more towards the "learn to be an engineer of software, not a programmer" camp, and I think that's great, for those who want it. For those people who do want or need more, the next step I'd recommend is to start learning assembly and how it functions, how to do a simple translation of calls into the equivalent assembly, and how different processor types/assembly languages differ in both implementation and use. Taking that, you can reexamine what was learned earlier in light of the newfound knowledge of the internal working. I don't think all of that is needed, though, to start programming and even to get a working game together. Pushing a person who just wants to have some fun with making a simple game into running the full gamut of software engineering might very well dissuade them from getting where they want. I've found that many prefer small, incremental rewards of completion, and that merely acquiring a new piece of knowledge isn't often what drives them (though I know it drives me, and appears to drive you, Mike).
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
Useful to a starting programmer, yes. Without going too much into tracing dump files or hooking up a debugger, it's difficult for a new programmer to extract useful information from a C/C++ crash.
As for your second point, it depends on what you are trying to do and your goals. If you want to work writing software, perhaps that's true, but in other cases (IT jockey who needs to throw together a script for something, businessman who could benefit from some programmed automation, or even "I'm not sure who interested I am in this stuff but would like to have some fun making a game" kid) just being a programmer is enough. Sometimes, teaching a person to be a programmer sparks their interest enough for them to pursue the engineering. Philosophically, however, I don't think that's the only appropriate path.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Well, for the moment, I've started here: http://www.cprogramming.com/tutorial/lesson1.html
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
Cool, I've gone through those, they're not bad, quite good in fact.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Cool. One thing I think I'll have to do is take notes...as much as I hate it in school, it seems that it might help here, even though I can look back at it, this will maybe implant it into my mind.
Only if you use GCC and its 'debugger'. Visual Studio is a much better way to learn C/C++. It offers clear error messages while compiling including references for more information, and it's a snap to debug an app in it while it's running. How in the world would you make this process easier? People can say a lot about MSFT, but they make one heck of an IDE.
We use VS exclusively within my company, although we have ensured our code compiles on GCC as well (although no app will ever compile on every version of GCC, even within 3.x and 4.x, unless it's Hello World). VS 2005, of course, since that one has the best compatibility with external add-ons and libraries
Good luck. Let us know if you have questions.
Why wouldn't a developer always have a debugger attached? It's not difficult, and it's already there. Your comment puzzles me; you're excluding the solution, and saying doing something is hard without using the solution that's entirely intended to actually solve the problem. To investigate a crash, you use a debugger to check out the dump. Why are you excluding that?
I'd point out that such a person is neither a programmer nor an engineer; they're an IT jockey, or a businessman.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Will do. I was going to do some more (only did the first lesson) but was damn tired. I actually forgot I had 3DS Max installed..., so I loaded that up and did a tutorial today.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Lol, thanks. The guy who was giving the tutorial was very good. I only lost him a few times, and that is with no prior knowledge. I think I'll try a table and a lamp next and create a small scene. I am interested in this a little bit more than the coding at the moment, but that is primarily due to being able to instantly have a product.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
Maybe by way of example using a trivial program and its resulting output (using VS 2010 Beta 1 until I update to B2 this week)...
C++
Code:
int main()
{
int test[5] = {0};
test[5] = 4;
return 0;
}Run-Time Check Failure #2 - Stack around the variable 'test' was corrupted.
C#
Code:
static void Main(string[] args)
{
int[] test = new int[5];
test[5] = 4;
}Index was outside the bounds of the array.
Below error message, the following tips appear, with links to topics detailing what's being explained as possible point of failure:
Make sure the maximum index on a list is less than the list size.
Make sure the index is not a negative number.
Make sure data column names are correct.
Get general help for this exception.
I find the latter much more instructive and useful for a starting programmer than the former. Yes, I think the former should probably be learned as well (i.e. what stack corruption is, how it occurs, etc), but having the assistance provided by c# in debugging when you're just staring is incomparable. Perhaps you've been doing this so long that you've forgotten the frustration a new programmer experiences when they get messages that are as cryptic as they are useful. Even with a debugger attached, there is much less actionable to a new programmer given by C++ than C#, even in our awesome IDE.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
I miscommunicated. I meant without going out of your way to debug. If using gcc, this means without using gdb, for windows, it means not using ntsd, cdb, windbg, etc. I didn't mean to exclude using whatever comes in your IDE of choice.
Of course, even without "hooking up a debugger" (default output from a chk no opt build) and running the program from command line, the output is the same (generic stack corruption error for c++ and the following for c#
Unhandled Exception: System.IndexOutOfRangeException: Index was outside the boun
ds of the array.
at TestApp.Program.Main(String[] args) in D:\PersonalDev\TestApp\TestApp\Prog
ram.cs:line 14
)
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
I made a little crappy table and experimented with putting posters on the walls and textures for about 30 minutes. I think I'll definitely need someone to make me textures if I do make a 3D game...lol.
EDIT: Eh...started to try and do a spider...I'm not sure where to start experimenting...
EDIT: Eh...started to try and do a spider...I'm not sure where to start experimenting...
Last edited:
You can also have a degree in game design. Look here: http://www.thedegreeexperts.com to find the best online program from the list of online courses provided by various top universities. Universities referred here are all accredited by USDLA.
Guitarrasdeamor
2[H]4U
- Joined
- Apr 5, 2008
- Messages
- 3,622
Lol, thanks Elledan...I just need to know what do with it. I hate playing around with stuff, and I don't know why (unless it is a physical object). I was the same way at the beginning of Photoshop.
Gary, I know, but I'm just not into the college thing. If it wasn't for all the extra shit that went along with it (core classes and such)...I might look into it more.
Gary, I know, but I'm just not into the college thing. If it wasn't for all the extra shit that went along with it (core classes and such)...I might look into it more.
Whatsisname
[H]F Junkie
- Joined
- Nov 15, 2000
- Messages
- 10,201
This entire line of argument you are pursuing is nonsense.
The default crashing style of a built executable is meaningless. Debugging by littering your code with printf statements is fun and all, but it is a massive waste of time. Any reasonably complex piece of software is going to require a debugger if you want to make it work in a reasonable amount of time.
Comparing two programming languages based on debugging, without using the tool designed to do exactly that, is absurd. If you are using windows, the visual studio c# and c++ debugger is very nice, not using it is a complete waste of time.
The default crashing style of a built executable is meaningless. Debugging by littering your code with printf statements is fun and all, but it is a massive waste of time. Any reasonably complex piece of software is going to require a debugger if you want to make it work in a reasonable amount of time.
Comparing two programming languages based on debugging, without using the tool designed to do exactly that, is absurd. If you are using windows, the visual studio c# and c++ debugger is very nice, not using it is a complete waste of time.
Maybe by way of example using a trivial program and its resulting output (using VS 2010 Beta 1 until I update to B2 this week)...
C++
Error message on crash (only thing displayed):Code:int main() { int test[5] = {0}; test[5] = 4; return 0; }
Run-Time Check Failure #2 - Stack around the variable 'test' was corrupted.
C#
Error message on crash:Code:static void Main(string[] args) { int[] test = new int[5]; test[5] = 4; }
Index was outside the bounds of the array.
Below error message, the following tips appear, with links to topics detailing what's being explained as possible point of failure:
Make sure the maximum index on a list is less than the list size.
Make sure the index is not a negative number.
Make sure data column names are correct.
Get general help for this exception.
I find the latter much more instructive and useful for a starting programmer than the former. Yes, I think the former should probably be learned as well (i.e. what stack corruption is, how it occurs, etc), but having the assistance provided by c# in debugging when you're just staring is incomparable. Perhaps you've been doing this so long that you've forgotten the frustration a new programmer experiences when they get messages that are as cryptic as they are useful. Even with a debugger attached, there is much less actionable to a new programmer given by C++ than C#, even in our awesome IDE.
Tawnos
2[H]4U
- Joined
- Sep 9, 2001
- Messages
- 3,809
Nonsense how? I'm simply stating that for a starting developer the diagnostic output produced by c# is more useful than that of c++. That ignores the debugger, but even if the debugger were considered I would dare say it's an easier task to debug c# (so long as you don't use "unsafe
) than c++. Nowhere did I say "litter your code with printf" (or equivalent). And yes, any reasonably complex piece will need some debugging, but when a user is starting out, just getting through the basics of "create a list containing 30 numbers and print them out from end to beginning" will often lead to simple crashes. The kind where being told "memory was never allocated" or "accessing outside of array boundary" helps.