We will design the game while we work on it, step-by-step.  The initial decision involves the question of the shape of the world the games takes play in.  What kind of map do we want to have?

After some thought, two fundamental design decisions were made today:

1. “Luck” will be systematized, thus we can have individual games with “more luck”  or  ”tough luck”.
2. The map will be the most basic one: squares.  No coastlines, no pseudo 3D views, no nothing.

More on the second decision:

• The birds-eye view from Civilization and it’s 4rth reincarnation gives something to the feel the isometric view from Civ2 and many RTS lack. I want to have that in my game.
• In Sim City 2000 you had a little map in the corner of the screen, showing the neighboring cities, each city in it’s square.  I always wondered: is Sim City land a giant sheet of math paper with a city in each rectangle?  Let’s get this in.
• The lines on maps always fascinated me.

With the basic model of a “math paper” map we can have all this and some more.  So the game will be basically conquering math paper, very abstract, very dry.  But I believe this has its own potential as a basis to generate an ultimately fascinating view onto a “kingdom”.

• The thing is this: in Risk, you have one dimension of squares: the countries.  And than you have neighboring countries.  So from a complexity standpoint, “math paper map” is similar to the World Map from Risk the difference being that the number of neighboring countries per countries varies in Risk, were on math paper map it stays the same.

• Isaac Newton Organizer
• OrgMode
• DevTodo
• Remind
• todo.txt

• Isaac Newton Organizer
• OrgMode
• DevTodo
• Remind
• todo.txt

Very similar to the idea of calling people Taylor if they were tailors and Smyth if they were blacksmiths.

So if you have a structure with certain properties, instead of giving it some arbitrary name and then having everybody learn the association between the name and the properties, you use the properties themselves as the name. This method has a lot of advantages. First, it’s very easy to create a name–as you think of the properties, you write them down and immediately have the name. Second, it is very understandable, because as you read something you learn a lot about the properties from the name. As these properties get more and more numerous, it becomes difficult to describe them concisely.

Something like this for the data files would be cool. Things I’ve seen so far deal with metadata like dates and authorship. Putting metadata into file names is a bad idea. But done anyway. Maybe I can hack the file name extensions somehow? Let’s see.

• patching my whole software library to not use the home folder (too much work)
• getting disturbed by the apple-folders an dot-files
• vendor lock-in by relaying too heavy on spotlight specific features or meta-data to find things

the whole scheme should make some sense. sorting computer files by media type (i.e. images, movies) is complete without merit. it’s the same mindset that encodes web pages in ascii.

• sorting plainly by project sounds good, except it is not scaleable (the list will get too long someday)