68 replies to this topic

[JETerán]

I have been following this topic very closely, and this is my personal conclusion as a self learner and with a BS in CS.

All the programming are a trip to learn. Think about them as is a way to help you achieve the system/game you have in mind. Please don't waste your time on analizing what could be more easy/dificult to handle/learn. In my experience, the harder things to learn are the most rewarding.

What I do is follow the trend; I do what PRO game developers do because, if you do, at the end you will achieve the same goals and results. It's just a matter of logic deduction.

Another thing, if virtually all the modern tools/games/engines are made in C++, it's because it has to be very versatil and rewarding (Valve or Epic can't be wrong), thus, needs some time to understand and learn; but when you do it, the results are limitless.

And finally, start TODAY. There's a bunch of tutorials/activities/classes/etc on the internet. The first that comes in my mind is gameinstitute.com, powered by PROs of the industry.

If you really want to make games, the only thing is that's stoping you is your attitude.

Hope this helps. I wish you the best success in this awesome trip.

Edit.
And you need to have "talent" to do it? nah, I don't think so. I think you have to stick with it until you accomplish your job. I remember a quote of John Romero that says (about when he was learning C) "crap, I remember readying all the book and not understaing anything that was saying". And that didn't stop him.

Check this article i read today:
http://www.theverge....on-took-so-long

Edit 2.
I wrote this as a way of reflexion. I frecuently try to stick to Aristotle's quote: Says the ignorant, the wise doubt and reflect.

Thanks guys.

Edited by JETerán, 09 September 2012 - 10:58 AM.

[phantom]

What I do is follow the trend; I do what PRO game developers do because, if you do, at the end you will achieve the same goals and results. It's just a matter of logic deduction.

Unfortunately your logic is wrong.
Beginners are not pros - pros are often people with years of experiance in the field thus what a pro does or does not use is of no importance to someone just starting out.

For example where I work we play many tricks with how memory is allocated, pointers are fixed up and how things are passed around the system; we are professionals and yet I would never advise someone to follow our line of thought without experiance.

The end result of the journey might well be using the tools that pros use however this will be relevent once the person in question gets to their level.

Another thing, if virtually all the modern tools/games/engines are made in C++, it's because it has to be very versatil and rewarding (Valve or Epic can't be wrong), thus, needs some time to understand and learn; but when you do it, the results are limitless.

And they are designed this way due to legacy and existing requirements - those are not the same requirements that a beginner is going to have.

Also there has been a shift to the vast majority of in-hosue tools being written in a .Net language.

Most games in existance are probably Flash or otherwise based as such C++ has no relivance there either.

AAA game production, staffed by experianced people with specific requirements, is not a guide for where someone should start regardless of their ultimate goal - it might guide their process as they progress however first of all you have to learn to program and as such what pros do is not important.

[Shaquil]

And even if you fall back to doing char * strings or <type>* memory allocation you now run into the world of no bounds checking where you can do as you like and nothing will tell you otherwise until something blows up in your face.

I've seen beginners confused by things relating to 'access violation at address 0x000000c' which I can look at and say 'oh, it's this...' right away but they have no idea about. And yet allocating instances of types and calling functions on them is central to C++ but not for learning to program and can be taughted better in language which tell you via better error messages what has gone wrong. Try missing of a ';' somewhere in a header and watch the explosion of error messages which happen due to one tiny syntax error which has no impact on the ability of someone to learn the basics of programming.

Hell, there was an example recently of someone being confused because they could apprently call a function via a null pointer to a class without things going wrong.

The C++ standard itself is known for using the word 'undefined' or 'implementation defined' through out its language.

None of the things I've mentioned above are 'advanced' and yet I've seen over the years people repeatedly trip up over them and then the resulting cryptic error messages/reactions from the runtime which can come about from it.

Edit: you can also add to that list compile times, header files, pathing issues and libraries.
Again none of those are advanced but being forced to deal with them just to learn is, to use your phrase, 'insane'.

He'll learn the best way to do the things he's been doing later. Just like when you start off writing code like int box1, int box2, etc, and then later you learn "Oh, that's what arrays are for. Bad habit erased."

But it's not just Bad habits like that - C++ carries with it a massive legacy and with it comes 'advice' which might have been important 10 or even 5 years ago but these days is worthless.

