Dev Blog #8 – Lost in Space?

This week I’ve been recovering from the great time I had showing Space Station Continuum at EGX Rezzed last weekend. The response was absolutely fantastic, and I’m immensely grateful to everyone who played the game and shared their thoughts and excitement for its future.

The game also managed to attract the attention of a variety of games journalists and YouTubers. Here’s a couple of the videos published so far:

Thanks to the testing by players at Insomnia 62 at the end of last month, the demo shown at EGX Rezzed was much more stable and allowed players to spend a lot more time with it. As a result, there were some truly enormous and complex stations made by some particularly engaged players (thank you!) which began to show some cracks in the existing astronaut pathfinding system. In short, they were getting lost.

Astronauts in Space Station Continuum each handle their own movement. They choose a target location based on what they need or want to do, and find a route to that location using a pathfinding algorithm. This algorithm is based on the A* Search Algorithm – common in computer science for a range of applications. Unfortunately, the current implementation looks like it was written by somebody who had skimmed a couple of articles on A* pathfinding and thrown something together that looked vaguely similar. That’s because it was!

I first designed the pathfinding system in Space Station Continuum many months ago, during the earlier prototyping phases of development. It worked, for the most part, but struggled with finding its way around more complicated space stations full of dead-ends. It’s something I’ve been meaning to revisit for some time now, and this past week I finally dived back into it.

What was wrong?

The existing implementation shared some similarities with a functioning A* algorithm, but had a couple of important pieces missing. First, it wasn’t generating the open set (also called the open list) correctly. And second, it wasn’t properly calculating the cost of each possible path. This resulted in astronauts being unable to find their way to their destination in anything other than the simplest of stations. This was obvious fairly early in development, so I had made them capable of pretending they had already reached their target any time they got lost. This meant they could eat, sleep, and even use the bathroom in rather inappropriate places.

bathroom.png
Not there you’re not!

Changing the current implementation to fix these problems was going to be time consuming, messy, and inefficient. So I scrapped the whole thing and started again.

Rather than explaining A* pathfinding myself, here’s an excellent video to do it for me:

A big difference between the solution described in the video and the one used in Space Station Continuum is the lack of a grid-based navigation system. Instead it uses a number of “Navigation Nodes” placed at appropriate locations within each of the station modules. These act as a guide to show the astronauts where they can and cannot go. By showing these nodes and colouring them differently, we can visualise how the algorithm works.

The blue node shows the destination
The red nodes show rejected paths
The green nodes show the chosen path

It’s quite interesting to watch the astronauts moving around with the nodes turned on. It seems that they’re now able to cope with much larger and more complex stations than the one shown above, and I haven’t seen them going to the bathroom in the hallways for a while! Perhaps I’ll leave this visualisation mode in as a toggle-able option in the upcoming Alpha of the game so you can see it too.

That’s it for this week. Don’t forget to Wishlist the game on Steam and join the discussion on Reddit to be the first to hear about any future announcements. There’s some exciting things in the works! I’m going back to watching astronauts navigate some cruelly-designed mazes to get to the bathroom. See you next time!

– John

Dev Blog #7 – Insomnia Games Festival i62: A First Timer’s Experience

This past weekend I was at the Insomnia Gaming Festival in Birmingham, UK, showing Space Station Continuum in the Indie Zone. This year’s Indie Zone was hosted by the excellent guys & gals at Payload Studios – creators of TerraTech.

My journey to Insomnia began way back in November with an optimistic application to have my game featured in the Indie Zone after reading about it in a tweet. Perhaps all the time I spend on Twitter isn’t completely wasted after all! Back then I was very much in the ugly prototyping stages of development, so the demo and screenshots I sent with my application weren’t the best. I wasn’t holding out much hope, but to my surprise I was contacted in February to say I’d been accepted! I quickly ran through a roller coaster of emotions that began with excitement and ended with the terrifying realisation that now I actually needed a working demo, and I only had one month to build it.

By some miracle I managed to pull this off, and before I knew it I was driving up to Birmingham to setup the day before the show. After getting more than a little bit lost finding my way around the back of the NEC, I arrived to find the HUGE collection of Indie games signposted by the signature inflatable tentacles of the Tentacle Collective.

