Browsing Category: Useful Tools

Even though hard drives are getting bigger and Internet connection speeds are increasing at a dizzying rate, not everyone has access to the latest technology. The smaller you can make your software, the more you increase the amount of people that can play it – thus increasing downloads.

Use the Right Tool for the Right Job

If you’re compressing images, choose the right format for the right job. PNG is a lossless format that is much better at compressing pixel art images than photographs. JPG can leave a lot of “artifacts” on these kinds of images, and is better suited for compressing photos or painted artwork. Choosing the right format not only shrinks the size of your application, but helps to maintain the quality of the final product.

Shrink Executables and Libraries

You can generally shrink you .exe and .dll files by around 50% by using UPX, with no discernible change in performance.

Note: Always compress executables after icons and resources have been added, as adding resources to a compressed executable can result in programs working strangely (or not at all).

» Get UPX

Shrink Images

If you’re using PNG images, pngcrush is an essential application to have installed. It has many different levels of compression available and can generate considerable space savings. Perhaps the most useful feature is the “brute force” option, which will try over 100 different combinations to create the smallest possible image file.

» Get pngcrush

Shrink Music and Audio

Using OGG or OXM for music can generate large savings when compared to raw formats such as WAV and XM. OGG is well suited to sound samples and music, and can make a huge difference if the correct quality settings are chosen. It’s usually best to try a few settings and listen to the results to see which quality to use, as some qualities work better for different kinds of sounds.

OXM is a compressed version of the XM music format, a MIDI like format that uses its own samples. The OXM format compresses the samples using the OGG codec, and can easily shrink a track by 70% or more with virtually no audible differences.

OggEnc is a command line tool for encoding OGG files, whereas OggDrop is a GUI application that supports drag and drop. OggMod is a tool for compressing XM files into OXM.

» Get OggEnc / OggDrop | OggMod

Pack Your Data

If your game uses any kind of custom data definitions, such as text or xml level definitions, you can generate extra savings by compressing them. There are many different compression algorithms, and some are more suited than others. Run Length Encoding (RLE) works well for data that has large areas of sequential data values, but isn’t as effective for other formats such as XML. There are plenty of freely available compression libraries, and including zlib and unrar, and most languages have a wealth of examples to look at.

Automate the Process

Manually compressing all of your media can be a slow and tedious process, and can generally be left until the game’s release. At the simplest level, you can place all of the commands into a Windows batch file and run it once you’ve compiled your software. Other options include using build software, which is covered in more detail in the recent build tools article.

This is a simple change that can make using the Windows command line much easier. Adding a directory to the Windows PATH will mean Windows will search the directory when a command is entered. The main reason for doing this is that it acts as a shortcut for common applications you may run.

For example, instead of typing : "C:\Program Files\SomeProgram\Bin\MyProg.exe" --some-arg to launch an application, you can type MyProg.exe –some-arg. This has three main advantages:

1. Looks Neater – This can be important if you’re using batch files. Long lines are hard to read, so shortening things is a good idea.
2. Less Typing – Speaks for itself. If you use the command line or batch files for any amount of time, you’ll appreciate how much easier it is to use if you’re not typing full paths for your tools.
3. Portable – Perhaps the most important detail. Not using hard-coded paths makes it easier to port your batch files to other machines.

Note: Be careful when editing your path variable, as you could render some programs unusable if you make a mistake. Also remember that changes won’t take effect until you restart the console.

Editing the Windows Path Variable

1) Right click “My Computer” and select “Properties” OR goto Control Panel and select “System”. This will open the “System Properties” window.

2) Switch to the “Advanced” tab, and select “Environment Variables”.

3) There are now two options. You can modify the global path variable, or add your own to your personal profile. If you want all users on the machine to have the same shortcut, add it to the global path, otherwise use the local one. 

Modifying the Path Using the Command Line

If you’d like to do this using the command line, you can use the “setx” command included with Windows XP service pack two. To add the directory “c:\program files\SomeProgram\Bin” to your path, use the following:

setx path "%PATH%;C:\Program Files\SomeProgram\Bin"

Remember to include the %PATH% variable at the start of your setx command so that you’ll keep existing path names.

Creating software is a time consuming business, and it’s important to always be on the lookout for ways to reduce the amount of time spent on less important tasks. The process of actually building software (creating the finished distributable binary) is one such area that can be optimised. Opening up your IDE and hitting “compile” might not seem particularly time consuming, but it’s only one part of the build process.

To get you started, here’s a short list of tasks that can be automated:

• Compiling the executables and dependent libraries
• Packing media
• Creating an installer
• Uploading files to an FTP site
• Checking out files from a repository to be built
• Sending an email about a finished build to other developers
• Creating the application documentation / Converting it to HTML
• Testing the software

The benefits of using an automated build system include:

• Saves time – Run a build and leave the computer to do the work whilst you take care of other tasks.
• Documents the build process – If a build requires several steps before being completed, a build file will document this process for you. This is useful if templates need to be generated or options need to be set before a build is ready.
• Improves quality – As well as automating the creation of a binary package, tests can be automated. This saves a lot of time on the development end, as tests can be constantly run so you’ll quickly find out if the software’s behaviour has changed.

Simple Automation – Batch Files

The simplest way to automate many of these tasks is to use batch files. A batch file is a list of tasks to be run, usually in the form of a list of applications with some command line parameters. Using a few simple commands it’s possible to run many tasks in succession without any user input, leaving you to do more important things. Microsoft.com has a is a simple guide to batch files which is a good place to start.

As useful as batch files are, there is only so much they can accomplish, and there may come a time when something more complex is required for your project. Thankfully there are many build systems available

Build Tools

There are plenty of build systems available, and several of them are targeted at certain platforms or languages. It may take a while to become comfortable with a platform, but the savings are worth it.

• GNU make – A standard system used by many Linux projects. It consists of a plain text file that lists targets and dependencies, and features many advanced features such as automatically determining which files require rebuilding.
• Apache Ant – Ant is designed as a replacement for make, and uses XML files to describe the build process instead of text files. It’s written in JAVA, and is completely portable.
• nAnt – nAnt is a .NET based version of Ant, and although it is not exclusively for .NET developers it has many features that make it useful for building .NET apps.
• A-A-P – A-A-P is a portable build tool that uses text-based “recipes” to compile and distribute software, but it can also be used for other tasks such as publishing websites and generating files from templates.
• Visual Build Professional – VBP is a commercial build tool that takes a more visual approach to creating build scripts. It integrates well into many Microsoft IDEs, but also supports other languages such as Delphi and Java.
• BlitzBuild – A free build tool aimed at BlitzPlus and Blitz3D developers.

Breaking the Task Down

Most build scripts will contain more than a single command, so it is useful to break the build script into different groups or “targets” that can be executed individually. This is particularly useful if building of data files is included, as it can be used for art or music to be built independently of the main application. Many build platforms also allow targets to be called from other targets, which effectively breaks a build script into a set of functions that can be executed in any order.

Common targets include compilation, installation and cleanup, but the choice is entirely up to the developer. It may also prove beneficial to include a separate target for generating debug versions of the application which can be distributed as a troubleshooting option.

Subversion is an open-source version control system. That doesn’t sound particularly interesting, and at face value it isn’t, but you only need it to save your skin once to realise how useful it can be.

Version control is a method of storing different revisions of the same file, usually source code or documents. This allows developers to see when changes to a file have been made, which can be useful for isolating bugs, and can also be used to “roll-back” a file to a time before a bug was introduced.

Along with these features, version control allows developers to merge two versions of a file, which is very useful for projects with more than one person.

This article covers the following:

1. What software you need
2. Creating a new repository
3. How to set up a Subversion server
4. Adding password protection to a Subversion repository
5. Laying out your repository and importing files
6. Checking out and checking in
7. Using tags and branches

What you’ll need

