Tokyo Game Show Post-Mortem – Part 2: The Show Itself + Tokyo Indies

September 18th – Business Day 1

The Tokyo Game Show takes place over 4 days. The first 2 days are business days, meaning that it’s only open to industry people (in reality, the requirements for industry people is pretty relaxed), and the last 2 days are public days.

One of the things I’ve always wanted to do in Japan was to have sushi at at the Tuskiji fish market, which is the biggest wholesale fish and seafood market in the world. It’s a pretty popular destination, so unless you arrive super early, you have to wait in line for several hours.

tgs_fish_market

I woke up at 4:30 AM to go, and even though I got there at around 5:30 AM, the wait was for the most popular sushi restaurant was already at around 4 hours. I ended up going to the second most popular sushi restaurant, which only had a 1 hour wait. It was still very delicious! Grin

At the fish market, the workers all drive around in these little vehicles with barrel steering wheels. I thought this would actually make for a really cool game idea.
After breakfast, I took the train straight to Makuhari Messe. I got there at 9 am and met Alex outside to give him his TGS pass, and then we went inside to make sure the booth was ready (mostly this consisted of us trying to get the poster back up as it had fallen off during the night). Here’s my 1 hour long commute to Makuhari Messe summed up in 5 seconds:

Even though it was a business day, the first day of TGS was still quite crowded. The density of people felt quite similar to conventions like PAX, and I actually forgot that it was a business day. I had a very consistent flow of people coming to the booth to play the game throughout the day.

Here’s a pic of the crowd:

TGS_business_day_crowd

Here’s a pic of the Indie Game Area from the outside:

TGS_IGA_02

Here’s another from the inside:TGS_IGA_03

And here’s Marc Ten Bosch of Miegakure playing Relativity!tgs_player

After the day was over, a bunch of the devs showing in the Indie Game Area headed to a nearby pub called ‘Always’ to grab some food and drinks, and relax for a little bit. There’s not a whole lot of stuff around the convention center.

Afterwards, we all got on the train back to Tokyo to go to Otaru.

Otaru is basically a weekly meetup of people interested in game development.
It’s organized by 8-4, the guys behind the Pre-TGS party, and it is at this one Japanese restaurant/bar, where everyone sits on the floor on tatami mats.

Otaru Tokyo Game Show 8-4

In any case, it was a ton of fun, and I had a great time and met lots of cool people. Apparently, it was one of the largest Otaru meetups yet.

otaruThis photo was taken by Zachary Pintchik

September 19th – Business Day 2

During the day, a few members of the Friend and Foe team stopped by. If you’re not familiar with them, they’re currently working on the beautiful Vane. They actually have a devlog here that I’ve been following for some time now. I didn’t know they were based in Tokyo, so when I learned that they were going to be at TGS, I invited them to stop by!

Sense of Wonder Night presentation took place this afternoon from 2 pm to 4 pm. As I was already familiar with most of the games there, and had played them earlier, I opted not to go but to stay and watch playtesters at my booth instead. A lot of people who went said it was really cool though, so I do wish I could have gone.

tgs_player_09-19

Very positive response from players during the day. A lot of people plying for over 15 minutes at a time, which was really surprising for me.

Someone even finished the demo! :D I think it must have taken at least 40 minutes:IMG_6509

As we were wrapping up the day, Lucas Pope came by the Indie Game Area! I’ve been following Lucas’ devlog for “Return of the Obra Dinn” and have been blown away by the quality of his edge-detection shader. It was awesome to finally get to ask him some questions about it in person and to get feedback on the look for Relativity. This was pretty much the highlight of my day!

I have a few ideas now on how I can fix some of the artifact problems for my own shader.

From 5:30 to 7:30 pm, there was an exhibitor party organized by Sony. I didn’t take any pictures of the event, but it was pretty fun, and mostly it was cool to get to hang out with other exhibitors.

September 20th – Public Day 1
When I showed up to get the booth ready on this day, I thought someone had vandalized my poster. But it turns out, Relativity got nominated for some prizes! The one on the left is from Famitsu and the one on the right is from Dengeki:

TGS_nomination

This was the first public day, and boy, it was crowded! I thought business days were pretty crowded, but they were nothing compared to the public day. It was just a massive sea of people.

