next »

[William Chyr]

Just came across this bug and thought it looked kind of cool:



Not sure exactly what's going on, but it looks like the render texture of the portal is rendering the view from the player camera, but with the scene normals as the colors.

[William Chyr]

DevLog Update #59 - 05/29/2014

Spent the last two days getting the game ready to demo at Indy Pop Con in Indianapolis this weekend.

This involved making builds, and playing through them to make sure everything is working. Now that the game is so much bigger, this turned out to be quite time-consuming. I was able to rush through the entire build in about 30 minutes, knowing how to solves the puzzles and where the shortcuts are, etc. My guess for a first-time playthrough by someone not familiar with the game, this would take somewhere around 2 to 3 hours.

I've also added vignetting and a little bit of noise to the player camera. I think this makes it look a little more dream-like:

[Elideb]

I re-discovered your game this weekend and read the whole devlog in one (long) session. Honestly, every new image I saw looked even better than the previous.
And with the new shader, it looks great (stairs not-withstanding).

I'll have to read all those posts about shaders, because we are looking for a way to improve the looks of Heart&Slash. I have been playing with shaders for soooo long, and still know so little 

[William Chyr]

@Elideb:

Really great to hear this! Thanks so much for taking the time to read through the devlog!

Shaders have been something I've been wanting to learn for so long, and so I'm happy to finally be able to work on them and have somewhat of a basic understanding. They're incredibly powerful. I can't say writing them as been that much fun for me though, mostly just because the debugging process is really painful.

BTW, Heart&Slash is looking fantastic!

[William Chyr]

DevLog Update #60 - 06/03/2014

Indy PopCon Post-Mortem

I exhibited Relativity at Indy PopCon this past weekend, and decided to write up a bit about my experience.

Indy PopCon is a pop culture and comic convention that took place in Indianapolis, at the Indiana Convention Center from Friday, May 30th to Sunday, June 1st. This was its first year, and I initially heard about the conventions from the guys at The Amiable. At the time, I hadn’t been to a convention before (this was before I even got into the Indie MEGABOOTH at PAX East), and didn’t really know what to expect.

However, I had heard from other developers that conventions are really useful for a number of reasons, and since this one wasn’t very far away, and was relatively inexpensive, I decided to go for it.

By the time Indy PopCon rolled around, I had already shown the game at IndieCade East’s Show & Tell, and also at PAX East, so I had a much better idea of what I wanted to get out of the experience.

Primarily, I wanted to test out the new design changes I had implemented after PAX East, to see if they are effective, and if I’ve resolved the issues I had witnessed then. Since IndieCade East back in February, I’ve been on an intense cycle of playtesting & iterating. Every month, I’ve attended at least one public convention, and each time, it has allowed me to pinpoint different problems with puzzle progression and pacing.

At PAX East, the introductory section of the game was quite good, but I did notice about 4, 5 areas that caused hiccups, and resulted in players getting stuck for longer than necessary. Since then, I had introduced recursive world space, rearranged some of the puzzles, and also tweaked the architecture in the puzzles.

I wanted to use Indy PopCon as an opportunity to see if these changes fixed the problem. With this in mind, and the fact that the game is still a bit ways away from release, I wanted to keep the booth very low-key. I wanted to see how people who hadn’t heard of the game before, and no idea what it was about, how they would react.

Here’s a picture of my setup:


Next to me on one side was Card Dungeon, and on the other side was an empty table. Here’s what it looked like from the other side. I was directly across from Young Horses (Octodad), Ragtag Studio (Ray’s the Dead), and Lunar Giant (No Kings):



The Convention

Indy PopCon was very different from PAX East. For one thing, it was magnitudes smaller. In large part, this was because it was its first year in operation. Another big difference is that it wasn’t a game-specific convention. There was only a small section made up of game developers (around 25 booths/tables). The majority of the booths from what I could see were related to comics, toys, cosplayers, and other internet stuff. This meant that you had a lot of people who attended to see comics or other things, and who had no interest in games.

This was very noticeable, especially on Friday morning (the crowd on Friday is very different than the ones on the weekend). At PAX, out of the many people I asked to try out the game, I can only recall one person who turned me down. Almost everyone there is interested in games and willing to at least give something a try. At Indy PopCon, I think the first 6 or 7 people I asked just said no right away. It was bit of a rough start.

Things got much better later that day, as well as throughout the weekend, but I think it’s indicative of the attendee demographic.

