• 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
Intrawebs

Why C# XNA When Everyone Wants C/C++

165 posts in this topic

I started with HTML when I was 15, and I sucked at it. In my defense, in those years everybody sucked at HTML.

When I turned 16, I starting poking at javascript, because it let me do things with my web pages that were fun and cool. At the time, no two browser executed any javascript the same way, and some individual browsers wouldn't execute it the same way in two sessions anyway. With a lot of hacking I figured out how to swap images around and had just enough performance to make an 8x8 scrolling tile map. 10x10 was asking for trouble, it would bring my 266MHz PII to a crawl, and if I accidentally wrote an infinite loop I would sometimes have to power off the PC in order to fix it. I thought I was the bees knees. I figured out how to use an IFRAME as a communication stream with a backend server, thereby creating the fundamental framework for what we now call AJAX. Nobody wanted to see it. It was javascript and therefore the devil incarnate.

When I turned 17, my parents bought me a C compiler (Borland C 4.52!) for Christmas; I didn't know about GCC at the time and its Windows support sucked anyway. They only knew to buy it for me because I asked, and I only knew to want it because people here at GDNet were talking about it (yes, I've been here *that* long). My dad didn't want me to install it right away, he wanted to install it because he was very protective of his computer. I didn't listen and just waited for him to fall asleep on the day after Christmas and did whatever the hell I wanted. In very short order I destroyed my parents' computer, thereby proving to my father that I should never again be trusted with his computer alone. It would be a full year until I had my own computer, and my father helped me pay for it because he was sick of me breaking his. Windows 95 wasn't very good at protecting the machine from errant programs. I eventually stopped crashing the computer and started writing some simple Rogue-likes. Half of my classmates in my freshman year of college were playing a Rogue-like I had written, making maps for it with the included map editor, and generally crying at me until I agreed to tutor them so they would pass their classes. It wasn't that I was any good at C, it's just that I was better than anyone else at the time (or at least for our area).

When I was 18, Penn State University no longer cared about C and tried to make me a C++ programmer, and I sucked at that, too. Templates did not exist at this time. Mostly, I sucked because compilers at the time sucked, there was no reliably standards compliant C++ compiler at the time, so it was just easier to default to C. Plus, Borland shipped with a proprietary library that supported printing in color in the console and using the PC beeper speaker. I couldn't make games like Rogue in C++, so I did the bare minimum to pass my classes, which often turned out to be "C in C++", which didn't matter anyways because that's how everyone did it.

When I was 19, Shippensburg University tried to make me a Java programmer, and I hated it until I learned to stop fighting it and figured out how to actually use it, and then I loved it. I was extremely successful in my junior and senior years because I would always volunteer for the graphics programming tasks in our group projects (nobody else wanted them anyway), and I could wrangle Java2D better than anyone else in the department. I built up my own library of code that got reused in all of our projects, and boy howdy, nobody was ever waiting on me for tasks.

When I was 21, against the wishes of my professors, I became a "Microsoft shill" and taught myself C#, which was easy because I knew so much Java. This was perhaps the single best decision of my college career, I got a job directly out of college because I was the only graduating senior the company interviewed who knew any C#. Unfortunately, it cost me my soul, if my professors are to be believed. I don't care, I make a lot of money at it.

When I was 25, after years of programming in nothing but Java and C#, having not touched any significant C++ since my PSU days, I found that I was a LOT better of a C++ programmer. Seriously, I hadn't written a major project in it in 6 years, and I hadn't touched it *at all* in 3 years. One day I decided to "visit an old friend", picked it back up, and was writing programs in it in a matter of hours that would have taken me months before. It felt yucky, I missed C#, I wondered how I lived with C before.

