As some of you know, on the “indie software” side of my portfolio I have The Journal. Originally released in 1996, the same year as my first significant indie game efforts, The Journal has grown along with me.

 

Yesterday I announced the release of The Journal 4. This release marks a significant milestone (to see what’s new in The Journal 4, click here). So many features that I only dreamed of in the first years have now been realized. Only took 8 years.

 

Here is a capsule history of The Journal, presented as an example of how an independent project, with low (or no) initial aspirations, can grow over time.

 

 

The Journal started out as a quick project, mostly as a way to learn how to use Delphi. Fittingly, most of the original users of The Journal were other Delphi programmers who downloaded it from the various “Made in Delphi” web pages. Feedback from these and other users prompted me to extend The Journal significantly, and release it as shareware.

 

(4 Freeware releases, from 1.0 – 1.21)

 

 

v1.30 was the first shareware release of The Journal, made available in October, 1996. This was a period of expanding features for The Journal. Hardly a month went by without a new release coming out with more features–and bug-fixes for previously added features. This was my education in OLE/COM. (shudder) This “growth spurt” period went on for nearly a year before finally slowing down.

 

With the release of The Journal 1.5 in January, 1998, The Journal became a mature software product.

 

(17 1.x releases, from 1.30 – 1.51)

 

 

The Journal 2.0, released in late September, 1998, built on the feature set that had been finalized in the 1.51 release. More word-processing and security features were added, and database maintenance and stability was greatly enhanced. Throughout the 2.x series of releases, The Journal continued to mature, though not at the same pace as before. Refinement and extension replaced a headlong rush to add new features. The 2.4 release of The Journal, coming nearly a year after the previous release, was the most significant of the 2.x updates after 2.0.

 

(11 2.x releases, from 2.0 – 2.43)

 

 

(From November 2001): The Journal 3 is a complete re-design and re-write of The Journal, incorporating years of accumulated feedback and suggestions. Since The Journal was first released in 1996, users have sent in their suggestions for features and extensions. As much as possible, these suggestions were incorporated. But some suggestions were beyond what the original design of The Journal could tolerate. There was only so far that The Journal’s feature set could be stretched without starting over from scratch.

 