Analytics

Generally, I don’t pay too much attention to analytics, as I don’t think they’re an accurate way to assess the design of a game.  I won’t go into the specifics here, but will just link to this GDC talk from Alex Bruce, in which he talks about some of the problems of letting analytics guide your design.

However, one number I’ve found to be very helpful, especially in convention settings, is seeing how long people play the game for before they stop. The reason why this was important to me, was I wanted to gauge how long the game can keep people engaged in an environment that is quite distracting, with lots of things competing for their attention.

Generally, my line of thinking is, people will stop playing the game once they get bored or frustrated, so if they keep going, it’s a good indication that they are in “flow”. Now, this isn’t perfect by any means, and there are several reasons why someone would quit playing earlier:

1) They simply want to see other things at the convention

2) They get to a point in the game where they realize a much larger time commitment is required.

3) Their friends are waiting for them and want to move on.

In any case, I decided to keep track of everyone who played the game, and how long they played for. Here are the results:

Day 1 - Number of players: 22, Average Playtime: 9 minutes



You can see it was off to a slow start. Several people tried it for a few minutes, and then got up to leave. I think this was largely due to the fact that the convention had just started, so a lot of people are just trying to get an overview of what’s around. I also noticed that many of these people tended to be much older.

As the day went on, I started to have more people sit down and play the game for longer. They also tended more to be “gamer-types”, and were already interested in the premise of a first-person puzzle game.

Day 2 – Number of Players: 33, Average Playtime: 16.3 minutes



On Saturday, the crowd at the convention was significantly larger. There also seemed to be many more gamers on that day. You can see that both the number of players and their playtimes increased. One thing I noticed is that if people got past the first 2 puzzles, they would then keep playing, usually until they got to the exterior of the level, which is the first milestone.

There were a few people who only played for a minute or so. For me, this doesn’t really factor into my consideration for design – most of them were just interested in trying things out very briefly, or just deemed that this wasn’t their kind of game (in the sense that some people only like FPS and others only like RTS). For me, the takeaway here is that once player get past the first few introductory puzzles, then they’re engaged. This is great sign for me, and indicative of the improvements I’ve made with regards to pacing.

Day 3 – Number of players: 17, Average Playtime: 23.1 minutes



On Sunday, the crowd was smaller than the Saturday crowd, but still larger than the Friday crowd. The demographic was also very different, and people felt much more relaxed. My guess is that many of the attendees had already come on either Friday or Saturday as well, and so had already seen man of the exhibits and were therefore not in as much of a rush.

You can see that despite the smaller number of players, the play time was longer. There was a 13-year-old boy who sat down without knowing anything about the game, and played straight through for 85 minutes. He actually got to the very end of the build, in which there was a level that I had just implemented. Since I hadn’t have anyone play that level before, it was ridiculously difficult and tedious. I just told him that he had pretty much beaten the game as it was, and there was no need to continue.

To see that he got so far was really encouraging, and also allowed me to get some feedback on some of the later levels. There were also a few people that brought friends back to try out the game, which was awesome.

Here are the numbers, for all three days:

Total Number of Players: 72

Average Playtime: 14.4 minutes

I didn’t keep track of playtimes during PAX East, but I think the average playtime there was closer to 10 minutes.

Conclusion

All in all, Indy PopCon was a lot of fun and a very positive experience. I got to hang out with a bunch of cool developers, met lots of fans, and got plenty of feedback on the game. I did notice a few areas which could be tweaked, but the parts in which players were getting stuck and giving up were fewer than at PAX East.

I think it’s definitely a good sign that the average play time has increased. Again, I want to emphasize that one should not read too much into these numbers. It’s important to understand context, who the players are, what kind of games they play, etc. It’s also important to not rely too much on metrics in design.

In addition to recording the start and end times of the players, I also observed the players playing, and followed up with questions when they were done, asking for suggestions and feedback. This part was tremendously helpful as well.

Logistics

Just a quick note on logistics/prices of exhibiting at Indy PopCon, for those who are interested. The table was $150, and electricity was $80 ($10/amp, and I had two laptops estimated to draw 4 amps each).

Also, special thanks to David Laskey of The Amiable for lending me a laptop for the duration of the convention.

[William Chyr]

DevLog Update #61 - 06/05/2014

Alternative Control Configurations

After several requests from playtesters at conventions, I've finally gotten around to adding new control schemes.

