Sign in to follow this  
mrr

Do you need C++ to write a modern game?

Recommended Posts

mrr    150
I am planning to make a very complex simulation game with many elements in it. So I figured to make it in C++ to keep track of all the different elements/objects now problem is I have been out of the loop for years so I know old C++ not the new stuff. On the other hand I am very good at C working with it daily for the last 14 years. What should I choose?? the new modern C++ makes me crazy.. Do you need it to write a modern game?

Share this post


Link to post
Share on other sites
OldProgie2    158
No, but it helps (in some cases).

If you can get your head around object orientation then some problems are relatively trivial. It can be difficult to do though if you are deeply entrenched in the old C style (structured programming) methodologies.

Having said that, not every problem lends itself to object oriented techniques.

Look at what you are trying to create and see if you can break it down into models. If you can (and easily) chances are an OOP approach will help.

Let the solution fit the problem, not the other way around.

Share this post


Link to post
Share on other sites
Gage64    1235
There's a free book called Thinking in C++ (see the bottom of this post) that is very nice for transitioning from C to C++ (chapters 4-6 in particular are great, minus the various void* ugliness).

But then again, learning a different language, such as C# or Python, might be a better use of your time.

Share this post


Link to post
Share on other sites
mrr    150
You make me belive that I can do it without C++. So I will!

Perhaps adding some object oriented thinking with structures and pointers to functions.

Thanx

Share this post


Link to post
Share on other sites
mumbo    131
You don't need C++ to write a game. I prefer to write most of my programs in C# whenever I can.

If you don't really want to learn a new language I would just use C since you already have so much experience in it.

Share this post


Link to post
Share on other sites
popsoftheyear    2194
Why not just use what you're comfortable with in C++ if you already have a bunch of stuff in C you want to take advantage of? Since, for the most part, you can directly use your C code.

There are definitely things that C++ makes simpler. No one said you had to use all the stuff in modeern C++ - most C++ programmers rarely use a large percentage of it. And even when they do, one must be careful not to use it wrong since it's so easy (aka every object in existence inherits from some common base object is a common pitfall that bites people). Point being, you don't have to use features just because they are there. Use what helps make your code clearer, more maintainable, and less bug-prone - even if it starts out as just adding member functions to your structs.

[Edited by - popsoftheyear on April 1, 2010 10:58:40 AM]

Share this post


Link to post
Share on other sites
swiftcoder    18426
Quote:
Original post by mrr
You make me belive that I can do it without C++. So I will!
It is certainly feasible, but my opinion is that writing sizeable simulations in plain-old-C is unnecessarily painful. If you don't have to use C (platform limitations, etc.) then I would recommend using something else (Java, C#, or something more esoteric if you are familiar enough with it: Haskell, OCaml, etc.).

That said, if C is your go-to programming language, by all means stick with it.

Share this post


Link to post
Share on other sites
Atrix256    539
Hey Mrr!

For what it's worth, all game developers I have talked to and worked with basically take what is good of C and what is good of C++ and combine them.

