Here's a few indie developer blogs that I subscribe to:

• An Independent Game Developer's Diary – One of the most interesting things about this blog is that it also describes the business side of things, such as deciding which business structure to use and basic accounting.
• Cliffski's Mumblings – The blog of Cliffski, the developer of Starship Tycoon, Democracy and Kudos. I definitely recommend checking out the Kudos Design Post-Mortem.
• The Dark Moon Blog – I first found out about this from reading a GameProducer article about "text-link-ads", and it was nice to see a fellow developer earning some cash from the programme. Jochen recently quit his job to become a full-time indie developer, so wish him luck!
• GameProducer.net – Juuso's blog on game development, which covers most of the areas involved in developing and producing games. Most people will find the indie sales stats of interest, especially those just starting out and wondering "how much can I make?" The site is regularly updated, and the archives have a lot of useful information stored within.

I promise not to write another list post for a while!

What is Blitz.ZipApi?

Blitz.ZipApi is a userlib and set of helper functions for BlitzPlus and Blitz3D that allow you to use ZIP functionality, such as compression and decompression of data. The helper functions take care of the most common operations, such as adding data (either from a file or a bank) to an archive or extracting a file.

Using Blitz.ZipApi, you can compress Blitz banks, read the contents of ZIP files and create your own archives.

For the latest updates to this project, please see the Blitz.ZipApi page.

License

ZlibWapi.dll is released under the zlib license. More information can be found at the Zlib homepage.

The userlib declarations and wrapper functions are free to use and modify without restriction. If you modify the code, please consider letting me know what was changed and why so it can be improved. If you do use this library in a project, I'd appreciate a mention but it isn't required.

Quick Links

Project Home:	http://www.sodaware.net/dev/blitz/libs/blitz.zipapi/
Project Documentation:	http://docs.sodaware.net/blitz.zipapi/
Bug Tracker:	http://bugs.sodaware.net/?project=2

Donations & Support

If you find this library helpful in your projects, please consider donating. Donations of any size are always welcome!

This library has been tested, but some bugs may still be present. If you find any, please submit them to the bug tracker. I can't promise they'll be fixed right away, but I'll do my best to sort out urgent problems.

If you have any comments, please feel free to leave them here. You can also send an email or leave them as a feature request on the bug tracker.

Download

Download Latest Release (1.0) blitz.zipapi-1.0.zip (100.7KB)

It's a none software development related post today. Hurrah!

Over the weekend, I created a new template for my brother's blog, "The Collected Writings of James Newton". I'm rather pleased with how it turned out, especially considering the fact that I'm not much of a designer.

It wasn't exactly how I'd imagined it, but I think I got the overall "feel" of the site right, and that's what matters. Creating a good atmosphere for a blog is important, and something I should probably take into account with my own blogs.

There are a few things about the design that I quite enjoyed:

• Wooden Background – My designs are usually quite clinical, and although it's not real wood, I think it gives the design a more "organic" feel.
• Rich Footer – They're all over the place, but I've never used one in a design before. Now I have. Grabbing random photos from TinyWebGallery was very simple, and they add colour to the site.
• Sidebar – It's not too different from most sidebars, but I still like it. I like the highlighted images in the RSS and article links, and also the "About" section.

If you're interested in video games, writing or a host of other things (including Animal Crossing and Harvest Moon), then hop on over.

The past week has been quite paradoxical. On one hand, I seem to have done more than ever before. I've been getting up at 6:30 and really knuckling down to get some work done. On the other hand, I seem to have worked on everything else except my game. It's not even playable at this point, yet every time I open up the IDE I just stare for a few minutes before wondering what on Earth I should do. It's quite disheartening, and it almost feels like my coding mojo has left me. Not a good sign.

I'm not sure whether it's a proper rut, or if I'm just struggling because nothing fun is happening. It doesn't seem so long since I was able to code up a nifty demo in a few days, and yet I've been at this for several weeks and have virtually nothing to show.

Perhaps I should dye my hair black and write some poetry.

Moaning aside, things are going well in other areas. I'm getting to grips with a few project management applications, which I'll be writing about in the future. I've also been polishing up a few of my libraries so I can release them into the wild. Writing unit tests and documentation aren't the most entertaining tasks on the planet, but someone has to do them.

So what's in store for the next few weeks and months?

I'm cleaning up some of my internal resources so I can release them to the public. They're not exactly earth-shattering, but I find them useful and sharing things is always good. I always imagined this site as somewhere I could share my tools and code, so it's about time I actually started doing it.

I'm also working on some interesting blog topics, including the next article in the "Game Design Lessons" category. I'm also preparing a few surprises in a few months, and I hope you'll stick around to see what they are.

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.