Evochron Legacy Development Page
This page will cover new design features as well as possible features. Since the content of this page deals with an unfinished game that (as of this writing, March 2015) hasn't yet even reached the testing phase and largely consists of prototype systems, some features I discuss here may not appear in the final game or may be different than described. There's also a chance the game may not even be finished and released if resources run out or something else occurs to prevent it from being completed.

With these disclaimers said, I'll introduce some of the new game's planned features and options.

It's been an amazing 10 years since the original Evochron was launched in 2005. The new game will be the culmination of my efforts over this period of time and it will continue many of the traditions the original game set a foundation with all those years ago. And in some ways, the new game is even returning to the roots of several core design principles I developed way back in the original game more than a decade ago. This new project began development in late 2011, so it's something I've been working on for going on four years now. The origins of its beginning, purpose of co-developing it alongside the expansion for Evochron Mercenary throughout 2012, and implementation of new graphics capabilities and gameplay options will be discussed on this page and organized in the various category sections below. This certainly isn't an exhaustive list as there are many other changes and improvements planned for the game, both minor and significant. But this page provides a fairly extensive review of what the new game is about as well as how (and why) it is different in several core design elements/principles compared to previous Evochron titles.

Over the course of the last several years since Evochron Mercenary was originally developed (which began development in 2008) and has since been developed further since its release in 2010, I have been carefully compiling, sorting, prioritizing, and prototyping many features and options. Player feedback has played a significant role in this process as well as my goals and interests for where I wanted to take the Evochron concept next. This has resulted in effectively rewriting old code systems as well as writing entirely new code systems from scratch to provide the new game with various new features and options. Even though there has been a major degree of new coding, many of the principles in the new game are similar to the previous game, but the application of those principles can be significantly different. My goal with this page is to try and cover in detail how many of the new systems/options operate and if they relate to an older system or option, how they differ and then provide the player with what they need to know.


Overview of Core Design Goals, Changes, and Additions:
What the game is and what it isn't will, in general, remain true to the original Evochron formula. The game will remain a tightly focused technical flight 'space-sim' with options and gameplay specifically geared toward that objective. As a technical space flight simulation, it will focus on what flying and managing a spacecraft as a lone-wolf pilot might be like in the future. Options for trade, racing, combat, exploration, and crafting will continue to be available. And in many cases, these elements have been greatly expanded as well as offer entirely new options not previously available in earlier games. The new game will continue to focus on various simulation aspects related to ship systems, physics management, weapon systems, flight controls, open space 3D navigation systems, and tactical technologies.

Like its predecessors, the new game won't have characters, required story plot points, social networking attributes, cut scene transitions, or external genre elements. If it doesn't relate to the player being in control and flying their spacecraft nearly 100% of the time they play, it won't likely be in the game. It will continue to be heavily 'sandbox' in its gameplay design approach, letting the player choose their path through the various combat, trade, exploration, and crafting options available. Its planetary systems will also be geared toward the elements of simulation, specifically, physics and flight rather than things like colonization, alien lifeforms, governments/politics, or anything else that generally doesn't relate to the space flight/sim focus of the game. Even activities done inside stations and on the surface of planets will ultimately be linked to effects and benefits applied to the player's ship and their management of it. So you can continue to think of the game as more of a space flight-sim that is focused on the pilot and their skills at flying, combat, navigating, trade, and exploring along with their ability to expand their ship's capabilities in those elements, rather than anything else. Evochron isn't a role playing game or person simulator, its focus is on the elements of piloting spacecraft and the complexities, challenges, and rewards that go along with it. The new game will continue in this tradition.

One of the key changes in the new game is the significant expansion of both the combat and non-combat sides of the gameplay equation. This includes a much larger war zone region between two factions across the middle of the Evochron quadrant. Trade and other peaceful activities have largely been moved to the upper (Federation) and lower (Alliance) systems in the game where conflict is minimal or non-existent (depending on who the player chooses to be allied with when they start a profile). This new structure helps provide a more predictable pattern of behavior where the player can better control what level of conflict, risk, and difficulty they want by traveling to systems with the conditions they prefer at any given time. They can do this with the new real-time changing territory control map that provides the current conflict conditions of various areas in the quadrant. Included with this structure is a more consistent behavior system for AI ships. Their faction affiliation now aligns precisely with their threat level and behavior. This has been implemented, along with the two main faction structure, by player request to help simplify managing the faction affiliations and predicting AI ship behavior. This also helps provide a more relevant structure since the new game has more of a war condition setting.

When I started developing Evochron Mercenary, the newest version of Windows was Vista with a majority of gamers still using XP. Resolutions were typically lower than they are today, so the game was designed to work well at those lower resolutions. In the new game, the graphics have been given a significant increase in detail, not the least of which directly relates to the scale of the game's universe (which will be covered in detail below). 1920X1080 is the target minimum resolution spec, plus the target minimum level of texture and mesh detail is significantly higher than before. Focus will continue to remain with 'flight' elements that include relevant and functional displays and indicators in the cockpit/HUD. So the traditional realistic avionics and visual 'situation awareness' systems will continue to be in the game (many of which have even been expanded/updated), including a horizon ladder, motion direction/drift bars, FPM (Flight Path Marker), galactically aligned compass, multiple contextually useful velocity gauges, gunsight COV data, and a 360-degree 3D and 2D radar with new modes and options.

External environment details will likely continue to lean a little more toward the artistic side of the spectrum rather than being strictly realistic, but efforts have been made to present space with higher detail and more realism... especially in terms of scale and visual detail. So the environment will continue to be designed primarily to facilitate the 'sim' and interactivity objectives. A critical aspect of the game's design will continue to be its relatively seamless environment, which lets the player travel virtually anywhere in the game's universe without cut scenes, loading dialogues, required trade lanes/highways, or jump gate 'doorways'. I consider the ability to travel from open space to the surface of a planet, to an asteroid field, to a nebula cloud, and to a star without such interruptions to be a fundamental core function of the game. Without it, planets and other objects in the universe become inaccessible background wallpaper or at least inconsistent separate 'sharded' parts of the universe. Instead, it's an important goal of mine to provide the player with an environment that they are free to explore without interruption, at their own pace, and using the path they choose. Even if it means parts of the universe are rendered a little more artistically because of everything else the game has to do, it's worth it to me to include this interactive and seamless attribute to the game.

The popular physics and flight control systems will largely remain the same, but will offer higher velocity limits to accommodate the new larger universe scale/size. So you'll continue to have the flexibility that the flight model has provided for many years, whether your preferred approach emphasizes more jousting, arcing flyby's, swirl patterns, bait-n-flips, lead/pure/lag pursuits, or any other number of maneuvering tactics. My goal is to continue to give players plenty of room to develop and improve their flying skillset over time, but still offer new players a basic template they can use to engage in combat. Rookies will still be able to zig zag back and forth in jousting patterns until they expand their skillsets and utilize more control options while veteran pilots will continue to be able to employ more diverse tactics. Plus, players will continue to be able to change their tactics significantly any time they want for situations that call for it. For example, some scenarios might call for a quick joust flyby attack to quickly eliminate a threat before reinforcements arrive while other scenarios might call for a slower and more elaborate series of arc'ed drift attacks to avoid being pinned down in the middle of a hostile swarm. There won't be a lot of significant changes to the physics and flight model systems since they have continually been one of the most popular elements of the game series for a very long time.

As before, there will not be any pre-release purchasing or in-game item shortcut buying. All in-game assets used in gameplay will be available to every player once they buy the game for one low price after it is released. There are no multiple paid tiers of in-game items, ships, weapons, equipment, etc based on who paid what and when... everything the game has to offer will be available to you as soon as you buy it and the only requirements to acquire them are within the game itself, the same gameplay options available to every other player.


A New Evochron Game
Evochron Legacy would be a new game in the series and is a project I have been working on for about 4 years now (2011-2015, probably averaging about 60-70 hours a week and untold amounts of coffee). Very early on, I did consider trying to modify Evochron Mercenary to form a very different mold of a game, but it soon became clear that there were too many functionality changes, too many technological limits, and too many gameplay differences to reasonably apply such things into the existing structure and design of EM. What was required for the new development goals was a major rewrite and restart in a lot of ways. Such a rewrite/restart would introduce several significant negatives to existing EM players if the new gameplay systems replaced the old ones. Trying to remove and overwrite the old game, rather than introducing a new game, would cause several issues to surface and I'll go over some of them below. So instead, I decided to work on and provide a (free) major expansion to Evochron Mercenary (launched in 2012) that had some of the new ideas/options 'back ported' to the older game and also began work on the new project as a stand alone title. Other improvements being developed for the new game were also added to EM later via free updates, so both games would benefit from certain features and options being developed. Such effects and changes were compatible with the existing EM framework and did not fundamentally change the game, its save template, its minimum requirements, its base rules, nor removed anything players had earned. I'd like to continue to do this with EM as long as it remains feasible to do so and based on player requests/interest.

As mentioned, Evochron Legacy is being developed as a new project starting from a new framework, technology level, and gameplay structure. Many of the new design objectives and gameplay 'rules' are fundamentally different than what was developed in Evochron Mercenary. To try and force many such planned systems into EM would require players to give up a lot of what they'd already earned in the original game because they do not exist in the new game or are at least very different and aren't transferable. For example, EM's reputation system doesn't even exist in the new game's planned feature set. It has been entirely replaced with a new and different system, including a different dynamic faction structure for every system region in the game. So earned reputation levels in EM would mean nothing in the new game. Likewise, economy, market, and trade systems are all also planned to be different. The player built singular station system in EM also doesn't exist in the new game's planned feature set and has instead been replaced by an individual station module unit system along with an entirely new and very different build system. The list of planned new and different elements goes on...

In addition to fundamental differences in options and gameplay, there is also the goal of keeping EM running on the systems it does now, rather than rendering the game incompatible, or at least more difficult to play for some players because their systems do not meet the minimum hardware feature set requirements of the new game. For example, it does look like when/if the new game is finished, it will likely require shader model 3.0 minimum, a newer version of DirectX (9Ex) minimum, newer versions of Windows (Vista minimum) a more powerful CPU, more powerful GPU, more memory, and more hard drive space. So rather than remove access or reduce playability to the game players had paid for, however big or small of a group they may be that might be impacted by such changes, it is important to preserve access to them and let them keep what they've earned in the game they paid for and currently enjoy, rather than rendering the game inaccessible to them.