20180330_093139

A lot of the other developers weren’t there to setup at the same time I was, so I didn’t get to say hello to too many people yet, but that did mean I was able to dive right into installing the demo and praying that it worked.

Tip: Bring your build on at least TWO thumb drives in case one decides to die
Tip: Bring your build on at least TWO thumb drives in case one decides to die

Success! The demo worked, was relatively bug-free, and it looked great on the AOC monitor provided for the show. That was pretty much it for Thursday. I was staying with a very generous friend near the venue for the weekend (thank you Vesna!) so I didn’t have far to go to get an early night and prepare for the opening day ahead.

Friday started bright and early – arriving at the NEC an hour before the doors opened to make sure nothing had broken overnight, and cover every available space on the table with badges.

20180404_103201.jpg
Badges. Badges everywhere. These were very popular

It didn’t take long for the Indie Zone to start getting busy, and within the first hour more people had played Space Station Continuum than ever before!

20180401_170218.jpg

Over the next few days around a hundred or so people played the game. This was an incredibly valuable opportunity for me to see how different people reacted to the game, and how I could improve the tutorial to better explain the building mechanics.

And I’m pleased to say the reactions were great! A lot of people instantly understood the game and where it would be going in the future, and were eager to talk about all the features they’d love to see. I had an especially interesting chat with Ben Moss-Woodward of Lave Radio – some of which you might get to hear on his show in the coming weeks.

Of course, a playtest wouldn’t be a playtest without a healthy list of bugs. Some of these were fairly mundane UI issues (most of which I was able to fix in the mornings before the show), and some were truly spectacular game-breakers. Including this demonstration of what happens when you destroy a few dozen solar arrays that have all been built in the same spot:

 

So if you were at the show and you came to play the demo, thank you! All the feedback you gave will go directly into improving the game, and at least a couple of the ideas we discussed have already been added to the list of planned features.

Extra special thanks to my friend Rob, who sacrificed his weekend to help me show the game and look after the booth when I couldn’t be there. You rock, Rob.

I’d also like to shoutout some of the other developers who were there, and say thank you for making me feel welcome at my first event as an exhibitor. Make sure you check out:

And of course, TerraTech by Payload Studios.

The next opportunity to play the Space Station Continuum demo will be at EGX Rezzed at London’s Tobacco Dock from the 13th to the 15th of April. Can’t wait to see you there!

– John

 

Dev Blog #6 – Pixel Art, Screen Resolution, and Zooming

One of the joys of a good construction/management game is being able to zoom in and out to marvel at your creation at varying levels of detail and activity.

One of the joys of good Pixel Art is the crisp, pixel-perfect lines and details.

These two things do not go well together.

To understand why, you have to understand one of the fundamental constraints of working with Pixel Art in games:

You can’t ever, EVER, cram more than one pixel of art into a single pixel of screen.

If you try, you’ll see odd visual effects as the game engine tries to decide which one of the two (or more) possible pixels to display in the single screen pixel available. It’s especially noticeable with sprites that feature grid-type patterns.

Above, the solar panel on the left is using the correct pixel density for the screen. The panel on the right is only out by 2.5%, but the difference is obvious.

So how can you overcome this problem? Especially when you don’t know the resolution of the screen your players will be using?

With MATHS, of course!

Luckily for us there’s a handy, tried and tested formula for figuring out the orthographic size (kind of like the zoom-factor for a 2D camera) that your game camera should use. It looks a little something like this:

Orthographic Size = ( (Height of screen in pixels) / ( (Zoom Factor) * (Pixels-per-unit) ) ) / 2

Most game engines will allow you to get the screen height fairly easily. In Unity it’s as simple as “Screen.height“. Pixels-per-unit refers to the number of pixels being rendered for each game-unit. Think of game-units as a measure of distance, so one game-unit could be equal to one metre in your game. A pixels-per-unit setting of 32 would therefore mean you’re fitting 32 pixels of sprite into every one metre of distance. This number will vary based on how you’re handling size/distance scaling in your game.

