Background Music in Unity

In my wee hours I've been playing around with Unity 3D for making games. One of the things I couldn't find immediately with a quick search was how to make background music. Unity and Jemini actually share a lot in common in terms of general architecture. Everything is a game object. Everything. Game Objects that emit audio can loop and play at the start of the game with just a click of a checkbox. So that's close. However, game objects have a spatial location. This means as you walked away from my invisible jukebox the music would fade, or if you turned you'd hear it more strongly in one ear and less in the other...

Thinking in terms of spatial objects, background music is like headphones that are constantly on your ears. Unity's game objects hierarchal, so I can attach game objects to each other, and they become relative in orientation.

I took my audio game object and attached it to my camera, and set the vector to 0,0,0. Done!

Thoughts on Estimations

Members of my team have been blogging about estimations, and I can't allow them to show me up. At an Agile shop we throw estimations at our projects so we can have a reasonable baseline moving forward. Even for myself, we often get hung up over things that estimates aren't even supposed to be doing.

Estimates are supposed to represent some value of complexity for the simplest possible solution for what gives value to the client. It's not a representation of hours, but just an idea that task X is about twice as hard as task Y. Developers are typically very bad about estimating hours, and need to pad those estimates by factors of 3-5 if they don't want to eat the cost of estimates. Since we bill hourly, and not per point, there's a disconnect. You can start getting a rough idea of a points per hour ratio once you've completed some work.

Unfortunately, we get hung up on some things with estimation:

1) Simplest Possible Solution - All login stories are a 1. This is because I can implement login by dropping a .htaccess file in the proper location and now my site has login. I didn't have to create a user table with a user model, and a controller to allow login, or any of that fancy stuff. Why are you overcomplicating such a simple implementation? Because that's not what clients need in most applications. Remember that the simplest possible solution is the in context of what delivers actual value for that app. Facebook can't use a .htaccess file for login, but some apps might (as we have implemented before).

2) Re-estimation - Estimates are a hunch of the complexity required to complete a task. Estimations reflect how complex a story should be, not how complex a story was. They are not historical indicators. If a client loads up a story with acceptance criteria that makes it worthy of a new story, you must commit to less work, and inform your client that this will have an impact on delivering good software. This means you talk money. You let him know this is going to cost him. Go ahead. Rub your fingers together. Smile big like you're about to cash in. When you start throwing around how many Earth Dollars that Ajaxy spinner stuff is going to cost him, you've forced a decision on them. They must choose to pay more, remove the silly things they are adding, or remove some other feature. This decision is far above the pay grade of mere mortals such as you and I, and it means that we can't be wrong. If they torpedo a project despite our advice, it was done with their hands, not ours. My experience is that this doesn't happen in the real world. The system is far too organic to fail if both the developer and the client are having active discussion on a daily basis on how to cultivate an application into a valuable product.

3) Estimated velocity - Velocity is the rate of stories being completed. This is a target, not a requirement. Our commitment we make (which we try to push to be at or above the target), is the requirement. Don't kill yourself to make this velocity. Developers don't go into an application. Applications come out of them. Instead, commit to less. Project to the client what that means and how that effects the project. You might be able to pick it up next week if you feel you have some hard stories ahead of you, and it's unavoidable. You can also use it as a mechanism to show how their constant stacking of extra little things is adding up, and sinking their project.

4) Including Design/Testing - Shame on you. All stories include design and testing. If you think a story is going to be more difficult to test than a normal story, bump it up. If it's going to be harder to design than a normal story, bump it up. When a story is done, that means you can walk away from it and pretend it never existed. You don't deliver stories without any design. That's unprofessional. That's what the high school student working for sweat equity does. Not you and me. And testing? It doesn't make writing a method faster, or assigning a variable faster. Increases the speed of developing features. So when you cry to me and say that we didn't include testing in the estimation, you are telling me that you are a bad developer asking for regressions. There, I said it. If you aren't testing because it slows you down, then you have something very fundamental to learn as a software developer. This is like you telling me that you don't understand inheritance, or the difference between an object and a class. There's loads of materials on testing, and even folks like me that are eager to help you. You get free executable documentation for yourself when you get code rot, and others when they jump into your project blind to help you out. You have a safe place for refactoring when you need to make changes, and mitigates regressions. If testing seems hard or time consuming, you might look replacing your testing tools with better versions that get the job done for you.

