Our Games: 

All Blog Entries by Tag

Weekly update: Playtesting and Jumping Height 


Cat is still doing some contract work, so I am going to write the blog post again.

Cat hard at work, Miles giving support!Last weekend my older brother was in Houston, it's only 3 hours away so I decided to visit him and obviously have him playtest our game. He does not play consoles or PC games so I wanted to see how he would handle the first section of the game. He was able to complete the tutorial so that was good! I think that was because of all the feedback we got and changes we made from previous playtesting, but there was still some things I noticed:

- I had to tell him about using the right stick to manually control the camera. I noticed that for people that don't play games with a controller they seem to intuitively use the left stick to move the character but don't ever touch the right stick. Maybe we could pop up some text if the player never uses the right stick? 

- The camera still needs more work, it's getting better but it does end up at bad angles/clips objects a lot of the time. I feel like I am noticing how bad it is a lot more when people that don't play games often play our game. I wonder if it's because more experienced gamers intuitively avoid bad camera situations (like trying to move the camera around the chameleon when he is facing a wall)?

- He is the second person that ask for the chameleon to be faster or to have a run button. This is a hard one, because it might be more of a problem with people not enjoying the world and trying to rush it versus the chameleon really being slow. I am not a big fan of having a run button because I noticed from past experiences that people just end up always pressing it; we might as well just make the default speed faster in that case but then it might change the feel of the game.

- He was another person that had trouble with doors that already have color on them. Those doors are not there to be puzzle (you can just open them because they already have the correct color) but I noticed that quite a few people get stuck trying to figure out what to do with those doors. They don't even try to press the open button, they just directly go to a "puzzle-solving" mode. A good piece of feedback was that perhaps we need a lock animation like we have for the sentinel when they don't have the correct color, so you know that a door is locked or not. This might also be solved if we ever implement the hint system we wrote about last week. Initially I would have thought that it would be fine for people to be blocked until they figure it out, because then they would learn it - but I did notice that even after they open the door they get stuck on the next one, meaning they don't really know why the door opened. 


The rest of the week I was working on jumping height. One of the things we noticed was that it was hard to stop people from jumping to high places that are supposed to be impossible to reach. I spent time this week making sure our jump is limited but still feels good.

Jumping test level: Should be able to jump on the orange box but not on the blue oneCat gave me 2 cubes that she sized to represent the height of the jump. The shorter cube represents the highest the chameleon should be allowed to jump and the taller cube represents the height that the chameleon should never reach. It sounds like it should be the same thing, but because of the way collision works in physics engine it's always better to have a buffer between what's possible and what should never be allowed for gameplay reasons.

Initially I thought this would be easy to do, but after a while I noticed a few problems with the way we do our chameleon movement. We use the Character Controller system from Unity to handle collision with the world. One of the problems was that during a jump if this system detects collision at certain angle it could end up pushing the chameleon up to keep from penetrating the collision. That's fine when walking but when jumping this means that the player can reach higher than we wanted to allow them to. We handle this now by looking at where the chameleon is going to move in the next frame when jumping, and not allowing the forward movement if it will end up hitting collision. It ends up looking the same as colliding with a wall 1 frame before the character is supposed to, but it seems to work well.

The other problem we had was that our movement was calculated based on how long a frame took. Most of the time when running at a constant 30 fps this was fine, but when running at low frame rate the time between each frame was higher. It's always a problem with any discrete realtime physics system, most of the time you want your calculation to be at the same timestep. What we do now is run our movement code at intervals of 33ms ( = 30 fps). At slower framerates we run the movement code multiple times but still at 33ms each time, which guarantees that whatever the framerate is our jumping curve will end up being the same.   


Miles showing me how jumping works:



Weekly update: Playtesting, Physics and Accounting!

Cat is doing some contract work for the next 3 weeks, so I will be writing the blog posts! They might be a little less well written, sorry! :)

Cat worked on the art style for some new frog temple puzzles before starting her animation contract work this week. 

On Tuesday night we did a playtest with two Austin indie devs. One of them played the game before at Fantastic Arcade but was not able to finish the first section, the other one never played the game before. A few notes:

- In one puzzle we use ivy for the player to climb, but if you take the color from it you drop and can't reach it again to put the color back in order to climb. We saw that problem before and I think we forgot to just replace the ivy with a ladder. 

The ivy that we need to change for a ladder

- When a sentinel is closing we pop up an invisible wall to stop people from being able to force their way through. On some sentinels it seems that invisible wall is bigger than the walls so when you are walking on top of a sentinel you look like you are floating.

- We still have a few rooms with camera issues; it mainly happens when the player has to do something in a confined space. Cat is going to look at changing the layout of those rooms to add more space. If I have time I might see if it's possible to make the camera handle better in those case (Maybe the camera can detect that it's going toward a confined space and change the way its controlled in that case?)

- It seems we need to be better at teaching people about the water logic before the first big puzzle that requires the use of this logic. At the start of the game we require people to take color from water to open a door but it seems that's either too early or not obvious enough. They are other optional water ponds that people can play with before reaching the puzzle but few people seem to interact with them. Cat suggested that we might need to reintroduce a simpler water puzzle we removed before.

The first use of taking color from water, we assumed it would be enough to learn the concept.

- Most of the time when people are blocked on a puzzle, just giving them an hint ("look at the ivy", "you can take color from everything") seems to be enough to help them figure it out. We started talking about maybe creating a hint system where we write a few lines for each puzzles and offer the player the choice to see a hint if they have been trying to solve a puzzle. Or maybe we can also have an "easy mode" where when entering a puzzle room the camera showcases key location/element of the puzzle. (I generally think of the Zelda puzzle as something that do it a lot) It might make our game more fun for people that are less familiar with games.


This week I finally was able to get the fire system working the way we wanted. The main challenge was to write a custom physics system for carrying objects and making them interact with gravity. In the case of the fire, that's something that we use when the fire is solid (after we take color from it). The main reason we don't use the Unity physics engine is that I find that most physics engines gravitate toward a realistic physics system and are hard to move toward a design centric physics system.

Fire system finally fully working! (for now :))

The rest of the week I have been doing accounting! Woohoo! ... Yes, I do like it :) We don't use an accountant so we do all our accounting/tax preparation ourself. I feel like as a small studio it's a nice learning experience and if we ever need an accountant we will have the knowledge to better choose one. The two main programs we use are:

- Kashoo (http://kashoo.com/) 

- Turbo Tax Business (for the LLC) and Turbo Tax Home & Business (for each of us)

Kashoo is a really simple online accounting tool that connects to your bank account to get all your transactions and allow you to easily create income/expense accounts. At the end of the year it's really great to be able to see your profit/loss or balance sheet for different periods of time. If people are interested I could go in more details, just tweet to let me know. ;) 

We still are a small 2 person studio, so most of our tax situation is pretty simple and Turbo Tax handles most of them easily (except for the R&D tax credit (form 6765), but the IRS has a simplified credit step that allows us to take advantage of it without needing an accountant).

In our case doing our own accounting allows us to have a better handling of our money and it makes us more confident when negotiating for contracts or talking about money. Trouble Impact has been running for nearly 3 years and I believe one of the reasons we are still going is that we learned a lot from doing our own accounting.

Miles helped me do this blog post :)


Weekly Update: Water, Fire & New Puzzles!

This week Issam worked on some bugs related to fire and carrying uncolored fire. Because you can carry fire, right now you can stack it, which can create some... issues... so we need to figure out a better solution for it. 

We also had a bug with the fire spawners where their triggers would overlap with other triggers - so for example the fire wouldn't start because there was a sound trigger nearby. That's now resolved.

He also added some functionality I needed for one of my new fountain puzzles to work - so that puzzle is now ready to be tested.

I spent some time this week working on the Frog Temple puzzle I had posted pictures of last week - it's playable now!

Jump height is pretty important in this puzzle, so we're going to refine the jump height. Right now you can jump a little higher if you get a running start, but for the sake of simplicity I want the jump heights to be the same whether or not you're in motion before jumping.

I made a new puzzle!

And I started working on this other new puzzle.

There's currently a bug where you can swim in the water even though it doesn't have any color. It's spooky looking!

Also I started laying out another new puzzle. I think it's going to look a bit different, so I'm excited!

Here's Miles and Issam taking a nap break.


Weekly Update: Fire & New Puzzles

Issam has pretty much finished adding the fire functionality this week! He created a system for carrying that will work with other small objects - which includes a simple gravity system that doesn't use Unity physics. The fire is now combinable again. He also worked on the fire spawner importer, and made it so that unless a fire is on a 'burnable surface' it will burn out:  

