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.
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!
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.
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.
You could only create shapes that were legal in the games it was made to edit
The outdoor areas in Doom 3 were made in an older version of Radiant and they are probably still better than the majority of levels created by indie developers using any other tool.
You cannot easily change that just because radiant is OSS.
Of course you can. It has brush, face, winding, vertex structs which can easily be used / modified for pretty much any task I would likely perform if I was using blender for making maps. The code is also relatively structured and flexible so anyone with knowledge in C++ can tweak it.
Anyway, what would you suggest instead? A non-artist spends weeks learning something like 3DS Max or Maya? I dont know if this is some snobbery or what but if a developer wants to make a game without any experience in art, this old ID editor is still one of the easiest routes to take for artwork that is good enough for most indie games.
Anyways, this is off topic to the thread so I am going to stop here. I would just like to state that the tools used to create older AAA games (like Quake III) should certainly not be ignored by indie developers because they in most cases still provide greater functionality than required.
I don't know why you would want to drag in a big OBJ brush mesh
I dont know if you have used *Radiant, but it is split up into multiple smaller meshes if required.
and then have to rebuild it from scratch in a proper scale (so lighting and physics work accurately with a proper meters based unit scale). Why do something wrong so you can go back and do it right later?
Though you find open-source an "irrelevant implementation detail", because Radiant is open-source, it is very easy change the scale that the exporter saves the .obj file as. (Though you will need to be able to compile the thing and thus have a fair knowledge of C and C++ rather than just a scripting language).
I also used to live in the BUILD editor...
Would be pretty good if it exported to .obj.
Tbh, any tool that makes it easy for a non artist to get their ideas across is good. Afterall, Maps can't be build in Unity alone.
Irrilict was a mess. Nothing worked very well. Basically made by a group of guys who just copied everything Quake2 did. Anytime you see an engine, and all the supported functionality revolves around what quake did, and quake file formats AVOID AT ALL COSTS! Forum is full of 'tard know-it-all, OSS zealots, who can't help you with anything when it comes to making games.
This is a tad unfair. Admittedly I do find the API a little messy and fiddly but it is good enough to get you started quickly with cross platform C++ games development. Something that UDK and Unity can't really achieve to the same extent (being closed source).
GTKRadiant (which is on the list) is not a good editor in 2013
Lol, I perhaps agree, but it also shouldn't be overlooked completely. Especially for coders who have no time to learn a full on modelling tool. Plus with the 1.5 version, it can export a map to Wavefront .OBJ making it quite acceptable for blocking out the majority of my level.