There isn’t really a lot to show unfortunately. Some streamlining of the power management screen, some new components, greater clarity in the ship management screen, not a lot of new stuff that you could see. There was however a pretty major overhaul of the skirmish scripting and mission scripting systems. The way the mission scripting worked previously is that you would define a mission, and each mission could have objectives. As you moved through the game events would be generated and passed to the mission scripting system. Each of the objectives would check the event and see if the objective was fulfilled. There were also actions you could add to the mission, these would check for the completion of objectives and do their thing when the objectives they depended on were fulfilled. So for example: The player clicks on a planet and the ship flies there, when the ship arrives at the planet a planet arrival event is sent to the scripting system. An objective watches for the planet arrival method and marks itself as completed in response. Then a cash reward object that was watching for the objective completion fires and puts some money into the player’s account. It worked pretty well for simple sorts of scenarios. But if I wanted to do anything remotely complicated, like watch for these two events in tandem, or this event or that one but not both, then I was out of luck.
But, I refactored everything using a brand new approach. Which meant I had to rip apart most of the main systems in the game. It’s nearly all back together and functioning properly, but at the moment everything’s broken and nothing works. The new approach is that you have a mission defined, and each mission has a set of triggers. A trigger has a set of conditions and a set of actions. The game sends events to the mission just like before, and the triggers each check the status of their conditions, then perform actions if all of their conditions are met. They also have a local context that allows them to read and write persistent data. This means that a trigger could look for a set of actions that can complete in any order, then fire when they are all completed, or fire only if one event has happened but not the other. It gives a lot more control than I had previously. Both the skirmishes and the missions use the same system as well, because the requirements for both systems were essentially the same. I’m hoping to have the whole thing buttoned up this week, and start playing around with the greater freedom and seeing what I can come up with.
This also marks a bit of a change in direction for the game. As originally envisioned, the game was sort of like a mashup of Steam Birds, Wing Commander Privateer, and Fire Emblem. Tactical turn based ship-to-ship combat wrapped up in an open world trading simulation with a compelling, ever changing story filled with interesting characters that interacted with each other. Quite a tall order, and early on I realized that the ever-changing story thing was a nice idea, but honestly not something I should focus on if I ever planned on releasing. Chris Crawford has been trying to make that dream a reality for the last thirty years, and still hasn’t found success. Perhaps there are approaches that could yield results, but at the moment my focus is getting something done rather than doing research. So, I realized that an ever changing story with characters that interacted with each other programmatically was right out. So I shifted my focus more into the open world space trading side of things.
Then came an explosion of space trading simulations. I don’t know what’s up, but everyone and their dog has decided that now is the time for making open world space trading games. Kind of funny because I’ve been sitting on this idea for around five or six years now, if I had made it four or five years ago it would have been wholly original. Fortunately none of the other games I’ve seen have taken my approach to combat, so I still have that. But I worry that by trying to make it a space trading game I’m going to be lumped in with all of the other games and get passed over. So I’m pushing it back towards the Fire Emblem side of things.
Fire Emblem, if you’re unfamiliar, is a turn based tactical fantasy strategy roleplaying game, where each of the units is a character with their own personality, back story, and unique interactions with the rest of the cast of characters. You move through the game fighting typical fantasy evil things, and as you do your characters become stronger, and develop relationships with the characters that they are most often positioned next to. It’s a pretty neat series of games and you would be well advised to check it out. That’s what I’m going to be pushing my game towards. I’m not sure about the characters improving their statistics, but I’m going to make it a more story driven and scripted game. Fortunately, this won’t mean a lot of extra development, nor will it mean throwing away big chunks of code.
I’m going to keep the open world map I currently have, the player will move around on it to get to the next story missions, they will also have the option of taking on side missions. These will probably also be heavily scripted and story based, but they will provide an opportunity for the player to earn more money and improve their forces if they feel they need an extra edge. The eventual hope is that I could put together a reasonably good story that would take around four hours to play through without too much trouble. Then I could release another story or two or three. They would use the same engine, same assets, etc. But they would add a lot of value to the game. My thought would be that people who buy the game early on would get the additional stories free, while each release would push the price of the game up for newcomers.
So that’s where it’s at, and I think that I’ve spent more than enough words going on about it. So I’ll end right there. And I really need to find some uniform and clever way of ending these things.