From the top of the stairs, this is what it looked like:

TGS_me_crowd Here’s another shot of the crowd from that day: tgs_sony_booth

After the day wrapped up, there was a party called the Indie Stream Fes:

indie_stream_fes_2014_logo

10 indies were selected to give 2-minute long lightning talks at this event, and I was fortunate enough to be chosen as one of them. The party didn’t start until 6 PM, but all of us who were doing lightning talks had to arrive at 5 PM to do a tech check and rehearse.

tgs_indie_stream_fes_prep

This was one of the coolest experiences at TGS for me, as I got to present Relativity in front of a crowd of around 400 industry people.

Here’s a shot of the crowd from the stage:

tgs_indie_stream_fes_crowd

Here’s Japanese Indie Dev Maruchu talking about his work:

And here’s Sun Park of Turtle Cream giving a talk about his 2nd person platformer game “Long Take”

During the party, the organizers also held a Kagami-biraki, which is a celebratory ceremony where they take out a sake barrel, and then break the lid of it using a wooden mallet. Then sake is served to everyone present.

They had these small little wooden boxes to drink the sake with, that had Unity printed on one side. I wanted to get a picture of me with one, but it seems that whoever I gave my phone to take a picture with had a bit too much sake to drink!

tgs_sake

Also, during the party, I got to meet one of the developers working on Pavilion! I randomly came across the trailer for that game late one night and was totally amazed by the art style and very surprised I hadn’t heard of it earlier. I didn’t realize he was based in Japan, so that was very cool.

September 21st – Public Day 2

Day 4 of TGS, and I have to admit I was feeling pretty exhausted by this point. I had basically been standing on my feet for at least 8 hours each day for the past 3 days, not to mention all the walking around.

The large crowd continued for this day, but it was a little less crowded than the first public day. I believe the attendee number of each of the public days is around 200,000.

Anyway, lots of positive response from players this day as well. Several played for over 30 minutes, and I think 3 people finished the demo, which is again, quite impressive. Someone even played for close to an hour! And when they were done, I asked them how long they had been playing for, and they said 30 minutes! :D

tgs_player_09-21

Here’s me at the end of the last day. Can you tell that I’m totally exhausted? I still had to pack up!

tgs_take_down

Like I said, don’t use Scotch brand double-sided tape. Just use the ones you can find at Japanese convenience stores.

IMG_6671

Here’s a shot during take down: tgs_cleanup

This is probably the first convention I’ve seen where people were riding parks around the convention center during takedown. They definitely had the right idea though!

September 22nd

Monday was my first day in Japan without anything I needed to do for TGS. I decided to go check out some parts of Japan outside of Tokyo. I ended up taking a day trip to Kamakura, which is a small city with a lot of temples about an hour and a half by train from Tokyo.

kamakura

In the evening, I went to a Tokyo Indie Meetup. This is a monthly meetup organized by local indie Alvin Phu, which is originally from Boston.

It took place in a gallery/cafe on the second story of a building in Shibuya. The event started off with just people hanging out and socializing, and then about an hour in, we started doing presentations.

IMG_6795

Japanese indie dev Moppin_ presenting his game ‘Downwell’:IMG_6798

Chris Johnson presenting ‘Expand’: IMG_6799

The Friend and Foe team previewed a trailer for Vane!IMG_6800

I had a USB with my Indie Stream Fes presentation, so I presented Relativity here too, and got some really great feedback! Anyway, it was a really fun event all in all. The Tokyo indie scene is small, but very vibrant. And lots of talent! I’m really looking forward to seeing the scene grow and play the games that come out of there.

Development Update – New Changes, Bit Bash, & IndieCade Feedback

Relativity_Game_Screenshot-2014-09-11_17-26-44

I am getting ready to go to Japan for the Tokyo Game Show. These last few days are getting pretty hectic with packing and making sure the build is ready, and of course, all the tiny little details that crop up last minute.

Anyway, I thought I’d take a moment to write about my experience showing Relativity at Bit Bash last weekend. I also heard back from IndieCade – unfortunately, I didn’t get in. I’d be lying if I said I wasn’t disappointed in the result, but the judges also gave me some really detailed and useful feedback. This is still a great opportunity to improve the game, and I’ll post their feedback  below, and share what I’ve  learned from this experience.

