A quick update before a barrage of more

So I haven’t posted in a while. A lot of stuff has happened since then. I’ll split the progress into `smaller` dev-blog-type posts. Otherwise, though we demoed at the Indie game night this past weekend, which was great. You can read others’ write up of that night here and here. If you don’t know, Utah Indie Games is a community of local independent developers, and meet up about every other month or so.

Next up, we’re going to Salt Lake Comic Con! we’ll be there all 3 days. (September 4 – 6) Be sure to check us out there. We’ll be in the Utah Games Guild booth, along with a bunch of other local devs. We’ve got a bunch more stuff in the works to talk about in the future, but more on that later.

Friction, intros, rumble, and backgrounds, oh my

I’ve been working a lot, lately, trying to get everything ready to go for Game Wars. We’ve fixed many of the UI bugs. I added my own class to take handle the balls friction in the game, because Unity’s friction wasn’t satisfactory. Either the ball would slip and slide everywhere, or there would be no conservation of momentum around a turn at all. I tried a number of different solutions, some more accurate than others. What I settled on was completely separating friction from torque. Normally, you would apply friction at the point of contact, but here, I applied it on the center of the object, based on the “best” contact, then applied torque to make the ball roll based off the relative velocity. So now, regardless of how slippery it is, it actually can never slide.

I changed the level intro system quite a bit. It used to be, the camera just spun around the ball and zoomed in to it’s final position, which took about a second and a half. Some people at the Utah Indie Game Night last month suggested that I use the intro to somehow hint at where the player was supposed to go. What I tried first was setting up a series of markers, then interpolating between their positions and rotations. That didn’t work. It wasn’t at all smooth, and Quaternions are weird. Despite the fact that I was interpolating between two correct rotations, it would still sometimes do a weird flip to get there. Second thing I tried was setting up animation curves with those same values. That solved the smoothness issue, but not the flipping one, also it felt really arbitrary, slow, and really stupid. So what I ended up doing is placing the camera’s handle (I always have the camera parented to an empty object, essentially giving me a manipulable pivot I can rotate around and do stuff with) at the center of the level, placing the camera well outside the level, and just slowly spinning the camera around it, until the user presses a button. This allows the player to study the level for as long as he/she would like, it doesn’t feel slow or dumb, and the player can cancel it at any time, so it’s not annoying, and as an added bonus, it doesn’t take any per-level set up time.

I also tried adding rumble. A little while ago, I was showing one of the old builds to a friend, because it had the prototype levels in it, which were way too bloody hard, and that build had rumble in it, and I had forgotten how much I liked having it in the game. However, I had to update Unity a while back in order to get rid of some random crash, and apparently sometime between that update and the one I was running previously, plugins became a Unity pro-only feature. To get rumble into unity, you have to use a plugin, found at http://speps.fr/xinputdotnet. But apparently, you can’t do that with unity free now. Hopefully they totally re-vamp unity’s input class, then. I guess that gets put in the “maybe this is something we can do eventually” bucket.

Lastly, I’ve been working on a new background for the first world. It’s a city. I’ve found a backdrop that I can use, It took me a good while to actually make it a 360 degree panorama, but it should work. I’ve been having some trouble, however, doing the foreground… of the background. Cities are hard to make. It doesn’t look like I’ll be able to finish it before the 25th though. But, I do have an idea for something I can replace it with in the meantime that shouldn’t look too bad, and should address the disorientation issue.

The competition

So Grow Utah Ventures announced all but 2 of the finalists for the Game Wars competition here.
I went ahead and tried to tracked them down. Here’s what I found:

SportStocks.com by Adam Snow
SportStocks.com
facebook.com/SportStocks

Vitality Wins by Maria Richards
VitalityWins.com
facebook.com/VitalityWins

Halfling Wars by Chondrostrike LLC
HalflingWars.com
Halfling Wars Kickstarter

Magnetic By Nature by Tripleslash Studios
tripleslashstudios.com
facebook.com/TripleslashStudios
kickstarter.com/projects/tripleslash/magnetic-by-nature

Momentum by Kelly Harper
ProjectileEntertainment.com
https://www.facebook.com/MomentumGame

Zombie Hunter by Ender Labs
EnderLabs.com
facebook.com/EnderLabs

phew, that was alot of links.

The retroactive post

So at the end of last month, we took our game to the Utah Indie game night, which, this time was hosted at UVU. We got a lot of good feedback. The most common critique was the camera. (The second most common was the difficulty ramp) People were getting unnecessarily disoriented and obstructed and such.

Since then, I’ve been doing quite a bit of work on those issues. First of all, I’ve put restrictions on the camera so the horizon is always in view, which is the biggest visual cue as to where exactly “down” is. I think that, combined with re-doing the world 1 background should make that a whole lot clearer.

Regarding obstructions, I wasn’t quite sure what to do about it because, as I had explained to other attendees, the shaders I used didn’t support transparency. I can’t believe it didn’t occur to me sooner, but the obvious solution is to change the material… duh.  So the end algorithm is something like this: We have a camera, a ball, a list of track materials and a corresponding list of transparent track materials. first, do 3 raycasts from the camera to different parts of the ball (we want a certain amount of overlap before transparency occurs), then filter all the targets hit to only keep the common hits, then dump any hits that don’t use certain materials. (mostly to filter out the rails.. they caused flashing if the camera just went past them for a moment) change the material on any objects that were hit this frame, but not last frame, then add to a list of objects that haven’t been hit, but are still transparent. Then decrease the alpha on the appropriate objects, increase it on the others, swap fully faded in materials with the originals, then update the lists, and rinse and repeat.

Of course it took a while to get there and there were certainly some weird things along the way, such as the fact that querying Renderer.sharedMaterials[] returns a copy of the array, not the original. Needless to say, that caused some head-scratchin’ problems.