He also solved the issue we were having with running out of layers by using a plugin that lets you use more than one tag at a time called All the Tags! The source code is available, so he was able to change it to fit our needs better. 

We have a lot of layers!

(Here is Issam struggling to read them...)

I worked a bit more on the art style for the first frog temple room, and now the fire works! 


I also designed some more puzzles on paper: 

And I have 2 new puzzles in progress:

(This second one worked much better on paper..... -__-)

Here's Miles trying to get us to open the balcony door: 


Weekly Update: Frog Temple Progress & Fire Functionality

This week I've been working on the art for one of the frog temple rooms! Right now the water is opaque for some reason... need to figure that out. ;)

I originally went with more of a wood pattern for the raised areas, which I think looks really cool - but I don't really think it fits the style that I'm going for... Maybe I can find somewhere else to use it later since it looks nice with our rendering: 

Issam has been working on replacing the fire that I made awhile ago. He added a system to spawn/despawn particles effects from a preallocated memory pool (meaning we create them at the start and activate/deactivate them when needed). We are also running out of layers in Unity (it has a limit of 32 and we're really close), so he's looking into reducing the amount that we use. He's currently re-writing the carry system to merge my placeholder logic with the way our chameleon's animation state system works. 

Here's Miles being awesome: 


Weekly Update: Fire & Frog Temple

I'm doing any early blog post this week since we're going to PAX South tomorrow through Sunday! 

Issam started the week by finishing off some of the lighting work he's been doing. Currently the whole game has ambient lighting, so he made a system where I can add vertex color information to models to change the intensity of the ambient light. (We want the fire casting light to become a puzzle element, which only works if we can have areas that are totally dark). 

We also played around a little with the new point lights and realized they could work pretty effectively as bounce lighting:

The rest of the week he's been working on re-making fire based on my prototypes. I think by next week we'll be able to start testing it in some puzzles! One thing we're adding is that fire will burn out in a second or two if it's not on a 'fuel source' like the initial fire spawner, or maybe wood or leaves (only with color!)

I started to work a little bit on some possible directions for effects. When I was working on the tiered fountain, I modeled some water ripples - which made me realize that I needed to start thinking about how some of that stuff might actually work. :)

I did this test, which I think looks a little too much like jello... but it's a start. (This is just in Max)

Also I worked a bit on the fire model. I want to try adding some bones and seeing what I can do with skinned animation - we'll see what happens!

I spent the last couple of days starting to think about the art direction of the levels set in the frog temple. There's a color-changing frog called the White's Tree Frog which hails from Australia, so I want the temple to be shaped after aboriginal art and architecture. This is what I have so far.

Here's Miles um... inside the blinds.


Weekly Update: Lighting

I didn't do very much this week... -_- so here is Issam's update:

We use Visual Studio to edit our code and shaders, but it does not have any syntax highlighting for the Unity shader files (.shader, .cg, .cginc, .compute). This week I modified a product called NShader to add support for that. From the product description: "NShader is an extension to Visual Studio 2008/2010/2012 that provides syntax highlighting for various shader languages including HLSL - GLSL - CG". I made it support visual studio 2013 only (less code), added Unity shader files support and allowed to change the color options in the Visual Studio "Fonts and Color" menu.

Our version of NShader can be downloaded here: 


To reduce draw calls during our shadow rendering (for better performance) we use something that we call "Shadow Meshes" ... well at least I call them that :) The main concept is for every FBX that Cat exports, we find all objects inside it that are going to be static in the game and we create one big mesh that's the merging of all those meshes. The following picture illustrates that: on the left is the imported FBX of one of the game sections, it includes around 300+ static game object. On the right is the generated mesh that we can use as 1 draw call to create the shadow that are due to all those objects. This week I fixed a problem with the way we generate this mesh, it was not correct if the root of the imported FBX had a rotation.




For lighting, we created a system of "light colliders". The idea is that we use the physics system to figure out what objects are affected by our point lights, and only turn on the "Point Lights" option of our shaders for those objects, to do this we create automatically at import a box collider for every object that can be lit (right now this is everything). This means that now we have a lot of colliders in our game :) The image below illustrates that, the green lines are the contours of colliders:



We had to work around a bug in the Unity editor related to having that many collides. We need to disable those colliders when in the editor or doing any undo is really slow, so at import when I create all our colliders I disable them and I also create a component that re-enable all those colliders when we start the game.


