Owen: Missions, bug hunting and 2.0

Hi everyone. This is Owen Lake (aka Xenon_Slayer), mission programmer for X3: Terran Conflict. I missed my chance to write for this blog during the initial development phase, so I’ve got some catching up to do. As you may have read in my interview in X-Universe News 35, I’ve been keeping myself busy with the latest update, 2.0. Well, where to start?

My main area of focus is on mission design and development, for both the plot and generic missions. In previous games such as X3: Reunion, these missions were programmed in the game code itself, a language called KC. Programming missions in KC gave the mission authors a great amount of freedom to do whatever they wanted, as every game function is a simple line away. Coding a mission directly into the game code has its drawbacks though. The only way to include a new mission is by recompiling the game, and distributing it with a patch, leaving community missions out in the cold unless they are accepted by EGOSOFT through the DEVNET. This system has given us some classics such as the Perseus Mission from X-Tension.

For X3: Terran Conflict, KC missions were dropped in favour of the Mission Director. The MD is a scripting tool, using XML files to store the mission itself, outside of KC. I started working with it back in 2006 along with several other volunteers. We tinkered around, making several missions and testing the MD functionality. I was not a programmer back then, and I found the MD was very easy to get my head around. Over the years, more functionality was added, giving us the jam packed MD we have today. All we needed then was mission content.

Several of us sat down to discuss what the plot of X3TC would be, including fellow mission programmer Al and X author, Helge. Many ideas were tossed around, such as exploring more about the Sohnen race. In the end, we decided on the 5 plots we currently have. I was assigned to code the Terran, HUB and HQ plots. The Terran plot was the most challenging as it was the main plot of the game and needed to carry the story along and immerse the player, while keeping the universe free and open. Most of the time, I would need to look though the list of MD ‘conditions’ just to refresh my memory of what the player could do to potentially break or exploit my mission. We really have so much freedom in X that different players may see or play the mission in entirely different ways.

We developed several small chunks of mission code which was designed to be re-usable. These ‘libraries’ are used in several parts of the plot and generic missions. The upcoming Aldrin Expansion mission in X3TC 2.0, uses these libraries extensively. The entire plot was coded very easily and within two months. The aim of the plot was to advance the Terran story further and present the player with several activities which they may not have done yet, not to mention show off some new content.

Much of the new content is obviously focused in the Aldrin region of the universe, which is very unique. The large asteroid in the centre of the sector separates stations to great distances. While the initial exploration phase is more extreme than any other in the X-Universe, it can become a chore to fly 300km from station to station. So, ‘how to solve a problem called Aldrin’. That is where Terran ingenuity (namely mine and Toasties) comes in. Using tractor beam technology, they have pulled several stations closer together. Then, using the Transorbital accelerators, they create easy, quick access between station groups.

The future of missions in X3TC is bright. We have several community missions on the script and modding forums, and a few in the pipeline for a future update. I have dived straight into the world of KC programming, adding new functionality to the MD or improving some UI. This is entirely new for me as I couldn’t really program anything this time last year. As well as adding new stuff, I have been able to do battle with my mortal enemies - Bugs!

I started testing far back in 2005, when X3: Reunion was in the Alpha phase. As we warn our betatesters, it isn’t all fun and games. Having a sneak peak at the new content is a bonus, but it is hard work to get results. Some bugs are easy to find and reproduce, but some only occur in very special, sometimes strange circumstances. A few weeks ago, we heard reports of “Zombie Hyperions”. Some ships seemed to have a mind of their own after being boarded and captured by the player. With a savegame someone had provided, I was able to see the ship was still assigned to patrol duty for the former owner. With the help of Klaus, we managed to “exorcise the demons”.

Other than the Aldrin Expansion mission in 2.0, mission development has taken a back seat for me, while I look after the rest of the game, keeping track of the bugs, organising the new text for translation and exploring the underlying code of X3. It has been a heck of an experience, but the danger was that as soon as I look at the code, playing the game would not be as much fun. While I still have not had time to play yet, I can’t wait until I do. There is so much in there that I can’t grasp it all or see it all. I’m still seeing ships during testing which I have not seen before! Just last week I saw my first Kha’ak invasion in X3TC; in the sector of Kingdom End, no less. That was fun to watch! ;-)

Simon: Updating the Universe Trader for 2.0

Hi, this is SymTec ltd. from the X3TC scripting team. For X3TC, we had improved the Trade Command Software MK3 in many areas – it got the new “Local Trader” option to make the pilot trade in one area only, a special internal blacklist that would stop it from entering into really dangerous territory, and of course was prepared for the new Terran economy. However, after many players had worked with the UT in their actual games, they told us that things were sometimes not running as smoothly as they should. Apparently, the pilots you hired got rather lazy after a while – just hanging out at the stations’ pubs when the next trading opportunity was just a few stations away, or trading in Energy Cells when there were plenty of other wares around.



For 2.0, I took some time to look over the scripts responsible for the UT, and found ways to correct some of the misbehaviour that people had reported in the previous versions. Reading through hundreds of lines of debug logs, I found the cause of the pilots’ laziness: Trying to be clever, they first checked if the current station’s products could be sold with profit – if that was not the case, they ordered another beer before going on with checking the other stations, and of course forgot about their plans right the next second. I was able to talk the barkeepers into not serving any beverages to working trade pilots anymore, so that should be fixed.

Especially for Universe/Local Traders with a big jumprange, designing the algorithm that picks a good trade run is always a compromise between game performance and trade efficiency – of course, it is possible to check every possible trade route in the whole area and pick the best, but that is performance heavy. On the other side, just taking the first opportunity that the routine finds is very simple, but most likely won’t satisfy you either. The MK3 software uses a method in between those extremes: The routine picks the trading wares based on random numbers and with those wares tries to yield a certain profit; but the probability for each ware type can be closely adjusted. With the new version, I changed these settings: Less energy, more tech wares (for fighters) and bio wares (for freighters).

As you proceed in the game, you have more and more money available, but the universe is a dangerous place for expensive high-tech traders. Creating a fighter escort for your trader is not quite a good idea, because they tend to run out of fuel if the trader uses its jumpdrive a lot and then get killed in the attempt to catch up. One solution to the danger of transporting expensive wares was to use fighter craft for the job: They have a smaller cargo bay and a higher price, but are faster, better shielded and more dangerous to potential attackers than the TS freighters. Several people asked me why they couldn’t employ a Universe Trader on TM class ships – now they can! TM class ships can carry around their own little defence/distraction fleet, have a decent speed and cargobay size, great shielding and weaponry, and are still less expensive than many super freighters: A great new opportunity for the more dangerous areas of the X-Universe.