In today's Drawing Board post I want to expand on the ideas I covered in a couple of previous topics: namely Lots and Structures, Procedural Generation, and Services Coverage. Specifically, I'd like to look beyond structures and talk about the other parts of a lot. While buildings might make up the most noticeable features of our urban landscapes, a lack of attention to what constitutes the space between them can thoroughly negate their visual impact, no matter how much care we lavish on their details. But let's not get ahead of ourselves, lest we outrun the Disclaimer:

Continuing on with the project charter, today I want to outline the sections related to voting mechanics. As discussed in several previous articles, the voting is going to be split up into three main areas: general votes, design voting, and leadership voting. There's still a lot that's open to change for these, particularly the exact voting methods used in each section; But we can always amend them later once something basic is in place, and we get a better sense of the overall voting dynamics.

In today's addition to the Drawing Board series (which incidentally, I decided to stop numbering; I have a ton of ideas for these articles, and I think it will get a bit unwieldy to be writing "Drawing Board XXXVII" before every title) I want to look in more detail at a feature which I touched on briefly back in my article about accessibility: a system for creating and editing presets for roads. But rather than just being limited to roads, I think this same system can also be applied to other network types, and even to zones, parks, and any other kind of object in the game. I call this system "option trees", as it mainly consists of a nested series of options (either number values, on/off toggles, or selectable line items.) As I mentioned in the Accessibility article, there is nothing particularly revolutionary about option trees, but they have the potential to add depth and power to the UI while retaining a high ease of use. But before I get started, the Disclaimer:

A complaint that's become increasingly common with new games is that they don't feel "finished". Look around the forums of almost any newly released game and you'll find a post to the effect of "I paid for a complete game, not a beta!" Reviews of "has a lot of potential, but feels like a work in progress" are not uncommon, even for high-profile, big-budget games. While I think part of the blame for this trend lies with publishers who push games out the door too soon and developers who don't spend enough time on testing, it's also an inevitable result of increasing complexity, both in terms of games and of hardware. It's simply impossible for a game to run perfectly on the nearly limitless combinations of hardware and software that make up the PC landscape. Game companies have to make some sort of compromise in order to release a game in a timely manner at a price people are willing to pay. An open source game, on the other hand, is always considered a work in progress. Short release cycles and small iterations foster the feeling that the end product is a continuous process of improvement rather than a monolithic single product. There are bugs, of course, but user tend to be more tolerant of them: they know that bugs are (at least in theory) in their power to fix, without being hostage to the original developer for changes to the code.

Metropolis falls somewhere in between these two cases. The game itself, being open source, will be improving continuously; In a sense it will never be "finished". But the development model we're pursuing, which asks users to fund the game by "buying" shares, also demands that there be a definite release, where a final product is delivered to the "buyers". The question I want to address today is, how do we determine what constitutes an acceptable point for an official release?