Despite all of my rant, and the rants others have made on estimates, they are just a guess that's turned into a metric. They aren't a big deal, and being a little off isn't a problem. If your estimation sessions are taking more than 15 minutes, you're taking it too seriously.

Auditorium

A week or so ago I picked up Auditorium for the iPhone. I played the free Flash version some time ago. The game hasn't changed much if at all since then. Although having it on the iPhone allows me to easily present it to others in person.

The game is interesting in that it's a music based game, but not like so much of the rhythm games that we see today like Dance Dance Revolution, Guitar Hero, Garage Band, and even DJ Hero if you dare call that a game. Those games are more about hitting the right beats with the right notes.

Auditorium involves steering streams of colored light into instrument nodes. The instruments play a small loop as they are struck by the light. Many of the puzzles involve multiple instruments. The goal is to 'fill' all of these instruments. As you get closer to your goal you'll have a lot of instruments playing loudly, which makes an excellent feedback system. The music that comes from the game as you play it isn't going to win awards, but it still sounds good and natural. Overall I think this part was well done.

The only part that's a little annoying about the game is the physics-ness about it. A lot of the levels feel like you have to move all of the pieces into that "just right" spot. Maybe that's the intent of the game's high concept. It's definitely not a deal breaker, but something to keep in mind with a game that uses physics for its main game mechanisms (or is physics like in the case of light particles that can be pushed, accelerated, and gravitated) - it's a good idea to think in terms of areas and values with a lot of imprecision.

Overall it's a fun little game. Play it when you can have sound so you can get the full light/sound effects from it.

RubyConf 2009 + JRubyConf

I've had the luck of not only attending RubyConf and JRubyConf at San Francisco this year, but also being one of the speakers. Unfortunately, my speaking was pretty much the only reason I was able to attend - the cost for attendance is pretty high, and the seats filled on day 1. I believe RubyConf boasted 250 attendees, a list that is artificially constricted. Thankfully, Integrum paid my way there. After a recent wedding and honeymoon, I may not have been able to go without that help. Integrum also helped sponsor JRubyConf.

Jay and myself co-presented Jemini. We didn't exactly fill the room, but we got a pretty positive reception. We even got some challenging questions from the audience - people are interested in using Ruby to make games and compete with the current trendy stuff (such as using XNA to deploy on the XBox 360). Jay and I played our strengths for the talk, and I think it'll make for good material once the Confreaks videos are released. Jay even talks about releasing a standalone screencast with voiceovers on his recording. If you're thinking about live-coding for a presentation - don't. At the very least record a video of it.

I submitted the Jemini talk mostly expecting it would be rejected. My thought was to grab a projector and demonstrate in the hall anyways. I wound up doing both. Jay and I positioned our laptops with games running. We then stood about 12 feet away with XBox wireless controllers in hand. People had to cut in front of us to get by, which meant they'd notice the controllers, games, or both. We got a lot of good reception and interest from that.

I also presented Monkeybars at the request of the JRuby team for JRubyConf. This talk I felt could have used a little more preparation. I was able to demo a variety of apps and show off things that weren't covered in the RubyConf 2008 talk. One nice thing is that someone presented Rawr first - and used it to deploy a web app! As a moonlighting tool developer, it's interesting and flattering to see what people do with your creations.