Subversion – The primary download is source code, but there are binary versions available for different operating systems, including Windows, Mac OS and most common flavours of Linux.

If you intend to use Subversion mostly from the command line, you might want to add the Subversion binaries directory to your Windows PATH variable.

Optional Downloads

TortoiseSVN – If you’re using Subversion with Windows, I highly recommend installing TortoiseSVN. It integrates with the Windows explorer shell, so you can see an icon if a file has been changed. You can and also check in items, commit changes and perform other common operations with a few clicks of the mouse instead of using the command line.

I use the “Sociable” WordPress plugin to add social bookmarking links to the bottom of every post. There are a tonne of social bookmarking sites around, so I’ve kept things light to avoid the icon overload that can be seen on some blogs. I’ve made two updates over the last few days, one was adding devbump and the other was adding CSS image rollovers.

If you’re not sure about adding a few bookmarking buttons, you might want to check out the traffic increase at webloghits.com. That’s the kind of increase that is worth a few minutes of your time.

Adding devbump.com

There are a lot of digg style sites out there, but devbump caught my eye because it’s aimed squarely at game developers. Submitting your posts to places that are actually interested in the subject is always more useful, so devbump was a natural choice. 

To add new sites to sociable, open up “sociable.php” and find the following line:

Once you’d found it, add the following after the “Del.irio.us” definition:

You’ll have rebuild the list of available sites by logging in to your blog, and selecting “Restore Built-in Defaults” from the sociable page (Options -> Sociable). “devbump” should now be available to use on your site.

Adding CSS image rollovers

Now for the fun part. I used some code from Present Tense (Hacking the Sociable WordPress Plugin for Image Rollovers), but it didn’t quite hit the spot so I did quite a lot of tweaking to get things looking nice. I’ve stuck it all in a zip at the end of this post.

Before you skip ahead to the freebies, there are a few important things to note.

Tweaked “sociable.php” — I made two main tweaks to sociable.php. One was because some sites have “.” characters in their name, so it wouldn’t work with CSS class names. The other tweak was to change the way that the HTML was generated. Instead of standard images, it’s a list.

Internet Explorer — Naturally IE messes things up a little bit, so you might have to experiment a little bit to get things looking the way you want them. Removing the CSS tooltip may help.

16 x 16 Images — I like to have text next to my images, so each one has a different width. If you open “sociable.css”, you’ll see I’ve defined each networking site with a pair of definitions:

If you’re using 16 x 16 images, you can move the width statement into the “.sociable li” definition.

Adding New Rollovers

To add a new image, you need to add a class with the name of the site, and then set its image. It’s really just a matter of copying an existing class definition and changing the names. I’ll add new sites as time goes on, but at the moment I’ve only defined: del.icio.us, digg, devbump, Reddit and Furl.

Free Stuff!

Everyone likes free stuff, so I’ve zipped up all of the files I modified for your downloading pleasure. There are still a few bugs to iron out, so I’ll be modifying this post as and when things change.

To install the changes, just copy the files into your “wp-content/plugins/sociable” directory — you’ll need to have sociable already installed (download here).

I’ve looked at a lot of bug trackers over the years, and I even had a crack at writing my own as part of my final year university project. It was certainly an experience, and it taught me the value of “eating your own dog food”.

There are hundreds of bug trackers in the wild, and they range in quality and functionality. Some are in-depth packages that really ease the process and were clearly designed with developers in mind. Others are not so good.

With so much choice available, it’s good to look at the pros and cons of various systems. It’s also important to make a list of your requirements, and as indies we often have a different set of criteria from larger companies.

Why Bother?

There are plenty of reasons to use a dedicated issue tracker:

• Organisation — Problems with the software are recorded in a central place, so you don’t have to worry about losing that post-it note with an issue’s details scrawled on it.
• Transparency — Although it can seem counter-intuitive, letting your potential customers see your bug database can have a positive effect because it lets them see that you’re actively fixing problems. It also lets them know that there’s a place they can send problems, and that they’ll be dealt with efficiently and not swept under the rug.
• Distributed Teams — If there are several developers involved with a project, having a central system where tasks are assigned is a Good Thing. It saves multiple people solving the same problem, and helps to share the workload.
• Documenting the Process — You know what was fixed, when it was fixed and who fixed it. In some systems, you can also find out where the problem occurred in the source code and use this information to improve the quality of code.
• Feedback and Support – Some systems also allow users to submit feature requests as well as support queries. Again, this helps with keeping things organised and preventing things from getting lost.

Do Indies Have Different Requirements?

Everyone has their own set of requirements, but as a general rule indie developers will not have the same requirements as a larger company. For a start, we’ll want it to be as cheap as possible! Thankfully there are a lot of open-source projects available that will run on most web servers.

My List of Requirements

I’ve put together my own list of requirements for an issue tracker. They’re by no means a definitive list, but they’re a good starting point for your own list.

Minimum Requirements:

• Easy to Use — Not everyone is technically minded, and I want the system to be accessible by as many people as possible.
• Support for Multiple Projects — I want something that can manage several projects, as it will be a central place for all my work.
• Access Levels For Projects, Issues And Fields — Although transparency is good, I still want a certain level of privacy with issues. The ability to set projects as private is important, as they might be WIP or not ready to be announced.
• Anonymous Viewing — I don’t want people to have to register just to view the list of bugs.

Nice Extras:

• Templates — I’d like the bug database to fit in with the rest of the site. If templates aren’t available, it should at least have a clean interface.
• Web Service API — An API is nice so that applications can submit their bug reports. This can be kludged if not available, but it’s nice if it’s built in.
• Project Overviews — I’d like to see overviews of projects, either with graphs or just a configurable list.
• Subversion Integration — As mentioned in my previous post, I use Subversion to track changes in my projects. I’d like a bug tracker that integrates with SVN so I can see what files were changed to fix an issue.

What Solutions Are Available?

Here are some of the better solutions I’ve looked at. I can’t really do them justice in a few paragraphs, and most issue trackers have the same core features so I’ve tried to pick out some of their more interesting aspects. 

Eventum

Eventum is an issue tracker from the MySQL team. Features include support for multiple projects, web-based and command line interfaces, and full CVS integration (Subversion integration is available at the Eventum Wiki). It also features XML-RPC and SOAP web services, as well as an IRC Bot which looks useful for distributed teams.

Mantis

Mantis is an open-source, PHP/MySQL based bug tracker. It’s simple and lightweight, but is designed to be easily extendable for people who want a little bit more. If you’re not after anything complex, Mantis is a good place to start.

BUGS – The Bug Genie

A very slick looking, open-source issue tracker. It supports attachments for issues, as well as multiple products, editions and milestones. You can also set it up to email you whenever an issue is posted. It’s very customisable, and you can alter the built in help as well as alter the appearance using themes.

JIRA

A feature packed, highly extendable piece of kit. The search features in particular are worth noting, as searches can be saved, shared and subscribed to. It can be extended to integrate with source control, and it features XML-RPC, SOAP and REST web service interfaces.

FogBugz

A comprehensive bug tracker, tailored toward making the workflow as smooth as possible. Issues are always assigned to a single person, and this person becomes responsible for fixing the problem (or delegating it). The interface is very clean and clearly tailored towards ease of use. 

One particularly nice feature is its ability to add customer emails directly to the system. For example, a customer email to “support@example.com” can be automatically entered into the system and become a new case. This case can then be assigned appropriately. The customer also receives an email with their case number, allowing them to see exactly what’s going on.

Axosoft OnTime

OnTime features a web-based interface, as well as Windows and Visual Studio clients. It can be integrated with several source control systems, including Subversion and Perforce. You can also define and use your own workflow, such as XP or Scrum.

There’s Plenty More…

Most of the issue trackers listed have demos that you can play around with to get a feel for the software, and I recommend trying a few out before settling down. I’ve tried several of the ones listed, and I’ve still found it hard to pick one. Although any system is better than none, it’s still important to choose one that “feels” right.

