Dev Diary: That is not dead which can eternal lie

Fear not, we haven't actually disapeared off the face of the earth. Like a deep sea monstrosity, being unheard from for a long peroid of time is no indication of whether we're alive. We do however all apologise for quite how terrible we've been at keeping you all updated on our progress.

What's been going on?

Despite our silence, we have been busy. As well as the expected game development, which eats away at your life; we have had one or two unexpected crises, and life has at times just been hugely inconvenient.

June. June was not very productive. I took some time off to see family, and not stare at code all day. This happened to coincide with Fabrice finishing university and needing to find a new place to live, and Mo also got a new job. The combination of these events made it difficult to get a lot done, particularly for things that needed some cooperation to do.

In July, code wise I'd managed to get back into the flow of things, and managed to make good progress on endless mode (which I'll go into in more detail later). Still had a few hiccups as Fabrice, who is the project lead on Starship Mechanic, moved into his new place and new job at the start of the month. For the most part we managed to find the time to iron out the small details that needed it though. The main event of the month, was that our sprite artist Ben Reid was going to have to pull out of the project. You may remember us mentioning him many posts ago, and he pretty much saved our arses in the build up to Rezzed. However, he was doing what he could in the freetime he had around work. After getting himself a new, better job (a lot of that going around it seems...) he didn't have enough freetime to dedicate to the project. Unfortunately, we still have sprites that need to be made and no one else in the team is able to pick up the slack in that area. Since then we've been scrambling to try and find a freelance artist we like who can help us out, which we're now finally close to having sorted. We should hopefully be able to make an announcement on all of that soon!

And now to August, which we're still in. So far, pretty uneventful. Started to make some good progress with a UI and style overhaul, our first attempt was somewhat rushed with us needing to have something done in time for Rezzed. Since then we've reevaluated what we have, and are finally starting to nail down how we want it all to look. Code is coding, starting to do some balancing and polishing of endless mode, and as of this week am now working out how to make this whole 'saving and loading' thing work. I've heard its pretty important.

Endless Mode

I made mention earlier that we've got to the point where we can start balancing and polishing endless mode. That isn't to say that endless mode is finished, there is still plenty we want to add to it in order to increase the variety of things the player will be asked to do. It is however in a state that it could theoretically be played continuously for a long peroid of time. I'm certain there are a million tiny bugs lurking, waiting to be found in it as well. Like so many monkeys, we'll probably be picking them out for months.

Endless Mode - Bounty Flowchart

Low Tech Development

It works pretty much as we described it in our last blog post, if you have a long enough memory to remember it. The game is broken up into distinct randomly ordered missions, which are themselves constructed from a series of semi random objectives. Completing a mission will net the player an amount of scrap that can be used to improve the ship for future missions. Playing for a long time should require the player be sensible about how they upgrade their ship. Completing missions as efficiently as possible maximises the amount of scrap collected by the player. This however means we have, approximately, a million different factors that we'll need to consider when balancing. For instance: how many more enemies should you have to deal with in the next mission in order to appropriately raise the difficulty; how do we make sure that the player can earn enough scrap to be prepared enough for the next mission; how punished should the player be for failing an objective within a mission... the list goes on.

New Engineering Bay

One of the things we found necessary to polish, based on lessons learned from Rezzed, was the Engineering Bay that the player had to work in. One of the recurring comments we got was that the bay was kind of unneccessarily huge. Lots of empty space, and it took quite a long time to get around the ship when trying to perform maintenence. As a response, its possible we went too far the other way. The new bay is much more cramped. We think this is a good move for various reasons. First off, it makes wiring much more of a challenge. When you install your new weapons system, you should now have to think about how you're actually going to connect that up to your battery. It also makes fires much more dangerous. With everything being so much closer together, even a small fire can cause a lot of damage. Lastly, you don't need to spend quite so much time just walking to the next place. It may turn out we've overdone it and we need to put some space back in, but hey, thats what playtesting's for!

New Engineering Bay

Hopefully the engineer isn't claustrophobic

Mechanics Changes

We've also made a number of key changes to certain systems.

Engine

So, we're getting rid of the engine bots that carry fuel around as a mechanic. We should have done this a long time ago, but we were really keen on the idea and so held on to it even though, honestly, it didn't work. The way it used to work is that the engine bots in the system would carry fuel from a depot to a furnace, with the final efficiency of the engine being a product of the fuel in the furnace and power to the system. The speed of the bots themselves could be set to either safety, normal or overload, which allowed the player to define bursts of activity to get more fuel into the system when they needed it. Unfortunately, this was very difficult to balance as we didn't want any mode to be clearly superior but it was hard to tell how much difference a speed increase to the bots would make. It also gave the player very poor feedback. They could change the setting from safety to overdrive, but because the fuel still needed to be moved it'd take a long time to get any discernable improvement in engine efficiency.

This is being replaced with just the safety/normal/overdrive settings. The setting will define by what amount the efficiency is modified (so an engine in overdrive recieving 20 power/second would might perform like an engine getting 25 power/second on normal), but will also increase the rate at which the engine degrades. This means that if the engineer wanted to have the engine operate in overdrive for a long peroid of time they could stand next to it repairing it continuously to counter the increased durability reduction. Of course, this doesn't necessarily mean that the bots will be gone. They may be kept around as a visual element in the system, but they will at the very least live on in our hearts.

Life Support

The core functionality of life support hasn't changed. You feed it power, it lets everyone on the ship keep breathing. It's a good, solid simple system. The change we're adding to it is more to solve one of our other problems. Namely, that the player couldn't sprint. This was deliberate, we didn't want the player to be able to sprint everywhere all the time. They're a mechanic, not an athlete. However, this stopped making sense when there was some kind crisis. If the ship is currently engulfed in flames it makes sense that they might want to pick up the pace. Our solution to this is to have a sprint meter that had to be manually refilled, which is where the life support system comes in. Now, if the mechanic is running low on energy, they can walk over to the life support system and brew themselves a hot cup of coffee. Giving them the energy they need for the next major catastrophe.

UI Overhaul

Ah user interfaces. So important, such a pain in our collective behind. One of the reasons for this is that with the new mechanic changes above, those systems will need to be redesigned anyway. The main reason though, is that the current UI really doesn't work. Several interfaces manage to feel cramped, while also not showing all that much information. When we took the game to Rezzed we discovered that several elements of the interface, that were really important, just weren't getting seen. It was also pretty flat and lifeless. If the player wasn't doing anything neither was the interface. This helped make the world feel pretty flat.

So, after many discussions, we've started to work towards a new UI that keeps what we thought worked well, but also works to improve on what went badly. Looking at ways to include small idle animations, generally have things move around more, how to draw the eye to important elements. Hopefully, soon, we'll be able to show you what we've been working on!

Thanks for bearing with us! Watch this space, as we will have some big announcements in the not too distant future! Till then, we must contine to face the antediluvian horrors that confront us all.