Our Games: 

All Blog Entries by Tag

Weekly Update: Swimming Controls & Starting Fox

This week Issam has been working on the swimming controls! He tried a couple of different variations throughout the week, and we've landed on one we'd like to playtest. He also added the ability to take/give color while underwater, and worked on the collision detection while swimming (for awhile, the chameleon was getting stuck in the walls...)

Moving forward, he's going to work on ice - we're also going to start thinking a bit about how we can build a hint system.

I've been working a little bit on the narrative (so I don't really have a lot of pictures to post!) and starting to brainstorm ways we can reveal information about the world through the environment. Starting off, I do think I'm going to want to feature some of the other animals in the wall art, so I've been trying to figure out what they'll look like. The other color changing animals are White's Treefrog, the Common Octopus, the Goldenrod Crab Spider and the Arctic Fox: 

I started modeling the fox. It looks pretty bizarre at this stage, but I think I can save it. ;)

I had a friend visiting from out of town on Monday - so Miles spent most of the week recovering from this traumatic event:


Weekly Update: SXSW Feedback

It's me!! I'm done with my contract!!

Last weekend we showed at the SXSW Gaming Expo at the Austin IGDA booth. We were lucky enough to get to show the game for a 3 hour chunk all 3 days, so we got a lot of feedback from watching people play the game. Here are some of the small changes we made: 

Make hints unreachable. There are a couple of places in the tutorial where we give the player hints through the artwork, which seems to be working well overall. In both places however, you could kind of stand on the wall collision and jump up and take color from the art. While there's not technically anything wrong with this, it looks pretty broken (in particular, check out the top image of the sentinel hint below). I moved some stuff around so that this shouldn't be an issue anymore - for the first hint, I moved the pots so that it doesn't look like you should be able to reach the hint, and for the second one, I raised it higher. 

Top: Before Fix, Bottom: After Fix

Top: Before Fix, Bottom: After Fix

Extend tutorial sections. After you first learn that you can take color and put it on things, we have a narrow hallway where you need to take the color from the green door (which you have just turned green). This hallway teaches you that you can still take color after using it. We noticed some player confusion here, so to make the concept a little easier, we extended the tutorial text which reminds you what buttons to push, which will hopefully prompt the player to try to take the color away again.

Top: Before Fix, Bottom Two: After Fix

Invisible wall. One of the pieces of geometry from a later room was poking out into this hallway. I hadn't noticed it since it's single-sided, so you can only see it from a certain angle. It has been removed!

Make "visible orange" easier to see. When you come out into the outdoor area, you need to find 2 separate pieces of orange. One of them has always been hard to see, but sort of visible from certain angles. We decided that it would be best if it was easier to find, since the real 'puzzle' here is to add color to the colorless ivy that's below it.

Top: Before Fix, Bottom: After Fix

Tiles under sentinel - color getting stuck. I had this weird long tile in this room, and players kept thinking that it was important for the puzzle and getting color stuck on it (it's a little hard to pick it back up again once you put it down - you sort of have to face to the side in order to avoid picking up the sentinel's color). I moved some stuff around and made it into regular tiles.

Top: Before Fix, Bottom: After Fix

Change shape of ceiling room branch! There's a puzzle where you need to put color on this branch, and because of the angle, it's really difficult to do. I tried turning it a little bit so that the wider side is easier to get to, and it seems better so far.

Top: Before Fix, Bottom: After Fix

Water room. This is a room where the immediate goal isn't visible (there's a pink pot behind the blue door), and since there's not a lot going on, sometimes players would walk in here and then leave, thinking they needed to bring something in from outside. I'm currently working on adding some latticework into the wall so you can see into the next room. Hopefully this will keep players in here... we'll see! 

Also I put a tree in the room on the other side (you can't get in there) because I think it looks cool. 


Here's some stuff I made note of, but haven't gotten to yet:  

Make first fountain bigger. Sometimes it's hard to get the color from the water.

Small Plants shouldn't have collision. It feels wrong to get stuck on them!

Tan looks too much like orange. Players keep seeing the large orange door and coming back inside and grabbing this tan color. They look too similar.  

Need invisible wall for top of section 1. Right now you can climb up this mound of dirt and get stuck on the other side of the level. 

Add hint for ivy climbing. At SXSW a bunch of players saw the ivy, but never actually tried to climb it. It ocurred to me that this is totally a game convention thing (assuming you can climb on ivy) so I'd like to add a hint to guide players here.


Finally, here are some ideas that we wrote down, but I'm not sure if we'll act on them yet: 

Locked/unlocked visual for all mechanical objects. Right now the big doors have an animation that plays when they become active, but nothing else in the game has this sort of visual cue. It might be helpful for things like the fountains, or smaller doors.

Put "fixed color" on sentinel towers. The sentinel doors have that spiral on them which shows that they need orange, but the towers to the sides don't - it might be worth adding that to make it more obvious.

Visual design of room 12 - hard to see everything. Because most of the room is below the character when you enter the room, it's a little hard to see all of the information you need. I might end up changing the design around a bit. 


Issam has been working on deep water swimming! He's currently adding a new trigger system so that I can add the deep water areas to the level through Max. After that he's going to work on swimming controls. He was also a bit busy with taxes this week!  

Miles had an exciting run-in with a pigeon and he has spent much of the week waiting for him to come back:


Weekly Update: SXSW 2015

This year we are again able to show our game at the South by Southwest Gaming Expo, thanks to the local IGDA chapter sharing their booth with local developers.  The schedule was for us to only show on Saturday afternoon, but another team cancelled on Thursday night and we were asked to fill in for Friday afternoon. So that's what we did today, after rushing on Thursday night and Friday morning to fix a few bugs :) 

Most of my week was spent preparing for SXSW, but I also spent some time making the blending between animations look better. Especially for the animations that have the chameleon carrying something. Now the switch between walking, jumping, swimming and underwater swimming is a lot smoother. 

Cat is finishing her contract work, so we don't have much else to show. Here are some pictures from today's SXSW showing:

Sometime Miles wants to be left alone to work:


Weekly Update: Underwater swimming and color rendering

Hi! Cat was still doing her contract so this will mostly be about what I worked on.

This week I started implementing some underwater swimming. We had the ability to swim on the surface of the water, but we think we can had a lot more puzzles if we allow the chameleon to swim underwater (and carry/take color from object while underwater).

The result started really well...

The chameleon discovered flying in the process:

But toward the end of the week we finally had something useable:

I still have to allow the chameleon to carry objects underwater and to take colors from objects, but it's looking good. Cat already has some designs she wants to try!

Currently the swimming uses 2 buttons, one to dive down and one to swim up. We want to change it to use 1 button, so we will experiment more with the controls. I also need to make the new water work with our art/design pipeline.

Finally one of the things we always have to take into account in our game is the way we render and how it affects color. Most of the time, a lot of rendering techniques end up changing the color of objects. While that looks good, in our case it's bad for gameplay. 

For example, currently our water rendering just consists of rendering a flat plane. In our game, because water has color it makes it harder to see the color of underwater objects:

 Blue water, red water, not rendering the waterThe previous picture shows how hard it is to distinguish the colors, and even how the difficulty depends on the water color. Right now that means we need to figure out a way to render water that does not create this problem. It's also the reason we don't have any underwater camera effects right now.

This problem of color rendering is something we had with shadows and lighting too, that's why our shadows are "colored" based on the surface they are on, so they never darken the objects so much that it becomes hard to see the color information.

Miles wanted to show that he could be as cute in a selfie as those Quokka selfies


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.