Tumbleton’s Fortune was a senior student game developed by a group of 3 DigiPen students. I acted as the lead designer on the project, designing the gameplay, levels, user interface and drew many of the art assets.
What went right:
A mix of platforming and puzzle solving gameplay
Tumbleton’s Fortune is a game that has 2 distinct gameplay elements: platforming and puzzle solving. Initially a 3D version of The Incredible Machine, gameplay consisted of the user rotating a camera around a puzzle, fitting pieces into the scene, and then clicking the PLAY button to see the objects interact with each other. If the puzzle wasn’t solved, the process would repeat over and over again. The gameplay was just too stale and boring.This wasn’t something that we wanted to do as our final game at DigiPen, so we set out to build something more exciting.
Since the puzzle element of the game was already there, I was really pushing for direct player control. Movement is empowering, it’s as simple as that. Adding a player character on the game field and directly controlling him as he interacted with all the objects was really fun to watch.
Now that the player had an avatar he could control in the game, I really wanted to push the sense of exploration. Games are all about exploring the unknown, finding new things to play around with and using them to win. At this point, we still didn’t have any concrete levels – the game literally consisted of a blank level with a controllable main character in it and a load of objects like cubes and spheres that we could drop on the field.
I was blocking out a simple platforming level one night, placing the cubes in a stair formation so that the character would jump from one to the other and there was a huge gap that I came across that I couldn’t jump over. One of my teammates came over and said that I should place a large cube in the level so that I can get across. When you place any object in our game, it automatically snaps to another. As soon as I placed a large cube to cover the gap, things just clicked and I found our main game mechanic – bringing in objects and placing them in the game world.
I’m a big proponent of simple controls, and with a more complex game like Tumbleton’s Fortune where players needed to move their in-game avatar and place objects into the game world, controls had to be thought out, usable and effective.
My main goal was to make the controls as intuitive as possible. I knew that if the controls were too complicated, no matter how fun our game was – players wouldn’t waste their time with it.
We examined a couple of different methods, but eventually settled on one that let players use the keyboard keys to move the game character and the mouse to place objects. This established that the keyboard is for direct movement – the platforming and the mouse isfor puzzle elements – snapping objects.
The mouse is also used for camera rotation, which is accomplished by holding the right-mouse button and moving the mouse. Initially, I wanted to implement camera rotation by simply moving the mouse around, but the player already uses the mouse to position objects in the game world. Otherwise, everytime the player was going to position an object in the game world, the camera would randomly move around.
In the beginning, when we were throwing objects onto the field and watched them interact, we needed some kind of an interface for that. One of my teammates implemented a simple sidebar that would show all the available objects that we had to play around with. We would simply click on one and then put it where we wanted in the game field.
Eventually, playing around with cubes and spheres got old, and we expanded the editor to include scaling, stretching and object rotation. Now, I could block out simple level ideas.
When we decided to turn the game into a platformer / puzzler, we added more features like pathing, hinges, triggers and switches.
The cool thing was that the editor was done in-game. We could load a level in a level editor, switch some things around, and save it right there and then. Then, we could play it without exiting the game. This allowed me to make quick iterations of all of our levels, resulting in a more polished experience.
Players can also use the editor to create and play their own custom levels.
What went wrong:
Since the game started out as a physics simulator, you would think that the physics was the first thing done. It was exactly the opposite. The person who was responsible for the physics first wanted to write the entire physics engine themselves. After a couple of weeks, with no progress, we decided to go with Tokamak, an open source physics engine. Things improved, and we were pretty happy with it, thinking that the physics issues were solved for good.
However, when we decided to switch the game genre, things broke down again. Tokamak started failing more and more. We were back at square one. At this point, our physics programmer found another solution – the Bullet physics engine. After a few weeks, he built a modified version of the engine, and we were back in business.
The problem was that it was a little too late, and some of the game levels had to be redone because object interaction was different as we switched physics engines. Valuable time was wasted on 2 versions that we had to scrap – our own physics engine and Tokamak.
While our in-game level editor was a joy to play around with, the object editor was a different story. It consisted of a generic windows application that let us adjust properties of every game object, set their collision, logic and calibrate triggers. Additionally, all the art assets like materials and shaders were assigned to objects here.
The goal was that if we wanted for an object to behave in a certain way, we would open it up in the object editor, adjust things, save it and bam! – it would automatically change in-game. In the beginning, things were working fine, but as our game grew in scope, so did all the content triggers. We would have to program specific triggers that would only get used once in the game for very specific situations, and they ended up bloating the trigger list.
Level building consisted between the creator switching constantly between the in-game level editor and the object editor because the two systems were tied so close together which was bothersome and generally slowed things down.
We also didn’t have an efficient method to deliver text to the game screen – we relied on a system where if the player touched an object, specific text would be displayed on the screen. In the end, we had to create many objects that were used once in the game just to output a specific dialog of text.
Because our team consisted of only 3 people – making decisions was easy, but we had trouble finalizing them. From things like gameplay to code to art style – these things took longer than they should have.
We had to switch gameplay half way between the project because we found the initial gameplay lackluster. We switched physics engines multiple times. We also didn’t finalize the art style and theme of the game – exploring the egyptian landscape because we weren’t sure if we were going to get models into the game. For most of the project, we were using random art assets and simple art. We switched only after we talked to a few artists who were willing to contribute some models.
For some reason, we stalled for no good reason when it came to making final decisions. There was no official producer on the team to direct us and keep us on schedule, which probably would have helped keep the project on track better.
In the end, I think that we delivered a fun game experience, if albeit a little too short. Considering the team was made out of 3 people – two programmers and one designer, we did very well compared to some of the other bigger teams at DigiPen and delivered a fun platformer with puzzle elements as our last hurrah! at the school.