Feasibility: passed, with reservations.

I normally do this with any project I find myself ruminating over: the Sanity Check (or more formally, "feasibility study", though I do call it a "sanity check" or "reality check" in case I'm being unrealistic, and just rationalizing an overactive imagination!). Before I go in feet first, I usually wait a few days after the initial desire to make something of an idea. Now is that time.

Did we pass?

In short, I think this passes the sanity check, with reservations. I'll need to remain focused, otherwise I'll be lost in irrelevant detail.

Why do most ideas need a sanity check?

So often on project forums, and for especially sandbox games, you see people with what seems a good idea for the game. They might open up exciting possibilities, but far too often they fail the sanity check. Just as a fiction author has to ensure that all the words are relevant to the story, so must a game designer think carefully before adding irrelevant details. It's very easy to write a two-line specification! Often the implementation will be several orders of magnitude more difficult to write.

Some issues that might lead this project to fail a sanity test:

1. There are already lots of similar projects out there, and this might prove to be a waste of time, unless this project is uniquely successful in some way.
2. This project is mainly driven by the development of technology. This could be a problem, because the resulting game should be compelling because of its benefits, rather than its features.
3. Will it be fun? (stealing a quote from Dwarf Forge material). I believe it will be, but mechanics and background technology alone do not create a game; other aspects must be designed in.
4. Is it likely to be completed? I don't know the answer to this question, and leave it open as a possible cause to close the project. Related to this is the amount of time I can realistically allocate to the project (not much).
5. Writing too much about the project, and not doing enough for the project [hint to self: like now!].
6. Lack of good research. Am I just reinventing a broken wheel?
7. A more successful project elsewhere. Someone might run with my ideas, but it won't stop my interest in this project (see below).

This Blog: Careless Bean-Spilling?

Also included in the sanity check is this blog! I'm aware that if I develop something that's commercially viable, and I've spilled all my intellectual property beans, then I'll have lost out on a good opportunity, and the cash will flow to someone else (after lots of hard work, of course). My reasons for writing this blog are various, but my main hope is that it will keep me focused on essentials, because I'll have to think carefully about how to describe new material (which should help cover all the eventualities when I imagine what pedantic readers might raise as faults), and there is also the possibility that committing this to a public blog will encourage me to continue at a reasonable pace, hopefully without making me a slave of the project. Writing about problems might give me a eureka moment, and I might even get hints from folk who know a lot more than I do!

Source Code: Open Source?

Related to this is source code. In the early stages, I plan definitely not to release source code. Instead, I'll publish illustrative snippets of code that show what I'm trying to do. Late stages: I'm undecided.

I should add that this blog and project are not about planting seeds to make money towards the end; I'm here because I find this interesting to me, and think there's a possibility that others might share my interest. By saying that, I'm not saying that a successful project won't then be commercially viable - I estimate the chances of that happening are slim - just that I'm not starting this as a business venture.

Summary

I think I have the checks and balances in place. My expectations are fairly realistic, and I'm confident that, given enough time, my methods will work, and we can reach a point where we have a fun and playable game. This passes the sanity check.

Next!

We'll describe abstraction, and how it will help us develop a quick prototype, and then allow us to introduce the difficult-to-develop versions that have better functionality. We'll also write about what is to be abstracted, and why.