Begun in the summer of 1999, development on The Journal 3 proceeded slower than expected. These initial delays were caused by several factors. I was (and still am) co-owner of another software company (Samu Games, http://www.samugames.com) and other projects came up that stalled the development of The Journal 3. Plus there was the ever-present need to support the current version of The Journal. By the end of 1999, only The Journal 3’s new database configuration was completed.

 

In 2000, two major projects with Samu Games prevented significant work on The Journal 3. The Journal 2.3 was released in early 2000, and The Journal 2.4 was begun in the fall of the year. Though the 2.3 release was a relatively straightforward update of The Journal 2.2. The 2.4 release, however, incorporated some of the features that had been designed for The Journal 3. New word processing features (like numbered lists and multi-level undo), improved image handling, and especially the new export/import format were all from work done for The Journal 3.

 

Most of the work on The Journal 3 that occurred during 2000 was on the new user interface. There was a lot of experimentation with new layouts, new configurations, and new ways of representing the categories and entries in the database. Some of it worked, and was kept. A lot of it, though, proved “iffy at best” and was discarded (or turned into a “user preference”, default off).

 

In March 2001, following the release of The Journal 2.4, I realized that I had spent too much time on “research and development”. If I expected to release The Journal 3 in this lifetime, I was going to have to stop thinking up new features to add and experiment with. So the feature set of The Journal 3 was “frozen”, and I began working on getting The Journal 3 done.

 

Interestingly enough, while The Journal 3 already sported quite a few features that The Journal 2.x would never be able to duplicate, The Journal 2.x had many more features that had not yet been implemented in The Journal 3. So to get The Journal 3 “done” I had to get all of the existing 2.x features working in the new version. Everything from simple options like “minimize to system tray” to more complex features like entry templates had yet to be added to The Journal 3.

 

This turned out to be the single largest effort in the development of The Journal 3. The Journal had accumulated quite a few features in its 5+ years, and re-doing them for The Journal 3 proved to take more time than I estimated. In August 2001, 6 months later, the last of the 2.x feature set was finally added to The Journal 3.

 

In September 2001, The Journal 3 was handed over to a small number of volunteers to see how it would stand up. With their help, most of the bugs and issues were found and either fixed or resolved. The last bit of testing and polishing occurred when The Journal 3 “pre-release” was made available in mid-November.

 

The Journal has already grown beyond my original vision for the project. I’m excited to see what new directions the product will head in the future.

 

2004 Afternote: The Journal grew significantly after the initial release of v3.

 

(23 releases of v3, 3.0 – 3.0.0.71)

 

 

August 2004: Though the story of The Journal 4 lacks the drama of The Journal 3’s grueling development period, it’s an important upgrade nonetheless. Built on the foundation created in v3, v4 takes The Journal to new levels of power and ease of use.

 

Work on The Journal 4 began in December 2003, with early efforts centered on switching from using the Windows Rich Text Common Control to the very powerful TRichView components created by Sergey Tkachenko. This was a huge change, both in source code and in philosophy, because The Journal was originally built around the rich text edit, and probably would not have existed except for that feature of Windows 95. After years spent tweaking and cajoling (and cursing) the rich text edit to get it to do things that Microsoft probably never meant for it to do, I suffered a few withdrawals. However, this one change, by itself, made possible a large portion of The Journal 4’s new features, including background images for entries, print preview, tables, and on and on. So I’m past the withdrawals now, and not looking back.

 

With the new entry editor in place, I shifted to adding numerous other features that users have asked for over the years, such as n-depth category nesting, user-created Calendar Charms, and daily/weekly reporting. Beyond user requests, there were other extensions that I wanted to make, such as the ability to install and run The Journal on read-only CDROM’s, that would make The Journal more stable overall and useful in new arenas.

 

By late August 2004, I had implemented the last of the planned additions and on 1 September I handed The Journal 4 over to a small group of testers. There’s nothing like user testing to help smooth out the new interface and add the necessary polish to the new features–and point out the obvious features and extensions you somehow forgot.

 

In conclusion: I’m very proud of how The Journal has grown, and I’m excited to see how the software will grow in the future.

 

-Joe

 

In Part 1 of this article, I talked about what an indie is, and what it means to have the indie mindset.

 

To review:

 

In Part 2, I will present the 3 reasons why today is the best time ever to be an indie, and cover the basics of getting started as an indie.

 

 

As I discuss in my book, The Indie Game Development Survival Guide, there are 3 key reasons why today–now!–is the best time ever to be an independent game developer. These are:

 

 

 

At no time in history have such powerful tools been available for so little money. And never has so much information about how to use those tools been so readily available.

 

From fully integrated development environments to graphic editing software that anyone can use (with a bit of practice); from configurable third-party libraries and components to pre-created graphic and music content; there are many, many resources available at low (or even no) cost. In a number of cases, these tools and resources are the same ones used in big budget retail game titles.

 

There are some tools, like the latest 3D rendering engines from Id Software and Epic Games, or the newest release of 3DStudio Max, that will be out of the reach of the un-funded indie, but there are many possible substitutes you can find on the Web.

 

As I will probably say more than once before this article is through: Don’t focus on what you can’t do. Instead look at what you can do.

 

 

By that I mean: The Web.

 

Do I really need to say more? The Web offers direct access to your potential players and unlimited “shelf space”, with an incredibly low barrier to entry. Creating and maintaining Web sites has become so easy now that even children have them.

 

While distributing and selling your indie project isn’t as simple as “build it, and they will come”, you can still accomplish a lot with a simple, clear Web page and convenient payment options (which are also easy to setup and use).

 

 

Try-before-you-buy marketing has grown past its roots in “shareware” to encompass almost the entire spectrum of software. Just about any commercial software package you can name, from the least expensive value-oriented product to such widely-used professional tools as Adobe Photoshop, is now available in a demonstration version that allows users a chance to “test drive” the product before buying it. Most retail games offer the same option to players.

 

The synergy of this Holy Trinity–cheap tools, easy distribution, and try-before-you-buy marketing–allows you to build your game at low cost, make it available to players, and build a community of players over time completely independent of the publishers and retail stores.

 

 

The first step to being an indie is as simple as deciding to give it a shot, to move past the normal work-to-earn-to-consume lifestyle that is so prevalent today, which was covered in Part 1. Now we will discuss the next steps to becoming a successful indie:

 

 

 

Indies have the same limitations as everyone else: limited time and limited money. There are never more than 24 hours in a day, and even no budget is still a budget that must be adhered to.

 

Since I’m advocating you start your indie career as an adjunct to your current career, time is going to be in as short supply as money. You are, after all, already losing 8-10 hours 5 days a week to your job. And if you have a family and friends, those will all take time, as well. So you will have to accept that the best you will be able to do, at least for the beginning, is 1-4 hours a day (or night).

 

Don’t expect to “find” time. You will have to make time. Some suggestions for freeing up time in your schedule:

 

 

The other big limitation you will have as an indie is insufficient funding. For your first project (at least), any expenses the project incurs will have to be paid for out of your own pocket. The good news is that by basing your project on “sweat equity”, your costs can be kept down. Also, a lack of money makes you be creative about solving production problems, since you can’t just “throw money” at the problem to make it go away. Creativity is always a good thing.

 

Like your time, you will find that you have little or no “extra” money. You will have to adjust your lifestyle to accommodate any costs your project can’t avoid. Here are a few ways you can adjust your lifestyle to make room for some minor project-related expenses:

 

 

Everyone, it seems, has a hobby, into which they invariably sink a lot of time and money. As was said in Part 1, why not support a hobby that has a chance to pay you back? A benefit of thinking of the project as a hobby is that you can avoid the temptation to run yourself into huge debt to see it completed.

 

 

Now that you have accepted your limitations, you need make sure that your choice of indie project fits within those limitations. In particular, you need to consider the following aspects of any project:

 

 

You should pick projects based on technology that you can readily acquire. In your un-funded or hobby-funded state, you will have to position yourself well back from the “cutting edge” of such technologies as 3D rendering, real-time physics, motion capture, and so on. In the same vein, you will want to avoid anything with the word “massive” in the description (e.g., massively multi-player role-playing games).

 

Fortunately, many low-cost alternatives exist for game technology. These may not look as sexy as the latest games, but you may be quite surprised by what is still possible with “yesterday’s technology.” And not all multi-player games need to host 3000 players on distributed servers. It all boils down to looking at what you can do with what you have available, and not wasting time wishing you had something else.

 

Beyond the technology, you also need to choose a project that doesn’t require dozens or hundreds of artists and musicians working full-time over a 2-year period to create the necessary game content. Which, again, means you should avoid any project that includes the word “massive” in it.

 

The easiest way to limit the content your project requires is to keep the game design tightly focused. Reduce your game idea to its essential elements, and focus on those. Again, though, don’t focus on what you can’t do. Look for what you can do that is new and creative.

 

You should start with a small project, one that has a reasonable chance of being completed within 3-6 months while you put in about 10-15 hours per week. Your can pursue larger projects in the future, as you learn how to create games within the independent context–and as earnings from your earlier projects begin to create new options for later projects.

 

 

Artists, or just people with the artist mentality of all-suits-are-evil (e.g., most programmers), shy away from learning business skills like distribution, sales, and marketing. The simple fact of the matter, though, is:

 

 

Though covering these topics in detail is beyond the scope of this article, none of them is particular hard to learn. In summary, these skills concern making your game available (distribution), getting the word out to players that your game is available (marketing), and them convincing them to pay for it (sales). That’s it. Nothing inherently evil in any of them, and all of them vital to any business venture.

 

Just be willing to learn the basics, and to experiment as you go, and will be surprised at what you’re capable of.

 

With a nod to Niké, their old logo is still the best possible advice.

 

 

You won’t know if you can until you try.

 

 

To wrap up, the Indie Alternative offers you a way to break out of the Rat Race.

 

You can live your own life, separate from your job and your boss, working on your own projects, creating your own unique games, without having to starve while living on the streets.

 

Use “corporate welfare” to keep you and yours fed and warm as you leverage inexpensive development tools, a ubiquitous distribution channel, and the power of try-before-you-buy marketing to build your independent future. You will have to start small, but there is no limit to how much you can grow.

 

More than anything else, “independent” is a state of mind. Think about it. Then go do it.

 

I used to go “bouldering” at a nearby park. Demolition (to build a canal, I think) decades ago left a lot of exposed rock face, and during the spring I used to head up there with some buddies to drink beer and climb rocks. (Fortunately, most of the rock faces were only 3-5 meters high, so we weren’t being that reckless. We thought we were pretty clever, climbing with a beer in one hand. Then we met a one-armed man doing the same thing.)

 

There was one spot in the park that proved interesting: a place where two 5-meter cliffs came to within less than than a meter of each other. The distance between them was so small any adult could easily step across without even breaking stride. You had to be aware of the drop, of course, but otherwise it was a quick step and onward.

 

What happened, though, was that people would treat that short open space as almost impassable. Many would never step over it, choosing to remain on the side they were on rather than take the step to the other side. They could see that the gap was incredibly narrow. They would even agree, if asked, that the gap was less than their normal walking stride. But they wouldn’t step over it.

 

To be fair, the first time I came to it, I paused to consider it too. I think anyone would. A 5-meter  drop down a rough stone cliff, to land on more rock, is definitely a cost of failure that should be considered. But how many times a day or week do we walk along a busy street, often less than a meter away from vehicles hurtling along at speeds that would be fatal if they hit us? That’s another situation where a single misstep could put you in a lot of danger, and yet most people never even think about it. Why? Familiarity? Obliviousness? A mix of both? Once I actually stepped across that gap, though, like everyone else who would just take the step, from then on I could take it at a run. Just pay attention to where you are, and take it in stride.

 

One obvious lesson is that some people just don’t like risk, and avoid it when the perceived cost of failure is just too high–even if the real *chance* of failure is miniscule. They only see what *could* go wrong, and they let that stop them.

 

Another lesson is that I could never get anyone to take that step who didn’t want to. They had to decide for themselves.

 

But that never stopped me from trying to point out how safe and easy the whole thing was, and how little risk there really was.

 

I’m stubborn, I guess, and yet optimistic. I really do believe that anyone can achieve whatever they want. But *they* have to believe it too.

 

-Joe

 

He details 4 mistakes that I think all indies have made at one point or another:

 

Mistake 1 – Making technology, rather than a game.

Mistake 2 – Not being clear about what you’re trying to make.

Mistake 3 – Making a game you are already playing.

Mistake 4 – Not being sure your game is fun before going too far.

 

Check it out.

 

-Joe

 

 

What do I mean when I say “indie”?

 

While there is a certain esprit de l’indépendance conjured up in my mind when I hear and use the term, for the most part all “indie” means is: self-funded.

 

That’s it. You pony up the money (if you have it) and effort (welcome to “sweat equity”) to make your project, you get to call yourself an indie.

 

An exception I’m willing to grant is for those clever souls who manage to get someone else to fund their project while retaining full control of it. It does happen, and it’s a trick I’d love to learn.

 

 

Note that this definition differs from the game development industry’s definition of “independent game developer”. To the industry, so long as you’re not owned or employed by one of the publishers, you’re “independent”. I think most media industries have a similar definition: if the studio/label/publisher doesn’t own you (yet), you’re “independent”. Even though in most cases those “independents” are quite dependent on them for funding–and even for permission to proceed (e.g., “waiting on the greenlight”).

 

The Indie Games Festival, held each year as a part of the Game Developer Conference, reflects this industry definition, though with a nod to the self-funded aspect. Check the rules. So long as you aren’t a subsidiary of, and don’t receive funding from, one of the “ineligible publishers” listed, you’re an independent.

 

The IGF’s rules in this regard have led to some interesting cases over the years, where rather well-funded games have been included in the IGF. Since the money came from a company not on the ineligible publishers list, the projects were deemed independent. Usually, though, only the struggling indies (or their advocates) complain about this perceived inequity. The industry at large doesn’t really comprehend the difference.

 

 

So, if you make a game on your dime (or the collected dimes of you and your team), you’re an indie. Even if you license your game to a portal or other, more traditional publisher and make a buttload of money–you’re still an indie.

 

However, as soon as you leverage that success to pitch an idea to a publisher and have them fund the development of that idea, and wait for their permission to work on the project, you’ve just left the ranks of indie-dom. If that’s what you want to do, though, more power to you.

 

Another possibility is to just stop working on your own projects, for whatever reason.

 

That’s about it for losing your indie status.

 

However, there’s nothing stopping you from being both an industry insider and an independent (beyond the occasional contract clause prohibiting it). Hollywood has a number of actors and directors who go back and forth from big-budget studio pictures (to pay the bills) and low-budget indie films (to feed the soul).

 

 

So that’s it. Believe in what you’re doing enough that if someone offered you $10 million to “do whatever you wanted” you would still be doing what you’re doing. Just maybe you’d do it with more gold trim.

 

I like to think that being an indie shows a certain strength of character, a willingness to be responsible for your own life in your own way. It’s easy to become a cog in the corporate machinery. Stepping outside the machine then represents the harder, riskier path. Many people avoid all hints of risk. As an indie, though, you’ve decided to face at least some risk.

 

But don’t let that go to your head. Indies are special, sure. But not that special.

 

-Joe

“I’m curious to see the thoughts of other developers about where the market will be 2-3 years from now. How will the market change/mature? What new opportunities are coming up? What distribution methods and markets are closing?”

You can read the full thread here.

I liked my own response, so I’m preserving it here on Joe Indie.

1964 – The Year That Was is the name of an album released by Tom Lehrer in…you guessed it…1964. The songs on the album satirize the issues of the day: racism, intolerance, the threat of global war, poor education, etc.

What makes it interesting in the context of this thread is that almost every one of the songs, written to make fun of the state of the world in 1964, could be considered relevant today, 40 years later.
(more…)