• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Idopik

C# - huh?

37 posts in this topic

I don't think I need to add anything to the discussion of C++ and C#, just that it all depends on your abilities, desires, need for balance and control, the usual generic response.

As for an IDE, I've switched from Dev-C++ to Code::Blocks (using the Nightly builds on the forum), for a little more control, more feature sets, and an IDE made using the langauge it 'advocates'.
As far as I know, there may be a possiblity for it to use C# (it does have support for D), but I honestly don't know

On the note of D, you could also try that. It's a relatively young language (began in 2002, I think), and I've seen some applications/libraries on various D repositories and on SourceForge. As far as how good it is for game programming, I can't formulate an opinion on it just yet. I still need to get into the language.
0

Share this post


Link to post
Share on other sites
Not to mention, that there is C++/CLI, which imho completely undermines C#, unless
you never learned C++.
0

Share this post


Link to post
Share on other sites
C++/CLI is great for porting legacy C++ code into a managed environment (eg, porting an old game engine so you can use it with C#).

It is sufficiently ugly and awkward to make writing fresh, new applications in it painful. [wink]
0

Share this post


Link to post
Share on other sites
C# for tools, C++ for games, is a nice rule of thumb.

I don't really advise *learning to program* games in C# if you want to get into the industry professionally - good luck writing a triple A title for the PS3, Xbox 360 and Wii in C#.

However, if you want to make an indie PC or XNA game or learn how DirectX works, it's quite nice. With DX being a lot about pointers and filling out data structures, you can get started faster in C#, and it's a bit more forgiving. You'll also find performance wise it's a lot better than Java.
0

Share this post


Link to post
Share on other sites
I still remember my high school C++ teacher saying that everything was going to be moving from C++ to Java, that still makes me laugh.
0

Share this post


Link to post
Share on other sites
Regarding C++ and safety --

It depends on what definition of 'safe' you're going after. C++ is not particularly type safe, in that it's a very weakly typed system. I can coerce any type to any other type in C++ if I want it badly enough. Then there's the trap of how easy it is to write code that suffers undefined or implementation defined behavior, both of which make it a rather unsafe environment to work in. Then there's the question of how safe it is with regards to basic operations without doing stuff like trashing your stack. Again, it isn't really, though there's a lot more you can do here than you could in C.

I'm having trouble thinking of anything that makes C++ "safe". I can think of things that make it safer than C -- but that's like thinking of things safer than dousing yourself with kerosene and then playing with matches.

You need to learn C++ eventually if you intend to make any progress in game programming as a profession. That doesn't mean you need to learn it immediately. C# is a great language, but there are various problems keeping it from being adopted in The Industry (tm). Those problems mainly involve platform support, legacy codebases, and developer training.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by fsm[...] you can get started faster in C#, and it's a bit more forgiving. You'll also find performance wise it's a lot better than Java.


What data are you basing this on?

I'm asking since I've only seen benchmarks that concludes the opposite, like this one.
0

Share this post


Link to post
Share on other sites
Ugh, not another "he said, she said" benchmark pissing contest. It all depends on your code, the compiler, the runtime, etc.

Regarding everyone "switching from C++ to Java", I think Java was held back by the awkwardness of using native code with it. With C# and the CLR, that was rectified by allowing easy interop with native libraries, making a transition more likely (though, still slow with library-lag).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by benryves
It is sufficiently ugly and awkward to make writing fresh, new applications in it painful. [wink]


I think you should update your knowledge about C++ in the .NET environment, as Managed C++ is no more...
Even Stroustrup himself praises C++/CLI's design, altough he doesnt like its non-ISO C++ keywords and Microsoft dependency.
Maybe you should just compare C++/CLI examples versus C# examples on MSDN...you might be up for a suprise.
Actually, have you ever used VS2005? :)
0

Share this post


Link to post
Share on other sites
Quote:

think you should update your knowledge about C++ in the .NET environment, as Managed C++ is no more...