So yes, the new game does have a higher minimum graphics hardware requirement than the previous game having moved up to shader model 3 (from 2) for its minimum baseline. This was necessary to support some of the new graphics/special effects I really wanted to include in the new game (not the least of which being shadows). So the minimum hardware spec required for this game is shader model 3. However, it does not require shader model 4 or 5 level hardware for a minimum since I could still render ships, cockpits, the space environment, and planets the way I wanted/needed to in shader model 3 (which has the much higher instruction limit needed for the game's graphics/effects). This does have the benefit of allowing the game to still be very broadly compatible, even with pretty old hardware, including older laptops that do not have a practical upgrade path. But the move up to shader model 3 also means that the minimum hardware specification requirements for Evochron Legacy are higher than they are for Mercenary, beyond just the higher performance requirements. However, the GPU requirements are still very minimal, supporting most GPU models going back about a decade. So although the game now renders through a newer DirectX and display model (9Ex and WDDM, which I'll go over more below), hardware compatibility will remain very broad, continuing the long standing tradition of my games.

Another change is the move to DirectX 9Ex minimum, rather than DirectX 9.0c. I decided to make this move so the new game can utilize WDDM which provides improved control-alt-delete/screen switching behavior, uses less memory, and may improve performance significantly on some systems. This was additionally important as it was required to also utilize DirectX 11 for potentially implementing an experimental Oculus Rift mode for VR support. I can't say for certain if VR support will become a reality at this point, but I have spent quite a lot of time exploring ways to support the Oculus Rift in the new game. These and related advancements have been extremely difficult to achieve. As many of you know, my games are written in DarkBasic Professional, a kind of script language that helps structure things in a more procedural way at a higher level, generally helping me to keep track of and manage the game's codebase better overall. But most of what goes on within DBPro is of course all C++. And DBPro was not originally designed to operate in WDDM or other newer graphics technologies. So to advance things to the graphics levels I wanted, it required recoding/updating significant parts of the development language itself as well as several additional systems the game depends on, which were also designed for older DX9 technology. I recruited two skilled programmers to help with the effort, Joel Sj�qvist (who single handedly has been developing an entire DirectX 11 graphics engine as a plugin for DBP) and Ron Erickson (who developed the TrackIR interface and has worked on other projects for my games in the past). Joel took on the challenge of migrating the DBP codebase to utilize DX 9Ex while Ron worked on implementing Oculus Rift support. With their help and many months of work, the project has been successful and the new game is now rendering with full WDDM support and has the potential to possibly support Oculus Rift at some point.

The remaining challenges for Oculus support will be whether enough detail and performance is available when rendering out to the OVR to meet the goals I have for how the game looks and works on such a system. But at least from a raw support standpoint, it looks like the game may be able to include an experimental Oculus Rift mode at some point that renders out to a DirectX 11 device in the OVR's direct mode. I then plan on continuing to try and build on the system so that it might become an officially supported option later on. There is a possibility support may be dropped at some point. If changes are made to the Oculus system by its developers as has been done in the past which broke existing support in other games (removal of API support and extended mode for example) or if detail/performance just isn't high enough to support the graphics output and dependencies of the game, then it may not be practical to continue trying to support it. But for now, I plan on continuing to work on trying to include and improve support for the Oculus Rift.


Setting and History of the New Evochron
After nearly four centuries of relative peace among colonized systems, war broke out between the Alliance and Federation over territorial and resource disputes. The war resulted in devastating losses on both sides over the course of about 20 years. The network of trade and commerce that had existed for hundreds of years across the Evochron quadrant was destroyed. Stations were obliterated, colonies wiped out, and fleets were decimated. 1/3 of humanity was destroyed during the war as empires and planets fell. Treaties were never signed and peace never declared, but both sides can no longer afford to fight at the levels they had previously. A perpetual state of conflict now exists with each side controlling roughly half of the quadrant, Federation forces largely holding the upper region and Alliance forces mostly holding the lower region. Disputed territories and regions of conflict remain in the middle part of the quadrant.

Humanity as a whole now finds itself in a state of post-war rebuilding and recovery. There is a lot of space left open for building and expanding on both ends of the quadrant while the constant threat of attacks from both sides continue. There are no longer individual factions within each system, only primary allies for the Federation and Alliance now remain.

The fixed station designs that the pre-war industrial complex had established are now gone, leaving behind new building systems that allow stations to be constructed from 'module' pieces in unique configurations. With the threat of persistent attacks, new technologies were also developed to give stations the option to defend themselves. However, most are largely unfinished, leaving the opportunity for the venturing allied pilot to build on them to restore defensive, trade, economic, and industrial elements. With recession conditions present in the initial state of the game's universe, it will be up to the player to build and expand station and city structures.

Constructor stations were also casualties of the war, so now stations themselves are the resource for custom item building and material processing... and in much greater ways. Virtually any equipment item can now be built in the new engineering lab available in stations, plus a few secret ones.


- Category Quick Links -

The Game's Universe Design
Environment
Planetary Terrain Engine
Multiplayer
Equipment and Weapon Damage
Jump Drives and Autopilot
Engineering Lab
Text
Save Games
Cockpit, UI, HUD, and Menu Selection
Weapon and Equipment Changes and Additions
Territory Control and Faction Wars
Shipyard and Ship Design
Graphics and Special Effects
New Ship Armor Design Parameter
Market, Trade, and Economy
System Requirements and Performance
Combat and Trade AI
New Build and Deploy System
Reputation and Faction System
Startup and Launching
Single Player Fleets
Gameplay
New Quest System
Cargo


The Game's Universe Design:

One of the biggest challenges in writing a new Evochron has been universe scale. A primary objective of the new game is to introduce a scaling system far more massive than what Evochron Mercenary used. The problem with this is the limitation of traditional graphics systems, which tend to start to twitch and chatter as float precision limitations are reached. You may have observed this in some of the games you've played in the past, particularly large environment games. The farther the player goes out from the center of the 'world', the more objects in the game may start to bounce and twitch the closer they are to the player's viewpoint. Developers generally limit this problem by restricting where the player is allowed to travel in the game's environment. You're either warned that you're leaving the area and are then destroyed if you continue, or you are simply boxed in and not allowed to move out beyond a certain point. Such restrictions should obviously never apply in a space-sim where the environment is fully open and fully 3D.

In Evochron Mercenary, the game's universe was structured in a tiled sector format, allowing the player to go anywhere in moderately sized cube sections of space. As the player moved from one sector to the next, the game's environment and object placement systems would shift the universe object content as needed for each new sector location. Although it was pretty complex to design and implement, it worked pretty well. But the total size of each sector was limited to around 10K in every direction from center to limit issues with precision. Increasing precision could only solve the problem farther out, it wasn't a viable option for as big as I wanted to scale the game's universe. So an entirely new system for placement and rendering was needed.

In the new game, I am taking a very different approach. Rather than having everything in the game's universe be dependent on where the player moves in the environment relative to only the sector location, the environment now adapts to where the player moves constantly both in-sector and between sectors. This allows the game's object and graphics systems to render at far greater distances and scales without the dependency on precision limits that the previous systems had. Think of it as a kind of dynamic central-point consistent rendering, the concept being a hybrid mix of the traditional sector layout with a new placement and movement structure for every object in the game. It uses an adaptive relative location setup that works for fixed location objects, static and moving objects, and dynamically placed objects (such as countermeasure flares, weapon shots, explosions, etc). This time, the sector layout system is merely used to preserve the navigation functionality found in the earlier games. It no longer serves solely as a required format to keep rendering within engine precision limits. It's main purpose is to give the player an easy way to quickly gauge their location in the game's universe in an established format that has been a long term staple of Evochron's design for nearly a decade now. The central-point element of the setup is all new to the series and I'll go over some specifics on how it works below.

Rendering everything in a game relative to the player's position as center is nothing new, it's how virtually any 3D game starts by default anyway. But the new Evochron approaches it in some unique ways. The game has to account for both the player's location in a sector as well as how far they move and in what directions. The engine updates the placement of every object in the game, whether it's fixed location dependent or not. For every frame update, the game takes measurements of the player's absolute location, relative location, movement, and orientation. It then generates values for how to move each object in the game's universe, updating them for the new condition of the player's new location and orientation. All physics factors are also taken into a account, so the new game will continue with the full six axis (three rotation and three direction) Newtonian style flight control physics system as well as include gravity and atmospheric factors (both of which have been significantly updated).

One of the biggest challenges during the development of this system was the game's MDTS (multi-directional tracking system). The MDTS depends on a very specific collection of input values in order to calculate a predicted path to auto-aim primary weapons. Much of that system was thrown off by the introduction of the new rendering approach. New offset calculations needed to be developed to adapt the MDTS to the new placement and movement format. I eventually succeeded after a lot of trial and error (and coffee).

Even though this new system is extremely complex and has numerous levels of detail and values to manage, it's all kept nicely in the background. So the player won't have to contend with a bunch of complex new navigation systems, they can simply use the sector and coordinate system they're already familiar with in the earlier Evochron games. The game itself will take care of all of the complexities and functions necessary to present the environment in the background using the traditional navigation console format.

So why was all of this necessary? The short answer is to allow for a much larger game universe and more specifically, to allow for much larger and more realistically sized planets. The planets in the new game can now span the equivalent of up to 5 sectors or more of the original game's scaling system. It's easy to render huge planets as nothing more than untouchable background wallpaper, but that would not be what Evochron has always been about... Evochron has always been about an interactive and accessible universe. So not only are the planets much larger, they retain their accessible functionality, allowing players to descend into their atmospheres and reach their surfaces seamlessly without loading screens or cut scene transitions, to perform various gameplay activities. Not interrupting the player from flying their spacecraft remains a top priority in the new game's design. The new system also allows for 1000% larger sectors themselves, providing a massive sense of scale never before seen in the Evochron series.

To help minimize the impact of increasing the scale of the game's universe so much, jump drives have also received an increase in their range that matches the new scaling. So while they'll still jump the same number of sectors, the distance they cover will now be 10X greater since 1 sector in the new game is equal to 10 sectors in the old game. That means jumping 10 sectors with a Mantis jump drive in the new game is equivalent to jumping 100 sectors in the old game in terms of distance. So if you're familiar with how the old jump drives worked in Mercenary, the transition to the new system should prove pretty easy.


Environment:

The larger scaling provides much larger regions of environmental effects including gravity, atmospheres, planet rings, and nebula clouds. While travel time has increased for such elements, their larger scope provides a greater range of exploration, cover/protection, and effects on the player's ship. Part of the objective of these changes is to provide more places to hide for repairs, add a greater layer of protection for new player-built cities, and for a significantly greater sense of scale to the game's universe as a whole.

In addition to the larger scaling, there are many other new elements to the game's space environment as well. From a distance, nebula clouds in the previous game were generally kind of bland, one color tone structures. In the new game, these clouds have been given a higher fidelity appearance with brighter coloring and a more varied look. These changes have been applied to increase the visual intensity they present, making them more significant visual obstacles the closer the player gets to them. And of course, the original and very popular internal cloud fly-through and lightening effects will still apply.

The backgrounds in the game have also been revised to provide a more detailed look. I hired an artist to create several unique nebula backgrounds specific to various regions within the game's universe. The results provide a more impressive, high detail look, particularly when combined with the new higher detail and more varied background star pattern. The background star pattern is also adjustable for different detail levels to work with low or high resolutions.

