Forgot your password?
typodupeerror
Programming Games

Ask Slashdot: Best Way to Learn C# For Game Programming? 254

Posted by timothy
from the can't-sharpen-the-sea dept.
An anonymous reader writes So I, like many people, want to make my own game. Outside of MATLAB, Visual Basic, and LabVIEW I have no real programming experience. I initially started with Ruby, but after doing my homework decided that if I ever wanted to progress to a game that required some power, I would basically need to learn some form of C anyway. Further digging has led me to C#. The other parts of game design and theory I have covered: I have ~8 years of CAD modeling experience including Maya and Blender; I have a semiprofessional sound studio, an idie album on iTunes, and am adept at creating sound effects/music in a wide variety of programs; I'm familiar with the setbacks and frustration involved with game development — I beta tested DotA for 9ish years; I already have my game idea down on paper (RTS), including growth tables, unit types, unit states, story-lines, etc. I've been planning this out for a year or two; I will be doing this on my own time, by myself, and am prepared for it to take a couple years to finish. The reason for listing that stuff out, is that I want people to understand that I know what I'm getting myself in to, and I'm not trying to put out a not-so-subtle "help me make a game for free lol" type of post. With all of that said, where is a good place to start (i.e., recommended books) for learning C# for game programming? I am familiar with object oriented programming, so that's a little bit of help. I'm not necessarily looking for the syntax (that part is just memorization), but more for the methodology involved. If anyone also has any suggestions for other books or information that deal with game development, I would love to hear that too. I know enough to understand that I really don't know anything, but have a good foundation to build on.
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Best Way to Learn C# For Game Programming?

