Writing a Game in C

[j0n]

Hi,


I've decided that the next game I'm going to write will be in C, without using any C++. I was wondering if many people do this in the pandora community?


I know most libraries are written in C, but as far as I know most people write games in C++.


There are a couple of main problems I envisage:


1) Lack of C++ standard library. vector, map would be most missed.


2) No boost.


3) No references.


Aside from that I don't think there will be too many problems.


My idea is to use preallocated arrays for most things I'd use a vector for, and maybe implement a map data structure as well if necessary.


The lack of references is a bit crap, but pointers aren't so bad. Besides I noticed references are a bit limiting in some cases.


I'm going to use C99, which I know MS doesn't support, but I don't support MS so that's fine.


Anyone have any comments or caveats that they can think of?

 

[lulzfish]

It will give you the advantage of uh...


I dunno, I almost think of C as a novelty language since I use C++ constantly.


I've thought about trying it so I can write functions and not worry about which class they should or should not belong to, but I never have.

 

[Letalis Sonus]

Use the GLib, it's kind of the C equivalent of boost, it even offers a reference-based system for doing OOP (creating own GObject classes is rather uncomfortable, though).

 

[skeezix]

Theres nothing wrong with straight C; for that matter it might make it easier for you to hand optimize if you're careful


Building your own hash table collection is trivial, and of course many C libs exist


Do whatever is comfortable or fun.. Straight C, C in C++ compiler to use some plusisms, or all C++.. They're all tyring complete and both are long in the tooth (useful)


I've done a bunch of plain C brute force lately just to make it easy for others to refer to from other languages (no func name mangling or class interface problems when bound to python or perl or lisp etc..)


Jeffphone

 

[ibisum]

meh, there is a lot of merit in writing good clean, happy, well-working C code these days.


if you're a C++ programmer missing maps and things, just choose your libs wisely; for a lot of basics stuff, you can use libdjb or so on. check out the linux kernels' own list/queue/hash basic datatypes.


and anyway, if you look around you'll see that things like maps and linked lists and dynamic arrays are all very, very well implemented on C already; just dig around to take what you need, or use the field survey to guide your own implementations. It shouldn't take you longer than an evening to whip up an abstract data type library in C, if you're already a good C++ coder.


Point is, yeah, go for it. C is a fantastic pure language to do interesting things in. I see no reason, whatsoever, not to just go for it ..

 

[j0n]

I've done a bunch of plain C brute force lately just to make it easy for others to refer to from other languages (no func name mangling or class interface problems when bound to python or perl or lisp etc..)

This is one of the reasons I forgot to mention I think C is great. C fits in well with almost every other language in existance, which makes it a great candidate if you want to script stuff down the road. Which I would like to do with python. I've done some python wrappers for C++ before, and it was ugly to say the least.

meh, there is a lot of merit in writing good clean, happy, well-working C code these days.


if you're a C++ programmer missing maps and things, just choose your libs wisely; for a lot of basics stuff, you can use libdjb or so on. check out the linux kernels' own list/queue/hash basic datatypes.


and anyway, if you look around you'll see that things like maps and linked lists and dynamic arrays are all very, very well implemented on C already; just dig around to take what you need, or use the field survey to guide your own implementations. It shouldn't take you longer than an evening to whip up an abstract data type library in C, if you're already a good C++ coder.


Point is, yeah, go for it. C is a fantastic pure language to do interesting things in. I see no reason, whatsoever, not to just go for it ..

Thanks for that, I hadn't heard of libdjb before, seems interesting. I think I'd enjoy reimplementing some of the basic datatypes like hashtables, I've learned so much since I originally implemented them that I think I'd do a lot better this time.

Use the GLib, it's kind of the C equivalent of boost, it even offers a reference-based system for doing OOP (creating own GObject classes is rather uncomfortable, though).

I've heard this before alright, seems like it does a lot of the crap I don't care about like handling dates, and parsing files. I'll definitely look into though probably in a softly-softly approach.


Thanks for all of the replies guys, some really interesting stuff there.


I'm going to start this off next week after I hand in my dissertation and I'll let you know how I get on.

 

[pmprog]

I guess it depends what type of game you're going to write, but you should find any type of game is possible, just might be a little more awkward in C.


I wrote FreeCell for the Wii just using C very easily. The Collector was also C though used elements of C++ (I created data structures for the "stages" of the game with function pointers, and set variables). Werewolves has gone C++ mainly. I've coded a Wolf3D type game using just C as well (ot should I say engine, it was never made into a full game)


Good luck

 

[Pickle]

i dont see much reason not to use c++ unless your going to target niche systems. Most modern systems including handheld can handle and support c++.


But in the end use what you know and are comfortable with.

 

[j0n]

i dont see much reason not to use c++ unless your going to target niche systems. Most modern systems including handheld can handle and support c++.


But in the end use what you know and are comfortable with.

