Wednesday, September 29, 2010

Input System: Part 1 Static Classes

This is going to be a mini tutorial on how to create a simple input system now there are many ways you can go about creating an input system and this is just my approach and is in no way the best but works for what I use it for which is all that matters. Now before I go into the code itself I want to first discuss static classes since there are major discussions with why static classes are bad and should be avoided and such. I will also try and explain when to use static classes and how to use them in relation to c#. 

Now lets start with the good parts of static classes. First off static classes do not need to be created they are automatically created at runtime and because of that these classes can be accessed from anywhere in your code without creating any new variables. This is the main reason why we are using a static class for our input because we want to be able to get whether or not buttons were pressed from not only our main class but a lot of sub classes will also need them. Because there is only one instance of the static class you will never need to create multiple instances of the input class which will simplify a lot of code. 

These characteristics of static classes do come with some downsides though. Now because static classes are created at runtime automatically they can not contain and constructors which in our case is not a problem. And because there are only one version of the class objects like bullets or particles are completely out of the question. Also people do not like it when you continually  reference static classes in your code because it makes it so they can not reuse only part of the code they would need the extra static class for it to function. Now this argument makes sense in a lot of ways but most of the time for me it is the static classes that I want to reuse anyway. For example whenever I create a new project I will instantly copy and paste in my input class and my base game class and build the game up from that. I can see it if someone was to use nothing but static classes to do everything in their game that it would get quite annoying to have to look at all the different classes to understand what is going on, but in this example our input class will be so self explanatory that this will be unnecessary. If this doesn't make complete since it should when I go over how to create and use static classes in the next part. 

Now I do not know exactly what static classes do behind the scenes but this is what I have read and noticed when I use them but I could be wrong in some parts. If you want to do some extra reading you can go here. This was a little more then I wanted to do on static classes since most of this will make since when I show you the code in the next few parts but oh well. Should have the next one ready soon. 

1 comment:

  1. I'm with you on this one. I tend to use static classes when I am either being lazy or i want to quickly smash out a rough and ready app that is required in a hurry (eg. print queue management util). It sure is easier than having to create a new instance each time.

    Yes, I also see why they should be avoided but, I suppose it comes down to whether or not anyone else is going to be using your code...