New Changes

Last month, I had the opportunity to show Relativity at SIGGRAPH as part of the MIX Showcase. I wrote about my experience and what I learned there in this devlog post.

Basically, after showing there, I realized that there were some serious design problems in the introductory part of the game.
When I got back to Chicago, I immediately scheduled a number of playtest sessions. I knew I had to redesign the introductory sequence in a very fundamental way before the Tokyo Game Show, and wanted to test out any changes, so I don’t run into unforeseen problems while exhibiting.

playtestingAbove – A friend invited me to his office to demo the game. Here is one of his co-workers playing the game.

I ended up doing about 4 playtest sessions a week for about 2 weeks, and slowly molded the intro into something new.

Here are some of the new changes I’ve made:

1. Interactive Instructions - Instead of having the instructions all in separate slides before the start of the game, the instructions now pop up during gameplay when players see the relevant element. Relativity_Game_Screenshot-2014-09-11_17-26-29 Relativity_Game_Screenshot-2014-09-11_17-26-37

2. Shortened the tutorial sequence - I want the player to get outside as soon as possible, as that is the real meat of the game, and the most impressive part visually. I realized that there were a few puzzles I had placed in the beginning indoor tutorial sequence that didn’t need to be there, and as such, could be moved elsewhere. For me, a good demo at a convention setting is when players make it through the interior tutorial section, and get outside. Too often though, I’d see people give up and leave right before the last puzzle. This was really anticlimactic, both because the player didn’t get to see the payoff for solving all these early puzzles, and also because they didn’t see the depth of the game. Relativity_Game_Screenshot-2014-09-11_19-21-43

3. First Hub World Overhaul - Completely redesigned the first hub world, effectively replacing it with the second hub world. From playtesting, everyone would talk about how much they liked the second hub world, while with the first hub world, people only talked about how often they got lost and how confusing it was.

Relativity_Game_Screenshot-2014-09-08_02-07-54

I think this is because the second hub world had logic to it. There was a meta-puzzle to the hub world itself, and this presented a sense of purpose, and a way to track progress. There were patterns that allowed the player to figure out where they had come from, and where they were going.

The original first hub was more or less random in design, and how you progressed through it depended largely on luck. Some playtesters told me that there was no sense of progression, and even when they did complete the level, it didn’t feel like they had completed it. They felt like they may have missed a thing or two.

After SIGGRAPH, I realized there was really no reason not to have the second hub as the first one. It’s better designed, easier to navigate, and everyone liked it. It was much larger than the first hub, but since it had a pattern and logic to its design, players found it much easier to deal with. It was only the second hub because that’s how I originally designed it, and my mind had come to accept that as reality.

4. Revamped the UI - I know it doesn’t make a difference in terms of the core gameplay, but having nice-looking UI really goes a long way!

Relativity_Game_Screenshot-2014-09-11_17-26-55

Bit Bash

bitbash

Bit Bash is a video game festival that a bunch of Chicago developers organized, which took place this past Saturday, September 6th. It was inspired by the Wild Rumpus party at GDC, and began as a series of conversations.

I won’t go too much into the festival itself, as there is plenty of information on the interwebz, except to say that it was a huge success with a turnout of around 1,400 people, and demonstrates that there is clearly a demand for such an event here in the Midwest. Also, the Chicago indie community is made up of a group of seriously awesome people, and I’m incredibly blessed to be based here.

IMG_6053Above – There was a huge crowd only an hour into the festival.

Anyway, showing the game at Bit Bash proved that all the design changes I had made were right. This time, instead of actively trying to recruit players, I would stand back and observe. And I noticed that people were making through the tutorial section and getting outside. It also helped a lot that I improved the start menu screen, so that it actually looked attractive and got players interested in it.

I had spent a lot of time on UI, and the game at Bit Bash was more or less able to run itself. There was a constant stream of players, and I didn’t have to stand around to reset it. Because of the improved UI and faster load time, people could very easily restart the game themselves.

I would stand in the distance and keep an eye on the screen, and after people finished playing, I would go up, introduce myself, and ask them some questions about what they thought. Almost everyone was able to make it the exterior parts of the level, so that was a very good sign.

