Today, I want to talk about the importance of testing code while you are writing a program because I recently burnt myself by not doing this. I was writing a wave table synthesizer for my CS245 class about sound synthesis. The assignment was really just a conglomeration of previous assignments with a little extra work involved. I started off by figuring out how I wanted to be able to represent the 16 channels a wave table synthesizer can have. A simple vector of vectors is what I chose. Then I just dove in and began writing how all the sounds would output with their respective DLS-style ADSR envelopes, velocity, and channel volume. I also wrote this cool piece of code that would remove sounds that had finished playing by swapping them with the end of their vector and popping the back off. Keep in mind I had not tested actually playing a sound yet. So when I finally got around to using a circular buffer to play my sounds the result was a very choppy and incorrect result. I took a step back from the code after a while of attempting to debug the problem and realized I could not find the problem and decided to start over.

I was talking to a classmate about how he did the assignment, and he said he just made stuff work in small increments. Of course I realized I had not done that and I really should have. So I restarted the project, but this time I made sure to start off by actually playing a simple sinusoidal sound through the circular buffer first. Then, I moved to playing an actual sound. From there, I just kept adding small portions of the assignment-testing the results each time I added a new piece. I very quickly found what was causing problems in my previous version of the assignment: I was removing finished notes in the code that was supposed to return the sound value for writing to the circular buffer. This caused a very large slow down.

The second version of the code took much less time to develop than the first, partly due to reusing code from the first version, but mainly due to test driven development.

I used this test driven development more recently in a MAT351 assignment that required me to write a quaternion library. First, I wrote what methods I thought the class might need. Then, I stubbed out the methods so they would be incorrect to what they should do. Next, I wrote the unit tests for each method. Test by test, I made sure each one failed and then worked properly by calculating the expected result and seeing if the proper result was returned.

Moral of the stories: Test driven development is a powerful method for writing and testing code to see if it behaves properly.

And here is some food for thought: What do you think will happen if computers become smarter than humans? I think before this happens we will take the route of merging with computers ourselves, similar to cyberbrains found in Ghost in the Shell. This provides new worlds of possibilities for programming, especially for security firms.

Unity Tips and Other Tidbits

Hey, everyone!

I want to talk about a few very simple tips for debugging problems in Unity (be it scripts or other things) and some other cool stuff I’ve been doing besides homework.

Simple Debugging Tips:

1.  Is your script not working/running?  Check to see that the script is on the object you are expecting it to be on or see if the script is enabled (the check-box is checked) on that object.  This is probably the most basic problem a Unity developer can have and not realize until a good amount of time has been wasted (trust me, I’ve done this as well as other teammates).

2.  Try not to move files around in the folders outside of the Unity project.  Instead, move them around inside the Unity project and it will help prevent problems.

3.  You changed the name of a script and now you are getting an error.  This fix is simple: Rename the class inside the file to the new name of the script.  Unity is looking for a class inside that file with the file name.  I’ve done this a few times and it’s a very easy fix.

4.  Do not have scripts with the same names!  This is primarily due to duplicate scripts entering your Unity project.  Unity is helpful and won’t let you create a script with the same name.  My previous game team had this problem and spent a very large amount of time trying to figure out this dastardly error.  I also solved this problem for an instructor at school.  This is caused by not following tip 2.

5.  This last tip is very easy: If you can’t figure out what your problem is by yourself and have already sought help from others around you, search Google.  Unity has been around for a fair amount of time now and the chances are that someone has already encountered your problem and learned how to fix it.  These solutions usually come from the Unity forums.  If your problem can’t be found, then go ahead and ask away on the forums, because there will be people there who want to help.

6.  Okay, one last tip:  You can live debug your scripts using MonoDevelop by running your game and then, inside MonoDevelop, click on the Run tab, click Attach to Process…, select the Unity Editor process, and click Attach.  Any breakpoints put in your scripts will then be hit and you can feel free to step through your code.  I have yet to figure out how to do this using Visual Studio 2010, but plan to do so.

Time for those tidbits I’ve been working on:

I’ve been reading up on hierarchical pathfinding lately because I have an idea I want to use it for.  I’ve been reading this in Artificial Intelligence for Games.  It’s a good book.  And after reading that I had all sorts of ideas on how to make an editor in Unity to edit a graph for nodes.  Since I haven’t done any work to make a custom editor, I started researching and made my very first editor window (even if it was the example window from the reference manual).

And some non-video game related stuff, I finished painting my gnome miniature for my new Pathfinder character:

Gnome Synthesist Summoner

He’s a gnome sorcerer miniature with the flames cut off.  The flames went from the tip of the dagger, over his head, and to his left hand.

Thanks for reading and I hope the tips help!

Hey, everyone!

I missed yesterday’s post because I was caught up finishing homework assignments due last night and was so tired that I forgot to make a post.  It’s been stressful lately due to homework assignments being due and not having time to work on Chained where there are other plenty of other reasons to feel stressed.

Anyways, I made a post for Those Guys on my team blog.  Go check it out!

Hello everyone!

This is my first post. And since it is, I think it would be good to post a little bit about myself. I am currently a senior at DigiPen Institute of Technology. I will be graduating at the end of April this year. I am currently working in Unity3D writing C# gameplay scripts for the team Those Guys. I have made a total of six games so far while at school and am currently working on the seventh. Some have seen the light of day, some have not. My Junior game was Exitus. I was the graphics programmer on that project. My current project, and favorite so far, is Chained. Chained is a 2.5D platformer which uses game mechanics to enforce addiction and eventually recovery by attaching a ball and chain to the character’s arm.

Enough about school, though. I will share a little extra about me. I enjoy playing games (that’s a no brainer) as well as hanging out with friends and making things. My current favorite thing to do is paint Pathfinder miniatures and play Fire Emblem: Sacred Stones.

Thanks for reading!