Asteroids previously had a static percentage of ore that could be mined specific to the sector they were in. Although the asteroids themselves varied in size and shape somewhat, their contents were generally the same as the other asteroids around them. In the new game, this has been changed to allow each asteroid to contain a unique combination of materials. With the new scanning equipment item, the player will also be able to analyze each asteroid for its contents before mining it, so they can pin down which one has the highest level of a particular ore they may be after.

Planetary ring particles are now no longer static in their locations. They now move around a planet when viewed up close, giving them a more realistic and active look. The content of asteroids is now varied individually so that one asteroid can have a higher ratio of certain materials than others in the same cluster (and new targeting equipment is available so players can scan for those materials before they begin mining). A new environmental event is also possible involving inbound meteors that can hit planets if not intercepted quickly enough.


Planetary Terrain Engine:

I have developed a new planetary terrain engine for the new game. Yes, yet another one :-) Some people enjoy hunting, fishing, or sports in their spare time. I apparently like to write planetary terrain engines.

In terms of planetary terrain, the new game features many new data generation systems and a much higher level of detail to better support the new large relative scaling. The new terrain engine does require significantly more memory than the previous system and this will be reflected in the system requirements.

All planetary terrain data will be managed in memory while the game is running, there is no pre-generated option this time around for good reason. As a test, I did save out the planet details in pre-generated format to gauge just how much data and time would be involved. To my surprise the process took about two hours to compile (on a fast i7 gaming system), generated over 500,000 data files, and used up about 90 GB of hard drive space. The level of detail and data is nearly 50X higher than that of the previous game. So it's really not practical to implement the pre-generated option for this game as it would use up more hard drive space than just about any other game out there, take hours to generate, and offer little in the way of a performance improvement. It's best to leave the data generated in memory in real time while the game is running. This helps to keep a reasonable hard drive footprint and minimize wait times. It also insures that if any changes need to be done to the planetary terrain engine, they can apply immediately in an update without requiring the player to wait another few hours for the files to be updated for such changes after they install a new version.

Other goals for the new planetary engine included being able to fly through more diverse terrain features such as canyons and mountain ridges. Rivers can now include paths that are cut through the terrain surfaces, providing players a way to fly at a low altitude and utilize the terrain for cover if needed. The overall variation in height has also been expanded greatly, thanks in no small part to the larger planet sizes themselves. Mountains can now be significantly taller as well as offering more variety and detail. While there is a baseline of raw heightmap data generated, the game also steps up the detail a level further by dynamically generating additional heightpoints as needed when the player approaches the surface. The game uses a core seed value based on the planet's location within the game's universe to produce a collection of generated values for the additional detail level, which effectively doubles the level of detail at the final stage.

An effect I've wanted to include for a long time is finally being introduced in the new planetary terrain and game engines. Planets like Onyx can now have an emissive lava effect, which allows for glowing orange/red lava to appear in cracks and wide volcanic seas across the surface. The effect is heightmapped, softened at the edges, and visually varied to give the effect a convincing look while still keeping the resource load fairly minimal. The new effect is also flexible enough to provide different colors and patterns, so there may even be a few planets with bio-luminescent or chemically luminescent liquids on their surface in glowing blue hues (or other colors).

Some planets may even have animal life on them. In fact, a player may even be offered an occasional contract to capture some of the local wildlife for scientific research to understand the effects certain planetary environments have on them.


Multiplayer:

Another goal for the new game was to redesign and update the game's multiplayer system. The original system has worked well, but has been significantly limited by the sheer volume of data required to synchronize various details of the game's universe between players. So a big part of the redesign has been to remove certain data sections that have contributed to the limitations and optimize what remains for improved performance.

Evochron Mercenary got to the point where several layers of data sets were being broadcasted and processed by the multiplayer system, including cargo containers, player-built stations, clan territory control stats, deployed objects, and more. So one phase of the development involved optimizing these systems and/or removing unnecessary components of them.

The next stage of development involved rewriting and redesigning the data packet structure. This helped reduce the overall overhead of these packets to a point that saved anywhere from a few dozen to a few hundred bytes of space, significantly reducing the bandwidth required to manage them. I also chose to subdivide the AI/NPC data sections into separate packets, which removed them from being bound to the player data packet structure, freeing up additional space for both sets.

Another element is a dynamic update rate system that throttles the level of data being exchanged based on bandwidth performance. If the server programs (2D or 3D) detect significant delays from multiple clients, the system now throttles the data rate until it can be sustained by the network/connections being used. Gamestate is still carefully kept in check with new higher resolution timers, improved predictive movement systems, and selective data rates based on events. With all of the new systems in place, the server programs can now quickly adapt to changing conditions including bandwidth, client performance, gameplay events, and player proximity. Overall, these improvements have allowed for nearly double the performance of the previous system as measured during testing, allowing for more frequent gamestate updates and smoother movement.

Another major change has been the multiplayer menu itself. For direct IP, the old system required completing several steps in a separate menu system before being able to connect. The listing system also required entering a separate menu, clicking to retrieve the list, then clicking on a server to join. These multi-menu systems worked, but were rather complicated to use having multiple steps needed to access them. So the new system aims to change this by combining everything into one main menu with single click access. The server programs will be the exclusive method to host a multiplayer session and all client multiplayer functions are now accessible directly in the main menu, both for direct IP and the listing system. For direct IP, you simply enter the IP address of the server you want to join (LAN or internet), then click the connect button. That's it, no more required multi-stage menu selections. The game will also remember the last direct IP you connected to, so if you want to join the same direct IP server you played on last time, you can simply click on the Connect button immediately to join. This should be handy for those who play the game over LAN a lot. For the listing system, simply click on the 'Public Server List' button, then select a server to join. Single player launches the same way, all from the same main menu. This helps provide a sense of consistently and unified behavior in the game in addition to simplified selection.

A somewhat requested feature for text chat has also been added. Some players had requested the ability to specify unique colors for the in-game text messaging system, so a color palette has been added to the text option icon to the left and below the message log. This lets the player choose a color for their messages using various shades of blue, green, yellow, and red.


Equipment and Weapon Damage:

One intriguing comment that occasionally surfaced in the feedback I received with previous Evochron games was that ship equipment was too protected. Once acquired, there was little to no risk of losing equipment components installed on the player's ship. This is changing in the new game. Equipment items will no longer be so secure.

In the more 'warfare' conditions of the new game, equipment items and weapons can be destroyed. If your ship sustains sufficient shield and hull damage, its equipment and weapons become vulnerable to destruction once they can no longer be protected. You might lose your shield generator in the middle of a battle, or that fancy Banshee particle cannon, beam weapon, costly missiles, or any other number of installed items. When something is destroyed, a notice will be posted in the message log and event log to let you know and you'll need to find a replacement at your next stop if you survive the battle and escape.

This 'perishable' factor brings about a much more personal risk factor to the game that will undoubtedly lead to more careful and strategic decision making on the player's part about what actions to take or not to take. It also means there will be another potential expense to consider when performing various objectives in the game.


Jump Drives and Autopilot:

Another significant change in the new game involves jump drives. By very strong player request, the space-folding point-to-point 'Fulcrum' jump drives will continue to be used in the game. In the earlier game, their range could be anywhere from one to ten sectors per jump and that will also remain the case with the new game. However, now that sectors are 10X the size they used to be, the distance covered by jump drives will also be 10X greater. There is now a 'cool down' period after each jump that requires the player give the jump drive time to reset itself before performing another jump. The ability to select an exit speed after a jump will remain available in the new game.

The autopilot has also been revised to better support the high speed capabilities of the ship you fly. When you engage the autopilot in the new game, it will scale the IDS velocity factor by up to 9X to minimize travel time between waypoints. This will also help provide an added measure of speed to better contend with the much larger scaling of the new game's universe. The autopilot computer can handle approach speeds effectively as well and will gradually reduce the set velocity as needed so the player doesn't overfly a waypoint. While the system will be pretty accurate, there is some allowance for variation so that entirely perfect tolerances may not always apply. Pilots will still need to watch for obstacles, distances, and environmental conditions that could effect their arrival approach speeds and pose dangers.

The special effects associated with the jump drives has also been improved. Previously, when a capital ship would jump in, it would just 'appear' with a flash of light and then coast to a slow cruising speed. Likewise, when a capital ship would jump away, it would build speed briefly and then just disappear in a flash of light. The new system displays a streaking effect that stretches the visible ship structure up to the flashing light as it comes into view when jumping in. When jumping out, the ship builds speed briefly and then stretches out to a a distant flash of light as it builds up velocity to the speed of light. This provides a much more pronounced and visible effect to the jumping procedure for large ships.


Engineering Lab:

I've wanted to implement a more diverse item construction system in a game of mine for a while and the new Evochron will feature an extensive array of items you can build using a variety of materials, including several new ones specifically added for this system. The plan is for the player to be able to build just about any equipment item in the game as well as a few secret ones that can only be built using this system.

The interface is split into two parts, much like the weapon lab. In the top section, there are three stages of the build process with four individual parts each. The first stage is called the Power Supply Array and consists of a Core with three auxiliary sub-parts. So the first step in building any item is to configure its power supply. The core will generally consist of some form of energy source with other optional energy sources and/or batteries also installed in other sections. You apply the material type and the number of units of that material into each part to define how your item will be put together.

The next stage is the Interface/Control Array and it defines how the power supply will interface with the item itself. There are controller, relay, coupler, and storage parts in this stage. This is where you'll generally need to install things like electronics, memory, and connection materials.

The last stage is the Function Array and this is where you determine what the item will actually do with the components you arranged in the other stages. You can install things like energy emitters and radio transmitters. Then you need to select what material to build the frame out of and finally, what material to use for its casing.

All of the components you can arrange in the engineering lab will have specific design attributes and dependencies that will determine what item can be built. For example, building one item may only be possible if you wrap it in a strong enough casing to handle the heat generated. Players will need to explore assembling various patterns of materials to develop the formulas necessary to build items. As with other design systems in the game, the engineering lab also supports storing designs as templates for building later.

The engineering lab will also let you build a few 'secret' items that can only be constructed using the lab and are not available on the open market. Such items can provide unique shield tuning, energy collection, and agility enhancements.

An important change to the inventory system is the expansion of the hangar storage capacity to 25 bays rather than just 5. This helps provide a much needed increase in the variety of items that can be stored for use with the engineering lab, as well as simply letting the player store more items at each station. This is in addition to the increase in the cargo bay limit of up to 10 slots.

The AI and trade systems have also been updated to allow computer controlled ships to occasionally offer build tips for the engineering lab. When a tip is provided by an AI ship, the details are stored in both the flight log and engineering lab build templates list. If no space is available in the template list, the data will be stored in the flight log only.


Text:

The text system in the new game is very different from the earlier games. I wrote a few custom functions in order to provide a 'bitmap' based text rendering setup that I could use to include very unique image based characters. This required me to literally have to edit -every- single text call in the game's codebase, numerous hundreds of them. It took an entire day to edit the text lines for use in separate functions, but the results have been worth it. I can now apply text effects quickly in a function that then applies to all of the text in the game, far beyond the standard font size, bold, italic, and coloring options. This also means that players will be able to modify the text in the game to a greater extent by simply designing an image file containing the characters they want to use in the desired positions and relative sizes within each character cell. This should also help make translating the game into other languages a bit more flexible by tagging any desired character to a set ascii value using the image option, then putting them together into words and sentences within the game's text files.


Save Games:

The new save game system has a few player requested elements. First, saving now requires the player to be at a location where they can park their ship to avoid a minor fuel penalty for saving in open space. If a player wants to save in open space, they can, but it will require the use of 10 fuel units to engage the cryo-storage and hibernate mode for the ship. The player must also be stationary and not be under attack for the option to save in open space. So this option will be good for important situations where saving in open space is worth the use of a little fuel. Locations players can save without the fuel penalty include trade stations, planet cities, and military carriers.

In addition, players will still have an option to save in open space without a fuel penalty since many of them enjoy deep space exploration where it can take a long time before they might encounter civilization. So to accommodate that option, a new deployable item has been added called a Hangar Station. Hangar Stations include a compartment for parking the ship as well as a cryo storage bunker for the pilot that doesn't consume the ship's fuel reserves. Deep space explorers and builders often have a deploy constructor installed on their ship already, namely for the refueling station. Now they can use the deploy system to also let them save their progress just about anywhere they want in open space. To enable the option, the player will deploy the hangar station, then fly inside it and park next to the central structure. At that point, they can use Alt-F9 to quick save their progress at that location. Next time they spawn, they will appear at the save point and the hangar station will auto-scuttle for them. As an added bonus, players who deploy a hangar station can share it with other players who may not have a deploy constructor, giving them the same opportunity to save their progress in open space. This can be a useful option for players wanting to team up for deep space exploration. Only one player needs to use an equipment slot for the deploy constructor while the others can focus their ship equipment configurations for combat or resource recovery.


Cockpit, UI, HUD, and Menu Selection:

Two all-new cockpits have been developed for the project, one for civilian ships and another for military ships. 3D modeler Norbert Iacob has designed the new models, which look great and fit well with the new game's overall design and style approach. The structure has been changed to accommodate a single mesh with different texture layers for the primary cockpit structure with a secondary structure for the 3 main displays. This will allow for a simplified modding system so players can import their own designs using a mesh for either civilian ships, military ships, or both while either leaving the existing 3 displays in place or also importing a custom mesh to replace that structure as well. And they will also be able to import designs unique to each ship type, both civilian and military.

Selection accessibility has always been a big part of Evochron's UI design. I've always preferred to have more options available on the screen that are only one or two clicks away, rather than having numerous layers of required selection trees, sub-menus, and folding tabs. It makes the menus a bit more crowded and requires some learning to memorize where everything is on a single console screen. But in the end, it results in faster access to many of the most common game options. One aspect that hasn't always aligned with this design objective is the Options menu. From the main menu, entering the key and button configuration menu required 3 clicks (Options > Configure Controls > Configure key/button controls). The new HUD color selection menu was one of several buttons under the video section. And the axis configuration menu was a sub menu from the main Options menu. If you wanted to go from one menu to the other, you'd often have to go back to the main menu, then click through the various stages again to get to the menu you wanted.

So for the new game, I've added a new row of buttons on the bottom of -every- option menu that lets you quickly select any of them in one easy click. So now, if you want to access the key and button mapping menu, it's just two clicks from the main menu. Plus, you can quickly switch back and forth through any of the menus by selecting the button for that menu at the bottom. This helps make selecting axis channels, buttons, and settings faster and much more efficient. Likewise, the in-game console menus also now have buttons at the top of their frames to access other consoles. So you can now access a new console from an open console using the mouse.

The Heads-Up-Display has also been revised with a new 'blue tone' look closer to many of my earlier design styles. The gunsight is now freed from its previous locked condition, allowing it to pan with the rest of the cockpit as the pilot turns their head using one of the pan view modes. It no longer disappears suddenly at a certain angle, but will remain in view until it leaves the screen. The benefits of this rendering change are that the gunsight can now remain in view longer when looking around, point more accurately to the forward directional location it is aligned with, and behave in a more consistent manner with other non-static cockpit display elements. Only the top menu selection buttons, compass, and flight timer will remain in a fixed position projected on the pilot's helmet visor. These upper HUD elements will also now remain visible as the player turns the pilot's head. So if you are using a panning view mode or 3D head tracking, you can still monitor your heading, control/thruster levels, and flight timer while rotating the pilot's head.

There are two new readouts at the top of the HUD that provide visual details on the positions of each flight control and activity of various maneuvering thrusters. On the upper left side, just to the left of the compass, is the 'Control' display and the five bars on this display indicate the level of input from various flight controls. The upper indicator shows the level and direction of pitch and yaw control the pilot is inputting. The lower indicator shows the level and direction of horizontal and vertical pitch control the pilot is inputting. And the horizontal bar on the lower right of the display indicates the level and direction of roll control the pilot is inputting. When the controls are centered, the bars will center themselves in the middle of their respective display fields. On the upper right side, just to the right of the compass is the 'Thruster' display. The upper indicator shows the level and direction of thrust from the forward thruster set. The lower indicator shows the level and direction of thrust from the rear thruster set. And lastly, the horizontal bar on the lower left side of the display indicates the level and direction of the forward and reverse thrusters, including main engine output.

The gunsight for HUD mode 2 has also been expanded to show more information about the ship's velocity. Previously, the horizontal and vertical velocity gauges were only above the radar on the middle cockpit display. Those readouts have been moved to the ship status display on the left (labeled VVL for Vertical Velocity Level and HVL for Horizontal Velocity Level), so now all ship status readouts are on the left display and the middle display is solely the 3D radar (with readouts for its new features/options). Horizontal and vertical velocity readouts have also been added to the left and right sides of the gunsight in HUD mode 2 as well as a total velocity readout at the bottom. Having these readouts included on the gunsight now makes it easier to distinguish your ship's directional velocities at a glance without having to look down at the cockpit display in the middle of a combat situation or complex maneuver.

The motion spears have been removed and replaced by a series of patterned lines in the form of a tunnel on the HUD in mode 2. This new indicator provides a sense of motion with a set 'ladder' like structure to help make visual velocity observation a bit more consistent and legible. The motion ladders also roll to align with the galactic ecliptic 'horizon' based on the movement of the ship, so they also indicate orientation. The motion ladder provides both forward and reverse direction indication as well as alignment relative to ship orientation and movement. It may take some players a little while to learn the new system, but it should prove far more more effective, especially in fast paced combat situations and while performing docking maneuvers.

A new pitch ladder system has been developed. The original system worked pretty well, but would twitch slightly at certain positions and would be clipped at varying angles as the pilot turned their head using mouse look or Track IR. The new system keeps the pitch ladder stable and locked to the central part of the HUD without clipping. The top and bottom clipping range is now consistent no matter what orientation the pilot's head is at.

The ship targeting system has also been expanded to allow for targeting some objects in range. For players who won't mind giving up tracking a ship temporarily, they can now target an asteroid, container, or build module with the ship targeting system. When selected, a target object will be highlighted by a blue bracket rather than a green, yellow, or red threat level bracket. The object's range, damage, and shield levels (if applicable) will be displayed on the direction indicator and the targeting MFD. This allows for a little more specific monitoring of an object's status, if desired. However, the targeting system's focus will remain prioritized for ships and the system will default to a ship when tracking new targets. Players will likely still generally use the main HUD and radar indicators for objects. But this option is available in case the player encounters a situation where the additional details the ship tracking system provides may help.

The 3D radar has also had significant revisions and improvements. Discussions and debates in recent years have prompted some changes as well as some new options. First, the 3D radar has been updated to include indicators based on distance. The blips themselves have been changed to hollow circles with vertical and horizontal bar markers indicating range. Objects that are farther away will have blips with fewer markers on them while closer objects will have blips with more markers on them (effectively increasing their size and presence on the radar display). A distant object that is at about the last third of the radar's range will be displayed with a circle blip only. A mid range object will be displayed with one range marker around its circle blip. A close range object that is at about the nearest third of the radar's range will be displayed with two range markers around its circle blip. This simplified approach helps provide a sense of distance as well as direction on the 3D radar display. The equal-distance 3D sphere format and directional lines have been kept for legibility and consistent formatting (while there are no remote or secondary elevation lines and/or range markers to clutter the display which could make it harder to keep track of numerous ships/objects that may be in the area). Simply marking the blips themselves with subtle range indicators will help the pilot quickly determine the relative distance of each indicated object. A brand new radar mode has also been developed that focuses on distance and heading only. This new mode projects the radar data using an overhead view, so only an object's distance and relative heading direction are indicated, excluding elevation as in the default mode. Some players may prefer this mode in some situations where only heading and range information are important. In addition to the new mode, range selection has also been added, letting the player narrow the scope of the display to shorter ranges to help clear up clutter and focus on only the closer objects. The radar's display mode, range setting, nav distance, and total hostile count (THC) are all displayed around the radar.

Another UI element that has received significant changes and improvements is the navigation console. During the course of Evochron Mercenary's life, the navigation console went through several revisions and additions, some of which were applied where there was room left in the console to fit them. This resulted in some of the options being added to a group of other options not really related to each other. While it was possible to learn and manage, it did mix some things outside of the placement the player might expect to see them. In the new game, the navigation console options have been reorganized to be grouped together into related sets of functions. So on the left side below the 'Current Position' details and the 'Form with Target' and 'Launch' buttons is the 'Waypoint(s)' menu which consists of five options associated with plotting, storing, and retrieving waypoints. At the top is the 'Autopilot' option which directs the ship to the current waypoint. Next is the 'Ping' option will sets a (unbound waypoint) marker on the nav map to the player's current location. The next option is the 'Map Log', followed by the option to add the current waypoint to the map log. Below that is the 'Set Loc' button, which sets the current (bound) waypoint to the player's current location. On the right side of the console are the 'Map Controls', which include options for zooming in/out on the map, rotating the map, sliding the map, viewing the map in 3D, and zooming the entire map. Below those options is the 'Map Modes' menu which provides options to select a text mode and activate the quadrant map mode. Below those options is the 'Options' menu which provides a few relevant secondary map options depending on which map mode is active. In the 'Nav Map' mode, the option to transmit the current position is available. In the 'Quadrant' mode, the 'Economy' and 'Territory' maps are available. I've tried to keep things close to the same locations they were before, but there are revised locations which will hopefully make things more consistent and accessible by putting these options in relevant groups together.

