- Using reflection to help build GUI for tools
- 3rd Party tools / components used to build tools
- C# and managed code for tool building
Reflection with C++ and C is a bit harder to pull off (use header files) than something like C# or Java. This limits this approach for dynamic generation of gui based tools and plugins for IDEs.
Some of the studios still using C++ or C for tools development were commenting that technical artists hate (yes I said hate) most of the grids and property setters exposed by tools. Most of the time this is because artists (creative type) are looking for color pickers and such (nice gui's) and developers are more analytical (just numeric values will do). The tools typically created by tools developers fit better with developers.
Possible ways to fix this were discussed. One would be to adopt something like MVC pattern and expose different views based on user.
With regards to 3rd party tools, artists again are looking for more WYSIWYG interfaces, instead of the lower level interfaces they are given. The idea of creating debug versions of data structures as well as executables came up. The problem here is when problems only show in the release build (data structures) and are ok in debug build.
Bug databases are crucial and automation to fill these without intervention (or light intervention) from artists are an absolute requirement. Artists typically will just quit using or find workarounds if given broken tools.
If using managed code, Sony Online mentioned they were using Cruise Control .Net but does not have it fully working yet (automate builds done but not functional tests).
Many studios are adapting Agile software development tactics (like daily calls about projects / issues).
Automated logging came up, with log4net pushed as a very good tool.
Maybe 60% of the studios in attendance (including Sony Online, Bioware, Pandemic, Microsoft Games Studios, 2K, EA) are currently using C# and managed code to build tool sets (at some level).
The ones still using C or C++ were doing so for richer data when crashes happened. Also, these studios were happy with what C# could do, but typically they have to use what is in place, with not alot of time to rewrite everything with a new language.
The idea of standardizing on languages (scripting, tools, engine) was discussed. John pointed out that its almost obsurd to try this. Developers use what they are familar with to get the job done. Whether is Ruby, Java, .Net, C, C++, Lua, Perl or whatever else. The one key point was not to be writing your own scripting engines, which is where some studios went. This becomes more of a computer science project than a functional piece of software. Standardization on a variety of languages (common used, non-proprietary) is required. Key point, make all tools dump data in common format (XML)! Embrace the chaos, don't try to eliminate!