So we completed the design document and can now go to work. It was a great effort to put everything into the dd. Didn’t know it can take that long. The first decision which has to be made is what is my target platform? Since we plan to make a Windows only game there are two possibilities to decide between the tools we will be using. Shall I use C++ or should I go with XNA? Both are great but I decided to go with XNA. Of course C++ would be the one to choose if we would talk about an high performance 3d application but we will develop a 2d game so I think XNA would safe us a lot of time. I could be terribly wrong (it will show in the future) but I think it’s the best decision. XNA ships with so many features we can use out of the box, so we can concentrate on the game itself which will save us a lot of time.
I never worked seriously with XNA as you can see on this Blog. I always thought C++ and DirectX are the way to go. The game MegaHot (which was released for Windowsphone 7 recently) was my first real XNA experience that far and I was impressed how cool XNA really is. Let’s do it in XNA.
There are plenty of great XNA tutorials on the web which already helped me on MegaHot so the first pit stop is on http://create.msdn.com which is my first choice when it comes to understand how things work in XNA. Plenty of sources there, tutorials, articles everything you need.
So I started with my framework this week and soon realized I wouldn’t come that far the way I was thinking. The first problem I ran into was my custom level loader. I planned to create our prototype and offer the build to the graphic artist where he can easily exchange his sprites, textures whatever, run the application and watch them how they look like in-game. This was the plan. I did this about 100 times in C++ and it worked great. The coder can continue to work on the game and the artists have the freedom to play around with the stuff. But it wouldn’t be that easy. I totally forgot about XNA’s content pipeline. As it seems by default you have to add all the assets in design time to the project. That means I have to provide the complete code to the artist? He has to re-compile every time he changes a single sprite? There are some exceptions like the Texture2D which allows you to load from file, but those are not available through all the asset classes like Models, Effects etc. The Texture2D class for example contains a function called Texture2D.FromStream(); where you can manage reading the texture data from wherever you want and simply pass in the stream with the texture data. But the Model and Effect class don’t contain something similar. That’s most probably because you don’t have access to the filesystems on a XBOX or a Windowsphone. But what if you are a game developer for PC only? More details about the content pipeline and the question how to add your content can be found on MSDN here
. Again I’m relative new to XNA if someone who reads this knows how to to do it please tell me. AFAIK this is the only way to go at current (there are moments where I missed my virtual file systems in C++, allowing the artists to drop their assets into the directories and the game handled everything itself). Ok no problem, let’s do it the XNA way. SVN repository created and the XNA tools installed on the artists machine.
The second problem I soon faced was my custom level file. In fact this was not a problem since I was not aware that XNA’s build in content pipeline allows you to extend it for custom formats. So this one is a real cool feature and shows the strength of XNA. My level file format is a XML file with all the data stored in there. It contains string, float and Vector types and also lists of class objects. XNA allows you to add custom formats with the ContentPipelineExtension. Now I’m impressed. It was so easy integrating my custom level file and creating my level loader to read it. The best thing is that changes which sure will be made on the level file format are so easy to implement. It usually took me days to make the same work in C++. Not in XNA. I knew it was a good choice to go with XNA (until now :)).
That’s all for now. Let’s continue with the editing tools…
