3D Terminology
July 4, 2010 by pekuja · Leave a Comment
With the 3DS coming out and with Sony rolling out stereoscopic 3D support for PlayStation, I think the term “3D” is starting to get a bit confusing. I thought games had been doing 3D for years now! Battlezone did it 30 years ago! Doom, Quake, Mario 64; did we forget about these?
Of course, none of those games were stereoscopic 3D, but if we keep calling both kinds of games “3D”, it’s going to get really confusing. I propose three distinct terms:
- 3D games / 3D gameplay: This is what we’ve had ever since Battlezone came out. Really became popular with Doom in 1993 and the PlayStation console in 1994.
- Polygonal 3D graphics: Introduced by Atari’s I, Robot, really became popular after Quake and Mario 64 in 1996. These days polygonal graphics are hardware accelerated and offer a lot of flexibility, so a lot of 2D games like New Super Mario Bros. and Trine use them as well.
- Stereoscopic 3D: Was probably first done in games by 3-D Worldrunner on the NES. Was tried again by Nintendo with the Virtual Boy, which didn’t really work out. Is now coming back with the Nintendo 3DS and with support in televisions and home consoles.
What I would like to achieve here is to stop the ambiguous use of the word “3D”. Currently it means three different things in games. I propose the use of “3D game” be reserved for games with actual three-dimensional gameplay. This includes games like Wolfenstein 3D even though the in-game objects were flat and there were no elevated platforms. It does not however include games like Viewtiful Joe or Bionic Commando ReArmed, in which the gameplay happens on a 2D plane. Some people call these “2.5D”, but I would just call them “2D games”.
Some 2D games do use polygonal 3D graphics, which is why I would say it like it is: “polygonal 3D graphics”. This is merely a technique for creating graphics and putting them on the screen, and can be used for both 2D and 3D games alike.
Finally, what everybody is buzzing about, and what triggered me to write this post: stereoscopic 3D. It is the visual effect of showing the player’s eyes different images to create the perception of depth. It is not a requirement for 3D gameplay, nor does it require the game to be presented with polygonal 3D graphics. It is it’s own thing, and we should call it such: “stereoscopic 3D”.
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 26: Grenade jumps
February 12, 2010 by pekuja · Leave a Comment
Well, the new feature isn’t so much grenade jumps as it is the fact that explosions have a blast force that pushes you away from them. It’s probably exaggerated for the simple grenade here, but allows for some nice jumps, which is nice. You do take full damage though. It might be a fun feature though, so I’ll consider adding a low damage, high blast force grenade, or make you take less damage from your own grenades. Making this work properly also required me to adjust the walking physics a bit. Earlier I was just setting the X velocity of the mole directly, which would of course mess up the momentum caused by the blast. Now there’s a bit of acceleration up until a maximum speed, and a simple friction model so that the mole will slow down a little bit every frame if it’s on solid ground. No bunny hopping though, but I guess I could add that on purpose. 
I might also add gun recoil tonight while I’m at it. Should be pretty simple at this point. I also really should start implementing the grappling hook soon. It’s a pretty major feature, but then again, maybe I should embrace mobility with grenade jumping instead.
Day 25: Grenades
February 11, 2010 by pekuja · Leave a Comment
The game got its second weapon today. It’s a basic grenade. The red circle in the screenshot is the explosion. I should really make a better explosion effect, but that’s not important right now. The grenade bounces pretty nicely off walls, and deals more damage than the assault rifle. With the introduction of the grenade, the player can now switch weapons with the face buttons on an Xbox 360 controller, with more crucial functions on the shoulder triggers and bumpers, so that you can keep moving and aiming while jumping and shooting, even though you have to stop aiming to switch weapons. A pretty decent tradeoff I think.
I had kinda promised to make a pre-alpha release over the weekend, but I decided against it because currently not many people could enjoy the game because you basically need two Xbox 360 controllers and a friend to play against. I am realizing that this won’t be a common setup for people, so I’m hoping to create an online multiplayer mode for the game, although in a lot of ways the purpose of this project is to create a game much like Liero that you could play with a friend in the same room without the limitation of having to use a jam-prone keyboard to play.
Implementing a couple more weapons should be pretty easy with my current codebase. The remaining major hurdle is implementing a grappling hook or “ninja rope”, if you will. It’s going to be an essential part of your mobility in this game. On the ground, you’re slow, so you’ll want to use the grappling hook to fly through levels that have been blown to smithereens.
Day 24: Splitscreen mode, some initial HUD elements, random levels, death
Quite a bit of new things this time. To make the game more like an actual game, I’ve added health meters to the players. They will die if their health reaches zero, granting the opponent a single point, and relocating them in a random location on the map. For this functionality to actually make sense, I’ve also added initial HUD elements that show the player’s name, health and score. And regarding randomness, I have now added randomly generated levels. I randomize some holes into the map, place some random rocks, and that’s pretty much it. When a player spawns into the level, an appropriate hole is created. While I was at it, I added a split screen view and made the level larger than the screen. No minimap yet though, so it can sometimes be kinda hard to find your opponent. I’ve also made some initial sound effects with sfxr, but I’m not quite happy with them yet, so I’ll probably have to think about them some more later.
Day 23: Simpler collision detection, arm redrawn
February 5, 2010 by pekuja · Leave a Comment
After struggling with the collision detection and response, and after realizing the collision detection was the single most expensive thing my game was doing each frame, I decided to switch to a simpler method. Madgarden had earlier suggested on IRC that I should try a plus-shaped collision shape. One vertical line of pixels, one horizontal line of pixels. This seems to work quite well, especially since I can keep checking pixels until I find a large enough area to fit the player sprite. That means that determining the player’s new location can be done at the same time as detecting whether there’s a collision at all. The only real problem I’ve noticed so far is that I can’t make the player climb steep slopes, because he needs to have ground directly below him, so steeper slopes than 45 degrees just are unclimbable due to the nature of the collision shape.
Another thing I fixed was the mole character’s arm. I had previously made the arm a part of the gun sprite, so that the arm would rotate when you aim. The rotation looked ugly though, especially since I couldn’t use any filtering on it as that would make it not fit in with the pixeled main part of the sprite. The solution was to draw a higher resolution version of the arm and gun, and use that unfiltered. This improved the results a lot, and also made me wonder whether it would be feasible to make higher resolution graphics all around. I think I’ll pass on that for now though. Maybe later.
The game is still lacking some core stuff. Namely, the players don’t take any damage or die, there is no score keeping, and there is just one weapon. That’s probably the order I’m going to start implementing these in. After I have those, the rest is all polish. I’m hoping to get some sort of a pre-alpha release out this weekend.
Days 20-22: Global Game Jam
Well, I kinda forgot to post during the weekend, but I attended the Global Game Jam. Specifically the local jam in Tampere. The event was very well organized and we had lots of fun. Our group was three people: Vilma Pekola as our visual artist, Juhani Hujala as our game designer, and myself as the programmer.
We went with a sort of mix of 2D and 3D for the visual style. The game is in three dimensions with perspective, but all the graphics in the game are flat, like a pop-up book. The game was put together using the Unity 3D engine. Most of the code is in C#, but some of it is Javascript. I think Unity helped a lot in putting the game together. We got some of the core elements into the game in just a few hours. The most interesting part code-wise for me was probably the string with the lanterns. I started out trying to make it a physical chain of little nodes, but it had problems, because the string would fall to the ground or act up when pulled around corners. The way I ended up implementing it is to just have the string and lanterns floating in the air, but I did attach them to spring joints so that they would sway a little, like wind was moving them. Another cool thing I added was to make the buildings turn translucent when you walked past them. That way you could still see what you were doing when you were behind a building. In retrospect I should had probably made that effect even stronger, but it works decently well even as it is.
The game is quite short and simple, but then that’s usually what you get when you have a 48h time limit. I’m very happy with the result though, as it is a complete game, and not missing any necessary features. When you’re working quickly like this, there’s always a high chance that you end up not having the time to implement some crucial thing, or that something breaks at the last minute.
The game is playable at: http://heygods.pekuja.com/
The game’s page at the GGJ site is at: http://www.globalgamejam.org/2010/hey-gods-follow-light
Day 19: New main character
January 28, 2010 by pekuja · Leave a Comment
I was thinking that the worms are kinda boring looking and make the game feel like an exact Liero-copy, which it doesn’t have to be, and probably won’t be. So I’m making it a MoleZ clone instead! Just kidding, but I did draw a new player character sprite that’s a mole. I kinda like it, although I need to work on it still. I think I’ll make the mole hold the gun single-handed to avoid having to figure out how the other hand should move in that case. I do need to animate the feet, and maybe make the nose bob around a bit when he runs. I think maybe since his other hand is free, I could make it wave a little when he digs. I’m liking this character a lot better already. Lots more possibilities for expression. Not that worms can’t be expressive, but I think they’d start looking a lot like the worms in Worms if I made them all cute and expressive. You may notice I also added drop shadows to the level. I might try them on the characters too. It’s pretty easy to do with OpenGL.
Day 18: Collision woes.
January 28, 2010 by pekuja · Leave a Comment
Well, I decided to ditch Box2D for this project. I could had probably made it work somewhat, but it’s probably a bad idea to try and vectorize a pixel based map like that. What I’m still pondering about is if the game would work better or at least as well with completely vector based levels. That of course does make level creation and destructibility a bit harder, although for the level creation I could still utilize bitmaps and the marching cubes algorithm though. I just wouldn’t be using it for the internal representation. The upside would be that in-game physics would be easier. I’ve now gone back to my own collision detection code and physics. It does work, but sometimes the worm gets stuck on things, or can’t jump even though it should be on firm ground. Of course, even with vector based levels I’d probably have similar problems. I just feel like in some ways working with vectors might be simpler because they are accurate. With pixels I need to basically make guesses about angles and such. Currently I try to guesstimate what direction the “wall” of pixels is, and I push the worm out bit by bit until it no longer collides with the map. If that doesn’t work, I just put the worm back where it was on the previous frame. I think that method might actually be more complicated than it needs to be, so I might still change it to something simpler that might work for the benefit of the playability anyhow.
My code is a lot better organized after this whole escapade. I’m only just now roughly at the point I was before I started though, but at least the collision detection is better now.
Day 17: Insert Löve pun here
January 25, 2010 by pekuja · Leave a Comment
So, today I decided my code was too much of a mess, so I would refactor and clean it up. I also thought at this point that it would be a good idea to start using Löve’s built-in physics engine (Box2D) instead of doing my own physics, especially since later I’ll want grenades to bounce from walls realistically for example. In order to achieve this, I needed to vectorize the bitmap based level. That in itself was not a big deal. I had done a marching cubes implementation before so I had reference material, even though my old code was in a different language. Anyways, after writing the algorithm up, I found that it still wouldn’t run. Turns out there’s some strange problem with using very small or slim polygons in Box2D. I’m not completely sure what the exact problem is or how to fix it. The comments in Box2D source code say “Shifting the edge inward by b2_toiSlop should not cause the plane to pass the centroid.” and “Your shape has a radius/extent less than b2_toiSlop.”. After those comments there is an assert that fails and stops my game from running. It’s apparently something to do with continuous collision detection.
On top of my Box2D woes, I was constantly annoyed by the lack of documentation for Löve. Some functions have no documentation whatsoever, which makes it all but impossible to use them. The physics engine is probably one of the most problematic cases, especially since I don’t have a lot of experience with physics engines in general.
Currently I’m not quite sure how to continue. I hope I can make Box2D work for me somehow, because even if I ditched Löve, I’d still need something for the physics. Chipmunk maybe? Or I could just roll my own. Not like I need anything fancy.