New C++ programmers, the ones who seem to defend the language with such tenacity (or ones who only know C++ like it is the only thing worth knowing), are also the biggest source of 'not made here syndrome' - many shunning the standard library as if it is some slow and horrible thing, instead favouring that own bug ridden versions, because they once read somewhere that it was slow. This persists going forwards and instead of taking advantage of tools which exist they go on to try and reinvent everything because they feel somehow they will 'learn more' (also the classic excuse of someone who wants to make a game but believes making an engine first is a good idea).

This is a mind set which is VERY hard to break and one which continues to be recycled from programmer to programmer as someone new starts all the other newbies around them just tell them what they have done themselves.

(I figure it must be some kind of self reinforcement cycle - "if someone else does it then I can't be wrong" but that's far far off topic).

All of the above is why, when compared to other languages, C++ is lacking.

Yes, C++ has it's strengths, one of which is being on all platforms and other of which being if you know what you are doing you can get more out of it than maybe you can in another language HOWEVER those two arguements are utterly moot because they are advanced topics (often requiring knowledge of the target platform and how the code generation can work) and you have already stated that advanced things don't matter to beginners.

When you are starting out getting told what you are doing wrong is more important than speed or frankly other considerations beyond learning the art of programming.
C++ makes this harder than it needs to be.

This was by far your best post. You used specific, concrete examples and attacked the ideas I presented instead of attacking me, I love this post. Now here's my response:

I've come up against a couple of the things you mentioned, and usually after already getting a couple of days into coding something. It was frustrating, I was confused, there were few answers, and it would have been easy to quit. But it was also exciting. It's fun making horrible mistakes and then learning why they're mistakes and what makes them so wrong in the first place. There's no better way to learn about something than to try really hard at it, fail, and then ask people who know better than you "Why did I fail?" It will always be better than having people warn you beforehand: You should absorb what you can from what you read/are taught, try it out, and then go back to learning with the new perspective you've gained from putting it in action: You can relate to what you're reading.

This is my personal philosophy, and you may agree or disagree.

And what you bring up also points to a very valid concept I neglected, but should have mentioned: There are some languages that might be better for those who want to learn to program games, and then there are some better for people who want to make games. I think it is misguided to try to write your own huge libraries/tools/engines when you can just build on previously done work, but then again the people who justify it by saying "I'll learn from it" are being sincere. Most likely, they aren't just interested in making games, but also understanding the basic inner workings of games. They want to know why the cool stuff works just as much as they want to make the cool stuff.

To that end, it's a bit harder to find a distinction between learning to program and learning to program with the technologies at your disposal. If a person agrees with you, they'll think that C++ is overkill, or too burdensome, and they probably think it's a language that requires too much technology learning at the cost of programming learning. If a person agree with me, they probably feel like they're interested in both learning the foundations of programming, and some powerful technologies to program with.

Again, it's just a matter of personal discretion rather than some god-given guideline. Completely subjective.

[L. Spiro]

Unfortunately your logic is wrong.
Beginners are not pros - pros are often people with years of experiance in the field thus what a pro does or does not use is of no importance to someone just starting out.

In this case, phantom is far from wrong.
Beginners should not emulate pros—the same results have no meaning if the reasons behind them are not understood.


But phantom says (without quoting) that people don’t learn from mistakes they can’t see.
That’s really a non-issue. Programmers will see those mistakes when the time comes that they reveal themselves.
The logic that a beginner will only see certain mistakes at a certain time can be applied to us all.
Whatever your level in C++ is, a mistake at your level +1 could be lurking in the shadows.

We will all get to them when we are ready.
As far as I am concerned, facing them early on is just building a level of critical thinking that will at a later age put you above your peers.
Unless you want to deny the biological truth that younger people learn more easily than older people.

You do no one a favor by presuming what they will be thinking at age 30.
I can tell you I wish I had learned C++ sooner so that I would be better at it today. For me to have followed the advice given on this forum today—
It’s like a 3-year-old child I met on the plane to Thailand the first time I left America. His mother was Korean, his father Japanese, and he was raised in America.
Guess what. While everyone else is second-guessing how much children can learn, his Korean and Japanese were entirely fluent, while I at the time knew only English (he also knew English, making him trilingual at age 3, with no accent in any language).


I stand by my previous statement.
Each person learns at his or her own level and rate.
Let each person explore this subject on his-or-her own and decide for him- or her- self what language is suitable for him or her.

Shaquil is not making his point very well, but he is not wrong.

What do you mean?

I mean what I said. I am sitting here taking your side, but I can’t vote up your posts. Something irks me within them…
That being said, it is possible that you are not being taken seriously enough because of your rating.
I do feel that some people are making C++ seem more horrible for a beginner than it should be, and I agree with points you have made in your posts.
They have been taken out of context and used to promote the other side.


C++ was my 3rd language, preceded by BASIC (TI-81 Calculators) and mIRC Script. That is what I had available to me. I could not initially grasp concepts such as dynamic memory allocation, and I was an idiot in this regard, but no previous programming experience helped me with it, and I would have ultimately been better off just learning it from the start.
As I mentioned, this was a basic thing I learned later than I should have just because of my upbringing.

Again, the final answer is to let this person try some languages himself and decide by himself what is overwhelming. Everyone learns differently. We can’t answer this question for this person.


L. Spiro

Edited by L. Spiro, 10 September 2012 - 04:52 AM.

[L. Spiro]

I've come up against a couple of the things you mentioned, and usually after already getting a couple of days into coding something. It was frustrating, I was confused, there were few answers, and it would have been easy to quit. But it was also exciting. It's fun making horrible mistakes and then learning why they're mistakes and what makes them so wrong in the first place. There's no better way to learn about something than to try really hard at it, fail, and then ask people who know better than you "Why did I fail?" It will always be better than having people warn you beforehand: You should absorb what you can from what you read/are taught, try it out, and then go back to learning with the new perspective you've gained from putting it in action: You can relate to what you're reading.

Now you have started to support your side better.

This is the type of person I would hire. Is it not the type you would hire?

I can also say for sure that I would never hire a person who asks, “What are the minimum requirements for blah blah blah.” I don’t care about people who seek the minimum requirements to complete a job.

C++ is harder to learn but I would rather have someone on my team whose resolve has been tested than someone whose resolve has not.
That being said, going with another language as your start is not so bad as I make it seem either. Again you really need to gauge this for yourself. Few people will blame you if you discover that C++ is too much to learn as a beginner. But you should at least try it out before you dismiss it.


L. Spiro

[swiftcoder]

I do feel that some people are making C++ seem more horrible for a beginner than it should be, and I agree with points you have made in your posts.

On the other hand, most of the people making C++ out to be a nightmare (myself included), have experienced C++ in a production environment. My impression (possibly incorrect) is that most of the posters avidly defending C++ do not share this same experience.

My daily work involves tracking down and squashing the kind of bugs that even highly experienced developers introduce to a large C++ code base. The type of bugs caused by triggering undefined behaviour in the language, misinterpretations of the language standard, compiler-specific edge cases, and obscure threading and allocation issues (which are often platform-specific).

Now, I'm not saying that other languages don't suffer from many of the same problems - but a language like Java does a hell of a lot more to insulate you from this sort of thing. And that's why I'll always recommend that one not start with C++ as a first language.

C++ is harder to learn but I would rather have someone on my team whose resolve has been tested than someone whose resolve has not.

So you like to hire stubborn programmers? Nothing wrong with that.

But sadly, 'learning' does not strongly correlate with 'knowing', when it comes to C++. There is a world of difference between someone who programs in C++, and someone who actually understands the language well enough to defensively anticipate pitfalls he hasn't run into yet - and trust me, there are still pitfalls that both you and I are yet to encounter.

Edited by swiftcoder, 09 September 2012 - 12:41 PM.

[phantom]

C++ is harder to learn but I would rather have someone on my team whose resolve has been tested than someone whose resolve has not.
That being said, going with another language as your start is not so bad as I make it seem either. Again you really need to gauge this for yourself. Few people will blame you if you discover that C++ is too much to learn as a beginner. But you should at least try it out before you dismiss it.

For me it would depend; if they ONLY knew C++ then I'd frown on it a little. Knowing a few programming languages make someone considerably more useful than someone who only knows the one at the expense of others, even in a junior position.

Part of my usefulness on our rendering team is that I can work just as well on the C++ engine as I can with the C# and python based tools - in fact during our swift rewrite of our build system I'm pretty sure in one day I did significant code in all 3 languages. Granted I wouldn't expect a new person to be able to do that, but still if I was presented with two candidates who were otherwise the same and one had some C# experiance and the other a little more C++ I'd take the former over the later.

[azonicrider]

I received the following question from the original poster via private message, but I'm answering here so others can also benefit from the responses.

As you know I want to begin python, where may I find updated tutorials there all from 2 - 3 years ago... :|

You'll want to learn Python 2.7 rather than Python 3; the differences (from your perspective) will be fairly minor and easily adjusted to once you decide to update, but for now a lot of the libraries (such as PyGame) you will want to use have not been updated to Python 3.

I recommend Thinking In Python, A Byte of Python, and the official documentation for learning Python. Once you get to learning Pygame you'll want to start with the official documentation and tutorials listed on the website.

Would there be a difference between 3, and 2? We both have 3 and are willing to downgrade.

Different in syntax, the only difference I remember, is using ("this is a string") instead of "this is a string" for printing out strings. Or printing out anything.
But yes, I had to downgrade to Python 2, to get it to work with Pygame. That was in June though, so maybe they've updated their library.

Edited by azonicrider, 09 September 2012 - 04:57 PM.

[Shaquil]

I do feel that some people are making C++ seem more horrible for a beginner than it should be, and I agree with points you have made in your posts.
On the other hand, most of the people making C++ out to be a nightmare (myself included), have experienced C++ in a production environment. My impression (possibly incorrect) is that most of the posters avidly defending C++ do not share this same experience.

My daily work involves tracking down and squashing the kind of bugs that even highly experienced developers introduce to a large C++ code base. The type of bugs caused by triggering undefined behaviour in the language, misinterpretations of the language standard, compiler-specific edge cases, and obscure threading and allocation issues (which are often platform-specific).

But this is where I think the conversation diverges from "Is C++ a good language to start with?" and becomes "Is C++ a good language?" As I've mentioned earlier (many posts ago; I don't expect anyone to go back and read) "learning" code and "mission critical" code are two entirely different things. Someone whose first language is C++ may never actually use any C++ at their workplace. On the other hand, someone who started with python may end up writing tons of C++ code in positions you've held yourself. We're talking about a starting point. The very beginning. The basics. And in that context, C++ is just plainly no worse than many of the other languages mentioned. There's a lot that it doesn't do for you, and there are plenty of things you're left confused about; but this isn't a problem exclusive to C++.

