Status Update

Hello! As you may have noticed, It’s been a long time since we’ve had an update on the front page. We’ve been keeping people up to date off-site, but we’re long overdue for another status update. So what’s happening?

New Hub Website:

You may have noticed some odd behaviour with the website over the last few days, that’s due to us switching hosts and getting our new website ready to go live.

Our plan for the site is ambitious. Ultimately we’d like to use the Space Station 13 domain responsibly and begin offering news and information for both versions of the game, including the many BYOND branches currently in development.

show 1

This means when the site rolls out in the next few days, we’ll have a dedicated BYOND section that will provide links and information to the many community hubs, servers, forums and wikis. Our roots are mainly in the original ‘goonstation‘ branch developed by the Something Awful community, but we’d like to extend an olive branch to anyone that would like to take part.

We’ve also approached several people in the community that are integral to the game’s past (and future) development, and they’ll be contributing a few stories on our behalf.

Development:

The silence may have said a lot, but development has been a struggle as of late. Our focus on rewriting large sections of the game has not only slowed our progress and momentum over the last few months, but a lot of the team’s motivation.

As you know from our last back-end update, there were a lot of systems in place that needed optimising due to the number of messages being sent to and from the client/server. This will probably be put on the backburner while we regroup and think about our next steps. The current plan is to try to get more content into the game.

We’ve also unfortunately lost founding team-member and coder, Enstorm. With the birth of his newborn daughter earlier this year, he ultimately decided that he could no longer dedicate the free time to working on the project while balancing his work and personal life. We want to thank Enstorm for his time, and acknowledge that we have a large amount of respect for both him and his work.

Our artist Supernorn has recently been hired at Chucklefish to begin work on a new title currently entering early development. We wish to offer a huge congratulations to him!

Supernorn resprited the majority of BYOND SS13‘s art assets in early 2009, and is responsible for the majority of the art in SS13 Standalone. Despite his recent hire, he’ll continue working with us to develop the game.

 

The Future:

Do the recent setbacks and barriers mean we’ve given up and cancelled the project? No.

Cpps7Uq

With game development, you hit hurdles and brick walls every day. This is simply the nature of the beast. Anyone who has attempted to develop and design a game will be the first to tell you that it’s a hard path to follow. Space Station 13 is an incredibly ambitious game, with a large amount of systems and simulations interacting and co-existing with each other. This makes the hurdles and barriers bigger and more frequent, especially for a small team with no budget, working for free in their spare time.

There’s a reason all past attempts have stumbled at the first few hurdles, but we’ve got the furthest to the finish line so far. We’re going to keep running.

 

 

 

 

December 26: Development Update

Hello! I hope everyone’s been enjoying the holidays. Since our last update, things have been gradually slowing down as the year reaches its end point. But what’s been happening, and what can we look forward to in the coming months?

 

A few things have happened since our last update. For one, all the art assets in the game have been given a second pass: Mostly recolouring with a set palette, and additional detail added where needed. Here’s an example below, current art assets are on the left, the old on the right:

ZXLo112

While subtle at first glance, the palette makes all the individual art assets consistent across the board, meaning you’ll have a more cohesive look to the game. Lowering the number of individual colours used is also a good way of keeping file size down, and with potentially hundreds of unique items dotted around the station, this is generally a good idea.

Next on the agenda, is a subject that brings terror into the hearts of all our coders. Walls!

Unlike BYOND SS13, Most of the objects in the game are not limited to a specific set of dimensions. (For BYOND, this is 32×32 pixels). This means we can generally make an object as large or as small as we’d like, within reason. However some things do still need to be attached to the grid, especially if they can block atmospheric gases like oxygen, etc. For a long time, this meant walls were 64×64 pixels to accommodate our grid size.

As the lead artist, having huge chunky walls when trying to work with a consistent size and perspective is a bit of a nightmare scenario. Especially if you want them to work well against glass and doors/airlocks etc. It’d mean also making them a similar size, which looks fairly ridiculous. So I pestered. I pestered for a long time. And we were able to rework how walls work slightly. Imagine a grid, now imagine instead of the walls taking up a square, they are instead cleverly placed on the lines between each square!

Not being too happy with overall look of the game, the changes to the walls gave me the opportunity to go back to the drawing board on some elements. I wasn’t happy with how little the game was looking like a space-station. It looked more like a laboratory than anything else..But with all the changes listed above, here’s how it looks now:

wall_dec

I’ve come up with a more sci-fi look to the base wall sprites, and also developed some custom floor trims to really add a bit of detail that was lacking before. The idea is to hopefully have unique art assets for each area of the station. So med-bay for instance could have a unique look from security, or engineering.

But what about the rest of the game?

backend

 

If we’ve struggled with anything during the development of the game, it’s getting the foundations in place now in order to save ourselves headaches in the future. Sometimes these involve going back and rewriting systems that are now working against us instead of for us.

If you’ve been wondering why we’ve been low on game-play demonstrations and in-game content recently, apart from developing this project solely in our free time – it’s mainly because we’re still fixing up these problems. Most of these hurdles have been jumped, and now there’s only one major barrier between us finishing the back-end and working towards adding more content and game-play features! I know some people were hoping we’d surprise them with a Christmas alpha, but developing a game you realise that for the most part it isn’t actually anything other than a set of half-functioning systems and ideas, that takes quite a long time to come together and resemble something fun and playable. Just bear with us, we’ll get there!

The current problem is in deciding how the game components should communicate.

The Client<->Server communication is great and works fine, but the local communication within the client or server was originally using a sort of broadcast where if something happens, that component builds a message and then all the other components check to see if they care about it.

That works, but the problem is you get bogged down in a ton of message spam as more and more things get implemented. Seeing where the system was headed, we realized it had to be fixed before it paints the game into a corner.

The general idea is to move to an event/listener model where each component defines the types of events that can happen, and other components subscribe to those events.
So there’ll only be data sent when it needs to be sent and only where it needs to go.

What’s making it difficult to do at this point is the fact that there’s a ton of existing component messages, and if you just tear them all out haphazardly, you won’t really know what you’ve broken. You’ll just have a bunch of stuff that no longer works.

So the plan is to have all the messages  be catalogued and documented, so there’s a blueprint to use to build the new system and not miss anything, and there’s just a lot of messages and message handlers and the only way to find them all is a lot of tedious looking around and writing by hand. This means we unfortunately have to go back a little bit, but we’ll be in a better position to move forward afterwards.

also

 

As an additional update, the coding for the new website is coming along very nicely, and we hope it have it up and running early next year if not before then! I’m very excited personally to replace the current one with something much more informative. An additional idea is to have a section for BYOND SS13, with a hub of information and links to all the popular branches.

We’ve had a great year for SS13 Standalone. We’ve implemented many systems and written tools that should make the content phase much, much faster in the future. If 2013 has been laying the foundation, I believe 2014 will be the building of the house..

Enjoy your holiday everybody, and we wish you all a very happy new year!

- The SS13 SA Team.

Don’t forget to follow us on on Twitter and Facebook

 

October Media Roundup

Hello again, you’ll notice our last official update on the site was July. Had we been twiddling our thumbs since then? given up and silently closed up shop? of course not!

We’ve been working hard, and posting occasional tidbits on twitter and facebook in the mean time. We’re aware there’s a number of people that only check the front page occasionally, and that’s okay. So what have we been up to? and what are we working on now?

model

Animation is one of the many improvements we can make to the game, now that we’ve switched engines. If you recall an earlier news update, we’ve opted for building our player as a 3D model and rendering out the sprites in 2D.

This technique allows all the advantages of 3D while remaining consistent with our more traditional drawn pixel art.

We’ve written a custom tool to render all of the player animations from eight directions, using point sampling and shaders to preserve sharpness and achieve a pixelation effect. Each rendered frame of animation is automatically exported out as a sprite. Modders will be able to model additional items or tweak textures to create new clothing items, which can easily be exported for use in game.

Below you’ll be able to see examples of the exported sprites, and a short video test of them running in game:

fall1punch1standrunwrunNWrunN runNE runSWrunS runSE runE

This is still a work in progress, and we expect the results to be improved as development continues.

We’ve finally replaced our placeholder Lobby, and instead of having all the information on screen at once, we’ve divided it into a few tabs. The Job Selection screen now allows you to pick between four departments: Command, Research, Engineering and Civilian. Choosing one of these will bring up all the available jobs in that department, along with a short description:

lobby

We’ve added a particle system to the game, and with it, a nifty little particle system editor. This will let us compile particle system presets and reference them in our game objects. With this, we can make effects like fire, explosions, gibs, lasers, crazy weapons effects, reactor cores (and reactor core meltdowns), and anything else imaginable that involves particle-based animation.

