In our last post, I talked with the guys about why they decided not to use an engine to build SMB. Let’s see how that turned out…
Liane: So you were rolling your own tech, how was that going?
Christian: So, I think at this point we’re just over a year in, and we’re still drawing boxes. It’s taking a long time to do anything. I think the last three months we’ve spent building mostly asset importing and asset loading tools.
Scott: Let’s just point out that…the screenshots from the last post are basically a fullbright green, brown and white field that looks like something from 1984. So yeah…
Christian: And at this point I think we can load it really efficiently, and that’s about where we’re at.
Liane: What did you do to move forward?
Scott: We felt like we were climbing a bit of an uphill battle trying to do all this stuff ourselves. Because we were not working on the gameplay at all. But we knew we needed to get over this tech stage and move to something else, and a little looking around the internet for some possible solutions to this problem turned up an open source graphics rendering engine called OGRE that had a very active community and some very smart people working on it. It had also been used to build Torchlight, which was a pretty well respected PC and Xbox 360 game.
Christian: The other important thing at this point was that OGRE had just changed its licensing model from LGPL to the MIT license [both are free software licenses, but the MIT is more permissive]. It meant that we were actually allowed to use their stuff to make a proprietary game.
Scott: It was well known at the time that using LGPL licensed stuff was a bit of grey area for this type of software. So having OGRE go to MIT was an opportunity to kind of do whatever you want with the code and not have to worry about it.
Christian: Yeah, but of course for us, this would mean throwing away all the stuff that we were just talking about before. Like, this is a graphics engine and it has its own asset importing tools and that’s what we just spent a whole bunch of time building. So, it was a very, very hard decision to try and change over to this, and throw the work that we had just finished right in the garbage.
Scott: Yup. It was a sad realization that all of our effort had resulted in a set of stuff that did only a few percent of this other package. It did those few percent pretty damn well but it needed to do more, quicker.
Christian: And the other thing that we were worried about at the time, this tied into our other post about our naivety, where we thought we were actually in a better position to make something that runs on consoles, and we were worried that switching over to OGRE would put us in a position where we were stuck on technology that would be very, very hard to port to consoles, which was our ultimate goal.
Scott: But at the end of the day porting our own stuff to consoles was probably going to be pretty hard, too, so we said "well, considering our background [not being in game technology], we should probably start with something that’s a little further along."
Here's a look at what they were able to create using OGRE.
Liane: Let's talk about the assets that got replaced.
Scott: I used to do some Quake levels [Quake III Arena, a first-person shooter by id Software] as a hobby and so I’d taken on the role of doing programmer art at the time, and started whipping up some pretty crude stadium ideas in SketchUp [a 3D modeling computer program]. Which, by the way, would have been an amazing tool for making Quake levels, back in 1999.
Here are some screenshots from the work Scott had done in SketchUp.
Scott: We had some crude prototypes in SketchUp and also in Blender [an open-source 3D computer graphics software]. I didn’t really know how to make a character or character rig but we just figured we could get started with that. I eventually accepted the fact that our path would be a little easier with one of the more widely used commercial packages like Maya or Max [3D computer graphics programs]. The reason that Max was chosen was actually because I had read it might be a little easy to get started with. So we had ordered ourselves a $6,000 copy of Max, which was a bit scary at the time. I’d starting whipping up some sort of crude renditions of what Hammer Longballo could look like and what our various characters could and might look like. As well as trying to get this rough model rigged a little bit so he could swing.
Christian: And in addition to throwing all of our runtime asset loading code in the garbage, we had this little tool called AssetForge, which was like an offline asset baking tool, which was also thrown straight in the garbage. It got replaced by a tool called OgreMax, which basically let us export stuff out of 3ds Max, into a format that we could run and use in OGRE now. So, like a year in, there’s two huge chunks of work that got thrown out.
Liane: Let’s talk about what it looked like now that you had a rendering engine and some art.
Scott: It was a lot of fun seeing the pieces come together, because the heads and the bodies were separate pieces in our art files.
Christian: We now had tools that we could do a lot more with. But we still had a pretty steep learning curve. If you look at some of those screenshots, I think the way that the heads are attached to the bodies was changed about three times. It sounds kind of trivial talking about it but if you’ve never done it before and you’re trying to figure out how to use the art tool, how to get the art out, and then how to put it together in the game – it actually took a lot of work.
Scott: It was probably a couple of weeks exclusively spent on welding body parts together, at the mesh level.
Christian: Yeah, which got thrown away again. But as you can see in screenshots, it started looking a lot more like a game really quickly because we got to make prettier art. But it also let us experiment with more time wasting things.
Scott: So we had this powerful rendering engine and art pipeline... it was a blessing and a curse at the same time because it started a slippery slope of us obsessing over production quality. And our ideas of building a simple crude indie game evolved into trying to do more and more and more and more, regardless of how few people we had to do it.
Liane: You wanted to talk about this screenshot….
Christian: So what we’re looking at here, these characters are still completely dumb. There’s nothing baseball here. For at least another two years, this is what the characters do. They stand in grids, near home plate, while we try to make them do stuff. In this screenshot, we were trying to get the ‘look-at’ to work right, as in the characters can look around and their eyeballs can move around. So we could move a ball around in this scene and the characters could all look at it. So instead of spending time on actually making a game, we were spending time on things like this.
Scott: This is the part of our journey where we build baseball-themed game technology but no baseball game.
Liane: And this screenshot...
Christian: This is lit in real time, these clouds are drawn in a really fancy way, they’re like these real time clouds that move about. It’s lit in real time, those are all real time shadows, the sun could move about. This was a two week project, that I spent a bunch of time on trying to see if this was something we wanted to do. So this is just one example of the things that time got spent on.
The other notable milestone around this time was moving the two-man operation from the basement into a 300 sq ft downtown (Victoria, BC) office space. Both living and working in the same house was getting old, so this was a much needed change of scenery.
In the next post we'll talk about their first actual demo of the game. In the meantime, leave your questions about this phase of the project in the comments section below - the guys will do their best to answer!
See this post on our blog here.