I’m always interested to see what other developers use for issue tracking, whether it’s a pen and paper, an Access database or something more complex. Feel free to let me know what you’re using, and why.

As I’ve previously mentioned, software development is divided into two very distinct parts. The fun part that everyone loves, and the tedious bits that suck away your energy.

You can think of it like an iceberg. There’s the top that everyone sees, where penguins frolic and hold parties. Then there’s the sub-surface part. A dark and dreary place that people try to ignore. You can thank that part for the sinking of the titanic.

Today I’ll be talking about the 90% you wish wasn’t there. Sorry about that.

It’s not all boring!

OK, so maybe it is, but if you’re a programmer you’ll know there’s a certain satisfaction you can only get by automating some part of the development process. As Steve McConnell puts it in “Code Complete“, if a programmer can do a job comfortably in five hours, or spend four hours and 45 minutes writing a tool to do it in 15 minutes, they’ll choose to write the tool every time.

My tools directory is littered with quick, one off scripts I’ve written to get a job done, or other small applications I’ve downloaded. Today we’ll be taking a brief look at my setup.

The IDE

The language I use most frequently is Blitz Plus, so my development environment is tuned to making me more productive in it. My IDE of choice is Protean, which became a free product earlier this year.

The main reason I chose Protean was the excellent code completion support, as well as the project support. These two features alone have probably saved me hours worth of work. The standard Blitz IDE is a little clumsy for larger projects, and it was quite a hindrance.

I keep the Windows taskbar auto-minimised on the left of the screen. This helps when I have several windows open, and also maximises the amount of space the IDE gets. It’s not a huge gain, but every little helps.

I also like the colour green.

Plenty O’Tools

My tools directory contains dozens of applications, ranging in size and complexity. There are far too many to list in detail here, so I’ll stick to the ones I use most often.

• PHP – I use PHP for a lot of “glue” scripts, because it’s quite easy to knock up a simple script to do something useful. My original build scripts were written in PHP, but I’m slowly migrating them to BlitzBuild. I’ve used PHP for all kinds of things, from generating code distributions to parsing source files for variables. I considered using Python for these tasks, but I felt more comfortable using PHP. It’s not just for websites! 
• pngcrush – A simple tool to compress png files a little further. Not really essential, but I’m still stuck in “this has to fit on a floppy” world so every saved byte counts.
• ResHacker - Blitz doesn’t add much information to executables, so I use ResHacker to add a fancy exe icon, as well as resource information. It can be used from the command line, so it’s part of my post-build script.
• Subversion – I run a Subversion server on another machine, and it’s saved my bacon on several occasions. I use TortoiseSVN for the front end, because it makes life so much simpler.
• xsltproc - I’ve recently started using DocBook for documentation, and I use xsltproc to convert it into something pretty. I prefer running it on Linux, as it seems to run much faster.
• Kate – I use this for editing DocBook XML files, and it supports code completion and code folding. I sometimes dabble with XXE for DocBook work, but I find it to be overkill for most of the documents I work on.

Putting It All Together

As powerful as these tools are on their own, they really shine when joined together in a build script. At the moment, my Blitz projects have three batch files: “pre-build”, “post-build” and “build-resources”. The pre-build script is for auto-generating source files, and the post-build script takes care of adding resources to the exe and compressing it. The resource builder compresses sounds and graphics, processes any extra files (such as XML files that need converting) and creates all of the data files.

In the future, I want to move all of this into a single BlitzBuild script, as I feel the three batch files are a weak link in the build chain. I’d much rather run a single command and have the whole process work automatically, than run different batch files. I also want to add support for different configurations. This will allow for quick builds that don’t create resources, as well as special debug builds that add extra information to the exe.

What tools do you use in your development process? Do you have any novel uses for existing tools? What single application saves you the most development time?