The Zoom Factor can be used for zooming in (making the sprites bigger), but not for zooming out (making the sprites smaller). A Zoom Factor of 1 gives you a one-to-one mapping of art-pixels to screen-pixels. You can increase the Zoom Factor, but only by powers of two CORRECTION: the Zoom Factor can in fact be any integer (whole number). I got this mixed up with the below section about shrinking sprites. Thanks to Reddit user /u/logibutt for pointing out my mistake! A Zoom Factor of 2 will double each art-pixel onto a 2*2 grid of screen-pixels. A Zoom Factor of 4 will quadruple each art-pixel onto a 4*4 grid of screen-pixels, and so on.

Pixels can easily be doubled without loss of information.
Pixels can easily be doubled without loss of information.
But shrinking images with single-pixel details will result in losses.
But shrinking images with single-pixel details will result in losses.

This means that when working with Pixel Art, there is an inescapable Minimum Zoom Level that corresponds directly to the resolution of your sprites. The more pixels contained within your sprites, the less you can allow your player to zoom out. The only way to get around this is to create half-resolution versions of all your sprites, and swap them in when the player zooms to half the true size of your sprites. A half-resolution sprite will allow you to use a Zoom Factor of 0.5, quarter-resolution 0.25, and so on. This works well but involves a lot of extra artwork, so if you’re going to go this route make sure the extra zoom level is really important enough to justify the effort/expense.

So if you’re going to have zooming in your game, make sure to design your Pixel Art with these limits in mind. Higher resolution sprites may allow you to include more detail, but they’re going to take more screen space.

And that’s the other joy of working with Pixel Art:

Less is very often more

Dev Blog #5 – New Year, New Modules

Happy New Year!

We begin 2018 having some brand new Station Module variants to share.

Here they are in action:

A super fast time-lapse of Space Station construction.
A super fast time-lapse of Space Station construction.

Those lines you see streaking across the upper atmosphere are the Command Modules launching and re-entering.

Progression in Space Station Continuum is separated into Eras. Each Era has its own technologies, challenges, and design styles. All of the new Modules featured here are inspired by real space station hardware of the past (and present). Each Module has a unique interior and matching Corner Module for 90-degree attachments.

Let’s begin with the first Module you’ll start with in the game. Its design is inspired by Skylab. Skylab was NASA’s first space station, launched in 1973 and de-orbited in 1979. You’ll need to look after yours to make it a bit more permanent!

Here’s Skylab as it looked in 1973:

skylab
Skylab in 1973. Image by NASA

And here’s how Skylab Era Modules will look in the game:

A Skylab Era Module
A Skylab Era Module

And here’s a bonus image with a Skylab Era Solar Array:

Skylab Era Module with deployed Solar Array
Skylab Era Module with deployed Solar Array

Next up, the Soviet Era. Mir, launched by the Soviet Union in 1986, was the first modular space station to be assembled in orbit. Pictures of Mir in the 80’s are hard to come by, but here’s how it looked in 1998:

Mir in 1998, taken during STS-89. Image by NASA.
Mir in 1998, taken during STS-89. Image by NASA

Here’s how your Soviet Era modules will look in-game:

A Soviet Era Module
A Soviet Era Module

As you can see, we’ve taken a bit of artistic license here to Russian-it-up a bit. Hopefully it will be clear why after seeing the next Era:

The Shuttle Era. Despite its many issues, the Space Shuttle was undoubtedly a revolution in the capabilities of space station construction. So much became possible that simply couldn’t be done before, and this was a very exciting time in spaceflight history. We’ll cover what that means in-game in future updates, but for now let’s take a look at the Shuttle Era Modules you’ll be launching.

These Modules have been heavily inspired by Zarya – the first module of the International Space Station.

Zarya as seen in 1998. Image by NASA.
Zarya as seen in 1998. Image by NASA

You may notice that Zarya bears a striking resemblance to many of Mir’s modules, hence the artistic Russian-ifying of those Modules in-game. Here’s the Zarya-inspired Shuttle Era Modules:

A Shuttle Era Module
A Shuttle Era Module

And finally (for now), the International Era.