For instance, nobody that I know uses cout, string streams or file stream functions. Instead, we all use the *printf style functions, fopen, fread and fwrite (unless of course you are working on a console with it's own file operations APIs!).

However, new and delete are a major step up from malloc and free, so people tend to stick to that.

Some game companies use the Standard Template Library (STL), but most big games realize that using STL, you don't have enough control over memory allocations so for instance, EA publicaly says that they've written their own replacement for STL, and the unreal engine has it's own dynamic arrays and maps etc as well.

One C++ thing i've seen used a lot in games is polymorphism (class inheritance w/ virtual functions).

This is really useful in a couple situations...

#1 - having a base class objcet that ALL objects in your game derive from. Using virtual functions you can make an interface that the engine can talk to all objects through to be able to do things like garbage collection and serialization. Using this common ancestor, you can also do things like keep lists of game objects that aren't necesarily the same type if you want to. Like for instance, making a tree of such objects to represent a game level in memory.

#2 - let's say you have both players (local and over the network players) and AI's in your game. You could have a base class CEntity and from that derive 3 classes CLocalPlayer, CNonLocalPlayer and CAIPlayer. All of these players have a GetHitPoints function, a SetHitPoints function, a GetHostileTarget function, etc but may all be implemented differently for each of the 3 players. They may also all have a Tick() function which is called once per frame to do the per frame logic for each different kind of object. Using virtual functions you could have a list of players (CEntity's) and just loop through them, removing the ones that are dead, calling update on the rest, etc without having to know what type each one is.

Also believe it or not, the OOP idea of accessors is really handy. IE Get and Set functions such as GetPosition and SetPosition.

You might wonder "well shoot why dont i just make position public and let people modify it directly".

The reason you don't want to do that is if you are trying to debug a bug where an object is moving smoothly down a path and suddenly teleports 6 feet off the path, then gets back on the path and keeps moving, you probably are going to want to put a conditional break point in "SetPosition" to see what the heck is making the object move so far (and off the path) in a single frame.

Also, if you use accessors, you can toss more logic in such as setting an "ObjectIsDirty" flag whenever someone calls SetPosition, or change the internals of how position is stored such as taking in 3 floats but bitpacking it into a 16 bit integer which is smaller for sending over the network.

Anyways hope this helps!

Moving from C to C++, especially in game development isn't too scary and don't worry, you won't lose all the nice *printf, file io or string manipulation functions you liked in C (:

Share this post


Link to post
Share on other sites
oliii    2196
a vast majority of mdern games are made in C++, but it doesn't meamn you have to use, it just makes it easier to find references. However, it's not a straight forward language, and starting with C helps (pointers, memory allocation deallocation on the heap, the memory stack)> If you know C, C++ is a natural step. C# is also an option, however your platforms will be limited.

Share this post


Link to post
Share on other sites
Grafalgar    548
Quote:
Original post by oliiiit's not a straight forward language


C++ is no less straightforward than any other (OO) programming language. It's difficult to master, yes, but imho it's much more straightforward than C# or Java. Don't get me wrong, I love me some C#, but I find C++ to be much simpler to use as the language itself has less features than C#, Java, etc. To your point though, C is easier than C++ and some may argue asm is easier than C (I disagree).

Disclaimer: I've been using C/C++ full time, every day, for the past 7 years. Obviously it's going to be 'easy' for me.

Quote:
Original post by Atrix256#1 - having a base class objcet that ALL objects in your game derive from. Using virtual functions you can make an interface


Yes, but just to make sure all reading are aware, virtual methods are more expensive than regular methods. Not only is there a function lookup cost, but it's very easy to blow your icache since the compiler has no idea which function you're going to use at build time, so it cannot easily optimize for speed. At runtime the PC can jump "very large distances" between virtual function overrides, causing an expensive icache miss. While OOP has arguably made making games easier and much more scalable, it does come with a cost, and the game teams I've worked with tend to be very picky when and where they use virtual functions.

Don't mean to derail, just wanted to comment. Carry on! :)

Share this post


Link to post
Share on other sites
mrr    150
Leaned to C after two first posts..
Now I am uncertain again.

Thing is you can do member functions with pointers to functions in structures.

And you can store different objects thus structures in the same tree/octree/bsp if you store void pointers to the objects.

And keep track of what kind of casting you need for each pointer.

Also you can almost sort of do the base class thing.. by having small structures that aggregate together...but then a single base class is probably impossible.

Also you can have similar functions in different structures like a draw function..so calling it on different objects will be the same.

I realize though all above is much harder to do in C than eqvivalent C++.


Share this post


Link to post
Share on other sites
AverageJoeSSU    564
Quote:
Original post by swiftcoder
Quote:
Original post by mrr
You make me belive that I can do it without C++. So I will!
It is certainly feasible, but my opinion is that writing sizeable simulations in plain-old-C is unnecessarily painful. If you don't have to use C (platform limitations, etc.) then I would recommend using something else (Java, C#, or something more esoteric if you are familiar enough with it: Haskell, OCaml, etc.).

That said, if C is your go-to programming language, by all means stick with it.


I agree.

You can certainly do all of this stuff... but it is sooooo painful!

you want to make a game! not an engine! you dont want to worry about base classes so much as you want to make object B have 20 hitpoints and swing an axe.

there are a ton of tools in non-c languages that provide you with ALL of this! so you can hit the ground running to make a game. Ogre provides all rendering so you dont have to worry about that... thats in C++. XNA is implemented in C# and has tons of stuff for making a game, and you can also deploy the stuff to xbox.

If you really want to make a game and not fool around, i would suggest not looking at languages and more look at the tools for which you can use to make your game, the language for which you use will become more clear once you figure this out.

Share this post


Link to post
Share on other sites
Portugaz D Ace    110
I would personally use a combination of C and C++. Visual Studio 2008 supports C as a part of C++ projects. Also in C++, if you use the declaration EXTERN_C, you can use C code directly in your C++ program code.

Share this post


Link to post
Share on other sites
Grafalgar    548
Quote:
Original post by Portugaz D Ace
I would personally use a combination of C and C++. Visual Studio 2008 supports C as a part of C++ projects. Also in C++, if you use the declaration EXTERN_C, you can use C code directly in your C++ program code.


Supporting C as a part of C++ is not a Visual Studio thing. C++ *is* C when it gets compiled. That's why you oftentimes hear people talk about name mangling in C++. MyClass::Function() gets turned int MyClass_Function(MyClass* this) at compile time, which is a C function.

What you can't do is go from C to C++ *if* you're compiling your sources as straight C code. But you can if you compile your sources as C++ code, because C is part of the language that is C++.

mrr: What you're talking about is just about exactly what the compiler does for you at compile time. Every C++ class you write, with virtual functions and all that gets translated into simple C code along with function pointer arrays and implicit "this" pointers. In fact, if you have the time for a fun project you could write a script that translates C++ code into straight C. If you do that, you've done exactly what the compiler does for you. It's a fun exercise, albeit time-consuming!

So, if you're on the fence about using C++ vs straight vanilla C, and you're considering duplicating virtual functions in C, you'll just be re-doing grunt work that the compiler already does for you if you write C++. In other words - you'll be reinventing the wheel :)

