Karsten_

Making games of a graphical nature doesn't really need a GUI library. Just set up an OpenGL rendering context, or a 2D canvas in any way possible (Java, Obj-C, C#), then you can easily use C for the rest.

 

How good are you at C? If you have spent quite a while mastering it, then I don't see a problem why you cant use it.

Especially since the popular way to develop games nowadays is using the Component Entity Model which favors composition over inheritance and so using an OO language is not necessary.

 

That said, C can handle object orientation perfectly fine which you can see in pretty much any C GUI library (Motif, Gtk+, etc..)

 

In other words, you don't need to spend time learning a new language and you can start making software. 80%+ of the UNIX world writes user-land programs in C so it is certainly capable.

I think it is an elitist thing personally. Some people (especially in game development communities) put C++ so high up on a pedestal that it is becoming "scary" for newcomers. This is annoying, especially for those who do find the language to be easier for what they want to achieve.

 

If you feel like you should be learning C++, then go for it. I personally wouldn't recommend anything else (Other than C if the project is not game related).

Everyone does it differently.

Perhaps try jumping into the game and when you hit a wall (and you will know when you have) and you have tried for a while to hack around the issue, then you will be more than happy to pick up the book and find out a solution to your problem because you will be frustrated by the code at this point.

... and then rinse and repeat

Try this one http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib

It is much simpler.

If you are using c++, i suggest putting most things in a shared_ptr with the correct deleter function so you dont need to worry about manual memory management.

If you prefer to use Linux/UNIX to develop your game (i.e because you use it as your day to day OS) then you might have some success with wine-g++ and DirectX.
You probably wont be able to use closed source engines with this solution though because I doubt they would be able to link with GCC objects.

Engines I have used that work pretty well on both platforms include include Ogre3D and Irrlicht

I have not had great experience with Unity's Linux support. It only really works on the very latest distributions. RedHat Enterprise 6 couldnt run it due to incompatible glibc versions. This isn't really Unity's fault but is a symptom of using a closed source engine. Linux doesn't really maintain backwards binary compatibility in the way Windows does. (Which is why NVIDIA and AMD's drivers tend to be problematic).

OpenGL works on every platform I have ever used so I always strongly recommend this, even some people tell you that it isn't quite as "good" as DirectX. As an indie developer, it probably wont even make a difference to you. Personally, I find it much easier to get started with.

To work with Unity you will need to know some sort of .NET language (C#, UnityScript, Boo, etc...).

Personally I feel C# is only percieved to be easier than C++ because it has newer libraries will less legacy stuff in them (afterall C++ has been around many, many years before C#). The C# libraries are also often much more abstracted than C++ libraries because they are usually much fatter bindings over C libraries than C++.

Python is similar to Boo so you might want to look into that when using Unity.

Lua is usually a scripting language above another language. If you are just starting out, I don't think you need this yet.

With Unity the closest to (developing entirely in) C++ you can get is C++/CLR which isn't really recommended and like C++/CX/RT is not C++. (Even though Herb Sutter did a great job improving it over Microsoft Managed C++ (which was naff)).

If you do go for C++ and you intend to develop 2D games, then I highly recommend OpenGL (and a simple image loading system like libPng or DevIL).

Although OpenGL was developed primarily for 3D, it works just as well and if not better than many 2D libraries. It also means that your game will be hardware accelerated which is perfect if you have an action packed world with lots of sprites, effects etc...

It also gives you an easier ride if you do want to port your game to Android, iOS, Linux etc... at a later date.

However, for 3D, OpenGL might be a bit too time consuming to start out with unless you use individual libraries such as a model loader, maths library etc... For this I might suggest Irrlicht.

If you decide to use C# instead (though I see no reason why you should), then OpenTK is a wrapper around OpenGL that gives you the same benefits. This means you don't need to waste time learning a new API.

rancineb,

I do pretty much all my development in a pretty common text editor (Vim) and then use Makefiles and xcodebuild on my Mac build server to generate the iOS packages.

I have found that C++ and OpenGL to be the easiest to work with for everything because of the simple fact that once you have a rendering context up and running, the rest of the code (pretty much 99.9%) can stay exactly the same for all platforms I have ever used (and probably ever will use).

If you do have your heart set on a specific games engine, then you probably are going to have to use the language that it requires. If you want to do 2D games then I highly suggest C++ and OpenGL and for 3D there are also loads of different libraries to load 3D models etc... that you can put together your own engine extremely easily.

Perhaps all I am saying is don't just jump onto C# because it is "what everyone else uses" because similar was done with VB6* back in the day and once Microsoft dropped it in favour of .NET. People lost a *LOT* of work. Portability and longevity of my code (and hard work) is king in my book!

* VB6 code is not at all compatible with VB.NET.

Yeah you read it whilst I was still fixing my post.<br /><br />Internet is too slow and these forums are a tad broken but I finally got my post submitted.<br /><br />I am off for a beer now lol.

It should compile, I would be interested in knowing why it doesnt for you.
On g++ I need tr1/memory and tr1/functional headers included.

As for the OP, he is the one that didn't want to call the constructor. I didn't question it lol (ironically in fear of losing rep haha). The "some_class" might add itself to a cache pool on creation and so not want to be deleted once the std::vector goes out of scope (i.e how Irrlicht handles meshes etc...)

As for (properly) using smart pointers, once you get this to compile, it works really nicely for C libraries (with the appropriate deleter func added) without needing to wrap loads of stuff in C++ classes. Though the problem in this thread isnt perhaps the best use-case for it.

Whoever decreased my rep, I am hoping you did so for the nullFunc stuff rather than the std::tr1::shared_ptr because although that looks messy, it is pretty standard C++.

Perhaps push the memory contained within an std::tr1::shared_ptr onto the vector but set it's deleter function to a function that does nothing.

array.push(std::tr1::shared_ptr<some_class>(new temp(), std::tr1::bind(std::tr1::placeholders::_1, nullFunc));

...

void nullFunc(some_class* unused)
{
  // do nothing...
}

C# for me is a big timesaver and makes you more productive
XNA is far easier to get working on a game, without dealing with much of the lower-level work of initializing devices, managing vertex buffers, etc.

Just because you use C++ doesn't mean that you do have to do lower level work. There are loads of C++ libraries and engines out there that are higher level than XNA.

Pick the language you prefer and pick the library you feel most comfortable with. Perhaps only use DirectX or OpenGL (With either C# or C++) if you want to go into the technical stuff.

Mesa3D is the primary implementation of OpenGL on UNIX and supports several hardware graphics adapters (More than the default implementation in Windows infact).

But, yes it can also be compiled to be software only.

Are you using smart pointers such as std::auto_ptr or std::tr1::shared_ptr?

These will help prevent almost all memory leak issues and really are the way to go in modern C++. Afterall, prevention is better than cure ;)