The International Space Station stands (or flies) as a monument to the previously unseen level of international scientific collaboration that created it, and continues to support it. Modules, robot arms, experiments, and resupply vehicles from all over the world have contributed to building the single most expensive object ever created by humans.

The International Era will bring lots of exciting new equipment and activities to Space Station Continuum, and the Modules you’ll be launching are inspired by some of the later modules that make up the ISS. Specifically, the Destiny Laboratory Module.

Destiny seen during installation in 2001
Destiny seen during installation in 2001. Image by NASA

Here’s how the International Era Modules look in-game:

An International Era Module
An International Era Module

I’m incredibly happy with how all of these have turned out, but personally this one is my favorite! What do you think? What pieces of space history would you like to see featured in Space Station Continuum?

See you in the next update for more exciting developments!

 

Dev Blog #4 – Interior Design in Space

Space station modules are cramped. Very cramped. And they stay that way forever. If one day you decide you want a nice new kitchen, you can’t just knock through a wall and extend into the garden. To alleviate this problem, and to make it easier to add newer equipment to older modules over time, NASA and other agencies have adopted the International Standard Payload Rack (ISPR). The use of the ISPR means that anyone can design a new piece of equipment and know for sure that it will fit on board, so long as they follow the standard measurements.

Space Station Continuum makes use of a similar system for arranging Interior Equipment. This Dev Blog will show you how it works.

When planning a new Module for your station, you’re presented with a “ghost” image of that Module showing where it will go.

A Planned Module.
A Planned Module.

You can then drag-and-drop various items from the Interior Equipment menu into your planned module. When you do, you’ll see Equipment Racks appearing on the rear wall of the Module to show you where that particular item will fit. Clicking on a location you’re happy with will add the Equipment to the Launch Manifest.

Adding Equipment to a planned Module
Adding Equipment to a planned Module. View Full Size

External Equipment, such as Solar Panels, can be added in the same way.

Adding Solar Panels to a planned Module.
Adding Solar Panels to a planned Module. View Full Size

When the Module is launched into orbit, any Equipment added to the plan will have been pre-installed on the ground.

A new Module docking at the station.
A new Module docking at the station. View Full Size

But sometimes you’ll want to add new Equipment to Modules that are already in orbit. This is an area where your Astronauts can be put to work.

When planning a new launch, Internal Equipment can be added to existing Modules in exactly the same way it’s added to planned Modules.

Adding new Equipment to an existing Module.
Adding new Equipment to an existing Module. View Full Size

The new Equipment will be included in the cargo hold of the Command Module that comes up with the next launch. One of your Astronauts will then carry it to its planned location and install it in an Equipment Rack.

Standard Modules contain a 4×2 grid of possible Rack locations. At the beginning of the game most Equipment needs only a 1×1 space, with Beds and Zero Gravity Toilets being a couple of exceptions needing a 1×2 space.

But what about Equipment that won’t fit inside a 4×2 space? For that you’ll need bigger Modules, and those don’t come until much later…

See you in the next Dev Blog, and be sure to check us out on Twitter and IndieDB!

Dev Blog #3 – Art: It’s a Process

When I began working on Space Station Continuum in March of 2017, I didn’t know everything about what the game would eventually become (I still don’t). One thing I did know, is how I wanted it to look. I grew up in the early 90’s, playing games on my Sega Genesis on an old CRT in the living room. The age of sprite-based graphics and upbeat chip-tunes fills me with a fondness and feeling of nostalgia like no other. In today’s world of preorder bonuses and microtransactions, what better way to escape to the good old days than to take the aesthetic of the game back to its roots?

I also wanted it to be mine. No matter what happened, I knew I wanted this game to be made by me, for me, with no compromises. In the very early stages of development, I thought that meant doing absolutely everything myself. The design, the programming, the art, the music. Everything. Since then I’ve learned that my time and energy is better spent working on the aspects of development that I can actually do – like the design and programming – and leaving the more artistic elements to, you know, actual artists.

So this week I’d like to talk about the process of getting the art of Space Station Continuum to where it is today. From spartan prototype, to basic developer art, to the realisation that I cannot draw to save my life.

Step 1: Prototyping

