48-Hour Contest 5: Article II
48-Hour Development Contest: Part I
[Published on GameCareerGuide.com March 18, 2008]
By Vishnu Desaraju
The University of Michigan hosts an annual game development challenge, in which small teams of students have just 48 hours to develop a video game. GameCareerGuide.com is running an exclusive five-part series written by the contestants about their experience making a game in just two days. In Part I, we meet electrical engineering student Vishnu Desaraju, who has twice in previous years been on the winning team.
The University of Michigan hosts an annual game development challenge, in which small teams of students have just 48 hours to develop a video game. The event is run by the campus' game development club, Wolverine Soft.
The 48-Hour Game Development Contest is one of my favorite events that our club puts on. I first participated in the contest two years ago, not knowing what to expect. Though I am studying electrical engineering, I don't have a particularly strong programming background, so I entered the contest as an artist. This was not a completely random decision on my part though, as I had several years of experience with graphics software such as Photoshop, 3ds Max, and Microsoft Paint.
The contest has a team balancing policy, which allowed my friend and I to partner with a very skilled programmer. We won the contest that year with a 2D top-down game.
The following year, I partnered with two other friends, one programmer and one musician, and took first place with a 3D side-scrolling game. So now, coming into this contest, expectations are high from other club members -- but no pressure.
Friday
6:30 p.m. Teams were just announced and the theme is to be unveiled at 7:00 p.m. I'm with the two people I expected to be partnered with: one friend, John, who is new to the contest and another friend, Dale, who is more experienced in programming and game development. Given Dale's experience, we will be using the Zenipex library, which was developed by the current president of Wolverine Soft and is the engine both Dale's team and my team used last year in the contest. Once again, I will focus primarily on graphics.
8:00 p.m. The contest officially started at 7:00. This year's theme is "Honoring Stephen Colbert." It's quite an unusual choice, given past themes such as "In your dreams" and "Fight!"
We go into the other room that was reserved for the contest and set up in there. Something that I learned from my first contest is to use the whiteboard that's provided for brainstorming. We start by listing several genres, game mechanics, graphics styles, and plot ideas and dedicate the next hour to refining these lists.
Our plan is to make a 2D side-scroller with pre-rendered 3D images for sprites. The environment will actually be 3D though, and the path will turn corners to give a feeling of depth. This odd blend of 2D and 3D will hopefully give us the graphical benefits of 3D art while maintaining 2D game mechanics, such as collision detection based on sprite boundaries rather than bounding boxes. The plot is this: President Stephen Colbert sends the main character to defeat bears and robots that are threatening to take over the country. The idea comes from Colbert's real attempt at running for president and plays on his apparent fear or hatred of bears and robots, as often described on his show. 11:00 p.m. The main models I have to create are a bear, a robot, and the main character. The bear will probably be the most difficult because I've done very little animal character modeling. I decide to model it first so that I don't run out of time to make it look decent. I also decide that the bear will be walking upright to make it seem more menacing.
I start by drawing a sphere for the head and modifying it to create other features, like the snout. Google's image search is a blessing for finding reference images. Modeling the head takes a little more than an hour, and I decide to animate the mouth before modeling the rest of the bear to make sure the head will animate well.
This proves to be a bit more complicated than I expected because rotating the jaw is causing some rather ugly interactions between the jaw and the head. Luckily, a bend modifier helps me to get a similar motion for the jaw without this issue.
For the next 90 minutes or so, I work on the rest of the bear's body. I try modeling the body as a separate object and then aligning it with the head, but it looks terrible. A few attempts even looked humanoid, so that's something to keep in mind for when I model the main character. Finally, I decide to extrude polygons from the bottom of the head and adjust those to create the rest of the body. So far I have a rough model of the entire torso, and it looks pretty good, or at the very least looks far better than my previous attempts.
I just started extruding some polygons from the body to create the arms, but we need to take a break and eat dinner before all the nearby restaurants close. Things seem to be going okay so far. Dale is working on setting up the environment and getting the camera to turn a corner while also rotating the sprite so that it faces the camera at all times. He seems to have taken the same approach I did: working on the difficult part while he's still fresh. John is working on the physics engine, which will hopefully save Dale some time. True to his training as an electrical engineer, he's implementing the engine as a series of second-order differential equations, which made our club president groan and shake his head when he heard about it.
Saturday
4:00 a.m. After dinner, I make some minor adjustments to the bear's upper body, and I finish the arms and claws. It's not too bad so far, with this method of extruding some polygons and adjusting their vertices, but I'm a little concerned about how easy it will be to animate.
I also decide to add hair of some sort because the bear was looking rather bald. I try using a bump-mapped hair texture, which doesn't work very well. So I fall back on an odd technique I learned for modeling grass, which I had also used in the contest two years ago to create facial hair for our title-screen image. I create a small, thin triangle and use the scatter tool to scatter thousands of those triangles all over the bear.
3ds Max has a cap of 65,000 instances for the scatter tool. That's a shame, but I suppose it looks all right, albeit a bit like a porcupine.
I also end up crashing the program once or twice with "out of memory" errors. That's one problem I would not have imagined encountering had we decided to do true 3D graphics instead of pre-rendered sprites.
While working on the hair, I realize the bear is missing two very important features that would help it look more like a bear (someone commented that it looked like a rodent at one point): ears and teeth. These are easy enough to add, although the teeth refuse to stay attached to the lower jaw, so I end up having them float along with the jaw as it moves. It's a bit of a hack, but hacks are standard fare in the 48 Hour Contest.
Dale had been having some problems setting up the camera in the scene and getting it to turn the corner without altering the zoom or angle, but I think he figured out most of it. Hopefully, implementing the solution won't drain too much more of his time.
We need to work on more gameplay aspects. John seems to have gotten projectile motion to work, as well as recoil from firing a projectile, and he has moved on to collision detection. I guess he's planning to work through the night to make up for the fact that he will be away for most of Saturday and part of Sunday due to other commitments. So ends the first night of the contest at the fairly typical time of 4:00 a.m.
4:00 p.m. I had a meeting off campus this morning that went longer than I expected, so I didn't make it back until 1:00 p.m. Before leaving for my meeting, I did stop by the room to get an update on John's progress before he left. He had the physics engine working well and also had collision detection working fairly reliably. As he explained his work to me, I realized that most of it was hard-coded, which means it will take a bit more work for Dale to abstract it into a proper class structure.
After returning from my meeting, I update Dale on John's progress and resume my work on the bear model. I set a goal of finishing the bear by 3:00, since all I have left to do is make the legs and animate the animal. Making the legs is almost identical to making the arms and takes very little time. But setting up the animations takes much longer. I try to animate the arms the same way I did the jaw, but with not as much luck. I eventually set up animations using several bend modifiers applied to various sub-sections of the bear mesh. This produces an ugly hierarchy of edit poly and bend modifiers that, if not set up correctly, could lead to the entire bear bending, rather than just the arms.
Nevertheless, my self-imposed 3:00 deadline has passed, and I decide to stick with this hack rather than waste more time trying to find a cleaner solution. The legs caused even more problems, as the technique I used for the arms did not work as well for the legs.
I settle for a twist modifier applied to the entire bear but constrained to mainly affect the legs, resulting in a shuffling walk of sorts. Normally, animations like this would be done using a bone structure, but based on my bad experiences with bones in the past I hoped using modifiers would be less error-prone. That clearly has not been the case, but at least the bear is done now and I'm only an hour past my original target.
8:00 p.m. The contest is now at the halfway mark and the pressure is starting to build. Dale is having more problems merging John's work than we anticipated. Earlier in the day, he decided to stop working on the camera after getting it to work correctly for everything except turning corners. He was able to set up the program to load scene data and character placement from text files, which will make level design much easier later.
People from other groups have stopped by on occasion, wondering why we were working in a different room and also curious as to how our game was progressing. I guess no one else heard the announcement made at the beginning of the contest that teams were free to work in either room.
I go and look around at a few other teams, and I think we're doing all right, although we could be in trouble if programming difficulties continue to plague us.
After finishing the bear, I start on the robot model. I had originally planned to make the main character next but feel that I need a break from making organic models after the headache of trying to animate the bear.
Once again, I start modeling the head, but this time using only simple shapes to achieve a more artificial look. I base the head and upper torso on pictures of a USB robot camera that I found while browsing image search results for "robot." After a short snack break around 5:00, I add arms and legs to the robot, again using basic shapes. Geometry-based modeling is so much easier than the polygon- and vertex-level work I did on the bear.
By 7:00, I have the entire robot modeled. It doesn't look particularly evil or even potentially harmful at first, but the spikes I add to the arms and the rocket-launcher sticking out of its chest should resolve that. I also decide to use bones this time to make animation easier. Unlike the bear, the robot's arms and legs are separate meshes, so I just have to link each mesh to an individual bone. That much I'm comfortable with when animating using bones.
In the next half hour, I set up all the animations for the robot's arms and legs. Two models down, one to go, and it's time for the group dinner.
Sunday
3:00 a.m. When I started the character model, I tried several approaches to making the body, such as drawing a silhouette and extruding it. However, after spending nearly an hour trying various ideas, I settle on modeling the entire character from the head down, just as I did for the bear.
The one aspect of the character model I had planned out from the very beginning was the face. I start with a slightly squashed sphere for the head and add a capsule shape with a taper modifier for the nose. The rest of the face is just a bitmap image that I drew in Microsoft Paint. All I have to do is apply the image to the head, check whether the eyes, nostrils, and other facial features have to be realigned, and update the image file as necessary.
This is a trick I figured out in the 48-Hour Contest two years ago, and the end result this time was exactly as I expected it to be. From here, I extrude polygons to form the neck, shoulders, upper body, and arms. Within three hours, I have half the character modeled.
At this point, I try my hand at animating the arms to see whether it will be worth it to continue with this model. Having learned my lesson with the bear, I decide to use bones this time, and after about an hour of trial and error, I finally get the arms to bend correctly. During this time, I draw several confused looks from Dale and others who stop by as I say out loud things like, "I guess moving bones after attaching them to the body is a bad thing."
Shortly after midnight, I model the character's lower body and legs, and by some stroke of luck, I am able to set up bones in the legs very easily. I put the final touches on the main model. In the morning, I'll start modeling his accessories and weapons.
I've helped a few people with Photoshop and 3ds Max problems for their own games over the course of the night, and we've had a few people try to figure out some of the more unusual programming problems we've had. This highlights a key feature of the contest that I've noticed every year: it may be a competition, but it's a friendly competition, and contestants are just as willing to ask for help as they are to give it.
12:00 p.m. I get back around noon feeling considerably more rested than I did the day before. At home, I looked up a few tutorials on making an Indiana Jones-style hat and a light saber, and now I finish both models within the hour. We decide the main character should be armed with both a light saber and the "Colbert cannon," both throwbacks to various episodes of the television show. While modeling the cannon, I realize that I haven't given the character hands yet! Taking some inspiration from Lego figures, I simply make a claw shape out of a sphere and then design a material for it in Paint that will give the appearance of having fingers.
2:00 p.m. By 2:00, I finish these accessories and start animating him. I have a few problems with the arm joint around the shoulder deforming incorrectly as the character swings the light saber, but that is easily fixed by adjusting the bones.
I suddenly realize we needed a projectile for the Colbert cannon to fire, so I "model" a presidential campaign button, rather, a rounded disc with Colbert's picture on it.
With four hours left in the competition, I think I'm done with the modeling and animation. I just have to render a few frames of each animation from the same camera angle as we're using in the game. Unfortunately, other areas don't seem to be going as well. Dale has been trying to add in the physics engine and collision detection systems but has been encountering bugs almost continuously. Trying to abstract John's work so that it can be applied to multiple objects on screen has not been easy, especially with hard-coded dependencies between objects such as the projectile and the character. There have also been a few instances in which both of us have stared at his code trying to decipher his logic, but with little luck.
John won't be able to make it back for at least another hour due to transportation issues. Hopefully, he's had some luck finding music and sound effects, since that's about the extent of off-site work allowed by the contest rules.
6:00 p.m. Right after I finish the models, I download a copy of the base files Dale was working on and start testing my renders to make sure the camera angles match. I start with a Washington, D.C. level and find some high-resolution images of the White House lawn for the background and ground. I also model a hedge for the character to jump over by adding a strong noise modifier to a box. However, when I add the images via Dale's level editor setup, all the images appeared mirrored.
We hadn't noticed this bug earlier since Dale had only been using placeholder art and had not verified orientation. It takes me the rest of the hour to get images to display correctly by tweaking the code and the level setup files. Although the camera angles in my renders match up with the scene camera, I find a problem with collisions that we should have anticipated. All our collisions were done using the bounding squares for the sprites, which works well for horizontal collisions. But by rendering all our images at a 45-degree angle above the horizontal, we can no longer use the top of the image as a realistic bound for collisions on top. In other words, when jumping onto an object, the character will land on the back of the object rather than inline with the plane of motion.
While the ideal solution would have been to recode collision detection and set a different vertical bound, this is by no means practical with little over two hours left in the contest. My temporary solution is to scrap our pseudo-3D idea and render everything from a side profile view, essentially creating a regular 2D side-scrolling game.
This fix considerably improves how the collisions look. There is also a slight flaw with the character design: His legs were in the center of the bounding square, leaving empty space on both sides that was still being checked for collisions. This calls for another quick fix; I add a "hover board" for the character to ride. It spans the width of the image and makes collisions seem more realistic while jumping over objects.
In all this chaos, I nearly forget to render the bear, robot, and projectile sprites from a side view.
Despite countless problems, Dale has implemented most of the collision detection and physics by now, and has started setting up the game states, title and ending screens, win-conditions, and so forth.
John returns around 4:30 with a bit of good news. By some lucky chance, his brother has just recorded some great instrumental tracks and is happy to let us use them (music is allowed to be from external sources, as long as copyrights aren't violated). So John works on setting up background music and also records a voiceover for the title screen to explain the plot. He then takes over level design while I add the hover board to the character model and started rendering. Now we have one version of the game on Dale's computer with the most up to date collisions, physics, and game states, and another on John's computer with older versions of the game mechanics but with sounds and a basic level. All that's left is combining them, and we should have something presentable when the contest ends in an hour. It's the epitome of crunch time.
7:10 p.m. Luck has not been on our side this year. The contest is now officially over and all we have is some sort of demo with virtually no gameplay. Things seemed to be going well right up until John left for a quick dinner (his parents were in town and he wanted to have dinner with them before the judging started). Dale had copied over all John's work and had added in the sound and new level files. He also added in the title, win, and lose screen images that I had made in Photoshop. But when he tried running the game, the level loaded as a black screen with background music. For some reason, none of the images were loading correctly although they had worked fine on John's machine.
With just minutes before the end of the contest, I run down to the restaurant and drag John back to load up his copy of the game for judging. Dale had a backup version of the game that we could have used, but John's version had the same game mechanics plus graphics, audio, and a simple level.
Thankfully, his version is now up and running on one computer. However, since no changes can be made to the official submission after 7:00, we'll have to run it directly from Visual Studio. This means we won't be able to set up in the other room, and I will have to post a sign to let the judges know where we are set up. I think Dale wants to keep working on the game so that, if he's able to fix the bugs in time, we'll be able to show it to people as a non-judged version. I don't think I'll be of much use for that, so I'm going to see what the other teams came up with and see if there's any hope of us not finishing in last place.
10:00 p.m. A bit of a positive twist came at the very end. We placed 12th out of 15 teams, the highest ranked team with an incomplete game. I guess the judges liked our physics engine, graphics, audio, and incorporation of the theme. Not surprisingly, incomplete games are fairly common during the 48-Hour Contest, but most teams will eventually complete their games, to some degree, in the following weeks. At the very least, we will. This has certainly been a different experience for me compared to the past two years. If I stay at University of Michigan for graduate school, I'll definitely enter again next year, but if I go elsewhere, I may have to make a trip back to Ann Arbor just for this, if I have time.
Vishnu Desaraju is a student at the University of Michigan and publicity coordinator for Wolverine Soft. His team's game placed 12th out of 15.
Original Article on Gamecareerguide.com
[Published on GameCareerGuide.com March 18, 2008]
By Vishnu Desaraju
The University of Michigan hosts an annual game development challenge, in which small teams of students have just 48 hours to develop a video game. GameCareerGuide.com is running an exclusive five-part series written by the contestants about their experience making a game in just two days. In Part I, we meet electrical engineering student Vishnu Desaraju, who has twice in previous years been on the winning team.
The University of Michigan hosts an annual game development challenge, in which small teams of students have just 48 hours to develop a video game. The event is run by the campus' game development club, Wolverine Soft.
The 48-Hour Game Development Contest is one of my favorite events that our club puts on. I first participated in the contest two years ago, not knowing what to expect. Though I am studying electrical engineering, I don't have a particularly strong programming background, so I entered the contest as an artist. This was not a completely random decision on my part though, as I had several years of experience with graphics software such as Photoshop, 3ds Max, and Microsoft Paint.
The contest has a team balancing policy, which allowed my friend and I to partner with a very skilled programmer. We won the contest that year with a 2D top-down game.
The following year, I partnered with two other friends, one programmer and one musician, and took first place with a 3D side-scrolling game. So now, coming into this contest, expectations are high from other club members -- but no pressure.
Friday
6:30 p.m. Teams were just announced and the theme is to be unveiled at 7:00 p.m. I'm with the two people I expected to be partnered with: one friend, John, who is new to the contest and another friend, Dale, who is more experienced in programming and game development. Given Dale's experience, we will be using the Zenipex library, which was developed by the current president of Wolverine Soft and is the engine both Dale's team and my team used last year in the contest. Once again, I will focus primarily on graphics.
8:00 p.m. The contest officially started at 7:00. This year's theme is "Honoring Stephen Colbert." It's quite an unusual choice, given past themes such as "In your dreams" and "Fight!"
We go into the other room that was reserved for the contest and set up in there. Something that I learned from my first contest is to use the whiteboard that's provided for brainstorming. We start by listing several genres, game mechanics, graphics styles, and plot ideas and dedicate the next hour to refining these lists.
Our plan is to make a 2D side-scroller with pre-rendered 3D images for sprites. The environment will actually be 3D though, and the path will turn corners to give a feeling of depth. This odd blend of 2D and 3D will hopefully give us the graphical benefits of 3D art while maintaining 2D game mechanics, such as collision detection based on sprite boundaries rather than bounding boxes. The plot is this: President Stephen Colbert sends the main character to defeat bears and robots that are threatening to take over the country. The idea comes from Colbert's real attempt at running for president and plays on his apparent fear or hatred of bears and robots, as often described on his show. 11:00 p.m. The main models I have to create are a bear, a robot, and the main character. The bear will probably be the most difficult because I've done very little animal character modeling. I decide to model it first so that I don't run out of time to make it look decent. I also decide that the bear will be walking upright to make it seem more menacing.
I start by drawing a sphere for the head and modifying it to create other features, like the snout. Google's image search is a blessing for finding reference images. Modeling the head takes a little more than an hour, and I decide to animate the mouth before modeling the rest of the bear to make sure the head will animate well.
This proves to be a bit more complicated than I expected because rotating the jaw is causing some rather ugly interactions between the jaw and the head. Luckily, a bend modifier helps me to get a similar motion for the jaw without this issue.
For the next 90 minutes or so, I work on the rest of the bear's body. I try modeling the body as a separate object and then aligning it with the head, but it looks terrible. A few attempts even looked humanoid, so that's something to keep in mind for when I model the main character. Finally, I decide to extrude polygons from the bottom of the head and adjust those to create the rest of the body. So far I have a rough model of the entire torso, and it looks pretty good, or at the very least looks far better than my previous attempts.
I just started extruding some polygons from the body to create the arms, but we need to take a break and eat dinner before all the nearby restaurants close. Things seem to be going okay so far. Dale is working on setting up the environment and getting the camera to turn a corner while also rotating the sprite so that it faces the camera at all times. He seems to have taken the same approach I did: working on the difficult part while he's still fresh. John is working on the physics engine, which will hopefully save Dale some time. True to his training as an electrical engineer, he's implementing the engine as a series of second-order differential equations, which made our club president groan and shake his head when he heard about it.
Saturday
4:00 a.m. After dinner, I make some minor adjustments to the bear's upper body, and I finish the arms and claws. It's not too bad so far, with this method of extruding some polygons and adjusting their vertices, but I'm a little concerned about how easy it will be to animate.
I also decide to add hair of some sort because the bear was looking rather bald. I try using a bump-mapped hair texture, which doesn't work very well. So I fall back on an odd technique I learned for modeling grass, which I had also used in the contest two years ago to create facial hair for our title-screen image. I create a small, thin triangle and use the scatter tool to scatter thousands of those triangles all over the bear.
3ds Max has a cap of 65,000 instances for the scatter tool. That's a shame, but I suppose it looks all right, albeit a bit like a porcupine.
I also end up crashing the program once or twice with "out of memory" errors. That's one problem I would not have imagined encountering had we decided to do true 3D graphics instead of pre-rendered sprites.
While working on the hair, I realize the bear is missing two very important features that would help it look more like a bear (someone commented that it looked like a rodent at one point): ears and teeth. These are easy enough to add, although the teeth refuse to stay attached to the lower jaw, so I end up having them float along with the jaw as it moves. It's a bit of a hack, but hacks are standard fare in the 48 Hour Contest.
Dale had been having some problems setting up the camera in the scene and getting it to turn the corner without altering the zoom or angle, but I think he figured out most of it. Hopefully, implementing the solution won't drain too much more of his time.
We need to work on more gameplay aspects. John seems to have gotten projectile motion to work, as well as recoil from firing a projectile, and he has moved on to collision detection. I guess he's planning to work through the night to make up for the fact that he will be away for most of Saturday and part of Sunday due to other commitments. So ends the first night of the contest at the fairly typical time of 4:00 a.m.
4:00 p.m. I had a meeting off campus this morning that went longer than I expected, so I didn't make it back until 1:00 p.m. Before leaving for my meeting, I did stop by the room to get an update on John's progress before he left. He had the physics engine working well and also had collision detection working fairly reliably. As he explained his work to me, I realized that most of it was hard-coded, which means it will take a bit more work for Dale to abstract it into a proper class structure.
After returning from my meeting, I update Dale on John's progress and resume my work on the bear model. I set a goal of finishing the bear by 3:00, since all I have left to do is make the legs and animate the animal. Making the legs is almost identical to making the arms and takes very little time. But setting up the animations takes much longer. I try to animate the arms the same way I did the jaw, but with not as much luck. I eventually set up animations using several bend modifiers applied to various sub-sections of the bear mesh. This produces an ugly hierarchy of edit poly and bend modifiers that, if not set up correctly, could lead to the entire bear bending, rather than just the arms.
Nevertheless, my self-imposed 3:00 deadline has passed, and I decide to stick with this hack rather than waste more time trying to find a cleaner solution. The legs caused even more problems, as the technique I used for the arms did not work as well for the legs.
I settle for a twist modifier applied to the entire bear but constrained to mainly affect the legs, resulting in a shuffling walk of sorts. Normally, animations like this would be done using a bone structure, but based on my bad experiences with bones in the past I hoped using modifiers would be less error-prone. That clearly has not been the case, but at least the bear is done now and I'm only an hour past my original target.
8:00 p.m. The contest is now at the halfway mark and the pressure is starting to build. Dale is having more problems merging John's work than we anticipated. Earlier in the day, he decided to stop working on the camera after getting it to work correctly for everything except turning corners. He was able to set up the program to load scene data and character placement from text files, which will make level design much easier later.
People from other groups have stopped by on occasion, wondering why we were working in a different room and also curious as to how our game was progressing. I guess no one else heard the announcement made at the beginning of the contest that teams were free to work in either room.
I go and look around at a few other teams, and I think we're doing all right, although we could be in trouble if programming difficulties continue to plague us.
After finishing the bear, I start on the robot model. I had originally planned to make the main character next but feel that I need a break from making organic models after the headache of trying to animate the bear.
Once again, I start modeling the head, but this time using only simple shapes to achieve a more artificial look. I base the head and upper torso on pictures of a USB robot camera that I found while browsing image search results for "robot." After a short snack break around 5:00, I add arms and legs to the robot, again using basic shapes. Geometry-based modeling is so much easier than the polygon- and vertex-level work I did on the bear.
By 7:00, I have the entire robot modeled. It doesn't look particularly evil or even potentially harmful at first, but the spikes I add to the arms and the rocket-launcher sticking out of its chest should resolve that. I also decide to use bones this time to make animation easier. Unlike the bear, the robot's arms and legs are separate meshes, so I just have to link each mesh to an individual bone. That much I'm comfortable with when animating using bones.
In the next half hour, I set up all the animations for the robot's arms and legs. Two models down, one to go, and it's time for the group dinner.
Sunday
3:00 a.m. When I started the character model, I tried several approaches to making the body, such as drawing a silhouette and extruding it. However, after spending nearly an hour trying various ideas, I settle on modeling the entire character from the head down, just as I did for the bear.
The one aspect of the character model I had planned out from the very beginning was the face. I start with a slightly squashed sphere for the head and add a capsule shape with a taper modifier for the nose. The rest of the face is just a bitmap image that I drew in Microsoft Paint. All I have to do is apply the image to the head, check whether the eyes, nostrils, and other facial features have to be realigned, and update the image file as necessary.
This is a trick I figured out in the 48-Hour Contest two years ago, and the end result this time was exactly as I expected it to be. From here, I extrude polygons to form the neck, shoulders, upper body, and arms. Within three hours, I have half the character modeled.
At this point, I try my hand at animating the arms to see whether it will be worth it to continue with this model. Having learned my lesson with the bear, I decide to use bones this time, and after about an hour of trial and error, I finally get the arms to bend correctly. During this time, I draw several confused looks from Dale and others who stop by as I say out loud things like, "I guess moving bones after attaching them to the body is a bad thing."
Shortly after midnight, I model the character's lower body and legs, and by some stroke of luck, I am able to set up bones in the legs very easily. I put the final touches on the main model. In the morning, I'll start modeling his accessories and weapons.
I've helped a few people with Photoshop and 3ds Max problems for their own games over the course of the night, and we've had a few people try to figure out some of the more unusual programming problems we've had. This highlights a key feature of the contest that I've noticed every year: it may be a competition, but it's a friendly competition, and contestants are just as willing to ask for help as they are to give it.
12:00 p.m. I get back around noon feeling considerably more rested than I did the day before. At home, I looked up a few tutorials on making an Indiana Jones-style hat and a light saber, and now I finish both models within the hour. We decide the main character should be armed with both a light saber and the "Colbert cannon," both throwbacks to various episodes of the television show. While modeling the cannon, I realize that I haven't given the character hands yet! Taking some inspiration from Lego figures, I simply make a claw shape out of a sphere and then design a material for it in Paint that will give the appearance of having fingers.
2:00 p.m. By 2:00, I finish these accessories and start animating him. I have a few problems with the arm joint around the shoulder deforming incorrectly as the character swings the light saber, but that is easily fixed by adjusting the bones.
I suddenly realize we needed a projectile for the Colbert cannon to fire, so I "model" a presidential campaign button, rather, a rounded disc with Colbert's picture on it.
With four hours left in the competition, I think I'm done with the modeling and animation. I just have to render a few frames of each animation from the same camera angle as we're using in the game. Unfortunately, other areas don't seem to be going as well. Dale has been trying to add in the physics engine and collision detection systems but has been encountering bugs almost continuously. Trying to abstract John's work so that it can be applied to multiple objects on screen has not been easy, especially with hard-coded dependencies between objects such as the projectile and the character. There have also been a few instances in which both of us have stared at his code trying to decipher his logic, but with little luck.
John won't be able to make it back for at least another hour due to transportation issues. Hopefully, he's had some luck finding music and sound effects, since that's about the extent of off-site work allowed by the contest rules.
6:00 p.m. Right after I finish the models, I download a copy of the base files Dale was working on and start testing my renders to make sure the camera angles match. I start with a Washington, D.C. level and find some high-resolution images of the White House lawn for the background and ground. I also model a hedge for the character to jump over by adding a strong noise modifier to a box. However, when I add the images via Dale's level editor setup, all the images appeared mirrored.
We hadn't noticed this bug earlier since Dale had only been using placeholder art and had not verified orientation. It takes me the rest of the hour to get images to display correctly by tweaking the code and the level setup files. Although the camera angles in my renders match up with the scene camera, I find a problem with collisions that we should have anticipated. All our collisions were done using the bounding squares for the sprites, which works well for horizontal collisions. But by rendering all our images at a 45-degree angle above the horizontal, we can no longer use the top of the image as a realistic bound for collisions on top. In other words, when jumping onto an object, the character will land on the back of the object rather than inline with the plane of motion.
While the ideal solution would have been to recode collision detection and set a different vertical bound, this is by no means practical with little over two hours left in the contest. My temporary solution is to scrap our pseudo-3D idea and render everything from a side profile view, essentially creating a regular 2D side-scrolling game.
This fix considerably improves how the collisions look. There is also a slight flaw with the character design: His legs were in the center of the bounding square, leaving empty space on both sides that was still being checked for collisions. This calls for another quick fix; I add a "hover board" for the character to ride. It spans the width of the image and makes collisions seem more realistic while jumping over objects.
In all this chaos, I nearly forget to render the bear, robot, and projectile sprites from a side view.
Despite countless problems, Dale has implemented most of the collision detection and physics by now, and has started setting up the game states, title and ending screens, win-conditions, and so forth.
John returns around 4:30 with a bit of good news. By some lucky chance, his brother has just recorded some great instrumental tracks and is happy to let us use them (music is allowed to be from external sources, as long as copyrights aren't violated). So John works on setting up background music and also records a voiceover for the title screen to explain the plot. He then takes over level design while I add the hover board to the character model and started rendering. Now we have one version of the game on Dale's computer with the most up to date collisions, physics, and game states, and another on John's computer with older versions of the game mechanics but with sounds and a basic level. All that's left is combining them, and we should have something presentable when the contest ends in an hour. It's the epitome of crunch time.
7:10 p.m. Luck has not been on our side this year. The contest is now officially over and all we have is some sort of demo with virtually no gameplay. Things seemed to be going well right up until John left for a quick dinner (his parents were in town and he wanted to have dinner with them before the judging started). Dale had copied over all John's work and had added in the sound and new level files. He also added in the title, win, and lose screen images that I had made in Photoshop. But when he tried running the game, the level loaded as a black screen with background music. For some reason, none of the images were loading correctly although they had worked fine on John's machine.
With just minutes before the end of the contest, I run down to the restaurant and drag John back to load up his copy of the game for judging. Dale had a backup version of the game that we could have used, but John's version had the same game mechanics plus graphics, audio, and a simple level.
Thankfully, his version is now up and running on one computer. However, since no changes can be made to the official submission after 7:00, we'll have to run it directly from Visual Studio. This means we won't be able to set up in the other room, and I will have to post a sign to let the judges know where we are set up. I think Dale wants to keep working on the game so that, if he's able to fix the bugs in time, we'll be able to show it to people as a non-judged version. I don't think I'll be of much use for that, so I'm going to see what the other teams came up with and see if there's any hope of us not finishing in last place.
10:00 p.m. A bit of a positive twist came at the very end. We placed 12th out of 15 teams, the highest ranked team with an incomplete game. I guess the judges liked our physics engine, graphics, audio, and incorporation of the theme. Not surprisingly, incomplete games are fairly common during the 48-Hour Contest, but most teams will eventually complete their games, to some degree, in the following weeks. At the very least, we will. This has certainly been a different experience for me compared to the past two years. If I stay at University of Michigan for graduate school, I'll definitely enter again next year, but if I go elsewhere, I may have to make a trip back to Ann Arbor just for this, if I have time.
Vishnu Desaraju is a student at the University of Michigan and publicity coordinator for Wolverine Soft. His team's game placed 12th out of 15.
Note: views and opinions expressed in this article are the author's and are not necessarily those of Wolverine Soft.