"it was always our intent to make an experience accessible to anyone interested in politics and strategy gaming, the game is still free"

If there is anyone who, seriously, can't afford $5, nothing stops you from offering the game to them for free.

But $5 for many people is nothing. People spend $5 a day at Starbucks without even thinking.

And it's not just about making money for you either. An income from the site gives you time to make it better, add additional games worlds, etc. To provide real service to your players.

But you're right, you need some way of differentiating among your players; some have money and some don't. If you try to charge everyone you lose those who don't want to pay, but if you charge no one then you lose the revenue (and the benefits that would come to the site and for your players if you had revenue) that you'd get from the players who could pay.

What about a premium service? Anything nifty you could offer to paying customers, while the basic game remains free?

It all boils down to scaling the game up though, as any form of revenue scales along. But before I can do that, I have to put still a lot of work in the new version, and sometimes I doubt whether it's all worth it.

I haven't tracked the amount of manhours at all. Ten hours a week gives me 2000 over four years, that seems realistic (although a little low considering the amount of code). At market rate that would make the project cost about $100k but of course something is only worth what a buyer would pay.

To answer your question: I'd be a happy camper for a couple hundred each month. Enough to pay for expenses (hosting) and justify a day off from the day job. To spend on projects like this of course.

So how about doing an experiment. The purpose of the experiment is to gather information, without doing any more programming. First explain to your players that you're going to run an experiment: you're looking for ways for the site to be self-supporting so it can continue to grow and meet the needs of its players. The experiment isn't going to affect game play, and that it's just an experiment: you'll take it down if it doesn't work out.

Every business faces the issue price differentiation between customers: some customers have little money and some have a lot, so how do you get the customers with money to pay more without turning away the customers who have little (or, in your case, no money).

