You would think that adding this middle layer would complicate the development process for the programmer, leading to a longer development time, but in fact, it allows the interface for the tool and the complex interactions behind the tool to be developed in parallel by the most appropriate persons. Splitting the development process in two parts, between an engineer and a designer, allows the engineer to focus on the hard programming tasks while the design expert works out the hard usability and design tasks. The two come together within the glue of the view model. This takes the time-consuming task of iterating on the UI with the feedback of the end-users off the shoulders of the programmer, and puts it onto someone in a role closer to that of the end-users, themselves.

Facilitating this relationship between tool designer and software engineer requires development tools that can bring these two worlds together. Fortunately, the most common framework for developing MVVM-based applications, WPF, has the tools to do so. WPF is a .NET UI library and a replacement for the older WinForms library. It uses a a declarative language called XAML, which is based on XML. Because of its declarative nature, XAML can be easily created with a graphical editor such as Expression Blend, which is well suited to designers, and works almost seamlessly with Visual Studio.

MVVM allows programmers and designers to come together in a way that they never have before, allowing them to shorten development time and increase tool quality by putting each task into the hands of the person best suited to it. Leveraging this power will give game developers the ability to create better interfaces for editing game data, and improve the development process overall.

The project is now on Kickstarter, and its looking for $200k in funding to build an open source IDE for Clojure and Javascript. If they reach $300k they are going to build plug-in support for Python , too. Very exciting stuff!

Light Table – a new IDE from Chris Granger on Vimeo.

Bret Victor – Inventing on Principle from CUSEC on Vimeo.

My name is Richard Rabil, and I’m a recent student member of IGDA and a participant in the Writing and Tools SIGs. I’d like to invite you to take a short, anonymous survey I’m conducting on software tools for interactive storytelling.

Ultimately, my goal is to evaluate a set of authoring tools for interactive storytelling and develop a report that can help people determine which software tool is best suited to their situation. Data from the survey will help me better understand game writers’ or designers’ preferences, and assign weightings to my evaluation criteria. This project will also count toward my graduate research.

Although the survey is geared towards game writing, I think it will be important to get a wide variety of perspectives from people who work in the industry. So even if you’re not a game writer, your input will still be valuable since you will likely have fresh insights from other aspects of the game development process.

You can access the survey here: https://www.surveymonkey.com/s/2Y5MD6B. It will be open between now and November 21st.

When I finish writing my report in mid-December, you’ll be able to download your own free copy at the following URL: http://dialoguejunkie.com/2011/10/29/survey-results.

If you have any questions, let me know! I hope you’ll consider participating and help me spread the word. The more honest input I receive, the more I believe the report will benefit the gaming industry.

Cheers,
Richard Rabil

<xs:schema xmlns:xs="http://www.roboticarmsoftware.com">
<xs:complexType name ="Unit" abstract="false">
  <xs:annotation>
    <xs:appinfo>
      <attribute name="Name" editor="TextField"/>
      <attribute name="Type" editor="EnumList" values="Infantry,Artillery,Hovercraft"/>
      <attribute name="HP" editor="Slider" range="1,100"/>
    </xs:appinfo>
  </xs:annotation>
  <xs:complexContent>
    <xs:attribute name="Name" type="xs:string" default="None"/>
    <xs:attribute name="Type" type="UnitType" default="Infantry"/>
    <xs:attribute name="HP" type="xs:integer" default="0"/>
  </xs:complexContent>
 </xs:complexType>
</xs:schema>

In our code, we’d read the appinfo and initialize the various controls for each property of the Unit type as defined above, that way, instead of just showing generic property editing controls, we can truly customize it to fit the data being edited. This is just a simple example, but you can easily come up with much more interesting (and hopefully useful) uses of the concept. You can find more detailed info on the W3Schools and MSDN websites.

Some possible topics include:

• Content Pipeline tools (creation, streamlining, management)
• Graphics/Rendering tools
• Profiling tools
• Collada import/export/inspection tools
• Sound tools
• In-Game debugging tools
• Memory management & analysis tools
• Console tools (single and cross platform)
• Mobile Device (phone/tablet) tools
• 3rd Party tools
• Importers/Exporters
• <That cool thing widget someone made last week that helped you find a bug or saved you hours of time>

The list is not exclusive, so other topics are welcome.

Proposals are due September 1st, and can be sent in using this form.

Now get out there, make your voice heard, and share what tools you use to help you get your game done!

In trying to wrap my head around an entirely new chunk of tech, I keep re-discovering patterns that make it easier to get your bearings on a lot of new code quickly. There are lots of these patterns that studios follow when organizing their code, and following these can make it easier to dive and and start getting work done (or just make getting work done in general). Some or all of these may be obvious to experienced engineers, but I figure it never hurts to reinforce best practices, and you never know when someone will have the total opposite opinion for really interesting reasons.

Maintain just a handful of high level solutions so its easy to gain grand perspective.

