It’s been quite a while since my last post but it’s all for good reasons!
The pixel art style has been shelved a little (not totally) in favour of a more sci-fi focused art style for the user interface.
The planet selector and title screen have seen the biggest visual changes.
The station itself is now much bigger and comes complete with two docking bays when the player starts a new game. Infoboxes appear above rooms when the player hovers over them with their mouse cursor. These boxes will tell you what a room is used for and it’s current status.
In other developments. you can now recruit a crew member and have a ship fly in to drop them off. At the moment this happens within one in-game hour of you recruiting the crew member. This will change, as even at faster than light speeds you are still pretty far away from Earth.
I’ve spent a lot of time working with pathfinding in the last few weeks; particularly with regard to ships. At the moment the only use case for ship movement is the transport ship that arrives to drop off crew members.
I’ve also had a lot of work to do on the Space Traffic Control element. When a ship is needed (eg: a new crew member has been recruited) then they will be seen on the arrivals board with an ETA. When the ship arrives. it will wait at a pre-determined point and then request docking clearance. The player can then choose whether to clear the ship for docking or to turn it away. In future, there will be negative consequences to turning away a scheduled ship, so you have been warned 🙂
For this to work, I’ve had the task of programmatically simulating the conversation between the ship and the station that allows the ship to request clearance. the station to reply with ‘yes please dock’ and then for the ship to find the next available docking back and move to it, stopping when it arrives. It’s just logistics and should be really boring but I have to admit it was fun to produce.
You can also now purchase and install systems. Each system produces vital resources for your station. At the moment there are only some basic starter systems which produce essentials like water and oxygen but I will be adding more as the need arises.
I’m moving on to work with how the crew will live on the station and how they interact with their surroundings.
Things are still a little rough around the edges and there is a long way to go but it’s a lot of fun. I’ll try and be better at updating this blog with developments now that things are moving along nicely.
Yep. I’m making a game. Not only is it my first game, it’s pretty bloody ambitious. i don’t like doing anything small though so I guess we’ll see how it goes.
I still haven’t found a way to sum up this game in terms of what it is or what other games it’s like. The few people I’ve told about this project have asked me the question and I’ve always started with an insecure utterance.
Sim City in space meets Deep Space Nine I guess?
I’ve always loved the concept of people living day to day in space. I’m a huge Star Trek fan and I’ve always been one of those people who enjoyed DS9 for the political element. So when I was thinking about what kind of game I wanted to set out to create, I thought about what kind of game I would most enjoy playing.
Star Trek Online came pretty close for me to replicating the kind of experience I was looking for. In spite of how much I enjoyed walking along the promenade and seeing the usual characters hanging out in Quark’s bar, it felt more like a museum than a living environment I could take hold of and start my own story within it.
So here is Protectorate. (Or the very very early stages of it’s development any way.)
In Protectorate you are a human captain commanding the Terran Union’s outpost in deep space. Orbiting a planet of your choice, your goal is to keep your station up and running, to keep the population alive, to serve the interests of the Terran Union (or your own) and to run the best space bars this side of Wolf 359.
I’m about three months into devlopment at this stage and I plan to throw all my new updates along the long creative journey that is making a game from scratch here from now on. If anything it will be cool to look back and see how much progress has been made, which I’m sure any other game developers out will agree, you need reminding sometimes that things are moving forward.
For now, here are a few screenshots of some of the things I’ve made so far.
Version 1.0 of ‘Timekeeper’ is now available to purchase on the Unity Asset Store.
‘Timekeeper’ is a tool that can be used to simulate the passing of time within a video game. The user can display one or many text objects in a scene showing the date and time and choose the speed at which time increments in-game. The user can also select the unit of measurement for incrementing time. This means that time can progress forwards by seconds, minutes or hours.
In addition to simulating the passage of time, one of the more useful features of Timekeeper is its ability to extrapolate a future date and time and then schedule an event to occur when that time has been reached. This means that a player could write their own logic and delay it for a specified amount of in-game hours, minutes, seconds, even days months or years if needed.
Feel free to get in touch if you need to know more!
I’ve finished development on a new Unity Asset to simulate the passage of time within a video game. You will also be able to use the time in game to schedule future events.
The asset is geared towards developers making RTS and Sim games. It’s based on code I wrote for my game ‘Protectorate’ which is still in development.
Assuming it is approved *crosses fingers/ then you will be able to use this site to access supoort and updates on the asset.
I started working on a way to allow the player to select from a set of systems to install on their station. It demanded a whole host of different development phases to be pulled together.
How would I structure the systems as data?
What attributes should each system have?
Technical aspects aside, this part of the process taught me that the one thing you can predict during the game development process is change.
I started the planning phase with nothing but ‘pure’ simulation in mind. Yes we can have a bar that shows the player how much water they have left on board the station and yes they can add new systems to increase said water supply, but what if we make it so that the water supply level doesn’t even appear until they add……A WATER TANK!
Then, later on when you are drawing art for a H2O reactor that the player can install on their space station to boost water production and fill up the water tank, I was confronted with the possibility of having to depict a pipe, sending the water to the water tank the player has been required to install before they can even get to the stage where they have my questionable pixel art rendered on their machine.
But what if they didn’t install the tank?
Would I even need to go the trouble of making them….pipe the water from the reactor to the tank. If so, do I need to add in more GitHub issues to plan programming this?
As I let out a standard sigh, I realise the question I should be asking myself is how complicated I want this game to be. Or even better, how much do I need to simulate in a simulation game before everything just get’s so technical that it’s less of a game and more of a discount pixellated holodeck?
Needless to say, I ditched the tank requirement for water producing systems. Players don’t need to install a box to store the water in, just like they don’t need to build an oxygen tank or wire up artificial gravity to stop visitors to the station from floating into the nearest bulkhead.
So my advice to anyone out there is this. When things start to feel like they are getting too complicated, ditch the water tank.
Here are a few of the new systems I created art for. Not in the game yet, just on the drawing board. See you soon. 🙂