One of my favourite things about WordPress is its extendibility. It’s very easy to add new functionality with the plugin system, and it makes for a really powerful application. Here are a few of my favourite WordPress plugins:

• Akismet – If it wasn’t for Akismet, I would have turned comments off a long time ago. I’ve been running it on this blog for about three weeks, and it’s caught nearly 400 spam comments. That’s a lot of spam for a small blog like this, and it was a major time consumer before I installed Akismet.
• WP-PageNavi – This manages the navigation between pages at the bottom of each page. I find it a lot easier to navigate sites that use this as opposed to the default WordPress “Next Page / Previous Page” setup.
• Related Posts – Shows the related posts at the bottom of each page. It’s almost essential for any blog that has more than a handful of posts, as it allows readers to find a lot of older posts that may have remained hidden to them.
• Smart Archives – Used in conjunction with “Exec-PHP”, it produces the archives I use on this blog. It’s another “must have” for anyone with more than a few posts.
• StatTraq – Shows me where people are visiting from, and what they’re reading. It’s not particularly heavy duty, but it gives a good overview of what’s happening.

You can find plenty more plugins at http://wp-plugins.net/.

Jensen Harris just posted a walkthrough of how Microsoft prototype using PowerPoint. It’s almost identical to the way I’ve been doing it, although I prefer to build the entire UI from shapes and images before creating a detailed picture and overlaying transparent “hot spots”. This makes it much easier to move elements around, which means you can quickly try out different layouts with minimal fuss.

One point is that it’s best to stick to small segments of the user interface in each presentation, because things can get very complicated very quickly.

I’ll be honest; PowerPoint is one of those applications that I treat rather harshly. I’ve been put off by too many awful presentations with whooshing bullet points, dreadful clip art and perhaps even a few sound effects for good measure. As far as I’m concerned, PowerPoint is a tool for creating nightmares. Horrible, bullet point riddled nightmares.

However, after reading “The Feature Bob Invented” on Jensen Harris’s Office 12 blog, I’ve learnt a new use for PowerPoint: Prototyping User Interfaces.

User Interface design is something of a dark art, and can be particularly difficult for programmers. Mocking up a few screens in paint is handy, but stringing them together and adding the correct hotspots can really help you visualise how it’s all going to work. It’s quite easy to put together a few slides with fake buttons, and I managed to get a rough prototype up and running within a few hours. Not bad for someone with “limited” art skills and a general distrust of all things PowerPoint. I was pleasantly surprised by how easy it all was, and just seeing it working gave me plenty of ideas for improvements.

One of the most enlightening things you can ever see is someone trying to use the interface you’ve designed. Having an interactive prototype makes it much easier to see how they react to the choices in front of them. Even if you can’t get to watch someone use your interface, sending your presentation to a few people to try out can still generate valuable feedback.

I highly recommend giving Jensen Harris’s blog a read. It’s a fascinating insight into how a large company like Microsoft designs and tests user interfaces, and shows off some of the new features of Office 12.

I’ve installed a lot of applications on my PC over the years, but several have earned the distinct honour of being allowed to stay:

1. Freemind – An excellent mind-mapping tool that makes it easy to grab lots of ideas. I use this to note down all my rough ideas, and although it’s not quite as flexible as a pen and paper, it’s extremely useful.
2. Keynote – I’ve tried several tools like this, and although it doesn’t have the power of Microsoft’s OneNote, it’s much smaller and sits quite happily in the tray.
3. CommandBar – If you use the command line for any amount of time, this is an invaluable asset. It allows you to open an explorer bar, similar to “History” and “Favourites”, that contains a working command prompt. I use this quite regularly, usually when building resource files for software, and it has made my life so much easier.
4. Foldersize - Another explorer extension, this time allowing you to view the size of a folder in a column in explorer. Quite handy when trying to find junk hiding on your hard drive.
5. Vim – There’s not a lot for me to say about Vim that hasn’t already been said. I use it mostly for editing batch files and .htaccess files, but also if I just need to edit a file quickly.

I hope you find them as useful as I do.