In my final quarter at Rose, I took a class entitled Game Design & Development. This was a 10 week course where we were taught about a variety of topics about game development. The core of the class was the game that we wrote. My team consisted of five people and we spent six weeks working on our game.

Wombat is a top down 2D shooter, similar to games like Alien Swarm and Smash TV. My team wrote the game from scratch. I was responsible for basic architecture, rendering engine, collision detection, particle effects, and numerous other small features.

Considering the scope of the project, a class project where none of us had any real game development experience, the time, six weeks, and team size, I consider our game to be a smashing success. By the end of the class we had a stable engine, working weapons and magic, an interface with a map editor, a working menu system, and AI. The game is nowhere close to being publishable, nor would it win any awards, but it is an excellent working prototype. Given a couple more months, I think our team could have turned the game into something really fun.

My teammate on the Wombat game, Nick Ohrn, has posted his first impressions of the project now that we are wrapping up. We actually gave our final presentation to the rest of the class today. Nick has this to say:

This game has been a treat to make, and I’ll post a video of the final product next Friday when we have to have it done. As far as implementation details go, we’ve been using XNA Game Studio, but that’s a whole other post (Preview: I like it a lot!). If you’re interested in playing the game when it’s done, drop me a line and I’ll see what I can do.

Now, my contribution to the project has mostly been in the realm of tool-set editing and map creation. In addition I’ve been somewhat of a lead artist (HA!), which has been somewhat interesting.

He also has a short video of the game in action. Unfortunately, it’s pretty poor quality. We’ll see if we can get something better for you guys soon.

I’m sure you were all holding your breath. I just heard back from my recruiter today and I didn’t get the job.

Considering my goals of wanting to work in the game industry and weighing working at Microsoft on something unrelated to games for two years versus going to grad school learning how to make games for two years, I’m not sure I would have accepted a job at Microsoft. But, I was a little excited about it and disappointed I didn’t get it.

Also, I would have very disappointed if I couldn’t be friends with Tim anymore

So now I’m waiting on RIT to see if I get a graduate assistantship position. I should hear within a week hopefully.

I’m in the SeaTac airport with nothng to do but wait for my 7:00am flight. Surprisingly, I only got sort of lost once on the way here from my airport. After taking an exit too early, it was clearly labelled as going to the airport, I wound up on the backside of the airport with all of the shipping facilities. Due to my planning, waking up at 4:30am, I was able to make it to the airport and get through security with an hour to spare!

This post means I survived the Microsoft interviews yesterday. They went well. I’m excited to hear back from my recruiter.

My day began with my rental car not starting. Turns out a Focus drains the battery if you leave the headlight switch on even the lights turn off. I ended up getting a ride from the rental company, but got dropped off at building 119 instead of 19. Not a problem, Microsoft has a cool shuttle service with little white Prius’ running around all over the place. Just ask the receptionist at any building for a ride to any other building and one comes to pick you up. Unfortunately, it turns out that I’m very bad at waiting for shuttles. The receptionist called two for me and they never showed up. But my first interview was with someone in building 119 so I ended up staying there though this meant that I only saw my recruiter for two minutes the whole day.

Throughout the day I talked to five people, two from the Live Experience team and three from the IE team. They all asked me one or two programming questions and most asked me specifically if I had ever had a experienced a team experience where there was a difference of opinions and how I dealt with that. Fortunately I think I had a pretty good answer to that question.

In case any of you are interested, here is a short summary of the programming questions.

• Image processing, dealing with RGB values
• Doubly linked list, very hard!

• Arithmetic with big numbers

• Comparing “lists” two ways at once, sort of game related
• More image processing dealing with RGB values, much harder than the first one

• Rectangular collision detection! I just implemented this in my game a few days ago, so pretty easy.
• Merging sorted lists

• “Safe” strcpy

All of these had some amount of discussion on how I was deciding to write it, follow up questions on stuff I had overlooked, or mistakenly assumed. I had a bit of trouble with the doubly linked list question, it was an odd scenario with an elegant solution. It felt a little puzzle like. And then the second image processing question was difficult as it required using bit values within an int for storage, something I’ve never had to deal with.

I didn’t have any “design a watch” type question that I was told interviewers love to ask. All the interviewers seemed to already know, or asked about my interest in game design. I’m not sure what that means though.

After all my interviews were done I waited a short while for my friend Eric Holk to get off work, Eric graduated from Rose last year and is now working at Microsoft. He got off and we went out for some pizza. You will all be glad to hear that we ordered a large, half variety of meat, half pesto, and finished it. We had to sit at the restaurant for a while longer before we could walk.

