XNA Game Development

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/xna_game_development.htm]

XNA is a Microsoft platform for easily creating games. These can run on Windows, and even the XBox.

 

Essentially, XNA handles the difficult part of image rendering, and provides the developer a simple API. Bill Reiss provides some excellent tutorials to get you started.

 

An XNA project has the Game class, which provides three main methods;

1. Initialize - sets everything up

2. Update - updates the models based on a game clock

3. Draw - renders images to the screen based on the game clock, and what you updated.

This is a very intuitive API which makes it easy to make simple games, especially 2D classics.

 

What I find interesting about XNA is that many developers got their start by trying to program simple computer games. However, back in the 80s or 90s, the bar was high because it's relatively difficult to do the image rendering, especially something fast enough for a real game. Many more developers can do the algorithms and simple logic than can do the rendering. Even with Windows GDI+, it just wasn't fast enough. But XNA actually works fast enough to make it worth while.

 

XNA games can also bedeployed to other Windows machines, you "just" need to install: (1) .net 2.0 redistributable, (2) XNA redistributable, (3) Direct X. It's motivating to be able to share your work with others.

 

In the next upcoming posts, I'll provide an XNA sample game I created, and compare it to Silverlight.

Five hours for one line of code

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/five_hours_for_one_line_of_code.htm]

The other day I spent five hours to write a single line of code. This has happened before, and it always makes me think "why?" To the non-developer it could sound crazy, I've heard many say things like: "it was just one line; you should be writing 100 line of code per hour to justify our budget."

 

The issues involved are:

1. The developer is working on a legacy sub-system that they had never seen before (perhaps the original creators are no longer available, and you need to dig through their work)

2. That sub-system is written in a different language

3. The sub-system itself was complicated

4. The line to be added was an undocumented feature

5. It took very long to test each change

6. This was a mission-critical feature, so it needed to work perfectly

You add those all together, and it's easy to see it the other way - "Wow, I'm glad we got that handled in only half a day".

 

Also, this is a rare case. A developer can write many lines of new code per day.

 

I think it touches on a bigger issue - just because the end result is simple doesn't mean that finding that result is simple too. For example, the total population for the US at a given moment is a specific number (somewhere around 300 million, off the top of my head). However, to find that exact number requires a huge bureaucracy and coordination among many civil organizations (like hospitals and immigration offices).

 

It something that any developer could come across, and should therefore be prepared to explain to their managers if needed.

 

The problem with "I'll just wait until school to learn to program"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_problem_with_ill_just_wait_until_school_to_learn_to_pr.htm]

I often run across young people who are interested in computers and programming. When I ask why they don't try to learn to program, many of them shrug it off as "I'll just wait until I take the programming class at school". If you're actually interested in programming, this is a very, very, bad idea. Here's why:

1. It encourages you to become reactive, i.e. "I'll wait for someone to show me before I proactively learn it for myself". With how fast technology moves, and the need to constantly solve new problems, you can't afford a reactive mindset.

2. Classes normally only cover established (i.e. older) technology

3. Classes normally provide a bunch of extra theory that you may not need in the real world.

4. There is just so much that a class won't teach you - Classes have a predefined curriculum, and often discourage you from exploring an interesting topic in more depth (most classes eventually become about getting a good grade on the tests, and if a topic isn't on the test, why "waste" your time studying it, at the expense of another topic that will be on the test.

5. The good programmers will already be looking at the technology that isn't covered by classes. So if you wait for classes, and then only cover what's in classes, you'll always be behind the good programmers.

6. Lack of emotional investment - you'll always be more interested in your own pet projects than some arbitrary school assignment. Practically, you'll learn and remember something far better if you have an emotional investment in it. Therefore you'll probably better understand the concepts if you apply them to your own pet projects.

For an aspiring developer, waiting to learn programming until you take it in school is like an aspiring athlete saying "I love basketball, but I'll wait to start playing once they show us how in gym class". Of course it's silly. Especially now with the internet, and free development tools, there's just no reason for a young, aspiring developer to sit-around for the schools to show them how to program.

Free Development Tools

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/free_development_tools.htm]

A lot of programmers get their start as young hobbyists. However, young hobbyists often don't have the money to buy expensive development tools.

