CS 550 Term Project
Objective/goal
Demonstrate competency with features of OpenGL programming including, but not limited to, material properties, lighting, textures, and animation by building a simple Monopoly game demo. Model pieces and dice in Blender, and provide random dice rolling and piece motion. A sub-goal is to have fun while proving competency. (author's note: Monopoly © 2007 Hasbro. All rights reserved.)
Methods
Pieces and dice were modeled using a free 3D modeling program called Blender. For the dice, a simple cube with subdivided faces was used. On each face, the subdivisions were collapsed then extruded (backwards) to make the spots. Once the rough outline was achieved, a subsurface was generated to make rounded edges and circular spots. The car was modeled in much the same way. The block that roughly resembled a car was first built, a subsurface was applied, then a lot of manual adjustment to get the shape right was done.
Each of the other pieces used the same method: rotation then manual adjustment. The dimples on the thimble were created the same way as the spots on the dice, first collapsing the vertices to a point in the center, then extruding that point back into the solid to create a hole. When the subsurface is applied, it rounds the corners, so some re-creasing was done to maintain sharp edges where needed.
The pieces were first loaded into a known working code so the lighting and material properties could be set without other variables. Three material properties were decided: a flat silver, or pewter, a shiny gold, and a flat green-blue plastic look. There is a single light for the pieces, place very far away so each piece is affected similarly no matter where on the board it sits. This is to help reduce the specular "glare" from a light source that is close to the pieces.
The textures were generated using pictures of Monopoly boards that the author owns. Each picture required some cropping and perspective correction, as well as being resized to a power-of-two size for OGL to read. The texture loader is based on example code from NeHe productions. Once the board is drawn and the textures applied, it is rotated to an aesthetically pleasing view and a separate, board-only, light is rendered so the board is well-light and visible.
The dice rolling is handled using a (very) simple random number generation that uses srand() with the current computer time to give somewhat random numbers. While it is not true random number generation, it does ensure that each time the program is run a different random number seed is used. The dice roll is (1 + rand()%6), and is stored globally so the piece movement subroutine can access the dice rolls, too.
To animate everything, a sleep function was used to control timing. This is not the most optimal way to control animation speed because it used 100% processor while between frames, but it works for this project. The dice rolls and piece movement (translation) are both animated.
Finally, camera rotation is handled using gluLookAt() with a fixed eye location. The camera automatically looks towards the active piece location, using the vector describing the piece location from (0,0,0) as the "up" vector. This is updated for each step in the animation, giving a smooth camera rotation that is centered on the active piece.
Challenges/roadblocks
There were only a few big challenges to overcome with this project. The first challenge was learning Blender. Fortunately, there are literally thousands of tutorials for learning Blender on the Internet. After an entire day working with tutorials, the piece modeling was somewhat easier, although anything beyond basic shape formation is still beyond reach.
The second challenge was getting the right lighting. Initially, lighting was implemented in the project code, which had to be recompiled with each lighting parameter change. The problem was that all the pieces are imported each time the program is run, leading to a lot of wasted time just to see that the lighting is wrong. The other problem is that lights that work well for the pieces don't adequately light the board, and vice-versa. The solution was to work on lighting in a separate program then re-integrate, as well as using two different lights: a diffuse light for the pieces, and a strong light for the board that is turned off when rendering the pieces.
The final big problem was getting the piece translation correct. This would be a non-issue except the board is rotated 30 degrees about x-axis and 225 degrees about y-axis to make a nice view. This presented some challenges when trying to line up the piece location with a specific space on the board. To get the translation correct, the entire view is rotated back to 0, then the pieces are translated in x- and z- directions, then everything is rotated to the nice view. Another complication is knowing where the piece is on the board, not just its location in space. To keep track of this, an integer is stored with the piece object structure, and a switch case is used to make sure the piece moves the right direction depending on the side of the board the piece is on.
Results
Well, this isn't exactly a data-collection project, but there are still results. In short, everything works as described above. Since the results can (and are) altered just by changing a couple of variables in the code, only the latest version's results are reported here. The lighting is satisfactory, although the gold and plastic materials are somewhat too washed out looking. The pewter looks great, though.
The textures for the boards turned out better than expected, as the space names are still readable when zoomed in. The four boards used are the "vintage," "heirloom," "french," and "star wars" editions. The dice rolling is still a bit too simple, as the dice only rotate around a fixed axis some random number of times to get to the rolled number. However, since rotation is non-communicative, it would be somewhat more difficult to get very nice dice rolls in OGL without some creative programming.
The piece motion is not exact, although it is always clear on which space the piece rests. This is because the spaces are not integer width, nor are they an easy to find width. At this point, the space width is hard-coded. Another small thing is that the window does not support resize at this point. While this would be easy to implement, there were many other high priority goals.
You can see some videos of the demo in action below.
Concluding remarks
While the results are not a playable game, it would not be difficult to add money handling and property purchases to the game demo, at least on a text-based level. To add the images for each of the monies and properties (as well as chance & community chest) would take some time, but would be doable. There is no intent to turn this into a playable game, though, as the author would like to avoid having his ass sued by Hasbro.
Some improvements could certainly be made to the program, some easy, some not so much. One aesthetic thing that could be fixed is when pieces are on the same space, program an offset so their location does not coincide. Another good addition would be to program the remaining (5-7) pieces to show off modeling ability and add a little variety to the demo.
Another improvement that could be made is some more tweaking on the material properties of the pieces and dice to make them a little more realistic. However, one must keep in mind that this is meant more as a proof-of-concept type demo than an actual release. Finally, it would be fun to add some more board textures, as well as some different camera views (maybe one viewing in from outside so the space names are right side up?).
Overall, this was an enjoyable project. The results definitely meet or exceed the goals set out for the project. There is camera motion, adequate lighting, variable piece materials, texturing, and animation. All that is left is polishing, but even without incremental refinement, this project is complete.
Demonstrate competency with features of OpenGL programming including, but not limited to, material properties, lighting, textures, and animation by building a simple Monopoly game demo. Model pieces and dice in Blender, and provide random dice rolling and piece motion. A sub-goal is to have fun while proving competency. (author's note: Monopoly © 2007 Hasbro. All rights reserved.)
Methods
Pieces and dice were modeled using a free 3D modeling program called Blender. For the dice, a simple cube with subdivided faces was used. On each face, the subdivisions were collapsed then extruded (backwards) to make the spots. Once the rough outline was achieved, a subsurface was generated to make rounded edges and circular spots. The car was modeled in much the same way. The block that roughly resembled a car was first built, a subsurface was applied, then a lot of manual adjustment to get the shape right was done.
Each of the other pieces used the same method: rotation then manual adjustment. The dimples on the thimble were created the same way as the spots on the dice, first collapsing the vertices to a point in the center, then extruding that point back into the solid to create a hole. When the subsurface is applied, it rounds the corners, so some re-creasing was done to maintain sharp edges where needed.
The pieces were first loaded into a known working code so the lighting and material properties could be set without other variables. Three material properties were decided: a flat silver, or pewter, a shiny gold, and a flat green-blue plastic look. There is a single light for the pieces, place very far away so each piece is affected similarly no matter where on the board it sits. This is to help reduce the specular "glare" from a light source that is close to the pieces.
The textures were generated using pictures of Monopoly boards that the author owns. Each picture required some cropping and perspective correction, as well as being resized to a power-of-two size for OGL to read. The texture loader is based on example code from NeHe productions. Once the board is drawn and the textures applied, it is rotated to an aesthetically pleasing view and a separate, board-only, light is rendered so the board is well-light and visible.
The dice rolling is handled using a (very) simple random number generation that uses srand() with the current computer time to give somewhat random numbers. While it is not true random number generation, it does ensure that each time the program is run a different random number seed is used. The dice roll is (1 + rand()%6), and is stored globally so the piece movement subroutine can access the dice rolls, too.
To animate everything, a sleep function was used to control timing. This is not the most optimal way to control animation speed because it used 100% processor while between frames, but it works for this project. The dice rolls and piece movement (translation) are both animated.
Finally, camera rotation is handled using gluLookAt() with a fixed eye location. The camera automatically looks towards the active piece location, using the vector describing the piece location from (0,0,0) as the "up" vector. This is updated for each step in the animation, giving a smooth camera rotation that is centered on the active piece.
Challenges/roadblocks
There were only a few big challenges to overcome with this project. The first challenge was learning Blender. Fortunately, there are literally thousands of tutorials for learning Blender on the Internet. After an entire day working with tutorials, the piece modeling was somewhat easier, although anything beyond basic shape formation is still beyond reach.
The second challenge was getting the right lighting. Initially, lighting was implemented in the project code, which had to be recompiled with each lighting parameter change. The problem was that all the pieces are imported each time the program is run, leading to a lot of wasted time just to see that the lighting is wrong. The other problem is that lights that work well for the pieces don't adequately light the board, and vice-versa. The solution was to work on lighting in a separate program then re-integrate, as well as using two different lights: a diffuse light for the pieces, and a strong light for the board that is turned off when rendering the pieces.
The final big problem was getting the piece translation correct. This would be a non-issue except the board is rotated 30 degrees about x-axis and 225 degrees about y-axis to make a nice view. This presented some challenges when trying to line up the piece location with a specific space on the board. To get the translation correct, the entire view is rotated back to 0, then the pieces are translated in x- and z- directions, then everything is rotated to the nice view. Another complication is knowing where the piece is on the board, not just its location in space. To keep track of this, an integer is stored with the piece object structure, and a switch case is used to make sure the piece moves the right direction depending on the side of the board the piece is on.
Results
Well, this isn't exactly a data-collection project, but there are still results. In short, everything works as described above. Since the results can (and are) altered just by changing a couple of variables in the code, only the latest version's results are reported here. The lighting is satisfactory, although the gold and plastic materials are somewhat too washed out looking. The pewter looks great, though.
The textures for the boards turned out better than expected, as the space names are still readable when zoomed in. The four boards used are the "vintage," "heirloom," "french," and "star wars" editions. The dice rolling is still a bit too simple, as the dice only rotate around a fixed axis some random number of times to get to the rolled number. However, since rotation is non-communicative, it would be somewhat more difficult to get very nice dice rolls in OGL without some creative programming.
The piece motion is not exact, although it is always clear on which space the piece rests. This is because the spaces are not integer width, nor are they an easy to find width. At this point, the space width is hard-coded. Another small thing is that the window does not support resize at this point. While this would be easy to implement, there were many other high priority goals.
You can see some videos of the demo in action below.
Concluding remarks
While the results are not a playable game, it would not be difficult to add money handling and property purchases to the game demo, at least on a text-based level. To add the images for each of the monies and properties (as well as chance & community chest) would take some time, but would be doable. There is no intent to turn this into a playable game, though, as the author would like to avoid having his ass sued by Hasbro.
Some improvements could certainly be made to the program, some easy, some not so much. One aesthetic thing that could be fixed is when pieces are on the same space, program an offset so their location does not coincide. Another good addition would be to program the remaining (5-7) pieces to show off modeling ability and add a little variety to the demo.
Another improvement that could be made is some more tweaking on the material properties of the pieces and dice to make them a little more realistic. However, one must keep in mind that this is meant more as a proof-of-concept type demo than an actual release. Finally, it would be fun to add some more board textures, as well as some different camera views (maybe one viewing in from outside so the space names are right side up?).
Overall, this was an enjoyable project. The results definitely meet or exceed the goals set out for the project. There is camera motion, adequate lighting, variable piece materials, texturing, and animation. All that is left is polishing, but even without incremental refinement, this project is complete.