Here are some shots of people playing the game at Bit Bash:

IMG_6060 IMG_6061 IMG_6067

IndieCade Feedback

Yesterday, I received an email from IndieCade informing me that Relativity wasn’t selected for this year’s festival. Needless to say, I was pretty disappointed. IndieCade was one of my top festivals I wanted to get into.

However, having seen the issues that arose when I was at SIGGRAPH, I can totally understand what happened. One of the really nice things about the IndieCade submission process is that the judges are required to give feedback on the games they juried.

The feedback I got from the judges were very informative and detailed, and I totally agree with the points they made, especially regarding the box puzzles. In fact, during a playtest session about 2 weeks ago, a playtester told me that he found the box puzzles to detract from the main theme of the game, and were very tedious to play through. This got me thinking about their role in the game, and I’ve since decided to scale them back a lot. So it was great to read the comments from the judges about the box puzzles. It means that the decision to lessen the role of the block puzzles in the game is the right one.

As always, each feedback is an opportunity to improve the game. It definitely hurts when criticisms are made about your game, but it’s important not to get emotional about it. This isn’t about feeling good, it’s about making a great game!

It can be easy to dismiss the feedback from the judges, saying “they didn’t get it” or that “this is just not the kind of game they like”, and I’ve seen some people posting on twitter to this effect upon finding out they’ve been rejected.

However, from the feedback I received, it’s very clear that the judges took the time to play through the entirety of my demo (which takes on average about 3 hours for a first time player), so the judges clearly made an effort to play and understand my game. I really appreciate this, and since the judging process is anonymous, and there’s no incentive for the judge to lie, it’s really important to think about why the judges felt that way. It can be easy to blame the system, to become angry and say that your game was biased against, but I think it’s much more effective to use this opportunity to really analyze your game – ask yourself if the design is really that good, and what’s holding it back? It’s not fun, but it’ll make your game better.

Anyway, since the feedback given was anonymous, I’ve decided to post it here in its entirety (this is for the version of the game in July 2014):

—–

Once my head got used to it and didn’t hurt anymore from switching, the game was interesting. However at one point I did feel like I was doing stacking boxes against a ledge. Navigating the balls through the tunnels bugged a bit in the big puzzle; the ball fell through the doors I was meant to open. ‘
In the seemingly endless staircase, I guess this was sort of the end of the game for now? I could revisit previous puzzles, and a place with cubicle-likes connected to each other. I fell through a connecting beam that was glitching with green. I also fell out of the endless staircase that didn’t turn out to be endless (red gravity). Here was another of those cubicle-like below it, but I missed it and fell into the void.

I think I was able to skip some puzzles in the first open world, I didn’t need to use a blue box there. I just fell myself toward the green pop and could make it from there.

I hope that if you’ll make more puzzles, you’ll be able to make some that feel more different from each other. The box-against-the-wall puzzles are different from each other, but they don’t feel that much different, since the concept of solving them is often the same, just a little more difficult. I’m sure you can think of some that are more clever, rather than more difficult; it feels like you can get a little more out of this.. Surprise your player!

Hope you won’t think of me as too harsh. I love puzzle games (such as Antichamber and Portal, which seem like a big influence), but that’s why it feels familiar and the patterns are easy to recognize.

Good luck with the rest of the development!

—–

The core mechanic of Relativity has immense potential. The first time you flip the world and start walking on the ceiling to access a hidden corner of a room is a real thrill. That novelty and discovery propelled me through the much of the game. And while walking through the different rooms there’s a real sense of how the entire structure connects in greater way. Walking outside the buildings into the open spaces where you can see the worlds repeat infinitely is a unique and wonderful moment.

The individual puzzles though bog down the experience by making the focus of the game on block placement than the joy of shifting the axis of gravity and bending spaces. While there’s some clever puzzles based on following block-line connections across floors and walls too many times I felt like I was staring at the floor placing blocks over and over. The worst offenders here are the puzzles in which you are required to use blocks as temporary platforms to get across spaces. The effective landing area of the player is a lot smaller than you would think and each time you fall off and have to restart the process is an exercise in frustration.

Still though the newness of the mechanic really helped push me the more mundane moments. I look forward to seeing the experience as it develops and I feel this game with further refinement and polish can be something incredibly special.