So that’s that. The weather was alright. A little colder than Indiana right now and a little rainy. It was a nice change. There is no internet at the SeaTac airport so this won’t get posted until I get back to Rose.

This blog may or may not turn into “fun and exciting experiences Matthew had while writing his game.”

My engine is coming along nicely. It loads and draws a map and can draw units. I was doing some refactoring because the TileEngine class was responsible for loading the Map and I thought the World class should be doing that. So changed some code so it was the World that created the map and then passed it to the TileEngine for rendering. Lo and behold once I got it compiled and ran it I was displayed a beautiful blue screen, which is the background color. No tiles! I was very distraught as there were no exceptions to trace and no null variables I could locate. I had no idea why it was no longer drawing my game.

And then I remembered two little lines of code that I had deleted and forgotten to replace.

These numbers specify the number of pixels in every tile of the map. These variables are used everywhere in my rendering engine. It uses it to specify the size of the tiles; it uses it to determine where to draw units. I had forgotten to set these values and thus they were the default C# value: 0.

Behold, my rendering engine was working properly! Only it was drawing all the tiles with 0 height and 0 width. It was drawing and infinitely small map. I added the lines back in and everything worked.

And now for the Programming Tip of the Day. The first piece of code is not equal to the second piece of code. Can you spot the difference? It took me about a half hour to realize that this was the reason my units were jumping around and not moving smoothly.

Good

Bad

This last quarter I was taking an AI (artificial intelligence) class. Our final project was to create an AI player for a simple capture the flag game. At the end of the quarter all the teams would compete in a tournament. Whoever won the tournament got an A on their AI and bragging rights!

My friend Jonathan, the same one who went to Florida with my roommate Eric and I, was my partner and we put in many hours on it. Unfortunately we were unable to polish it up completely. We had no idea how well we would do in this tournament as there are a lot of really smart people in the class who spent a lot of time on it.

We found out the standings today. We got 4th place! Check it out

To read a paper we wrote about our player, you can read the rest of this post.

I’m taking a class on artificial intelligence this quarter and one of the things we do in this class is we read papers on important AI topics. For example, we read Turing’s paper on the famous “Turing Test.” And we read a paper by Searle on whether digital computer can truly understand things the way we understand things. The current paper is on Stanley. I’m sure you’ve all heard of Deep Blue. It is the computer famous for beating one of the greatest chess players of all time, Gary Kasparov. A lot of people point to Deep Blue and say that it proves machines can be as intelligent as we are at difficult tasks. Unfortunately Deep Blue isn’t very intelligent. It’s rather stupid as far as chess programs go. It’s just stupid really, really fast. It beats players simply by calculating way more possibilities than a human can comprehend. Because Chess is a solvable game Deep Blue can play well. Stanley is a machine that in my opinion accomplished a lot more than Deep Blue. Stanley is a vehicle that drove autonomously over 142 miles in less than 7 hours. Not only did it follow the course it was given, it avoided obstacles, corrected for inaccuracies in the route, and AI was entirely responsible for all of this.

The vehicle was able to drive as well as it did because of its many sophisticated input devices. For short range detection it uses five laser sensors on the roof. Each sensor is angled differently to get the optimal data. While these generate a highly accurate 3D point cloud of the road and possible obstacles, its range is limited to 30 meters. With a detection range of only 30 meters, Stanley was on capable of going 25mph and preventing collisions. For this reason the team also used a color camera and some fancy computer vision technology to detect obstacles, drivable road, and unknown terrain. With this, Stanley was capable of more than 50mph and still swerve to avoid obstacles. Many times during the race this proved to be crucial. Numbers given in the paper show more than 95% accuracy determining drivable terrain in both flat terrain and mountain roads.

Perhaps the most spectacular function of Stanley is its path planning. The team was given a disc with a number of the route’s latitude and longitude coordinates. This meant that Stanley was not responsible for coming up with the best route. The data however was horribly inadequate. Not only did Stanley have to respond to unexpected events, the data given was not entirely accurate and in some cases the given route was 10.7m off the actual road. This meant that Stanley had to plan its own short term paths. Before that Stanley improved upon the initial data. A preprocessor ran through and greatly increased the number of waypoints and then smoothed this path in order to give Stanley a faster route.

