Changes include:
1) Asteroid belts now include known reserves. The earlier idea of having a single number for this didn't work as prospecting then adds easy finds rather than a mixture of hard and easy, so there are now two sorts of ore: hardrock and easyrock. Prospecting (with sensor factor) finds 75% hardrock and 25% easyrock, but mining (with impulse factor) extracts 75% easyrock and 25% hardrock, with all the obvious implications. No other locations do anything. For demo purposes there are a lot more asteroid belts than normal.
2) There are multiple officers, who have names and skills, so they can get meaningfully better at mining and prospecting at least.
3) There are buttons for radical change of officers' menus, allowing one engineer to take the helm and put in a jump order, and one science officer can take the long range sensors and scan a remote star system. More generally, the principle is that menus select orders and buttons change menus, though all buttons are also "submits" for orders.
4) There's some basic status examples, gained for being the first to visit or scan a system and for getting any easyrock. The ship list on the entry page is sorted by status and it does decay at 10% (rounded up) per turn, so the numbers ought to be bigger. General per-star comments record the first ships to visit and scan the system.
5) There's a report of the previous turn's actions, if any.
6) Scanning remote systems gives a report as if there, but no scope for actions of course.
7) Modules can be maintained but this, like decay, isn't capped to stop reliability going above 100% or below 0%.
===========
There's a new version at http://www.pbm.com:3507/tbg/. Apart from new bugs, the highlights are:
1) Proper movement, with cost related to square of distance and warp factor, and chance of success related to cost and skill at navigating to that star. Beacon stars provide a big skill bonus and show on the jump menu with asterisks. Failed jumps cost money as if they worked.
2) Basic trading appears, with factory prices rising when players buy and colony prices falling when they sell. The starting and upper limit price at a colony is 25 + distance to the factory, so no trivial trade routes. Contraband doesn't behave any differently to other goods yet.
3) Shops arrive, selling non-improvised modules and restocking up to about 10 items.
4) The universe expands, in a small way, to include 3 x 3 regions with the starting area in the middle. Long range scans show far more information about regions than players would really get, and buttons allow the jump and scan menus to be pointed into different regions.
5) Scanning keeps its unlimited range for testing, and sets a permanent record so the player can always check that system again (showing current information, not the more correct historical picture yet). Links to scanned stars appear in the starmap and reports.
6) There are basic data structures for aliens and trade goods, but they don't do anything interesting (linked from main results page).
7) Improvised modules decay each turn by 1% for each improvised module in the ship.
8) Weaponry officers and modules are hidden as they don't do anything yet, medical officers can only do healing (good for aliens' cosmopolitanism and likings, which themselves don't do anything) and - like anyone else - trading. Engineers and Science officers remain good for movement, scanning, mining and prospecting.
9) Under the covers there is fast binary chop lookup on most of the data structures and some cunning to keep data structures cached in memory except when a turn runs asynchronously and changes them.
In all, it's just crossing the line between a UI demo and a toy, it needs some competition before it counts as a game.
=========
There's a new version running at http://www.pbm.com:3507/tbg/
Minor changes include fixes and tidyings for last week's feedback, mainly from Doug and Dave Forrest, and the medium sized change is conversion of the map to full WilliamTech. This made it very tall and thin, so I doubled the width to keep it squarish (at least with my browser/fonts combination), but the general space-distortion of this aspect ratio is more worrying. Scanning via terminals is also disabled for now as I notice it's gone wrong in this version. It's less needed anyway as there's a lot of linking to ships, stars, aliens and trade goods now, and it's obvious from the link URLs how to get access to the data that's not explicitly linked. (This will be restricted one day of course)
The big change is the addition of combat, unusual in at least two ways. One is that it's only fighter strikes, not ship-to-ship, done first both because it's easier/smaller and because there's more novelty to think about in it than ship-to-ship, which will be essentially the TBG-1 combat system.
The other odd thing is that it's mainly a combat simulator, though it does also do actual combat as an afterthought. This works by making the combat engine a separate net service as discussed earlier, so it can be a core component of player-written combat simulators on other servers. Of course the ideal first customer of the engine in its simulator role is the game itself, so the order form can include results of _next_ turn's battle as a prediction.
This works, via the active UI, by allowing inclusion of enemy combat orders in the form, so the player can enter a prediction of what the opponent will do and see the results against their own current orders (when they remember to press a button). From the test and debug point of view this is more useful than actual combat because you can try things much more quickly and without constantly needing replacement ships to practice with. Note that for real combat the aliens don't use any orders, so it's very much biased to letting players survive, or even win, for now.
Combat details:
The fighter strike phase uses just fighters and drones, which are new modules not used in ship-to-ship combat at all (the TBG-1 weapons with these names have been renamed). Drones do more damage but are less flexible, they can only attack-to-damage and do 35 points per tech level. They dogfight at -1 tech level when being intercepted and have no scouting ability.
Fighters can do a variety of missions. When attacking to damage like drones they do 25 points per tech level, and when attacking to capture they do 15 points per level. In either case they also do 5 points per level of scouting, and when specifically scouting (as pathfinders, not attacking at all) they do 15 points of scouting per level. Their other alternative is in defence, intercepting one specific incoming fighter or drone each. Interception results should depend on relative modified tech level, but are simplified in this version to always working as a turn-back-attacker and damaging the interceptor if it's lower tech than its target.
Scouting is needed to find the enemy ship at all, the total of all attacking fighters' scouting points is compared with the enemy ship's cloak factor, and the entire attack is cancelled if it's smaller. Various things like favouring and blessing cloaks, whether the defender is hiding, or deploying defensive fighters, and perhaps a big silent-running option, should affect the cloak factor but aren't implemented yet. The temptation to include sensors in the scouting calculation should be resisted, since one aim of this is to bring cloaks into better usefulness balance against sensors.
Damage and capture attacks work with targetting groups. Curiously, this is Doug's overly complicated targetting system that turned out to be right after all. By default there are four groups, and active UI buttons allow this to change down to one or up without limit. Enemy modules are assigned to target groups, and fighter/drone attack missions are assigned to the same groups. Targets within a group are chosen at random, and there's no overflow between groups, so there can be a price to extremely precise targetting.
Shield allocation is more like TBG-1 than the UI might suggest (the old multiple-selection menus don't fit the cleaner modern data structures and always annoyed player scripters, so they're replaced by per-module menus). One difference is that fighter opps and offering gifts are now on the same menus as additional shield allocation. This means it can be especially effective to attack during peace negotiations (for those of the Cylon persuasion) and there is a conflict between using your fighters in action or keeping their "ground" bases relatively safe.
What else? Just the things I've forgotten, maybe they're obvious.
===========
There's a minor code update today (but not a restart, since nesh data structures can change shape while running):
1) Power sorting added. 2) The long and short range scanners are now mounted the same way up, so the star map and region map both have y co-ordinates going the same way. 3) Scanning fixed. 4) Favouring cloaks or shields appears on a tactical menu, and works. 5) Other tactical menu options, and all the new strategic options, don't do anything. 6) There's a per-module "baggage" option, which doesn't do anything but reflects the idea of putting non-combatant modules and cargo into a separate baggage train or saucer section, to make combat factors higher in battle. The big potential disadvantage of doing this is that the winner of a battle gets the enemy baggage as extra loot. 7) Broken modules still count as working for combat, making it quick to develop a powerful ship in testing.
===========
There's a code update today, allowing surprisingly little new activity for its size. It's the first sketch of the very large area of the Federation's government, which I'll cover in multiple threads to avoid overflowing your mail servers.
The idea of scaling up political rules to have a single President plus a governor per region didn't fit into the wider scheme, as relations with aliens and Big External Threats brought military organisation into prominence too. This is because it's OK to have two parallel structures for religion and politics, but having three means they should be integrated into a single consistent hierarchy.
So we go to something like the Mimbari Grey Council, with representatives from religious, warrior and worker castes, or in this case religious, fleet and political representatives. The Government has 11 members, made up of these groups:
Four Prophets, actually the senior prophet of each religion, which is generally the one from the region with the most active players in that religion.
Four Ministers, elected by the colonies of the four skill-types of aliens.
One Homeworld Consul, elected by the homeworlds.
One Fleet Consul, elected by the ships of Starfleet (player and alien), one vote per ship.
One Admiral, elected by the ships of Starfleet, votes weighted by power ratings.
Only aliens in the Federation get a vote of course.
(In the current code this is simplified to elections every turn and all offices being elected entirely by aliens based on who they like most, not on political campaigning at all.)
The government operates on a 9 x 9 board representing religious/political space, shown at http://www.pbm.com:3507/tbg/STATE with a sampling of keywords in each square to hint at the rules. It also uses colours in a speculative way that looks OK on 24 bit displays but a bit wrong in 8 bits: these should change to the standard browser colour set if they turn into a real feature.
This space has several possible classifications, such as good vs bad on the vertical axis and imperial vs republican on the horizontal axis. The government can be thought of as one counter on this board for the official position of the state, which controls many rules, plus one counter per playet showing their own religious/political position. This position affects interaction with aliens for everyone, as well as being of great significance to players in the government.
Each office is constrained in where its holder can be on this board (current code allows anyone to be elected to anything, the candidate list should be filtered by players' political positions). The picture shows Great Old Ones off the edges for clarity, the prophets' actual positions are limited to the row or column on their deity's edge. The Admiral is limited to the left four columns, the Consuls to the middle five and the Ministers to the right four columns.
The business of the government is carried out by making proposals and passing or rejecting them. In the purest form this could be left entirely to the players in free debate, but in practice that gets stuck in various ways, so assume instead that there are many pressures on the government from the trillions of aliens it rules. The effect is that players merely decide how to play the opportunities that come their way, and can't directly do anything when they lack the right opportunity.
Abstract opportunities appear on the board as either proposals or vetoes, in a random location and with a random "range" number. The range is the maximum (d1/taxicab/othogonal) distance to the government's own position for which this opportunity can be used. A player can use such a valid opportunity only when they're on the same row or column as it.
A proposal comes with enough support that it will pass unless someone plays a veto against it on the following turn. Proposals include many types internal or external to the government process, such as moving the government position, calling an election, appointing governors and fleet commanders, awarding triumphs (in the Roman sense) to victorious commanders, and so on. The board is supplied with new opportunities after each election, which comes ten turns after the previous one if not called earlier.
There are, of course, lots of implications to this which I'll leave you to work through.