The navigation console's range has also been increased and also now allows for quick transitions between sector mode and quadrant mode. The range limit has been increased from about 9 sectors to 33, more than triple the range of the original map system. Players can see much farther out now and plot jump points much farther away than before without having to manually type in coordinates. If the player zooms out enough, the map will automatically switch to quadrant mode. The navigation console also now lets the player plot a sector jump point on the quadrant map. So for deep space explorers, they can quickly set a jump point to a sector location anywhere on the quadrant map without having to manually type in a sector coordinate value. Then they can zoom in from the quadrant mode to a specific sector region on the map, allowing them to view any charted region in the navigation database.

In addition to the major range increase is the new ability to view other parts of the navigation map that aren't local to the player. To do this, the player can simply right click on a charted system anywhere on the quadrant map. The navigation system will then zoom in on that location and let the player view details about that area remotely without having to be in the system. Each charted system now has a nav sensor 'beacon' at its center, which allows the player to retrieve remote sensor data about that system from a distance. It's range is limited to about 40 sectors from the center of the system, so there is still plenty of unexplored/uncharted space that can't easily be called up on the nav map. For those areas, the player will still need to fly there to manually nav scan the region for details.

A new feature of the navigation console is the addition of a highlight bracket to the nav map. Horizontal and vertical lines draw to a central box/bracket that is positioned based on where the player is pointing on the map. This provides a much better visual cue for the player to help them know exactly where they are pointing on the nav map and what icon they may be highlighting. They can simply place an icon inside the bracket to bring up context details about the object or to right click and set a jump/nav point to the object. When the player zooms out, the bracket can also be used as a way to better gauge which sector is being highlighted for right click zooming. With this simple addition, there is much less guess work for plotting precise waypoints in open space.

Another new capability of the nav system is the ability to zoom in on other parts of the local map and auto center to the new location. This option bypasses the original requirement of the player to zoom out from the sector they are currently in and then right click on a sector to zoom in on it. Now the player can simply move the highlight bracket to a desired sector and then zoom in on it with the mousewheel. The nav map will center to the select sector automatically and let the player continue to zoom in or out from that new selected center sector.

The nav map now also includes animation effects to help the player better gauge where they are zooming in or out from and where they are panning. The player can also now pan the map around one sector at a time using the arrow buttons on each side which remain available even when zoomed out. The new map capabilities provide a much more flexible and adjustable navigation console system that should be far easier to use and more controllable than any map system in a previous Evochron game.

Also new to the nav console is the 3D map mode. This mode lets the player hold and rotate the nav map in 3D, which lets them view nearby object icons in their relative positions in 3D space. It can help make keeping track of all nearby objects, including those that are above or below the galactic ecliptic, easier by displaying their positions using all three coordinate axis values rather than just two at a time. Mouse wheel zoom control is also provided in the 3D map mode.

On the left side of the nav console is a new menu labeled 'Local Pts' which stands for local points of interest. This menu lets the player quickly set a waypoint directly to an object within the current sector. If the object is a planet or moon, the system will automatically place the waypoint a safe distance away to allow the player to quickly jump to a nearby location.

I've also worked to streamline other elements of the UI, including the inventory console. Later in EM's development, a double check prompt dialogue was added to the sell system. Some feedback indicated this just added another layer/step to have to go through in order to sell something. While a bypass option was available, it made more sense to revise this system in the new game. So rather than requiring the game to be paused and the player to have to move the mouse pointer over to a separate menu to confirm a sale, the game now simply uses the same double click system that discarding uses. When the player clicks on an item to sell it, a text alert is displayed in the message log and the item is highlighted in red. To confirm the sale, then player simply clicks on the item again and the sale will be finalized. This should help prevent accidental selling while also keeping the process smooth and efficient.

The key and button input system has also been revised to allow for fast click and release functionality. So you can quickly select one option, then another pretty much as fast as you can press and release each key or button control.

I've worked to apply many of the requests and solutions to criticisms of the earlier game into the new one. The UI and related options/systems have been a significant part of those efforts.


Weapon and Equipment Changes and Additions:

I've been carefully gauging player feedback on the weapons available in Evochron Mercenary along with how often certain weapons are used and why. This research has helped shape some of the upcoming changes in the game's weapon systems.

First, Fulcrum Torpedoes have long been a source of contention for some players, trade for others, and largely unused by many. FT's have been replaced by a new kind of weapon class entitled 'Disruptor', a weapon type that has received some request and interest over the years. Disruptors are designed to interfere with the fulcrum fields of jump drives, restricting spacecraft to regular engine operation only. When a ship is hit with this weapon, it's jump drive won't be able to form a jump field for roughly 200 seconds. This can be used to keep a ship or multiple ships in the area if needed. The player who launches the weapons will also usually be subject to the effects as well, so it essentially levels the playing field. Should prove interesting for both PvP and PvE battles.

Another change involves proximity mines, which were largely designed around FT functionality. These are also now disruptor weapons and will detonate when a ship gets close. So if you anticipate a ship will be near a location, you can plant one of these mines in advance to disable their jump drive.

Particle and beam weapons have also been changed significantly, in several ways, they've had a ground up rewrite. Players have been asking for longer range cannons and the new game roughly doubles the range of these weapons. The MDTS will secure a lock at roughly double the range. However, the longer ranges also results in more time for your target to evade the gunfire. So while the range is now significantly longer, the chances for hitting decrease significantly at those longer ranges. But if your target is slow moving and/or is flying directly at or away from you, then you can now often hit the target much farther out.

Another significant change with the cannon weapon system involves power consumption. Within the game's fiction, the longer ranges of the weapons requires more power, so the energy reserves of spacecraft have been increased substantially. But this comes at the expense of taking longer to recharge. In order for beam weapons to remain sufficiently effective against shields, their energy consumption has also been significantly increased. So the most powerful beam cannons may only be able to fire a few times before needing to recharge. Some players might now find weaker beam weapons to be more to their liking with their lower energy consumption in exchange for moderately lower yield. Balancing these factors will likely continue to be worked on during the course of testing.

The kinetic effects of particle cannons has also been changed. Ship shields now provide kinetic resistance against particle cannons, allowing the shield arrays to absorb the energy rather than allowing the impact shockwave to pass through them and shake the player's ship. So while the shields are yellow or green, the player's ship will be unaffected by particle cannons while the shields absorb the impact energy of the gunfire. Once an array is critical and gunfire can get past the shield system, the shots will directly impact the hull and then cause kinetic impact effects, shaking the player's ship. This condition is true for player controlled ships as well as computer controlled ships.

Changes to particle weapons include a wider range of yields. The principle of burn out rate still applies, so higher yield, hotter burning particle weapon still inflict more damage, but now at a better comparative level versus lower burning particle weapons. I've run a number of tests to compare and contrast various weapon configurations in an effort to balance the new higher ranges with greater differences in yield. So long range cannons should no longer have quite the extensive advantage they've had in the past for some players, depending on player skill, energy setting, equipment based weapon enhancements, and opposing weapon/shield configurations. Combined with the changes in kinetic effects, various particle cannons should be better balanced overall. If you choose a longer range weapon, you might be able to reach your target first, but it won't suffer from severe kinetic effects until its shields are down and the damage level will generally be lower. This gives the opposing ship a chance to absorb the impacts for a while until their cannon is in range, possibly with the ability to inflict more significant damage faster than yours. If a player tries to swirl around a target to keep them at the edge of range of their weapon, the opposing player can counter it by boosting power to shields, limiting the effect of weaker incoming gunfire at longer ranges. Each cannon design can be suited to a particular play style, but overall, players should find the new yield levels, range limits, and kinetic changes to all help better balance different combinations of weapons stats in combat. This will likely still require somet tuning and tweaking, which I hope to cover as beta testing begins.

A number of players have wanted missiles to become more capable, less destructible, and much more of a threat. Some feedback also indicated that missile types other than the Excalibur needed to be more effective. One of the significant changes is that missiles are now armored. They can resist several direct shots from cannon fire, rather than easily being destroyed by only one shot. When you fire at a missile, the shots will impact the hull of the missile, resulting in a flash of impact light. It will generally take about a dozen shots to destroy a missile, making them much more resistant and increasing their threat potential as requested by players. Missile ranges have also been doubled, allowing for locking and firing at even greater distances relative to cannons. And lastly, missile speeds have also been increased significantly, making it much more difficult to outrun them and evade them. Players will have less time to anticipate sequential countermeasure use and will need to maintain situational awareness of any inbound missiles far more so now that they won't be able to so easily outrun them. In fact, trying to outrun them in a dogfight will generally be impractical and players will need to evade via defensive maneuvers, use CM's, or shoot them down far more so than before. These changes have also been done to help increase the value of missiles in combat, making them more worth the money they cost.

Deployable fuel stations have also been changed to make them a bit more realistic. Previously, they could be deployed virtually anywhere and seemingly generate fuel out of nothing indefinitely. They now require being near a base fuel source before they can generate fuel that can be used in spacecraft. You still won't need a fuel converter, those will still be available and work the same way as before. But a fuel station will now also need a material resource from a nebula cloud or star in order to generate fuel. Fuel stations will provide an advantage over fuel converters in that they can recover a lower density of particles for fuel, so you won't have to be as close to a star to recover fuel as with a converter. You can generally stay near the edge of a star's gravity field and still recover fuel with a station while a converter will require you to be well inside the gravity field of the star. Another side effect of this change is an increase in the usefulness and benefit of fuel pods that can be mounted onto secondary hardpoints. If you need emergency fuel reserves for deep space exploration, fuel pods are now a much more important resource than they were before when fuel could be generated out of nothing by a deployable. A well-equipped deep space explorer will now generally want to include a deploy constructor as well as fuel pods as an additional measure of protection.

The previous 'cargo' section of the target MFD has now been changed to the 'scanner' section. This has been done to accommodate the new scanner option that expands the previous cargo only system. In addition to the cargo scanners, a new 'Target Scanner' is now available which provides additional details on the ship you have targeted. With it you can detect the ship's engine, number of resistor packs, hull plating type, module type, and wing class. This can be useful information in combat when you need to better determine the threat potential of a ship and to gauge how effective your weapons might be against them, although it can be useful in non-combat situations as well. Target scanners can also provide content information of asteroids you have targeted, giving you the ore content in percentages when in range. You can also stack a cargo scanner with a target scanner in separate equipment slots and the two will work together and toggle their displayed information on the MFD in five second intervals.

A new addition to the equipment list is the Low Light Terrain Visibility Optics System. This item lets you view terrain that would otherwise be nearly invisible on the dark sides of planets and inside asteroid caves. When activated, it will tint the terrain green as it brings up the visible spectrum so you can see the contours of the terrain at night or inside asteroids.

Another new item is the repair beam. The repair beam lets a player repair the hull damage of ships and station modules. It can also repair any subsystem damage of ships. The beam must be aimed at the structure and reach full strength. Damage will then be repaired at a much faster rate than even a top class repair system can manage. This can be useful in multiplayer combat where one player in a squadron can be designated for support and provide repairs to their teammates as needed during battle. It also gives players a way to repair damage to their stations, including while they might be under attack or in between attacks.


