I’ve decided that with both Eridani and Teide being quite uninteresting as far as planetary bodies go, the Lyota System (first system in the game) needs to be a little more impressive. Both Eridani and Teide systems are intended to be basically lifeless systems. In Lyota, I’ve added an additional moon as well as a gas giant. Lyota (the earth-like planet) is supposed to be a moon of the gas giant. At certain perspectives, this doesn’t look quite correct. Still working on it. I have not tried it in stereo 3D yet, but I imagine that a similar problem would exist if a 2D photograph were taken in real life without any point of reference to account for size.
I’ve been working on programming missions and polishing up the existing missions. We are still waiting for deliverables from various people we are working with, so in the meantime I am fleshing out the missions and thinking about the missions to come later in the game. I wanted to share this screenshot, it doesn’t show much; but it’s something I’ve been working on for a new mission in Eridani. Originally, Eterium’s escort missions only allow for a single ship to be escorted. This meant boring missions like escorting a freighter, or occasionally escorting something more exciting like a destroyer. Since the player’s carrier, the Canopus, herself always has escorts, it was impossible to do a mission where you escort the Canopus. I’ve modified some code and added some new features and we now have support for escorting multiple ships at the same time.
This screenshot is from an autopilot sequence where the player is escort a very important freighter to a jump point. The Canopus and her fleet have come along to provide extra assistance (this is a very important freighter — don’t want to give away any of the story though).
(Click to enlarge)
You’ll immediately notice the Canopus and her two destroyer escorts, behind her is the freighter in question. If you look closely at the center you’ll notice the player’s wing, four Sagaris medium fighters in a diamond formation. But if you look further out from the center and in front of the diamond formation you’ll see 2 Sagaris and 2 Talwar fighters flying additional protection.
I haven’t scripted the battles yet, but I’m envisioning something similar to the massive battle in the first mission of the Beid System, except the Canopus wouldn’t be in as much immediate danger. I’m also thinking about having the Canopus scramble several bombers to help take out capital ships. This jump point is going to be well protected, but we need to get the freighter through at all costs.
While we are working with a writer to rewrite the Eterium story, I have been given time to concentrate my effort on some matters of polish. Continuing to create missions when we don’t know exactly where the new game will take us would be a waste of my time. I have been concentrating on matters of UI. You have already seen screenshots from the new simulator and the ship loadout screen. Today, I am bringing a couple screenshots from our new ship library. While serving on a carrier, you will have access to a ship library that will contain detailed information about all known ships. The library heavily borrows components from the ship loadout screen, and actually the loadout screen has been improved considerably as a result of this. Here are a couple preview screenshots:
I’ve been working on the mission simulator. The simulator will not only allow you to play “historic recreations,” but also customize the procedural mission generator to create new missions. There will be more missions by the time the game is released. The ones currently in the simulator are placeholders, although I am pretty sure Battle of Vega and Battle of Procyon will be in the final release. I am also thinking about adding mini-campaigns in the simulator that feature a series of missions. Here are a few screenshots from the simulator UI that I’m currently working on.
I am working on the last few missions before we release a development beta for testing (to kickstarter contributors at the beta level). These last few mission in the Teide System deal with the assault on a Revi Mining Station. In the previous post I showed a couple screenshots of the mining station in game. This is the first pass on the mining station, the final art will look a lot better!
In this multi-part mission, the player will lead an assault on this heavily armed and well-defended station that is critical to the Revi war effort.
I’ve been working to improve the lighting on the cockpits. Originally most of the cockpit lighting was baked into the texture. Now the cockpits react to the environment a lot better. The reason I decided we needed to do this is because I am working on adding missions in the Teide System. The Teide System is a new system added to the game that has a brown dwarf star. As a result, the environment very dark and the bright cockpits looked out of place. Also I was not very happy with how the cockpits looked when launching from the carrier as they did not react to the lighting inside the landing bay like the ships do.
Screenshots of new Lighting:
Preview of the Teide System (still early in development)
One of the complaints that we have had while play testing Eterium was that the navigation hazards like asteroid fields and mine fields were too difficult for some players. Unlike the enemy AI, nav hazard difficulty did not dynamically adjust. Adjusting difficulty for a nav hazard is much more difficult than an enemy AI. The enemy AI can have its abilities updated in real time. Without major replumbing, nav hazards can only have their difficulty set at the beginning of the mission. Furthermore, enemy AI difficulty is not saved between deaths. When the player reloads a checkpoint, he also reloads his difficulty. The reason for this is that in the act of dying, the difficulty settings are basically destroyed. If difficulty carried over between reloads, then the game would become ridiculously easy. Since that AI adapts in real time, it really is not necessary to carry the difficulty over after death. But in the case of nav hazards, the only real way to determine success or failure is whether the player crashed into a hazard or not. In the case of asteroids, most collisions, especially at the speed the player is likely flying, are fatal. Nav hazard difficulty must carry over between missions. But we cannot allow the nav hazards to get too easy; sometimes the player makes a mistake and dies in an asteroid field, this does not mean that the nav hazards should get easier.
Note: These updates will not be added to the demo (anytime soon). We are pushing forward with development of the rest of the game and releasing another build of the demo, with just certain new features integrated, would take a lot of time. So these are proposed changes, many of them already implemented in the beta version we are working on.
These changes are based on feedback we have received on the demo. The first thing we have done is added two new targeting keys that can be assigned to keyboard or joystick. Target enemy ship attacking the ship I am escorting (this has no relevance in the demo, since there aren’t any escort missions) and target enemy ship attack my wingman. These have yet to be mapped to the xbox controller because I am still deciding how I want to do that. I am thinking about having double tap of X select enemy attacking the ship I am escorting.
For mouse controls: holding down the middle button and moving the mouse side to side now rolls your ship. Pushing the mouse forward and back (beyond a generous deadzone) increases/decreases speed.
For the Xbox Controller: Pushing the Right Stick (usually used for Roll) forward and backward (beyond a generous deadzone) gives you fine tune control over increase/decrease speed. (It used to be that you had to hold down Y for a second or two, since tapping Y sets full throttle). Since you can get up to speed very fast with the right stick, I am thinking about remove Y and A as full throttle / zero throttle and reassigning new commands to those. Although I have gotten used to tapping those buttons for quick speed changes. We’ll have to do some play testing with both ways and see how it works out. There are very few buttons on the xbox controller, so the more I can free up for other commands the better.