One open source project I have been keeping an eye on is CoApp. Microsoft is currently paying a Garrett Serack to develop an open binary and source package management platform for Windows. The goal is provide the ease of use and flexibility of linux-style package management on the Windows platform. This is exactly what Microsoft needs to do to keep its operating system competitive in the current climate. Anyone that has developed or broadly deployed an open source application on windows knows the pain that can be avoided if this project succeeds.

CoApp Presentation from Garrett Serack on Vimeo.

Filed under: Builds, Dependencies, Frameworks, Productivity, Programming | Post a comment

This ongoing series delves more deeply into each of the “six reasons your game development tools suck” as argued in my very first post.

At one company I worked for, we wrote our level design tool, as well as a cinematic tool on top of Maya.  The idea was that Maya already had an interface for drawing 3D objects and moving them around in the scene using well known controls.  Unfortunately, the design staff, many of which never used Maya, didn’t really get any benefit from a tool that was well understood by 3D artists. 

With the number of interface elements visible in Maya, to a designer or even a programmer, it can seem overly complex and cluttered.  Add to that the fact that we added additional interface for the design tool itself, and you’ve got something completely unwieldy for the Maya novice.

In addition, as levels became more complex, load times in the tool became longer and longer, and the responsiveness when doing the simplest operations became slower and slower.  In order for the tool to be usable, everything except what you were interacting with had to be turned off, the management of which became another task that slowed down the users.  One programmer on the game team actually refused to ever open the tool, so when testing of a feature or fixing a design bug was required, he’d get someone else to do it for him.

I’ve been in other situations where building a level design tool inside of an art package was a consideration.  In those cases, it’s often recommended as a stop-gap solution.  The argument goes that getting something up and running in an interface that is well known and already supports certain features will be quicker than writing the tool from scratch.  Saving time is usually the best policy, but thinking that time will actually be saved by this method is a fallacy, and stop-gap solutions often become permanent ones.

Time saved on initial development of a 3D viewport with picking and move controls is wasted figuring out how to cram every new feature required by the design team into a limited interface.  The designers’ time is wasted navigating an overly complex tool with buttons and menu options they will never use, nor understand. 

In this situation, we eventually learned our lesson.  The next level design tool was a stand-alone program, but that was for the next project…

Filed under: Programming, Tool Design, Usabilty, LinkedIn, Six Reasons | Post a comment

This ongoing series delves more deeply into each of the “six reasons your game development tools suck” as argued in my very first post.

Two of the most important concepts in software engineering are abstraction and modularity.  Abstraction allows us to categorize problems and write general code to handle all problems within a group, while modularity allows us to combine disparate abstract components to create unique solutions for a particular problem.  These two concepts give us the ability to write elegant, yet powerful systems that can solve many problems at once.

These systems often rely heavily on data, which is the glue that holds the abstract techniques together.  Data is used to configure which components plug into one another and how they behave. 

As programmers, it makes a lot of sense to us to expose the raw data in the tool to the people responsible for making something useful with it.  After all, not only is this the easiest implementation, it’s also difficult to see another implementation that would not constrict the end user’s ability to get the full benefit of the system’s power.

If the tool was in our own hands, or even in the hands of another programmer, this would all be true.  Unfortunately, this is usually not the case.  The end users have to figure our very clever system out for themselves, often with no knowledge of our intention, the underlying data structures, or even basic software engineering or programming concepts.

Instead of empowering the end users with our uber-system that can handle any problem, we’ve saddled them with a system so intricate and burdensome, that they can’t wrap their minds around it, let alone do anything useful with it.

Training can help to a degree, but that turns into one-on-one training with every user for any one person to understand.  Documentation also helps, but often ignored, in reading as well as in writing/updating.  Usually, one person ends up being the expert that everyone relies on, but when only one person can use a tool, you know that it’s doomed to failure.

The answer is simple, yet hard to swallow.  The tool interface can not be designed around the data structures used by the underlying system.  The tool must be designed around the users, and the very specific things they want to do with it. 

