Bearhugger

Both coding styles are fine and I would be fine using either. The only style I cannot stand is the GNU style of having half-indented braces. Very annoying to maintain, and if a real TAB slips through the code it's going to look real ugly with different tab settings.

 

 

That being said, personally, I have a preference for putting my opening braces on their own line because it makes the blocks pop out more. I already put a lot of white lines in my code to separate the logical "sub-tasks" of a function, and a condition block of a few lines is definitely a sub-task that I would white-line anyway, so putting the brace on its own line feels more consistent and natural with my coding style.

 

It also serves to separate the condition from the blocks. For short conditions this is a non-issue, but for long conditions that span on multiple lines it becomes harder to quickly spot where the condition begins without that empty white line.

If so, I cannot understand how VS with all amount of components use so little memory? I wrote  not big WPF applications and during work they use near 100 MB of memory. VS is very huge application an it use only ~ 300-400 MB. How could that be if it created using WPF (C#) or they use it only for face and C++ for "background"? 

Microsoft Visual Studio is not monolithic. It's a mish-mash of multiple technologies that have been accumulated over years, some programmed directly against the Win32 API, some programmed in COM, others in .NET, OLE, ActiveX, etc. Visual Studio .NET added a lot of managed code, (AFAIK the WinForms editor is run by managed code), but there's no way Microsoft could afford to rewrite the entire developer suite in .NET.

 

Visual Studio 2010 is still using all these native components. What was remade was the entire presentation layer in WPF, whcih had to be re-written in managed code. Due to the large native codebase the VS team inherited, they had to hook the main loop in C++/CLI to dispatch the messages to the native components that need i, but the user-interaction code remains largely WPF and .NET. Microsoft has made a presentation about how they converted Visual Studio to WPF. (ie: http://www.microsoftpdc.com/2009/CL09)

And if you remember that all native Windows application like VS, Office and other develope using MFC, you will understand that it is the best practice fro Windows developing a complex MDI applications.

 

By the way, in WinForms(which actually in same state as MFC) or WPF you just cannot do some specific things which you can do on C++ and to do them, you need to go deeper.
So, I don`t think that MFC worse than any other modern technology.

I have built the first version of my RPG game editor with MFC before switching to .NET/WinForms. The only thing MFC has that I miss in WinForms is WM_CMDUI and maybe updating widget controls directly in member variables because I'm not a fan of data binding in WinForms. (It looks better suited for database binding than objects.)

 

I'm a big defender of MFC, and I really think it's not as bad as people make it out to be. It might not be a marvel of software engineering, but it has been powering applications since 1992. If I have to build a Win32 GUI application in C++, I'd rather use MFC than Qt, for example.

 

But as much as I like MFC, I find its range of use cases very narrow. Big commercial applications that need native speed and responsiveness (like Adobe Reader) are typically built in Qt because cross-platform is becoming increasingly important. Business applications and internal enterprise tools are built in .NET or Java because who needs C++ to build a bunch of text boxes bound to a database table? Microsoft is starting to use WPF and WinRT for Windows-specific with rich UIs. Games only need a blank window so just learn how to make one using the Win32 API. I wouldn't be surprised if Visual Studio 2014 does not support MFC.

If you want to bind your WPF to an expression, simply create a read-only property whose getter returns your expression.
 
yes, but a lot of times the expression isn't something you want to name with specific parameters; maybe a name would make sense with unspecified parameters i.e. maybe it would make more sense for it to be a method.

In that case you have to resort to using a custom converter with a Convert method that does the call for you. This is the part where WPF can get annoying, especially if it's just for little things like "value - 10." If you have a lot of things like that to bind, you can easily find yourself with over 20 converter classes just for simple expressions. Fortunately, custom converters are pretty straightforwards and you can give your converter properties that hold the method's argument. Since object parameters can be set in XAML, it allows you to set the called method arguments in XAML. As long as you don't want to use a binding to set the arguments, it's not that bad.

 

How does binding to XML files work?

I haven't used it myself so I don't know how well (or bad) it works, but look up XmlDataProvider on MSDN. Basically, it's a data provider just like a normal database data providers, except that instead of binding to a database, it binds to XML. It looks like you can use XPath to search through the file.

Vanilla (non-implicit) C# properties have nothing to do with variables, they're simply syntactic sugar to replace the ugly get/set methods of older languages. We naturally associate them with variables because get and set methods usually are, but you can always have a read-only property whose getter returns "x * y".

 

If you want to bind your WPF to an expression, simply create a read-only property whose getter returns your expression. If you implement INotifyPropertyChange and fire it whenever something causes the result of your expression to change, your object should be properly refreshed in the UI. This is the basis of Microsoft's MVVM design pattern, the pattern we're supposed to follow when using WPF.

 

Also, WPF bindings are actually powerful enough to allow searching through arrays and other collections. (Including dictionaries.) You can also bind to XML files.

 

With all that being said though, the best language is the one that will give you a salary. 

It really depends on your goal for this project, because XNA and Unity are completely different beasts. XNA is "only" a 3D and multimedia C# library, while Unity is a full-fledged 3D game engine that has already done the complicated software engineering work for you, so you just plug in your game logic and hit Play.

 

If you're looking for a good programming exercise, XNA would be the better choice because it doesn't come with an engine.

 

If, on the other hand, you're looking to test a game design concept, or actually release a commercial 3D game on multiple platforms, then yeah go with Unity unless you *really* want to program a game engine. (If you want to make a 2D game, I agree GameMaker would be better suited.)

 

Concerning XNA...

 

XNA has apparently been discontinued because Windows RT and Windows 8 "Metro" favors C++ programming, so yeah I would be careful before investing in a discontinued platform. (Maybe favor MonoGame.) However, if you know you want to use it, there are plenty of great games that have been successful using XNA, like Fez, Bastion, Breath of Death, etc. so it's a totally viable platform. Besides, looking at how things seem to be going, Windows 8 and Windows RT are likely to die long before XNA. ;)

I haven't used Qt Creator extensively so I don't comment on it, but I have used Eclipse a lot, so in case it helps, here's my thoughts about it.

 

Advantages:

* The syntax highlighting is better than Visual Studio and supports more styles, plus Doxygen comment coloring.

* Code completion seemed good enough.

* You get free refactoring tools for C++ without having the shell 200$ for a lame commercial plugin. (Refactoring also happens in realtime in the editor which is pretty cool.)

* You can auto-generate your method stubs from a class definition. (If you can do that in VS I don't know how.)

* You can auto-generate getter and setters for the attributes of your choice..

* If you work with others, you can force coding conventions. (For example, we never use camelCasing where I work, but we hired an ex-Java guy who wrote all his methods like that. Eclipse immediately underlined his methods in red.)

* CppUnit integrated, if you're the type who'd rather spend hours write test than spend them debugging.

* If you program in any other language, chances are that there's a plugin for it too. (Python, Ruby, JavaScript, PHP, Objective-C, Java, you name it!)

* You can hold CTRL to make all your symbols turn into links and you can click on them to navigate through your code base.

* It has A LOT of plugins, and most of those are free. (In fact, plugins are what makes Eclipse what it is.)

* Tons of useful features for backup and source control, like git/svn/etc. plugins and export/import to zip.

 

Disadvangages:

* Debugging seems a bit lacking and the default interface looks confusing, even in Java. Plus it's slow. (Or maybe I'm just spoiled by Visual Studio.)

* It uses Java so you need the Java runtime. It's not incredibly slow and you probably won't notice unless debugging or refactoring though.

* The workspace-based project management system is confusing. Basically you pick a folder (which is by default NOT in your Documents folder) and all your Eclipse projects have to be there.

Even for old technologies, there are a lot of gray zones.

 

Take a language like Visual Basic, for example. You write your program, hit Play and it starts right away, no compile or anything, and you can pause and edit the code anytime during debug, so interpreted, right? But wait, when you're ready to release it, you compile it directly to machine code as a .exe file and ship it as any other executable. So what is it?

 

In addition, Visual Basic has the Variant data type which is the default and behaves like a variable from interpreted languages (ie: a Javascript 'var') but it binds to the COM/OLE VARIANT datatype and needs no interpreter to make it work.

 

I tend to separate languages in 4 classes:

* Binary: Assembler. Self explanatory.

* Native: Compiled directly to machine code. (C, C++, Pascal, FORTRAN, etc.)

* Scripting languages: Compiled from text files at runtime. (Ruby, Python, JavaScript, VBScript, F#, Lua, etc.)

* Virtual machines: Compiled to intermediate bytecode and interpreted by a virtual machine at runtime. (Java, C#, VB.NET, J#.)

 

That still does not cover everything though. Objective-C, for example, compiles to machine code but it has a mini-virtual machine for handling the message dispatching and garbage collection. Visual Basic is an oddball as I have mentionned. Also, where does C++/CLI fit?

If you're limiting yourself to C and want it to be cross-platform, I think GTK+ is the way to go. High-profile programs like the GIMP and (apparently) Firefox use it so it sounds very mature and stable.

I find that using paperdoll for 2D sprites doesn't work well for armor and clothes. Usually you'll have characters with different builds and some being male others female, so when it comes to things that cover the body, you just can't reuse the same paperdoll art for different character. Also, since clothes are deformable, you have to animate it for every sprite. It just seems less complicated and more flexible to draw a new sprite for everything your character can wear.

For weapons and rigid stuff though, the paperdoll works well. And you probably want to implement that as a paperdoll if you have a lot of weapon and allow characters to dual-wield weapons, otherwise the different combinations will get overwhelming.

If it helps, what I'm doing in my game is that each player character has different spritesheets, one for each kind of armor the character may wear. For example, the typical character has a spritesheet for normal armor, mage armor, heavy armor, etc. I love it so far, because I can adapt the armor to the kind of character. (For example, a more "knightly" character wearing plate armor is all covered in shinny armor, while the same armor worn by a barbarian is less shiny and has gabs showing his muscles.) Combined with the good old "palette swap" technique, I can create variations of color among items from a same armor class so each piece of armor is unique visually.

Don't worry, a couple years back, I also got massively downvoted and a mod even chastised me just for writing opinions against the trend. (Can't remember if it was here, Beginners' or Game Programming forums.) The thing is that programmers, especially on the hobbyist/open-source side, can be very passionate about which language, methodology or tools they prefer to use, so if you hurt a sacred cow, you'll get vivid opposition and bad karma. This isn't just GameDev or Stackoverflow, it's everywhere. I dunno why you're getting downvoted, but if it's for a similar reason as I did, I wouldn't lose sleep over it.

These forums are still a good source of information for game development even if you disagree with the opinions though.

Which version of Blender did you try? I used to hate its interface with passion, but from 2.5 and on the program has a completely new interface which is (IMHO) just as good/better as the one of professional packages such as Maya or 3D Studio Max. I wouldn't go back to those. But maybe it's just that I'm just getting used to Blender since I've been using it seriously for almost 5 months now.

It depends where you work at and what you're working on. When working on amateur games in your basement, it is. And it probably is in many programming jobs as well, but...

If you work on software for flight systems, army-related projects, or any other class of software where a fault, (or even a lag) could have a catastrophic outcome, then all the hard rules of software engineering (ISO20000, ISO14764, IEEE1222, SWEBOK, etc.) kick in and you don't really have a lot of margin to solve the issues, you do what the engineers tell you to do, how they tell you to, and by respecting herculean programming rules. Since your "freedom to create" is near-zero in those cases, I think programming is hardly an art when working on those particular types of project. Unless YOU are the engineer, I guess.