There are two major computations performed by the battle system. First, space combat is computed. Once this part is over, and provided there are still attacking ships in orbit, computations regarding ground combat are performed. Once these two main chunks have been computed, experience points are attributed.

This posts attempts to explain what the various steps of each computation are and how they work, generally speaking.

This flowchart shows the essential steps of the battle computations. Exit conditions and various internal steps have been omitted for clarity.

Space combat

The first step of space combat is fleet updates. When attacking fleets first start a battle or when fleets join an ongoing battle, they suffer “time dilation” which causes them to be less efficient for some time. This time dilation effect must be decreased over time.

Once fleets’ time dilation strengths have been updated, ships need to undergo various systematic updates: ships that can repair themselves will regain hit points, countermeasures will recover from previous damage absorption, and weapons will charge or cool down. If no weapons are ready to fire, then the space combat computation is over.

If there are weapons ready to fire, the first step is target selection. If a weapon already has a target, there’s a chance it might still select another target – this depends on a fleet’s strategy (for planet-based weapon platforms, there is a fixed, very small probability of target change). If such a change needs to occur, or if the weapon had no target for some other reason, it will seek a target based on the fleet’s (or the planet’s) tactics – basically, it can select targets by size, weaponry or defences, with different priorities. An attacking fleet’s strategy will determine whether the weapon may target the planet’s infrastructure.

Once weapons have selected their targets, they may fire. A computation is performed to determine whether the weapon actually hits, whether the shot may be intercepted and which amount of damage it would cause on a “naked” ship from various variables such as the ship’s experience, current hit points, manoeuvrability… When a weapon fires, there’s also a small chance of a critical hit, which cannot be intercepted and deals twice as much damage.

Depending on strategy settings, some ships may try to intercept shots aimed at other fleets or at the planet. Such an interception depends on how successful the aim was, and on various other factors such as how many hits the intercepting fleet might sustain. A successful intercept will cause the ship that intercepted the shot to take the damage – which is particularly useful to defend planets. No ship can intercept two shots in a single battle update, however.

Once the destination of all shots have been computed, the corresponding damage is inflicted to ships and buildings. Ships may have countermeasures which can sometimes absorb part or totality of the damage. Of course, should a ship or building reach 0 hit points, it is destroyed. In addition, any ships or buildings that provide ground armies will have their army strength reduced accordingly.

Ground combat

Once space combat has been resolved, and provided there are any attacking ships left, the computation of ground combat begins.

First, the ground defence advantage is computed. It is determined by the amount and type of ships supporting ground troupes, by the amount and type of military buildings, and by the population’s happiness.

The support that fleets provide for ground armies may vary depending on a fleet’s current strategy. Fleet strategy also determines whether ships that carry armies should drop the troupes to the planet’s surface or attempt to extract them.

Once the system knows which armies are on the planet, providing there are both attacking and defending armies, ground combat is computed. The damage dealt by either side is mostly determined by the advantage value, although their respective sizes has an influence. Finally, damage is applied to armies (and to the corresponding ships or buildings).

Assigning experience points

After all actual fighting has been computed, experience points are given to ships (buildings will have no XP in milestone 2, but that might change later). The amount of experience points granted to a ship is determined by the damage it inflicted to other ships, by the shots it intercepted, and by the damage the ground armies it carries inflicted.

Next time…

… I will explain the mechanics of space combat more precisely, and how it is affected by fleet tactics and strategies.

In order to make sure that the fleet-related information is complete, the most crucial component is the battle system. It affects a few things on planets, and has far-reaching consequences on the whole ship design and fleet management system.

The most basic types of information handled by the battle system are the definitions of weapons and their countermeasures. The basic principle – three types of weapons vs. three types of countermeasures – has been described many times. This time I needed to come up with the details.

Weapons

In addition to their types, weapons will have four characteristics.

• Base damage is the “standard” amount of damage a weapon deals when it hits. Depending on circumstances, the actual damage may be different.
• Accuracy describes the probability that, in a perfectly neutral environment, the weapon actually hits what it is aimed at.
• Charge time and Cool-down time are delays that occur before and after the weapon is fired.