Every game begins life as a bare-bones prototype. Something simple to demonstrate the core mechanics, and verify that the concept can be fun. Space Station Continuum’s prototype looked like this:

prototype_screenshot

The purpose of this prototype was to test the heat-flow mechanic between station modules of arbitrary sizes. It worked, it was fun to mess around with, and it looked awful. But that’s ok, it’s just a prototype. This early version of the game was just for me to work on everything that’s going on in the background. It didn’t have to look good or make sense to anybody else just yet.

Next I needed to work on the basics of the construction system. Creating new modules, dragging and dropping them into place, that sort of thing. I added some buttons, a new type of station module, and a background image. Now it looked like this:

construction_screenshot

Impressive, right? Again, this version of the game was purely functional, and only needed the most basic of visuals to show me what was going on. Eventually I was going to have to start showing this game to other people, and that meant I’d need something more than a few white blocks covered in text. I, a software developer, needed to make some – gasp – art. How hard could that be though, right? This is my game, surely I can make the art, no problem. Oh boy was I wrong.

Step 2: Developer Art

“Developer art” is a term used to describe art which is terrible. And the art I made fits that description perfectly. So I’ve got that going for me, which is nice. I began with the basics. The first thing I needed was a station module. What does a station module look like? Well, it’s kind of cylindrical, and it maybe has some windows. Easy:

double_res_module

Oh. Well that’s, uhhh… something. But it’ll do for now. Then I made a smaller one for the corner modules, threw together a star field and the Earth’s surface, and here we have the first screenshot I showed to another human:

first_art
Space Station Continuum: Microsoft Paint Edition

Clearly this isn’t close to being an actual game yet, but you can start to see what’s going on, and perhaps get an idea for what it could become in the future. That’s exactly what developer art is for. It gives you a starting point for discussing the game with others, and helps visualise new features as you begin to flesh them out.

At this point I was still confident that I’d be able to do the final art by myself. Everything so far was just a first pass, and hadn’t taken me very long. I was sure that once I spent any significant time on the art it would come out how I envisioned it. So I did, and it didn’t. I remade, remade, and remade everything you see above over and over again, but I never managed to get the game looking how I wanted it to. The furthest I got with my own work was this:

One of the last screenshots containing only my own work, including some early UI elements.
One of the last screenshots containing only my own work, including some early UI elements.

The art I was drawing was coming out okay, but it wasn’t great. It was also taking up an enormous proportion of my time, to the point where I was eventually spending twice as long wrestling with pixels in GIMP as I was writing the mechanics of the game. It was time to throw in the towel, embrace my limitations, and find somebody who knew what they were doing.

Step 3: Bringing In The Professionals

Enter, Jay Knox and Simon Butler. Since getting involved with the project back in July, Jay and Simon have been doing some truly excellent work taking Space Station Continuum from prototype to polished.

The best way to demonstrate the benefits of bringing real artists on board is to show their work side by side with mine. First, a station module interior:

 

Look at that! It’s so good! This was the first piece of art I commissioned when I was trying to decide whether to continue doing it myself, and it made that decision for me instantly. Seeing this instantly brought me back to iconic pixel-art classics like Flashback. Just wait until you see this in-game, with equipment stacked up and astronauts floating around. It’s amazing.

Next, possibly the most important component of your space station; the Astronauts.

Astronauts: My original developer art vs Simon's fully animated version.
Astronauts: My original developer art vs Simon’s fully animated version.

Not only do the astronauts now look like humans rather than anaemic chimpanzees, but they’re also fully animated. With multiple idle animations, run cycles, and more to come. We’ll look at those in more detail in a future dev blog.

On top of these, Space Station Continuum now has updated module exteriors, solar arrays, beds, treadmills, backgrounds, and more. With more coming all the time. I’m very excited to continue sharing the evolution of Space Station Continuum’s art with everybody as development goes on.

For now, I’ll leave you with a comparison between how the game looked five months ago, and how it looks today. Can’t wait to see what it looks like five months from now!

Space Station Continuum: May 2017
Space Station Continuum: May 2017
Space Station Continuum: October 2017
Space Station Continuum: October 2017