So You Want to Make Zune Games?

Posted in C#, Coding, XNA on May 17, 2008 at 6:44pm.
There are no comments.

I’ve seen lots of Zune users now eager to start programming, but most of them seem to think they can just jump right in learning C#, XNA, and game programming all at once while trying to make an RPG or some other large project. In light of that, and a recent post on the XNA forums, I would like to present my advice I gave on the forums to those looking to get into game programming with XNA (for the Zune or otherwise):

“First of all learn C#. Don’t touch XNA or game programming yet. You will do yourself a huge favor by getting familiar with the language before the tools. Far too often we’ll see lots of people get stuck in their games on very simple C# issues that aren’t game related. If you take a few days/weeks/months (however long it takes for you) to learn C#, you will be better in the end. I usually recommend this free, online tutorial series: http://www.csharp-station.com/Tutorial.aspx. Of course there are countless other websites and books you can use as well.

Then, once you are comfortable with C#, start building small games. I don’t mean a small RPG because you will quickly find how not-small any RPG project is. I’m talking Pong, Breakout, Space Invaders, Frogger, Pac-Man, and Tetris. Things like that will get you through the basics of game programming and all the way to a finished product. That is really how you should learn. Too many people start off learning C# and XNA while trying to do an RPG only to get frustrated and quit because they didn’t listen and start small. I’ll be a little selfish here and plug my Alien Aggressors tutorial (82 page PDF on how to make a Space Invaders/Galaga clone): http://nick.gravelyn.com/2008/04/22/alien-aggressors-tutorial-up/. And again there are tons of other resources you can find by searching for XNA tutorials in your favorite search engine.

The last thing to know is that there will not be a tutorial for everything. The key to becoming a good programmer (for any area) is learning how to take what you know and apply it in a new way. If you become reliant on tutorials showing you how to do everything, you will fail when you reach that point where there are no more tutorials to help you. Do the work now and start experimenting. Take tutorials you see and try to bend them into doing other things. That will ultimately be the key in completing your future game projects.”

The Downside of Public Code

Posted in .NET, Coding, XNA on March 24, 2008 at 11:55pm.
There are 6 comments.

As some of you read before, I’m doing a huge tutorial for Ziggyware’s latest article contest. What I’m doing is writing a start to finish tutorial on creating a Space Invaders clone. It’s going to take a long time to write, but it will be worth it both for the community and my own portfolio.

But this experience really makes me appreciate writing non-public code. For instance I had the entire working game with two-player local co-op done with about 4-6 hours worth of work. However that was by hacking together about 800 lines of code into one file to get things working. Clearly not the way I want to teach others to code. It would’ve been fine for just shipping a game, but since I’m supposed to display some proper coding techniques in the tutorial, I have to clean things up.

I have now spent more time cleaning and refactoring than I initially did writing the game. And I’m not even done. I have to finish cleaning up another couple of files and commenting everything. And then I still want to add the networked co-op feature (system link and LIVE) before I’m done writing the game. And then finally I get to write out the tutorial to create the game.

So let this be a few lessons to all of you out there:

- Code you release to the public should look far nicer than code you keep to yourself.
- If you don’t plan on releasing the code to the public, don’t focus as much on keeping it clean unless it becomes a problem.
- Never casually say you’ll write a tutorial on making a whole game in IRC because you’ll be held to it.