It is easy to compute the average damage inflicted by a weapon at each tick. This allows weapons of the same level, but of different types, to be relatively different in behaviour without sacrificing game balancing.

For example, one could imagine a beam weapon that fires once every two ticks, with a base damage of 5 and an accuracy of 80%. This weapon would inflict, on average, 2 points of damage every minute. It is easy to create a mass driver with similar results; such a weapon would fire once every 4 minutes, inflicting a base damage of 20 with an accuracy of 40%.

In battles, each weapon fires independently. Weapons on the same ship may have different targets – while this makes no real sense for fighters, it prevents really big ships from concentrating their fire on a potentially much weaker target.

Countermeasures

Just like weapons, countermeasures have a few more characteristics in addition to their type.

• Maximal absorption is the maximal amount of damage that can be absorbed by a countermeasure before it becomes inefficient.
• Efficiency describes the probability that a countermeasure intercepts damage.
• Absorption recovery is the amount of absorption points recovered at each tick after damage absorption.

Balancing for countermeasures is a little more tricky than it is for weapons. I chose to use a (totally artificial) value corresponding to the efficiency multiplied by the amount of minutes a countermeasure would be efficient for if it was absorbing half its maximal capacity at each minute:

Efficiency * Maximal absorption / ( Maximal absorption * 0.5 – Absorption recovery )

Obviously, this means that the recovery should always be lower than half the maximal absorption…

In battles, all countermeasures of the same type act as one single countermeasure on a ship, with an weighted average used as the efficiency and sums for both the maximal absorption and the recovery.

Balancing weapons and countermeasures

No countermeasure can prevent damage indefinitely unless its recovery rate is higher than the damage being inflicted. While this might happen when pitting e.g. a very big ship against a single fighter, it makes it relatively easy to balance weapons and countermeasures of the same level – a weapon’s average damage should be slightly higher than its respective countermeasure’s recovery rate.

Next time…

I am still working on the battle system at the moment. My next post will be about fleet tactics and strategies, as this has been (is?) a major headache.

Beware the build queues

While the build queues have a seemingly infinite capacity that is not limited by the amount of money you have in reserve, they will grind to a halt if you run out of money!
In addition, civilian build queues take priority over military build queues, so if you’re down to 0 bgc, your ships will never be ready in time.

No Hyperspace

Because M1 is mostly a test of the new game engine, some features were removed completely. This includes Hyperspace.
Don’t wait for cruisers! Your fighters will be able to get to the next system without help.

Technologies

Remember: technologies in B6M1 have no direct effects. Instead, they allow you to build new things.
For example, do not expect a population growth increase from implementing Corpse Reanimation; you will have to build Reanimation Centres on your planets.

Happiness

Whenever something affects happiness, its value does not change immediately.
The planet page’s General tab will indicate that the happiness is changing, and give an indication about how much it is changing:

• “+” and “-” after the happiness value indicate that it is increasing or decreasing by less than 10%,
• “++” and “–” indicate that it is increasing or decreasing by more than 10%.

Employment

One of the three factors which influence happiness is employment.
Buildings provide jobs, which your population then man. Keep the jobs / population ratio close to 1 for higher happiness. You may go up to 2, but past that, happiness will degrade really rapidly.

Empire size

The size of your empire has a strong influence over your planets’ happiness.
Happiness will increase until your empire reaches 10 planets. Beyond that, it will start decreasing, reaching 50% at 20 planets and degrading much faster beyond that.

Population growth

As usual, happiness is the main factor controlling population growth. Every 24h in real life, your population increases by ( growth factor * happiness / 100 ).
The growth factor is initially set to 50. However, each Reanimation Centre building constructed on a planet increases the growth factor by 10.

Milestone 1 is definitely not a good game, in that there are no incentives for anyone to actually fight (which was also true of Beta 5, with the exception of corruption which never really worked as anticipated). If the next step had been planet management, as was initially announced, it would have made it even worse, as the relatively heavy Beta 6 rules on this point would have added complexity, but no incentive, and no reason to spend money on anything other than just “breeding planets”.