Hmm, maybe I should have explained that one of the reasons that I want to use C is that I am very familiar with C++ and other object oriented languages like Java and python.


I find that my way of thinking is such that I get bogged down in what patterns I should use, rather than in what I'm coding. I find C coding to be much more fun and doesn't involve carrying around a huge templating / class / exception system which I don't care about.


Also does anyone actually know ALL of C++? It's a giant language, anytime I think I know everything about 10 new things come and bite me.


I like the way with C, it's all contained in a very small and useful book - The C Programming Language.


I have the C++ Programming Language too, but it's a hell of a lot less interesting and more mind boggling.

 

[Rockthesmurf]

I decided to go down the C (not C++) route quite some time ago for a little project, as I didn't want to get caught up with over engineering. I didn't actually complete the project *sigh* it is here if it is of any interest though:


http://svn.assembla.com/svn/zodiacmonopoly/


It was (is?) a monopoly game for Zodiac - as I say, it was never quite finished, but wouldn't take *too* much to finish it off and put it on Pandora.


Steve

 

[j0n]

I decided to go down the C (not C++) route quite some time ago for a little project, as I didn't want to get caught up with over engineering. I didn't actually complete the project *sigh* it is here if it is of any interest though:


http://svn.assembla....zodiacmonopoly/


It was (is?) a monopoly game for Zodiac - as I say, it was never quite finished, but wouldn't take *too* much to finish it off and put it on Pandora.


Steve

That page 404ed me, sounds kind of cool though.

 

[skeezix]

