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

How many of you use C for game programming?


108 posts in this topic

I'm very curious. I use it myself because of its simplicity and less haggling with accessor functions, member access, etc. Though many may not agree with me. I'm just curious about what people's take on this is.
0

Share this post


Link to post
Share on other sites
[quote name='francoispress' timestamp='1295843589' post='4763738']
I use it myself because of its simplicity and less haggling with accessor functions, member access, etc.[/quote]If that's your problem with C++ (or OOP?), then you're using C++ wrong.

I voted sometimes -- I mostly only use C for gluing different systems/modules/languages together.
1

Share this post


Link to post
Share on other sites
You're missing an option "Hell no!"
Seriously, after working with std::string and the other STL containers it's hair raising annoying having to resort to C instead of C++. I sometimes have to at my work place and I'm glad if I can keep the C parts short.
0

Share this post


Link to post
Share on other sites
I occasionally dip into standard/ANSI C, but only rarely. I much prefer C++ for things like RAII because as Endurion mentioned it really helps avoid certain classes of nasty problems.

Which is not to say I have any love whatsoever for C++.
0

Share this post


Link to post
Share on other sites
Only in C. Because I only know C. And I like it, I like "immediate mode" style, and that I can tinker the shit out of it.
But I'm not by any means a programmer.
0

Share this post


Link to post
Share on other sites
I tend to stick to higher level languages so C++ is rather nice especially when using boost. I don't tend to use inheritance in languages so I can see where C looks nice. The main problems I have with working in it for extended periods is string functions and lack of standard containers. I'd need to a really valid reason to choose C or C++. I can do anything in C++ in C so there's no real advantage for choosing C. Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.
0

Share this post


Link to post
Share on other sites
Got forced to for a month or so once - found lack of destructors for RAII the most annoying part. In some ways, I tended not to be as guilty of over-engineering when using C, but equally projects were far more brittle and buggy.
0

Share this post


Link to post
Share on other sites
I use C for some of my game programming. Mostly this is because it's one of the languages I'm strongest with, it works well if I plan the architecture in advance and I'm better at debugging C than some other languages. Libraries are easier to use too. Downside is the lack of namespaces and the need to find libraries to do basic things like working with strings (although if I'm doing a lot of string work I'd use another language like Python).
0

Share this post


Link to post
Share on other sites
I sometimes use it for small development tools, for instance a small command application that converts one binary format into another, but that's it.
0

Share this post


Link to post
Share on other sites
[quote name='francoispress' timestamp='1295843589' post='4763738']
I'm very curious. I use it myself because of its simplicity and less haggling with accessor functions, member access, etc. Though many may not agree with me. I'm just curious about what people's take on this is.
[/quote]


I have this crazy idea sometimes that I want to program in C so at one point I rewrote my latest project to C. I may go back at some point but I am thinking that if I need a high level language I would embed Lua instead of using C++.

I was thinking about what you say about accessor functions. You don't have to use them in C++ and you can, and sometimes should, have them when programming C. But it was quite a relief to get away from idiomatic C++ and just solve the problem. But this limitation is just our heads.

I also think C is quite fun. It is nice to find different solutions to the problems. But having to write container classes is a mess. It takes a few iterations to get them right. I know I am talking against my last paragraph where say "just solve the problem" because I would get some stuff done faster if I would stick to C++ and code with an open mind.

Also C code compiles a lot faster than C++. I think 2 or 3 times faster!
0

Share this post


Link to post
Share on other sites
I use C++ at work, but like to write my personal game projects in C. When I write code in C, I tend to put the data first and be a little more pragmatic about architectural decisions. I don't waste time on building complex class hierarchies with the intent of reusing them again - I just make the damn game. C is also a lot easier to bind to other languages like Lua, Python, or Mono, and in those languages you can do all the OOP you want. C is also a little easier to throw on an SPU.
0

Share this post


Link to post
Share on other sites
I avoid C like the plaque. It doesn't have anything that C++ has like templates, smart pointers, containers, string classes, etc. I personally C a waste of time anything above system/hardware level.
0

Share this post


Link to post
Share on other sites
[quote name='Tachikoma' timestamp='1295885819' post='4763935']
Yes. For an iOS game.
[/quote]

iOS uses Objective-C ;)
0

Share this post


Link to post
Share on other sites
[quote name='Seaßourne' timestamp='1295891218' post='4764011']
[quote name='Tachikoma' timestamp='1295885819' post='4763935']
Yes. For an iOS game.
[/quote]

iOS uses Objective-C ;)
[/quote]