That will probably handle about 90% of the problems the system was designed to solve.  Most users will get along happily with that, and even find their own clever ways of getting some of the additional 10%.  They’ll be much happier with a tool that is easy to use than one that is all-powerful.

Filed under: Programming, Tool Design, Usabilty, LinkedIn, Six Reasons | Post a comment

I thought I would bring to the community’s attention this new book on Game Development Tools that’s looking for submissions.  Here’s the call:

We invite you to submit a proposal for an innovative article to be included in a forthcoming book, Game Development Tools, which will be edited by Marwan Y. Ansari and published by A. K. Peters. We expect to publish the volume in time for GDC 2011.

We are open to any tools articles that you feel would make a valuable contribution to this book.

Some topics that would be of interest include:

• Content Pipeline tools (creation, streamlining, management)
• Graphics/Rendering tools
• Profiling tools
• Collada import/export/inspection
• Sound tools
• In-Game debugging tools
• Memory management & analysis
• Console tools (single and cross platform)

This list is not meant to be exclusive and other topics are welcome.

The schedule for the book is as follows:

June 30th – All proposals in.
July 15th – Final list of accepted authors are informed and begin articles.
August 15th – First draft in to editor
September 15th – Drafts sent to other book authors for peer review
October 15th – Final articles in to editor
November 30th – Final articles to publisher (A K Peters)
GDC 2011 – Book is released.

Please send proposals to marwan at www.gamedevelopmenttools.com.

Regardless of whether Toolsmiths readers get into the book, it sounds like it could be great.

Filed under: Announcements, News | Post a comment

If you are free at 6:00 PM on Thursday come out for some drinks during GDC. We will be at The Thirsty Bear Brewing Company.

Filed under: Announcements, GDC | 1 Comment

The Toolsmiths now have a twitter feed here (thetoolsmiths). Blog posts should be tweeted there, and we will drop some tweets about happenings at GDC.

Filed under: Announcements | Post a comment

First off, our official Tools SIG gathering at GDC is on Thursday 1:30 to 2:30 at the IGDA booth.

Everyone should also show up to at least one of John Walker’s excellent roundtables. I find them useful to see what approaches people are using in their pipelines and share lessons learned from the past year.

Technical Issues in Tools Development
John Walker (Applied Signal Technology)
Thursday 4:30- 5:30 Room 120, North Hall
Friday 1:30- 2:30 Room 120, North Hall
Saturday 9:00-10:00 Room 120, North Hall

Lectures:

Data is a Four-Letter Word
Paul Du Bois (Double Fine) and Henry Goffin (Double Fine)
Thursday 10:30-11:30 Room 131, North Hall

Building Blocks: Artist Driven Procedural Buildings
James Golding (Epic Games)
Thursday 10:30-11:30 Room 130, North Hall

The Asset Pipeline for Just Cause 2: Lessons Learned
Mathias Westerdahl (Avalanche Studios)
Thursday 3:00- 4:00 Room 131, North Hall

Introduction to Maya API Programming and Custom UI
Kristine Middlemiss (Autodesk Inc.)
Thursday 4:30- 5:30 Room 300, South Hall

Collada – Featuring WebGL
Mark Barnes (Khronos Group)
Friday 1:30- 2:30 Room 123, North Hall

The Role of Middleware in Game Development: Today and Tomorrow
Martin Walker (Artificial Mind & Movement), Kevin Scharff (Spark Unlimited), Matthew Shaw (Electronic Arts, Mythic Entertainment Studio) and Mark Stevens (Autodesk)
Friday 4:30- 5:30 Room 123, North Hall

Filed under: GDC | 1 Comment

Visual Studio fan or not, its ubiquity in game development means that sooner or later you will have to deal with its shortcomings. It is the de facto standard IDE for the de facto standard game development operating system.

One of its weak points is the project file property editor. While it does wrangle compile and link flags pretty well, it tends to break when organizing include and lib paths in large codebases. The knee jerk thing to do is to laundry list each include and lib path that every project needs in each project file. This can be a real pain when moving to a different version of an SDK or library (since you have to update it in every project where it is referenced).

