Day 27: Robot 3D model
February 22, 2010 by pekuja · 3 Comments
Mini Ludum Dare 16 was held last weekend. I planned to make a game a bit like Canabalt or Robot Unicorn Attack, where your character runs forward automatically and you control certain actions, like jumping. My version was going to have a killer robot and more actions though. Unfortunately, I kinda got stuck working on this single 3D model and then wrangling with 3D model file formats, so I ended up not making a game at all. I did learn some useful things about 3D animation and file formats though.
The thing about 3D model formats is that there are a whole bunch of them with varying feature sets and support. One shocking thing I discovered was that there seem to be very few software libraries dedicated to loading 3D models. The two I found with support for more than one format are libg3d and Assimp. Other than that, the selection was very varied in completeness and quality. Nothing that stands out. Nothing that is really even designed as a library for other people to use. Mostly example code or stuff somebody wrote to match their own needs or just for fun. This really made me wonder about why that would be. Doesn’t everybody who makes a 3D game need such a library? It dawned on me, the answer is no. 3D model file formats are mostly written for the specific needs of the application that they were designed for. For a 3D modeling application, this is a very wide set of needs. Certainly wider, or at least very different, from what you might need in a game. It makes sense to design your own format for a game so that it matches the features you need in your engine. This way you also get to become very familiar with the process the model takes from the 3D modeling application to your game. This means that when doing the actual modeling, you know which features of the modeling app to use. This was one mistake I made when animating my little robot. I was using Blender’s constraint feature to parent the different pieces to each other and to restrict the movement of the feet so that they stay upright and don’t go through the ground. This information is lost when exporting to most formats. Amazingly enough, the FBX exporter is able to export my animation correctly, but there is almost no code or specs available for loading FBX files, because Autodesk keeps it on a tight leash, and their own SDK comes with a convoluted license agreement which I will not accept because frankly I have no clue what it means. Collada is another generic format, and it’s completely open, and XML based. Basically, the only problem with Collada is just that it supports everything under the sun, so it’s overkill for most games. It’s also XML, so the files can potentially grow pretty big, but then that’s what compression is for. Then there’s also the Quake family of model file formats. MD2 and MD5 are probably the most interesting ones. MD2 was used in Quake 2. It’s very simple and widely supported, but doesn’t have modern features like skeletal animation, and doesn’t allow for untextured models, which is what I was doing with my robot there. MD2 also requires the whole model to be a single mesh, which my model wasn’t. MD5 was used in Doom 3. It’s a more feature rich format, but not as widely supported. I couldn’t use MD5 either for this model because I wasn’t using skeletal animation. Another potential candidate for a file format would be Microsoft’s .X format, which was designed for use with DirectX games. It seems pretty decent. Seems like my model might actually work with it if I fixed the parenting of the different parts of the model.
I hope that wasn’t too rambling. I already rewrote it once because it started to get too rambley, but it ended up being at least pretty long anyhow. I guess the important things here are that you should be aware of the limitations of the file format you’re using, and be aware of how different features of your modeling program work with the chosen format. It’s probably a good idea to do all animation as skeletal animation unless it’s just not well suited for what you want. It’s easy to go from skeletal animation to vertex animation, but you can’t go the other way around. It’s also probably a good idea to prepare to texture map your models even if you’re just using solid colors, since some formats like MD2 require that. If you do feel like your game would be better served by using vertex animation and no texture maps, maybe you just need to design your own format that supports that setup. Know the limitations beforehand and keep them in mind when working. It’s hard to fix your model afterwards if you used an unsupported feature.
Day 11: Miscellaneous small stuff
January 13, 2010 by pekuja · 2 Comments
Well, today I’ve done some small stuff. I adjusted the gravity so that my character can jump two tiles high. I also toyed around with the level editor and made some platforms to jump on. Added a little concrete road block that’s just background graphics right now. It also doesn’t look much like a concrete road block because it’s just hard to make identifiable things in 8×8 resolution. I also added a little attack swoop animation. The character himself isn’t actually animated for the attack, it’s more like a little arc that appears in front of him.
What I’m realising again when trying to figure out what to do next is that this concept is kind of boring. Parking garages aren’t very exciting, and it’s hard to figure out interesting things to add. I could probably add some small details here and there, but as far as actual level layout elements go, I feel pretty limited. I don’t know, maybe I don’t need that much. I could just keep using cars and lamps for level layout. Will see. I do have some ideas for this design, but I’m just not feeling it as a whole, so I might take a break from it and pursue some other designs.
Day 10: Fixing the physics
January 13, 2010 by pekuja · Leave a Comment
Well, yesterday I worked on the physics, but they were still a bit broken. Now I feel like they mostly work like they should, although the code is still a bit messy. Yesterday, the character would be able to stand on walls, because the collision check saw the tile right next to him. I eventually fixed this by making collision checks and checks for whether the character has walked off a ledge two separate things. Before I was running into the problem that checking outside the character was wrong for collisions, but checking inside the character was wrong for standing. While I was at it, I got rid of all internal state for the state machine states (yo dawg), and instead store all relevant information in the player character’s object. Another thing I realized I needed for the collision detection, was checking which direction the character hit a tile in. Basically checking whether the tiles being checked against have changed, and in which direction, so if the character moved over a tile boundary on the left, and is now in collision with a tile, we assume that it was a horizontal hit, which currently will bump the character back right a little. If the character instead had crossed a tile boundary on the bottom, we would assume the character just landed on a tile and change him to a standing state.
Daily progress blogging
It’s 2010 now, and I looking back at 2009, I feel like I didn’t accomplish enough in game development. So, for 2010, I’m resolving to do something productive game development related every day, and blog about it. The rule is, I need to have produced some text, image, code, 3d model, or something like that. I will probably share some of that stuff here on the blog, but probably not all of it. I will however write about it all. The point of the rule is that I can’t play a game and call it “research” unless I write the research up and think about it. If I do though, it counts. I’ll try not to do too much of that. 
So, I guess the first post is due in 23 hours. I’d best get cracking!
Pekuja.com now using Wordpress
I’m transforming my website into a Wordpress blog. I figure I’ll update it more often if I can do it through a web interface.