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).
There are some stellar ideas in this talk about how to change scripting workflow to lower the latency of iteration:
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.
One of the most basic of usability features, undo/redo is also fairly straightforward to implement. Most engineers will tell you that undo functionality needs to be planned for from the beginning of a project. So why is it still just an afterthought for most game development tools? We recently had to implement an undo solution for a client in a design tool. This is a general implementation similar to those I’ve seen at other companies. I’m sharing it with you here so you can plan for it when you sit down to design your next tool.
For undo to work, we need an object to encapsulate the functionality of executing an action, along with the undoing of the action We also need to support redoing the action, which is a variation of the initial execution. For those who like design patterns, this functionality fits nicely in the “command” (a.k.a. “action”) pattern. The execute, undo, and redo are all functions that need be added to the command object to support the functionality we need, along with a specific constructor.
The constructor is responsible for storing all of the necessary data within the command class to be used later on by our execute, undo and redo functions. We simply copy values passed in to the constructor to member variables.
The execute function does everything that would have been done had the code not been moved into an undo-able command. This fact makes it relatively easy (but tedious) to implement undo after much of the tool is written, or to move functionality that didn’t support undo into the undo system.
Some commands need to perform multiple actions at once. For instance, we may need to overwrite data that existed before. In this case, we perform two undo-able actions at once, the deletion of the old data and the creation of the new data. So, we pass in a list of pointers to the command base class. This list will contain this action and any other commands that need to be executed along with this one. We’ll create and execute those actions within the execute function. The current action is added to the list last, for consistent ordering. The importance of this will come later.
The undo function is a simple matter of reverse engineering ourselves back to the previous state using the data passed to the constructor. For everything the execute did, we basically do the opposite, with the exception of the multiple command functionality, which is called from code outside of this class, from the undo stack, itself.
Redo basically does everything the initial execute did, but like undo, we skip the multiple command functionality. We call the execute function with a null list of commands (we could use a boolean parameter) to signify we should skip the execution of the multiple command code.
In order to have more than one level of undo, we need to store these actions on a stack. In our case, we’ll actually use two stacks (for undo and redo), encapsulated in a command stack class. Similar to the commands themselves, there are three basic functions in our command stack — execute, undo, and redo.
A command is passed to the execute function of the command stack. The execute function creates the list that is passed to the command’s execute function, calls that function, and pushes the resulting list (which has been populated by the command’s execute function with one or more actions) onto the undo stack. The redo stack is then cleared, since there are no commands to redo after a brand new command has been executed.
Undo simply pops a command list from the undo stack, and executes undo on all items in the list in reverse order. Items were added to the list in the order that they would normally be executed. In our example above where a new item overwrote an existing one, the deletion of the existing item was first in this list. We want to restore the old item after deleting the new one. Finally, the command list is pushed onto the redo stack.
Redo pops a command list from the redo stack, executes redo on all items in the list (beginning to end, this time), and pushes the list onto the undo stack.
Once this is ready, you simply need to create the commands where appropriate, and call execute on the command stack, with the command as parameter. Once the commands are added to the stack, you can simply call undo and redo on the command stack from a key command or menu item.
This simple implementation will give you unlimited levels of undo functionality. The only limitation here is that some commands can use a lot of memory. That’s generally not a problem when talking about tools being run on PCs with virtually unlimited resources, but it can be a concern. How the commands, themselves, are implemented will affect this, so that takes careful consideration. A simple fix for this would be to represent the undo and redo stacks as circular buffers with fixed sizes. Presumably, you can find a reasonable number of undo levels for your application.
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 of you may have read my recent Gamasutra article, Game Tools Tune-Up: Optimize Your Pipeline Through Usability but I wanted to discuss something that writing that article has really brought to the forefront of my mind. As an industry, we aren’t very reflective on the methodologies we use regarding the development of tools. This blog as well as other sources may be bringing about a change in that regard, but it is progressing very slowly. There are techniques in use in other industries that have significantly increased the usability of software, and many have been around for many years.
While at GDC this year, the idea of usability came up at the Tools Round Table. Now, I’m pretty sure John had included the topic at the round table, in part because he had gotten a very early preview (and several revisions) of my article before it went up on Gamasutra. I appreciated the effort on his part, but I was a little surprised at the total lack of response from the group. When asked who was using what techniques for usability, the room was completely silent. I expected that if anyone in the industry was doing anything at all with usability, surely this was the group.
Although it was a bit disheartening, it illuminated a real issue in game development that most of us have known in our hearts for quite a while. Very few people are serious about making game development tools accessible to their users. Artists, designers and even programmers spend a great deal of time dealing with tool issues for the length of every new project. The tools developers wonder why they have so much trouble, without ever realizing that there are techniques in existence that could answer that very question and could help them make better tools that got fewer complaints and more work done.
I recommend every tool developer out there take a look at these resources:
The Usability Professionals’ Association website
Jeff Sauro’s Measuring Usability website
Also, read Alan Cooper’s excellent books on usability:
and
The Inmates Are Running the Asylum
Scheduling tools is tricky business. Most tools aren’t even started until they’re needed, unless you’ve got some very forward thinking management (an unlikely scenario at many game companies). The time constraints are impossible since they’re in sync with an equally impossible game production schedule, and budget constraints can be equally constricting.
So, how do we get tools into the developer’s hands as quickly and cheaply as possible, while still delivering high quality software? Well, if you’ve heard of the quality-speed-cost triangle, you know that if you have to have high quality, and you need it fast, then it’s going to be expensive. Most game companies choose cheap, fast and low quality when it comes to tools, but I believe we can wrangle the schedule a bit to get pretty fast, pretty cheap and very high quality. Unfortunately, it takes a great deal of upfront planning to get there – something game developers aren’t very inclined to do.
First of all, schedule in design. At least 25% of your total time should be devoted to designing the tool. If you have a week, schedule an entire day (or two). If you have a month, schedule a week. If it’s a large project with a GUI, include a mock-up of the the UI. The design should also include a list of features for each of the other milestones in as much detail as possible as well as goals for each one. These go beyond features to explain what all the features are meant to achieve. A milestone should meet these goals, and not just the features, to be considered complete.
After the design is finished, the next major milestone (there may be smaller milestones in-between) comes halfway through the development process and is what I’m calling the “first usable version”. This is similar to the “vertical slice” almost every game has to go through these days, and includes core functionality only. The goal is to deliver a tool that the developers can use to get their work done, and isn’t meant to be pretty or user-friendly. Subsequent milestones will add usability features to the tool. It take a great deal of planning to pull this off without creating work that will get thrown away later, which should be carefully considered in the design phase.
The alpha and beta milestones deliver the final promises on quality. It’s useful to sit with the representative users and get feedback on remaining issues. Formal usability studies can be performed if time permits and those problems addressed. The final deliverable should include documentation on using the tool, something that has been sorely lacking in the game industry. Too many times, frustrated users turn to the developers for help on common problems which could be easily documented, saving everyone a great deal of time. Tutorials are also important, as they can give users a chance to see how the developers intended the tools to be used.
As you can see, we’re able to extended the speed side of the triangle to reduce cost and improve quality, and add a stop-gap in the middle to get users up and running quickly and cheaply. When these components are included in the schedule, then we are not only able to get something to the users in a timely fashion, but we can also (eventually) deliver something of high quality, as long as management doesn’t see the first usable version as finished. They must be informed that the first usable is something to build on, and not at all final, and that increasing the usability of the tool beyond basic functionality will improve the development process greatly.
Of course, this is just one aspect of scheduling tools, but any more detail would too long for this blog. Maybe we’ll talk about the other issues in an upcoming post, or you could leave a comment describing your own process.
I have a co-worker, Darius, who is creating a game for a small game system called the Meggy Jr. Watching him work on this, I was impressed with the tools that he came up with. He’s not a (really) a programmer, but still somehow can make tools that serve his needs pretty well. I’ll let him explain:
This is the level editor I’m using for a roguelike game I’m building for my Meggy Jr. The level is just a 16×16 bitmap array. Each cell of the array is a different color, and each color is a different object. 6 is blue, and it’s a wall; 5 is purple, and it’s a door.A level editor in Excel
I built this level editor in Excel. I set the cells to be 20×20 pixels, big enough for me to work with conveniently, and I used conditional formatting to map the background fill colors to correspond to the Meggy Jr’s color mapping. If you look to the right, you’ll see that I’m using CONCATENATE statements to pull together the numbers into the bracketed statements that I literally just copy and paste into my array declaration in code. With this system I can make a level in a minute, and drop it into my code with a couple of mouse clicks. It only took me five minutes to build this level editor.I’m always pulling crap like this: I love using Excel to abstract things out and then generate code for me. I would never do it for a big project, but for my own hacking it saves me a ton of time.