Milestone 2, reloaded

The (new) second milestone must therefore concentrate on bringing these two elements to the game.

First of all, the new ship design and fleet management system will be added. Ships will be capable of carrying three different types of weaponry (beam weapons, mass drivers and missiles), as well as their countermeasures (shields, armours and point defences, respectively). But since a weapon in space isn’t really much of a viable ship, other parts will be provided – hulls of various sizes and engines. Finally, a “special module”, the drop pod, will allow ground troops to be deployed. A few default designs will be provided, but you will have the option to customise the designs or to create new ones.

Why is this important? Because, by changing the fleet’s configurations, you might gain an advantage on your enemy. For example, if you are at war with someone who uses mass drivers and shields, you might want to construct or refit ships to use heavy armour and missiles. This constant need to adapt will cost money, which should take care of one of the problems mentioned above.

The second problem remains, however. Why would you go fight your neighbour if there is no actual reason to do so? The solution is relatively easy to find. Why are there wars, in the real world? The major reason for that is resources. As a consequence, the resource system which was planned for Milestone 4 will be added in the next release. However, to keep things simple for now, resources will only be found on planets (which will remain the only available map objects for the time being), and won’t come in too many varieties. Most advanced technologies will require resources to be used.

While what we just discussed hopefully took care of both major problems, they introduced new ones.

A consequence of the new fleet system is that the hastily designed, totally unbalanced battle system from Milestone 1 has to go. This is not a bad thing, it’s just worth mentioning.

Many ship parts, many new types of turrets (as they would have to follow the same pattern as ship weapons), mining facilities to extract resources… The line-based research system of Milestone 1 will not be sufficient to handle this. A graph-based research system, similar in structure to Beta 5′s, will be implemented. It will not feature any optional technologies at this point, as this would require some form of technology exchange. In addition, the “research budget” system used in Beta 5 will be replaced with a much simpler system allowing per-technology control.

In addition to the above features, which should introduce major changes to the gameplay, a few minor elements might be added, depending on how much time I have: a new user interface as well as replacements for both internal messages and the “normal” messaging system. The French translation may or may not be included.

Because of my relatively heavy schedule, Milestone 2 will be released sometime between April and June of 2011.

So, what about Milestone 3?

Milestone 3 has become more distant. It will definitely feature the new planet management system (from M2 in the initial post), the new economy and in-system objects (M4). It will also include forums, although its alliance management will remain simplistic – this will allow Beta 5 to finally rest in peace. It might also include the new universe structure, but that is a big “maybe”. A few alien races might be present as well.

Language

A lot of the most critical bugs in Beta 5 were caused by the features of PHP itself. First of all, PHP is not really meant to run something as computation-intensive as an online strategy game. Performance problems definitely ensued – even at this time, it takes at least ~40s to compute a complete hour tick. The other major problem that was encountered is that, well, I am clumsy. I make quite a lot of typos. And PHP is quite forgiving of typos in variable or property names – it will in fact completely ignore them, creating the new variable/property when writing, or returning null when reading… This kind of bug is hard to track down, especially because its consequences can become visible only in completely unrelated parts of the code, and because, when reading such code, your brain tends to “fix” what you’re reading for you. You won’t see that variable named $militart. You will in fact read the perfectly correct $military, because you know that’s what it should be.

Because of this (and also because some choices made by the Zend team with regards to PHP 6 annoyed me, but that is another matter entirely), Beta 6 was to be written in another language… But the question was – which one? There are dozens of candidates out there; in addition, it is often the case that language A is better at doing X than language B, but B is better at doing Y than A.

The criteria I used to guide this choice were performance, clarity, support for UTF-8, easy database integration. C++, C#, Java, Python, PHP 5 and 6 as well as Perl were considered.