Overdoing the 'language' is a common problem; people tend to drink the koolaid and never look back. Especially with schools these days pumping java and heavy-OO and patterns (which is all good), bnut people tend to come out thinking they have to have 'perfect patterns' (and forget the world is imperfect), and tend to think first about heavy-OO (when the reality is OO is best for medium to large projects.. for small projects or prototyping, you end up spending most of your time making get/setters and class definitions and could've been long finished already


(ie: classic example is card game; you could do OO in C just fine of course, but C++ and so on make it 'easier' and 'more complete'; so you coudl write an array of structs for your deck of cards; or you coudl write a base abstract class as an interface to a deck, and another as a card template; then you need a concrete deck class for your deck implementation, plus you need more abstract classes for each card-type perhaps, plus concrete classes for each of those. You also need a base abstract class and concrrtete class for 'player' (be it AI or human) and the real classes, and a state model and.... .you can see how just thinking about you, in a prpoer OO design you'll end up with 20 files of class definitions, or you could've written the whole prototype game instead


So, do what you want to do for fun, and don't look back.


(Remember, the "FILE" object in C is a class, just like any class in a heavy OO language; it has methods, private members, etc. Its just not language assisted, but language design != language.)


jeff

 

[j0n]

Overdoing the 'language' is a common problem; people tend to drink the koolaid and never look back. Especially with schools these days pumping java and heavy-OO and patterns (which is all good), bnut people tend to come out thinking they have to have 'perfect patterns' (and forget the world is imperfect), and tend to think first about heavy-OO (when the reality is OO is best for medium to large projects.. for small projects or prototyping, you end up spending most of your time making get/setters and class definitions and could've been long finished already


(ie: classic example is card game; you could do OO in C just fine of course, but C++ and so on make it 'easier' and 'more complete'; so you coudl write an array of structs for your deck of cards; or you coudl write a base abstract class as an interface to a deck, and another as a card template; then you need a concrete deck class for your deck implementation, plus you need more abstract classes for each card-type perhaps, plus concrete classes for each of those. You also need a base abstract class and concrrtete class for 'player' (be it AI or human) and the real classes, and a state model and.... .you can see how just thinking about you, in a prpoer OO design you'll end up with 20 files of class definitions, or you could've written the whole prototype game instead


So, do what you want to do for fun, and don't look back.


(Remember, the "FILE" object in C is a class, just like any class in a heavy OO language; it has methods, private members, etc. Its just not language assisted, but language design != language.)


jeff

Cheers for the reply dude, your thoughts reflect a lot of what I am thinking at the moment.


I am a recent graduate of a course which taught heavy-OO and patterns and I'm now realising that it is of almost no use for my personal interests.


I have arrived in that situation many times where I have many files and a brilliant OO-design, but no prototype.


It is pretty frustrating not to be able to see the fruits of your labour, and I also think it doesn't really help in the long run.


I now believe reusing well written C code is just as easy as reusing a C++ class.


In work of course I use OO programming, more because I believe it easier to talk to people to talk about objects and patterns than structs and functions.


I agree that FILE is a good example of a C class. I will probably use these kind of classes in my own work, albeit only if they suit the situation.

 

[Rockthesmurf]

I don't know a huge amount about it, but these days there seems to be a lot of noise coming from games developer about the component design patter over the classic object orientated inheritance model.


I've only started really looking into it properly, and it does all feel a bit alien, I do see the potential benefits of it though, especially with game code (I'm more of an engine programmer, so some of the problems this methodology resolves aren't issues I've really come up against a huge amount before, which makes it harder to see the potential in some cases).


Anyway, just thought I'd mention it!


Steve

 

[Tam Toucan]

The "class OO inheritance model" is often used very badly by programmers. Especially in games. You have a GameObject then a Enemy then a Monster then a BossMonster then a.....That's just bad OO. "Prefer Composition over Inheritance" (has vs isa). A component design lets you do this; a BossMonster has MonsterAttributes and has BossAttributes. It's still OO though.


Whether it's a problem in a small game, probably not, but on AAA titles they have some insane inheritance diagrams.

 

[skeezix]

To be fair, a OO design is 'hard' in the sense where there is often multiple fully 'correct' ways, and you may get well down the road before your design starts to solidify to the point you realize it is better another way. It seems pretty well known that no project can be perfectly design, and no project can be nearly perfectly designed frist try.. usually it takes (apparently) 3 tries before your design is mostly right The trick is getting it as close to right as you can first time, or flexible enough..


So is-a versus has-a can be a tough choice there; I've often doen that very same thign myself .. Abstract -> Entity -> Mobile,Container -> Enemy -> Boss (And 'container' really should be a has-a, but I blew that one once..) but .. Boss is-a Enemy ... you coudl argue either way, successfully.


Does a Planet 'have a ' coordinate? or is a planet just a thing, and a map is alist of thigns with coordinates? Well, it depends....


Thats why coding is fun, right?


jeff

 

[foxblock]

Having never thought much about this, but thinking about this now made me realize a few things.


I actually take way too much time thinking about "how" to code (patterns, classes, mathematical equations, etc.) than "what" to code, so at the end of the day I have written some beautiful and well organized code, but actually have not achieved much.


In game development it's essential to be able to prototype very quickly to test game ideas and see whether a specific mechanic will work out, before actually doing any "final" work.


I felt that this is not possible in C++ as you have to design classes and while you are at it, you might just do it right.


Not that's obviously bullshit, you can prototype quickly in C++, too, but then you might as well not be using C++.


I heard C# works better in that regard... well that does not work for me sadly.


On the other hand having a well structured class "library" is very useful in the end, even for small projects.


Having the BaseUnit -> BaseEnemy -> Grunt class structure enables you to easily create new enemies from a "template" without rewriting or copying a lot of code.


You can change how positions are handled or data is loaded in the base class and it will be applied to all.


So I found when I finally have my classes adding new stuff to a project is rather fast, simple and easy.


Obviously the way to get there takes a lot of time and is very unrewarding, which, sadly, is not too good for game development and prototyping.


I guess I should just spend less time trying to write clean code and actually just concentrate on features. Though I will stick to OOP for the above reasons.

 

[bzar]

When doing Wars: Commando I employed a need-based inheritance model. By default I did big classes without even thinking about splitting stuff up to an inheritance tree, then pushed stuff up to base classes as needed to avoid copy pasting code. Worked out quite well to achieve a set goal, but any work on it now would be a mess . In the end I had an enemy class, a vehicle class, and infantry enemy class and stuff. Oh, and an Actor class which IIRC amusingly is also the base class for grenades to avoid duplicating the collision detection model


EDIT: of course this was because of the rush to get it done

 

[Cilph]

Hi,


I've decided that the next game I'm going to write will be in C, without using any C++. I was wondering if many people do this in the pandora community?


I know most libraries are written in C, but as far as I know most people write games in C++.


There are a couple of main problems I envisage:


1) Lack of C++ standard library. vector, map would be most missed.


2) No boost.


3) No references.


Aside from that I don't think there will be too many problems.


My idea is to use preallocated arrays for most things I'd use a vector for, and maybe implement a map data structure as well if necessary.


The lack of references is a bit crap, but pointers aren't so bad. Besides I noticed references are a bit limiting in some cases.


I'm going to use C99, which I know MS doesn't support, but I don't support MS so that's fine.

Anyone have any comments or caveats that they can think of?

As someone who prefers C: 1) Somewhat of a problem. 2) Not a problem, I never used Boost to begin with =D. 3) Nonargument, replace references with pointers to const data.


OOP is still possible by using structs and functions on those structs; Replace vectors with an array of pointers, resized when necessary, with some buffer.


And always, always, be wary of memory leaks. It happens a lot quicker than in C++.

 

[barzoule]

Interesting topic. Gotta say I've been writing pretty much all of my projects in C (using standard libs) for quite some years now. And it sure is still easy to over-planify, and try doing specific libs, rather than making your game (or demo or whatnot). But it can become VERY comfortable to write in C. Especially using pointers and function pointers.


Fun thing: I actually learned C while/by doing Quake (and Q3A) modding. The C one can find there is pretty elegant and kinda close to OO.


j0n: good luck with your game!