Up until now, this was the only control configuration:

WASD - move
Mouse - look around
E - pick up / drop / interact
Space bar - rotate

I've added the ability to use mouse clicks, so now:

Left Mouse Button - pick up / drop / interact
Right Mouse Button - rotate

I tried it with LMB to rotate, but the problem there is that you're more likely to press LMB by accident. If you accidentally rotate when trying to pick up an object, it can be kind of annoying, as it can screw up the puzzle solving process a bit. However, if you accidentally try to pick up an object when you want to rotate, nothing happens, so it's not a big deal. I therefore decided to go with this as the default mouse click control scheme.

Since I had also witnessed some non-PC gamers struggle with using mouse and keyboard setup to play the game, I decided to go ahead and add controller support as well.

I'm using an XBox 360 controller. Here's the setup:

Left Analog Stick - Move
Right Analog Stick - Look around
RT/LT - rotate
A - pick up / drop / interact

I'll definitely need to test these configurations in the coming weeks, and of course, in the final release, there will be an option to map the keys however you please. In the meantime, I think this will make the game more accessible to playtesters during development.

[William Chyr]

Also, just as a test, I added a shader that replicates what it's like to be colorblind.

Here's a comparison:

[William Chyr]

DevLog Update #62 - 06/08/2014

Falling Through Floor Bug Fix

Back in April, I introduced recursive world space in the game, as explained here: http://forums.tigsource.com/index.php?topic=37314.msg1017598#msg1017598

One of the issues I encountered was that I needed to increase the fall speed. Up until then, I had very slow fall speed, so when you fell, it was very floaty, and you could air control very easily. My thinking was that the game was not about execution, and so I did not need to hinder the player's movement. Having a slow speed meant that it was easier for players to navigate the exterior scenes, and also since the player would respawn after they had fallen off the world, it wasn't really an annoyance.

However, once recursive world space came into play, there was a lot of falling. I could no longer have a slow, floaty fall, because then if the player fell off, it would take an excruciatingly long time for them to land again.

And so, I added acceleration when the player was falling and also set a terminal velocity, since you can theoretically fall forever, and I don't want the player to pick up so much speed that everything is just a blur. I felt that having velocity max out at around 70 units/second created a really nice feel to the fall. It felt like a rush so that you landed on the platform below in a reasonable time, but at the same time, it wasn't too fast that you couldn't appreciate the visuals.

For the most part, this worked fine. Except once in a while, something like this would happen:



As you can see, the player has fallen through the first wall, and landed inside the tunnel, instead of on top of it.

This was quite problematic, as it meant players either accidentally got into a new area they weren't supposed to be in, or landed in a hallway they've gone through, and therefore needed to walk over the same area again. Neither was desirable.

Even worse, sometimes this would happen:



For reference, this is what it should look like normally:



While the player didn't fall through the wall, he is now stuck in it. This is actually far worse than falling through a tunnel, because this way, the player can no longer rotate and is stuck inside, and I would need to restart the game.

After it happened during a playtest session yesterday, I decided it was time to finally fix this problem.

My first approach was to have a raycast originate from the player pointing downwards, and if it detects ground, then start to slow the player down by applying a force in the reverse direction.

The problem was that it didn't always work. The main reason was that the player could air control to being above a surface at the last minute, and therefore his speed doesn't get slowed down enough. When it didn't work, it also didn't feel very good, because you didn't get a very satisfying landing. You just sort of parachuted down to the landing, instead of nice, instant, "thud" effect.

