Sponsored By

Q&A: Aristen's Gladwell On FxStudio's 'Special' Debut

Startup firm Aristen has revealed FxStudio Creativity Suite, a cross-platform special effects sequencing solution for games - Gamasutra talks to founder and ex-Monolith staffer Toby Gladwell about the tool's mission and its first deal, an integration with

Mathew Kumar, Blogger

July 2, 2008

6 Min Read
Game Developer logo in a gray background | Game Developer

Middleware developer Aristen, founded by ex-Monolith developers Toby Gladwell and Andrew Kaplan, has announced FxStudio Creativity Suite, a cross-platform special effects sequencing solution, and that it is also to be integrated into the Gamebryo platform. Aristen also announced today that as a Certified Partner of Emergent Game Technologies, FxStudio is being integrated into Emergent’s Gamebryo platform. Toby Gladwell was one of the original founders of Monolith Productions (No One Lives Forever, Tron 2.0) but he's since co-founded Aristen, where he now serves as CTO. Gamasutra talked to Gladwell and he introduced us to the company's new middleware solution. he explained: "FxStudio is a cross-platform special effects sequencing system built to provide artists and engineers a way of sequencing special effects, tapping both the creative spirit as well as any existing technology." "When we talk about special effects in games people so often think of a particle system," he said, but "the reality is an effect needs sound, models, screen effects, user interface interaction, controller input and more." Intending to offer solutions for both artists and engineers on development teams, Gladwell described how one module, the FxStudio Designer, "provides a sequencer building special effects from components that represent interesting pieces of functionality such as a sound, particle systems and screen wobble" and that the FxStudio Runtime module "provides an optimized core for working with banks of special effects and the functional components." Why found Aristen? Toby Gladwell: Monolith marked my transition from home brew development into the “real” games industry. During my tenure at Monolith I developed many tools in close conjunction with the content and engineering teams, and ever since I can remember I’ve been into game development with a particular focus on tools and technology. I’m constantly driven to find solutions that boost a game team’s ability to be both creative and prolific. After leaving Monolith I was with Secret Lair Studios for a couple of years, and I left to realize the dream of building professional production ready tools and technology for the games industry. Starting a company was the only way to really devote the time, attention and money that great middleware require. How was it to move from developing games to developing middleware? TG: We found the transition to be a quite natural move really. I’ve always managed tools development to be product focused and to that end I’m constantly visualizing a product with box, website, and support. Moving away from internal development, there are obviously differences such as the support requirements. You also need to have an open mind for middleware development. You can’t make assumptions about what your customer wants and you have to be very careful about imposing your own rules and regimens. What do you see as is the importance of middleware? TG: It just makes sense to avoid reinventing the wheel each time a new game is developed. In my experience, a great deal of time and money gets burned on in-house development when there are perfectly good off-the-shelf middleware solutions. You want trees in your game? Use SpeedTree. You want user interface? Use Scaleform. But I do think that it’s up to a game team to discern what they should use. They should definitely do due diligence on any middleware they are considering and estimate what it will take to tune it for their own specific needs. In general, the more technology that is being encompassed by the middleware package, the more likely it is to take time, money, and effort. So what makes great middleware? TG: There are several key factors that make great middleware. The obvious first factor is that you need to solve an existing problem or need that is widespread, and do it very well. “Well” in this case means easy-to-use tools that are intuitive, solid implementations for SDKs that are clearly documented, and finally, awesome support to look after the customer. Of course, a few “gotcha’s” in designing middleware spring to mind. This should go without saying but when building middleware, you have to understand clearly what the goal is. What problem are you solving, what need are you fulfilling? You have to also make sure that those problems and needs really do exist! Even if you’ve figured out the goal, if you are unable to define a clear line of delineation between what is game team responsibility and what is yours, then you are in trouble. This is probably the trickiest part and I think it often reveals how much (or little) you really understand the problem. Designs should also call for easy integration. No one wants to spend months of development time trying to get your middleware working. The design of middleware should embrace the fact that game teams may already have existing technology that they’d like to keep. One of the core values we’ve used to build FxStudio is to minimize impositions and maximize empowerment! But how can you make middleware that fits different studios and game designs? TG: Creating middleware that suits different studios and game designs is essential. One of the reasons there are very few special effect middleware solutions speaks to this very question. Designing a system that is powerful enough to build the next AAA first person shooter as well as a great RTS or platformer is no easy feat. Everyone has a different engine architecture, art requirements, and game design. What we’ve done is to break down one big problem into pieces and solve each one at a time. For example, everyone needs to solve the problem of efficient use of rendering so we implemented a fully data driven Level of Detail system that our licensees define in their own terms. Do the different platforms make a difference? TG: Yes. One of the biggest problems found in today’s middleware is the lack of consideration for cross-platform support. Sure, a lot of middleware provides runtime support for multiple platforms, but do they really consider the impact cross-platform support means to the artists’ content pipeline? Often tools force artists to duplicate their work just to make small changes for one platform or another. FxStudio was designed from the ground up with cross-platform support in mind. Each property within an effect can be “specialized” and targeted to a specific platform. This specialization extends to the LOD system as well. Cross-platform support is a requirement in today’s middleware market, unfortunately only a select few really do it well! What is your advice for middleware creators? Understand the problem domain! Find out what game teams are having issues with and see if there’s a place for a middleware package. There’s still a great deal of pain in game development, and shipping great products seem to be a somewhat unnatural process. And whatever you do, don’t develop in a vacuum. There are many developers out there who will share their needs and help with direction. Be realistic about what you can produce and define a release through a concrete set of features that you know the product needs. You can burn through a great deal of time second guessing what game teams are going to want. Feature creep, like in all products, is a killer!

About the Author

Mathew Kumar

Blogger

Mathew Kumar is a graduate of Computer Games Technology at the University of Paisley, Scotland, and is now a freelance journalist in Toronto, Canada.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like