Do you agree with this article? I'm not sure that I do. I think the problem is not that C# and XNA are high level, but that because they are high level and allow you to achieve impressive results with relatively little effort, people tend to only teach what is necessary to achieve those nice results. They don't teach the relevant theory, algorithms and principles because those are not immediately useful and are not needed to get a fancy demo running. In other words, the problem is not with the choice of C#/XNA, but with the way they are being used/taught. Do you agree? BTW, sorry if this has been discussed before.

Disclaimer: I don't work in the games industry and have zero intention of ever doing so.

XNA allows you to get stuff up and running quickly, and is essentially a C# wrapper around parts of the DirectX and Direct3D frameworks. Trouble is, a lot of the internal implementation is shielded from you so you can do so much without understanding how any of it works.

To me, it's like having a vintage car and a modern one (for the most part). Open the bonnet (hood to you Americans) of your 1967 Ford Anglia and you'll see all sorts of bits and pieces and, unless you're a mechanic, you won't have a clue about what half of it does. Open the bonnet on my dad's 2005 Saab and you see a massive plastic blanking plate, held down by non-standard screws that the AA couldn't remove when it broke down last year - you can see no internal parts and the only things you have access to is the oil dipstick and washer bottle.

What I'm trying to say is that XNA is effectively a sealed unit, and it's perfectly possible to use vast swathes of it without understanding how half of it works. Just because you've written Half Life 3 Episode 6 using XNA doesn't mean you know how to write a fast scheduling algorithm, or implement per-pixel shading using the darkest corner of the video memory, or how to implement perfect 3D collision detection because, chances are, you're using XNA's own implementations from the already available methods without any understanding of the theory. You can easily call

public void superDuperTwozzle(GraphicsDevice gfx, Matrix viewMatrix, OMFGFastShaderObject shader)

and out comes Halo 4, but do you understand it based on the tutorial code you stole from Ziggyware? Probably not, in fact it is probably more of a hindrance than actually sitting down and learning the theory.

Mind you, I think the same of things like the Java Collections Framework (what's the internal implementation of SuperDuperArrayList<Foo>.MegaSort()? Is it a quicksort, selection sort? How do the sorting algorithms work? If you don't know and understand that, then how can you know which ready made tool to use?) in that people just use them because they're there, without any thoughts for performance and efficiency.

Yes, getting flashy demos running ASAP is all well and good, and it's a great way of prototyping, but if you've got a load of flashy demos using a sealed-unit framework and know nothing about the technical implementations or can't think outside of the box then there's a good chance that you'll crash like the Hindenburg in a technical interview. This is especially true when you consider that the vast majority of retail console titles are written in native C++ SDKs, the exceptions including smaller casual titles such as those found on XBLA and XBLIG.

I agree with that article for the most part, but if XNA is becoming more and more popular I think there may be a shift towards that sort of thing. Perhaps, one day, Microsoft will be able to produce a new C# exclusive XDK for the AAA developers to use? You never know, but if stuff like this does happen then perhaps the article will be a lot less correct.

Stuff like XNA should be used to reinforce existing teaching and not to replace it.

I can't speak for a pure game development degree, but really I don't see it as such a big problem.

Going to C# and XNA over C++ and DirectX or OpenGL is just a natural progression of technology. After all, how many computer games are written in x86 assembly these days? You'd be crazy to try to write a modern game in such a way, because much better and more appropriate tools are available for the task.

C# might not be quite as fast as C++, but it makes development a lot easier. XNA might not be as fast as pure DirectX calls, but I bet it's not that far off. But you save a lot of time in development, and it's easier to teach.

So, using these languages and APIs is not a problem at all in my opinion.

Not teaching fundamentals is a problem, but I don't necessarily consider teaching how to keep track of pointers and avoid causing seg faults to be a fundamental that needs to be taught if someone is going to be using C#. After all, it's completely conceivable that a new programmer these days may never touch C or C++ code.