The built-in solution to this problem is Visual Studio Property Sheets. Property Sheets are separate files of config data that each of your Visual Studio projects reference (or inherit from since they can be nested). Property Sheets let you define your own macros that can be expanded using the standard $(Macro) syntax. Using property sheet macros to path to the include and lib folders of your libraries and SDKs allows for updating all your project’s SDK dependencies by editing one shared property sheet file.

Insomniac’s property sheets are organized like this:
Root.vsprops
> SDK.vsprops
>> Windows.vsprops

Root.vsprops defines for top level macros, SDK.vsprops defines macros that path to versioned SDKs and libraries checked into revision control, and Windows.vsprops defines macros and build settings for projects that target the Windows platform. We also have a simple perl script (getsdk.pl) that syncs SDKs specified by SDK.vsprops by reading that file in directly (vsprops files are really XML files).

Another tricky bit of dealing with Visual Studio comes from its lack of a real compiler plugin API. Each of the major build system integrations on the market (Incredibuild, SN Systems ProDG VSI) have to essentially hack your Visual Studio installation to function as a replacement for stock features. When using these plugins Visual Studio still thinks its calling cl.exe and link.exe but really its calling a replacement program that either does the plugin’s bidding or falls back to the real stock program.

This creates an interesting situation with SN System’s ProDG VSI because it needs to know which version of the PS3 compiler to use when you go to build a project. The VSI plugin looks to environment variables of Visual Studio’s devenv.exe to find the compiler to call from the replacement cl.exe and link.exe. Since most of us like to branch our code, defining which PS3 SDK to use as a global environment variable is a pain because you have to update that environment variable on every machine that builds code every time you change SDKs.

Sadly one cannot use property sheet macros to solve this problem. Even when the “Set in build environment” option is checked the user macros are never sourced into devenv.exe environment and will not be defined when the VSI goes to build your PS3 project. VSI will then error out that its unable to find the PS3 compiler. Presumably this option only causes the macro to be in the environment when Visual Studio calls out to external build tools when it is running its own builds (and not the builds of a hacked-in plugin like Incredibuild or VSI). If Visual Studio had a real plugin architecture for alternate platforms then this would probably “just work” since the proper integration would be able to use the Visual Studio build system to call out to 3rd party compilers without unfortunate file swapping hacks.

A handy solution to this problem is to use Workspace Whiz’s Solution Build Environment to read environments variable from a text file in the same folder as the solution file. The text file just needs to use a basename that matches the solution file (Foo.sln would have a corresponding Foo.slnenv file). This will allow you to specify the proper environment variables and have them be loaded into devenv.exe’s environment and be ready for VSI to utilize when it needs to build your PS3 projects. Since this file can be checked into revision control you don’t have to ever worry about setting a machine-wide environment variable for VSI to do its job.

Filed under: Visual Studio | 6 Comments

The Toolsmiths was created, and is an integral part of, the IGDA Tools SIG. Right now, the IGDA is holding elections for its new board. There are 23 candidates for 5 positions on the board, and you can read all of their statements at the IGDA’s website. In addition, Boston Chapter member and indie developer Scott McMillan has subjected each of the candidate statements to some scrutiny, and asks them some important questions about where they feel the IGDA is going over the next few years.

The elections are very important, especially this year. In the past, the IGDA has had image problems, in no small part because of the actions of certain board members. It is important that we get board members that are actually extensions of our own voices, so that the IGDA can actually represent us as developers. If you are a member of the IGDA (which I really hope you are) please go vote.

Filed under: IGDA, SIG Business | Post a comment

GDC gets closer every day.  This year, instead of doing an official IGDA roundtable to talk SIG business, we’ve decided to just get together for beers at a local bar.  The location and time is yet to be determined, but I would like to find out what night the membership / readers would prefer.

So please take a moment to visit the site and respond to the poll in this post to let us know when you’d most like to gather, and we’ll see you at GDC!

 Loading ...

Filed under: GDC, SIG Business | 2 Comments