About a year an a half ago I worked on a game for the iPhone called Scrap! The game enjoyed a short life in the iTunes App Store and I'm pleased to announce that Scrap! is now available on the web.

Check it out!

I got a little bored with my code color scheme for Visual Studio last night, so I went on the usual hunt for something better. Found a post from the author in the comments for a post on Jeff Atwood's blog about VS color schemes, and wanted to give it a plug. Very cool stuff:

http://frickinsweet.com/tools/Theme.mvc.aspx

Just added this one to my blog reader this morning, but I had to share it publically. The IGDA just started a blog featuring entries from some well established players in the game industry, and more specifically the game tools space. Hard to say for sure what will become of it, but I think there's a wealth of knowledge that could be shared on the topic of "Why game development tools don't have to suck". Game tools and technology has been one of my primary interests in programming, so it'll be exciting to hear what these guys have to say.

Check it out for yourself: http://toolssig.wordpress.com/feed/

For anyone wanting a little more information about this little game I published, here's a nice "how to" video Jeremy, the game's designer, made for it. Enjoy!

Just a quick blurb about my first title credit for the iPhone.

Challenge your hand-eye coordination, by flipping, rotating, dragging, and stacking pieces in a 360 degree environment. Use touch and multi-touch controls as each level pits you against the clock to build before your time runs out. SCRAP! is a puzzle game like no other. Have a piece that you can’t use? Let it go to the SCRAP! Pile, and pull it out when you DO need it. But don’t let too many stack up! At Splitcode, we hope that you enjoy SCRAP! as much as we enjoyed spending the many sleepless nights making it for you; and we know that you will find it as fun as it is challenging!

Like what you hear? It's available for download today from the iTunes App Store!

Welcome to the once again revamped MattRudder.com! I got bored with the old style, and really didn't want to reimplement it for this newly migrated site so here is the result of my boredom and wanting to use what artistic abilities I have.

I'm still working on porting the portfolio content to the new site, so stay tuned for those updates in the next day or so.

For those of you who don't know, FogBugz is a web-based issue tracking software, and the best I've used at that. We live by FogBugz at Logos, especially in the Web department, so that's why I was so excited about their latest feature.

For awhile now, FogBugz has been offering a hosted edition of their amazing issue tracking software for $21/user per month. With this package, they maintain the server, database and software, and you get to sit back and enjoy. Not to mention, it's the quickest way to test out the latest release. In his blog yesterday, Fog Creek head Joel Spolsky mentioned that there was a free startup version dubbed Student and Startup Edition. With this edition you get 2 users for free! Awesome for those with the gumption to work on projects by themselves or with one other person, or if you just want an extended trial of FogBugz.

In order to signup right now (since this feature hasn't been officially "announced" I'm guessing) you'll have to sign up for FogBugz on Demand normally, then switch to Student and Startup via the "Your FogBugz on Demand Account" screen. (Big thanks to Ian Jones for relaying the info on how to get setup  with a Student and Startup Edition account)

Over the past month or so, I've been working on our first real service using WCF at Logos. You could say that the research work was really done a couple weeks ago. Most of the pain and anguish I've felt during development has been with setting up SSL certficates for use with the service. I'm happy to say that they are no longer an issue! (can I get my WCF achievement badge now?)

To make a long story short, if you're trying to connect to a service using self-signed SSL certificates, you have one of two options:

• Add a method to ServicePointManager.ServerCertificateValidationCallback to accept all certificates (just return true; this one's a bit of a hack  :P)
• Add the issuer certificate to the client's "Trusted Root Certification Authorities" list.

I probably would have found this sooner if I had done more reading and less banging my head against the code, but we all have to learn somehow, right?

Well, I said I was going to write more frequently, so I thought I'd get in the habit of it. Maybe quality of posts is more important than quantity. Ah well, we'll try this out and see how it goes.

It sure is alot harder for me to get motivated to write code outside of work these days. I guess programming all day is enough to make anyone want to do anything but with their spare time. It seems like it should be easier to work on my own ideas. Maybe if I were more organized; I think the problem is I'm not sure _how_ to get organized.

I'm working on the same thing I've been working on for years. I want to get a killer code base together so I can work on some games. There are a few things that have come to light while working on my own project, all things that are true with any project, but especially so when you have a small team (like one guy, for instance) The main purpose of posting this here is so I don't forget to consider these things when I start on revision two. I've been reading up on some of my favorite software development blogs lately to see what I'm doing wrong (Joel on Software, anyone), so forgive me if I blatantly rip off someone else's quotes or something.

1. Know your feature set, and don't stray from them (feature creep)
   This seems like a no brainer, but when you want your project to be the best of the best its easy to get carried away. For example, the current project I've got going is in it's simplest form a game engine. The problem is, there aren't any parameters for the project laid out so when I started programming I wanted to have a 2D game engine for Windows. Simple, right? Well, a few months later the project was turned into a 3D general purpose game engine with cross-platform support but still able to support features from the latest and greatest of graphics hardware. Now that's a pretty tall order, especially for one guy working on it in his spare time with no professional game development experience to go off of.
2. Design Twice, Code Once
   Ok, I stole this saying from carpentry, and tweaked it a little to fit into programming, but there are plenty of similarities that make this adage hold true for software development as well. It's a whole lot easier to see weak points in your design if you get all your ideas out on paper first, and it's nearly impossible to change code once its released, especially if you've got other parties using your code. Nevermind that without design upfront you'll more than likely run into a show-stopping road block at some point in your development process. They made us write design documents in school for a reason.
3. Keep your specifications reasonable, and set deadlines
   I tend to daydream a bit when I start on a new project. Thinking of all the great, wonderful... no... fantastic features I'll add to my awesome game engine and how incredible the games will be that use the technology. The problem is that I'm only one guy, and on top of that I can only work on this project in my spare time. Start with a core set of features and get those solid first. You can always add more in version 2.0. Setting deadlines seems sort of silly on a one man team, especially when you need to extend those deadlines you only have to convince yourself. I don't know about you, but I work better under deadlines. It gives me an idea how hard I should be concentrating on a given task and most importantly, it helps track progress throughout the project. Checking off milestones can be a huge morale boost on a solo team, when there's no one there to tell you things are looking great.
4. Use the same tools the pros use
   If your a small team working on a project for fun, there's no reason you can't be using the same tools that the guys getting paid are using, especially if you're already using them at your paid job. Get yourself some source control at least. Trust me, it's worth the trouble of setting up and using, even if you're the only guy on the project. I've been using Subversion for awhile now on my personal projects and it really helps, and there's no worry of my files getting out of sync when I move between machines because everything is stored in one master repository. Unit Testing and Bug Tracking; also additional tools that you can add to your arsenal for no additional cost other than a bit of time it takes to learn, which you will make back over the course of your project.
   

Like I said before, these notes are for my own benefit for later projects so hopefully I don't make the same mistakes twice. By making it public maybe someone out there can glean a bit of experience from my mistakes. There are of course exceptions to these rules, and I obviously didn't hit every important point in a software development cycle. If anyone thinks of other things to note or corrections to the rules, please discuss. If I were an expert at this, I wouldn't have to write it in the first place so please feel free.