Particle_Tool

gameplayupdate

Work is progressing on a new interface design that we hope will make the game intuitive and easy to learn. We approached a lot of new players, and asked them for specific feedback on the BYOND interface. What doesn’t make sense to a new player? Can we make it intuitive without removing complexity? We wanted to retain the hands and the intents system, but give the player much better feedback when they use them:

guitest

Intents are now limited to two modes, Harm and Help - which can be toggled between at the press of a key. Previous intents such as Disarm and Grab are now reintroduced as Actions, and will appear on the action bar contextually depending on whether you have Help or Harm mode active.

An example would be the Carry action. This appears on the Action bar when you have Help mode active, and will allow you to carry a fallen player on your back and [potentially] move him or her to safety, You’ll be able to use both hands with a player on your back, but at the cost of movement speed.

Alternatively, if you had Harm mode active – the carry action would be replaced with the more traditional Grab action. Which you’ll remember being much more aggressive, allowing you to grab hold of players and escalate it into a choke hold.

Actions like Disarm may appear in both Help and Harm mode, as this action can be considered both passive and aggressive in nature.

 

also

Cpps7Uq

Over the last few months we’ve been working on replacing our website and logo with something more informative, polished and professional. Our current website was thrown up rapidly in 2011, and while the game has changed and evolved during development, the site hasn’t changed since it launched!

Those that follow us on socal media will know we have a new logo, designed by the talented Mike Levos. You’ll notice the old logo remains on our site and forum, but that’ll be changing once the new site goes live. We have a  shot below to show you guys how it’s going to look.

Our biggest improvement is getting the twitter on the front page, so those of you that primarily check the site can see we’re active and working hard!

show 1

As usual, if you’re not already following us on twitter and facebook  – Why not? We’re cool!

July 06 2013: Status Update

Hello my friends, Supernorn here with some more words on Space Station 13!

Coding: Since our last update, Keelin and Enstorm have been working hard on the netcode. In coding, this can be pretty unfun, but highly important and necessary work. 

Ostaf has been working diligently on improving our atmospherics code. Support for internals was just added, and more recently he implemented the ability for items to move around with gas. This means that when you expose a room to the vacuum of space, well.. 

We’re still working on these important frameworks, and once we’ve got these out of the way we can really get full steam ahead with adding content. We can already see the potential, we hope you do too!

As always, don’t forget to follow us on twitter, or like us on facebook - where we continue to post small and frequent updates!

May 17 2013: Status Update

Hello my friends, Supernorn here with some short words about two dimensional spacemen! 

Art AssetsI’ve taken an approach to picking a job and then working on the items and objects required to perform it. I chose medical first, as some of the objects had already been completed by synthorange. Here’s a look at some new/old/tweaked items collated together for consistency purposes:

Gameplay features:

Atmospherics:  Basic atmospherics are in, remove a floor tile or open an airlock to watch all the air get sucked out the room. The Hypoxia effect indicator will now pop up to show when you’re taking suffocation damage..

Crafting: There’s a very bare-bones implementation of crafting in right now. Currently you add two objects together and if it matches with the game’s recipes you’ll have successfully crafted an item. This is obviously very simple but will be fleshed out later on down the line. This section of the graphical interface is also fairly outdated.

Health System: Health has been in for quite some time, and is a fairly basic implementation for now. However there are multiple types of injury you can sustain. Getting pierced with a sharp object will cause you to start bleeding and lose health, particularly severe wounds will continue to bleed until you treat them with bandages.


Hotbar: The mechanics behind the hotbar were originally going to provide access to ‘on the fly abilities’ for example, a stab ability if you were carrying a sharp object. Lately this seems like it would be an over complication, and it would make more sense to bring back the intents system. This is still up for debate so we’d be glad to accept feedback…

Don’t forget to follow us on twitter, or like us on facebook - where we continue to post small updates every now and again.

January 29 2013: SS13 Developer Q&A

Happy New Year!

2013 is going to be an exciting and hopefully fruitful year for our SS13 remake. We’re still busy porting our base over to SFML, as discussed in our November Update. This unfortunately involves shooting down the many bugs that pop up from such a switch, so while at the moment this sort of thing feels like a bit of a thankless task, we’re looking at the bigger picture.