[swiftcoder]

We're talking about a starting point. The very beginning. The basics. And in that context, C++ is just plainly no worse than many of the other languages mentioned.

Spot the error that won't be caught by compiler or runtime, then try to reproduce the same (silent) error in Python:

int main(int argc, char **argv) {
	 if (argc > 1);
		  printf("too many arguments.\n");
}

And another:

int main() {
	 char *array = new char[10];

	 array[20] = 5;
}

Shall I go on?

[JETerán]

Start here
http://www.khanacademy.org/cs/tutorials/programming-basics

[Karsten_]

I think perhaps someone on this thread who is very stuck on the idea that C# is easier should try to convert this "Test" class to C#.
What I would like them to do is pay extra attention to making sure the outcome is exception safe (since "Danger" might throw an exception).
I can guarentee that the exception safe C# implementation will involve quite a bit more code.. and be more error prone... and not as elegant... and slower... ;)

struct Test
{
  // Something contains a thread or socket descriptor so must be cleaned up.
  std::auto_ptr<Something> something;

  Test()
  {
	something.reset(new Something());
	Danger danger(something.get()); // throws exception
  }
};

Edited by Karsten_, 11 September 2012 - 03:47 AM.

[Dynamo_Maestro]

I think perhaps someone on this thread who is very stuck on the idea that C# is easier should try to convert this "Test" class to C#.
What I would like them to do is pay extra attention to making sure the outcome is exception safe (since "Danger" might throw an exception).
I can guarentee that the exception safe C# implementation will involve quite a bit more code.. and be more error prone... and not as elegant... and slower... ;)