—–

Art is great, shows a nice refrain given the subject matter. For more variety, maybe different superstructures could have different color schemes, bright, dark or colorful, etc. Something as simple as alternating the color scheme could really give different superstructures different moods.

I really enjoyed the mistake of slipping off the edge of the structure, it was a pretty clever way to handle ‘falling of the edge.’

While engaging at first, the box-stacking component of the gameplay became a bit tiresome, especially because you know the solution, but now you have to apply the repetitive movement to complete it. I wonder if experimenting with the box scaling could help with this?

I did enjoy falling off edges to get to strategic locations, which there was more of later in the game, like when you’re turning on the color-coded beams, you’re falling down into various nooks and cranies of the superstructure. There was one interior puzzle where, after an extensive box-stacking, I lept off with a box in hand to the desired platform.

I would’ve like to see more variety in the puzzles, maybe this could be a good angle? Since its a WASD first-person with a central gravity mechanic, I think considering more non-discrete acrobatic movement in the puzzles could help add diversity.

—–

IGF Feedback

The IndieCade feedback strongly parallels the feedback I received when I submitted Relativity to IGF last year. When I submitted Relativity in fall of 2013, I thought I had such a kick-ass demo, and the judges would be crazy not to choose this a finalist. Of course, this didn’t happen, and I was disappointed.

However, I continued to work on the game, to improve it, and by the time I got the feedback from the judges, in April 2014, I not only agreed with the problems they pointed out, but I had also started to address those.
In the spirit of open development, I meant to share the feedback I received for IGF when I received them, but had forgotten to, so I’m going to do it here. This is for the October 2013 version of the game:

——–

I just wanted to say that I had a great time playing Relativity, and I think the general premise has a lot of potential for some interesting puzzles. But I wanted to convey my thoughts that it felt like this was the BEGINNING of a much bigger and better experience. And by that I primarily mean how you progress. The colored box system works, but I don’t think that should be the primary form of interaction/progression. I don’t want to sound disrespectful when I say this (as I probably would be annoyed by this feedback if I worked on the game), but I would recommend trying to experiment with what it means to orient the gravity to each wall in a room. I think there’s a lot more that you can find if you mess around more. What if there was a linear progression through a room, with the room filled with stairs and hallways, and you had to go through the right order? What if this? What if that? As I played the game, I sorta got bored by the colored block requirement and I just started walking around the room, flipping the gravity. It was like a breath of fresh air, and it makes me think there should be something more inherent to that in terms of going through the game. It’s way more fun to think of where you are, instead of where the blocks are. I guess that’s it, base it on the player’s perspective primarily, not the block’s perspective. But again, this is your expression, so take what I say with a grain of salt. I think, with more time, it could be a great game. I definitely like the block idea, but I don’t think it’s the “true” form of the game.

Oh, and not sure how far along the game is, but try to differentiate yourself visually and narratively from Portal, otherwise players will think it’s a retread of what Valve already did. To me it definitely like I was playing Portal again, and that loses some of the wow factor. But overall, great job on it! I’ll be looking forward to what you do with it in the future :)

—–

Hi there – was very interesting playing through Relativity. As a game I think it’s definitely accomplishing some of what it sets out to do, but it also feels very very early in terms of things like setting and puzzle design, which I think is holding it back a bit for me in terms of voting for any of the categories.

Let me say, first, that I think that you really have got a lovely mechanic here, and one that’s much more interesting that just “look ma! I can walk on the wall!”. I think the way it changes your relationship to the space of the world is fantastic, more interesting than the Portal gun I think, in the way that it’s localized and perspective-changing. I had several occasions when I felt genuinely disoriented and the way that the game forces you to spend a lot of your time *not* taking an orientation to the world is really interesting (and slightly nauseating at times). I had a moment of running up some stairs while very much simultaneously thinking of myself as running *up* them toward a wall. These sorts of moments are just the kind of Escher-esque things that can be great about this game.

So, that said, I didn’t vote for any of the awards because it just feels too early. You have this really interesting mechanic and relationship to the world, but the world isn’t there yet, the puzzles aren’t really there yet, there’s no contextualization, no texture (literally and figuratively) and so on.