A few weeks back we announced that we’d be holding a developer Q&A fielding questions asked from our community. We want to thank those of you for being so patient. It needs reminding that we’re working on this in our spare time, and real life events can often throw spanners in the works for a non-paid project. This January the spanner has appeared in the form of a wave of sickness, that quickly took us out one by one. Here’s the podcast featuring Supernorn, Keelin and Enstorm (Ostaf was sick) discussing some questions raised recently on the current SS13 remake.

Don’t forget to follow us on twitter, or like us on facebook – where we’ll post small updates every now and again.

November 04 2012: Status Update

 

Lobby Screen:

Hello crew!

For the past month or so we’ve been busy little bees, getting our foundations in place and preparing for what we’ll require for alpha. Our resident artist Supernorn has been working on the new lobby screen to replace our rather hideous placeholder!

Here’s a quick (not final) work in progress snap of how it’s coming along. Text content kindly borrowed from Goonstation .

The new lobby screen for SS13

Code:

On the code front, Enstorm has begun switching out our back-end graphics library from gorgon to SFML. Changing to SFML (Simple and Fast Multimedia Library) offers better cross-platform compatibility, better speed and allows us to do some more advanced things rendering wise since we have almost direct access to the OpenGL layer (whereas before we were relying on Directx 9). Opting for OpenGL is also necessary to future proof the game, what with Windows 8 recently dropping support for Directx 9.

Code wise there isn’t a whole lot left for the alpha, with the exception of a few things that could be tidied up and possibly re-factored after the switch takes place.

Human Mobs:

Our recently appointed modeller Hamshot has wasted no time whatsoever, cranking out a human model with a bunch of wearable items. Not only that, he’s in charge of creating our animations. The current method which we’re investigating is the creation of a low-poly 3D model which is then rendered out frame by frame and exported as a selection of 2D sprites. This method will save hundreds of hours of time and effort that would be required to do this by hand.

Here are some extremely first pass preliminary tests, with placeholder textures. But these generally show the method we’re investigating. Also note Hamshot has created a seperate walking animation for when you’re wearing heavier gear!

Preliminary first pass results below. These are tests to see how effectively we can achieve the ‘pixel look’ from a sprite exported from a 3D model

Preliminary first pass of 2D Sprite exported from 3D model Preliminary first pass of 2D Sprite exported from 3D model.

Got feedback? Join in the discussion here! Don’t forget to follow us on twitter, or like us on facebook – where we’ll post small updates every now and again.

October 17 2012: Status Update

Behind the scenes we’ve been updating and rewriting old code alongside creating debugging tools. A rather large map format rework has just been completed. Next on the list is an update to the placement manager – the system that lets you place objects and tiles in the world.

Hamshot has joined us and will be responsible for the 3D work we will require for future human sprites and their animations. Nannek, a long time coder for goonstation has also volunteered to help out with coding duties.

Apologies for the news blackout folks! when we have something worthy of the front page it gets a new post on here, with smaller updates usually posted on our forums and twitter pages. We’re expecting a big news post to happen around us hitting our alpha milestone, which we’re close to approaching!

June 19 2012: We need to talk about Mobs

Currently we’re working on some internal tools and trying to figure out how we want to tackle a few things.

Our first real barrier is how we want to get human mobs (aka the players) in. This has slowed progress down a fair bit recently as we discuss our options and what we can do with the resources we have available. Currently the player is a 2D sprite with 4 directions and a ton of separate items and objects for each. The prospect of animating players has looked more and more implausible with the current method, as we came to realize just how much work and time we’d need to put in. A walk cycle for each direction including each item of clothing and carried objects alone would amount to hundreds of thousands of frames of animation , making modding clothes and adding other animations pretty undesirable. This has been a bit of an elephant in the room for some time.

We looked at the possibility of 2D puppet animation but decided visually it looked a little off with the rest of the art. The stuff Project Zomboid showed off really impressed us however, and we contemplated using a similar technique of creating a crude 3D model with a range of animations and then exporting each frame as a 2D sprite to blend with the rest of the 2D assets.

This would mean we could animate the character once and have all four directions for each action instantly, allowing for more complex stuff like attack animations etc. With very little extra work.

Keelin has been working on a toolset that would take an animated model and export it, and we’ve put the word out that we’re looking to add a 3D character artist/animator to the team.

Thanks!