The following three images show how our game looks like with different options:


1) No HDR - No shadow - No Post FX



2) No HDR - Shadow - No Post FX 



3) HDR, Shadow, Post FX



Here's Miles helping Cat unpack from vacation




Weekly Update: New Fountains, Puzzle Designs & Lighting

I'm still at my parents this week, so I didn't get as much work done as I would have liked... but this week I worked on a couple of small things.

I redesigned the fountains so that you can actually get into them and take the color from the water. It's really hard to get the blue from the original small ones:

So I had made this really weird looking placeholder fountain ;)

And here's the new one. :)


I also spent some time working on new puzzle designs, so here are some scribbles:

And here's a new one I'm building (it's pretty featureless so far):


Issam is working on our project again! Since I was messing with fire stuff, we realized that we hadn't added point light support to the new shaders Issam made (we can't use normal Unity lighting because of the way our material/shaders support color changing). Issam added point light support this week, and also made the code handle multiple lighting sources better.


Miles has been exploring the inside of Issam's lamp. ;)


Weekly Update: Playtest Feedback

Happy New Year!! 

I'm still on vacation at my parents' house, so I didn't get a lot done this week - but I did have a friend playtest all of the puzzles I've made so far and I thought I should type up the notes I got from watching her play. Some of them are things that we already knew about and still haven't figured out, but I got some new ideas. :)


Blue door. The first two doors that you open require green - but the third one you encounter is blue. I had initially placed the door to teach the idea that different color spirals means different color requirements, and I had a small "puzzle" where you opened another door to go find some blue. It felt a bit boring and weird, so we took it out and just assumed that people would figure out the color thing.

I think that people do figure it out - but when my friend was playing I realized it would be pretty simple to put a fountain in there (already on) and show that you can take the color from the water in the fountain. That way you're seeing the fountains earlier in the level (right now you don't see them until you need to turn one on - it seems to make more sense to show you what they do first).

Ivy puzzle. When the player walks out into the garden for the first time, they need to find 2 spots of orange color. The first one is at the top of a patch of ivy, and the other one is at the top of a patch of ivy that doesn't have color (so you need to add color in order to climb it.) The main issue here is that ivy without color looks very different from ivy with color - and we're not really giving you an opportunity to make the connection between the two before it's a requirement to interact with it.

Now I'm thinking I can place some extra ivy near the colored ivy - it still looks different, but I think it's more likely that players will make the connection if they can see both of them next to each other. That ivy won't help you do anything, but then when you see the third patch, you'll have some idea of what it is.

Sentinel. We've been working on issues of clarity for the sentinel for a long time, and we've gotten it to a point where most players do figure it out, but after seeing one more person spend a significant chunk of time staring at it, I've decided to just go all the way and make some 'wall art' that spells out how the sentinels work. I don't have a problem with players taking a long time to solve puzzles, but this really isn't a puzzle - it's a rule that they need to learn to solve puzzles later, so I think it's ok to spell it out.


Add water puzzle before big water puzzle. We used to have a water puzzle where you specifically learned about turning the water solid, but it was awkward so I took it out. When my friend was playing I realized that it had been really important to specifically point out that feature of water before the final 'big puzzle' in the tutorial section (which requires that you solidify the water). 

Still need to fix layout of big rooms. I've written about it before, but there are some overall layout issues with the big room in the tutorial section - your two main goals are the big yellow and purple doors, but the players don't usually noticed them before entering into the smaller rooms. I need to figure something out...


She also played through all of my new puzzles, and I'm pretty happy with how that went. We still need to figure out how we can keep players from getting stuck in some rooms though (it's possible to move the color around enough that you can no longer complete the puzzle).


Issam is still working on a contract, but it's over soon! Maybe I will have some updates from him next week!

Miles is practicing being a goalie.


Weekly Update: Happy Holidays!

Happy Holidays!

This was a short week since I left to visit my parents, but I was able to make some changes at the beginning of the week! I started off by going back to the fire and making the fire pots work - they create fire when you give them color. and make new fire if you 'take it away' (by taking the color and moving it):

Because of this you can actually make unlimited fire (which we will probably change ;) ): 

I also spent some time making a new puzzle, which is mostly functional right now: 

I'm spending a couple of weeks with my family, so Issam & Miles are hanging out together back in Texas. :D