It's not what you know, it's who... a space game that's all about people and relationships. Successfully funded, but you can still back the game to get beta access.
The Kickstarter campaign may be over, but you can still back the game! Purchase INSIDER access now for full access to the beta. Add-ons will become available nearer to game launch.
I’m very excited about the new feature I’ve just added to Sol Trader - when you visit a location you can now listen in to all the conversations that are going on whilst you’re there.
This is how it works: characters will chat away about their lives and their friends to anyone in the room. The chance of chatting varies depending on what they’re doing, and if they have low wisdom they’ll chat more. They’ll stick to existing conversation subjects if they can, and the things they bring up are entirely random. This means that big revelations are definitely possible. It’s possible for lots of info to come out by accident, including work incompetence, embarrassing friends, and office romances.
The best thing is that these conversations are sharing real information that is recorded as you go along. You never know when an indiscretion will come in handy later for an information gathering mission.
It’s now great fun to simply sit in a bar and listen to the characters chat away to each other. You pick up a lot of useful information about what characters have been up to and where others might be found. It’s also rather scary handing over sensitive information to another character now, especially a reckless one: you never know where it’ll end up.
Up to this point, communication in Sol Trader was almost entirely reactive. It was impossible to find anything out without going and asking someone. This meant that characters used to feel more like mindless vendors of information than like living and breathing individuals.
Now they actually talk to each other, characters feel very much more alive. Additionally, because characters remember the information that’s talked about, they can form new opinions of other characters, and change their behaviour accordingly.
This new build with gossip in will be out to Insider backers in the next few days. This brings to an end the cycle of work on the interactive world and gameplay progression through organisations and missions. Next, I’m moving back out into space with work on asteroids, ship customisation and advancement, and polishing off combat.
Game design can be such an enigma. Some features that you work away on for ages never seem to be that fun, whereas a small thing that only took a few hours, and that I debated including at all, has proven to add a huge amount to the feel of the game.
I posted this a while back:
After quite a lot of soul searching, this is still true. I now know that I don’t know how to make a great game, but I do know how to go about being lucky enough to discover one.
Sol Trader’s release date is set for late April 2016 so we’re gearing up for two big shows this year to put the game in the hands of gamers.
We had a great time at EGX in September last year, and are looking forward to returning to EGX Rezzed on 7-9 April.
We have a big double stand and there will be lots of opportunity to get your hands dirty with a preview build of the final game. You’ll be able to create whole new procedural societies to interact with, flying missions, trade goods, shoot down pirates and avoid the wrath of their family members…
If you’ve got your tickets, we’ll see you there. If you haven’t there are still some available.
I’ve just finished reworking the old state-machine based AI system that I threw in to the game last year just to get something working. Sol Trader now boasts a full STRIPS-based planning AI. This works by starting a character off with some basic needs to fulfil: the need to socialise, rest, work, self-improve, etc. It then uses pathfinding techniques to work out a series of steps to get those needs fulfilled, such as buying a cheap good and selling it for more somewhere else, hitting the bar after work, or hanging around a jumpgate looking for easy prey. Here’s how it works.
Let’s say Anthony, an AI character, is tired and has a strong need to rest. To fulfil that need, the game allows the character to rest at home, but also to stay a night at a friend’s house. Here are some rules from the actual planner in the game written in a semi-formalised manner:
RELAX_AT_HOMEif we are
IN_LOCATION(MY_HOME)at cost of 0
STAY_A_NIGHTif we are
AT_HOME_OF(CLOSE FRIEND)at cost of 50
To stay the night at a friend’s house, Anthony would need to move to their house, so we need some more rules to cover this:
AT_HOME_OF(PERSON)if we are
MOVE_TO(LOCATION)if we are
IN_CITY(CONTAINING LOCATION)at cost of 10
Let’s assume that we are already in the city in question. The planner starts off at the need (
REST) and works backwards until it find this
IN_CITY state. It then forms a chain of actions to complete to get the need fulfilled:
ANTHONY'S PLAN: MOVE_TO(HOME) -> RELAX_AT_HOME -> FULFIL_NEED(REST)
The game will always chose the lowest cost option. If Anthony is in his home already, or in the same city, then he would just go home to rest, rather than to a friend’s house. However, let’s assume he is in a different city. It’s too far for Anthony to head home to his house, so the lowest cost option would then be to trespass on the hospitality of a friend who lives in that city.
There’s no one-size-fits-all when it comes to good game AI. The effectiveness of AI techniques varies dramatically depending on the type of game being designed. However, planning is a great fit for Sol Trader: it’s had a dramatic effect of the feel of the game.
Now the AI is now intelligently making decision based on relative needs, the game has the following new features, all of which were easily added:
It was also very easy to put in a conversation option which asks what a character is thinking about. This returns some text detailing the character’s top need, which shows what they’re most likely to do next:
I’ve posted the start of a reference guide to the forums for modders.
This new build is now available from the forum if you have purchased insider access (if you haven’t there’s still time!) If you are already a Kickstarter backer and you haven’t received your copy, or you’re a member of the press, do get in touch.
Since getting the new mission code into Sol Trader before Christmas, I’ve been working on upgrading the conversation mode. Now it’s possible to have much more detailed conversations with players about your events and theirs:
Conversations get ‘deeper’ the more you share, so you can feed a character lots of interesting (and potentially damaging) information about your life, and in return you’ll get equally sensitive information back about the character you’re talking to.
If you’re talking about a different character, then you can share what you know about them and get information back in return. This way you can build up pictures of characters you know about by gradually discovering information about their past.
The flipside is that you’re sharing sensitive information about yourself, which could potentially be used against you by other characters in the future. It’ll soon be possible for characters to blackmail you by forcing you to undertake a mission by a certain time, or they’ll release damaging information about you. Be careful who you give your sensitive information to!
The relative radio silence from Sol Trader Towers is for a reason: I’ve been working hard on a flexible and moddable mission structure, that allows players to take a variety of interesting quests in-game.
I’ve built a few missions to start with, including delivering parcels for business or personal reasons, taking characters on business trips and making other characters disappear. It’s great fun to have a variety of things to do for characters now and adds yet more colour to the game. Because it’s completely moddable, I’m also excited to see what storylines other people come up with!
The full details of how to create your own missions are available as a lengthy forum post, which will be kept up to date with changes and clarifications. Here’s an overview:
The missions are organised into packs, which exists under the
data/missions subfolder. If you have access to the beta builds, you’ll see there’s one pack there already: these are the missions that are built in to the game.
There are several csv files in each mission folder:
requirements.csv: This file details the cases in which this mission might be triggered. Each character in the game has a chance of picking this mission (and becoming the ‘giver’ of the mission), based on the conditions imposed by this file.
conversation_player.csv: The extra conversation options available to the player because of this mission.
conversation_ai_response.csv: The extra options the AI can choose from as conversation responses.
opinions.csv: The extra opinion triggers, used for reactions to the generation and completion of these missions.
strings.csv: The new strings needed for the previous CSV files.
The possibilities for you to build your own missions are expanding all the time, as I add new missions triggers and possible goals for the AI.
At the moment it’s possible to take on any mission from any person, which isn’t very realistic. I need to allow players to gain other character’s trust, so that they will only give you sensitive missions in certain cases. Additionally it will soon be possible to start a career with an organisation, which will give you a rank, a certain amount of built in trust, and access to more senior characters.
I’m also going to be working on the in-space AI very soon. At the moment only freelance traders fly around between planets: it’s time we had passenger ships, military guards and pirates thrown into the mix.
Have a fantastic Christmas and I’ll see you all in the new year with some more updates.
The opinions a character has of other people, based on the partial events that they know about them, will now directly affect the things that happen in the history generation. This creates new events, which will in turn feed more character opinions.
There’s a new beta available on the forums if you have insider access.
In the example on the left, we can see that an acrimonious divorce of Meredith’s parents has left an indelible mark on her childhood. She now has a very low opinion of her father, Dudley.
When characters are adults, they can then generate a series of ‘favours’ (or ‘missions’) that they want completed. This is a source of work for the players, although completing certain missions does have real consequences on your relationships with the target of the mission. If they find out you’ve taken a mission against them, then they won’t be happy with you.
To continue our example, Meredith, whom we are now married to, wants us to find out some potentially incriminating information about our own father-in-law, Dudley. It’s up to us whether we take it or not. If he finds out, we’ll make an enemy of him.
As the game goes on, the player will get embroiled in these relationships between the various characters and be able to directly affect their stories. Choosing what to take on and who to ally yourself with forms a major part of Sol Trader’s gameplay.
Another example: the sad tale of Sarina, our older half sister. I picked Dagny and Warren in history generation to be my character’s parents, knowing that Dagny was cheating on her husband Hayden, mostly to see what happened. Little did I know how much it would affect Sarina, Dagny and Hayden’s eight year old daughter. When she found out about my birth, she got very upset.
She didn’t blame me, thankfully, although she never thought much of me. However, she never really spoke to our mother again, especially since her beloved father Hayden died soon after we were born.
She left home at a young age, and became a political assistant, but she didn’t make too many friends. She was doing ok for a time, only to find out that the love of her life, Richard Ruhr, had been having an affair behind her back all along.
She divorced him, got depressed, quit her job and by the time I grew to adulthood at the start of the game, she was living in a hippie commune somewhere on Mercury, trying desperately to get some gossip on her ex-husband.
This new beta is now available from the forum if you have purchased insider access (if you haven’t there’s still time.) Let me know if you find any other interesting stories such as these!
I’ve been working hard on the Sol Trader core gameplay mechanics in the last two weeks. High up on my list was a way of generating more interesting missions for the characters to complete.
In order to have a reason to gather dirt, find locations or desire an early end for an enemy, our characters need to feel strongly about other people they know. This is where their opinions and prejudices come in.
Characters already keep track of the events they know about for each other character in the game. Now they can form an opinion of a character based on the partial set of info they know about someone else’s past.
The plan is to use these thoughts about each other to make decisions about who they’re friends with, deal with relationship breakdown, blame and prejudice.
Here’s an example of how we configure this under the hood for an occasion where a character is caught and reported for taking bribes:
Anyone knowing about this event will think the character is less deserving of sympathy and assume the character is less moral. If we’re the one catching them take the bribes, then the briber becomes much less influential over us. If we’re the one being caught, then the one catching us is definitely no longer our friend. Depending on our profession, we will brief against them or possibly try to take them out.
Now characters have opinions about others, we can use these to guide their conversation choices, who they’re likely to target, give us gossip on, etc. It’s all game design fuel for other behaviours in the game, and will combine to form interesting unexpected effects and tell original stories each time.
Next time I’ll discuss about the new events that get created in the history generation because of these new opinions. Our stylised formulaic view of history is about to become, well, a lot more messed up. Rather like real history…
Since the Kickstarter was successfully funded last month, I’ve been working hard the next major feature: combat!
Here’s a short video showing progress so far. If you’re on the beta of the game, head over to the forums - you can grab a new copy of the game today and start shooting things for yourself! (There’s still time to jump on the beta if you aren’t already…)
Since the Kickstarter finished, I’ve added sound effects and explosions, and I’ve done a lot of work under the hood on the entity component system to allow the to removal of components from entities.
This was fiddly as I had to change the implementation of some of my fundamental low level data structures in order to support fast removal. It’s worth it, though. Now when a ship blows up, I simply remove the components that made it a physical thing (Spatial, PhysicalObject, Renderable, Enterable, etc) and leave the components for its logical existence (Ownable, Nameable, etc) so that characters don’t forget about it.
I’ve also added the basics of ‘bad’ events when combat takes place. When a ship is destroyed, the game kills everyone who happened to be on the ship, and adds ‘killed’ events for them, blaming the pilot of the attacking ship. These events will come back to haunt the attackers in future, as word gets around about who is responsible…
Lastly, I’ve added the first draft of the inevitable “game over” screen, with a Rogue-like throwback style :) This one is a work in progress and will get more interesting later on:
If you’re the kind of person who likes to get the up-to-the-minute news on development, and doesn’t mind lots of detail, you can see the latest development notes on our Trello board. You can even comment and vote on cards - I welcome any feedback!
Plenty of people have been writing about the ‘Indiepocalypse’ - the alleged death of the indie game development market and the destruction of indie studios everwhere. Some are wringing their hands and foretelling utter doom, whilst others are wondering what all the fuss is about.
Here follows my take, as I embark on the final phase of the perilous four year journey of finishing my first indie game, with plenty of people on the internet telling me that I’ve wasted my time.
I think we’re witnessing a market correction, brought about by an oversupply to the market of good games.
I believe that we do have to be lucky to succeed, but that we can make our own luck. After reading a lot and studying the market, I have come to believe that the main thing that separates successful indie devs from failed ones is sheer determination, stubbornness and persistence. We have to be in this for the long haul, and we have to enjoy the process.
I don’t think indie games are doomed, but some indie developers will have to quit the business. I’m also determined to do all I can not to be one of them. Here’s my approach.
Firstly, I have an alternative career. I train and coach teams of developers, and work part time locally, which allows me time in the day to work on Sol Trader without worrying (too much) about whether my family will eat next month.
Sol Trader has been four years in development, but I’ve only worked on it significantly during the day in the last year. I’ve used savings from consultancy work to get me this far. This means development is sustainable and I can avoid crashing out financially.
I’ve been building the Sol Trader community from day one, as everyone is advised to do. However, I’ve come to believe that the important thing is to have something for people to do in response when we communicate with them. We need a great call to action.
For example, Sol Trader has been available purchase on Alpha Access since May 2012, and on Kickstarter for Alpha or Beta access since the beginning of the year. Even when we paused sales on the game this year, people could still sign up to our mailing list for news, updates and articles.
I’ve found that it’s very hard to get anyone excited about anything without something people can do or buy. Otherwise people get bored of constant tiny updates about progress and they lose interest.
This is why I think great content marketing is so important. I’ve learnt that game updates are best when the audience can learn something from what I’m saying (like how to add bloom to an engine, or how to implement an entity-component system). They stimulate great discussion, they give my audience value, and they slowly grow the community around the game.
Sol Trader was a good game a year ago. It wasn’t enough. After feedback from the failed Kickstarter campaign at the beginning of the year, I’ve reworked the gameplay fundamentally from the ground up. I’ve focused the design on people and relationships, and it’s turning into something unique, original and truly interesting. I’m hoping that this means I’ll gather more press attention than I otherwise would.
Making a simply “good” game isn’t going to cut it. There’s so much about games at the moment that is derivative, and the product lifecycle of existing popular indie games is increasing with slower moving minimum specs and DLC to keep existing audiences entertained. I plan to do all I can not to settle for “good”. I’ll delay the game’s release if it means turning it from a good game into a great game.
This all might not be enough. Perhaps no one wants to buy this game and that would be sad: although comments like this one from YouTube fill me with encouragment! Part of the reason to do two Kickstarters was validation of the core concept to ensure there’s enough of a market. I believe I’ve had enough validation of the idea to continue pushing at it!
Perhaps it’s just brazen stubborness, but I just know that I’m not going to quit and I’m going to release Sol Trader no matter what. I am running this as a business, but it’s more than a business to me: I’d release it even if I knew now it was going to make no money. I’m sure that people will enjoy it (they are already) and I believe in the design: this game just needs to be made.
Am I wrong, or crazy stubborn, or both?
Six months ago, Sol Trader was in a very different place. The previous campaign hadn’t quite made it, yet we’d been greenlit in the same week. I’d had a ton of feedback about the game. The main thing that was clear was that it was difficult to understand the core gameplay, and that the lack of a demo was making that worse.
I therefore decided to completely revamp Sol Trader’s code and gameplay, and spent several months completely overhauling the game. As I said last week, every line of code in the current build of the game is less than six months old. I’ve focused on the fundamentals of the gameplay - the interactions between you and your family and friends - and dramatically improved the code architecture and visual of the game.
The result is a playable demo (download it now from the website) which shows off the vision for the game for the first time. Every interaction - buying and selling goods, accepting missions, gathering information, hiring ships - is done through people who can potentially become your friends, allies or enemies. Every decision you make and action you take will have an ripple effect on the people you interact with, causing consequences that you must live with long term.
At times working on this game has felt completely overwhelming, especially as a solo indie. Thankfully I’ve been cheered on by some amazing people: Richard Patching and my brother Steve Parsons being at the forefront. I’ve been ably supported by a great team: Aamar Rana has provided some fantastic artwork and Andy Dollerson is responsible for the wonderfully moody soundtrack. Furthermore I’m grateful to everyone who has ever encouraged me on social media, retweeted a tweet, or liked a post on Facebook: you all are collectively responsible for keeping me going!
This is a crunch point. The game is mostly written and we’re heading into general beta next month. There are still some big features to add, such as weapon systems and more varied missions, but hopefully enough of you like what you see so far to want to join me in the beta and help me finish this thing off.
Sol Trader has all the potential to become a classic genre-defining game. I’d love you to help me make it one.
The beta test is finished. The demo is ready. The campaign is prepared. The video is uploaded. The press releases are written and sent.
It’s now only three days to go until the new Kickstarter campaign for Sol Trader!
The campaign will be available at this link when it goes live on the 21st.
Creating this game is definitely the hardest thing I’ve ever done, but I’m very pleased with the result so far. Last time I learnt an enormous amount about what the game should and could be. Since Sol Trader was greenlit, I buckled down and started to rewrite the core internals of the game. I’ve now reached a point where every line of code in the current build is new. It’s quite literally a different game to last time, and also looks and sounds about five times as good, thanks to great art and music from Aamar and Andy.
It still feels scary to share my game with the world, but I’m so grateful for all the encouragement and feedback from early backers and beta testers. Thanks everyone!
Here are some of the latest screenshots from the new build. Enjoy!
I’m now in the final stages of getting a playable demo out to beta testers (if you’d like to join the waiting list, you can sign up on the forums). I’m busy cramming in the final few things to make the demo as complete and as fun as possible.
I’ve done all my development on OSX for the last few months, so last week I put together a Windows version: thankfully it only took about four hours, due to both using SDL2 and to splitting the game code from the platform layer. I’ve also just implemented the code that allows players to talk about another person in the game, and I want to briefly discuss how it works.
I wrote in June about how Sol Trader uses information as a form of currency in order to help the player advance. The power of gossip to spread rumour and information is known to us all, and it seemed to me the best way to allow players to gain information about others.
When chatting to Amos, he started talking about Orville Averill. We can now press for more information, or try and find out where he is.
As players chat to various characters, other people will come up in conversation. We can either choose to change the subject, or press them for information about that person. The AI tracks when each character was last seen by that person as well, so asking the right questions can help players track down difficult to find characters to complete certain missions.
Each conversation has a certain amount of patience attached to it - that’s what the little blue circles are in the screenshot. Asking questions ‘spends’ patience, which means that after a while we won’t get anything else out of a character and will need to come back later. The better we know someone, the more questions we can ask, and the better information we’ll get.
In playtesting this has thrown up some suprising effects. For example, often the best people to get information from are those in prison: they have plenty of time on their hands and often know a lot of different types of characters:
Prisoners are often the best source of information about people, and they have plenty of time on their hands to chat.
People in prison usually don’t know where characters are though. For that we’re best off talking to bar staff, as they might have seen characters come in to socialise. Making friends with hotel receptionists will give us good information about people who travel a lot, and spaceport staff will often have seen characters passing through.
Barring any last minute issues, the demo should be out on the 22nd on the same day as the new Kickstarter launches, so you will soon be able to try it for yourself!
Adding live code reloading is one of the best things I did when working on my current game, Sol Trader.
Live code reload reduces our debug loop down to milliseconds. Now when I recompile the game, it notices I’ve done so and loads new code whilst the game is still running. Here’s a demo:
Thanks to Casey Muratori (again) and his excellent Handmade Hero series for teaching me the basics, and to this github project for demonstrating how to do it in OSX, my development platform of choice.
There are a few architecture changes that we’ll need in order to put this feature in our code. Here’s how I did it.
Sol Trader now has a clearly defined platform layer, separate from the game. The game code itself knows nothing about the platform at all and it passed in everything it needs in order to calculate what’s next. Here’s the method that we call to run a game loop:
The update and render call takes some
Memory, the screen dimensions and the input that we received this frame from the player. It is the job of this method to render the next frame to the screen, in under 16ms.
Memory is just a big chunk of raw memory allocated by the platform layer at the start of the game. The
gameUpdateAndRender function is free to do what it likes with this space. It’s important to note that it’s persistent across live reloads which means that all state should be saved here. The game is not allowed to allocate any memory itself, it has to use the memory given to it.
gameUpdateAndRender actually is implemented as a call into a shared library (a DLL on windows, or a dylib on Linux/OSX) using a #define trick I learnt from Handmade Hero:
(We need the
extern "C" here to stop the compiler from mangling the name, so we can find it in the shared library.)
This is a cut down OSX version of the platform layer I’m using. Similar code exists for other platforms:
At the heart of it, it’s a standard game loop. We first allocate enough memory using one big
alloc call at the beginning. This is all platform specific code, so it’s ok to use OSX, Linux or Windows specific calls here. We figure out our screen dimensions from the platform, create a window, and initialise OpenGL or whatever graphics library we’re using.
Then we load the code using
dlopen and if that succeeds, we find the
gameUpdateAndRender function and save the location. In the main loop, assuming that all worked, we call the saved function with the info it needs to render the frame.
Here’s how the
build.sh script looks:
We build the shared library containing only the game code, not the platform code. We then use the platform code to load and run the shared game library.
This is an amazing way to develop games. For too long in the past I have sat watching a long compile, then ploughed through the game from the main menu, to find the bug I’m trying to fix, only to find that I’ve made a stupid error and have to start again. We need to find fun as fast as possible - anything we can do to reduce the debug loop is a good thing.
Live code reload also does away with much of the need to use a scripting language (fast feedback). I don’t have any designers who don’t write C (it’s just me!) so I haven’t implemented one for this game. I also don’t need any GUI configuration files for layout, it’s all just implemented in C with live code reload for positioning tweaks.
Trust me: once you’ve tried it, you’ll never go back.
A decision to rework a major piece of infrastructure late on in a game’s development is pretty significant. It’s especially so if we’re replacing it with our own code written from scratch.
Yet about a month back, after plenty of profiling, I took the decision to remove the GUI library I was using from Sol Trader’s codebase and replaced it with my own.
The library I was using, libRocket, has many useful features and it got me a long way during the game’s prototyping stage. It is however written in C++ and extensively uses a large class inheritance tree with lots of virtual methods. I’ve written before about how this can potentially be a speed problem, and it turns out through profiling that this was indeed the case for my game. Because parts of the game are very GUI heavy, these performance problems surfaced quite quickly after building the final interface structure for city mode.
So, on 1st July, I set out to write a minimal GUI as quickly as possible, whilst at the same time reskinning the prototype GUI I had with the new look and feel. It took about 60 hours to both write the GUI infrastructure and reskin the interface. In that time I also implemented live code editing, revamped the asset system and vastly improved the efficiency of the renderer.
Here are a few reasons I went with the “from scratch” route rather than using different library:
I’ve been heavily influenced by Casey Muratori’s no-libraries approach to writing video games. Avoiding libraries really does shorten the debug loop. By pulling out the last major library and its dependencies, I doubled the build speed of the game.
The new Sol Trader coder is leaner and meaner that it has ever been: all 12,000 lines of code now compiles in under a second and updates the running game live.
The current GUI that my game needs is around 1,000 lines of C code. I don’t need anything fancy and it doesn’t need to be made general purpose: it only has to work for what I need. By cutting out extraneous code I can keep complexity and code size right down to the minimum.
This is a fancy way of saying “the game code fits together well.” Now I’m writing my own GUI code I can create exactly the interfaces that the rest of the game wants to use. I can also build it with my own game’s constraints in mind: because of the way space travel looks on screen, a good frame rate is essential.
In hindsight, I definitely made the right decision. Build speed is so important because the shorter our debug loop the faster we can iterate towards fun. Writing my own tiny GUI library within my game has meant that now there are no external barriers to a smooth frame rate.
I can now understand why there aren’t that many well established game GUI libraries out there. It’s relatively easy to write just enough GUI for what we need, and relatively difficult to write enough GUI so that everyone can use it.
I think “Not Invented Here” is overrated. As developers we’re often tempted to reinvent the wheel, and often that’s unnecessary. However, as long as we understand the concepts, sometimes it’s ok to rewrite the code without resolving the problem. Perhaps we need to focus more on not reinventing concepts and less on not rewriting code.
Now that it’s almost reached the playable demo stage, I’ve been wanting an opportunity to show Sol Trader off in person. So we will be taking the game to EGX 2015 with our own booth!
My friend Richard Patching and I will be in the Rezzed area of the show - there will be plenty of opportunity to ask us questions and see the game in action. We’re also hoping that the man responsible for the amazing artwork, Aamar Rana, will also be there for a day.
If you’re from the press or a publisher and want to make an appointment for a demo or interview at the show, I’ll be available Thursday to Saturday morning. Send me an email to book a time.
After finishing the new GUI and the city mode interface last week, the next major thing to do is to revamp the space mode again. We now have a continuous space model: it’s now possible to fly from one end of the Solar System to another, but it’ll just take a (very) long time…
This week, I’ve been adding jump gates back in to allow faster travel to and landing on the different planets, and I’m in the middle of adding particles back in. After that we’ll put back the AI ships, weapons and trading systems. Finally I’ll be balancing the interaction between characters, and adding simple missions.
By the time EGX comes around, we should have a playable demo and a new Kickstarter campaign running to to raise funds for a marketing push. Spending correctly on marketing is essential for any indie game, especially if not from an already known publisher. I’d like to raise enough money to budget for that, and to give everyone an opportunity to buy the game at an early bird price.
The final release will be early next year, once I’ve added the final features. It’s all coming together and it’s very exciting! Follow us on social media or join our mailing list on the website to keep up to date.