This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
[In this technical article, Cinemaware and EA veteran Khawaja -- the creator of the Fork Particle visual effects middleware -- looks at the state of UI and flow for game tools, suggesting practical tips to make your own internal tools and scripts easier to use and succeed with.]
Today, the creative process in various aspects of game development requires trying out numerous ideas and multiple iterations to perfect the final product. A fast iteration process enables better results.
Real-time visual feedback or real time preview is the key to fast iterations during video content development. This principle lends to development of software tools with user friendly graphical user interfaces (UI) and an added level of sophistication.
A digital artist once said to me, "Half my life was spent watching the progress bar on my computer monitor." We have come a long way from that point in time. Now, we need to create a much larger amount of assets for our games, so efficiency in creating these assets is more critical than ever.
Growth in video game production content translates into development of improved tools to efficiently create and manage content assets. These tools -- both externally licensed ones and those created internally by teams to manage particularly custom tasks -- incorporate data creation for new technologies and streamline production pipelines.
Eventually, tools may intelligently design some assets automatically. Currently, the creative process requires multiple iterations to reach the final asset revision.
There are two developer issues associated with the basic problem. The first issue emerges because often not enough time is spent on tools during a game project's pre-production period. It is also frequently assumed that enhancement to the software tools during the project will be sufficient.
This generally results in patched tool features and inflexible software architecture that eventually can only be fixed or improved by performing an overhaul. But due to time restrictions, an overhaul cannot usually be done for the project the tool was originally written for.
As for issue two, an interactive software tool usually requires a powerful engine under the hood, and friendly UI. It is natural to implement the underlying engine first because it is the tool's core functionality. It can be sophisticated and complex, which takes time to put together.
However, the lack of sufficient time assigned to the user interface design and implementation can compromise the use of the tool and limit the speed of work. It can also limit the number of users because of the steep learning curve, and that can be especially painful during project crunch periods.
In the final phase, the asset content is integrated so it can be reviewed in the context of the game for look and feel. A slow asset integration process results in fewer revisions -- or none -- due to its cumbersome nature, which can obviously compromise final quality.