Basic algorithms, data structures and that sort of thing are just as important to a pure game developer as a general computer scientist, for sure. As long as a student knows what a linked list is, what it's for and how to use it, it's not such a big deal if a class is already available for them. That's what the STL is for in C++ anyway.

Edit: My experience with XNA is fairly limited, but I feel that even though it takes care of a lot of things for you, that's still not a big problem. It's not like developers are still writing everything from scratch these days anyway. I'd imagine that most large titles are using physics libraries instead of writing their own code, for instance. Plugable modules are definitely going to be the way of the future, so you might as well teach that sort of thing to students.

Not that it hurts to teach them how something like collision detection works, of course, but it's kind of less important to go into depth unless physics is your specialty in the game dev business.

I read Lee's point in that article as being summarized by his final paragraph:

Quote:
So what should these students be using? C/C++? Well yes, that is pretty much an industry standard but concentrating on those would cause exactly the same problems. Try C/C++, try Lua, Prolog, Lisp, SML and a variety of scripting languages.

That the problem is not that Language X is being used in courses, it's that it's Language (singular) X. It's just another form of specialization over generalization, and on that point I agree: it would be useful if students were exposed to a much broader slice of the available languages and development paradigms that exist.

But perhaps I'm just reflecting my own opinion into his words.

I tend to agree with jpetrie's take on things, the fixation on a single language is a problem.

I would agree that the people coming out of these courses and heading into games programming, certainly if their aim is console shops which the majority are, need some understanding of C and C++. However, we can't expect expert level of understanding because C++ on its own is a beast which can take years to get to grips with but they should certainly be able to handle beyond the fundamentals.

