I’ve taken close to 10,000 screenshots over the course of Manifold Garden‘s development.
Here is all of them in a timelapse video:
I’ve taken close to 10,000 screenshots over the course of Manifold Garden‘s development.
Here is all of them in a timelapse video:
I’m finally back in Chicago after quite a bit of traveling. Tokyo Game Show last week was a blast! I’m still trying to process everything, but here’s the post-mortem about my experience while my memory is still fresh.
Back in May, I heard the news that Sony was covering the cost of booths in the Indie Game Area (IGA) at the Tokyo Game Show (TGS). It hadn’t actually occurred to me to submit to TGS prior to this. I had known about Sense of Wonder Night (SOWN) as Antichamber was shown there, but didn’t think I could justify the cost of going to Japan.
However, often with these large conventions, the cost of the booth is the most expensive item. This was certainly the case for me at PAX East. So with the Sony sponsorship, I thought, this could actually work, so I decided to submit.
The application deadline for IGA was June 11th. I submitted my application on June 10th.
Sense of Wonder Night is an event that takes place at TGS as well, and is a showcase of 10 games, focusing mostly on experimental titles. It was actually inspired by the Experimental Gameplay Workshop at GDC. The application process for SOWN was separate from that of IGA, and the deadline was about a month later, on July 7th. I also submitted Relativity to that.
Neither IGA nor SOWN required a submission fee, which was really awesome.
Only July 29th, I got an email from the Indie Game Area organizers saying that Relativity got in! To be honest, I wasn’t really expecting to get in, so had more or less forgotten about the event.
Needless to say, when I got the news, I was not only surprised, but also quite excited and nervous as well. Up until now, I hadn’t seriously considered going to TGS, and I only had 3 days to respond and confirm (I needed to let the organizers know my decision by July 31st).
Right away, I reached out to a few indie devs who I know had been to TGS, and also talked to other Chicago-based indies.
A lot of the feedback was along the lines of:
“Japanese players are not crazy about western-looking titles, and indies games (especially for the PC) don’t do really well there”.
“Don’t expect to make sales while there. You’re not going to meet the same fan base that you would at events like PAX East or PAX Prime”
However, everyone unanimously agreed that it would be a fantastic life experience. And if you’ve seen Alexander Bruce’s talk about the development of Antichamber, you’ll know that going to TGS and Japan in general was one of the most profound experiences for him as a developer.
I went back and forth on whether I should go or not, and ultimately decided I would. Here were my reasons:
After I responded to the IGA organizers and confirmed I was going, it was time to get ready. I had about a month and a half before the show began, so there was no time to waste!
One of the first things I did right away was to go to the library and check out a bunch of Japanese textbooks and audiotapes. I started practicing reading and writing hiragana, and also started listening to the Pimsleur Japanese series – doing one episode a day.
Now, as you probably know already, Japanese is an incredibly difficult language, and it takes people years to master. I wasn’t going to learn how to explain gravity shifting game mechanics in the span of 6 weeks. However, I did learn some basic conversational Japanese, like asking for directions, talking about eating and drinking, and this actually helped quite a bit when I was in Japan.
Poster and Postcards
The Tokyo Game Show organizers emailed a PDF manual about what to expect in the Indie Game Area, and what the booth looked like. One of their suggestions was to have a poster.
I figured since I wouldn’t be able to explain the game in Japanese, that I would put some introductory text on the poster to give people an idea of what the game is about, and a bit about myself. That way, if people have any questions, I can just point to the poster.
Here’s the design of the poster:
It turned out I was the only one in the Indie Game Area to do this, and it worked really well! A lot of the booths just had a poster with an image and the game title on it. This would be fine if you were just showing at PAX, but this meant that a lot of Japanese gamers couldn’t tell what your game was about. Likewise, there were several Japanese indies that only had posters with Japanese on it, and I had no idea what their games were about.
I got the same text printed on postcards, with the Japanese text on one side and English on the other. These were also really handy to have at the booth.
Regarding translation for the English text, I ended up contacting a translator living in Japan based on a friend’s recommendation, and also reached out to Playism, a company that does game localization in Japan. I had actually met someone from Playism on the shuttle ride to the airport during GDC back in March.
I only had about 200 words to translate – including the poster text as well as all the UI in the game, so it was pretty small translation job, and didn’t cost very much.
Once I got the text back, I actually shared my designs on twitter and asked for feedback. Moppin_, a Japanese Indie gave me some really good feedback, and helped me tweak a few sentences to improve the flow of the text.
Phone / Wifi
Like many of you, I now find it very difficult to travel without cell phone plans. Seriously, how did people meet up or find places before cell phones!?
As it turns out, getting a sim card in Japan is actually kind of tricky, as you need a Japanese address to do so. I did some research and decided that a pocket wifi device would be my best option. It’s basically a small device that can receive data, and you just set your phone to get wifi from that.
I ended up going with PuPuRu, which I highly recommend. The cost is about 4 USD a day. On their site they have a map that shows the different areas in which they have coverage. I spent all my time in Tokyo and surrounding areas, and didn’t have any problems.
If you do decide to get this, and want to have it right after you land in Japan, remember you need to book it about a week before you arrive. I had to let them know which flight I was coming in from and send them a copy of my passport. They sent the device in advance to the airport, and I was able to pick it up at the QL counter at Narita when I arrived. This was really convenient, as I was able to look up travel directions right after I landed.
Looking for booth help
As a solo developer, I’m very much used to traveling to conventions and doing everything by myself. However, getting some additional help when exhibiting is always nice.
As an exhibitor in the Indie Game Area, you can get up to 5 passes for free. I reached out to Twitter and asked if there were any indies based in Japan who’d be interested in helping me out for a bit during the show in exchange for a TGS pass.
Through this, I was introduced to Sagar Patel – a Kyoto-based Indie who is originally from Montreal, and who organizes the Kyoto Indie meetup. Sagar then connected me with his friend Alex, who is also based in Kyoto.
What little time I had outside of working on all the stuff above was spent getting the game’s UI localized in Japanese.
I continued to use OnGUI instead of switching to the newest GUI system in Unity 4.6. Mostly this was because I didn’t want to run the risk of breaking anything, and even though OnGUI is not very efficient, I was at least familiar with it.
I ended up hardcoding all the UI in both Japanese and English. This is not the best localization solution –the preferred method is to have the different languages in an XML file, and just call directly from that.
However, I didn’t really have too much time to implement that, and since I don’t have that much text in the game, I just decided to go with the hacked solution for now.
I do wish I had spent more time on optimization, as frame rate of the game running on my laptop was a bit of an issue.
I arrived in Japan on Tuesday, September 16th, around 5 PM, after a 20 hour trip. My flight was from Chicago to Toronto, with a 6 hour layover, and then a 12 hour flight to Tokyo.
This was actually pretty exhausting as my flight from Chicago was at 6 AM, meaning I had to be at the airport at 4 AM, so I just didn’t get any sleep the night before. On the other hand, I didn’t feel jetlagged at all when I landed.
After I picked up my pocket wifi device, I took the Narita Express train to Tokyo, then transferred to the metro line, and went to Ueno station, near where my hostel was located.
I checked in, and then grabbed a bite to eat at a restaurant nearby.
The party was really cool – a ton of industry people were there, both locals and people coming in for TGS. I also got to meet a lot of the indies who were going to be exhibiting in the Indie Game Area during the next few days as well.
One of the options given to exhibitors is to set up your booth the day before TGS starts. You actually have to let the TGS organizers know that you want to do this by September 10th. I figured since I’m carrying a bunch of things, and would prefer not to panic on the morning of the show, I’d go in earlier to set up.
The Tokyo Game Show takes place at Makuhari Messe convention center, and is actually in Chiba, which is about an hour outside of Tokyo. If you’re leaving from Tokyo Station, you need to take the JR Keiyo Line, and a one-way ticket costs 550 JPY.
This is the layout of Makuhari Messe:
There were 7 halls in total for the expo floor. The Indie Game Area (in pink) was in Hall 3.
And this is the layout inside the Indie Game Area:
Our location meant that it was really great for exposure, as we were directly across from Square Enix and Capcom. However, we were quite far away from the Indie Lounge area, which was were the benches were, so we couldn’t sit and watch people play our games…
A few things I learned:
It took me about an hour and a half to get set up. Most of the problem was because I was originally using Scotch brand double-sided tape, and it wasn’t very effective, so the poster kept falling off.
Anyway, here’s what my booth looked like once I got it all set up:
I am going to take a break from development of my game, titled Relativity, for the next few days to 1) reflect on the project and get an overview of the game so far, 2) plan out a course of action for the next few months, and 3) catch up on all the life things I’ve neglected for the past several weeks.
I should warn you now that this blog post will be quite long and convoluted, and will likely reference many things that probably don’t make any sense. This is because this post is intended mainly for myself to help me make sense of the project. However, if you’re interested in game development, you may find a few bits here and there that are somewhat useful, or at least interesting.
I have been working on the game full-time for a little over 7 months now. My initial intention was to create a small practice project to get myself familiar with the Unity engine, but alas, I am now knee-deep in development of a game I’m hoping to release publicly sometime in 2014.
By now, I’ve rewritten the entire game about 6 or 7 times, although the exact number depends on what would be considered a “rewrite”, as some versions contained major modifications from previous versions, but were not changed from the ground up. Both the game mechanic, as well as the visual aesthetics of the game, have gone through significant changes in the course of development, and will likely continue to do so. In fact, I would say that even the latest visuals are nowhere close to what the final game will look like.
Currently, these are the features I have implemented in the game:
While it is very difficult for me to estimate how far along I am in development, as this is the first game I’ve ever made, I would venture to guess that I’m about 30% of the way through. I have ideas for 5 more kinds of objects that the player can interact with, each of which will lead to 10 puzzles. By the time I finish implementing all the different ideas I have for player capabilities and object types, I will probably end up with around 80 to 90 puzzles. I will then select around 40 of the best levels from this group, and refine them over the course of a few months.
The core idea of the game centers around changing the orientation of gravity, and in this way, the player gains new perspectives on how to solve different types of puzzles. Without going into too much detail about the game play at the moment, I want to show you some screenshots of how the game has evolved. I no longer have the project files for the very first prototype of the game, but version 2 is pretty close, so I will start with that one.
As you can see, in versions 2 and 3, I put a lot of focus on the visuals, spending a tremendous amount of time looking at different wood panel and concrete textures to try to pick the right one. This was a bit of my mistake, as I should have spent that time prototyping different game play mechanis and puzzle designs.
Another mistake I made while working on these early versions was that I caught too caught up in creating a narrative for the game when the game play itself hadn’t been fully finalized. When working on version 3, I had written an entire elaborate backstory, including what the style of architecture should be, and even a new language system. Much of it was irrelevant to the game at this point, and used up valuable time. Also, by having a story set in place, it forced me to design puzzles around the narrative, instead of trying to create puzzles that explored the game play mechanic.
After having some people playtest the game, I realized I needed to rework the core mechanic and the puzzle design. It was hard to let go of the old ideas at this point, as I had already invested 4 months into the project. However, I knew that if I didn’t do it now, it would only get more difficult down the line. Also, around this time, I watched this talk by Jonathan Blow, in which he talked about the importance of constantly prototyping, and the willingness to ax an idea as soon as you realize it’s not working out.
With version 4, I decided to start from the ground up, and to focus on the game mechanic without worrying about the visuals at all. As you can see, pretty much everything in the game is white, with only a few colors here and there, and almost all the objects are basic primitive shapes. This allowed me to focus on the game play itself, and it was here that I began to find another mechanic that led to much more interesting and diverse puzzles.
From then on, I began to explore the potential of this mechanic, and would only introduce visual elements to the game when they played a function role. As such, there are no unnecessary visual elements. Everything, from the shape of objects to the color of the wall, exist to convey certain information to the player. The game may not look as “exciting” as the early versions, but the visuals are more carefully designed, and in this way, much cleaner.
Through various small changes here and there, I arrived at version 6, the latest version and what the game looks like right now. It is still nowhere close to finish, and I have a lot of ideas to add. Consequently, I don’t think I will get to the final polishing stage until early 2014.
During the first few months, I was able to keep track of the number of bugs in my head. But now, it seems like every feature has at least one or two minor bugs, and every time I fix one thing, something else seems to break. I thought this would be a good place to list some of the problems (in both design and development) that I am currently facing:
I spent the past few days adding decals to all the levels in order to better communicate puzzle objectives to the player. In the next few weeks, I will begin to create various new capabilities and design new levels accordingly.
While the interaction design and the feel of the game are not completely finalized, I’m pretty happy with how it is at the moment, so I will leave it as such for the time being. I do need to implement a way for players to save the game, and also to adjust the sensitivity of the mouse and the controller while they’re playing. I also need to implement a background timer so that once I begin playtesting, I can get an estimate of the game’s play length.
I will also start to brainstorm ideas for a story, and ways to communicate the story to the player, whether via in-game text, cut scenes, or voice-overs. However, I don’t want to get too carried away with the narrative at this point. I want to have the game structure pretty much set, and then use this as a foundation to create the narrative, instead of the other way around.
Finally, it has been a while since I pushed to Github, so I need to get around to doing that. Soon.