Territory Control and Faction Wars:

One of the most common requests for change involved the 'clan' system. Specific points of interest were stations, methods of territory capture and control, map data, and faction commonality (rather than numerous splinter clan groups within each primary division). Taking all of the aspects into consideration, I've redesigned and changed how the system works as a whole. I'll go over the changes and additions to the new multiplayer linking system below.

One important element in the new territory system is the consolidation of the identity structure into two factions. In single player, the player can choose between one or the other to be allied with and various hostility and station accessibility options within the game's universe will line up with their selection. In multiplayer, the player can choose either faction to be allied with during the course of their gameplay session and their choice won't impact their single player status. When a player joins a multiplayer game and chooses a faction to be allied with, their choice determines their threat level relative to other players in the game. The game will automatically apply their faction affiliation ID to their callsign for them. From there, the game is open to changing territory control conditions between the two factions.

Trade stations are now always neutral in terms of territory control, as they have been in the game's single player side of things for a long time. They can be built, destroyed and rebuilt without having any impact on the regions territory control status. This will allow for independent players to construct new trade stations without having to be involved in the territory control system at all. Likewise, there is no control benefit for faction affiliated players to build these, they can now strictly be used for opening new trade routes, providing inventory, offering contracts, storing items, designing ships, engineering items, and designing weapons. The only potential territory control benefit for stations comes after they are built. Once a majority control level is reached for a given faction (around +30%), indicating hostile forces have been removed from the region, then completing peaceful objectives via contracts/missions can help further increase the territory control level. And those contracts are what can be available by an allied station in that region. Completing combat contracts in a disputed territory can still provide territory credit, but not from the contracts themselves, only for the hostile ships you destroy during the course of completing those combat contracts. Once majority control is achieved, then the territory control system will transition over to peaceful objectives. This means building an allied station in the area becomes an important next step in building the control level further. While the station itself doesn't add territory control credit, it's construction facilitates the steps needed to do so. It allows the area to harvest resources, construct more allied ships, and develop inventory manufacturing. All of which help further strengthen the control of the region and makes it more difficult for enemy forces to invade and retake the region.

The methods of how territory is acquired has also changed. In multiplayer, players can battle it out for territory control at a rate of about 1% per PvP kill (adjustable by the server operator). Completing contracts is no longer associated with territory control in disputed regions, they are merely a reputation, wealth, and rank benefit for players. So faction wars are now the only way to acquire territory in the multiplayer game in disputed territories. This also carries over into the AI system, requiring AI ships to be destroyed for control to shift. Only after a region has been secured for control can completing peaceful contract objectives further increase control for a faction.

The quadrant map display system has also been changed. Now that there are only two primary factions for territory control, there is no need to display a lot of clustered text for different clan groups. The two colors, green and red, are now used to simply identify allied and hostile territory regions and they are now organized in squares so you can more easily determine where the border of one region ends and another begins. You can hold the mouse pointer over a region to display the control percentage. Zooming the map is still supported for a larger view.


Shipyard and Ship Design:

One major element of redesign and feature additions is the shipyard. I've largely tried to keep the same layout as before so the UI is familiar to existing players, but the options and capabilities have been significantly expanded. Three of the primary design options for ships have been moved from the component menu to the frame configuration menu. The shield core, fuel tank, and cargo bay options are now adjustable in the frame configuration menu using the selectable tile icons. And of course, they now share in the assembly capacity system of this stage of the ship design process. A forth option has also been added, namely ship armor which I'll cover in more detail below. So the frame configuration menu has been roughly doubled in size with options and now controls most of the main functional parameters of the ships you design. You can also directly optimize a ship for a particular role this way, giving up one capacity parameter to expand another whereas before they were not linked in this way.

These changes also allow for new options to be introduced to the component section of the shipyard. The component options focus on ship functionality rather than capacities. So now the pieces you put together for your ship can effect a variety of functional factors including its agility/aerodynamic efficiency (flying in planet atmospheres), structural strength, mass/weight, and weapon evasion/resistance. You can also reduce one aspect of functionality to increase another, just as with the frame configuration menu. For example, if you intend to focus on dogfighting, you can lighten your ship by covering its hull in a lighter material, installing a thruster module to improve agility, and installing a basic structure reinforcement to help keep weight down. You'll need to consider the effects of such selections and changes will have on your ship with whatever design parameters you come up with. Here are some details on the component options in the shipyard:

Resistors:
When designing a ship, the player can select various resistor packs to provide additional protection from energy weapons. These systems can help insulate the ship from energy weapons by absorbing some of the energy and safely dispersing/discharging it inside external pods. The ship's hull is used as a conductor to transfer the energy to the pods. More pods can absorb more energy, but at the expense of more mass. Increasing the ship's mass can impact its open space agility and atmospheric flight capability (hindering maneuverability and requiring more speed to generate more lift to offset the greater weight). So it's important to consider which level of resistor you want to apply. Here are the different types and levels of protection: - Level 1 (2% increase in energy weapon resistance) - Level 2 (4% increase in energy weapon resistance) - Level 3 (8% increase in energy weapon resistance) - Level 4 (12% increase in energy weapon resistance) - Level 5 (15% increase in energy weapon resistance)

Plating:
Players can choose to apply a specific material to cover the outer part of the ship's hull. The outer hull is the first surface any incoming weapon fire will encounter before impacting armor (which is layered behind the outer hull). Each material type can provide a unique benefit to the ship:
- Titanium (20% faster hull repair)
- Reflective (15% increase in energy weapon deflection)
- Reactive (10% reduction in missile impact damage)
- Silica Fiber (20% improvement in heat insulation)
- Composite (20% reduction in hull mass)


Modules:
All ships have a module connection that can accept a component to enhance a functional element of the ship. The player can choose which system to enhance with their component selection in the following categories:
- Shield Module (+10% improvement to shield power reserves)
- Thruster Module (+15% improvement to maneuvering thruster capabilities)
- Energy Module (+10% improvement to energy reserves)
- ECM Module (+25% improvement in countermeasure effectiveness)
- Heatsink Module (20% reduction in heat signature profile)

Once installed, the module is part of the ship's core design. While only one module can be installed in this part of the ship, it has the benefit of not consuming any equipment or hardpoint slots, leaving those open to other equipment items to customize and improve the ship.

The shipyard has also been expanded to include many new performance details about the ship you are designing. On the left and right sides of the middle display are readouts for:
- Mass Level
- Structural Integrity
- Energy Level
- Heat Factor
- Firepower
- Agility
- Atmospheric
- Acceleration and Deceleration
- Fuel Efficiency
- Range

Each of these parameters can be effected by the components and capacities you specify in your ship's design. This way, you can have a real time gauge to measure the effects of the changes you make while designing your ship.

Several of the capacity options have also been increased. Civilian ships have the ability to be configured in higher and more diverse capacities than military ships. For example, a high end civilian ship can now be configured to carry up to 10 equipment items while military ships can carry no more than 8. Likewise, a high capacity civilian ship can be configured to carry up to 5000 units of fuel, 250 countermeasures, 10 cargo bays, or 10 levels of hull armor. So while military ships can still have an edge in certain combat roles, civilian ships can be configured for more diverse roles like cargo transporting, station constructing, exploration, spying, and mining.


Graphics and Special Effects:

The graphics and special effects have received significant improvements and changes. The new game targets a minimum resolution of 1920X1080 as a baseline for cockpit displays, text, texture, and UI detail. The new bitmap font system helps accommodate this goal by providing smoother edges and more consistent rendering for each character without having to be larger/wider to maintain a certain level of legibility at lower resolutions. Likewise, cockpit displays can have finer detail and more character space can be available for UI details and options. The game should still look good and work well at lower resolutions, such as 1600X900, but it is optimized to operate best at 1920X1080 minimum.

I've hired a 3D modeller to create new spaceships, cockpits, and station modules for the game. His name is Norbert Iacob and he has been doing a great job of designing original ships to replace the bulk models used in the previous game. The level of detail for them is much higher and the variety in appearance is also much greater. There are now two unique dedicated cockpits for each primary class of spacecraft. Civilian ships now have their own cockpit design that appears larger and roomier while military ships have a tighter and more confined design. Texture details are much higher and the mesh structures are assembled in memory to include objects such as thruster nozzles, engine exhaust outlets, and cannon barrels. Since the ships (and engine components) are now much more varied in design, they needed a new in-memory assembly system to properly place various nozzles and outlets, so each ship frame now has its own dedicated placement mapping for those structures. I'll go over some additional details below.

As mentioned to above, I've designed a new engine outlet and exhaust system to provide each ship with a unique thruster layout built around its shape. There are still 8 primary maneuvering thrusters, but they can each be arranged independently to be properly placed at various locations on the ship's hull. So the player can see each individual thruster nozzle as the thruster effect is also aligned with the nozzle. The end result is a much more pronounced and visual thruster effect for each ship in the game. Support for additional exhaust outlets for the main engine has also been added, so ships can now have more than two engine outlets at the back of the ship.

Explosion effects have been greatly enhanced. The base explosion animation has been doubled in resolution and an all-new debris effect has been developed. When a ship explodes, it no longer just disappears and leaves behind a few small debris pieces. Instead, the game engine now takes the mesh data from the ship model and then breaks it apart in memory. It then throws the pieces out into space from the central explosion point, providing a much more pronounced impression of what's left of the ship being blown up. The new system works for capital ships as well as smaller ships and even station modules. The explosion system also scales, so the player can select different levels of special effect detail in the Options menu for systems that have difficulty processing a high number of vertices for an explosion effect. The system can break down a ship's structure into fewer pieces to reduce the resource load needed to render the effects. So if you have an i7 gaming desktop with a high end 3D video card, you might want to keep the setting at 'High' whereas if you have midrange or older system, you can set it to 'Medium' or 'Low' to gain improved performance that works better for your system configuration.


New Ship Armor Design Parameter:

A new addition to the shipyard is the ability to select the thickness of your ship's hull armor plating. A new field is displayed in the frame configuration menu that lets you select the hull armor plating value from 0 to 10. The more armor you add to your ship, the better it will resist direct impacts from weapon fire. You can reduce the level of hull damage by up to 20% by adding more armor. Armor does not effect your shield system, which is entirely separate from the hull.


Market, Trade, and Economy:

One of the biggest improvements in the game involves the trade and economy system. Previously, price fluctations were randomized within the confines of pre-established static economic conditions. This has been replaced in the new game and the new economy system is dynamic, allowing it to completely change over time. The game launches from a fixed point in time with set economic conditions, but where it goes from there is dependent on market changes, inventory shifts, and events including actions the player takes.

As such, no two game paths will be identical, so as time progresses in the game for the player, the economic conditions can be significantly different for them than for another player... or even another save game of their own. The player can directly impact the value of a commodity in the local markets they buy and sell in. Under current testing conditions (which may obviously change by release), if the player sells a set of 25 units of a commodity in a system, they can effectively reduce the value of that commodity by around 1%. Continuing to sell the commodity at that location can further reduce the value, saturating the market there and resulting in a devalued condition (even all the way up to 50-75% less). This can potentially require the player to travel elsewhere to find a location that will pay a better price. Likewise, buying a lot of one commodity type and taking it outside of the system can increase its value by making it less available. Some commodities are also related to each other. For example, water contains hydrogren, so buying and selling it can also effect local hydrogen cell prices.

In addition to the item specific pricing system, there are also overall economy conditions that can change. The quadrant map has always provided a economic overview, but in the earlier games this was static and unchanging with only minor variations in inventory prices. In the new game, this map is now also dynamic and will change based on current market conditions for regions of space 500 by 500 sectors. If you perform actions which help boost production and research, you can increase the economy level for that area by enabling it to build more, sell more, and design more. Changes are reflected in that regions grid on the economy quadrant map. The further an area shifts toward green, the higher level the economy is at. Performing a lot of trades in an area can also help increase the economic conditions of an area. If a system is left rather empty and struggles with conflicts, its economy can decrease. So the player can be activately involved in changing the conditions of a region by their actions. And the changes are long term, rather than only temporary or being restricted to small random limits.

Multiplayer also provides a unique dedicated economy system players access when they log into a server. A player's earned single player economic conditions don't change while they play online and the multiplayer system links the server's economy for all human players together while they are online. So each server can have its own unique economic conditions based on player actions and events during the course of gameplay.

In an effort to adjust the risk, reward, and effort factors of credits in the game to effectively make them more valuable and difficult to obtain, several other signficant changes have been made to the game's pricing and market systems. Emphasis on commodity trading has been increased by providing a more significant price variation structure compared to other items in the game. Previously, a player could pick out a few select weapons or equipment items, then quickly transport them to a nearby system with little effort or risk for a very high profit. In the new game, these single item price variations have been reduced and brought more in line with commodity price variations and in many cases, even narrower. Commodity trading will now be a much more profitable option in the game and players who pay attention to economy types, levels, and pricing structures will be rewarded with high paying opportunities relative to other buy/sell options in the game. In fact, the variations can even result in certain low value items being highly profitable when they are in high demand in certain areas in the game's universe. As one example, food is not often considered a valuable option in the current game. But in the new game, it's base value is double and its potential value offset can vary by up to 20X depending on location and demand. This means that if you have 25 units of food you bought for about 50 credits in an agricultural market, you could sell it for over a 1000 credit profit in another location. Under the game's new credit value structure, this now becomes a worthwhile endeavor. Other commodities can have similar variation.

The station inventory discount for station licenses has been changed to 5%.


System Requirements and Performance:

The new game will be a significant change in course for how my games have targeted a range of system configurations in the past. Evochron Mercenary will remain the 'Evochron' of choice for the broadest system compatibility and highest level of performance on the widest range of system configurations. The new game however will be targeting a much higher minimum level of detail and as such, will require significantly more performance from the system it is being played on. There are also some new hardware requirements. For example, one new system requirement will be support for shader model 3.0 minimum. I have put a lot of effort into continuing to support a wide range of systems, including certain low and mid range configurations. But the requirements for the new game will be higher, although still playable on some older systems that might be a few generations behind in hardware feature sets and performance.

The game does still focus its resources and displayed content on the 'sim' element of 'space-sim', so graphics, options, physics, and control systems that relate to flying your spacecraft are given priority. This means certain environmental details will continue to lean a little more toward the 'artistic' and 'simplistic' side of the spectrum rather than strictly 'realistic', but the levels of detail presented are still significantly higher than in the previous game and will require a more powerful system to run well. Certain detail and effects settings will be adjustable to help improve performance on older/slower systems.


Combat and Trade AI:

AI ships in combat now have more options available to them in their decision making. One of the new choices they can make is escaping. If they are not under orders for a mission or contract and have sustained some damage, they can choose to escape and warp away if they believe they may not survive the battle. They will also generally time their escape when the opportunity presents itself, such as when they are evading an incoming attack from behind and the path ahead of them is clear.

AI also now have much more range in the equipment loadouts they can select. Previously, repair systems were pretty much kept away from AI ships. They now have access to them and will generally include them in their ship configurations.

For direct ship-to-ship trading, AI pilots can now offer useful build tips for the engineering lab.


New Build and Deploy System:

One of the biggest additions to the game involves the new build and deploy system. The old system has been removed and replaced with a new dedicated module based construction design. This includes the addition of a new console, appropriately named the 'Build and Deploy Console', which can be accessed with the F2 key or by clicking the 'Build' button on the HUD. As you can probably tell, this means the jump drive key has been moved also, which is now the F8 key, so it's no longer sandwiched in between console keys by default.

A big part of this new feature is that even default stations in the game's universe use the build system. During the course of the war between the Alliance and Federation, many of the minor stations were destroyed, leaving only some of the major stations. And the stations that remain have been rebuilt using the build system. This also means that default stations in the game's universe can now also be destroyed as well as rebuilt. This provides a much more dynamic structure to the game's universe, resulting in a gameplay timeline that can be unique for every player. So even though players will start from the same point in the game's history, how it branches out from there can be different for each of them. For example, one player might encounter hostiles who manage to destroy a default station in a system and they decice to rebuild it, but in a different location. Their actions and the actions of the NPC/AI ships in the game result in a unique event and station condition for the universe they are playing in. And since it was all part of the game's new AI and player-directed building and destruction mechanisms, the player and AI pilots have a direct impact on many such events and conditions within the game through their actions.

The build console lets you construct structures for various functions on-site. The items you build are no longer magically transported to the location you select as in the old game, but instead you actually construct them from the materials you have on board and build each part piece by piece. This requires the player to recover resources to build, rather than just paying a fee to have something teleported to a location. As you build, materials such as metal ore are taken from your cargo bay and used to construct the module you select. If you run out of material and want to keep building, you simply fly to an asteroid field or trade location and acquire what you need, then return to the build site and continue constructing. You are no longer limited to individual one piece static designs for your stations, you can actually customize how they look and function by how you put them together using individual modules. For example, you start with a power core module and put it where you want your station to be. Then you can add other modules to it, such as a living/crew module to house people to run the station, a production module to provide an inventory, storage module to provide a place to store cargo/equipment, weapon turret module to defend your structure, or a number of other modules. You can stack/connect them together to design the look of your station and may need more power modules to support your design as it expands. Each power module can support many other modules connected or nearby to it. You'll also want to plan your designs carefully. For example, placing a weapon turret in a position that leaves it surrounded/obscured by other modules can reduce its effectiveness by limiting its available firing angles.

The procedure for building is pretty simple. The game divides build points into 50X50 blocks of space and when you activate the build console, a yellow placement marker will appear ahead of your ship indicating the currently selected build point. If you have the required materials in your cargo bay, you can then build one of the modules at that point. It takes a few seconds for the particle emitters to put the module together from the materials, but once complete, you're ready to continue on and build the next module. The placement marker will also change color based on whether you are building at a point in open space, connecting to other modules, or if the build point is obstructed. For optimal construction, you'll want to connect station modules together at their connecting ends. Most modules are designed to connect with each other at 90 degree angles horizontally or vertically. Some modules, such as production modules, require more spacing for connected placement due to their larger size and the placement marker will indicate this by also growing in size as needed to display the optimal position. When the placement marker is at an optimal connecting position relative to another module, it will change color to green and that will be the best place to put the new module you want to build. If the build point is obstructed by another module or object, the placement marker will change color to red and you won't be able to build at that point. You aren't required to connect modules together as they can operate independently as stand alone structures, but it's best to put them together for optimal energy transfer and structure. For example, more modules can share in the energy provided by a power module if they are closer together.

Finally, the build modules require being destroyed to be removed and can be eliminated individually. Deploy modules still provide the quick scuttle option, but build modules are designed to sustain weapon fire and function more like a station component that is part of a larger superstructure. So to destroy a module so you can change your design, you can simply destroy the module you want to remove with weapon fire. Likewise, the modules are similarly protected from other players in this way. So if an opponent wants to destroy a structure you built, they will also have to destroy the modules one at a time. This is where defense modules like weapon turrets can come in handy. You can also install a shield module that will provide shield protection to other connected modules. If power is readily available from a shield module, it can often be applied to other modules instantly. Otherwise, there may be a required charging cycle for those modules, depending on their build time and build location within the structure. If a shield module is destroyed, it immediately sends a shockwave through the connected modules that brings down the shield arrays of all connected/nearby modules, leaving them vulnerable to direct impact from weapon fire. If there are secondary shield modules installed into the design, they will immediately begin to start recharging the downed arrays. But there is a period of vulnerability for the modules until the recharge cycle is complete. If no other shield modules are available, the shield arrays will remain down until a new shield module is built and installed. So you'll likely want to design your stations with protective structures in place to help defend important components like shield modules and power modules.

To build a station, you'll first want to start with either a power module or a command module. A power module provides energy to nearby modules and is a good base structure to build from. A power module doesn't have to be directly connected to other modules in order to power them, it can transfer energy to other modules remotely through power bands in open space, but it does need to be within about 500m of other modules in order to give them energy. It's best to connect other modules to each other though for optimal energy transfer by allowing more modules to be powered by the core power module when they are closer together. Larger station structures will require more power modules once you exceed the 500m range limit.

The command module gives ships a place to dock and conduct trade, ship construction, engineering, and hangar storage (the storage module is for managing the station's inventory, not a player's). You can then construct other modules around the hangar, although obviously not in front of a hangar entrance :-) Command modules also serve as power modules, so you don't have to build a separate power module if you are building a command module. However, building power modules in addition to the command module can provide redundant power sources as backups in case one or more is destroyed in an attack. Unlike other modules, only one command module can be built per sector. You may want to shelter some of the more sensitive components of your station with other modules and/or build a certain shape to make defending and repairing easier. There will now be a wide variety available to players for customizing the layout of the stations they build for appearance and function.

Once a command module is in place, a station icon will appear on the nav map for that sector. To accommodate player requests for a more limited visibility status for stations they build, the new system will only detect a hangar module when the player is in the same sector. They are now largely cloaked from nav sensors down to only one sector of range. Only one hangar module is allowed per sector, but you can build many other module types around the hangar module or elsewhere in the sector.

**** Update July 1st, 2015 - During the course of testing over the past few months, it became apparent to the testers that it would be better for gameplay overall if station command modules were detectable beyond one sector. When the range was limited to one sector, it was just too difficult and time consuming to try and locate stations for building, docking, and attacking. So as of this writing a new data array and revised nav map icon display system has been developed to show icons for command modules up to about 30 sectors away.

Like power modules, shield modules have a range of about 500m. So in order to protect modules with shields, you'll need to keep them within that range of a shield module or build additional shield modules if there are modules that are out of range. If a shield module is destroyed, all modules in range will lose their shielding and you'll need to rebuild the shield module to restore protection for them.

Cities are also now created using the new build system. This means cities can also now be destroyed and rebuilt. When building city structure, an additional substructure is added to each module to suspend them above the terrain. And when building a hangar near the surface of a planet, a special version of the hangar is constructed that provides a wide docking area to better accommodate the atmospheric physics conditions.

Another significant change for stations/hangars involves the previous fees associated with them. In the previous game, you would have to pay a recurring fee for as long as you had items stored in a station's hangar. These fees would stack if you have items stored in more than one station. So due to the new dynamic nature of the new game's station system where stations are much more buildable and destructable, the fee structure has been changed to be a one time 'transaction' fee. So now when you store items or retrieve them, you will be charged a sort of access fee for the transaction, but you will no longer be required to pay recurring fees for the hangars you have items stored in.


Reputation and Faction System:

A significant amount of the feedback I've received over the last 5 years since Evochron Mercenary was developed and released indicated that the reputation system was a bit confusing, complicated, and difficult to track and manage for some players. The random behavior elements also created a sense of confusion and inconsistency for some. So the entire reputation system has been scrapped and rewritten while also being consolidated with the new territory control system. There is now one global reputation system designed around the primary factions: Alliance, Federation, and Vonari. Rather than trying to keep track of individual sub-factions within every system, the new structure links systems together based on their association with each primary faction. So the player now only has to keep track of their standing with the Alliance and Federation as a whole.

Generally speaking, the Federation largely controls the upper portion of the Evochron quadrant while the Alliance controls the lower portion. In the middle are areas of disputed territory, where ships on each side will often be activately fighting each other rather than focusing on more trade activities. The upper and lower regions of the Evochron Quadrant will be where trade occurs primarily, at least early on when the player starts a new profile. This safer area of space is where several systems are located for each faction, giving new players a larger region to get started in with a much lower risk of conflict early in the game. And the faction they choose to be allied with will determine what system they will start in.

The online faction system is now also linked with the reputation system. So players can choose which faction to fly for before they join in multiplayer, then have the in-game ships be hostile or friendly to them based on their faction affiliation.

The player also now has the ability to trigger battle areas, opening new war fronts between the Alliance and the Federation, based on their actions. If the player engages hostile ships on their own territory and destroys enough of them, the enemy faction's control level will drop and allied forces will eventually begin to move in and join in the fight. Combat contracts will eventually begin to be offered and depending on the outcome of battles, the control of the system can transition from a conflict zone to being securely in the control of one faction or the other. The game now works this way in both single player and multiplayer, with territory control levels unique to either the player's profile (single player) or the server they are playing on (multiplayer). This gives the game a new element of dynamic territory control far beyond the capability of the old clan system.


Startup and Launching:

Another significant change in the new game involves how the player enters the game. Rather than suddenly spawning into the game's universe, there is now a multi-stage startup procedure that operates from the time they are in the main menu until they appear in the game after clicking on 'Launch'. The player enters the main menu directly in the cockpit of their ship with all systems shut down. Clicking on 'Launch' (or 'Connect' for multiplayer) begins the startup procedure for their ship. Systems will begin to boot up and charge, complete with sound effects providing various button presses and spool up noises. This process continues while the game loads. Once loading finishes, the player's ship is placed at the spawn point and the final startup procedures activate. The gunsight, HUD buttons, and cockpit displays gradually scale and flicker into view. Then the shields and energy levels begin charging. Once all systems are online and active, ship controls become active and they can pilot their ship out of the hangar.

While this appears to largely be a cosmetic realism feature, it actually also serves a purpose. The few seconds it takes for the startup procedure gives the multiplayer server time to update the player with the latest territory, economy, and build object conditions.


Single Player Fleets:

The single player fleet system has been heavily revised and modified. No longer is the player restricted to issuing directives to their fleet group as a whole, they can now limit their orders to individual ships within their fleet. So if one ship in their fleet is heavily damaged, they can order that one ship to leave the battle to repair and reload. Likewise, the player can order one ship back to join in formation while the others engage in the battle. This way, the player can direct their ships in a more specific and strategic way while also expanding what their fleet can do as a whole at the same time (for example, a player could order two or three ships to mine for resources while the others join the player for defense during a contract).

Another new system is the 'Fleet Status' screen. When the player clicks on the 'Fleet Options' at the top of the HUD, a new option is available at the bottom of the order screen named 'Fleet Status'. The button is green in color to distinguish it from the command options. When the player clicks on the status button, the fleet ship selection menu changes to the status screen and will provide the player with real time damage data for each ship in their fleet. This way, the can periodically check for the status of each ship in their fleet during battle and order specific ships to retreat as needed. The fleet option menu will remember the player's mode selection so if they close and reopen the menu, the status screen will still be displayed by default.


Gameplay:

Of course, gameplay in general has also received a lot of attention and has been expanded. One significant change is the joining of the distress call system with the game's main contract system. This allows distress calls to utilize the same menu structure, objective sequencing, and payment system. So distress calls can now have the benefits of a more diverse payment structure aligned with how other contract payments are established, an accept/decline option controlled by the player, multiple simultaneous distress call offers in the list of available contracts, localized alerts, and dedicating time limiting specific to a particular player. These changes and improvements will help facilitate player requests, not the least of which was removing/limiting the distance factor for a given distress call objective. Now, distress calls can be individualized for each player and kept local to the sector they are in. They'll still have to hunt down the needed commodities/materials to meet the objective if they don't already have it on board their ship, but reaching the required location is now much more practical. To offset this reduction in difficulty by keeping the objectives local, the player will risk failing the objective if they leave the sector, as with any other contract/mission objective. So this can make it more challenging to acquire the needed commodities/materials by limiting where they can search for it. If the required commodities/materials are not available in the current local inventory, then the player will need to have planned ahead and stored the material in advance in the local station hangar or aboard their ship before accepting the distress call contract.

Another benefit of incorporating the distress calls into the contract system is that they can now be linked in multiplayer. So if a player accepts a distress call contract, other local in-sector players can join as well in multiplayer. This way, a player who may have the needed commodities/materials but wasn't offered the distress call can help another player complete it who is offered the distress call.

One of the more popular requests for a mission/contract objective over the years has been intercepting inbound meteors on their way to hitting a planet. So a new contract objective and meteor system has been implemented to include this option. When available, the planet will send a distress call through the game's contract system, offering payment to the first responding ship who can destroy the inbound meteors before they impact the surface. The contract availability is time limited, so the player must accept the contract and arrive at the waypoint before it's too late. The player then chases down multiple meteors as they travel toward the surface of the planet. The player has a brief time while the meteors are still in space to fly as fast as they can to catch and intercept them. Once the asteroids enter the atmosphere, the situation changes as the player will then be limited by how fast they can fly to catch the meteors and the meteors themselves will be obstructed by the flame and smoke contrails caused by entering the atmosphere. If the player can destroy all of them before any impact the surface, they will complete the contract and be paid. If any meteors hit the surface, the contract is lost. As part of the game's more dynamic structure, if meteors impact city modules, they can destroy them. So there is risk to both structures and inventory/economy should the meteors hit the planet. The new contract objective and meteor system are also available in multiplayer, so players can join together to cooperatively take out the asteroids for improved chances of success.

Other new contract objectives are emergency distress calls for water delivery, oxygen, food, and medical packs to a local planet. These resources are important supply elements in the game's universe and on occasion, the local planet may be in critical need of one or more. When/if this happens, the distress call will appear in the contract list and the number of units required will be significantly higher than the typical material contract, 50 units rather than only 25. Pay for the job will also be significantly higher to help offset the added cost of acquiring the 50 units.

Even more new contract objectives include possibly capturing animal specimens for ecological research and placing certain deploy modules at specified locations.


New Quest System:

The old quest system has been scrapped and replaced with a new system that is not bound by the game's internal contract/mission system. Instead, the new quest system is designed to operate entirely on its own without any contract-based or other player dependencies. One significant difference in this approach is that the system is designed to work exclusively in single player, freeing it up from the confines of having to use the game's multiplayer contract/mission structure and instead, allowing it to operate entirely independently for many new and unique options. This also means the objectives and events are now specific to the player on the quest. Without interference from or dependencies on other players to complete fixed contract objectives, the new quest system is now open to having branching structures with more complex stages, objectives, and effects. The player on the quest can now complete things like travelling to a waypoint within a time limit, following either a winning or a losing path within a quest, and/or complete certain tasks on their own time and in their own ways.

Another primary objective of the new quest system is the ability for the player to manage their quests from within the game and to also allow for multiple quests that do not interfere with each other. A new 'Quest Menu' will be added to the inventory > news console which will allow the player to scroll through any available quests they have installed, then 'activate' one they want to play. They can optionally save their progress, then deactivate a quest and switch to a different one 'on the fly'. The player will no longer be bound to one quest at a time nor will they have to give up one quest just to play a different one. They can manage multiple quests in one menu interface and choose when/where to activate them. They will also be able to continue from where they leave off in each individual quest.

The new quest system also supports using player-designed objects. This means that players would be able to load an external object they made themself into their quest and the game will load it and use it in the quest system for the purpose they specify in the event directive(s). The game will also do all of the work internally to generate collision data on the fly when loading a custom object, so the player will properly react to the surface of the object's unique size and shape, rather than just being spherical or box collision. So a player can load just about any structure they want into the game and use it as part of the quest story, from massive shipwrecks to fly around to small data boxes that broadcast information when discovered.


Cargo:

The cargo system has also been changed to accommodate player requests and provide additional functionality/options. Many new cargo items have been added, particularly commodities useful in the production of items in the engineering lab and for trading in various markets. New commodities include memory chips, batteries, energy emitters, mirrors, radio components, particle accelerators, and lenses.

The potential capacity of the cargo system has also been increased. Previously, the limit was five cargo bays maximum. The limit is now double that, up to ten cargo bays can be built into a civilian spacecraft, if it has the assembly capacity to include them in its design. This limit was established after careful reviews of player feedback, potential exploits, and balancing conditions for hangars and trade. Hangars will still provide a significant advantage with up to 25 bays of storage, but ships can now carry twice as much cargo as they could before. Balance has also been considered, so players will need to compromise in other areas of their ship's design in order to configure it more for cargo hauling rather than combat. The limit has also been kept to a maximum of ten to help keep active trade running/transporting a part of the gameplay equation.

The cargo container system has also been updated to work with the new cargo bay limits. Containers in open space and on planet surfaces can also now carry up to ten bays worth of cargo. So players can jettison their entire cargo bay and be able to later recover it or transfer it to another player. The trade console has also been updated to support all ten cargo bays for direct ship-to-ship trades as well.