Fortunately, in .Net, you can get most of the core development tools for free.

• Microsoft provides express editions for its platform. They're more limited than the commercial products, but they get you started.

  • An editor for your programming language (like C#) - VS C# Express

  • A backend database engine - SQL Server 2005 Express

  • Environments for web and game development

• Even a hobbyist should still have source control (note that this isn't .Net specific, you could use it to manage any files)

  • A free, open-source, source control system (which is way better than VSS) is Subversion.

    • Command line version - great for automating things

    • GUI front end - good for an easy GUI

  • Even if you are the sole developer, source control still is invaluable:

    • It lets you keep track of all your changes, giving you the confidence to experiment with big changes because you know you can just roll back. This is much better than copying your entire project each time you do something big.

    • It lets you view the entire revision history of your code

• There are tons of free helper-tools, like NUnit for unit tests, FxCop for static code analysis, and more. Scott Hanselman does a great job of summarizing these.

Given that the knowledge is free (via millions of internet tutorials, blogs, and reference guides), and the tools are free, all you need is a computer and motivation, and even the young hobbyist can become a great developer.

---

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

 

Fun Pet Project Ideas

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/fun_pet_project_ideas.htm]

Perhaps the best way to learn programming is to do a project that you're personally interested in. When I talk to younger  programmers, I usually suggest that they find something and try it out. For example:

• Create your own game with XNA game development

• Build your own personal website

• Build a tool for data manipulation of your blog sites (like Facebook, myspace, or live journal). For example, you could write a tool that converts the archive files into a word or PDF doc, so you could have a book form of your entire year's worth of entries.

• If you're a student, solve your math or science homework with a program.

• Play around with Ajax or Silverlight to make a fancy way to display your pictures online.

There's also: http://blogs.msdn.com/coding4fun, whose name says it all.

 

The point is that people naturally remember the things that they personally care about, and most people care more about their own pet project than an arbitrary work or school assignment.

 

---

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

 

Developer Jokes

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/developer_jokes.htm]

Here are two developer jokes, just for laughs. I can't remember where I heard these:

Interviews: A confident college grad is interviewing at a software company. When asked what sort of compensation he's looking for, the grad suggests a 6 figure salary, 5 weeks time off, and free tuition for a masters degree.

"No problem," replied the boss, "We even give you your own company car."

"Really, are you kidding?" asked the grad.

"Well, no... but you started it."

 

Time sheets: A manager was staffing for a new consulting project, and insisted that he needed a developer with at least 15 years industry experience. When he found himself staffed with a young kid, barely out of college, he told his director "You must have made a mistake, this guy is just a kid, but I need someone senior".

"Oh," his director replied, "my bad, I determined his age from the amount of hours he logged in his timesheet."

 

---

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

 

Using Nullable to create a null boolean

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/using_nullable_to_create_a_null_boolean.htm]

A classic problem in data mapping is how to handle null values. For example, a database column may be of type int, but it allows null. Many devs will just designate a sentinel value (like Int32.MinValue) to correspond to the DB null. That's okay for integers or DateTimes that have millions of values to spare, but it doesn't work well with booleans where you have only two values. You can't always assume that "null" corresponds to "true" or "false".  There are many common solutions to this:

• Having an additional property "IsBooleanFieldSpecified" [Problem - this requires an extra property]

• Not using booleans, and instead using a wrapper that has a third option for Null (like System.Data.SqlTypes.SqlBoolean) [Problem: most devs think in terms of System.Boolean]

• Requiring all booleans to be not null in the database such that the null problem never appears [Problem: This may not be realistic, especially for legacy systems]

One easy way to handle this with C# 2.0 is with Nullable types. For example, you could write a method that takes a null boolean:

    public static string HandleBool(Nullable<bool> b)
    {
      if (b == null)
        return "NULL";
      else if (b == true)
        return "TRUE";
      else
        return "FALSE";
    }

 

    [TestMethod]
    public void NullableTest_1()
    {
      Assert.AreEqual("NULL", HandleBool(null));
      Assert.AreEqual("TRUE", HandleBool(true));
      Assert.AreEqual("FALSE", HandleBool(false));
    }

 

Note that without the "Nullable" prefix, passing in null would throw a compile error. The solution seems the best of all worlds.

 

---

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.