Quote:
Original post by AverageJoeSSU
you want to make a game! not an engine! you dont want to worry about base classes so much as you want to make object B have 20 hitpoints and swing an axe.


Quoted for truth. If you want to just make a game, there are easier options to just get up and running than to figure out the ins-and-outs of an arguably difficult language.

Share this post


Link to post
Share on other sites
Ravyne    14300
Quote:
Original post by Atrix256
For instance, nobody that I know uses cout, string streams or file stream functions. Instead, we all use the *printf style functions, fopen, fread and fwrite.


Eh, I used to do the same until I actually sat down and learned to use to used the C++ stream-based functionality for binary file access. I'll grant it's more difficult than the C-style mechanismns at first, particularly if you're familiar with those, but the C++ style operations are quite convenient once you've got your head around it. One particular advantage is that the '<<' and '>>' operators are perfectly suited to expressing the decorator/undecorator pattern, which is highly applicable to I/O, succinctly.

Quote:
Some game companies use the Standard Template Library (STL), but most big games realize that using STL, you don't have enough control over memory allocations so for instance, EA publicaly says that they've written their own replacement for STL, and the unreal engine has it's own dynamic arrays and maps etc as well.


I see a lot of third party game code at work. We really like getting code that uses the STL, as it makes our lives a lot easier. Those who choose to "roll their own" tend to have a lot more bugs both internal to their replacement functionality, as well as a result of it. Plenty of companies roll their own, probably about half the stuff we see, but that tide appears to be shifting. Its hard to beat the C++ Standard Library container classes, and if you need custom allocation patterns, that's what the _Alloc template parameter is for -- all containers support it.

As far as EASTL, that was more about error-handling philosophy (SEH vs. Return codes) and compiler deficiencies from back in the day than it was anything "wrong" with the C++ Standard Library.

Share this post


Link to post
Share on other sites
mrr    150
A lot of sensible advise here.
I wavered back to C++ and started to use it.
I am programming as much C like as possible.
Of course I have run into new problems but thats for another post :)

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