For the conference itself, I sometimes thought that JRubyConf had started early. If you've been on the fence of the legitimacy of JRuby, you're running out of excuses to drink the kool-aid with the rest of us. Many of the talks mentioned JRuby in some form (if even to point out that their stuff didn't work with JRuby). By the way, 'g' works on JRuby (which I demonstrated [and Tom Enebo helped me get working]). JRuby now has some peripheral tools that are starting to mature such as Duby and Surinx. We still have some people that think that 100% Ruby is still too much Java (huh?), but there's still some folks that think the Earth is flat too (:

Other Ruby implementations such as MacRuby, and IronRuby are all doing well in their respective realms as well. If I saw correctly, some Ruby scripts were evaled against an existing C# app and the Ruby lib was able to override a lot of behavior. You can do this with JRuby too, but the app has to be designed for it. I'm under the impression this app wasn't. This aligns with what the DLR is up to. I didn't see Rubinius really appear on my radar, but I'm not really watching for it.

Overall I wouldn't go to RubyConf unless you were presenting. All of the material becomes available a few weeks afterwards online. You can establish relationships with library maintainers (who are universally eager to have more users) online as well. As far as the Ruby elites, the Ivory Tower goes, I submit the value there is less than nothing. This is why local/regional conferences sprout up everywhere. I see people doing cooler stuff at our local user groups than I see at these conferences. The local connections are far more valuable and productive than having Matz take your card. All of this said, it's still a pretty fun experience.

Bringing my wife Stacey along was a good move - not just for brownie points. She helped keep my sleep schedule anchored to something reasonable and helped snap my head out of the tech space so I could retain optimal sanity. Jay brought his wife Diana along too. While we were at the conference, they went out and had fun together. It seemed we weren't the only ones with this configuration too.

Gauntaga - Part 2

Jay and I sat down for another session a couple weeks back. We've recorded the progress, and gave some descriptions ourselves. The video was recorded in the new QuickTime packaged in Snow Leopard:

RI taking forever on Rubygems

I currently maintain Rawr, Monkeybars, and Jemini. All of these projects can be downloaded and installed as Ruby gems. However, there are some problems I've run into fairly often that's not critical, but annoying. This particular problem just makes the project look unprofessional, something we should fight tooth and nail as open source developers.

RI is a document indexing app that allows you to view RDocs at the command line. I don't ever use it myself, but by default it runs and builds an index over any gem I install. Unfortunately, when under the reins of Rubygems, it stalls when it hits binary files. When running RI by itself, everything works just dandy. You can cancel the gem installation with a swift kick to the control-C, but who wants to tell their users to do that?

In the end, I had to tell Rubygems, or Mr. Bones, to exclude certain file types that were virtal to my gem to be excluded from the RI index. Since Mr. Bones uses Rubygems, I'm not entirely sure who to blame, but Mr. Bones is just built on top of Rubygems, so I'm going straight to the source. Like a good little developer, I filed a bug a while back. Until then, you folks have the fix here, within my project config in Rakefile:

PROJ.rdoc.exclude << /jemini\.jar/
PROJ.rdoc.exclude << /package/
PROJ.rdoc.exclude << /\.java/

I just made sure all binary file types and locations were covered under this, and happiness was quick to follow!

As a side note, I've given up on my language formatting for my blog. I just have to fight it too much to get it to work, or change settings in my blog that make all my previous posts get auto-formatted to Ugly mode.

Gauntaga - A Jemini game in 1 hour

This week Jay McGavren and myself sat down behind the my laptop and started on a game - Gauntaga - which is a fantasy themed version of Galaga. In the previous two weeks I worked on getting our animation system revamped and stupid simple, and supplying the game with all of the art and sound it needed. Our purpose was to test the speed and ease of Jemini development.

We did spend a good deal of time fixing a silly bug related to our project generator. We only clocked an hour of time against the actual game.

What we got done was pretty neat. We have a character that can move from the keyboard keys. You can start a game, stop a game, and quit. We plugged in background music and backgrounds for both the menu and the game itself. Considering that's just an hour's work, I'd say that's pretty fast. In another hour I believe will will have a fully playable game - which I define as having artwork, sound, a victory condition, a loss condition, and the ability to exit the game from within the game.

Another thing to mention is that even though we've made these tools, we haven't become familiar with them yet. As this happens, I'm sure we'll be able to churn out the same functionality even faster!

As some side notes: I've been using RubyMine as a Ruby IDE, and I love it so far. That's not to say it's without problems or quirks. It does have TextMate keybindings, which I've found to be mostly complete. Fortunately keybindings are something I can patch even on a proprietary app. Jay (A TextMate user [who won't switch <yet>]) was using some of the shortcuts with realizing it. Of course, the shortcuts that didn't match really stood out. This is a different story from say Netbeans, whose bindings are totally alien to the TextMate user.

Here's what we can do: