Slashdot Mirror
Ask Slashdot: Best Way to Learn C# For Game Programming?
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.
You should just start. I'm an "expert" on game programming in C#, and the hardest thing about it is not reading slashdot.
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.
Udemy has 12 courses(https://www.udemy.com/courses/search/?ref=home&q=c%23) up there and they have big sales all the time. If you can get some for $10, it might be worth it.
"I say we take off, nuke the site from orbit. It's the only way to be sure."
do the unity3d tutorials and mess around with C# in there. you get to use your 3d skills and actually make something whilst you learn
Everyone I know that tried it, gave-up on it.
Except for those people who had to target a platform that requires verifiably type-safe CIL that targets the .NET Compact Framework. Xbox Live Indie Games was this way, as was Windows Phone 7. Practically the only language that produces such bytecode is C#, as standard C++ as compiled by C++/CLI is not verifiably type-safe and IronPython requires Emit which isn't part of the Compact Framework.
the C++ code ran on a server instead of a desktop OS like C# requires.
Windows Server is a server operating system whose NT kernel is inspired by the architecture of Digital's VMS. It runs C# in the .NET Framework. FreeBSD is a server operating system. It has a port of Mono, a .NET Framework workalike, called BSD#.
Warning: this is blatantly self-promotional. It's also a pretty good answer to the question, I think, so hopefully I won't get violently modded down.
It sounds like you're exactly who Jenny Greene and I wrote Head First C# for. I played around with a lot of different ways to teach both C# language and core object oriented programming and computer science concepts, and I found that building games was easily the most satisfying way to do it.
The only way to really learn a language is writing a lot of code, and one of the biggest challenges I had putting the book together was coming up with many different projects. The answer was games: a card games, a turn-based game, arcade games -- it turns out that building a game is a great way to keep readers motivated, especially when they're learning new concepts. I've had a lot of really positive feedback from first-time programmers who found it really satisfying to get through the book, and especially building the final project (a retro Space Invaders game).
You can download a free PDF of the first three chapters of Head First C# from the O'Reilly page and see if you like it.
Building Better Software
Why C#? Develop your game in C++ using OpenGL ES for rendering. Your code will compile as-is for iOS, Android, Windows, OSX, and others. You will only need a couple hundred lines of native code (java for Android, Objective C for iOS, etc) to handle events and pass execution into your C++ code. My game engine runs on all the above platforms and 99.9% of my code is shared across all of them.
Also, these days many, many developers simply use an existing game engine and only bother with the high level code specific to their game. Mundane stuff like the low level rendering, Audio APIs (which unlike OpenGL ES, differ quite a bit from one platform to another), physics, etc, is ground that's been treaded several thousand times nowadays, and most game developers leave that stuff to the experts in the various fields to handle the nitty gritty. Optimization of those routines is usually where the "expert" part comes into play.
I work with a game designer / artist who implements all the high level game stuff in Lua, and my engine takes care of all the aforementioned "boring" stuff, freeing him up to actually develop games, and not worry about crap like polygon tessellation algorithms and tons of other very boring stuff that would just be a waste of his time.
Better known as 318230.
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.
Forget C#. Start with Haskell and get a PHD in category theory and applied mathematics. Then study GHC internals for several years in order to figure out how to make Haskell fast enough for anything non trivial. Only approach game development once you have a solid understanding of GHC internals, endofunctors, lenses, monoids, monads, comonads, cofree, cofree comands, synergistic cold fusion, rankntypes, multi parameter typeclasses, string theory, functional dependencies, synthesized kinetic energy, generalized new type deriving, existential quantification, existential crisis, scoped type variables, GADTs, the space time continuum and have solved the halting problem. Also reimplement the entire standard library because the current one is terrible and horribly inefficient.
Either that or pick up any of the few dozen C++, C# or Python game development books and start reading.
C# is typically slightly slower than Java so....
Citation please? In my experience C# is somewhat slower than native code but much faster than Java.
Any insufficiently advanced magic is indistinguishable from technology.
I love C#. I program in it every day. It's plenty fast, and it's a great language.
However, there are two reasons I would suggest looking to another language.
First, the hottest market for gaming right now is mobile. While it's possible to compile C# for iPhone or Android using Xamarin (along with Windows and OS X), it's not exactly a native experience.
Second, C# (like O-C, C++, etc.) is a general programming language -- it's not in any way specific to the domain of game programming. So, while it's *possible* to design complex games in any modern language, you're probably going to spend *way* too much time dealing with silly stuff like tracking graphics resources and animation loops and simulated physics. You'll have a higher chance of success if you use a language and platform that is more game-specific out of the box.
I would suggest looking into Swift -- it'll give you access to the lucrative iOS market, it's C-like, and it has features that are game-specific. Sure, it's a new language it doesn't compile to Android, but by all accounts it looks like a great language with first-class support for gaming, so you can focus less on infrastructure code and more on the game.
Another option would be HTML5. Depending what sort of game you're looking to build, Javascript and HTML5 may be just the ticket, and there are a number of libraries that can abstract away browser differences and assist with the plumbing needed to make a game run.
Yep,
Unity - you would be surprised how many commercial games are using it. Several new independent titles like Wasteland 2, Torment: Tides of Numenera, Castle Story, Kerbal Space Program. Runs on Windows, Mac, Linux, iOS, Android. I also heard that over 50% of the mobile games are using unity (check out "The Room" and "Temple Run" for examples). The scripting language is C#. The workflow is tailored to the visual assets, so it is perfect for someone with your background. The unity engine does a lot of the work for you, so you can accomplish quite a lot with not a lot of scripting.
Pick an engine you want to use first, then pick a language to learn that is used by that engine. Very few games now are written purely in a native language with no supporting engine, so pick a modern game engine that will do a lot of the hard, low level work for you. Then, learn the language that is used for interacting with the desired engine. For example, if you wanted to use the Unity engine, then you would basic learn C#. If you wanted to use CryENGINE, then you would learn C++ and Lua scripting. If you wanted to use the Unreal4 engine, then you would learn blueprint visual scripting and C++.
Once you know the engine and language you need to use, then pick up a book, take a course, etc... There are lots of ways to learn a language, but the most important thing is to practice, especially in the environment and engine that you plan to use. Each of the engines have extensive documentation on how to program for their engine and interact with the game assets.
http://gameprogrammingpatterns...
This site takes a subset of the "Gang of Four" patterns and explains how and why to use them in your games.
You'll especially enjoy the command pattern which will be heavily used in an RPGSgame.
Cwm, fjord-bank glyphs vext quiz
I'm currently using C++ for developing an RPG, and I would recommend it over C#. I don't know much about C#, butI have coded in it a few small programs. C++ is very well known in game development. I would recommend it and a framework such as SFML or SDL. Once you get more familiar with these, you can move onto learning Directx3D and OpenGL. Learn about Game States (I just learned this the other day and it drastically makes management of game code so much easier), game timing, game loops, Isometric games, sprite-sheets and tiling. The latter two are important for 2D games and since you are building a RTS, It may be essential for you. I know you are not doing a RPG game, but a lot of the material can be used for an RTS. I'm following a book called Programming Role Playing Games in Direct x, it's not for beginners, but it has valuable information on gaming algorithms for Enemy AI, Game States, Game loops, etc. I would recommend checking out Coke and Code ( type that into Google ). I think the same person also released a Youtube RPG tutorial series. 3DBuzz has some tutorials, but some are paid. There C++ one also does a RPG game. SFML Made Easy is another series on Youtube that is really good. It wont be an easy task, just start small, take your time, and don't do too much at once. Start with just getting a character walking around on a screen ( this will require animation frames, so look that up ). Understand the update() and render(), calls in a game loop.
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.
C# is typically slightly slower than Java so....
Which means, just as GP AC said, it's completely unsuitable for a "serious" game.
What OP needs to learn is C, or at a minimum C++. Nothing else will fly for this application. Rudimentary games can be done in other languages, but anything that really needs fancy graphics or fast processing will need C++ or C.
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.
Surprisingly enough, there is. A lot of game developers use GameMaker to prototype games. But some of them are good enough to be published on Steam straight out of Gamemaker. And it's simple enough that my 11-yr old has been using it for his own game.
Disclaimer: my former prof built it.
There's also Unity3D.
These tools take away a lot of details that used to be 80% of the work, and leave you to work on the *game*, as opposed to rendering the screen without tearing or trying to get the audiobuffer to play without clipping, or... etc.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I use unity. Like you say, if you make more than $100K per year, then you need to buy pro.
But really, who cares? $1500 - $4500 (depending on what you need) is a very reasonable price for the tool, and an insignificant cost at that point. The cost of writing games is orders of magnitude higher than that, and Unity will end up saving you more in time than $4500 worth of programmer's time. They don't even charge royalty.
Also, why a trap? The terms are clear and you know them up front. Nobody is deceiving you into paying for something you did not want. From my point of view, the terms are quite generous and reasonable, and if you don't think so, then you simply use other tool and this does not affect you
If you have to pay $4500 because you are making $100K/year , it is a very nice problem to have :).
C# doesn't 'run through a virtual machine' - CIL bytecode is 'always' JIT compiled to native machine code in both Microsoft's .net platform and in Mono.
The only overhead/problem here is quality of the JIT (you need only look as far as ECMA 262 to see how much difference that can make, eg: JaegerMonkey vs. V8), CIL JIT has type checking requirements - so there's once-off validation overhead for each JIT, and lastly unlike C/C++ your JIT compiler rarely has (or wants to have, due to memory and performance considerations) a complete view of the entire program - so you don't get anything remotely similar to link-time optimisations.
That said - for relatively flat code structures - well written C# will JIT into, in many cases, identical instructions to what GCC/Clang/MSVC will do for equivalent C/C++ code.
The primary differences are around exception handling and boxed types. Neither of which you're going to be using heavily in performance critical code segments in C# anyway - because all of them can be avoided with well written C# or some unsafe magic.
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
I'm sorry, but your long list of "I did this and that" means only that you are a gamer with a few artistic skills, it has absolutely no value for game programming !
During my 18 years of game programming, I met a lot of people that had "wonderful" ideas (it's funny how everybody has a dream game), but no skill to realize them.
They always boasted about the fact that their idea was great, but their project never got released.
Writing a game requires the following skills:
1) technical skill: coding
2) art skill: graphics/animation and sound/music
3) gameplay skill: making the game enjoyable
4) story telling: making a coherent game's universe
In my life, I never met a single person with all of these skills, at a decent level.
The most talented ones had only 2 skills.
Firstly, before coding your dream game, try to write a very simple game. It will show you where you'll need help.
If you are a beginner, you won't be able to code Starcraft.
Try something related to your project, so you can increase your knowledge.
Secondly, since most of the CPU power is spent on display and AI, you'll need to learn:
1) how to optimize the display.
Since the whole screen needs to be redrawn very frequently, you have to learn techniques to render fast.
There are tons of techniques in 2D and 3D.
2) AI algorithms, most notably path-finding algorithms if you want to program a RTS.
Thirdly, try to build a prototype in one month.
If you are able to build it in one month, you'll probably be able to work on your project during several months.
It will also show that you don't lose yourself on details (non-professionals tend to waste their time on small details, thus the final goal disappears).
If you are unable to build it in one month, it means that your project is not well defined, probably too ambitious or completely unrealizable.
Fourthly, I would recommend to build a motivated team around your game.
This is a virtuous circle: when your motivation will decrease, they'll encourage you and when they'll get demotivated, you'll encourage them.
Nowadays, I believe that it's impossible to write a game alone, unless your game is very simple.
Find people who believe in your project and who may help you.
The performance reasoning may go away sometime soon. Microsoft has been working on a native compiler and has a preview for Windows Store apps. They've said they're bringing it to the full .NET platform. At which point you get all the performance of C++ with the benefits of a robust framework and a good language.
Three of us took that "Beginning Game Programming with C#" Coursera course. Two of us were professional programmers (myself a professional game developer) so we blew through the course; our third was a gaming buddy who wanted to try out programming -- he was an excellent gamer but had never done any programming. (Back in the day he had done a little shell scripting on Windows.)
The coursera is NOT a beginner friendly course -- it had two major problems:
* it teaches concepts in the wrong order, and
* doesn't explain key critical concepts at all, or extremely poorly.
My buddy dropped out after a few weeks because he just felt completely lost. We would spend hours going over concepts with him and he would get most of it. But when it came to the assignments he didn't have enough of the big picture and low level details to reason things out. IMHO there are better lessons out there, such as:
* http://www.codecademy.com/
* http://learn.code.org/hoc/1
Which is a shame too, because the professor is actually friendly, and has good intentions.
MOOCs are "famous" for having a 98% drop-rate. Seriously, like 20,000 students signed up. Very few made it to week 5.
Visual Basic went to .Net five versions ago. It was acceptable to take VB to mean classic VB in 2003, but in 2014, you have to say so if you mean the old stuff. The VB6 development environment doesn't even run on any supported operating system. VBA is still around, but it's always been incorrect to refer to VBA as VB.
I started by working with the Quake 3 engine and seeing what I could do to it. I wound up modifying the guns by adding new firing modes, modifying how the camera a little and learned how to add effects to the game.
Then I messed around with the trigger editor in Starcraft.
Then I messed around with the trigger editor in Warcraft 3 and made a lot more complex things, including implementing the character progression system from a single game from a popular Japanese RPG series -- which shall remain nameless -- in a tower defense map. (It was an awesome-bad project.)
What did I find? This taught me the basics of game programming as well as a lot of about algorithms. It made me a better programmer. Then I made some Starcraft 2 maps, one of which was a port of a Warcraft 3 map. Then I said fuck this, and took the RPG I started in Warcraft 3, moved to Starcraft 2, and I now have a 2D RPG game engine written from scratch for PC that is well beyond the progress of either of the maps it came from. I would argue you don't learn to program games in a language. You just learn the paradigms used to make a game work, and then apply that to a language. You want to learn? Do it. Books may help if you get stuck along the way, but do yourself a favor and stick to libraries if they exist. No one wants to draw their own fonts or write a PNG loader.
Although yes, you may learn some more about the language you're using along the way. I learned a lot about C++. Try to stick with learning to do things The Right Way (tm) and you will surprise yourself with what you learn. For the record, I wrote my own game engine because I wanted to learn how to do that. I sometimes wonder if I should have used a ready-made engine but the learning experience is massive, although I don't recommend it for everyone. I am quite insane.
Google.
I'm 100% serious. I learned C# that way and wound up writing the application code for a product that sells for about 5 million a year.
Here is your task, since you're interested in making games. Make a game of pong in C#. Use Google to look up how to do it. Start with a hello world program. Then make a program with a form. Then figure out how to paint to it. Keep going.
At the end of the pong game you'll know enough to be dangerous. Good luck!
Weaselmancer
rediculous.
It would be hard to make a programming language slower than Java, even if you tried.
1996 called and wants its Java insult book back.
Try Beginning Game Programming with C#
About the Course
The Beginning Game Programming with C# course is all about learning how to develop video games using the C# programming language. Why use C# instead of C++, Java, ActionScript, or some other programming language you may have heard of? First, using C# lets us use the Microsoft XNA and open-source MonoGame frameworks, which help us quickly develop games for Windows, Android, iOS, Mac OS, and others. Second, the Unity game engine is very popular with indie game developers, and C# is one of the programming languages you can use in the Unity environment. And finally, C# is a really good language for learning how to program.
Also sign up at Coursera. They have a course titled "Beginning Game Programming with C#" taught by the University of Colorado. The course also teaches basic C# syntax, so it's very beginner friendly. You just have to wait for it to be offered again before signing up.
If you really want to learn to program games, start with Lua instead of C# or C++. It's a tiny little scripting language that can be learnt in a few hours and is used by an enormous number of game development companies. Lua is often tasked with providing a UI for the game, logic flow, rapid prototyping of features, anything really except for the critical loops - which are all handled in C++.
Once you have Lua under your belt you should learn C++, because at the heart this is what all performance sensitive games are written in. The game engine will be a mess of tight, sometimes obscure C++. If you want to make changes that are at that level then you absolutely need to be able to write C++.
Finally, think about learning C# if it's supported by the game engine you have chosen to use for your game. It should perform about the same speed as the Lua code and it's used for the same tasks - game logic, etc.
Since you're a beginner, I'd recommend you go with either Unity or Unreal Engine as these are both easier to learn and have a lot more community support. Unreal Engine now comes with the complete source code in C++, so you can take a solid look under the hood and see what's happening in there. CryEngine is moving towards releasing more of their source code, but are not there yet.
Really your first question should be which language to learn, but which engine to learn. The engine will dictate which languages you need to learn from there.
All those moments will be lost in time, like tears in rain.