[lmm]

Mostly good advice, but I find test-first helpful even for personal projects. And Qt is superb for internal editor tools. Drag and drop the widgets in the designer, write a few lines of Python to wire it up as an actual program, done. It won't look pretty and it will waste memory but it will work.

[veli_joza]

I think the point of article is to resist learning Qt while making a game, because you believe it would make you more productive some time later. If you already know Qt and can do lots of work quickly, more power to you. IMO, Qt is powerful technology with good future; getting familiar with it is a fantastic investment for young people in IT, just not so much in game development.

[lmm]

I mean obviously don't write a GUI if a CLI will do, and don't write a CLI if editing text files will do. But if you do need a GUI editor then I think Qt is the fastest/best way to get from zero to working GUI.

[mysterydip]

That can sometimes be a deceptive trap, though. What if there isn't a lib or wrapper for Qt (or whatever it happens to be, physics, networking, etc) in your language of choice? I've gone searching the net for solutions to roadblocks in the past to find "this would be perfect... if only it worked in my language." Do you write your own wrapper, try to use something else, switch languages, etc. It can be a vicious cycle that ultimately has you not making progress.

[lmm]

If a language isn't popular enough to have Qt bindings available already then it probably isn't popular enough to use for your first game.

I mostly avoid the cycle you mention by having a single strongly preferred language and focusing my library knowledge there.

[reidrac]

Or use someting like http://www.mapeditor.org/ and export to JSON. It could be more extensible, but a text property can have JSON, so you can kind of extend it like that.

Then process that JSON into whatever you need (I use python at that point).

I've been using it for a couple of years and it makes my life a lot easier.