Blogging as a Development Tool

January 6, 2009

bloggingDevelopment.jpg

As a designer and developer with a day job, I find it very difficult to find the time to sit down and really get my hands dirty with projects.

I have had several ideas come through my head that I would have loved to build and design, but ultimately, the time didn’t permit it.

I was determined to try something new, so I took a recent project idea I had, which was to create a Flex-based role-playing game engine. The engine was designed to be similar to the old Ultima games of the 90s (specifically Ultima V), using tile-based graphics, simple controls and UIs.Now with any game engine, there are tons of factors to consider. How does the engine display the game map, manage character inventories, process world events, facilitate conversations and commerce, manage battles and random events? All of these are pieces of the larger puzzle.

I have built prototypes of the engine in the past; however, it was sloppy code, I was trying to put everything into it and ultimately it looked cool, but I would get pulled away and wouldn’t feel that I had enough time to put any serious effort into it.

Months later I would pick it back up and I wouldn’t understand what I had written — It had been too long and the code wasn’t what it should have been. So I would give up and abandon it, just to repeat the cycle again when the motivation stuck me.

The most recent time this happened, I stopped myself and asked, “What are the main issues that prevent me from doing anything?”

Here were the answers:

  • I don’t have time to build out large pieces of the project. I feel I have to get the larger pieces completely done in order to keep my momentum going.
  • I sometimes work from different computers and locations.
  • I want to document what my ideas are and what I ultimately make, but have no way to do that consistently.
  • I have ideas for the project, often when I’m away from my computer, but have no way of capturing them.

Ultimately what I decided to do was create a private development blog. I use WordPress for most of my blogs and use the WordPress iPhone application and MarsEdit to publish my posts. So now the question was how to use it to document my project.

There are two main things that I needed to capture. The first is that I tend to think in modules, components or classes. I’ll have a Map class, a Character class, or a MapTile class, each of which I iterate funtionality over time. The second is how I am able to represent relationships or concepts that need to be captured between components and classes. For example, how do I track changes to the maps when the player moves items or alters them in some way.

What I decided to do was create two main categories: “Development Notes” and “Specifications”. I would then create posts in either of these categories for individual components, classes or for more general items that I wanted to document and remember later.

For the classes, I would create a unique post for each iteration of the class. So, for my game, I could make a MapTile Revision 1 post. I would write a short paragraph about what that iteration of it would do and outline any use cases, or other items that I would want to remember when it came to code. If it has any data schemas associated with it, I would represent it using unordered lists and any pseudo-code or real code I would format using the many code formatting extensions for WordPress.

When I was done, I would have a single post that would contain what that iteration of the item would do, how I thought I would make it and I could refer back to it later.

When it did come time to code the component, I could refer to the post, and any changes that were required, I would post as comments to the original item, showing the change from the original specification. When I was finished developing the item, I would add a new category association of “Completed” to the post and then it would get filed away there.

Now, when I began the next iteration, I would have a complete record of the development effort and changes that happened version over version and I could plan and build each component. I could also quickly find various items that are associated with it using the tag cloud, or use additional categories or tags to classify posts within application functions or modules.

It is a simple system, and one that I am refining as I go, but it is proving helpful, even for a team of 1. For a larger team, I could see it as a great way to communicate. Team members that are building or designing components could subscribe to specific tags or categories to keep apprised of changes or updates from other team members. It does add some work to the process, but I have found with this, I am able to avoid a lot of throwaway work and can keep on track, even when life calls me away.

Share this:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • PDF
  • StumbleUpon
  • Technorati
  • Tumblr
  • Twitter
  • email
  • FriendFeed
  • LinkedIn
  • Live
  • Reddit
  • Slashdot
  • Suggest to Techmeme via Twitter

{ 2 comments… read them below or add one }

greg January 6, 2009 at 7:17 pm

Interesting concept, I think I’m going to give it a try too. I’ll let you know how it goes.

David Wilhelm January 6, 2009 at 7:40 pm

I like this idea.. great way to generate documentation for self and/ or others. Problem is I’d be too lazy to do it … unless it was integrated into my workflow. Say if when you commited to version control, the commit message became the title of a blog post which popped up in an editor window and then got posted to the blog. Actually wouldn’t be hard for me to do this as I use vim, and a plugin (blog.vim) to post to my blog. So I can just create a command to commit to git (say) and then call the BlogNew command to kick off a new blog post.

Leave a Comment

Previous post:

Next post: