If the engine team produces an API so opaque that the tools team cannot consume it efficiently, the engine team fucked up.

The thing is that I believe that an engine team fucking up is not exactly an extremely rare situation, but I could be wrong
We all know that a lot of commercial software can be rather sub-par

All I'm saying is the tools team should not be punished because the engine team failed to do their job. Likewise, the engine team should avoid giving itself the extra work of doing part of the tools job, by designing a proper API in the first place.

If your team is too dysfunctional to accomplish this, you have far bigger problems than worrying about who writes the icky C++/CLI.

All I'm saying is the tools team should not be punished because the engine team failed to do their job. Likewise, the engine team should avoid giving itself the extra work of doing part of the tools job, by designing a proper API in the first place.

If your team is too dysfunctional to accomplish this, you have far bigger problems than worrying about who writes the icky C++/CLI.

I can agree with this


Just to clear things up, this is all purely hypothetical, I'm not facing any of these issues personally, mainly because I'm a lone wolf in the projects I'm working on when it comes to programming, which means all programming work will eventually be done by me (so if I fuck up it'll be just me who has to deal with it )

if you have a organized team, at least you can blame [s]someone[/s]! the other team if they screw up

hehe, just kidding

I can agree with this


Just to clear things up, this is all purely hypothetical, I'm not facing any of these issues personally, mainly because I'm a lone wolf in the projects I'm working on when it comes to programming, which means all programming work will eventually be done by me (so if I fuck up it'll be just me who has to deal with it )

Same here....

I work with web, and only do my "hardcore" programming in my spare time, and alone...

I've seen more tools teams fsk up than engine guys. The big problem with tools is that some people assume it *must* be an easier task than the engine, and so the less experienced members of the team are often assigned the task (it's just some buttons right???). The net result is a buggy toolset, that interfaces badly with the engine, is a touch crashtastic, and ultimately affects the art teams productivity. But yeah, it *should* be the tools guys that write the wrappers. It's just an additional sanity check to make sure the engine interface is straightforward to understand and use. If it requires 'that engine' guy to write the wrapper, then I'd start looking very closely at 'that engine' guy, to see if he's actually up to the job at hand.

Generally when your boss or client come and say "It's just a button there, can you put it there for us?"....

Tools programming jobs are generally overlook by the UIs that are done, which have a very complex code under the hood...

By your point of view, yes tools programmers can fuck everything up more than engine guys, but if the engine guys don't make their job right, tools programmers also won't, and probably the engine guys will make the tools guys fix what's wrong..... (not by experience thought, but it's more obvious)

Going back to your original questions on what GUI framework you should learn, I recommend all of the above. If you can demonstrate knowledge of making GUIs, I'd assume you can learn whatever framework our company uses. However if you really want to impress me you could tell me the pros/cons of WinForms, WPF, wxWidgets, and Qt and demonstrate that you could choose the right tool to meet the needs of the project. However, that still won't get you the job without a lot more experience.

Tools is such a broad term that it can cover just about anything, and it can vary quite a bit between companies. You could be working on a level editor, tracking and visualizing memory fragmentation, writing scripts to help animators work in Maya, a build server, content pipeline, databases and web reporting, scripts to package up a build and prepare it for submission, or just about anything else. Long story short, if you have a broad set of knowledge as a game developer, you should be able to adapt to any company or task you're given. If you can gain anything from the discussions here, you can argue all day about who should be implementing what, but you should be able to do it if needed.

[quote name='Mauricio Cinelli' timestamp='1311721654' post='4840870']
By your point of view, yes tools programmers can fuck everything up more than engine guys, but if the engine guys don't make their job right, tools programmers also won't, and probably the engine guys will make the tools guys fix what's wrong..... (not by experience thought, but it's more obvious)

A good toolset allows quick iteration of gameplay and design concepts. Quick iteration helps you determine the capbilities (and flaws) of the engine underpinning the project. If an art team knows the limits of the tech, they can, and will, design within those limits.

(To an extent) it doesn't really matter if the backend is good or not, the designers will still have the tools to make the game fun to play. If the backend is shoddy, you might have slow loading times, the shaders may not be 100% optimal, the maths library could be faster, the models might have to stay relatively low poly, but the game will still be fun to play - and ultimately that is the only metric to determine whether you have succeeded or not. The old adage of 'dont let perfect get in the way of good' applies in spades here....
[/quote]

If it can be used, though not 100% optimal, you can revisit later on and tweak. However, if the backend is broken... then no one can work, and the game fails.

The best tools/engines are the ones that continuously evolved and still continues to evolve. look at the unreal engine version 1, it didn't have all the capabilities of the current version, but the games were very playable and very enjoying.