Comments Filter:
  • by Anonymous Coward on Friday June 20, 2014 @05:49PM (#47285529)

    You should just start. I'm an "expert" on game programming in C#, and the hardest thing about it is not reading slashdot.

  • by Anonymous Coward on Friday June 20, 2014 @05:50PM (#47285541)

    So just do it. Use free tools so you don't spend coin on something until you are sure it's something you'll stick with.

  • Re:It's too slow. (Score:5, Insightful)

    by neminem (561346) <neminem AT gmail DOT com> on Friday June 20, 2014 @06:05PM (#47285631) Homepage

    I'm pretty sure the reason your payroll calculator written in C# was that slow had nothing to do with the .net framework and everything to do with something you failed to optimize in that version, but did optimize in the original Cobol version. Either that or you were running it on a way slower computer - a "desktop OS" rather than a "server", even though those terms are pretty meaningless and there should not be any reason you would have to run it on a desktop machine? Unless, of course, you're defining "server" as "machine that doesn't run Windows", in which case, that's pretty no-true-scotsman-like. You can make a plenty fast Windows server machine, then run headless, server-like C# programs on it.

    Yes, obviously C# programs aren't going to be quite as fast as equivalent c++ programs - you *are* compiling C# code to bytecode and then running it through a virtual machine, so of course it'll be a little slower. But only a little. I doubt you could write a balls-to-the-wall Crysis-like shooter in C#, but I don't imagine there'd be any performance-related reason you couldn't write an RTS in C# and have it run just fine on any machine not so old that its OS wouldn't support the .net framework anyway.

  • by Anonymous Coward on Friday June 20, 2014 @06:18PM (#47285703)

    Yeah, no shit... is anyone else sick and tired of these Ask Slashdot "stories" where the obvious answer is "pick up a fucking book"?

    Seriously, Amazon has a shitload of them with titles like "C# Game Programming," "Learning C# by Programming Games," "Beginning C# Game Programming" etc. etc.

    What the hell is wrong with kids these days? Oh... I'm sorry, the question was "what's the BEST way?"

    There are these little stars next to the book titles on Amazon...

  • Re: It's too slow. (Score:1, Insightful)

    by Anonymous Coward on Friday June 20, 2014 @06:40PM (#47285819)

    Ok. I'm going to make wild ass guesses here.

    1. Your company was using COBOL-based payroll system. FROM WHICH:

          a. Your company is not in the business of writing software for sale to others. They're not software engineering experts.

          b. Your company's business process changes very slowly. It is not a dynamic working environment. Slow growth, if any, OR

          c. Your company's business is highly regulated.
    2. Your management is fairly conservative.
    3. Management does not know, value or do a particularly good job of using technology to increase productivity and automation.

    This kind of environment isn't a preferred opportunity for highly skilled, creative software engineers. Your engineers were likely average or low-average talent. Probability. Not fact. That's OK. Not everyone is a superstar. It doesn't take superstars to get the job done. It just takes work.

    People who really understand how to work in COBOL have a set of patterns and ideas about software engineering that is a lot different from
    the usage patterns in which Java and .NET were designed to perform well.

    I'm not saying that there aren't plenty of engineers who "get" COBOL who also "get" .NET. It's just that gaining expertise in those to skill sets come from divergent experiences.

    Finally, it's just not that hard to do things with .NET and Java that make it be slow. They're garbage collected and safety checked. Sometimes that hurts.

    So, bottom line, your software engineers probably used C++ to construct a system that was likely structured a lot like the COBOL system was structured. It's safer to do it that way.
    And likely, some of that structure and a few of the idioms they used within it were killing performance on .NET. .NET and Java are awesome platforms. They have limitations. It's not always clear what they are at first glance.

    The good news is that most of the time, you can get a lot of performance gains for not much work if you just sit down and do it methodically.

    Finally:

    There's a lot of games out there with core logic and game engine type stuff written in C#. The graphics, IO, Sound systems are the ones that have to perform fast.

    When you want to push a lot of bits, code closer to the hardware. When you want to do a lot of complex logic, give yourself some help with higher abstraction.

    Good luck.

  • Unreal 4 (Score:5, Insightful)

    by alteveer (979070) on Friday June 20, 2014 @06:42PM (#47285841)
    My advice, as a professional game developer, is "don't write code unless you need to."

    If you must write C# you should take a look at Unity, but honestly you would be remiss if you overlooked Unreal 4. It is the newest version of the Unreal Engine, and it includes most of the most important features of a game; behavior trees, navigation, user interface, physically-based rendering, animation state machines, multiplayer replication, etc. You can do most of what you want to in Blueprint (a visual scripting language), and if you really need to, you can edit the source code (the license is a full-source license) and make what enhancements you need in C++.

    Writing most of this shit from scratch will take you years, just get down to the actual MAKING of the game, and use someone else's engine. The terms are fair ($20/mo, 5% gross revenue for PC platforms and mobile), and the engine is extremely well curated.
  • by Shaterri (253660) on Friday June 20, 2014 @07:06PM (#47286027)

    To reinforce this: Building your own engine is a great way to fall into a trap that you won't escape for years if not decades. If you're interested in building a game, then you should build a game, and use the toolchain that lets you get to your game as quickly as possible. Right now that's a race between Unity and Unreal Engine 4, and while neither one has perfect support, I'd say the userbase for Unity is sufficiently deep that it's a better starting point. Don't worry, you'll still get plenty of opportunity to code (and to learn C# - another reason to go with Unity over UE4, if that's the language you really want), but there'll be enough that you don't have to code that you can focus on the fundamentals of building your game.

  • by gweihir (88907) on Friday June 20, 2014 @07:32PM (#47286173)

    Unless you want to be locked in to MS? Learn, any of the things that also work on iOS and Android and you may actually end up with an useful skill.

  • by Brulath (2765381) on Friday June 20, 2014 @07:41PM (#47286235)
    Not every game needs to be super CPU-intensive though; Hearthstone is created in Unity3D, for example, and that works super well on everything but an iPad2. Skipping C++ initially and learning to create a game in Unity3D with C# is probably a wise choice for a bunch of people, at least for prototyping and for a wide variety of games that aren't CPU-limited.

The typical page layout program is nothing more than an electronic light table for cutting and pasting documents.

Working...