(Personal experience: guy I've been working with for around a year and a half now, primary experiance in C#, good coder but had to ask me a fundimental C++ question a few weeks back. Confusion down to his familarity with C# over C++).

I don't see the usage of C# and XNA as a problem however, simply because when they get spat out of university your average graduate is going to go on and work with technology which already exists giving them time to get to grips with the more advanced things. Or not of course, it could be that they stay at a level of 'game play programmer' as such all that back end knowledge about graphics pipelines, networking, sound systems and the like they might have been taught would be effectively wasted.

What certainly needs to come out of these, and other, schools is an ability to problem solve, to ask questions, to be able to design systems (even at a game play level) and work within a team correctly.

(Personal experience 2: guy joined the company last year, during his 3 month probation period while working on our game he took it upon himself to, in the branch he was working on, re-write the Lua interface moving all the functions which previously took a lua object into class functions for the lua object without mentioning it to anyone. I found out the day before we were due to merge for pre-milestone testing.. I raged. Fortunately he learnt from this experience and has become a decent member of a team, didn't get me back the 3h merge time however while I had to detangle everything).

Personally, I think in a perfect world these courses would be longer to give a broader chunk of information to students (more languages for example), the places teaching would get paid differntly so they didn't have to fight to hang on to students, and hopefully from this we'd get a high quality, if lower number, of students out the other end.

Quote: To me, it's like having a vintage car and a modern one (for the most part). Open the bonnet (hood to you Americans) of your 1967 Ford Anglia and you'll see all sorts of bits and pieces and, unless you're a mechanic, you won't have a clue about what half of it does. Open the bonnet on my dad's 2005 Saab and you see a massive plastic blanking plate, held down by non-standard screws that the AA couldn't remove when it broke down last year - you can see no internal parts and the only things you have access to is the oil dipstick and washer bottle.

And yet that automechanic needs not the understanding and theory of how ores are mined, refined, cast and forged into componets themselves. Even in the world of car modification for more performance people are still dependant upon such sealed systems...These heads with this block, that intake with those exaust manifolds...Inorder to develop, engineer, and manufacture any of those parts requires an extra level of understanding well beyond that which most automechanics grasp.

My line of work is manufactureing engineering for embedded systems. Basicly this involves takeing the product plans of one group of engineers (say a control module for automated stop lights) and engineering the process to manufacture it. Much of this involves takeing off the shelf sealed systems (widgets) and constructing purpose designed systems for the manufacture of the product. I don't need the extra specialisation of the product engineers to do my job. And the end users of my work, the assembly workers, need not my engineering knowledge either...and the customers who use such products need even less knowledge to use the end product.

So even with knowledge beyond C# and XNA, you are still dependant upon the hardware manufactures and chip engineers and the standards which they set with thier sealed systems. And as these systems matured something like XNA is bound to happen. At some point this XNA "wheel" meets 99% of the users needs, lets those seeking to satisfy the remaining 1% try to reinvent it.

Ahh, the old 'low level' vs 'high level' debate, in a game development specific tone.
C# will abstract away the pain of explicit memory management, it will clarify code and will let you get to the point.
XNA isn't that high-level to keep the important stuff away from the programmer, you are still dealing with vertex and index buffers, writing shaders, scene graph, render queue, light culling. It just keeps you from writing yet another .X , .3DS, .COLLADA, texture ... loader, it handles some animation (but you still need to know what you are doing), gives you basic math primitives, and generally kills those useless and unproductive days of work and debugging that will provide little insight in to the relevant subject. It's hardly a magic wand that allows students to create Halo and Half Life - if that was all it took than game programmers would be out of business.
What's the difference between writing a deferred shading demo in XNA or C++ & DX regarding the knowledge gained/demonstrated ?

As for learning different languages, you can hardly get away from that, and you have to be really lucky to avoid learning/using C++ in gamedev, but learning different paradigms is what's important.

Although XNA would be even better if it was open sourced (at least partially).
The resource manager for eg. I could hack it to do resource loading in the background thread(s). You can 'sort of' do it right now (load file to memory in a background thread) but if it was opensource you could go beyond this, essentially process the entire file to the VB/IB copy phase, or loading lower levels of the mip-map texture first and progressively loading others in parallel, so the smallest one gets loaded right away...
And it wouldn't require exposing any of the low level/platform specific stuff for the XBox, just the resource manager.
Not that any of the above would actually be useful in a indie game, but as a prototyping/learning platform it would be really great if I could just hack on my ideas on to already existing platform.

Quote: Original post by phantom
I tend to agree with jpetrie's take on things, the fixation on a single language is a problem.

Well said. While I was at university students were exposed to a variety of languages: C, C++, x86 ASM, ML, Prolog, and Scheme. Learning these was the absolute minimum requirement. Unless otherwise specified, coursework was accepted in any language. A professor expected to receive submissions in the languages listed above as well as any other programming language.

I suspect professors enjoyed seeing their students learn new languages on their own. Often times students would compete with each other by completing coursework in particularly "hard" languages simply to out do their peers. Things like writing a universal turing machine in Haskell would give the author a tremendous amount of "street cred" if you will.

What specific universities pump out students that learn only one language or have a "primary" language, anyone?

Quote: Original post by aaron_ds
What specific universities pump out students that learn only one language or have a "primary" language, anyone?

I could name one I've attended which is almost pure Java, with the exception of a few erratic weeks of badly-taught C in second year (the lecturer didn't understand his own course material and the teaching topics were very disjointed and full of non-sequitors), with equally small lashings of XHTML, a tiny bit of MIPS assembly running in an emulator and never properly explained, and a tiny bit of optional PHP.

So yes, it was mostly a Java shop. That's not to say we enjoyed it, though; much to the contrary [grin]. I remember them saying at the open day initially that they thought it worthwhile that their students would be able to graduate and put on their CVs that they were Java programmers, which of course sounded great at the time because I hadn't studied that abomination before [smile].

For reasons of personal security and my current personal circumstances, I won't name said institution although I will say I transferred out of it two years ago and now attend another institution.

As I've said before, however, it's my personal belief that UK universities are pumping out armies of mediocre programmers and ill-prepared "software engineers" exposed to three-four years of badly managed, internal and artificial projects as opposed to actual computer scientists or people capable of solving an actual, real world problem.

C# and XNA can make the task of game development easier. I do not see how that is a bad thing.

Some of the most profitable games are retardedly simple.