Something very unexpected happened. The Babycastles folks were running a Summit at the Museum of Modern Art and Design(MAD) - It was centered around bringing Keita Takahashi's ideas to reality along with other things like game (not just videogames but also about things like games in physical spaces) related talks and indie music bands.
They wanted some help with the programming for one of their projects. For some inexplicable reason they thought of asking me and I jumped at the opportunity. I had always wanted to explore physical games/ alternate interfaces and wanted to do things similar to what Kaho Abe does. And now they told me I was actually going to work with her! Not to mention an opportunity to work with Keita Takahashi!!
I had an initial meeting with Keita and Kaho. The project, Mario Ball, was to build the original Mario brothers - but instead of using a normal controller the ideas was to control it using a wooden maze representing the level and Mario actually controlled by a ball. I think Keita's original drawing explains this the best.
Kaho had decided that we are going to use a magnetic ball for Mario and an array of magnetic reed switches underneath the controller surface to detect where the ball is an move the on screen Mario accordingly (It was decided not to use computer vision because that was already being used for another game). This is where I was going to help them - Actually build the game that processes the controller input to move Mario around in the game. It was also decided to build the controller as a big box so that it would require two people to work with each other to actually control Mario! We also decided that we would make Mario go up side down when the ball is actually moved up and it stays up there - something like a change in direction of gravity. I was concerned with the resolution of the magnetic reeds and asked Kaho to also add an accelerometer so that we can try and interpolate Mario's position when the ball was actually between two magnetic sensors and we had to guess which direction Mario was actually moving. Throughout the meeting I was mostly just thinking - Yay!! I am talking with Keita!!
Kaho was going to build this insane setup with 90 magnetic reed switches connected to an Arduino through a set of multiplexers. The program running on the Arduino would detect the active magnetic switch and write that value to the serial port along with the 3 axis acceleration information from the accelerometer. So now we were ready to start building the controller and the game. The kicker - We had 6 days to build this whole thing!! (And not even 6 whole days. I had to go to my day job on all the days and work in the evenings. Kaho was handling the hardware for 2 other games)
I think my experience with working with multi-tiered systems in my day job (At this small startup) helped here. We decided what the format of the controller output is going to be like so that we can initially work separately and in parallel and then put the controller and the game together when they were ready. I decided to build the game with a ball and magnetic switches that are actually simulated (Similar to mocks/stubs that we use to test in isolation without external dependency) so that I could iron out some of the issues I would face even before the actual controller was ready. In hindsight this got me to 50% of the actual solution - but that was good enough given the time crunch. The things I totally got wrong in my simulation were the area which each magnetic switch covered and the maximum speed the ball would actually be able to roll in the real world.
So I went back and started to actually build the game. I didn't spend much time thinking about it but I decided to use Processing because of its inbuilt ability to use the serial port to interface with the controller. This was a good and a bad idea but at the end of the day was probably the right decision. The good part was that it all worked out and even though I developed the whole thing on the Mac it perfectly ran on the Windows machine where we finally put it - including the serial port part. The bad things included Processing not really having an easy way to rotate and blend images at the same time (Really? I expected better) and some bugs when part of the rendered image going offscreen. The IDE itself was horrible at times and I had to actually delete one file at a time to find syntax errors. At the end of the day the positives probably overrode the negatives. But the next time around I would think a bit harder before using Processing for a game.
I spent the first few days to actually get the assets of the original Mario brothers(Thanks Syed!) in and trying to mimic the looks of the original game as much as possible. I built the game in a way which is probably not recommended - I tried to get the graphics of the game done well before the actual logic/gameplay of the game. But I found that doing this motivated me much more than just dummy boxes and circles. Looking back I think this also helped out because I would have never been able to put in the effort to get the graphics right in the crazy days that were going to follow. I also spent the initial time building the framework in Processing to read in the world layout and character animation from Tiled TMX files. This also helped me out later when Keita wanted me to add extra characters into the game and I was able to do it with relative ease. As usual I wrote custom collision detection code instead of trying to figure out how to use Box2d with Processing. In my defense I didn't have time to ramp up on anything more complicated than the simple graphics APIs and this was the first time I was using Processing.
We met halfway through the week - Both the hardware and software were lagging behind where they should have been at that point. Keita was amazing as always - He had built the frame for the controller and created an actual Mario Ball by pasting colored strips to create a Mario on the magnetic ball (Thanks Lauren for the photo!).
That night me and Kaho just worked through the whole night trying to finish as much as possible. We made really good progress but we still weren't ready to put things together. The whole time I wasn't stressing myself out and tried to stay as calm as possible. I also told myself that Babycastles always manages to pull off these things - So I had nothing to worry! (It was half true at the end :). So here is the picture of the amazing circuitry that Kaho put together that night. I think she called it a unicorn barf or something like that.
The next day we had to shift to the MAD and this is where things started going wrong. We weren't allowed to stay late the day before we had to set the whole thing up! So on the opening day(Friday) we just had a few hours to get the whole thing ready. Kaho was also getting very busy dividing her time between all the projects she had to get working. This was a very tense day and unfortunately we weren't able to get Mario Ball ready that night.
On Saturday we finally got the game and the controller talking with each other. It was a magical moment. I never thought we would ever get to this stage given the craziness that was the whole project :) It had few kinks including a bug in the Arduino code which made it print lots of useless values in between the actual useful ones. A few hours later and few critical bug fixes later we had something close to playable - There were some issues with Mario appearing to teleport when the ball moved too quickly - but the game was definitely playable. And so by Saturday afternoon Mario Ball was ready to go! We spent some time getting the actual hardware for it setup and the game was finally ready to be put up.
I haven't talked much about Keita and probably mention here just a bit. He is a person of few but precise words and I would like to keep this section the same way. He is an amazing combination of a nice guy and a person who pushes you to the limit. He wasn't there to just have fun - But actually do something great. Good enough was not good enough - perfection was the only end point. In the end I didn't do everything that he asked for - but the game definitely ended up much better than if we had just aimed for something good enough. The couple of things I took out of this whole experience was to aim high and always keep improving.
Even though we were almost a day late I was very happy to have Mario Ball running for more than half of the summit. I think most people had lots of fun playing the game. There were some who said it was too experimental - but I thought that was part of what we were trying to do. Kaho had done an amazing job with the hardware - It worked without anything breaking for most of the summit (It briefly broke down on Sunday evening - but it was just someone had yanked on the controller so hard that the USB cable connected to the Arduino had come off. The crazy wiring just kept working the whole while).
So here it is - A picture of couple of people playing Mario Ball in the jungle themed arcade section of the Summit (The jungle theme was an amazing achievement of its own. Somebody needs to write about that). This should give an idea of the size of the controller and how it would take two people to use it. There are so many details in the controller I can't capture here. Keita added the fur like exterior and window handles(which reminded Keita of his Grandmother's house?) on the side so that you can easily hold and play.
Here is a video of people playing it at the Summit. I am sort of happy that I was able to capture the experience of the two players actually co-ordinating with each other to play the game.
I have no good words to end this post. Maybe that this is just the beginning. We will keep improving. You will see a better Mario Ball in the future!!
Kaho was going to build this insane setup with 90 magnetic reed switches connected to an Arduino through a set of multiplexers. The program running on the Arduino would detect the active magnetic switch and write that value to the serial port along with the 3 axis acceleration information from the accelerometer. So now we were ready to start building the controller and the game. The kicker - We had 6 days to build this whole thing!! (And not even 6 whole days. I had to go to my day job on all the days and work in the evenings. Kaho was handling the hardware for 2 other games)
I think my experience with working with multi-tiered systems in my day job (At this small startup) helped here. We decided what the format of the controller output is going to be like so that we can initially work separately and in parallel and then put the controller and the game together when they were ready. I decided to build the game with a ball and magnetic switches that are actually simulated (Similar to mocks/stubs that we use to test in isolation without external dependency) so that I could iron out some of the issues I would face even before the actual controller was ready. In hindsight this got me to 50% of the actual solution - but that was good enough given the time crunch. The things I totally got wrong in my simulation were the area which each magnetic switch covered and the maximum speed the ball would actually be able to roll in the real world.
So I went back and started to actually build the game. I didn't spend much time thinking about it but I decided to use Processing because of its inbuilt ability to use the serial port to interface with the controller. This was a good and a bad idea but at the end of the day was probably the right decision. The good part was that it all worked out and even though I developed the whole thing on the Mac it perfectly ran on the Windows machine where we finally put it - including the serial port part. The bad things included Processing not really having an easy way to rotate and blend images at the same time (Really? I expected better) and some bugs when part of the rendered image going offscreen. The IDE itself was horrible at times and I had to actually delete one file at a time to find syntax errors. At the end of the day the positives probably overrode the negatives. But the next time around I would think a bit harder before using Processing for a game.
I spent the first few days to actually get the assets of the original Mario brothers(Thanks Syed!) in and trying to mimic the looks of the original game as much as possible. I built the game in a way which is probably not recommended - I tried to get the graphics of the game done well before the actual logic/gameplay of the game. But I found that doing this motivated me much more than just dummy boxes and circles. Looking back I think this also helped out because I would have never been able to put in the effort to get the graphics right in the crazy days that were going to follow. I also spent the initial time building the framework in Processing to read in the world layout and character animation from Tiled TMX files. This also helped me out later when Keita wanted me to add extra characters into the game and I was able to do it with relative ease. As usual I wrote custom collision detection code instead of trying to figure out how to use Box2d with Processing. In my defense I didn't have time to ramp up on anything more complicated than the simple graphics APIs and this was the first time I was using Processing.
We met halfway through the week - Both the hardware and software were lagging behind where they should have been at that point. Keita was amazing as always - He had built the frame for the controller and created an actual Mario Ball by pasting colored strips to create a Mario on the magnetic ball (Thanks Lauren for the photo!).
That night me and Kaho just worked through the whole night trying to finish as much as possible. We made really good progress but we still weren't ready to put things together. The whole time I wasn't stressing myself out and tried to stay as calm as possible. I also told myself that Babycastles always manages to pull off these things - So I had nothing to worry! (It was half true at the end :). So here is the picture of the amazing circuitry that Kaho put together that night. I think she called it a unicorn barf or something like that.
The next day we had to shift to the MAD and this is where things started going wrong. We weren't allowed to stay late the day before we had to set the whole thing up! So on the opening day(Friday) we just had a few hours to get the whole thing ready. Kaho was also getting very busy dividing her time between all the projects she had to get working. This was a very tense day and unfortunately we weren't able to get Mario Ball ready that night.
On Saturday we finally got the game and the controller talking with each other. It was a magical moment. I never thought we would ever get to this stage given the craziness that was the whole project :) It had few kinks including a bug in the Arduino code which made it print lots of useless values in between the actual useful ones. A few hours later and few critical bug fixes later we had something close to playable - There were some issues with Mario appearing to teleport when the ball moved too quickly - but the game was definitely playable. And so by Saturday afternoon Mario Ball was ready to go! We spent some time getting the actual hardware for it setup and the game was finally ready to be put up.
I haven't talked much about Keita and probably mention here just a bit. He is a person of few but precise words and I would like to keep this section the same way. He is an amazing combination of a nice guy and a person who pushes you to the limit. He wasn't there to just have fun - But actually do something great. Good enough was not good enough - perfection was the only end point. In the end I didn't do everything that he asked for - but the game definitely ended up much better than if we had just aimed for something good enough. The couple of things I took out of this whole experience was to aim high and always keep improving.
Even though we were almost a day late I was very happy to have Mario Ball running for more than half of the summit. I think most people had lots of fun playing the game. There were some who said it was too experimental - but I thought that was part of what we were trying to do. Kaho had done an amazing job with the hardware - It worked without anything breaking for most of the summit (It briefly broke down on Sunday evening - but it was just someone had yanked on the controller so hard that the USB cable connected to the Arduino had come off. The crazy wiring just kept working the whole while).
So here it is - A picture of couple of people playing Mario Ball in the jungle themed arcade section of the Summit (The jungle theme was an amazing achievement of its own. Somebody needs to write about that). This should give an idea of the size of the controller and how it would take two people to use it. There are so many details in the controller I can't capture here. Keita added the fur like exterior and window handles(which reminded Keita of his Grandmother's house?) on the side so that you can easily hold and play.
Here is a video of people playing it at the Summit. I am sort of happy that I was able to capture the experience of the two players actually co-ordinating with each other to play the game.
I have no good words to end this post. Maybe that this is just the beginning. We will keep improving. You will see a better Mario Ball in the future!!
No comments:
Post a Comment