struct Test
{
  // Something contains a thread or socket descriptor so must be cleaned up.
  std::auto_ptr<Something> something;

  Test()
  {
	something.reset(new Something());
	Danger danger(something.get()); // throws exception
  }
};

Well considering we have no idea what you are trying to achieve, what you are trying to do or any information other than some random code, one could easily and validly do anything, maybe the design choices made sense in C++ and thats why 'you' feel they wont work in C#, maybe theres a better way to do things that are so much simpler over all and you have just complicated the situation and since we dont know what Something / Danger is how are we meant to mimic the example.

Sometimes more code is written in C#, that doesnt make it a bad thing, depending on what it is, you cant simply add some code and accuse C# of being error prone or not elegant, I was tempted test your theory but honestly I have no idea what I am even looking at never mind why an exception is required and I could easily question why you used a struct, why theres no destructor, why you chose auto_ptr, randomly (and pointlessly) questioning your example.

I am sure if you posted the whole example a C# programmer would happily test your theory, I was going to post an equally pointless async method and ask you to do it just as elegant and safe in C++ but I dont think theres much point

[Karsten_]

Heh, I still suggest you try it.. You will be suprised how awkward these (effectively 3 lines) are in C#

And this is barely as complex a technical requirement as an async example (although we have some pretty good C++ libraries for that without requiring language changes. For Compiler specific async functionality, OpenMP is much better than C#'s offering, and Codeplay's offload can even do it in parallel on the SPU. Much more powerful than anything C# can do!). This just demonstrates that C# fails at even the most simplistic design requirements.

edit: FYI

public class Test : IDisposable
{
  // Something contains a thread or socket descriptor so must be cleaned up.
  Something something;
		
  public Test()
  {
	try
	{
	  something = new Something();
	
	  using(Danger danger = new Danger(something))  // throws exception
	  {
		  
	  }
	}
	catch(Exception)
	{
	  Cleanup();
	  throw;
	}
  }
	
  private void Cleanup()
  {
	if(something != null){something.Dispose();}
  }
	
  public void Dispose()
  {
	Cleanup();
  }
}

Edited by Karsten_, 11 September 2012 - 12:52 PM.

[MichaBen]

On the other hand, most of the people making C++ out to be a nightmare (myself included), have experienced C++ in a production environment. My impression (possibly incorrect) is that most of the posters avidly defending C++ do not share this same experience.

Over the last years I have spend quite some time debugging, fixing and refactoring parts of an old C++ engine that contains large pieces of badly written code, parts of it written by long-gone interns. Yeah, it contains some nasty bugs, and evil C++ constructions and even had some dependencies on compiler-specific bugs. Still, the majority of the bugs are still logic errors, only a very few number of the bugs are actually those so called evil C++ constructions that invoke undefined behaviour. Your post kind of gives the idea that these bugs are a significant part of the average C++ code base, but in general that is not the case. Logic errors still remain the majority of the bugs, and for the fatal errors most of it were either assertions or null pointer crashes, which will not be different on so called safer languages (yeah, null pointers may trigger an exception rather then crash, but if you didn't expect a null pointer you probably didn't put try/catch there either so it will terminate with unhandled exception after all).

[swiftcoder]

yeah, null pointers may trigger an exception rather then crash, but if you didn't expect a null pointer you probably didn't put try/catch there either so it will terminate with unhandled exception after all

But it will also give you a lovely stack trace, which tells you exactly where to start investigation.

By comparison, a SEGFAULT doesn't give you any trace, unless you are experienced enough to a) be running your program in GDB, or b) have core dumps enabled, both of which require you to know how to compile with debug symbols enabled and optimisation disabled.

And that's assuming you even received a SEGFAULT in the first place - it's entirely possible that your invalid pointer landed somewhere you actually have permission to write, in which case the error will be silently ignored (until some indeterminate time later, when you find an invalid value elsewhere in your program.

[Karsten_]

Valgrind has always given me a much better output than .NET's generic stacktrace stuff and gdb for this kinda thing and as such is trivial to fix.
Valgrind can also detect memory errors without requiring a SEGFAULT too.
Using standard smart pointers (like you should be using) helps avoid these issues anyway.
In C and C++ it is very easy to disable optimizations and add debugging symbols.
C# also needs to be put in debug mode or it won't give out line numbers.

Edited by Karsten_, 11 September 2012 - 01:01 PM.

[swiftcoder]

Valgrind has always given me a much better output than .NET's generic stacktrace stuff and gdb.

Sure, but now we aren't talking about languages, we are talking about complex and platform-specific development tools (that beginners won't know to use, or how to use effectively).

In C and C++ it is very easy to disable optimizations and add debugging symbols. C# needs to be put in debug mode or it woun't give out line numbers.

Can you tell me, off the top of your head, exactly which optimisations are disabled at -O1 versus -O2, and what optimisations still need to be disabled to reach Python-level debug-ability (i.e. constant folding)? Can a beginner do the same?

We aren't talking about experienced C++ developers using their language of choice. We are talking about fresh-out-of-highschool, wrote-a-few-pages-in-html beginners. Your protestations to the contrary, I just don't see where C++ is in fact as easy as Python for this use-case.

(and please keep in mind that when I assert this, it is on the basis of having spent several semesters teaching programming to non-CS students).

[Dynamo_Maestro]

Heh, I still suggest you try it.. You will be suprised how awkward these (effectively 3 lines) are in C#

And this is barely as complex a technical requirement as an async example (although we have some pretty good C++ libraries for that without requiring language changes). This just demonstrates that C# fails at even the most simplistic design requirements.

edit: FYI

public class Test : IDisposable
{
  // Something contains a thread or socket descriptor so must be cleaned up.
  Something something;
		
  public Test()
  {
	try
	{
	  something = new Something();
	
	  using(Danger danger = new Danger(something))  // throws exception
	  {
		  
	  }
	}
	catch(Exception)
	{
	  Cleanup();
	  throw;
	}
  }
	
  private void Cleanup()
  {
	if(something != null){something.Dispose();}
  }
	
  public void Dispose()
  {
	Cleanup();
  }
}

I wouldnt know what I was trying to achieve, I understand that you want to mimic something but what if 'Danger' or 'Something' were poorly implemented, that caused the verbosity in the first place.

You will need to post the full example if you want me or anyone else to understand and then a comparison can be done, I dont have a link but an oldish thread a while back attempted something like this and when the guy posted the full C++ example it was a disaster and didnt even work in either C# or C++ and I think he even compared WPF to Win32 :/.

The problem with these comparisons are they are limited to certain things and often important parts are missing, for example, in C++ you got away with Something something; where as in C# I would have had to write Something something = new Something(); based on this I could easily say C# is more verbose, but ultimately its the end product that is the focus. I recently had a situation where I had to change my design because I no longer could use PhsyX, changing the C# side of things was fine and straight forward, but C++ holy shit I lasted almost 2 weeks fixing stuff and still found problems after, now even though it was my fault for redesigning mid way development I could easily have said "C# is better".

Sometimes its the developer that needs a review not the language ;)

