August, 2006
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.
Related posts:
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 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 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.
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.
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.
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.
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.
Related posts:
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?
Related posts:
There’s an interesting discussion going on at the IndieGamer.com forums about games we designed as kids. I still have the notebook I used to design games in, and although their scope far outweighed my ability, it’s fun to look at them to see how things have changed.
Some of the designs were detailed, spanning pages of documentation, maps and game elements. Others were just paragraphs describing a concept, and usually a pretty unoriginal one at that.
It’s amazing how much confidence a small amount of programming knowledge gave me back then. Copying a listing out of a book made me feel like a king, and my ideas reflected that. These days I’m far more grounded in my approach, which is surprising considering how my abilities have increased.
(Some of these ideas are typed directly from my old ideas book, and I’ve included the mistakes for comic effect.)
The Cream of the Crop
Psycho Bean
Not so much a game idea, as an entire franchise. I can’t take full credit, as it was something my brother cooked up whilst high on sugary “Lemonade Dippers“. It started out as an audio tape recording. Due to my brother’s high pitched voice and the tape recorders “double speed” facility, Psycho Bean was blessed with a voice worthy of Alvin and the Chipmunks.
The story followed a happy bean called “Cutie Bean” that gets struck by lightening and turns into “Psycho Bean”, a ruthless killing machine that destroys all in his path. Other characters included “Granddad Zimmobean” and “Baby Bean”. Complicated stuff.
Psycho Bean’s power came from lemonade dippers, but if he ate too many he would be sick. Levels included such original locales as “Bean Town”, “Bean City” and “Bean Laundry”. The penultimate level took place in the lemonade dipper factory, with a bloody finale in the Lemonade Dipper Burglar’s Hideout.
Like most of the games I designed in my youth, I got as far as designing the sprites. Perhaps I should have been an animator instead.
Unfortunately, Psycho Bean was retired once my brother’s voice broke. It was a cruel reminder of the brevity of youth.
Sonic Blast / Sonic Boom
OK, so now we’re into “Watch out for lawyers” territory. Sonic Boom started out as the sequel to a text adventure I wrote called “Sonic’s Adventure”. Sonic’s Adventure was actually the first game I’d written without any outside help, and the finished result was relatively playable. A sequel, Sonic’s Adventure 2 was started, but lost due to a corrupted disk. Many tears were shed that day.
Like most of my ideas, Sonic Boom started out as a small idea and grew into a mammoth undertaking. I wrote it for the Atari ST, long before I had the Internet, so I drew all the graphics myself. I remember painstakingly copying the Sonic 3 sprite from a sticker album. Tough days.
The game didn’t get particularly far, but it was my first foray into graphics so I was relatively pleased with how things went. There was no scrolling, it had annoying music and I’m not really sure what I intended for it. It had colour cycling though, which made for pretty waterfalls and sparkly gems.
Sonic Blast then mutated into Sonic Boom, which was more of a strategy RPG in the style of Shining Force. There were three different level types; side-scrolling adventure stages, top-down exploration stages and top-down turn-based battles.
Sonic Boom was easily the most playable game I ever wrote for the ST, and although the code was an absolute mess, I got quite far. There were four levels, and I had plans for approximately six chapters (that’s about 36 levels in total).
Another feature was “P-Life”, which was loosely based on NiGHTS’s A-Life. Every time you defeated an enemy, you would collect part of their DNA. This could then be fused with the creatures in a special garden, and you could create interesting hybrids.
As time went by and I switched to a PC, the dream of my own Sonic game lived on. DarkBasic was the first language I tried, and before long I had a terrible model of Sonic sliding around a terrible level. DB didn’t get much further than that.
I still have many folders crammed full of ideas and drawings, and of course I still have the dream. Sadly, most companies frown quite heavily on fan-games, so the journey will have to stop here.
Shining Force Online / Shining Force IV / Shining Force X / Shining Online
As with Sonic Boom, Shining Force Online was inspired by another commercial game – “Shining Force”. Many, many hours were spent playing it, so it seemed only right to devote more hours to creating my own version.
Clearly, I should have spent more time thinking up a decent title for it.
I can’t really take credit for this idea, as it followed the same pattern as most games these days; 1) find a forum about games, 2) tell everyone you’re going to make the best game ever and 3) find people to do it all for you.
My brother and I signed up to help a fellow fan with his Shining Force game, but it quickly became apparent that he had no idea of what he was doing. Thankfully, he had quite a big team and had put all their email addresses in the “To:” line, so we instigated a coup to overthrow his leadership.
We should have realised that some of those emails belonged to his friends, and he quickly found out. I can’t remember exactly how the email exchanges went after that, but I don’t think he was very pleased. First lesson of mutiny: Make sure you’re not the only people that want to rebel.
Once the excitement died down, my brother and I set about writing our own game. I’d already written most of the engine for Sonic Boom, so it was merely a case of adding new graphics and a plot. As you can see from the screenshot above, graphics were something of a challenge at the time. The Atari version even got reviewed in UCM Issue 23, although I think they were a little bit generous with the score.
After migrating to the PC, the game got a new title and a complete facelift. Two PC demos were released, and they generated around 4000 downloads between them. Not bad for a demo.
Other notable achievements include 3000 pieces of hate mail, all from the same guy. Downloading 3000 large emails via dial-up was no fun, especially as the connection liked to die during the process. Still, it was fun to inform his school of his transgression.
The source code also contains a set of quotes to inspire me. Most of them are of the “This game sucks” variety, but there were a few nice ones in there.
I made a lot of good friends whilst making the early demos, and I still keep in touch with them. It would be fair to say that the response to my early work helped me make the decision to become an indie developer. They were good times, and James and I still have piles of paperwork spanning all of our ideas.
Of all the game ideas I want to complete some day, this is right at the top.
The Bottom of the Barrel
Battle Racers
Description: “A racing game where you fight opposing cars or just race”.
That’s about as detailed as it got, apart from the “other details” section which had the following important information: “The car is red, with with [sic] white stripes, the opponents cars are white with black stripe.” With detail like that, it’s hard to understand why I never made it.
Immediate Action
Description: “You have to progress through various missions and achieve various goals”.
Somewhat inspired by Andy McNab’s book of the same title, this was set to be an army game with multiple vehicles, missions and weapons. As you can see from the description I wrote, it was thoroughly planned. From what I remember, designing the game was as complex as looking through books to find pictures of cool weapons and vehicles, and then writing their names down.
All Good Things…
That brings us to the end of our journey through my childhood dreams. Will any of these ideas ever see the light of day? Let’s hope not.
Do you have any ideas from your childhood you’d like to share? What ideas are you proud of, and which ones make you cringe?
Related posts:
Let’s face it, most of what I’ve been working on over the past few weeks has not been particularly exciting. In fact, it’s been downright boring. Unfortunately, game development is not all fast cars and multi-coloured particles. A lot of it is dull, tedious and less exciting than watching a race between paint drying and grass growing.
As if things weren’t bad enough, skipping over the dull bits to work on exciting things will always come back to haunt you. Talk about kicking a man when he’s down.
The Slightly Boring Bits
The blank canvas
It’s more intimidating than boring, but starting out with an empty project is boring in itself. Although there’s the initial rush of starting something new, it’s quickly followed by the realisation of how much work needs to be done. Creating the initial skeleton is a lot of work, and you’ll probably end up rewriting it at least once. That’s something to look forward to.
Setting up tools
It’s easy to waste days, even weeks, on setting up your build environment. Choosing a language, setting up working directories, version control, customising your IDE and creating build scripts are all part of the initial fun. You might even write a set of coding standards if you really want to put yourself off the project before it’s started. Remember to spend at least a page debating over how many spaces a tab should contain.
The Really Boring Bits
Testing
Hopefully most people realise that being a game tester is not the same as playing games for a living. Testing your own game is much worse, because by the time you’re ready to test you’ll be sick of the sight of it. To make matters worse, you have to wade through all your code and fix all the bugs that crop up. It’s bad enough having to test something you hate, but being reminded that you make mistakes (and lots of them) adds insult to injury.
Documentation
Need I say more?
Anything that involves accessing files
Ever been excited when a game reads something from the hard-drive? Thought not. Spare a thought for the soul that coded it.
The “glue”
Games are lots of fun things stuck together by lots of boring bits. Error checking, file manipulation (as mentioned), resource management and all the bits that glue the main components together are all parts of the job you’d rather never see.
It’s fun to watch things fly around the screen, but there’s a lot of work to be done behind the scenes before anything can start flying. It should come as no surprise to realise that coding all of this is no fun at all.
Planning
It’s not much fun.
The Good News
You could have to clean up this kind of thing for a living.
Related posts:
