Programming games in C#?

I read on another website that some “real” game development was being done in C# which was news to me. I have been writing business apps in C# since it was in Beta, but of course, I’m a gamer at heart. Since I have not/will not have the time/drive to learn C++, off to Amazon I went. There are a variey of books on C# and gaming which interests me. I am realistic enough to understand what that I am not going to be writing a marketable game anytime soon, but I would still love to toy around with it. Furthermore, it seems realistic to me that the types of games I like most (strategy and RPGs) would be more manageable to dork around with than a shooter or flight sim, or something along those lines.

So with that in mind, can some of you with experience give me a point in the right direction as far as books/websites? I have done simple games (text based, dice games, stuff like that) and would like to do a simple RPG, perhaps with simple graphics (In my mind I am seeing the original "Bard’s Tale and thinking something on that level should be manageable)… What would be some good resources for getting started? I have hardware to develop on and VS.Net, and I can buy other stuff as needed…

I apologize if this has been covered before, but closest thing I could search up was this: http://www.quartertothree.com/phpBB2/viewtopic.php?t=11233&highlight=c which had some useful info, but not quite what I was looking for.

Before you get too deep into programming, you should spend a little more time on game design. If you are going to develop an RPG, you should at least have a clear idea of the rule set and graphic style you want to use. There is a pretty broad spectrum between simple (e.g. web-based) graphics and professional (e.g. animated 3d) graphics, and you will need to master different technologies depending on where in that spectrum you fall. Of course, if you are using C# and you don’t want basic web forms or windows dialogs, you are probably going to have to deal with DirectX 9 Graphics. Downloading the DX9.0c SDK from Microsoft wouldn’t be a bad place to start tinkering around…

–milo
http://www.starshatter.com

.

As for as books are concerned, check out Programming Role Playing Games. Though not C# specific, it is CRPG specific and gives you a fundamental understanding of the basic objects of game design: state machine, game loop, 3D graphics, etc. I recommend it highly.

If you want to slum a little lower, you can download our open source RPG RuneSword on SourceForge. It’s around 45,000 lines of code in VB. Point being: I wouldn’t do an CRPG for my first major game. It’s an enourmous project and maybe even deadly for a one man team. I’ve done it 4 times now and each time I say “never again.” Truly a multi-year effort.

But I’m a nut, obviously, and you might be too. If a CRPG is in your heart, go for it.

I can’t think of a reason not to write in a managed language (and using the Directx managed wrapper!) if the distribution model can handle including the runtime (20 megs) and you can take the performance hit (no shooters). It’s much, much cheaper to write anything covered by a managed language feature set in a managed language, games included.

C++ is going to head the way of assembler at some point in the not-too-near future.

If you do start anything and in need of help I would be happy to join.
Mind you, I know C#, but I am not a professional programmer. Still I Guess I’m better then no help at all.

I recently did some stuff in C# using DirectX (DirectInput Action Mapping). The main problem that I experienced that may have been cleaned up in the very latest Summer 2004 DirectX release is that the documentation for the Managed DirectX used by C# just blew.

Also, you don’t have DirectShow or DirectMusic in Managed DirectX.

And as Jason says, you’ll take a small performance hit.

But download the entire Summer 2004 SDK and play around a bit.

C++ is still going to be around for a while. (Not that I like the language – there’s plenty about it I don’t like. But it’s going to be around for a while.)

But, if you’re a beginner and aren’t working on a serious huge game, then yeah, some other language like C# might be better to start with. You have to beware of all those “programming games in C#” books though, because by definition the authors of those books are pulling stuff out of their ass. There’s basically no quality control over who writes game books – it’s just whoever proposes one, and if it sounds good to the publisher, hey.

Your best bet is to get a language-neutral game programming book or a few, and also some references about whatever SDK you’re using (like managed DirectX), but web sites might do just fine for that.

XPav points out that DirectShow and DirectMusic aren’t supported by Managed, but I should add that these APIs have been deprecated so they won’t even be supported non-managed in DX10. (DirectShow has always been a gigantic piece of crap, and DirectMusic never really did enough, or did it the right way, to justify its existence). So you don’t really want to use them, no matter what development paradigm you’re participating in.

Since this thread seems destined to degenerate into programming geekdom anyway, does someone want to summarize or otherwise point me to resources which point out the major structural differences between C++ and C#?

Given that I’m finally really starting to think about moving from C to C++, I have the odd fealing that C# will be entirely too namby-pamby and “friendly” for me to even consider using it ever, but I’m still interested in the differences.

Bah, choice of language is just an exercise in syntax mastery. Really it’s the underlying structure of the code that matters. I guess the question is whether you’re trying to pick a language for personal projects, or if you’re intending to use it as a way to get into an established company. If it’s the former, you can use whatever you like since it’s the end product that matters. If it’s the latter, C++ is the “safe” language to learn.

  • Alan

Gams are best modeled using Karma physics and high resolution, with some nice photorealistic multitextured skin. With a little effort you can create highly realistic and fun gams.

OH! I’M SORRY, DID YOU MEAN GAMES?!

Since this thread seems destined to degenerate into programming geekdom anyway, does someone want to summarize or otherwise point me to resources which point out the major structural differences between C++ and C#?

C# and Java are basically two different variants of Modula 3 expressed in syntax that is similar to C++. ;) I have a fair bit of Java experience, but only a touch of C#. In a nutshell:
[ul]
[li]Compiles into machine-independent language-independent code which runs in a managed execution environment.
[/li][li]Garbage Collection coupled with the elimination of pointers (in C# restricted use is permitted within code marked unsafe)
[/li][li]Powerful reflection (i.e. run-time typing) capabilities
[/li][li]No header files, all code scoped to packages or assemblies, no problems declaring one class before another with circular dependencies
[/li][li]Classes all descend from object and must be allocated on the heap with new keyword
[/li][li]Thread support by putting a lock on objects when entering code marked as locked/synchronized
[/li][li]Interfaces, with multiple-inheritance of interfaces, single inheritance of implementations
[/li][li]Inner classes
[/li][li]No concept of inheriting a class with a specified access level
[/li][li]No global functions or constants, everything belongs to a class
[/li][li]Arrays and strings with lengths built-in and bounds checking
[/li][li]The “.” operator is always used, no more ->, :: operators
[/li]null and boolean/bool are keywords
[li]All values are initialized before use
[/li][li]Can’t use integers to govern if statements
[/li][li]Try Blocks can have a finally clause
[/li][li]No compile-time templates, generic types are being added to the CLR
[/li][/ul]

Bah, choice of language is just an exercise in syntax mastery.

I disagree. Different programming languages have different levels of semantic abstraction that are far more important than any syntactic differences. Functional languages like Miranda and SML/NJ let you express abstract concepts in a completely different manner compared to low-level procedural languages such as C, Pascal, or Fortran.

For example, here is the quicksort algorithm expressed in Miranda:


sort [] = []
sort (a:x) = sort [ b | b <- x; b <= a ]
             ++ [a] ++
             sort [ b | b <- x; b > a ]

This is not just syntactically different than the same algorithm expressed in C; it relies on a list selection abstraction that has no parallel in the C language.

–milo

[size=1]EDIT: List formatting[/size]

More to the point, there’s no auto-conversion from anything to boolean, which means the stupid old C/C++ trick “if (0 == foo)” to avoid unintentional assignment is no longer necessary.

Also, you can switch/case on strings (which is very fast thanks to “string interning”), and there’s no preprocessor (there’s conditional compilation but no “macro functions”).

Anyway, as to the original poster who already knows all this stuff as he said :) : I’m not aware of any C# specific game programming books but you’ll almost certainly need Managed DirectX for what you’re planning. I’m making a 2D hex-based wargame engine with GDI+ – that works but it’s just barely fast enough, and I had to pull all kinds of tricks to get a decent rendering speed.

Well, maybe you think some other language is better… The main problem with managed languages and other higher level languages when it comes to games is probably the unpredictability of garbage collection. GC generally makes memory management easier, but in some cases it can actually be harder (and it doesn’t eliminate memory leaks either). Shooters is one example, but any game where interactivity is important might be affected.

I actually consider C#/Java as low level languages in many ways. I think it might be better to use Python/Lisp or similar languages as a beginner. For games I’d say Python is a good choice, I tried the pygame library and it was really nice. Compared to both lisp and C# Python might be really slow, but when it comes to simple games the CPU time required for game logic is pretty small.

Although C++ certainly is no requirement to make games I still think that you understimate the problem. Learning yet another language is hardly a problem compared to the difficulty of programming a reasonably complex game. If you aren’t prepared to spend time on learning C++ you probably won’t be prepared to spend time actually completing a game either. Even though the main part of your game is written in a high level language you might still have to do some part in C++ for perfomance reasons, so knowing it is definitely good.

I don’t think it’s possible with C# yet, but you can compile Java to machine code if you want. In any case, this is not really related to the language itself.

I guess I have only used compilers which warn about this problem, so I have never used the “backwards” notation. The trick doesn’t work with (foo1 == foo2) either.

I agree that Python with pygame should be a viable choice. However, if you want to use Lisp you must make sure that all required functionality on your target system is conveniently accessible. Interacting with anything but plain ASCII text tends to be a big problem for Lisp implementations.

Also, while I agree that Lisp is a higher-level language than C#/Java I’m not sure why you would put Python in a different category – from what I’ve seen it’s your basic Java clone with some Lisp features tacked on. (Though I like this pragmatic approach, don’t get me wrong!)

Although C++ certainly is no requirement to make games I still think that you understimate the problem. Learning yet another language is hardly a problem compared to the difficulty of programming a reasonably complex game.

While I agree in general I strongly disagree on the particular language. C++ is an incredibly complicated mess of a language, and mastering all its details is much harder than with a relatively cleanly designed language like C# or Java.

Also, difficulty of learning is just one thing; another thing is the difficulty of using a particular language. C++ is both hard to learn and hard to use (cryptic STL compiler errors anyone?). Like I said above, switching from C++ to C# gave me an incredible productivity boost, and that’s very important for a one-man team.

I think it’s only a matter of “when” not “if” C# will become a good platform for game programming. The problem right now is the .NET runtime is not a standard part of Windows, and until it is, it makes download (for web-based games) or installation a necessity, which will most likely cause all sorts of problems.

However, if you want to “learn” C# by programming a game, I think that’s a great idea. I think C# will be a much more marketabkle skill in the next 10 years than C++.

I’dcheck out all he new stuff on design patterns. Thely the “Singleton” and “Observer” patterns are especially useful for game programming.

For game design, I’ll always fall back to the genius of Chris Crawford. We had him come in and speak 2 weeks ago and he was, excuse my language, fucking brilliant.

Python IMNSHO is a good choice, and pygame is an easy to use wrapper around SDL and/or OpenGL. I’ve found Python to be more productive than either Java or C#. Python is also plenty fast enough, and not nearly as slow as most programmers expect. I saw a demo by a guy doing Nuclear Physics simulation, IIRC he generated optimized python code with speeds better than half as fast as hand written C. It’s easy to convert any bottlenecks you might have to C, and for cpu intensive things like graphics this is mostly already done by a library and/or hardware. For a strategy/RPG game this is moot however, as you won’t need to do any such optimization.

And there’s Psyco to make it even faster.

Managed languages will take over because memory management and unnecessary use of pointers is just too expensive to develop with. You can write anything you want in C++, but it’ll cost you more for the apps being discussed here.

As to “unpredictability of garbage collection”:

Q: What happens in a C++ system that runs out of memory?
A. It does an linked-list compaction algorithm that locks up the runtime until it’s done. As a bonus, if memory is too fragmented for it to be able to execute (surprisingly common with long-running systems), your application dies, basically.

Non-pausing GC is a mild annoyance, by comparision.

Err, I’ve never seen that C++ behavior before. Is that part of the C++ standard or just Microsofts implementation of C++?

It’s been a while since I looked at this, but that was the state of the art a few years ago. Really, if you think about it, the C++ runtime still has to garbage collect eventually - it just defers it until you really run out of memory. On a sufficiently complicated application, you’re going to have to write your own damn mini-GC by faking OS memory pages, always requesting even-sized blocks, blah blah blah; why not have the language do it for you?