Innovating With Infuseopoly
Steven Wright once said, “I think it’s wrong that only one company makes the game Monopoly”. The 3D team at Infuse decided to accept that challenge, and learned some computer programming in the process.
You’ve probably heard the terms “right-brained” or “left-brained” used to describe someone. Although the science has been disproven, the words have stuck. We all seem to be predisposed to one pattern of thinking or the other. So-called “right-brained” people gravitate more towards artistic pursuits, and “left-brained” people towards logical, analytical ones.
Bridging The Artistic / Programming Gap
At Infuse, our production team includes talented people strongly planted on both ends of the spectrum. But one group here has to balance both types of thinking on a daily basis: our 3D artists.
As an artistic medium, 3D requires an extremely high degree of technical understanding. Which is not to say other art forms don’t require refined technique. The technical skills being referred to here are that of an engineer or computer programmer, traditionally “left-brain” abilities. When a painter makes a mistake on their canvas, they know the strokes to use to correct it. When a 3D scene is misbehaving, the artist has to start thinking in terms of source code and break the problem down in terms of logic.
3D Team Finds Fun Way To Learn Programming
Our 3D team at Infuse is always looking for ways to improve both their left and right brain skills. Focusing on the left side, several members expressed an interest in learning more about computer programming. We decided Python would be our language of choice, because it has become the almost universal standard for scripting across 3D software packages. Which is exciting in and of itself because there was no such standard ten years ago. Our two primary 3D development tools at Infuse are Autodesk Maya and Autodesk 3D Studio Max. When both programs were released, they included their own unique languages for scripting (MEL and MaxScript). We have experts on our team in both languages, but even they recognized the utility of being able to write Python code that could be easily translated between both programs.
At first, we started with the basics. The team members each wrote their own text based games, from knock-knock jokes to choose-your-own-adventure. After getting over the hurdle of understanding Python syntax, we were ready to test our skills in a more production-like environment. During a programming class one day, we ended up going off on a tangent to explore just how truly random Python’s
random() function was.
Together we wrote a text based program to roll a virtual pair of dice. It would roll tens of thousands of times and print out the percentage that each possible combination appeared. For all of you Python programmers out there,this simple script of ours will count 100,000 throws and tell you the percentage of sevens and twelves.
Taking Programming & 3D Design To The Next Level
That exercise led us to the idea of building a playable board game within Maya. Autodesk would probably tell you that Maya is a platform for creating cinema quality 3D renders, not playing games. But it seemed like an interesting challenge to use it for something it wasn’t designed for, so we decided to give it a try. We settled on Monopoly and got to work. First off, we needed a few basic 3D elements; namely a board, player pieces and dice. The next task was to prove that we could make pieces move around the board using a Python interface. We ended up using the timeline for any animation in the game, we would set keys for the start and end points, then clear the keys after the movement completed. The challenge with moving pieces around the board wasn’t in getting from one point to another, it was making sure they followed the perimeter of the board when going from one side to the next. We also had to make sure the piece was pointing in the right direction as it was moving.
Python is an object-oriented programming language, which is a huge benefit over MEL or MaxScript. We immediately found uses for this capability in both player and board creation. The board was composed of a list of “Tile” objects. That allowed each tile to hold the relative x/z position for a player on it, as well as a list of players on the tile, whether it was owned, etc. Likewise, each player was represented in the system as a “Player” object that held the amount of money they owned, what avatar they were using, and a variety of utility functions for moving their piece.
With a proof of concept functioning, it was time to take a harder look at all the mechanics of the game, and break it down into logic that a computer program could evaluate. One of the team members took on the weighty responsibility of creating a mind map that demonstrated all the logic gates the program would need to follow over the course of a typical game. That mind map was translated first into a text based program that demonstrated the fundamental concepts of the play system. Then it was just a matter of translating that system over to the 3D environment we had started in our proof of concept.
At the same time the logic development was taking place, we also put some time into creating an elegant representation of dice rolling. Going back to where our idea originally started, the computer instantly figures out what you will roll using a random number generator. But we wanted to make it look a little more interesting than that. So one of the team developed a physics simulations to record a library of 3D dice throws. When the program’s random function decided what the dice would roll, the correct animation sequence for that dice would be triggered, and it would look as though a pair of dice were actually being tossed onto the board.
A side aspect of the game development that we had some fun with was customizing the Monopoly game board to be Infuse oriented. Our founding partners became the railroads, Water Works became a contribution to our Simple IRA, etc.
Working Together, Working For Fun
Not sure how many games of Infuseopoly we’ll actually end up playing in Maya, but this was definitely a “journey not the destination” sort of project. First of all, it was an opportunity to work together on a project just for fun, which was a reward in itself. But even more importantly, everyone involved gained a substantially greater understanding of Python and programming in general. This is an extremely important skill for a 3D artist, because it teaches them to think like their computer. That way when things go wrong, it doesn’t seem like voodoo. They can break the problem down logically and find a solution.