He was talking about C++/CLI, and he's right. It's pretty ugly to work with. C++/CLI also has a ECMA standard, incidentally; it's its own language.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by guardian24
Even Stroustrup himself praises C++/CLI's design, altough he doesnt like its non-ISO C++ keywords and Microsoft dependency.
Stroustrup designed C++, which raises some serious questions about how many pounds of salt to carry when listening to him talk about language design.

Having done more work in C++/CLI than I ever wanted to, I can honestly say that I hate this language and pity anyone else working with it. It takes the insanely complex beast that is C++ and makes things even worse. It doesn't help that the compiler emits worthless and irrelevant error messages for many common mistakes.
0

Share this post


Link to post
Share on other sites
Well OK, but maybe you should demonstrate its "ugliness" and "makes things even worse" thingy. Imho its "nice" :), and there are many positive reviews on the internet.
I dont think that this is ugly:

interface class I {
};
delegate int ClickHandler();
ref class M : public I {
event ClickHandler^ OnClick;
public:
property int Num {
int get() {
return 0;
}
void set(int value) {
}
}
};


Where is the ugliness, comparing to C#?
You could surely show some examples...
0

Share this post


Link to post
Share on other sites
Quote:
Original post by guardian24
Where is the ugliness, comparing to C#?
It's in your hideous code formatting [lol]

For the most part, the language itself does not *look* bad. Neither does C++, for that matter, unless you're playing with the more convoluted depths of it. It's the sheer complexity of things, and the mass of finicky details that really complicate things.

For example, consider destruction.
ref class Foo
{
public:
~Foo() { Foo::!Foo(); }
!Foo();
};
So we've got a destructor, which more or less behaves like a destructor. And then we've got this extra thing tacked on, which is the finalizer. The destructor implementation, in turn, explicitly calls the finalizer. These get remapped into the disposable pattern. Foo implements IDisposable, and two methods are generated, Dispose() and Dispose( bool disposing ). Finalize() is also generated. Those methods call the destructor and finalizer as they see fit. GC.SuppressFinalize is magically called for you at some point as well. The compiler emits more calls to these functions around your code as needed. You now use delete obj; instead of obj->Dispose(), and destructors are also chained automatically per C++ rules -- which of course means that you need to mark your base class destructors virtual like in C++. Oh, and you're not allowed to explicitly implement IDisposable. In other words, this is illegal:
public ref class Foo : IDisposable
{
public:
virtual void Dispose()
{
}
};
Another example. Every variable can now be a value, a pointer, a reference, a handle (managed reference) or a tracking reference(ref/out in C#) to one of those things. You can form a reference or a pointer to any of the first four, but the reference will show up as a pointer when exported with an attribute, and who knows how other languages consume that. You can form a handle to any ref class, but nothing else. And boxing gets involved somewhere in there, allowing you to have boxed handles to value types. Don't forget NULL for pointers but nullptr for handles. You can pass anything as a tracking reference, but you have to use the [Out] attribute to differentiate between what C# calls 'ref' and 'out'. I also noticed something about some "take-address" operator, but really just didn't care. All that only applies to managed classes; native classes and structs can't be exposed as values. On top of that, you can take pointers to things inside managed objects, but only by using pin_ptr and interior_ptr, which are pseudo-template pointer types that the compiler inherently knows about. Then you've also got the pseudo-template array type. So some of the syntax here:
array<Byte>^ data = gcnew array<Byte>(100); //gotta use gcnew. Can't use ^ on the rhs.
pin_ptr<const unsigned char> pinnedData = &data[0]; //automatically unpins via RAII. And make sure you put const in the right place!
array<array<MyClass^>^>^ local; //whoo jagged array


For more fun, look into any of the following:
* String literal handling (when is it a char*, and when is it a String^?)
* Casting behavior, safe_cast, and what the compiler does with C style casts
* Context sensitive keywords -- I can happily name a variable 'delegate' if I want!
* Explicit overriding
* The rules for mixing generics and templates, and metadata for managed templates
* The myriad of rules for what you can and can't do with tracking references
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0