Very, very much looking forward to seeing where you take this.

Also a “bug” (perhaps it isn’t, it hard to tell in these sorts of environments) in the elevator cube thing – if I changed orientation while inside it I got spat out into the surrounding world. Which I initially thought was a kind of homage to Portal’s furnace scene, but didn’t actually seem to be. Nice potential easter egg to hide there somewhere maybe.

One minor technical comment is that I think it would make a *huge* different if the orientation change was just animated quite a lot faster (and perhaps more smoothly)… the jolt of stopping at a wall definitely removed some of the kinaesthetic enjoyment of the space…

—–

The puzzles were fun/interesting, but — in the end — was looking for more of a ‘hook’ to the game, other than the whole walking-on-walls thing. Would like to see some kind of story or ‘voice’ to set this game apart and make it feel like more than a Portal homage. Also, agree that the overall mechanics need to be tightened up/smoothed out to be an optimal experience. 

—–

Conclusion

Making a game is hard! For me, I’ve been working on this game alone for almost two years now. It’s like my baby now, and it can be really difficult to get an objective view of the game. My feelings toward the game can go from thinking it’s the coolest thing ever one day, to thinking that it’s absolute crap the next day. Rejection is never easy, and taking criticism is still difficult. I get butterflies in my stomach whenever I’m about to open an email with feedback on the game. However, honest, straightforward feedback that point out the problems in your game is hands down the best way for you to improve!

When I look at the IGF feedback and see how far the game has come, I know I can do the same for the IndieCade feedback!

Development Update – Arrows on Boxes

I had a few game developer friends playtest the game last Thursday. The response was quite positive. I implemented a lot of the feedback I got from GDC regarding puzzle pacing, and it’s definitely much better now. By adding a few smaller puzzles that isolate specific concepts in between the larger puzzles, I was able to smooth out the learning curve, while at the same time not dumbing down those larger puzzles, which I really liked.

The new look is also working really well. Making lines vary with distance is still an issue, but it didn’t affect gameplay too much.

One feedback I got was that players have a hard time remembering which direction a box falls towards. This is especially an issue in puzzles where you have to have boxes from three different gravity fields all working together to accomplish your task. In this situations, it’s really important to know which direction a cube is going to fall, since sometimes you’ll want to avoid rotating onto particular surfaces.

A lot of people have suggested adding arrows to the boxes to address this issue. I finally got around to doing it yesterday. It took way longer to implement due to some unexpected issues with generated meshes not being saved into a prefab object in Unity, but it’s all done now.

Here are some screenshots of the new boxes in action. It’s definitely an improvement, especially since even when I’m playing the game, I find the arrows to be quite helpful.

Relativity_Game_Screenshot-2014-04-04_18-14-57

 

Relativity_Game_Screenshot-2014-04-04_15-11-25

 

Relativity_Game_Screenshot-2014-04-04_17-16-43Relativity_Game_Screenshot-2014-04-04_18-30-26

Development Update – Edge Detection

One of the things I’ve decided to focus on these past few days is to refine the look of the game, and try to develop a unique visual identity. Up until now, pretty much every visual decision has been made based on functional reasons.

Since architecture has been, and still is, a key theme of the game, I thought that would be a good place to start looking for inspiration. Eventually, I came across this post by Thomas Eichhorn about a shader inspired by old architectural drawings. Eichhorn originally wrote it for vvvv, but looking at the image of the final result, I thought this would be a good place for me to start.

I took his image of the final result of the shader, and added a layer of blue highlights to the upward facing surfaces:

relativity_look

I actually quite like the look. Immediately, it provides a sense of atmosphere, a warm, nostalgic feeling that takes me back to reading illustrated adventure books as a kid. I thought it would be a great style to offset to clinical/sterile nature of the game at the moment. Also, it didn’t look like any other 3D game out there, so this would help in establishing a visual identity.

But first, I had to roll up my sleeves and dive into shader programming.

Edge-Detection

I started off by looking at the edge-detection image effect script that comes packaged with Unity Pro. After a day of being totally confused, with a failed attempt at learning node-based shader programming with Shader Forge, I was eventually able to understand what the script was doing.