For the experiment add a tiered membership: free (what you have now) and patron ($5/month). Both are identical in terms of gameplay (both for fairness and so you don't have to do any programming). By becoming a patron a member has their name listed on the homepage as a patron of Particracy (which is literally true). During new user sign up prominently display the patron option "you can become a patron for $5/month, or join for free". On the homepage above the patron list have a button "Join the Patrons of Particracy".

If anyone signs up, that tells you that there are people eager enough the support the game that they'll give you money even though they don't get any tangible extra features.

Next you might try running a Google ads campaign, max $5 total and max $0.05 per click, using a keyword of "political simulation game". This will deliver 100 people to your landing page. Track how many of the 100 become users (if any) and how many become patrons (if any). This will tell you how easy it will be to draw in new users when you have a way to make money.

Now you look at your conversion rate (is it 0%? 5%? 1%?) and get a sense of what it would take to get to $200/month (40 paying customers). For example, if your conversion rate is 1% then you'd need 4,000 customers to get the 40 paying ones. Then you can look at a) if you want to go for that, or b) do you think that doing things like more programming and adding the premium service you're thinking about might get the conversion rate up.

The point of the experiment isn't for it to make money by itself (though of course it will be nice if it did :), it is to gather information and to give you encouragement.

Now, naturally you may decide not to bail after due reflection, advice, and discussion. And that's OK too.

But as long as you're deciding not to stop because of your previous promises, you're going to be trapped. And, like you say, the trap doesn't end: there's always more work to be done.

What you need to do is in your own mind to put together a bail plan. For example,

In return for breaking your promise to work on the site, you'll:

- give the code to your partner free and clear, and make no claims on any future revenue the site makes

- if your partner finds someone else to work on it, you'll volunteer X hours to help them get up to speed

with the actual details of course specified by your judgment.

I'm not going to advise you to stop or not to stop. However, once you have a plan for stopping, and it's a fair compensation for breaking your promise, then you can stop. And once stopping is on the table as an acceptable option for you, then you can make a logical decision as to whether you want to stop or not.

The study, by itself, doesn't tell us whether hiring low digit ratio traders would be more profitable for a firm, or even if the average lifetime earnings of someone entering the trading profession would be higher for someone with a low digit ratio.

I may not be answering your question since I'm talking about usability instead of more powerful features, but I can't but imagine that there'd be a market for simple and easy to use, even if it turns out it's not going to be addressed by your particular startup...

I have a table, some data that I've laid out in rows and columns. Something simple. How much money I've been paid on my invoices to clients, for example, one invoice per row.

Then I want to sum the column, to get how much I've been paid in total. (Yes, I'm talking about a very simple spreadsheet. But that's my point, that something so simple is still messed up!) So I type in a formula: =sum(C2:C10)

Now I add a row, to put in another entry. Does my sum change, to include the new row? (C2:C11) No, it does not.

So I do not want to be saying sum(C2:C10). I want to say, here is my simple table, and give me the sum of this column. Which, I don't know what the language would look like, but if I named my table "invoices" maybe it would be sum(invoices.C) or sum(invoices.amount) or something.

Every time someone comes out with a new spreadsheet (Excel, OpenOffice, Google Docs...) I look to see if it is easier to use. Nope! Everyone is too busy being compatible with the last guy.

I'm assuming that (in terms of your example) the invoice amounts that you're adding up would form a contiguous range of numbers, and that this range would be bounded by whitespace. That is, you might have some other range that used column C -- say "expenses" -- but it would be lower down, say starting at C15, and there would be at least one blank cell between the two. Is that correct? If it weren't for that lower range, you could just take the sum of the whole column and you'd be good. But it's too inconvenient (and not the "spreadsheet way") to force everything into separate columns.

If the above is correct, how would you feel about being able to define a range with a notation like this: "C2:C✱", meaning "the range of cells that starts at C2 and goes down until it hits whitespace"? Then as you add numbers to C11, C12, etc., the range would automatically expand to include them. But you'd still have to be careful to ensure there was a "moat" of whitespace around your invoice range. If you filled in the last non-whitespace cell before your other table, you'd now have connected the two tables in such a way that "C2:C✱" would leap down to the end of the second table. In other words you'd be lumping "invoices" together with "expenses" which is probably incorrect.

For your data C2:C10 - Do a field: sum(C2:C11) Then when you want to add more data - right-click on the row (11) and "insert" That will update your sum calculation.

Also - you can do named fields - so that if you select the fields C2:C11 - then you can name them as "invoices" (in excel 2003 it's in the top left corner - there's a selection box you can type in. Just select and type a name in there). The lets you do the command sum(invoices)

Also - don't forget you can do something like sum(C:C) which will just give you everything in C column..

I.e. leave a blank row at the bottom of my table, and have the sum include that blank row? I actually know about that trick (thanks :)... what I want is a spreadsheet that does what I want without my tricking it.

With the list builder you are always given an extra row at the bottom to continue adding to the list. Any formulas below the list builder will be pushed down and expanded.

The list builder also turns on Auto Filters for the list as well.

You can do what you're wanting with dynamic named ranges.

From reading some of your other responses it seems like you don't want to sum the entire row, maybe because you have the sum listed at the bottom of the dataset or something. With a dynamic named range you can add rows to the bottom of the range, and you also get a nice name to reference it by. It works by using offset and count/counta to deliver a range based on how many occupied cells there are (depending on if you use count or counta).

There are a few ways of doing it listed here: http://www.ozgrid.com/Excel/DynamicRanges.htm

In my experience you can do an incredible amount of things in Excel before you even break into doing stuff in VBA. You just have to look at any of the numerous resources out there that have tricky formulas available.

When I said, "I'm frustrated every single time I use a spreadsheet", it's not that I can't do whatever it is that I need to get done, I just get annoyed when products are made hard to use when they don't have to be. It's not so much a personal frustration as that I've spent a lot of time at non-profits helping non-computer people use computers, and it's a huge waste of their time and of my time to have to train them how to manipulate the software to get what they want instead of the software just doing it.

C2:C11 was a tremendous advance in 1979 when personal computers had 48K of memory and 40x25 character screens, but goodness gracious, it's thirty years later!

Making something easier to use is a tremendous amount of hard work, but it isn't conceptually all that hard to understand: you look at what people are doing, and you write software to implement that, instead of making them manipulate the software to do the implementation themselves.

I haven't looked at it myself so I don't know if Apple got it right or not, but from Timothee's comment that "Numbers actually manages tables as independent objects of a page", it sounds like they're at least trying.

On the other hand, having defined tables with in a workbook is great idea, but it makes the whole application a wee bit more complicated. I'd like to see it in something of a hybrid between Access and Excel, where you can mix structured and tabular data.

The formula should describe the calculation I want performed and it should continue to work even when I enter new data. For example, if I have a "defined table" as you say, I should be able to ask it for a sum of a column in the table, and have it continue to work even if I add new data to the table, with hacks or trickery or invoking obscure commands.

Of course, it's not perfect if you look at the proprietary format, at the smaller number of formulas than Excel, and so on. But it's a nice piece of software as far as I'm concerned.

It's a moot point since you don't have a Mac but from what you describe, Numbers does what you're missing.

I saw in one of your later comments that you were also talking about multiple tables on the same page. Numbers actually manages tables as independent objects of a page. So, in a table you can ask for the sum of a whole column without getting the numbers from another unrelated table on the same page. That's something that always bothered me in Excel.

if you use insert row - then formulas respond and will go from C2:C10 to C2:C11 (tested in excel2003 at least)