Anyway im a fan of C# and C++ and use them both for different things but typically together, I personally am more in favour of C# for many reasons but sometimes I prefer to use C++, I could list all the great things about C# and even compare it to C++ but it makes no difference what others prefer and I gain nothing by convincing people to pick a language and you know what the best thing is about using both C# and C++ together, it means I get to laugh at comparisons

[Karsten_]

Dynamo_Maestro,

This code example really couldn't be simpler. We arn't interested in how Disaster or Something are implemented, all we need to know is that we must call Dispose on them.
This is mimicking something. It is mimicking C#'s piss poor attempt at useful resource management and it fails. It is not suitable for games.

As for your suggestions on design change or the developer needing review.. Hey, I agree this stuff does happen, but changing effectively 3 lines compared to around 8 plus 2 extra functions ain't a good start to the refactor... or the poor git having to sit down with the coder under review to check the src! hah.

Can you tell me, off the top of your head, exactly which optimisations are disabled at -O1 versus -O2, and what optimisations still need to be disabled to reach Python-level debug-ability

I see what your saying but frankly just because C++ has the extra features, you certainly don't need to teach it all to beginners. Likewise with python you probably teach them using the garbage collector rather than true RAII (with CPython).

Kinda like we don't need to teach C# using the /unsafe flag and pseudo pointers to beginners. There is more to learn in C++ to become a master... but that is not a bad thing... it just shows how limited C# really is.

Afterall, they will probably always be ending up using Visual Studio and select the Debug profile in exactly the same way they would in C# and Visual Studio. Teaching them using the command line and Vim never goes down well.

I also teach a few courses at my University (while I am doing my PhD) and I have taught using two very different platforms. XNA/C# in the first year (until it was effectively dropped by Microsoft) and now C++ and OpenGL. So far there have been no extra issues due to the upgrade in language and platform. Plus the students will be in a far better position at the end of it knowing a true industry standard language rather than being tied down to hobby or games making tools like XNA.

Edited by Karsten_, 11 September 2012 - 01:28 PM.