Chris Granger‘s Light Table was originally a concept video for a dynamic language IDE that extends concepts by Bret Victor about how to make the coding experience more focused and integrated with the final product.
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.
Jeff Ward (@fuzzybinary) and I (@gorlak) have a chat about game tools development with Mike Acton (@mike_acton) of #AltDevBlogADay (and the Tools SIG).
I was recently invited to do a talk at Game Forum Germany, and the talk I gave was called “Data Driven Is Half the Battle.” I’ve made the slides available on my website if you would like to take a look.
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.
This ongoing series delves more deeply into each of the “six reasons your game development tools suck” as argued in my very first post.
A lot of clutter in a tool’s user interface can be very confusing. When a user needs to scan the toolbar for a specific button to do something very routine, that’s time wasted. Going about this search my result in a context switch that causes the user to momentarily loose track of what he was doing beforehand, causing a further loss in productivity. Minimizing these effects should be considered when designing a tool’s interface and there are at least two environments where this interface bloat tends to occur.
The first is the tool built on top of another tool. Building a tool on top of a 3D package, like Max or Maya, for instance, leads massive clutter. The interface itself is already complex, and adding to it just creates more of a problem.
To get around this issue in Max or Maya you can edit a few scripts to remove some of the standard interface items that users of your tool will never use. If you’re creating tools on top of other packages, there may be customization options to remove elements there, as well.
The second case is the uber-tool environment, in which all tools (outside of commercial packages) are built inside the same interface. Creating UI and AI in the same interface may not make the most sense, after all.
You can tackle the uber-tool issue in several ways. Try creating custom views that specify which tools are available for each user group. This is especially easy if the tools are all built on top of a plug-in architecture — Simply install the correct set of plug-ins for each user. This also has the benefit of less memory overhead, and possibly a quicker load time. On the other hand, if it’s important for your organization to have a consistent interface for every user for the sake of collaboration, try creating different modes for each interface that are easy to move in and out of.
In general, you should probably only add the most commonly used items to a toolbar, and keep everything else just in the menu. This will reduce clutter and make it easy for users to do what they need to do quickly most of the time. Allowing more advanced users to customize the interface to their personal taste is also a good idea, as they’ll have a better idea of what is easiest for themselves, keeping the default interface as simple as possible.
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…
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.
Some time ago, I decided to write a small C# “wizard” tool for enemy encounters and other level design patterns. The idea was to create pattern types, that designers could define with a small amount of data (different for each type of pattern) that could be exported into a much more complex xml format that could describe when to spawn what enemies, what behaviors and properties to give them, etc. in order to make each instance of a pattern unique.
The properties set by the designers were stored internally as an XML document, since XML in C# is incredibly easy to manipulate, and since the data would be different for each level design pattern. It was easy enough to save out the raw XML data as it was stored internally, but the problem was how to transform this data into the format that would be read into the game. Enter XSLT.
C# has the functionality to transform data internally with an external XSLT file. It’s easy enough to associate a XSLT file with a specific pattern, apply it at run time, and then simply write out the result. At this point, it’s simply a matter of providing the designers with the data files necessary to generate their data.
The advantages here are great. Putting the complex structure and syntax in an external file, and separating it from the designer’s view, allows them to concentrate on what’s actually important. The downside is that someone has to craft these XSLT files, which is a format that is a bit obtuse for someone used to functional languages. Additionaly, XSLT has little to no debugging capability.
Now, more recently, I’ve had the challenge of writing an exporter from OpenOffice Calc, which also uses XSLT as filters for importing and exporting. All OpenOffice documents are are stored as XML. In fact, if you simply rename an .ODS file to a .ZIP file, you can explore the format, which is spread over several files inside the .ZIP, the most interesting of which is called content.xml. This is the data that needs to be transformed in order to get the information out of OpenOffice into your own format.
What we wanted was a way to store properies of all enemies in a single table, so designers could tweak values easily. The data then needed to be exported into a proprietary text format (not XML). This is also relatively easy with XSLT, but as with anything, exporting from Calc with XSLT had its pitfalls.
It’s easy enough to access individual cells in a row in Calc. Unfortunately, for some reason, they decided that if adjacent cells in a single row have the same value, it would only be stored in the first cell and an attribute on that cell would indicate the value repeats for n-number of cells.
With XSLT, there are no variables that can change their values, only constants within a single template (the XSLT equivalent of a function). Consequently, there are no “for loops” in the traditional sense. The way to get around this with XSLT is to use recursion. In my script, I basically have every cell recursively calling the template on the next cell in the row, or on itself in the case of repeated cells, and track the cell heading (the first row of the table) separately. Just thinking about it gives me nightmares.
At any rate, more and more data is being stored as XML, and consequently XSLT is probably here to stay. It’s another tool that should be available in the game developer’s toolbox, but must be used with care. To learn more, there are tons of resources on the web, but your best bet for a good introduction is the W3 schools site at http://www.w3schools.com/xsl/.
Over the past few years, cloud computing has become the next big thing for enterprise software. The ability to easily scale resources to meet the needs of the end users cheaply is very attractive. Amazon, Sun, Google and now Mictrosoft (among others) are all offering cloud computing solutions. I’ve recently been playing around with the AWS (Amazon Web Services) to see what you can do with this technology, and I can already see a few ways it could be applied to games.
Running games on the cloud is an obvious use of these resources. Need a game server accessable from anywhere in the world? Start one up on a virtual server. The ability to build machine images (AMIs on Amazon), complete with your own software running on operating systems like Linux, OpenSolaris, or even Microsoft Windows Server gives you that possibility for pennies a day.
But, where cloud computing could really come in handy is in game development. Imagine starting a build distributed across the cloud, in which thousands of virtual machines simultaneously start processing individual bits data. You might see builds going from minutes or hours to just a few sconds.
And the cloud isn’t just for processing either. Some companies offer services for managing data that would traditionally reside in a relational database, and as well as file storage services. You could even use your own machine image running some flavor of SQL. With that capability, why not store assets in the cloud? An asset control vendor could use the software as service (SAS) model for asset control, supplying developers with web and client based views into an asset database on the cloud itself.
The big problem here is that we’re trading bandwidth for processing power and flexibility. The build process may take a few seconds, but retrieving the results to local machines may eat up every bit of build-time savings and then some. We may see overnight builds turn into overnight downloads, and that’s no savings at all.
Bittorrent file serving (available on AWS) may be useful as a build distribution model, but with most users on a single network, it doesn’t seem likely to make a difference. Limiting the download process to necessary files only is simply the flipside of building necessary files only, so may also offer little in the way of savings. Doing a bit by bit comparrison of files built on the cloud, and downloading just the file differences, may be a way to reduce the download time, assuming there are chunks of data in a binary file that remain constant between builds. Other optimiztions almost certainly exist.
All in all, it could be a big win, but until someone proves it, we can’t know for sure.
One thing I’ve been interested in for a while is what I call “The Dependency Question” as it relates to tools. The question is, when and how do you share code between your game and your tools, specifically tools that are communicating with the game either directly while it’s running or through things like asset files. There are many options on how to do this, and even more opinions on how to do it wrong. From a dependency standpoint, though, you have two options.
First, you can have the tools and the game depend on a shared library of resources. The tools have their own UI, tick or don’t tick at their own rate, and may or may not use the same renderer as the actual game. By creating tools this way, you have tools automatically update their own behaviors as new features are added to the game, or even automatically generate their own UIs if you’re using a dlls and a reasonably robust reflection system. The problem here is that if you’re not using the game’s update and render loops, you still have to boot the game to see everything in action. This can create long turnaround time for assets, especially if your game takes a long time to boot and / or load. That said, this allows you to keep your tools slightly smaller, it reduces dependencies on what are often unnecessary game libraries (like threaded sound and in game UI), and can make the tools less prone to break due to game changes.
Your second option is to either make the tools dependant on the entire game, or make the tools embedded in the game. Now, I think every studio has a small amount of “on the fly editing” capabilities in their engine, but there are very few that are willing to take the full plunge and make their game the editor. In some cases, this is because they can’t afford the extra memory or processor time to fit an editor on a console dev kit. That said, in game editors, or editors that can run the full engine stack, can reduce asset turnaround time significantly. Given a properly designed tool, artists, designers, and scripters can actually edit objects on the fly, and see their changes affect the environment immediately. Once given a tool like this, few would want it taken away. However, these tools can also get cumbersome as well. Because you’re working in the game engine directly, few tools developers in this scenario will take the time to develop good user interfaces, as it tends to clutter up the screen quickly, instead relying on weird key or button combinations to achieve the desired result.
In both cases of dependency, the one thing you need to avoid is the dreaded #IFDEF EDITOR block, and I know you’ve all seen them, and they almost always defeat the purpose of having shared code in the first place. The idea behind shared code is to make sure the editor behaves the same way the game would under the same circumstances. #IFDEF EDITOR blocks, by definition, create inconsistencies between editor and game. But these blocks almost always become a necessity at some point, which is why some studios prefer to forgo the dependency question entirely, and instead opt for a tool that outputs a platform independent format (XML or JSON for example) then has various versions of the game decide what to do with them. The game can ignore blocks it doesn’t understand, and fill in missing blocks with default values if needed. This keeps game and editor independent, so that mismatches can be safely dealt with. However, it still incurs the wrath of the slow turnaround time, and the necessity to maintain two separate code bases.
In my opinion, dependency is a requirement. The idea here is to protect against game changes, include the ability to preview your game, and shorten turnaround time to the game whenever possible. Toward this end, you should limit yourself to dynamically linking in only the libraries you need, which is usually your rendering libraries and your game object libraries. Try using reflection where possible to generate your UI against game objects so that changes in game objects don’t require complete editor recompiles. Save and load objects to a text format (XML is my favorite, but you can choose whatever you like) at least during development so that you can protect against mismatched resource bugs, and, lastly, use a robust shared command system to transmit changes to a running game to shorten turn around time.
This ongoing series delves more deeply into each of the “six reasons your game development tools suck” as argued in my very first post.
Many game companies struggle with delivering tools quickly and cheaply. Money is always an issue wherever you go. After all, the bottom line is what keeps a company afloat and it’s employees employed. No one wants their company to fail, to lose their jobs, or to lay off their workers.
Game companies are in an especially difficult position. Attempting to balance a workforce spread over multiple disciplines — art, design, programming and production — is hard enough, but when you consider that those disciplines have their own specialties within each one, the task is even more difficult.
The obvious solution is to cut corners wherever possible, and that oftentimes falls squarely on the shoulders of the tools team. Why? Because most game companies don’t make money selling tools. Tools programmers serve in a support role, and therefore (in the minds of most game execs) are less valuable than those working directly on the games.
Tools teams very rarely get the full support of management, and game teams can’t be stalled waiting for tools to be completed. The unfortunate sentiment among those in power is that there’s no time for tool design. Get it done and get it done now.
There is no time for design, so the thinking seems to go, but what does that really mean? Does that mean that the programmer implementing the tool charge blindly into development without thinking about how the tool needs to function? Of course not.
The programmer has a vague idea of what to do, and without ever writing it down or validating his thoughts with the end users in any formal way, begins to implement the design from his own mind. He still thinks about it a great deal. Perhaps 75% of his time is spent thinking and only 25% is spent typing. There are probably still many unanswered questions, but as the tool begins to take shape, some answers may start to become more obvious one by one. The tool seems to practically design itself, but in reality, design is going on quite informally.
But wait! What if one of those unanswered questions causes a serious problem? What if the best answer to that question requires a rewrite of major portions of current code-base? What if the other possible answers are so undesirable, that the rewrite actually appears to be the best option. Because the design had been postponed until the code was in the process of being written, redesign is now very expensive. Code that has been written will go to waste, and new effort must be exerted to replace it.
If the programmer takes this problem to a (non-technical) manager, concerned with cost and speed of developing the tool, the manager may come to the very justifiable conclusion that a rewrite is not the way to go. Instead, just make a work-around for this one problem, in other words, a hack.
As long as that’s the end of the story, then that’s probably okay. Unfortunately, more issues may arise, with similar outcomes. Also, once delivered, the end users will likely have feedback. After all, without any formal design process, many of their needs/wants/concerns went unheard. And now the real fun begins.
It’s already been established that the quickest solution is more desirable than better architecture and code, and so as feature requests are delivered to the programmer from the users, more and more workarounds are put into place to deliver a new tool quickly. This leads to code that is difficult to maintain and potentially very buggy.
The end users are now saddled with a tool that does basically what they want but perhaps has stability or performance problems. The difficulty to fix those issues increases as time goes on as the code becomes more brittle and spaghetti-like. Fixing one thing breaks something else, leading to a never-ending maintenance cycle that really makes no net improvement whatsoever.