To be clear, the iOS APIs are written in Objective-C, but your game code doesn't have to be. You can mix C and C++ with Objective-C very easily.
0

Share this post


Link to post
Share on other sites
Never, I see very few advantages in using it. If accessors are a pain then just make the variables public.
0

Share this post


Link to post
Share on other sites
Well, I can work pretty fast with C. Reusable (or easily modifiable) stuff has been gathered through the years of coding. Okay, I usually don't give a shit about nice design (and I'm too lame to go multithread). I need stuff to load? A global 1million sized array! I need a flag or a state variable? A global variable, huhhh
0

Share this post


Link to post
Share on other sites
[quote name='Sirisian' timestamp='1295859309' post='4763797']
Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.[/quote]


If you need to cast, then you're trying to compile a C program as C++. My favorite idiom is:[code]
Type *var = malloc(sizeof *var);
free(var);[/code]
This is less brittle, more readable, and the compiler will tell you if there's no prototype for malloc(). I don't know how relevant that last part is anymore. Maybe it could cause a problem if sizeof(int) isn't the same as sizeof(void*)?

But, I still agree that there's not much use for C in game programming. The only place I could see using it would be as a lighter choice than C++ to drop down to from a higher level language, whether for speed or gluing bits together. In those cases, I see myself using mostly the C subset of C++, and C++ isn't as good at being C as C is.
0

Share this post


Link to post
Share on other sites
I might get flamed for this, but oh well, I'm used to it. I think C++ promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate C++, but I prefer straight forward C over some class/template crazy C++ code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in C++, you can do in C, but just requires a bit more effort.

I wrote my first 3rd person shooter game in C. Saw no advantage in using C++ whatsoever, and it was easier to follow/maintain.
0

Share this post


Link to post
Share on other sites
[quote name='Way Walker' timestamp='1295900142' post='4764103']
[quote name='Sirisian' timestamp='1295859309' post='4763797']
Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.[/quote]
If you need to cast, then you're trying to compile a C program as C++. My favorite idiom is:[/quote]
touche. That's what I get for coding in C++ so much. I'm curious why my professor never questioned that. :blink:
0

Share this post


Link to post
Share on other sites
I use C a fair bit to write libraries that get called from python code. (At times it can drift into the dreaded c/c++ bastardization mess, but I try to keep things to C for most parts. Some of the C++ standard library stuff is just too tempting. I really don't want to know just how badly a few of these libraries break if I try to port them.)

Right now, the current project I'm finishing up is about 60% C by Lines of Code, which seems to translate to something around 20-30% functionality as I look back at some of my documentation.
0

Share this post


Link to post
Share on other sites
Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D
0

Share this post


Link to post
Share on other sites
[quote name='Eelco' timestamp='1295910770' post='4764202']
Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D
[/quote]
Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.


I like D, but without a decent, open IDE, it won't gain any momentum.

1

Share this post


Link to post
Share on other sites
[quote name='Eelco' timestamp='1295910770' post='4764202']
Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.[/quote]
Not enough.

In order for a major shift to occur, there needs to be a killer feature.

Tapes won over vinyl because they were robust.
DVD won over tape because they didn't need to be rewinded.
USB won over DVD because it's not mechanical.

Java won over C++ because of garbage collection.
Dynamic languages won over the web because they removed the need for compilation step.

Note that in all of the above cases there are plenty of examples of incremental improvement. Zip drive did not win since it merely improved on size of disk. Blu-ray or AudioDVD did not win because they do similar.

To improve, one must change some fundamental aspect, not just iterate on existing parameters.

The killer feature of C++ over C? Namespaces, either real ones or struct/class encapsulation. And little else.

But merely fixing what is broken or improving on individual parameters simply isn't enough.

[quote]C code compiles virtually without modifications,[/quote]Virtually without? Or completely without?

What about C-with-classes, which represents huge portion of production code. And if that code compiles already, why would I now start with a new language that might or might not work?

A C++ which compiles virtually all code is fine. It takes no effort, one just switches the compiler parameter in build.
D code first needs to be rewritten, build needs to be rewritten, application must then be tested and finally, in addition to all the usual bugs, a whole new class of bugs appears from "almost compatible" code.

None of this adds anything at all to final product, it takes *years* away from time that could be spent on that. Even if that problem were solved, there is still the lack of the killer feature.

[quote]without a decent, open IDE[/quote]There is no IDE for PHP. Well, there are many, but most one can hope is some trivial syntax highlighting. It certainly hasn't hindered the adoption, in many ways it made language accessible since all one needed was notepad.
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