Even though Stanley has a smooth path to follow, it is still affected by the actual road in front of it, what it detects on camera and from the lasers. Many possible paths are computed and the best one is chosen. At any given moment Stanley can gently “nudge” to the side, similar to changing lanes, or it could quickly “swerve” to avoid a rock or a pothole. It is because of this flexibility that Stanley was able to successfully traverse the entire course with only a few minor incidences.

The way Stanley picked the best path was similar to how my AI program of fire trucks rescuing people worked. It scored each path based on some equation and then picked the path with the best score. There were many properties, or limits, that Stanley had that needed to be considered. Its speed was governed by several different factors, rules, health of the vehicle, and traction. If the path chosen was determined unsafe at the current speed, Stanley would slow down. Similarly, if Stanley hit a rut, it would slow down. After a short period of time Stanley would increase speed again, but this was enough to keep Stanley’s speed to a safe level over sections with lots of ruts.

All in all, Stanley is an impressive machine. Nothing about the car’s mechanics is out of the ordinary. It uses a stock engine, stock suspension. It has a few more bumpers and things to prevent damage to the car, but nothing performance wise. Everything special about this car is in the software, and the most spectacular is the artificial intelligence that drove it.

So I could be commenting on the recent post by Joel saying that you don’t have many options when choosing a language for writing high profile web software. You get .NET, J2EE and PHP but NOT Ruby on Rails. Or I could comment on DHH’s response on his LoudThinking blog about how almost everything in Joel’s post is crap, inconsistent and lacking in facts. But that would just be following the times.

Instead I’m here to give you some links about what makes a software development company great, why schedules are good, why you have no excuse not to test, how to interview, and how to manage.

• 12 Steps to Better Code
• Painless Software Schedules
• Top Five (Wrong) Reasons You Don’t Have Testers
• The Guerilla Guide to Interviewing
• Command and Conquer and a Herd of Coconuts

• Hitting the High Notes added
• Field Guide to Developers added

Have fun. In case you were wondering, I did just read them all.

I finally got around to switching this over to Mephisto. It is running the default theme right now, which is very nice, but I’d like something a little more custom Hopefully I will get around to that soon. Let me know how as broyou like it. Comments should be working, something was not true for the last few months.

This also means all the static pages I had on my site are now gone. Expect to see those up shortly.

So this is running Mephisto a new blog/cms engine written by Rick Olson, technoweenie, and designed by Justin Palmer. It is meant to be a very light application for Rails hackers. After having trouble with Typo I decided to switch as I’ve used many plugins written by technoweenie and they are all excellent.

This is not on my main blog site yet because I want to make sure its stable, I’m sure it is, I want to look into changing the theme, and I need to figure out some configuration settings.

Stay posted.

I made a small web-app last night that I am quite proud of. OneFile!

What?

OneFile is an application that allows for one file to be uploaded to it. At any time, anyone can upload a different file overwriting the old file.

Why?

I admit its trivial to code and doesn’t do a whole lot. But do you know how many times in the last month I’ve had to email or ftp a single file to someone?!

I must have this!

I know. You now all want your own copy of OneFile (it doesn’t really scale well). I have it available in an svn repository. Point yourself to http://svn.raydenuni.com/onefile/trunk. There is one small bug. It is unhappy if the first file you upload does not exist. It tries to find the create.rhtml template which of course does not exist. Nothing is truly broken though. Its just annoying. If I find out why I will fix it and let you guys know.

If anyone feels like making it look pretty, let me know.

I’ve been reading a lot of articles on software development lately. This is a short list of some of them that I thought you might all enjoy.

Getting Real – Written by the creators of BaseCamp and Ruby on Rails, its the product of their experience building BaseCamp. I think this should be a required reading for my school’s project management class.

Beginner’s Guide to Ruby on Rails – Written by someone coming from ASP and not PHP, this is an interesting, and slightly humorous read. I’m not done with it but part 1 was good.

The Perils of Java Schools – Joel always writes challenging articles and this one more than most. It made me realize that my school gets some things very right, PLC, and is not so great in others. I think I will show this to one of my professor’s when I get back.

Personality Traits of the Best Software Developers – I just read this and I agree with his arguments. Of course this could be because I flatter myself with having all four traits.

That’s all for now. If I think of another article in the near future I will add it here.

So I was informed today that my blog throws errors when one tries to comment. If you have tried to comment in the last couple months and could not I apologize. If you tried to comment in the last couple months and couldn’t, shame on you for not telling me sooner.

I tried updating Typo to the brand new 4.0.0 but this ended up screwing around with my admin pages and reverting back to 2.6.0 didn’t fix it. Summary: I’m getting tired of Typo.