Of course, in terms of performance, C++ revealed unbeatable, which is not really surprising. On Linux, the Mono implementation of C# turned out to be a little slower than Java, itself a good 10x slower than C++. Python, both PHP’s and Perl were… well, really much slower than either C# or Java (which is not really surprising either, but… I was still a little disappointed regarding Python). That pretty much sealed their fate. In terms of clarity, support for UTF-8 and database integration, C++ is terrible, which also eliminated it. C# and Java remained. In the end, despite C#’s cleaner typing, Mono’s I/O performance (and therefore database integration performance) is not that good, which led me to choose Java.

General architecture

Beta 5′s code has a major flaw, one that shouldn’t have happened but did anyway. I originally intended to completely separate game code – for example ticks, or the actual action that underlies sending a fleet – from display-related code. However, because Beta 5 was sort of rushed and did not undergo proper design, a lot of the game code ended up being coupled with the display code, which (in addition to the massive amount of delicious JavaScript spaghetti) made it totally unmaintainable. That mistake had to be avoided, especially if other interfaces (IRC bot, smartphones, dedicated client) are to be supported at some point.

The decision that was made for Beta 6 was to write a separate game server, which would run independently of any type of user interface. This server handles commands, background tasks such as game updates (“the things formerly known as ticks”) and returns raw data whenever appropriate. “Clients” which provide user interfaces then connect to the server, allowing players or administrators to interact with the game. At the moment, only two such clients exist – the main web site, and the administration site.

Legacy Worlds software deployment

As this diagram shows, it would be relatively easy to add new “clients”, connected to the game server and providing other types of interfaces.

The game server

Because of the “milestone” development process, the server has to follow one major constraint – it must be easy to replace parts of it. This imposes a component-based design where components are as independent as possible.

A client communicates with the server through a set of classes which represent commands, responses and actual data using a component called the SessionClient. This component has a server counterpart, the SessionManager, which supports different types of sessions with different authentication requirements, states and valid commands through specific components called “session definers”. At the moment (and for the foreseeable future), three such definers exist:

• the external session definer handles commands which can be executed by anyone (for example, requesting the list of supported languages),
• the game session definer manages player sessions, their various states (disabled, banned, active, vacation mode…) and commands,
• finally, the administrative session definer handles commands from the administration interface.

While the session definers (and especially the game session definer) will definitely change in future milestones, the essential component that is the session manager itself is stable by now.

Session definers don’t do much by themselves. With the exception of basic constraints checking, most of the logic is actually implemented in lower layers. The validation and transformation components handle proper validation of the commands’ data, forwarding all of this to the data access layer, and then transforming the results into something which can then be sent back to the session layer.

This lower layer (and, to some extent, the administration session definer) relies extensively on a set of system components. These components are in charge of all operations required for the good operation of the server, but which are not really related to the game logic. They include:

• the ConstantsManager, which caches game “constants” in memory for quick access and allows them to be updated by administrators, notifying components who use them as necessary,
• the Ticker, which executes actions on a regular basis at various frequencies, relying on the ConstantsManager for its master frequency,
• the Logging components allows asynchronous logging from the rest of the code, as well as log clean-up and querying,
• the Internationalisation component caches translations from the database, and handles administrative commands updating these translations,
• the Mailer which fetches internationalised e-mail templates, transforms them, and sends them.

Both the system components and the data access layer can access the database. Access is (with one very small exception) never direct – all read-only operations read from views, while the update operations are implemented through stored procedures.

The diagram below shows the various components or groups of components of the server as well as an arbitrary, unnamed client.

The various components of the Legacy Worlds game server

The components in green are stable – they will not change, with the exception of bug fixes. Yellow components contain mostly stable code, but are still missing some parts which will be added in later milestones (for example, the UserAccount component does not support using contribution credits). Finally, components in red are likely to be completely replaced or heavily modified.

What the diagram does not show is that the database is structured using namespaces, which follow the organisation of the server components quite closely.

Next time, on the B6 blog…

The next (and last) post of this series will tell you all about Milestone 2.

The administrative overview page for a superuser.

Admin Privileges

One of the most important and powerful parts of the new admin system is the privilege structure that it implements. An admin can have any combination of the privilege tags allowing for a very customisable admin team with staff only having access to tools that they require. The privileges are defined by the following tags that can be assigned to any admin account:

• SPAM – The ability to send game-wide messages
• I18N – Manage in game languages/translations
• CNST – Modify game constants
• USER – Manage user accounts
• BANH – Wield the banhammer
• TICK – Pause/start server-side tasks
• NAME – Validation of Empire, Planet and Alliance names
• PREF – Set default account preferences
• LOGS – Browse server logs
• BUGM – Receive automated game error emails
• BUGT – Manage bug reports
• MNTM – Enable/Disable maintenance mode
• SUPER – Superuser. All privileges as well as admin management

Messages & Spam

Admins have a message system almost identical to the in-game messages that all players can use. This system is of course connected to the game allowing players and admins to correspond, with the difference being that the message will appear in red text in the player’s inbox.
The ability to send “spam” (messages that reach all players) is still present, although it is now controlled by the SPAM privilege.

Internationalisation

M1 has a very customisable internationalisation system, letting admins with sufficient privileges to tweak almost every single piece of text a player will see in their Legacy Worlds experience. From the email confirmation during password recovery to the request to join an alliance to the name of battlecruisers, all the text in M1 can be modified from the admin interface.

The administration site's internationalisation menu.

Game Constants

In previous versions of Legacy Worlds, to change aspects of the game such as population growth or the delay before a planet could be renamed would require difficult and possibly dangerous changes directly in the game’s code or in the database. M1 however, introduces constants, a new feature making this job much easier and safer. Throughout the game’s internals, whether it be equations or elsewhere, there are ‘constant’ values affecting all of the game’s calculations and actions. The new admin interface has an easy control panel, with clear descriptions and constraints, where these values can be changed and the game can be significantly customised without even being reset.

An example of a "constant" that can be modified from the administration interface.

User List & Accounts

The user list is fairly self-explanatory in that it provides admins with a list of all user accounts, displaying the email address, current empire name, status and game language. Player accounts can have one of the eight following status’s; unconfirmed, active, on vacation, entering vacation, leaving, disabled, banned and being reactivated. By selecting an individual account from this list, an admin can access more detailed information about this account including the number of official warnings the user has received, a list of all empire names the account has used, vacation and game credits and a log of all session information for that account.

Banhammer

The banhammer is a very important and powerful tool in the administrative arsenal, and as such has several built-in precautions. The banhammer allows an admin with appropriate privileges to request a ban on any user account. Because this is such a strong and potentially permanent action, all bans require approval of at least one other administrator, meaning that any account banned from the game has been done so with the endorsement of at least two administrators. The banhammer keeps logs of all bans and requests (pending, expired and rejected) along with the admin who made the request, the reason(s) for the ban and the date the request was made as well as the date, reason and admin who rejected the request if applicable.

The Banhammer's ban request form.

The Ticker

The ticker is the server process responsible for all time-based actions and updates in the game. Every action in the game (e.g. ships being built, research progressing, population growth, etc…) as well as some out of game activities (e.g. recap emails, ‘instant’ notifications) are controlled by the ticker. In M1 the ticker can be controlled from the admin interface; admins can start and stop any of 14 individual ticker tasks, as well as pause the main ticker thread. If any of the tasks are stopped, they can be scheduled to automatically restart at any given time.

Name Validation

Because Legacy Worlds is a family friendly game, there are fairly tight restrictions on the naming of empires, alliances and planets. To enforce this, every name in the game must be checked and validated by an admin. Of course, names changes are shown in the game before they are validated, but when they are checked if they aren’t acceptable the player who first used the illegal name may get a warning or more severe punishment.

The summary for the name validation interface.

During name validation, there are three options that are available for an admin: validate, reject and send warning and reject, send warning and ban name. The meaning of these are fairly obvious, either allowing a name to be used, or disallowing it, with the last option also telling the game that this name is unacceptable thus automatically preventing it from being used in the future.
When a name is rejected, depending on the type of name, certain actions may take place. If an Alliance name is rejected, the alliance is disbanded, and the player who named that alliance is sent a warning. If a planet name is rejected, the name is set to a random string of characters and the player who named the planet is sent a warning. If an empire name is rejected, the empire is renamed to “Rude Empire XXXXXX” (where XXXXXX is a random string of characters) and the player is sent a warning.

