The Administrators' Guide to the spreadsheet database version of CK

This is also the Admin controls specification for the online version. These are in YELLOW.

HM The King

AOK-GM (GameMaster)

Baroness Roopatra

AOK-S (Senior Administrator)

The Marquess New Liberty

AOK-K (Administrator)

HG The Bishop

AOK-K (Administrator)

Earl smooth

AOK-K (Administrator)

Lord Luigi

AOK-K (Administrator)

Knight Febo

AOK-K (Administrator)

Use cases

Building Project (construction of a new building, addition/change to an existing one, demolishing)

Sent a Building Project entry spex in the same file with

Character and Lot screen mockups.

All new building, changes to old buildings, demolishing, paving the roads, gardening etc. is systematized to be a Building Project

You need to access CityMap DB tabs:

BUILDING REGISTRY

Add the information on the building here, refer to previous ones as examples.

DETAILED

Draw a most representative floor plan of the building here. Typically ground or 1st floor. Write enough explanations.

OVERVIEW

According to the "density" of the building, color the lot with an appropriate shade of grey. Again, follow the examples.

There is a column "Built" and another one "Paid". If neither is filled, there might be a row in the BUILDING REGISTRY, but it only indicates a planned construction. Do not remove such (or any) rows.

After the building information to the above 3 tabs is fulfilled, you can enter the building year to "Built" column. Then the building exists.

The "Paid" should be done right away or asap. It is done as follows:

In the Character DB you need tabs:

N_STONE

The building cost calculator shows how many stone you need to "actually" pay (50% of what is the total stone amount). Deduct this amount from the

character's current year stone balance in the following way (IMPORTANT - DO EXACTLY AS TOLD, THIS SHEET DOES NOT HAVE A CHECKSUM):