Mephisto to the rescue! This is a new blog engine with some cms capability from the talented team of Rick Olson(Development) and Justin Palmer(UI/Design). Rick Olson, better known as technoweenie, has been very helpful to me with my Rails development. He wrote several plugins that I use and has answered many of my questions on irc.

Unfortunately Mephisto requires a gem that Dreamhost does not have and I am not allowed to install gems. So I have to wait until my tech support request goes through to install Mephisto on my server. Mephisto is still in heavy development, so things might be hairy, but at the very least it should be interesting.

Retrospective

I just finished work on Dashboard, the content management system for musicians that I’ve been working on for the last month. It took a little bit longer than I had planned on, but overall the project went well. I learned a lot. This was my first real Ruby on Rails project that I worked on all by myself. Before this all I had done was work on the IRPA cms. Here is a list of things I learned as well as things that just went well.

Pat on the Back

CRUD: In my quest to learn how to set up a many-to-many relationship I came across David Heinemeier Hansson’s keynote from RailsConf, which I have already told you about, and I came to learn a new way of structuring code.

file_column, acts_as_paranoid, foreign_key_migrations, and artist_location are the plugins I used on this project that I had never used before. Some required a little more work to get working, but they are were all very helpful in building the features of the project.

Migrations are something I had never used before, simply keeping my schema in a single sql file, but now I would never build a Rails app without them. I’m not sure I used them the most efficiently, as I had some problems adding and dropping columns in later migrations and often refactored everything into the original. This was fine for development, but it would be unnaceptable for making changes on a production application.

Working with a client on a daily basis was a new, and exciting, experience. This really was an agile process as I would begin each day by working on a feature, by the time I had finished working on it, the client would be online and I could show it to him and get feedback on it while, or before, I worked on the next feature. Aside from a few design flaws, for which we were both responsible, everything went smoothly and quickly.

I ran my own SVN server and used this religiously, committing every little feature I added before working on another. With 76 revisions, it made it easy to save myself when things went awry. This also made it easy to install the latest version, and keep it updated, on the client’s server.

Room for Improvement

Not everything went perfectly though and there are things I plan on doing better next time.

Design flaws and misunderstanding were the cause of a few headaches. I spent two days refactoring code because I had written my routes incorrectly and then we changed how something was organized. If I hadn’t written the routes incorrectly the change would have taken 5 minutes, instead it took most the day. However, because of this refactoring, I fixed the routing problem.

It was greating using plugins and outside libraries to accomplish stuff, it saved countless hours, but not all of them are easy to install and use. Documentation on some of them is minimal or nonexistant, and none of them have “enough” documentation. However, the people in #rubyonrails, and especially technoweenie the author of several plugins, were very helpful. Installing RMagick and configuring it with file_column was a breeze on Windows. I was impressed and very surprised. Installing ffmpeg and all of its dependencies however was a nightmare. It certainly was not ever meant to be installed on windows and I spent most of the day trying to figure out what dependencies I was supposed to install, and where to install them (Program Files was a bad place due to the space). Then once all of this was installed I had to build ffmpeg. This wouldn’t surprise anyone installing it on Linux, but this is Windows. Even after I got it completely installed I still had problems with it and even now it doesn’t work perfectly.

Project management should have been better. I used my wiki to write down design ideas, list required features, and keep track of bugs. Wikis really weren’t designed to do this and after using Trac, which is wonderful, it was unpleasant. I have recently installed ActiveCollab on my webserver and will be using it in the future.

I’m not sure what sort of documentation I needed to add to my code. Most rails code is fairly well self-documented. If you don’t know what the show() method in the ArtistController does, then you need to learn about Rails, not read the documentation. But I did have some unique methods in Application.rb and it might have been useful to document some other unique things I did.

I’m ashamed to admit this, but I didn’t do any formal testing. Rails comes with functionality for testing and it is supposedly very easy and it is something every programmer should do, but I didn’t. I was learning so many other things that it didn’t feel worthwhile for this project. I’m still not sure how useful it would have been. I guess we’ll see how bulletproof my code is over the next few weeks as the client plays with it. I plan on reading the testing chapter in my Agile Development book and using it in the next project.

Wrap Up

Overall, I enjoyed working on this project. I look forward to seeing what some artists do with the front end and seeing how popular it becomes. One of the most exciting things about it, is that a lot of the code is very similar to what I needed to write for ShowCase, so I will be copying a lot of that over. Look out for a ShowCase update soon.