BS: You sort of have a bit of the versus fighting arena stuff. It reminds me very much of [Treasure-developed Sega Saturn brawler] Guardian Heroes. It seems like Guardian Heroes is the basic model for Castle Crashers.

TF: It's weird, 'cause, it's in the spirit of Guardian Heroes, but there's not a lot that's really that similar. Guardian Heroes was Street Fighter mechanics on two planes, kind of like a Fatal Fury thing, jumping in and out.

And it's completely different in the way Castle Crashers plays. But there's just something about the spirit of that game, the chaos and the cartoon graphics. That is sort of the same spirit as Castle Crashers.

BS: It's also thematically similar in terms of the multiplayer...

TF: The leveling up the character stuff.

BS: The way you level up the character, choose the stats. And once you unlock more characters, you can play them against each other in the arena. There are a lot of parallels to be drawn.

TF: Yeah, and some of that was intentional, and some of that actually just sort of happened. But that game's definitely one of my faves -- everything by Treasure, I always say, is one of my biggest faves.

BS: A lot of it just makes sense for that kind of game. So why not use it?

TF: The character stuff was an organic thing. "Oh, we've got all these characters, let's make them playable."

DP: See, I'm always out of the loop on that one. I didn't play Guardian Heroes. My inspiration is River City Ransom. I like that game, I really like it.

BS: But you can't pick up dudes to throw them at each other in Castle Crashers.

DP: You can pick guys up in River City, but they've got to be on the ground.

American Technos' River City Ransom

BS: You can pick up the other players, so you can throw them at each other!

DP: Yeah, you can. I wanted to explore that. But, you know -- there's always things I want to explore -- there's a billion things in that game that I wanted to do that I didn't do. Just 'cause there was too much.

If you added everything Tom and I wanted in the game, I think I can't even imagine... I can't even imagine what that would be like.

BS: Did you try implementing some of those ideas?

TF: We're always tinkering with little things that don't quite work right.

DP: We look at all the weak parts. We fill out all the weak parts. That's always what takes precedence. You know, this level isn't right, we need to do something with this level. And then that level takes precedence. When we're happy with player mechanics -- and they can always get better in some way, but once we're really happy with player mechanics, we start looking at all the rest of the adventuring and all the other stuff.

That's the way it goes. We make sure that there are no loose bolts. And I think that that sometimes takes the precedence, because you have to schedule it all out in a way where everything is cool, instead of really cool mechanics, but you play shitty levels. So, we have to balance out all the quality.

BS: What tools and development environment do you have? Both on the art and on the code side?

DP: I draw in Flash. We got a bunch of proprietary tools and export stuff. The game ends up in C...

TF: It's a big mash-up of Flash and C++ that it all comes down to. And really, we don't really use anything else for development.

BS: It's simple, not in a bad way. It's quite straightforward.

DP: It helps us focus on the things that matter. Instead of me having to worry about what dimensions an image is and whether I export it with an alpha channel or not. I don't have to think about that.

TF: On the original Alien Hominid we had to switch the way certain vectors ported over, so it became this whole thing of basically creating spreadsheets in Photoshop and cutting them out and rasterizing all these parts of Dan's art.

BS: Oh wow.

DP: I didn't even realize he was doing it.

TF: There was this ridiculous amount of stuff in Alien Hominid that was just like, it felt like weeks of rasterizing Dan's art 'cause it wasn't all converting properly. But now we got it all down to a proper science.

DP: Tom didn't want to bother me with that, so I had no idea he was doing it until the last couple of days where he had lost his mind. Because he's in Philly, and I'm in San Diego, I had no idea that was happening. But after he went through that, I guess we perfected it, right? We won't do that again, right?

TF: I didn't have to do any of that, this time around.

BS: In Flash, isn't collision detection really difficult to do, to get right and precise?

TF: It can be tricky... for the first Flash games, people used [Flash command] Hit Test, but I never used Hit Test because I'm still stuck in the old thought of when Hit Test was really too slow, and would slow down your stuff. So I just compare X and Y with input.

BS: It seems to be working okay. Just anecdotally, I know that a lot of Flash games have more of that than others.

TF: Hit Test is the easy way to go. And Hit Test really works well. A lot of people now can do platformers, and lots of people use Hit Test on the terrain. And they make it look so easy and effortless, but [with] the way I'd do that, it would be a big headache.

So, that's why I stick with straight lines and diagonals with my platformers. (laughter) But also, it could be why some of them don't always work as well -- but a lot is really down to tuning. Like, if someone just tunes it up well, they'll nail it, no matter how they do it.