The lower the solution count in your project the better. Ideally they should all be in the top level folder of your code. The key here is to create awareness of the major chunks of technology in your project. I think most people agree that the bar should be low for any engineer to get in and look at tools, engine, or game code. The more you hide solutions within your code tree the more arcane knowledge is required to even know who the major players are in your codebase.

Direct all compiler output to a single folder.

Nothing hurts broad searches more than having large binary files mixed in with the source you are trying to search. It’s probably the reason why Visual Studio has preconfigured laundry lists of source code file filters in their Find in Files tool. If you redirect all your compiler output folders to its own root folder then broad searches gets orders of magnitude faster since it doesn’t have to wade through compiler data.

If your compiler output is directed to a separate dedicated folder then doing a clean build is just a simple matter of destroying the output folder and re-running your build. Explicit cleans are just slower, and its just easier to delete a folder when scripting things like build server operations.

Code generated via custom build steps counts as compiler output too! Add your output location an include path and #include generated code, even c/cpp files. Doing this keeps a very clear distinction between generated code and code which belongs in revision control (and hopefully you aren’t storing generated code in revision control!).

Keep 3rd party library code and solutions separate.

A big part of effectively searching through your codebase is being able to differentiate your code from external library code. Littering 3rd party libraries in with your own code can muddle search results.

Frequently its not necessary to clean build both 3rd party code and your project code, so having separate solutions can save time. It also makes performing search and replaces within solutions that only have your project code in them safer (you don’t want to search and replace within a 3rd party lib do you!?).

Install large 3rd party SDKs directly onto workstations.

Revision control isn’t the only software delivery mechanism on the planet. Nobody should be making changes within the CellSDK, DirectX SDK, or FBX SDK so they shouldn’t be checked into revision control. These packages tend to be very easy to script for unattended installation (msiexec). This makes it easy to write a simple SDK checkup script to make sure that any given client (even build servers) have the latest kit installed.

Most large SDKs have environment variables that make them easy to find on the system, and even if they don’t you can typically assume where it should be installed. If they are missing it’s a simple thing to track down and install t (even for junior or associate engineers). Also, it never hurts to add compile asserts to validate that the code is being built against the correct version of those libraries.

If you happen to develop on a system with a package manager, they are awesome for making it easy to pull down 3rd party libraries directly off the internet. Microsoft’s CoApp project aims to do just that on Windows.

Only check in binaries of what you cannot easily compile.

The less compiled binaries you check in the better your revision control will perform, and everyone you work with is served better when revision control works well. Source code is much quicker to transfer and store on servers and peers. Not checking in compiled binaries means less waiting for transfers, less locking for centralized servers, and less long term size creep for distributed repositories.

Checking in built versions of libraries will create a headache for yourself in the future when you want to deploy a new compiler or support a new architecture (which will require you to recompile using a bunch of crusty project files that haven’t been used in months or years). It’s always worth a little extra time when adding a new external library to take command over your build configuration management. Sometimes this can involve making your own project files instead of using ones that may be included with the library source code. High level build scripting tools like Premake, CMake, and boost::build are worth spending time to learn, and can make hand-creating IDE-specific projects seem archaic. If updating external libraries in your engine is easy you will do it more often, and hence reap the benefit of more frequent fixes and improvements you don’t have to do yourself.

This article was also posted to AltDevBlogADay.

The purpose of the group is to provide a discussion forum for all types of game tools development, from command line tools, to UI-focused tools, and middleware applications. This can include things like best practices in version control, building and build servers, exporters, level editors, deployment scripts, and game to tools integration. Basically, if you do it as a tools developer, we want to hear about it, and discuss it with you.

See you on the list!

The purpose of the talk was to show that just making game systems data driven is not the end of the road to making your game configurable, especially when you want the rest of your team to be able to edit these configuration files. Formats like XML and JSON are awesome, but by design lack any context for the properties and values they control. This is good thing from a programmer’s perspective, since it means that we can define the meanings of properties and valid values, but a bad thing from the perspective of someone who has to edit those files. Either the system needs to be really well documented, you need to create a tool that ensures that people editing can only supply valid values.

Maintaining these tools can become a huge pain in the ass, though, especially when features or data modules are being added frequently.

My proposal to fix this was to use reflection, either custom coded in C++ or one offered by the language you’re using. This is the one I have the most experience with and the one I’m most comfortable using. Interestingly fellow Toolsmith Geoff Evans actually has an article in Game Developer this month about using reflection in Helium, which is worth checking out if you’re looking to implement this sort of behavior.

However, this does not mean this is the only solution, especially if you’re moving data between multiple systems and / or multiple languages. In this case, a data definition system, might be more worth your while, especially if you can just use the data definition to dynamically load the class as specified (this would be possible to do in dynamic or duck typed languages).

No matter what, the key takeaway of the talk was twofold: 1) Make it easier for people to modify data, and everyone will be happier, and 2) Make it easier for your programmers to do so, and they’ll do it more frequently, with fewer bugs., which also makes everyone happier.