None of the languages I had learned to that point had prepared me for stuff like SQL or Prolog *at all*, and I had to completely relearn how to program when I started doing non-trivial javascript (JS is more appropriately a functional language than a procedural language, and its object oriented idioms are unlike the C++/Java/C# world OO idioms). I'm learning F# now to maybe incorporate it as a scripting system into a project I'm working on right now (which includes 3D rendering in C#). I wish Python were more popular and more readily available when I was first starting, I think I would have progressed faster if I had started on something other than C. I wish I had more time to learn stuff like Lisp and Ruby. I wish I had never learned VB at all, because it only turned out to be a resume bullet point that got me dragged in to too many crappy projects. I've made money doing PHP and Perl (I never did like PHP) and JSP (whoa, talk about mind fuck after only ever doing AWT and Swing apps in Java) and ASP 3.0 (I still have nightmares) and ASP.NET (meh, whatever, I'd rather be doing desktop apps) and Oracle PL/SQL and MS Transact SQL (big differences there), and I even once hacked some COBOL that the state had lying around that was suddenly going haywire because of Y2K.

I don't even consider myself very wide in my knowledge of languages. If all you're worried about is learning C++, you are seriously behind the curve.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
I don't even consider myself very wide in my knowledge of languages. If all you're worried about is learning C++, you are seriously behind the curve.


Behind? At or ahead I would say. I've done all that you have mentioned, and I'm bored and getting little/no challenge at work (C# and MOSS 2007). Anyway, it's not just learning "C++", it's learning "game dev with c++". I did C++ 7 years ago at uni and sold out to MS as well, and it paid off as well. My heart isn't behind it currently, hence moving to gamedev and wanting to be marketable.

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Daaark
Quote:
Original post by DevFred
Do you mean correctness? Bugs in games don't do much harm, whereas in other areas, they can result in catastrophies.
They harm the bottom line. They harm customer confidence.

If you buy 2 games in a row from a company whose main menu's crash you to the desktop without even an error message, you're not likely to ever buy another game from them!

Bugs in games hurt both the customers and the developers.


But I think he meant Catastrophes and Harm in Real Life, like plane crashes, meltdowns, or a car rolling over a person because of a bug in the brake system. Or maybe just a bug in a finance software causing a stealthy 1% loss each day. Or something else from RL.

edit: Something like this, I think he meant.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Intrawebs
Quote:
Original post by capn_midnight
I don't even consider myself very wide in my knowledge of languages. If all you're worried about is learning C++, you are seriously behind the curve.


Behind? At or ahead I would say. I've done all that you have mentioned, and I'm bored and getting little/no challenge at work (C# and MOSS 2007). Anyway, it's not just learning "C++", it's learning "game dev with c++". I did C++ 7 years ago at uni and sold out to MS as well, and it paid off as well. My heart isn't behind it currently, hence moving to gamedev and wanting to be marketable.

Your boredom is a function of who you work for and what projects you're working on, not what language you're doing them in.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
Your boredom is a function of who you work for and what projects you're working on, not what language you're doing them in.


Exactly....the projects I'm working on are boring, as well as who I'm working for. Hence once again wanting to do game dev. And once again needing to learn c++ to be truly marketable. I'm I totally missing something here or are some people not really reading what I post?
0

Share this post


Link to post
Share on other sites
Learning how to be a 1337 C++ programmer and learning how to program a game are two rather orthogonal topics. The important bits of game programming utilize data structures, patterns, and techniques that are largely the same no matter what underlying language you program them in. The difference is that in a certain languages most of them can be implemented more quickly, thus allowing you to learn how to use them more quickly.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
Learning how to be a 1337 C++ programmer and learning how to program a game are two rather orthogonal topics. The important bits of game programming utilize data structures, patterns, and techniques that are largely the same no matter what underlying language you program them in. The difference is that in a certain languages most of them can be implemented more quickly, thus allowing you to learn how to use them more quickly.


Very true. I read your article just now on undo/redo. Trying to do your original solution in c++ vs. c# would take you twice as long (xml serialize/deserialize).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by noe
If company has C++ programmers it can do games for PC, Mac, consoles, handhelds, well for every platform that has C or C++ compier which in practice means for every platform there is.


Except close to any mobile platform, where games have to be in objective-c (iphone) or mostly in java. only on windows mobile, you can really think about c++ development (and i still wouldn't, c# is just too nice :)). on the zune, another mobile platform, you only have xna/c# as a public option.

it always depends on your targets. just be aware that c++ on consoles is completely different to c++ on pc's.

i personally never use c++ on pc's anymore. i did, years ago, fighting against c#.. :)

still, in the end, language is unimportant.

btw, to the performance croud. i did the raytracing in c# and raytracing in c++ thingy. i actually got similar results on both (without leaving the c++ world itself and going into the simd world), and the c# code was still much more clean and simple to manage..
0

Share this post


Link to post
Share on other sites
Quote:
Original post by davepermen
btw, to the performance croud. i did the raytracing in c# and raytracing in c++ thingy. i actually got similar results on both (without leaving the c++ world itself and going into the simd world), and the c# code was still much more clean and simple to manage..


The only problem being that some of us don't find your performance claims reliable. Please provide Benchmarks (for commonly used types of scenes), Statistics, Sourcecodes.
0

Share this post


Link to post
Share on other sites
Although this discussion was somewhat heated, it inspired me to think about porting my engine from C++ to C#.

However, I have some question regarding to which extent you would do this:
I'd use OpenTK as a C# OpenGL binding but on their website they state that calling OpenGL functions in C# is a bit slower that via C++ due to the overhead of transitions from managed to unmanaged code and back (C# binding to driver and back [smile]).

Also, I found this blog where the diagram states that the graphics engine would/should still use compiled (unmanaged?) code.

So, my question is: Would you port the entire engine to C# or the better part of it, leaving the graphics subsystem in C++ (or maybe more generally everything that needs to communicate with the driver many times a frame - like OpenGL calls: draw calls, state changes, binding objects [Texture, VBO, FBO etc.], setting shader parameters etc.)?

Thanks in advance.

Thomas
0

Share this post


Link to post
Share on other sites
Quote:

However, I have some question regarding to which extent you would do this:
I'd use OpenTK as a C# OpenGL binding but on their website they state that calling OpenGL functions in C# is a bit slower that via C++ due to the overhead of transitions from managed to unmanaged code and back (C# binding to driver and back ).

Also, I found this blog where the diagram states that the graphics engine would/should still use compiled (unmanaged?) code.

So, my question is: Would you port the entire engine to C# or the better part of it, leaving the graphics subsystem in C++ (or maybe more generally everything that needs to communicate with the driver many times a frame - like OpenGL calls: draw calls, state changes, binding objects [Texture, VBO, FBO etc.], setting shader parameters etc.)?

I think you should really make a new thread to discuss this, it's way off topic. In brief, yes there is a minor cost to crossing the native/managed barrier, and as such it is often better to do it as little as possible, but by leaving only your renderer in native code you may end up making that transition a lot more than you would if you ported the renderer and only made the transition for the low-level API work (what OpenTK does). It depends. I suggest you create a new thread.
0

Share this post


Link to post
Share on other sites
Quote:

Then why do all the big name developers use C++? Or maybe that isn't true? Maybe you can point out some larger development houses that use a different primary language.

Are they a bunch of masochists who like to make things harder for themselves (since C# and other languages are more readable)? Are they just stubborn and set in their ways? There has to be a reason everybody uses C++, and if it is not speed, then what is it?


So I thought I'd jump in on this discussion, and I'm going to preface my response by saying "Save your hate/flame responses about WildTangent for another thread, this thread is about technology, not business."

That being said, I worked for a company called WildTangent for many years. Back when they were a technology company they had an ActiveX graphics engine with a Java interface which was designed to be a flash competitor that anyone could use (we're talking 2000'ish dot-com stuff here.) Our engine, being ActiveX was C++, but all the games were written entirely in Java, a managed language. There were performance penalties for calling through the COM layer, but the rendering on the C++ side, and the game logic on the Java side worked just fine. We wrote a Tony Hawk Pro Skater 2 port "Skatepark Sessions", a "Need for Speed" port, among other games with all the game code in Java... a managed language, and they ran great.

We also solved the C# "issues" around garbage collection and memory management of C++ engine objects when I was there last year. Our C# games ran with ample speed (~1000fps for a racing game with vsync off of course.)

These days, whichever language you choose, I'm pretty sure from personal experience, you can make a viable game with it, from an academic level.

But that's academics, and you're talking "big name developers" which is business. There's development costs which can be offset by using pre-existing company tech, and there's target market issues, where C# doesn't work on PS3 or non-MS devices.

The WildTangent Webdriver as a graphic engine, failed because Microsoft lost the Java war, and XPSP1 made ActiveX objects "scary" to the common user by popping up enough dialog boxes and yellow bars and page reloads to dissuade the user from jumping through all the hoops. From a business perspective, you don't want to write tech, that another company can pull the rug out from under you on. You probably don't want to ship the CLR/JIT interpretor to run your game, in the case that your end user doesn't have the version you need pre-installed. That leaves you with C++.

It's a mature language with the least dependencies on external companies. It's the most portable among devices, and that leaves you with flexibility to target PS3/Xbox360/Wii etc... without too much re-engineering. It makes a LOT of sense as a language of choice for big name developers to use.

Is C# bad to use? Heck no, but in the world of business, targeting more than just XBLA is where it's at.
0

Share this post


Link to post
Share on other sites
In these kinds of topics people generally only want to read what they believe. The OP is convinced you have to be a C++ wizard to get any kind of game programming job and several people have backed him up on that. The OP has heard what he wants to and if you make this topic 10 more pages praising C# its not going to change his mind.

As to the topic, I'm not in to trying to create the next super FPS. So whatever "speed increases" C++ has over C# is pretty much overshadowed by the benefits of a managed language.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by davepermen
Quote:
Original post by noe
If company has C++ programmers it can do games for PC, Mac, consoles, handhelds, well for every platform that has C or C++ compier which in practice means for every platform there is.


Except close to any mobile platform, where games have to be in objective-c (iphone) or mostly in java.


Our iphone games are written in C++, with various necessary Obj-C(++) wrappers in order for it to run on the iPhone. The back-end (rendering, gamelogic, network interfaces, etc) are all written in C++. The only exception is when we have to use the Obj-C / NS* objects in order to do something iPhone specific (think finding the path of a file to load). But then that's also nicely abstracted and hidden away.

So, no, C++ does not keep you from working on mobile apps, especially not iPhone :)

Quote:
Original post by davepermenjust be aware that c++ on consoles is completely different to c++ on pc's.


Er - what are you talking about? I've worked on consoles, mobile platforms, PC - and the C++ has remained consistently the same all 'round. All that changes is the hardware and the assumptions you can make based on said hardware.


0

Share this post


Link to post
Share on other sites
Quote:
Original post by capn_midnight
When I was 18, Penn State University no longer cared about C and tried to make me a C++ programmer, and I sucked at that, too. Templates did not exist at this time.


You can't be that old. I remember you posting about college in 2000, so even if you entered school in 97, making you 18 then, then templates still existed at that point. C++ Builder 1 came out that year, and I know for sure that it had template support, and we used gcc with templates for my data structures class that year as well.
0

Share this post


Link to post
Share on other sites
This thread's run its course. If you want to keep talking, consider making a new thread specifically about what you're trying to discuss. Remember that C++ vs C# on its own is still off limits.
0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0