Tokyo Game Show Post-Mortem – Part 1: Application and Preparation

TGS_poster_horizontal

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.

Application Process

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.

Hearing Back

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:

  • For me, development of the game is about the journey behind it, as much as it is about the game itself. To this end, I want to experience all the opportunities that are available to me. I’m not doing this just to make a game – I also want to meet passionate people, go places I wouldn’t have gone before, and grow as a person.
  • I’m still pretty far from release, so I’m not looking to make sales at the moment. My main priority is still to get feedback on design. TGS would be a great opportunity to receive feedback from players coming from a totally different cultural background, and who have likely never heard of or seen the game before.
  • I had originally planned to save up to exhibit at PAX Prime. However, when talking to a fellow indie dev, he pointed out that showing at similar conventions may not give you the same return each time. I’ve already shown at PAX East, and while PAX Prime is an opportunity to meet new fans, the demographic of the two conventions is quite similar. From a playtesting standpoint, I’ll probably see a lot of similar people at PAX Prime as I did at PAX East, so may not necessarily gain new insight based on players’ backgrounds.
  • Another event I had been considering going to at the same time was Fantastic Arcade in Austin. I had submitted my game to that, and didn’t get in, but was thinking I would still go to meet other indie devs and get feedback on my game from them. However, as was pointed out to me, a lot of these devs I am very likely to meet at the other North American conventions, like GDC and IndieCade. And really, I can get feedback from North American indies anytime I want. At TGS though, I am much more likely to meet people who I would never meet otherwise.
  • The life experience – While I’ve traveled to Japan twice prior to my TGS trip, neither were for work. This seemed like it would be a fantastic way to see a side of Japan that isn’t a cookie cutter experience. Plus, as a game developer, going to Japan for a video game convention seems like such a cool experience. It’s the mecca! It’s not very often I get to travel overseas for work, so I didn’t want to look back and regret not taking this opportunity to experience something new.

Preparation

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!

Japanese Language

tgs_japanese_books

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.

tgs_booth_design

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:

TGS_Relativity_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.

postcard_horizontal

Translation
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.

huawei_gl04p_pocket_wifi_lte

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.

The Game
What little time I had outside of working on all the stuff above was spent getting the game’s UI localized in Japanese.

relativity_UI_bilingual_02

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.

Travel

September 16th

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.

TGS_flight_path

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.

TGS_Narita

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.

TGS_First_meal My first meal in Japan!

 

After that, I headed over to Roppongi for Pre-TGS party organized by 8-4, a video game localization based in Tokyo, and they also have apodcast.

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.

TGS_84_play

September 17th
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:

makuhari messe layout

There were 7 halls in total for the expo floor. The Indie Game Area (in pink) was in Hall 3.

indie game area layout

And this is the layout inside the Indie Game Area:

tokyo game show layout

I was in booth 84, highlighted in yellow. The booths are organized by alphabetical order. I was in between Wales Interactive and Witch Beam, who were awesome neighbors for the 4 days.

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’s better to rent a 26” TV from the convention center for 10,000 JPY (100 USD) instead of bringing your own monitor. I brought a monitor, and yes, I saved some money, but it is a serious hassle carrying a giant suitcase through the Tokyo train lines during rush hour. There’s also a ton of walking you have to do to transfer between lines, and some of the stations don’t have elevators/escalators. For all the trouble my giant suitcase caused me, I would have gladly paid for the TV. Plus, it was much bigger than my 21” monitor, and you don’t run the risk of accidentally breaking your monitor.
  • Don’t use Scotch brand double-sided tape, it doesn’t work very well, and it leaves a mark. I bought some double-sided tape from a convenient store while in Japan, and it worked way better.
  • The booth only provided two outlets – this wasn’t enough as I had my laptop, the monitor, speakers, and phone charger. I asked if I could have extra outlets, and soon enough, two workers came and installed them for me. What I didn’t know was that this actually cost 3500 JPY (35 USD), and on the last day, I got a bill unexpectedly. Sad If I had known, I would have just gone out and bought an extension cord. Oh well.

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:

IMG_6377

Relativity: The Journey Thus Far

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.

