First deployed in the developer's own Eat Lead: The Return of Matt Hazard, which shipped for the PlayStation 3 and Xbox 360 earlier this month, Vicious Engine 2 is a full suite of new technology that offers new solutions for developers.
Here, vice president Wayne Harvey, lead technical engineer Doug Cox, and senior programmer
Luke Hodorowicz discuss their expectations for the engine and its licensees, how process is as important as technology in creating multiplatform games, and why developing technology at the same time as developing a game makes their product stronger.
You recently announced that Vicious Engine 2 is going to be launching at GDC and it makes a big step forward for the engine in terms of the platforms it supports and the technology. Can you give me a quick overview of what you see as being the major salient points about the engine and where you've taken it from version to version?
WH: In the past iteration of the Vicious Engine we felt like it was a really strong product, but its major weakness was also its biggest strength and that's the number of platforms that it supported. Because of the number of platforms -- anything from PSP to PS2, Gamecube -- because of that we felt like we often could not shoot for the moon in terms of big features; and with VE2 that's no longer the case because we can support the PC, the 360, the PS3.
Does the technology still map across the platforms that you've supported previously?
WH: No, it actually supports the PC, 360 and PS3 only.
Okay, so then is the previous product going to continue on the market as a PSP, PS2, Wii engine?
WH: Absolutely, and it's still doing very well in that function. But you know, the Wii one also supports the 360 -- but because of the big cross-platform feature set we're unable to support some of the higher-end features on the 360.
This is a really broad question, but I'd like you to just answer however you see it making sense. How do you see your product fitting into what's available on the marketplace right now -- as people are looking to license engines?
WH: Yeah that's a good one. [laughs] Well, you know I think it's a flexible solution for people out there. I think it really appeals to more creative groups that are out there, folks that don't necessarily have a really large team of veteran programmers. It's something that a small startup of creative designers and artists can jump into and learn very quickly and I think that sets us apart from a lot of the other options that are available. And it's proven against many products and many platforms.
One thing that's kind of unique about where you guys are is that you're one of the only, if not the only, engine that's from a developer that's owned by a publisher. How does that affect things from your end?
WH: Actually it hasn't affected us at all. I was very concerned about when we sold Vicious a couple of years ago that there would be an effect. But surprisingly no one really cared. And I'm not sure why that is. We have gotten a few new questions regarding that because of the impending Namco acquisition of D3.
So there is a little bit different of a feel there but still, it's nothing crazy. It's not like the RenderWare situation with EA buying Criterion.
Speaking of D3Publisher, it's a Japanese company -- though obviously they have a large operation in Los Angeles. How's that affected your relationship at all? Have you had interest in working with some other development teams in Japan or have they helped you move into the Asian markets at all?
WH: [Vicious CEO] Eric Peterson and I flew to Tokyo back in December to show the technology to a lot of developers out there in Japan and it was very interesting. As a result of that we have a couple developers that are currently using the technology and it's sort of in an evaluation mode to get the hang of it. We're hoping that we can build deeper relationships with those guys so that they can evangelize it going forward.
That's an interesting tactic.
Speaking of licensing, in terms of licensees, in the past about how many licensees did you have? And moving forward for the new technology how are you doing on the licensing front?
WH: In the past we probably peaked out at about 20 or so, each of them working on multiple projects and SKU plans. On VE2 we have evaluations out there with many of them and we're close to signing with some of them, but we would definitely like to keep it that small, going forward. We have a very tight team of engineers and support staff, and we're not in it for bulk licensing; we want to have a good number of really solid partners out there helping us make the engine look the best that it can.
What is the limiting factor? Is it just that you want to have a strong relationship with the licensees or is it that there's only so much in the terms of resources that you can provide? How do you make those decisions?
WH: Well, it really goes back to our gaming roots. We started Vicious Cycle to make games first and foremost and we don't want to lose sight of that going forward. And the effort to make games we need some really great technology, really awesome stuff that helps us make better product. And we love to share that with people out there and we want to create that revenue stream, but we don't want engine licensing to become solely what we are.
And obviously that leads into the question -- there have been some criticisms of Epic, that since they started out as a developer and their priority at times can be on their own titles, they haven't been able to provide the kind of support that is consummate with the product that they're offering. How does looking at things like that, those kind of criticisms affect you?
WH: We go into every new relationship with a developer that's using our technology saying that we're not a professional services group. If we need a feature in our products, you're going to find that feature in the technology, in the source code that you receive from us. But we're not here to write specific features for you. And I think having that stated up front has facilitated the process all along. And honestly we've had no complaints about our support.
In terms of the engine itself, how specific is it to a genre? The only game that's currently -- correct me if I'm wrong -- been shipped on it is Eat Lead: The Return of Matt Hazard, right?
Douglas Cox: For VE2, yes. Basically the underlying gameplay systems and everything in our scripting system and all that hasn't changed from the previous one, so there hasn't been any specialization in VE2 just for third-person, first-person shooter games or anything like that. So it's still possible to make various genres with it.
WH: In VE1 we've built many different types of games. Everything from first-person shooters to side-scrolling kids' products, to a strategic card game, for instance. I think that's the testament of the flexibility of the tool set.
In terms of the tools, what kind of tools ship with the engine? And do they allow for real-time editing? That's just very much a serious and important facet of things like Unreal and Gamebryo.
DC: Well, as far as tools go we've got exporters for Max, there's exporters for Maya that are in progress -- basically the full set of tools that you need to ship your game. All the localization and type utilities and stuff like that are there. Some tools for handling VO and all that kind of stuff are there. There's an asset manager that helps you manage your assets -- check-in, check-out files, all that sort of stuff.
As far as real-time editing goes we have -- most people run right with the game and editor open. As far as what you see in the editor when you make changes to placement and affinities and place any triggers and all that sort of stuff, you see that. Any changes to materials you see immediately when you're editing the materials. If you export something out of Max you'll see that reload automatically in the editor, so you get those kind of changes. And there's still script changes and stuff like that right now; you basically you can restart your level with the game still open and continue flying in and see what changes you've made, as far as that goes.
In terms of support for things like networking and more advanced genres: Obviously as you move from the prior set of platforms to the expanded set of platforms, the demands are going to be much higher. Especially if you're someone that wants to make a really competitive Xbox 360 multiplayer title. So is that something that you handle pretty effectively in your tools right now or is that something that's more got to come from the developer who licenses it?
DC: Actually, right now one of the next major features we're working on is improving the multiplayer stuff. In the past we've had support for it. Robotech Invasion was kind of the first thing we did with it. We had up to eight people on that and that was mostly deathmatch, team deathmatch kind of game.
There was Spy vs. Spy, that was fewer people but had a good bit more platforming elements to it so there were puzzles and traps and little things like that that had to be kind of synchronized across the clients and server.
And then there was also the Marvel card game we did which was more of lock-step type game where it was obviously quite a bit different than first person shooter action. So there's some changes that we made for that game as well.
The latest changes we're making are all about trying to get higher player counts and better use out of bandwidth and stuff like that. Basically trying to get as many people as bandwidth will allow on a game.
Is it something that can be packaged up small enough to be included for, say, a download game on XBLA or PSN effectively?
WH: Absolutely. Yeah, it's been used on one or two WiiWare products at this point, a couple XBLA titles. We may even be working on something right now that we can't talk about. So, yeah there's definitely the power to make that happen. Though you have to be smart about it and organize your game assets perfectly to facilitate that. You know, not have 12 different levels each with their own set of textures, and blowing that memory.
DC: Just from the download requirements that Microsoft has, basically. The more they expand that obviously the more games will come out that are not just tiny little arcade style games, I think.
Luke Hodorowicz: But the runtime footprint is really small compared to even the 350 meg you can have on an XBLA game, so that's really not a whole lot over it.
DC: Luke added some extended compression, file compression basically, so we can squeeze even more data in there now to meet the download requirements.
How have you found making the games' performance consistent over the PS3 and 360 within the engine? That's obviously been a real problem for developers to get; even up till now it's still a problem for some titles. Even things that shipped as recently as this holiday. How are you finding that?
LH: We try to run exactly the same assets on both 360 and PS3 and as a team we try to make them perform the same but that's not always possible. So we just have our team and level designers both play the game on whatever ends up being the slower console for whatever game we're making. Just so that we know performance is going to be good on those platforms. Obviously if you work on one platform or other, you can take advantage and do a little more with them but, yeah...
DC: Yeah, making cross-platform games takes a little bit of figuring out what's slow and then getting one the engine guys to optimize that then figuring out what the next thing is. It's not which piece of code's slow, now. It's which piece of code on which platform. There's just kind of a juggling act basically, and as they come in we optimize it and go on with what's slow next.
I think it took a little while to get everything set up as far as getting artists and level designers going with their machines, dev kits so that they can do daily builds if they wanted to to test their levels, and have them get the idea of where their performance is hurting. It seems to be going pretty well now. We've got a couple artists who seem to be pretty committed to checking performance and helping other people out with optimizations that they've learned.
WH: And you know another big key to it is what we refer to -- actually playing the game on the target hardware and not just playing it on the 360 and trying it out on the PS3 on milestone day.
DC: Yeah, testing it, alternating. Testing it on both consoles is definitely nice when you're doing that. So, just trying to get the process in place where people know they have to test each console. With our own internal testers, making sure there is testing both.
I could be making the wrong inference here but it sounds like it's saying that you're ironing out while you're developing the actual, the game, Matt Hazard. Is that what you're saying? And then that sort of became a solution that went more engine-wide?
WH: Well, you know VE2 is born from Matt Hazard; that's how we develop technology here. Like I said before, we need a feature, we build it. Well, we just happen to need a high-end current-gen engine so we built it around the old stuff, for Matt Hazard. As we worked on that game we've learned a lot of lessons for about how to develop games on the 360 and PS3 and by the time it shipped we think we've figured out a lot of good solutions.
DC: And Luke figured out how to write three or four different lighting and rendering engines. [laughter]
LH: We obviously had a period of time where we were getting acquainted with the new hardware and making sure that what approach we went with was going to look good and run well on both platforms. People complain that they're different, but once you get familiar with it I think you can get the same results from both platforms with pretty much the same speed.
The question it sort of comes back to is, how much is this controllable on an engine level? Because it sounds like you guys, your team had to do a lot of work to understand how to get those two platforms in sync in terms of performance. But then, for someone who licenses the engine, how much of that is taken care of, essentially?
DC: At that point, as far as our documentation goes we've got our guidelines. We've got some of our own internal guidelines that we type up for artists and level designers and things like that. One of the goals is usually to make sure that licensees are acquainted with the same guidelines so that if they go off in a different direction, then they at least have some reference on what has worked in the past or what worked for us.
I think actually us developing the game while we were working on the technology helped us a considerable amount because we were able to find all of those performance issues in different parts of the code and it's not just, "Well, Feature X runs great in a level by itself," kind of thing.
We try to document that, we try to answer questions on the forums and stuff like that whenever something comes up. It's really hard to have a flexible engine and not have licensees, obviously, put too many enemies in a level or something like that, that's going to kill performance. So they have to start from our guidelines and see which way they push technology for the game that they're making.
LH: And the evaluation comes with assets and rendering technology that we built here, so people will see exactly what we put together in terms of meshes, materials, shaders and that kind of thing.
Does the engine come with Matt Hazard?
WH: That's on the table for discussion. For instance, the VE1 comes with the first level of Dead Head Fred as an evaluation. I'd like to do something very similar with this. In the meantime until Eat Lead has run its course on the shelves, we have other assets in there that are pretty good and many of those assets are pulled directly from the game. They're provided at a very game-neutral level.
Hindsight is 20/20 and we're getting deep into this generation, but do you think that people were maybe optimistic to what extent a licensed engine could solve their problems?
WH: Yeah, I think there's some of that. I think many game developers, especially new ones think that most of the problems are around the technology. "If I only had a renderer I could make the best game ever!" But there's so much more involved in terms of resource management and allocating your memory pools appropriately and things like that that add up to the whole. Something as simple as, say, level design can have a huge effect on how your game performs on hardware.
DC: If you are asking, like, are there people out who are so optimistic about licensing an engine in general to solve their problems, I think, yes. Even though there's quite a bit of development done on this generation of consoles, there's still a considerable amount of work that we've leveraged from our past engine.
We've pulled together a group of our programmers and just said, "Let's start without knowing any history." You know, never having written a console engine. That alone is a huge task to undertake, I think. So, I think there are definitely people out there, like Wayne said, that may not have the huge programming staff that can figure out all the ins and outs of threading and PS3 and 360 tricks and stuff like that. They get all of the performance out of it, but have a good game idea. Those kind of people are definitely interested in licensing an engine and making their idea into a game.
And you think that's something that's feasible with VE2?
DC: We've seen it happen with the previous gen and tech and I don't think that there's any reason why people can't do it now. Especially some of these same companies that we've been licensing the old tech to, I think they've obviously got a good head start towards how our engine works and they're going to see a lot of those same things in VE2, and they'll learn how to make the new assets, create the materials, and stuff like that that you can do on the new hardware, and they'll just keep pushing it to its limits as far as making the best game they can make.