After talking to a few other developers, I finally figured out a solution. BTW, a shout out to Ben Perez (@trinketben), Tom Eastman ((@trinkettom), David Laskey (@david_laskey), and Justin Pierce (@JTown_), for the help.

So here's the fix:

In LateUpdate(), after all the movement calculations are complete, I do a raycast downwards from the player, to see if ground is detected. This doesn't kick in until a player has reached a certain velocity, so that I'm not this raycast in every frame, when the player is just walking around normally. It basically only occurs during high speed falls.

What I then do, is that if ground is detected, I create a Linecast from the player's previous position to the player's current position. If the linecast returns true, this means that there's a collider in between, which means that the player has fall through a wall.

So what I do then, is I set the player's position to the previous position. If you're paying attention, there's a split second flash, which is when the player sees the other side of the wall before they're teleported back out. However, this is not very noticeable and is a much better situation than actually falling through.

Now, the reason why I have to do the raycast down before the linecast is because of the way the triggers for the recursive world space works. As the player falls through the trigger, they will actually get teleported to a position above their previous position (since the player is technically only in one world the whole time). This means that if I just do a linecast, then it will return true in this situation, because it will be going up and through the world. By doing a raycast down, I make sure the ground is actually below the player.

Also, the reason why this happens in LateUpdate() is to make sure that all the movement calculations have been completed. I used to have it in FixedUpdate() and it wasn't quite as accurate, because I think there was still some movement stuff being down after the raycast process.

To test the code, I increased gravity from 10 to 15, and also increased the terminal velocity from 70 to 200, so that the player is falling much much faster, and it's all working fine now!

[William Chyr]

DevLog Update #63 - 06/12/2014

I took some screenshots while redesigning one of the hub worlds this week. Thought I'd show you a bit of my level design process, and the evolution of the level through some images:

----------------

First, I start out by placing simple primitives to block out the level and get a sense of the space:




----------------

Once I'm happy with the overall layout, I start to replace some of the placeholders with actual assets. Here you can see the pipe getting replaced with actual glass pipe segments (I've also added the coloring filter on the player's camera):


----------------

During this time, I'm also replacing some of the large blocks with more interesting architecture:


----------------

You can see now that the entire pipe has been replaced:


----------------

However, after playing around in the space for a little while, I decide that I'm not too happy with the design of the pipe. It doesn't indicate direction. I try something new. The pattern on the pipe indicates direction. Looks a bit awkward though... :


----------------

Here's another design that looks a little better


----------------

How does it look indoors?


----------------

Now I start designing the interiors, so rooms don't all look like giant boxes:


----------------

Finally finished, here's a few shots of everything put together:










----------------

Of course, this isn't by any means the final form of the level. I'm going to need to playtest this quite a bit, and I imagine it will go through at least 10 - 15 iterations before I'm happy with it.

[William Chyr]

DevLog Update #64 - 06/13/2014

Experimenting with making some marketing material. Here's an idea for a poster. Any thoughts?

[sam_suite]

I love that! It gives a great sense of the tone and theme of the game without actually revealing any mechanics in much detail. Obviously, it's also an awesome representation of the art style (since it is the art style).

9/10 - would continue to look at poster

[William Chyr]

@sSuite:

Thanks so much! Really glad to hear that. Like the game itself, I'm planning to keep iterating on the poster idea. I'd love to do a series of them when the game is released, probably one for each gravity color.

[marvinhawkins]

Wily,

I like the poster because it kind of shows the minimalism, yet largeness of the world. It kind of reminds me of a Coldplay album cover. Pretty cool overall.

Thanks for sharing your experience on showing your game publicly. I took a slot at ACEN back in May and had a similar issue getting users. It was definitely a humbling experience,and I ended up taking feedback that maybe that particular idea wasn't ready for primetime yet.

Just curious as to how you asked for people to play? Did you have to approach them? or did you get a steady stream of curious booth passersby?

I really thought,'if you're in a booth they will come' but I couldn't have been more wrong about that. Some of that I think was my game's curb appeal, but yeah, you definitely have to be proactive.

[William Chyr]

@marvinhawkins:

First off, my name is Willy, not Wily. Noticed that you've misspelled it twice now

How you attract people to your booth really depends on what you want to get out of the experience. If you're in full-on marketing, then you'll probably want to have banners, etc to grab people's attention.

For me, I just wanted to playtest, and see people's reactions, when they don't know anything about the game, so I kept my booth pretty minimal, knowing that it wouldn't attract people right off the bat. Usually I would just ask people if they wanted to try out the game, and explain a bit about the premise.

Most people were pretty receptive.

[marvinhawkins]

Apologies didn't mean to offend

[William Chyr]

@marvinhawkins:

No worries. Non taken.

[William Chyr]

DevLog Update #65 - 06/20/2014

Working on a level. It's just rows upon rows upon rows of blocks:

[sam_suite]

That works really well as a

[jctwood]

Having played this game at the Radius Festival in London I cannot wait for more. It is absolutely beautiful both logically and artistically.

[Connor]

"For me, I just wanted to playtest, and see people's reactions, when they don't know anything about the game, so I kept my booth pretty minimal, "

Woah. comma heaven. lol

i always seem to ask this, but any news on a demo? just wondering :L