The importance of tools (Part 1 of 2)
As any good developer would know, tools are an absolutely essential aspect of development of any project, regardless of size. All too often it can easy to design the perfect tool for the job, but ignore and perform the task by hand because the tool costs 5 hours, and doing it by hand will take 3. In the first of these articles, I’ll be discussing this simple repeated mistake alongside some example tools that have been created for the usage of CraftWorld.
When to create the ideal tool for a Job?
If you find yourself in a situation where you have a mundane and repetitive task, or even a complex one, you most often need specific non-existent application to grease the wheels of development. Even if it is a task that you know for certain will only ever be done once, then it is time write something to fit the job. An ideal example of this, is our Simple Sprite Sheet Packer. There are many other sprite sheet packers out there, and many of them are free and provide good results. The largest issue with this is simply the search time. Regardless of how much of a bing/google ninja you may be, most of the time this time is simply wasted beyond a 5 minute search.
Developers build their own tools, for their own purposes. A few even find their way to a small sellable product on an obscure website, or file site somewhere. The results these rare finds may yield are often varied and frustrating. Lack of support for setting quality on a png, or simply constraining height to a certain size is enough to render the found tool useless. In these situations it is best to simply say “Fuck it” and begin from scratch, as simple and as quickly as possible.
Benefits of your own tools? As your demands change, and increase, it is simple to update and modify what you already have to fit. Skipping this, will usually result in more tiresome searching. Adopting an attitude of “Just build it” will create you toolbox of unique and perfect applications over time saving time in both the long and short term. Plus you will pick up essential tangential skills along the way.
Any XNA developer, would benefit greatly from a cursory knowledge of WPF or Winforms considering they all can share C#. My biggest regret is not simply writing more tools.
A small example.
Daniel used winforms to create this simple sprite sheet packer after finding a bug in a “from the wild” tool that created the perfect sprite sheets, but neglected to sort alphabetically. It took no more that 4 hours, and was something that would have proved infinitely useful during the development of Project Delta, Project Alpha and Zombies 2.0. Now WP7 versions of these games are far more likely…
We simply use this tool for generating animated water textures for png’s created in the open source application, Blender. Shortly after it’s creation we were able to quickly trial a half dozen different textures within half an hour, only to discover that there was a better way of creating pretty water. But more on that in a future post.
A large example?
CraftWorld is an RPG built atop perlin generated , block based terrain. Tweaking such a beast had become a pain, so Daniel decided to invest a few days in creating the perfect terrain preview tool.
It is simply 128×128 textured planes interlaced, rendered with a custom shader for performance and to apply false depth to the scene. It results in a holographic slice of any given segment of terrain that renders at close to 1000 fps (We’ve capped it to 120)
Daniel worked hard on multithreading this monster to heck. Each core this application has access to, splits the perlin workload, allowing ultra fast terrain generation for on the fly preview of our current settings. Couple this some automatic importing of a simple settings.Config file (just a text file) and it is a fantastic utility for tweaking our terrain. This negates the need to fire up the full engine, swap out to fly camera mode and wait for the full 3D content to stream in, region by region.
The tool began its life as a simple debug utility to find the cause of terrain seams. These were reported during our first engine test, as giant blocks of terrain, seemingly out of place with the rest of the world. The issue was simple that the multi-threading system was out of sync, causing some regions to build out of order or in some cases, flipped and reversed. After that, Daniel got creative and wanted to make sure the generated data was actually matching what the in game terrain was showing.
Now we can furiously try radical new things, and move variables by decimals to get just the right look, avoiding floating islands and infinite mountain ranges. Implementing dedicated floating island worlds, castle generators and specific environment types should now be easier, with a means by which to actually view the data in a relevant way without need to run the whole game.
Next week I’ll be writing up some info about the tool we use for testing the new water shaders we are using on PC and Xbox and another micro-tool we recently finished.