Development
Environment – Tools and Other Stuff
Ok, we are set to do a Tetris® clone! What should we do now? The answer is: we should be familiar with our tools, to create our development environment. That’s really important, because if you don’t have a very organized environment, your game is not going to be very good, since you will probably get lost. Games are usually big projects, with more than just the binary output of the program. That means that we will need to edit and organize other files, and not only the source code and executable. That also means that we will need tools other than our compiler. This will not make the compiler less important. In fact…
Let’s start by choosing the language and the compiler. I won’t open a big discussion here about what language is the best one. C++ is the best one. ;) But that’s too difficult for beginners, especially because it is (usually) not managed. The other choices would be C, Java, VB.NET, C#, Pascal, Python, and a bunch of other languages. Out of those, I am choosing C#, because I think .NET Framework is a great paradigm for creating new software. It is portable, easy to develop, has a lot of free resources, has a free compiler, and I think that .NET is the next big step in home computing. Maybe not the “next”, but the “current” already. There are a lot of languages for .NET, but two are really native: C# and VB. Why not VB, then? I’ll tell you why: I was a VB developer, and since VB 4.0 I have developed a whole lot of systems with it. Because of that, I know that VB developers tend to have a lot of bad practices while programming. VB.NET is really good, but since .NET was released, I checked C# as the “new” language, and I realized that it was as easy as VB, but better, because it has more structure, and the object orientation is much, much better. So, why not C#?
What about the compiler? Isn’t C#
a product of Microsoft, so we will have to pay to develop in C#? In one short
word: NO! Check out the MSDN .NET
Ok, the language and the compiler are already chosen. You must be asking now, what else? Usually that’s all somebody needs to start developing a system, right? Maybe a database server, that, of course, we won’t need. But, as I said before, a game is not just the result of the compiled source code. For a game of Tetris® we shall have images and sounds, at least, so we will need an image editor and a sound editor. As Tetris® is a very simple game, any image and sound editor will do, and if you don’t want to have even that trouble, you can download the images and sounds I used for our project.
After our project is ready for shipment, we will also need a good setup tool. In order to keep everything free, I would say that Inno Setup is the best tool, and many popular paid softwares use it as its setup tool. I also suggest a complementary tool called ISTool, that will help making the setup script for Inno Setup. Both tools are free, and my source code of Another Block is shipped with a Inno Setup script.
That’s all we need for our project. Aside from that, I will advice you, soon to be game developers, to use some other tools to keep organization and structure in the project, as well as in the source code. I know, I know… You are thinking: here comes the unpleasant part. It shouldn’t be unpleasant though. Having a nice and structured project will pay off later, because you will be able to reuse parts of it very easily, and to update and make new versions and include new features very easily too.
So, let’s go talk about best practices. It’s nice to code your source code in a good standard. The Microsoft .NET Design Guidelines are a very good starting point, and so is the Internal Coding Guidelines, by Brad Abrams. I agree with all he’s written but the advice not to use tab characters to indent the code. That, of course, is a personal choice. A good tool to check all that is FxCop. It’s a very easy to use, and easy to integrate, checking tool, for .NET. Developing teams from Microsoft use this tool and these coding guidelines.
Finally, let’s talk about directory structure. I know this is not exactly a tool, but it’s a good practice, and it’s useful to make everything organized. Of course this is only a suggestion, and if you think you have a better way of doing things, please feel free to do it your way. You can even send me suggestions to improve my standard. I will be happy to improve it. I use the following structure:
ProjectName
|
|.....[branches]
|
\.....[trunk]
|
|.....[InnoSetup]
| |
|
\.....[Output]
|
|
|
|.....[bin]
|
|
|
|.....[Debug]
|
|
|
\.....[Release]
|
|.....[CodeCommentReport]
|
|.....[doc]
|
|.....[FxCop]
|
|.....[help]
|
|.....[images]
|
|.....[obj]
|
\.....[sounds]
Ok, let’s explain it. You can see that under the project directory, we have two main dirs, called branches and trunk. The branches dir will have, inside of it, dirs with revision’s numbers, where we will put revisions that we think will be worth to branch, that is, to kind of backup and separate it for later use, maybe. To create a branch, we will create a directory inside branches with the number of the revision, and copy the current trunk inside of it. The trunk dir will have the current working version of the project.
Inside the trunk, we have the project setup; here we will keep the setup script, and inside the Output dir, we'll keep the output of that script, that is, the setup itself. The bin directory will hold the binary outputs of our project, both in Debug and Release versions. This is default in Visual Studio. The CodeCommentReport directory is a special directory where the whole documentation for the source code will be kept. I chose this directory because that’s what the automated code report generating tool that Visual Studio .NET has generates by default. The doc directory will hold every document we generate in our project, like the UMLs, articles, and knowledge sources we need. The FxCop directory will have the FxCop project and everything related to it, if something more is needed, and, of course, if you are using FxCop. The help directory will have the help project and the HTML pages with the help contents for our project. The images and the sounds directories will have (guess!) the images and the sounds that will be distributed with our project. The obj directory is automatically created by Visual Studio, and it has the files that VS uses to link and create the binary output for our project. The trunk directory itself will have the project and the code files.
That’s it! Not too painful, was it? I hope not. Now we are ready to really start doing something, and to start talking about our game indeed, in our next article: Architecture – The Project! See you then!