State of the Game

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:

  •  28 puzzles
  • 1 environmental hazard
  • 2 different kinds of objects to interact with
  • Various visual cues to assist with interaction (allowing the player to better sense distance)
  • Some sound effects
  • Various environmental cues to assist the player with determining the objective of each puzzle
  • Some placeholder background music
  • Title screen and in-game pause menu
  • Xbox 360 controller support.

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.

Evolution of the Project

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.

Version 2Relativity_02_Screenshot_01Relativity_02_Screenshot_02

Version 3Relativity_03_Screenshot_01 Relativity_03_Screenshot_02

Version 4Relativity_04_Screenshot_01 Relativity_04_Screenshot_02

Version 5Relativity_05_Screenshot_01Relativity_05_Screenshot_02

Version 5.5
(This version didn’t contain enough significant changes to warrant a full number upgrade)Relativity_05B_Screenshot_01 Relativity_05B_Screenshot_02

Version 6Relativity_06_Screenshot_01 Relativity_06_Screenshot_02 Relativity_06_Screenshot_03

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.

Problems I Am Having

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:

  1. The game looks too much like Portal. While it does seem like you can’t make a first-person puzzle game without people inevitably comparing it to Portal, I think the visuals at the moment do draw a little too heavily from that game. Most of these are placeholder art I’m using to prototype levels, so eventually they well be redesigned. But when I show the game for playtesting, the first thing that springs to the player’s mind is Portal, which ends up influencing their expectations. Right now, this isn’t necessarily a negative thing, but I do want the game to have a unique visual aesthetic and style, so I will have to spend some time on this aspect of the game later.
  2. Collider objects intersecting with one another. I think this problem is mostly due to the native physics engine in Unity, which requires objects to intersect one another in order to calculate collision. For most circumstances, the intersection is minor and doesn’t affect game play. However, because stacking boxes is a pretty major component of my game, intersection of the boxes is a bit of an issue. I’ve found a way to minimize the intersection by playing with the min penetration value in the project settings menu, and making objects kinematic when not being used, but collisions are still not working as well as I would like.
  3. Odd physics glitches here and there. The physics in Relativity is heavily restricted. For example, there is no rotation and no bounce. While this is unrealistic, I found that it was a huge improvement with regards to the playability of the game. This is because the game requires very precise placement of objects, and if the physics is too realistic, it actually becomes very difficult to position objects in the desired positions. By restricting the motion within a certain range, I can minimize player frustration. As such, I am overriding a lot of the native physics functionality in Unity and writing my own. For example, sometimes, for collisions I am using triggers placed on the surface of objects, and using the trigger to detect whether something has come into contact with an object, instead of the default collision detection functions. This leads to unexpected bugs here and there, like objects going through walls, especially when the objects are used in a new situation. I haven’t quite figured out a good way to tackle this issue yet except to try everything I can think of when playtesting, and see if any odd behavior arises.
  4. No narrative. This is not really a problem at the moment, as I’m still trying to refine the game feel, and to work out all the puzzles and player capabilities. However, at some point, I will need a narrative structure for the game in order to provide incentive for the player to keep going. It gets a little boring to keep solving puzzle after puzzle without knowing why, and with no end in sight.
  5. OnTriggerExit function on some of my triggers are called when it is not desired. Specifically, when I have a kinematic collider sitting on the trigger, and another objects hits the kinematic collider, OnTriggerExit will be called, and the trigger will think that the kinematic collider has left even though it hasn’t. If I make the collider non-kinematic, then I get major problems with colliders intersecting one another, as stated in problem 1 above.
  6. Player occasionally rotating out of the room. I think this can be solved by using a ryacast from the back of the player’s head and determining the distance from the player to the wall to make sure player rotation doesn’t cause the player to flip out to the other side of the room. However, in my experience so far, these small problems are usually deceptively difficult and end up taking a ton of time to fix.

What’s Next?

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.

A Few Lessons I’ve Learned So Far:

  1. Always be prototyping.
  2. In the early stages of development, focus on game mechanic, not narrative and visual aesthetics.
  3. Playtest often, and early.
  4. Don’t be afraid to let go of ideas that are not working.