The planet name validation interface.

Logs

M1 incorporates a very detailed set of logs that keep track of every aspect of the game. Each time the server sends a mail, a player logs in/out, you build a fighter, you view your planet list or do anything at all inside the game, it is logged. Even admins signing in and viewing the logs is logged. The logs provide a thorough history of what every player has done and how the game has reacted to that allowing for a useful resource when bug-fixing. Because of the logs’ tendency to become massive, search tools are provided.

An arbitrary slice of server logs.

Bug Tracker

The built-in bug tracker in M1 adds much needed functionality in allowing players to report any bugs and problems they find in the game. The admin side of the bug tracker provides a good interface to control how the bug reports are organised and seen by the public. When a bug is initially filed by a player (or an admin) it awaits admin validation and its visibility is set to private. In the bug tracker control panel, the bug’s status can be controlled and set to “being handled”, “fixed”, “won’t fix” or “not a bug” and its visibility can be either kept hidden or it can be made public, any bug can also be merged with another bug. As well as this admins can comment on the bug to provide detail although these individual comments can be set to either public or private.

The main controls of a bug report's administration form.

Maintenance Mode

Maintenance mode allows administrators to shut off access to the game and pauses all ticks in the case of a server error, upgrade or particularly bad bug. It displays a splash screen informing the user why maintenance mode is active, when it began, when it should be finished and the current server time. When Milestone 1 was first launched there was an error that caused Hotmail to block all emails coming from the game, this is an example of when maintenance mode would be activated.

The game's site with maintenance mode active.

Next time, on the B6 blog…

The next post will describe the game’s software architecture. It will be published on July, the 11th.

The most important thing to know is that actions have no immediate consequences. Instead, everything updates once per minute. The game time, present on all pages, corresponds to the number of updates since the game was started, one “hour” of game time being in fact one update. By default, all durations are expressed using game time, although that can be modified through the preferences.

Empire overview and research

The first page a players sees once he logs on to the game is the empire page, which is split into two pages – an overview of the empire’s current situation, and the research status and management page.

The overview gives, as usual, some statistics about the state of an empire – its planets and fleets as well as its economic situation. The empire’s economic situation consists in three somewhat unrelated part: the empire’s cash reserves, cash flow (income from planets, upkeep from both planets and fleets, over a 24h interval) and current investments (how much money is being poured into constructing new buildings or ships). In addition, information regarding new messages and ongoing battles is available, linking to the appropriate pages.

The empire's overview page

Research in Milestone 1 is extremely simple, re-using the same principles as Beta 4 and earlier versions. There are two “lines” of research – civilian and military. Each line contains three technologies. As time passes, the empire’s planets contribute to research depending on their population, until a technology is discovered. At this point, the technology must be implemented in order to gain access to the new ships or buildings. Technologies do not provide automatic, empire-wide effects – buildings must be constructed.

Research view and management

Planet management

An empire’s planets can be managed using two pages – the empire’s planet list, and the individual page for each planet.

The planet list displays information about all planets in an empire. Since there is a lot of information to display, and because the user interface is not really roomy, tabs allow different types of information to be displayed:

• the “General” tab lists coordinates and population information (population size, happiness level);
• the “Economy” tab lists income, upkeep and profit (or loss);
• the “Production” tab corresponds to the activity of buildings on the planet: military production, which allows ships to be constructed, industrial production, which increases income, and growth increase, which augments the population’s growth rate;
• the “Construction” and “Shipyards” tabs indicate what is being built on the planet, in terms of buildings and ships, respectively;

Shipyards information from the planet list.

• finally, the “Military” tab displays the military situation on all planets.

The planet list's military situation view, including a planet under attack.

The various tabs in the planet list all link to the relevant part of the individual planet management page, with the exception of the military tab (which leads to the battle view if there is an ongoing battle).

The individual planet page consists in three tabs:

• the “General” tab lists various statistics about the planet such as happiness (which changes over time – an indication of the current change is displayed if appropriate), and allows general commands such as renaming or abandoning the planet;

A planet's general information tab, showing statistics, controls, and military situation.

• the “Buildings” tab lists the buildings present on the planet, including details such as the amount of jobs provided and the type of production, and allows the construction or destruction of buildings (which takes time and therefore uses a queue);

A planet's buildings and construction queue.

• the “Shipyards” tab controls the production of ships.

The planet page's shipyards tab controls the production of ships.

Fleets and battles

Once ships are produced by a planet, they enter an initial deployment phase during which they are unavailable. When this deployment finishes, the ship or ships automatically join the biggest fleet present in orbit. As usual, fleets can be moved around, set to attack other planets, merged, split or disbanded. All ships are capable of interstellar travel – there is no Hyperspace in this version. A fleet can be clicked to obtain more details on its current location, status and composition. In the case of moving fleets, a little more information is provided.

The fleets page, showing details about a moving fleet.

A fleet’s speed is determined by its “Orbit-to-Orbit Flight Time” (OOFT), which determines how much time it takes for the fleet to move from one planet to the next. It also determines the speed of interstellar travel.

When attacking fleets are present at a location, a battle begins. Because of the minute-by-minute nature of B6M1, there are no actual battle reports; instead, a battle viewer listing the battle’s current status and all events that affected the battle is provided. The history of past battles remains available at all time.

The battle viewer includes all battle-related information: fleet powers, ships and events.

The rest of the universe – friends and enemies

A very simple alliance system is provided. It works much like Beta 4′s alliances worked – they are basically a set of players, managed by a single leader. All members can see the list of members and planets. In addition, the leader can disband the alliance, kick members, accept or reject pending requests, and transfer leadership to another member. If the current leader leaves the alliance for one reason or another, the alliance is automatically disbanded.

The alliance page, showing the planet list with a planet under attack

The usual enemy list is also included, with the possibility to add either players or whole alliances.

The universe in B6M1 is pretty simple; the rectangular map only contains systems, which all contains 5 planets. The map is basically a grid, on which an empire’s own planets are displayed in green, allied planets in blue, planets belonging to enemy alliances in red, and planets belonging to other alliances in yellow. It can be displayed either in 3×3 mode, which provides a clear view of a small chunk of the universe, or in 5×5 mode, or in 7×7 mode (at which point names become unreadable, but colour-coded information becomes more useful).

Map in 5x5 mode, including all available colour codes.

The map viewer’s defaults may be altered from the account preferences.

Communications

A simple messaging system has been included. Folders are gone, so are internal transmissions. There are only two lists of messages – received and sent. Messages are colour-coded: grey for messages between empires, blue for alliance messages and red for messages to or from administrators. Because there are no rankings, it is possible to list all empires, alliances and administrators when composing a message. Because it was quite easy to do, direct IRC access is provided, using PJIRC (Java is therefore required to use this page).

A list of received messages (no alliance messages there, unfortunately).

This is a new release, a completely new code base, and it will contain bugs. There is no avoiding that. Because there are no forums at this point, and because forums are not the best tool for that anyway, a bug tracker has been included into the game’s interface.

Next time, on the B6 blog…

A post about the administration interface will be published on July, the 9th.

As was said in the initial description, this release is not anything like Beta 6 should be in terms of game or interface. It is meant to be a test of the system’s architecture. As Tim’s preview pointed out, a few things have changed – some in the right direction, some … not.

The release can be found at http://b6m.legacyworlds.com ; it is open for registration as of now. The game itself will start on July, the 15^th.

While the most important new feature in Milestone 1 is the minute-by-minute game updates, quite a few improvements made it into the release. For example, M1 offers customisable e-mail reminders for various types of messages, a better planet overview, an integrated bug tracking system… On the other hand, a great many of Beta 5′s features have been removed (trusted allies, forums, beacons…) or simplified (research management, fleets…) The interface itself is much simpler, relying solely on good old HTML. While the new rules are listed on the game’s site, a short, general introduction will be posted on this blog on Wednesday.