Go to the cell of the builder, current year (last row in that character's column). There is a long formula. Add to the beginning of the formula after the "=" sign

first "-", then the stone amount and then "+" before the formula. When you press Enter, the stone balance should go down by that amount.

If afterwards the character's balance is negative (seen in row 1), then he must buy stone the same year from other characters.

Luigi's stone shop helps, because you can buy the maximum amount (currently 100k) without telling him, just add this amount to the character,

deduct it from Luigi, and make an opposite transfer of moneretos accordingly (moneretos are transferred similarly in the T_MON tab).

T_MON

Now it is the time to bill the Labor cost and the Imports cost, as well as the Architect commission and the Building permit.

The important thing to realize here is that the sums of Labor COST and Imports COST do NOT correspond to the sums that are paid to the

pools (only the sum of them does). This is because, technically Labor is first divided to NPC and PC labor, and both of them are (in varying

percentages) added to Labor POOL and Services POOL. Also since practically always the stone is bought from peasants, this money is

also first divided to PC and NPC, and then both of them go to Labor pool and Services pool, with part of the NPC money also going to the Town,

for the reason that due to high costs of living, many of them live on the countryside and do not return all the money to the economy. (It goes to the town

because it has to go somewhere. The town is also the source from where the tourist income to Services pool comes, so it acts as the foreign trade account.)

Good news is that this division happens automatically, so the only thing you need to do is to add all the money to all the pools as adviced by the

cost calculator, and once it is done, deduct the sum from the builder's account. The Building Permit fee goes to you for doing all these

additions to the databases. Please try to not hurry. Even for me, it easily takes 20-30 minutes to completely record one building. It is faster if you

can have several projects to be recorded at one time. Do them one by one still, to not forget something.

BI work does not need online implementation in this version

Building inspector work

Before recording a Building Project to the DB, it needs to be checked for adherence to the rules. There are several rules that need to be checked:

STRUCTURAL STRENGTH

This concerns that arching is done properly. High Arching support columns need be not violated. Low arching span may not be longer than

4 m (span means the open space with support on both sides. High arching may support low arching. High arching itself need not be supported

except from the 4 corners of it - the walls are not required at all. Low arching may not carry any weight except itself. There are more explanations on

the BUILDING EDITOR and MoneroHouse tabs of this file, also an even better guide is in the making.

ZONING RESTRICTIONS

There may be restrictions concerning leaving passages in the lot, or maximum height, minimum or maximum floor area, and also you may only

build doors and windows to the edge of your lot if there is a road, or if the adjoining land belongs to you, or with the permission of the neighbor.

INTERIOR CONCERNS

We are living the 1400s and all ways of making artificial lighting are really sooty. Therefore each room should have a window if at all possible, to

see even something. What is considered plenty of light, is if the window ratio (window area : floor area) is 1:6 and the windows are not blocked. Also

the direction matters - windows to the north give views, but less light than those to the south. If window area is 1:10 or less, it starts to feel dim.

But most important is to have the windows, Windowless spaces are nearly usable for human living, although the presence of torches, candles (expensive)

and fireplaces is presupposed.

Also the shape of rooms is important. If room length is more than twice the width, it is not optimal for regular

living and gets penalized in the pool payouts. In public areas, the shape of the room is not that big a concern, but the presence of very many

doors and such will eat up the space in restaurants, curtailing their maximum capacity.

The room height standard for NPC apartments is now getting to be 2 m. This is fine for them, but unlikely that PC's would like to live any extended

time in such circumstances. Also what matters is that windows cannot start from floor level (except in special cases at extra cost) and by having

room with h=2 you can only have windows with h=1, leaving the rooms a bit dark (fit for NPC's though). In public buildings such as taverns,

it would be good to have h=4 to give more breathing room. Above this is seldom practical, but can add to the interior sumptuousness, and comes

naturally if High arching is used over a long span. The high arching corner point should always be at least 3 m, to preserve the shape of the room.

A thing to consider is the Grandiosity of doors and staircases. The carpentry costs very little. So if you want to add Grand to the wooden things, it is done

by adding to the corresponding cell. An example is a house with 3 m main door, 4*2 m inner doors, and a staircase that has 3 sqm area. If it is really cheap,

it is possible to reinforce the main door only and leave others at the basic level. A normal building with otherwise

30% luxury would, however, not require anything Grand let alone Opulent. In really grand building where the

doors are big and staircases are under much use, Grand is preferred. Opulent is no more stronger than Grand,

but adds more carvings and effects. Later on, Magnificent level will be added. Opulent is already quite nice with some gold...

Year Change routines (deducting servant wages, adding esteemed buildings money to the Services pool, distributing Labor and Services pools, charging overdraft interest)

At present these are carried out by GM only.

Financial happenings.

Year changes every 0:00 GMT. It moves on by one. No real-time clock is needed at this stage. The following things are done in succession, with no overdraft check in between.

Player servants are billed from their m accounts. This money is divided according to a control which allows a % dividend to be set to every m account.

Currently the % is 70% to the Services pool and 30% to the Town, but this needs to be customizable (by GM only) that the money can go anywhere in any proportion.

Tourism is a fixed sum per year (currently: 30 million m). This is deducted from Town and added to the Services pool. The recipients of the sum need to

be able to customized similarly as with Servants above. The sum can be changed by GM alone.

Labor pool payout means that a set (originally 10%, customizable by GM) percentage of the Labor pool is divided among nearly every character. Therefore it is practical to

store the information of the dividend-% in the Character table. The individual %s are set automatically by level increases but can be customized by admins.

Upon distribution, the money is divided in proportion to the individual %'s and added to the characters' m accounts.

Services pool payout happens in a similar way. The payout% is originally a property of a single business, or room, etc. and they are first collected (manually,

by admins) to a Lot-specific aggregate %. Then since the Lots are owned by one character (or corporation, which are characters), they get added to the

characters who own them. In this proportion, a set % of the pool is divided. The % is originally 10% but can be customized by GM.

After conducting all these operations, a character's m account may be negative. The game should not ever allow the m account to go negative as a result

of any player actions, but in the year-change it may happen. Overdraft interest is immediately charged according to a set rate (currently 1.2%, GM customizable)

and the "Overdraft" warning light (spexed elsewhere) set ON. Overdraft interest is the same for everyone and is credited to HM account.

Bulk money transfer

We need a "bulk money transfer" tool, which allows the admins to enter the message (which gets displayed in every participants' account history - being

able to display the account history is not mandatory yet but the message data needs to be stored)

and then make any number of additions and subtractions to the lines of this tool, which is prepopulated with all the characters, one per line.