Here is an interesting video of the tools Eskil Steenberg has engineered for his game Love:
His integration with Uni-Verse is definitely an interesting take on what life as a content creator could be like without having to deal with load/save/export via files on disk. Verse seems to disconnect where data is stored and how its managed from the user. It comes across to me as fitting the client/server paradigm of the web into content creation tools for games.
Several years ago, I developed an effects tool at High Voltage Software. I was rewriting the effects system we had used on Hunter: The Reckoning and a couple of follow-up titles while creating the tool. The original system had given us some really great results for our first generation Xbox titles and the company wanted to reuse it in an otherwise new codebase. However, the original programmer had left the company and the code itself was kind of a mess. Also, there was no tool for creating the effects, just a text definition file that few knew the intricacies of.
So, I set about creating a system that, at the bare minimum, should have a cleaner implementation than the original, would be capable of recreating all the effects from the Hunter games, and have a GUI for doing so. The results were excellent. We used the new system and tool on Dual Masters and Leisure Suit Larry. The Dual Masters Team was able to take my initial implementation and add some additional features, like keyframing, to create not only all of their effects, but also their very cinematic battle scenes. On Larry we used it for all of our in-game pickups, censor boxes, and other random effects throughout the game.
This tool was much more than a particle tool, although the particle tool existed within the same interface, and switching between the two was relatively easy. This was a compositing tool, allowing artists to combine particles, animated models, lighting, and other simple objects together to create stunning visual effects. Every object could be attached to every other, with offsets, if necessary. Particle systems could be attached to animated skeletons, models could be attached to individual particles, and new effects could spawn on particle collision. It was very powerful.
The tool was written in C++ using MFC (that’s how long ago it was), and had a window running the game engine inside the tool, so that the effects could be viewed in real-time while being edited. The tool was still in use years after I left the company, so I consider it a great success.
We use compositing tools all the time, perhaps without even thinking about it. Level design tools are compositing tools. A designer takes prefab objects like enemies, traps, pickups, etc. and drops them in a level (with art created by an environment artist). The result is a composite of all the level design and art elements with instance data for each.
The power of compositing comes from the ability to combine simple objects to create extremely complex ones whose sum are greater than their respective parts, so to speak. With the proper tools, these complex game objects can be easily created by the content team. The possibilities are limitless. Cinemas, UI, behavior, and countless game-specific systems are all candidates for compositing tools. It’s a very powerful, easy to use pattern.
Today, we have an interesting tool writen by Toolsmiths reader Eddie Schooltz. The tool, which he wrote about on his blog, is for searching for Perforce change sets, and I can see how it would be incredibly useful (provided you have good changelist descriptions) when searching for when things changed.
Eddie says he’ll be posting the source to the tool, and we’ll keep you updated about when that happens.
Today, we have out first guest post! Today’s post is from Jay Taoko the founder of inalogic inc, a software company specialized in game development tools for artists and programmers. Before inalogic, Jay was a programmer at Ubisoft where he worked on Splinter Cell Chaos Theory and Rainbow Six Vegas. Before that, he worked for EA Montrealand for a flight simulator company. Jay’s interests are in real-time 3D graphics, rendering theory, and custom UI components development.
There was an article in February 2009 Game Developer issue, entitled “Introducing new tools to artists without getting spitballed”. In it, the author Bronwen Grimes was explaining the effort she had to go through to get her team transition to a new tool she wrote. She went through all of the stages needed to convince management and the team that the tool was needed. Naturally, she had to answer that age old question: “the current system works, so why change?”.
It got me thinking. As an independent developer, I can write any tool I want if I believe there is a need for it. No need to ask anyone about it. And yet, I still face that same question: “what we have works, why should we use your tool?”. Even more difficult to answer this one when you are a complete outsider to your client team. Well I believe the answer is part of the question itself. Chances are, if the system a team is using “just works” then it is likely it has been so for a long time and only limited resources are dedicated to maintain it. In the game industry, a long time can be as short as the time to develop one or two projects. After that, team members move on to other projects or other companies, a new hardware generation comes along and there is nobody left to understand or maintain that system that “used to work”.
At the very least the team should consider, if the system they use is making their skills obsolete. The game development process does not remain still. It moves as the hardware and software industry progress and as gamers demand for more. A new tool that makes things better and faster can bring along a new set of technologies and methods that game developers have to learn and master. It may take some time to train on a new tool but it is the only way to remain productive and competitive in this industry. Also, as a tool matures, training becomes a matter of discovering what each new version has to offer.
Part of the role of a tool developer is to anticipate its clients’ needs. And that is what keeps a tool developer active and alert on technologies and practices that can bring definitive advantages in game development. I use XSI as DCC tool and every time a new version is out, I know it fixes some bugs of the previous version, brings new features that will be standard tomorrow, and probably makes better use of the multi-core capability of my CPU. Although I may not have a use for all the new features it brings, I like to know about them just to stay up to date in case me or one of my clients as a need for it.
Every tool has to earn its place in the developers arsenal. Tools developers have to connect with their potential clients. Understanding their issues and showing them, not how the tool works but the benefits they will get, is crucial. That was the essence of that article in the Game Developer magazine. To answer the question, “why change a process when it just works?”, I say it is not so much about change; it is about the necessary evolution of the process.
If you would like to contribute a guest article to the Toolsmiths, please feel free to email us at toolsmiths -at- igda.org.
At GDC, we got a lot of good ideas on what people expect from the Tools SIG in the comming year(s), but I want to ask the blog readership what they think, to make sure we’re focusing our efforts on the projects that will not only give the most back to the community, but expand our reach to new members. To that end, I’ve included in this post two polls figure out where to focus our efforts. If you are in an RSS reader and can’t see the polls, please take a moment to visit our site and respond. Your responces will help shape the SIGs efforts in the comming year.
In addition, if you have ideas for other efforts, or would like to volunteer to help in any efforts, please do not hesitate to email us at toolsmiths -at- igda.org.
When I was in college I was a double major — computer science and English. I know, I know, strange combination. Anyway, of the few things that people have said over the years that have really stuck with me, one such pearl of wisdom came from an English professor. He said that a piece of writing can be written and rewritten and edited over and over again forever, but at some point you just have to stop and go with what you have. Eventually, a piece of writing stops getting better regardless of your effort. It’s what Economists call the law of dininishing returns. As additional production effort is applied to a system the output gained from each unit of effort dininishes. It is sometimes more beneficial to stop the current effort and apply what has been learned to something completely new. It’s a lesson the game industry should learn.
Middleware companies sell complete packages for AI, physics, UI, animation, you-name-it, but what constitutes a “complete package” anymore? What a lot of middleware companies deliver seems no where near complete, even for the subset of game development technology of which they are supposed to be the leading industry experts. They release new versions monthly that game studios have to integrate to get lastest features and bug fixes. Are we game developers, or simply beta testers for middleware companies?
Many of these companies have great customer service. They offer support tickets so developers can submit bugs and feature requests, but at this point, they’ve gone from middleware provider to service provider. They customize a solution intended for the masses to the needs of individual companies, when what they should really be doing is applying the effort spent on maintenance of the current version on developing the next version. After all, once a few games have shipped on the current product, its viability has been proven. STOP DEVELOPMENT! Give us what you have right now and put your development effort into making the next version that much better.
Sure, those companies that shipped games probably needed workarounds. And the other companies out there with games in development have workarounds too. Some of the currently supported features have unexpected results, or just don’t give you what you want. But do you really want to wait around for the “fix” anyway? Waiting around holds up your production. You have to remember that you are not their only customer. It may be months. It may never come. It could be the fix that breaks everything else in your game.
You can’t rely on it.
So what can game developers do? Well, the next time you’re shopping for a middleware solution for your project, and the salesperson tells you about the cool new features coming in the next or upcoming release, don’t plan on getting them in your lifetime. If you can live without a feature, design your game without it. If it isn’t there now, and you really need it, shop for another solution. I don’t want to be a beta tester any more. Neither should you.
The Toolsmiths are now all back fro m GDC (I’ve been on site with clients the past week) so we should probably recap some of what happened. Geoff, thankfully, has already posted the notes / slides from his talk, and I’ve now filled in the Tools SIG wiki with some of the notes I was able to take from John’s Technical Issues in Tools Development round tables and I’ve posted notes from the IGDA Tools SIG round table as well.
So now I’d like to take some time to talk about official SIG business, specifically what came up at the round table. The thing I heard more than anything else (other than the fact that the title of the talk should have had “Administrative” in the title to make it obvious the talk was administrative in nature), was that in order for us to keep the Tools SIG relevant growing, we need to provide tangible benifits to the Tools community. I think we’ve started down that path already with the Toolsmiths and the mailing list, but we need a lot more.
At the round table, we started talking about things we can offer in the new year, not only to increase usefullness to our members, but to serve as outreach to bring in more members to the SIG and the IGDA. These include
Over the next few years, we’d also like to look into providing other benefits, including:
What we need from all of you, in the mean time, is input into what projects you would be most interested in seeing started, and which ones you would help volunteer to complete. So, probably over the next week, I will be running some surverys / polls through the blog to try to find out what is most important to our readership, and from there, hopefully we can provide the community with exactly what they need. If you have any projects that you would like to see the Tools SIG accomplish this year or over the next few years, please do not hesitate to add them to the list, and I will add them to the poll.