The game, however, is not what Milestone 1 is about. There is absolutely no code shared between Beta 5 and this new release (with the exception of some parts of the interface, obviously). It is a complete rewrite, in a different language, using a different architecture, which will be described in a later post.

The new version was designed from the start with ease of administration in mind (which was really not the case with Beta 5): it can support administrators with various sets of privileges, and most of the system can be affected through the administration interface. Because this is an important part of the work that was done here, and because most of you are unlikely to ever see this interface, there will be a post here on the subject.

Last but not least, reaching Milestone 1 means that… well, work will start on Milestone 2. However, because I do not have much time for it, it will be released in quite a while – a consequence of that being that it should include more features than originally indicated. Another, more important consequence is that Milestone 2 will actually be what was announced as Milestone 3, in order to make the game a little more interesting. Of course, expect yet another post on the matter.

In the meantime, enjoy M1!

It would appear that the schedule I gave for milestones was a bit too enthusiastic.

As you know, LWB6 is a complete rewrite of the game. In a different language. And therefore, using different libraries, some of them chosen completely at “random” (that is, based purely on API cleanliness).

Two weeks ago I noticed that, despite the fact that everything I had actually worked, I was having major performance problems. This prompted a rewrite of 75% of the code I already had.

I have rewritten most of the code already, but it is not really “clean” code, needs additional testing, and more commenting. In addition, some parts which used to work no longer do.

In addition to the above, I am currently (1) working on a government-funded contract, (2) trying to turn my job experience into a diploma and (3) buying a house. While all of these are important (to me, anyway), I’m afraid they aren’t compatible with heavy LWB6 development work.

Because I want to make sure that B6 development starts on a clean basis, Milestone 1 is delayed until July, the 15th. In addition, other milestone releases will also be delayed – probably with a 6-month release interval, but I need to think about it some more. I will post the new schedule when M1 is released.

Please accept my most sincere apologies.

Will there be contribution credits in Beta 6?

Obviously, yes, or I would not be posting about them. However, they will not be used simply by viewing the pages as they were in Beta 5.

So what are Beta 6 contribution credits used for?

Generally speaking, there are two types of uses for contribution credits.

• They can be used to buy features. Once bought, such features stay linked to your account permanently.
• They can also be used to subscribe to some features. The subscription model uses some credits every day, with features being disabled if the account runs out of credit.

Can you name a few of these “features” you keep yapping about?

I can’t name all of them because, well, I don’t know them myself, but I can give you a few examples.

In the first category, you will have extra message storage or extra folders, extra slots for ship designs or build queue extensions.

In the second category, you’ll find stuff like disabling in-game ads, creating automatic filters on your messages, access to better planet management tools, and fleet automation (e.g. automatic retreat).

How do people get contribution credits in the first place?

…because obviously you won’t be rating Beta 6 planet pictures. Well, you’ll always have the option to pay for your contribution credits, through PayPal, although new options may be investigated. Bug reports will be another possible source of credits, but I will get back to these in a bit. Two new options will be added: voting on game-rating sites, and bringing new people to the game.

What about milestone releases?

Obviously, new features introduced by a milestone release will never be require contribution credits to be used. However, once a milestone release has been properly tested and the next one is introduced, some features may become subjected to the contribution credits system. Contribution credits will be carried over from a release to the next.

You said something about bug reports?

Oh, yeah, I did. Bug reports will be handled through a specific interface, allowing easy tracking and automated attribution of contribution credits, the amount of which will depend on the severity of the bugs.

Will Beta 5 contribution credits be carried over to Beta 6?

Not until Beta 5 is finally shut down, and they will not be transferred directly but rather after a conversion.

Will it be possible to trade credits?

No. The only thing this would cause is the emergence of a parallel economy.

Will people who don’t want to or can’t pay still be able to enjoy the game?

Voting on all rating sites as often as possible will allow non-paying players to get enough contribution credits to enable most of the game’s subscription-based features. They might have to sacrifice one such feature for a time if they want to activate one of the permanent ones, but they shouldn’t be too annoyed by the whole thing.