Our Games: 


All Blog Entries by Tag
Friday
Apr172015

Weekly Update: Bloom & Monkey King Story Panels

Issam is away visiting his family this week, but he's been working on our rendering!! He finished up the deferred rendering and added bloom which is stronger when things are in direct sunlight. He also did tests for fog and depth of field. 

Right now he's making it so that the chameleon can push objects while swimming underwater.   

I finished up the octopus model and rigging it using CAT (he's made out of tails!)

Skinning him was a big pain... 

Next I made a Tufted Gray Langur for a story I want to tell through the art:

And here are the first three panels of the story! Still working on it.

Here's Miles enjoying some time in the sun: 

Friday
Apr102015

Weekly Update: Character Models & Rendering

Hello! This week I've been modeling a bunch of characters! The idea is to use them in wall art (like this kind of stuff) We want to really start working on showing more of the narrative of the world through the environment, and the first step is making some characters to tell stories with. 

I finished up the White's Tree Frog from last week

And made my Golden Crab Spider:

Then I spent a couple of days trying to rig her...

First I looked at the premade spider rig in CAT (Another of Max's rigging systems), but it was missing some leg joints that I needed:

Then I did a weird experiment with Biped where I tried to make 2 bipeds work together, but Max ignored my skinning information:

Then I made a custom CAT rig that I thought was good, but the legs weren't really bending correctly:  

So I finally made one with the bends built in and it works!:

Here she is skinned:

And here's the current lineup:

Now I'm working on the octopus: 

She looks a little angry right now ;)

...which will finish off the main 5 characters/temple animals. After that I'm going to need to make a few non-color-changing animals. There will probably be a monkey. I'm not sure what else. :) Maybe a crocodile??

 

Issam has been making our game work with Unity 5's deferred renderer so we can easily handle multiple lights casting shadows. As part of this he's been spending time fixing our shader and trying to figure out better HDR/Tonemapping settings.

We can currently have spotlights and point lights that cast shadows, but he's still working on the HDR settings - right now he feels like the lighting looks too overblown (or dark at the other extreme). Also the HDR settings affect the colors a lot, so he's spending a lot of time on it.

Testing out multiple shadow sources:

 

 

Here's an image from earlier in the week when he was playing with the ambient lighting and tonemapping settings.

 

 

Here's a weird thing that happened where he accidentally inverted the shadows:
And now he's away visting family!

 

Airport working!

 

Miles has been diligently protecting the office/apartment from potential invaders:

 

 

Friday
Apr032015

Weekly Update: Moving to Unity 5

This week we decided to move our game to the new Unity 5, there were a few reasons for this:

- We still have a long development time, there was no point in staying on a version that will not be updated anymore.

- Unity 5 has better support for consoles. With Unity 4, each console build required its own version of Unity

- We wanted to try the new realtime global illumination as soon as possible, we felt like it would be really good for our game. (Spoiler: I am highly disappointed by it) 

 

This is how we handled the move to Unity 5:

- Updated the asset store plugins we use to their latest version while still in Unity 4 (NGUI, Sunshine, Master Audio)

- Deleted the library folder and any files generated by our custom importing. Opened the project in Unity 5

- Fixed our custom importer scripts to work in Unity 5. In cases where an FBX depends on another asset, we added a way for it to wait before importing itself and removed all calls to AssetDatabase.Refresh() during importing. We also submitted a bug to Unity about an error that happens when trying to re-import an asset when the inspector tab is open (it's a harmless error but still annoying to get).

- A few scripts got "auto-upgraded" to the Unity 5 API when opening the project - mainly all the scripts used by the "standard assets" that ship with Unity 4. There were still a few scripts that needed to be manually fixed but nothing that required more than 1 line change.

Running in Unity 5! (looks the same as Unity 4 :))Once we had the game running in Unity 5, we decided to try the new realtime global illumination (GI) system. Our game involves changing object colors, so it would be really good if we could get a nice bounce light effect that reflects that color change. The way the new GI was advertised I assumed it might work for us, but once we started trying it we found some limitations:

- It only works for static objects. For dynamic objects you still need to manually place a lot of light probes in your scene. 

- It requires a long offline baking time, which was one of the reasons lightmaps are out of the question for us. Cat is our only artist (and designer, and co-owner and social media manager ... so her time is important :)). Anything that has a really slow iteration time (in this case more than half an hour) does not work for us.

So while GI is advertised as realtime, in the end it requires someone to spend a lot of content time on it. It might be good if you have someone in your team that has time to spend on manually setting up lighting each time your scene changes, but in out case we don't.

Unity 5 does have a better deferred renderer support, we are going to spend some time trying to figure out if we can use it to have multiple lights casting shadows. Currently the forward renderer in Unity 4 (and 5) is slow when using multiple lights.

 

Cat has been working on our game narrative. We are trying to get something she can use as a base when creating environments.

She also as been working on new models for the other temples (for the temple artwork - not playable characters). Here are some work in progress screenshots:

 

Maybe having Miles' office at Cat's place was not a good idea...

 

Friday
Mar272015

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:

Friday
Mar202015

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:

Friday
Mar132015

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:

Friday
Mar062015

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

Friday
Feb272015

Weekly update: Playtesting and Jumping Height 

Hello!

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:

 

Friday
Feb202015

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 :)

Friday
Feb132015

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.