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:
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:
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?
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.
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