There are 5 different modes with Unity’s edge-detection script. For my purposes, the closet one to what I was looking for was “RobertsCrossDepthNormals”, which basically selects one pixel, and then checks to see if the surrounding pixels have similar normals or depth values. If not, then a edge is drawn. However, there were a few problems, namely, it wasn’t able to pick up several important edges.

Here’s a shot of a set of stairs, which is pretty common throughout Relativity:

Edge_Detection-2014-03-31_18-36-28

With Unity’s edge detection applied, this is what it looks like: Edge_Detection-2014-03-31_18-35-50

So you can see the problem here is that the edges of the steps on higher section of the staircase are getting lost. This is because the algorithm is using both the normals and the scene depth to figure out the line, and in the higher sections, because you’re just seeing the front face of the steps, and not the top face, the normals are all the same.

You can increase the depth sensitivity, which does pick up the edges of the steps higher up, but also ends up with these black artifacts for areas in the distance, where there’s a large change in depth value. You can see the same issue happening on the side of the cube in the middle of the frame:

Edge_Detection-2014-03-31_19-49-50

Another problematic area was when I had staircases on the side:

Edge_Detection-2014-03-31_18-37-27

From this angle, Unity’s edge-detection works really well, since you can see very clearly both the front face as well as the top face of the steps:

Edge_Detection-2014-03-31_18-37-15

However, from another angle, the edges disappear completely: Edge_Detection-2014-03-31_18-37-40

I decided therefore to create my own edge-detection algorithm, using what Unity has done as a starting ground. The main difference is that instead of checking to comparing to see whether both the normals and depth values are similar, I break it into two steps.

First, I do a check comparing only the normal values of surrounding pixesl. The selection of pixels is actually from the original Unity script. Basically, if the pixel we are examining at the moment is “A”, then compare the normal value of the pixel “B” vs “E” and then “C” vs “D”.

pixel_layout

The reason why I start with normals first is that, in my case, there are no false positives. In other words, when you’re only using normals to do edge-detection, you will only miss edges, you won’t pick up wrong edges. Of course, this wouldn’t work if you had curved surfaces, but for me, since all the angles in Relativity are 90 degree angles, and everything is made up of boxes, this was no problem.

So I draw a first set of edges that pass the normal test.

For the second step, I then take everything else, and run it through a depth test. This time, I add up the depth values of pixels “B”, “C”, “D”, and “E”, then divide by 4, getting a value for the average depth value for the surrounding pixels. I then subtract this value from the depth value of pixel “A”, and if the difference is greater than 0.001, then it’s determined to be an edge.

In the following images, the blue lines are edges drawn in the first round by comparing normals, and the red lines are edges drawn in the second round by comparing depth values.  Edge_Detection-2014-03-31_18-59-35

Edge_Detection-2014-03-31_18-59-22

Edge_Detection-2014-03-31_19-00-04

 

You can see that where the normal test misses the edges, the depth test is able to catch them. And the sensitivity at which the depth test is set allows me to pick up the edges, while not getting any of the weird artifacts from the default Unity shader.

Here’s what it looks like with all black lines: Edge_Detection-2014-03-31_18-39-11

Of course, there’s still some issues, such as the normal lines being thicker than the depth lines, and I still need to fade out the lines in the distance to help with player depth perception. But overall, I think it’s a pretty good start, especially since considering yesterday morning, I had no idea even how to approach this.

Development Update – GDC Feedback

Hey all! It’s been a while since the last update. March has been a pretty busy month. Between trying to implement all the feedback from IndieCade East in February, attending GDC, and starting playtesting again, I haven’t found the time to post here as regularly.

Anyway, finally made enough progress on the different fronts to take a small break and write up an update.

GDC

So, this was my first time attending GDC, and just as everyone had told me, it turned out to be awesome. I only had an expo pass, so didn’t get to go to any of the talks or workshops. But even then, for me, it was amazing just meeting other developers and getting feedback on my work.

There were so many indie developers whose work I respect that were there, and all of them were super approachable and generous with their feedback. Some of the people who I had playtest the game and get feedback from were Justin Ma (FTL), Marc ten Bosch (Miegakure), Brendon Chung (Quadrilateral Cowboy), and Pohung Chen (Perspective). They all had very different and interesting insight and feedback on the game.

Relativity_2014-03-30_v8 2014-03-31 16-36-58-14

Justin talked about having a clear distinction between areas where the player is solving a puzzle, vs areas where the player is supposed to be exploring. If there’s confusion between what the player is supposed to do, the player can’t quite approach the problem with the right mindset. For me, this was a really good insight, because I had noticed that sometimes players would walk into a puzzle room, and when they don’t get the puzzle right away, they would turn around and walk out, thinking they had missed something they need earlier.

For me, when playing other puzzle games, this is a really frustrating feeling to have. Is the reason why I’m not able to solve this puzzle because I’m not getting it? Or is it because I just don’t have the right tool? This is why I really enjoyed Portal’s puzzles, because you knew in each test chamber, that all the elements you need were right there, you just needed to piece them together correctly.

From this, I know I need to make the distinction between puzzles and exploration areas more clear. The challenge is that, unlike Portal, there is backtracking in Relativity. I don’t seal off a test chamber once you enter it, so how can make sure that the player understands that they have everything they need right there to solve it? Fortunately, because the player can walk on all different surfaces in the game, I can place the entrance in an area that’s not as easy to go back into once the player enters a puzzle area, so that it’s clear, “hey, this is an isolated area with a puzzle”.

He also had some feedback with the visuals, and really emphasize the need for the game to have a unique visual identity, to distinguish it from a lot of other FPS puzzle games.

Relativity_2014-03-30_v8 2014-03-31 16-37-42-44

I showed the game to Marc ten Bosch and Brendon Chung separately on Thursday afternoon at GDC, one after the other, and both gave me really good feedback on puzzle pacing and level design, specifically on how to isolate individual concepts, and introduce them one at a time. I didn’t realize until then that in a lot of my earlier puzzles, I was actually introducing 2 or more concepts at once, and a lot of players would get confused on what they were supposed to take away.

It was also interesting to see their approaches to puzzles. Marc, himself working on a puzzle game based on an abtract mathematical idea, found the difficulty level in the puzzles to be just right, and said that any hints or additions to make them easier would ruin the puzzles, but Brendon, who does more linear narrative based games, found the first puzzle to be really challenging. In a way, both are correct. The puzzles don’t need to be made easier, but there needs to be other puzzles before those, to correctly lead up the player. This way, it can address the issue of pacing. For example, I ended up adding another puzzle before what was originally the first one, to isolate one of the concepts, and but kept a lot of the other designs. From playtesting I’ve done since then, this seems to work a lot better.

Relativity_2014-03-30_v8 2014-03-31 16-38-23-13

Pohung gave me some awesome insight on puzzle design. He used an analogy from the Chris Nolan film, The Prestige, specifically this line about the structure of magic acts:

Every great magic trick consists of three parts or acts. The first part is called "The Pledge". The magician shows you something ordinary: a deck of cards, a bird or a man. He shows you this object. Perhaps he asks you to inspect it to see if it is indeed real, unaltered, normal. But of course... it probably isn't. The second act is called "The Turn". The magician takes the ordinary something and makes it do something extraordinary. Now you're looking for the secret... but you won't find it, because of course you're not really looking. You don't really want to know. You want to be fooled. But you wouldn't clap yet. Because making something disappear isn't enough; you have to bring it back. That's why every magic trick has a third act, the hardest part, the part we call "The Prestige".

In the same way, a great puzzle should follow this structure. Pohung used one the puzzles from Relativity that he felt did this correctly (which was actually unintended on my part). The puzzle had two parts. The first part is pretty easy, and is meant as a build up to the second part. The second part at first seems like the first part, but actually requires a variation of the technique. Pohung talked about his line of thinking in approaching the second part, going “Ah, this looks easy, it’s just what I did before…. wait a minute… that’s not going to work here… hm….. ah ha!”. As such, this puzzle shows something ordinary (a simple technique that the player learns), then something extraordinary (the puzzle looks similar, but it seems the technique no longer applies…), and then brings it back (player realizes a variation of the technique would work).Relativity_2014-03-30_v8 2014-03-31 16-38-45-43

Anyway, it’s quite difficult to talk about puzzle design in depth without showing you the actual puzzles. However, hopefully there’s some high-level stuff that you may find helpful in approaching puzzle design for you own games.