So here’s what we’ve been up to in January and February…
Much time was invested in continuing to refine ship movement. Heru smoothed out the rotation and braking cycles nicely. Heru also fixed a few bugs and covered edge cases with formations and multiple ship intercepts. We still need to get ships and groups of ships to match orbital velocity within hailing distance, but we’ll get there.
Heru put a lot of time into getting all of our UI windows to sort properly so the window you want is always on top. Dialog boxes also now adjust size to accommodate additional text.
We expanded success and fail conditions in events to include groups (e.g. defeat all the ships to succeed) or one of several conditions (e.g. the event fails if a certain ship is disabled, or you jump away).
We added another major feature related to events, what we are calling speech dialogs. Previously, we only had a single big dialog where I would write blocks of text. After creating a few events, I felt that the text was just too dense and lacked a lot of opportunities for tension, drama and humor.
So we added a speech dialog. You and your crew are always represented on the left, and other people you encounter are always on the right. Text prints out at speaking speed, and I can also add pauses in the text for emphasis. Of course, you can hit the spacebar to skip ahead.
The effect is just what I’d hoped for, and I put a good amount of time into enhancing the 40 events we currently have to be more fun and engaging. The stories now have more drama, humor and flow. And then I continued creating more events. Writing these events continues to be one of the most rewarding aspects of the entire process for me.
As you can see above, at long last character heads are mostly implemented in the speech windows. We aren’t completely done with characters; I’ve begun to optimize the 3d models and add faction-specific accessories. I have a lot of modeling to do there, and Heru has some programming as well.
We also took the time to implement persistence across a game session for the characters you interact with, so their names, titles, faces and clothing accessories stay the same. And I can reference this info easily using tags.
You’ve probably already seen the multiple choice dialog boxes in our events. Now we can layer these choice groups so you can drop down into another level of choices and return back to the previous level. Narratively it gives you a chance to ask questions or pursue other courses of action, and it has added a lot to the feeling of the events.
We can now add a specific hero shot of a ship in an event dialog that we call a story. This gives us a place to put non-dialog narrative that doesn’t involve a player choice. These story windows help establish tone and let the player know where actions are taking place.
As I continued to build events for the game, a happy side effect of this was a lot of testing on the event system. Heru fixed a few issues, and made numerous adjustments and visual improvements to the event system.
Which comes to the biggest gain we’ve made with events so far. You may recall that when we implemented our events we used JSON for the format. Unfortunately I found JSON’s heavy syntax difficult to read and harder to debug. I felt like I was spending too much time editing and debugging syntax instead of writing events.
I began thinking a lot about how we could speed up the process. I’d used YAML (a subset of JSON) in the past, so we converted events to that format. It turned out to be quite fast to convert JSON to YAML. The results have been extremely positive. To give you an idea of how much easier the format is to read, here’s the before and after for creating a ship:
old JSON format for creating a ship:
“initializations” :
[
{
“type” : “spawnShip”,
“shipId” : “victim”,
“role” : “initiator”,
“shipTypes” : “refugee”,
“factions” : “Irenic”
}
],
and here’s the structure for the same thing in YAML format:
init:
– spawnShip:
id: victim
types: refugee
factions: irenic
You can see how much more compact YAML is – it takes half the space! Also note the lack of brackets, curly braces or commas. This makes it so much easier to read, edit and debug. So a major win there.
After Heru made the change to YAML I kept thinking about how to make the process even faster. The first part of creating an event involves me writing story and dialog and adding a tag for each bit of speech or story in the event to the dictionary file. Then I would create the proper YAML for each aspect of the event and add the tags to the YAML. Since all the text in the game is already stored in a single file and conveniently tagged, I started wondering “can I automate the process of building an event?”
And this is where a well designed naming convention can be used for big gains. Since I was already using logically-named tags in the dictionary file, all it took was adding some codes to those tags and writing a simple programming script.
Within an hour I had a working script to automatically parse dialog and multiple choice tags into YAML. It worked so well I expanded it, and kept expanding it. Now I use coded tags to specify actions and structure right in the dictionary file, so I have almost no hand-editing of the YAML to do.
With all this in place I went from needing up to four hours per event to create JSON structure and debug the JSON to less than two minutes to create the YAML structure, with no debugging needed. It’s hard to understate those gains.
Of course, I still have to write the events and test them, and creating content is time consuming. But now I can focus purely on the content and not worry about the format.
Lastly with events, we’ve designed them so that they can be influenced by many factors. We have the first layer of our occurrence condition system for creating events that start, for example, in the first ten days and only if the player doesn’t have a repair ship.
Another major accomplishment in our development is the addition of weapon parameters and the weapon progression system. Up to now, weapons have been static. Weapons are now procedurally generated with unique but balanced rates of fire, ranges, damage and resource usage. The power level of the weapons available now increase over time. You can receive a proceduralized weapon in an event and add it to your ship immediately. In events you can also receive a plan for a weapon, which allows you to use resources to make copies of a weapon. If you don’t have room, you can melt down a weapon for resources to make room or delete a plan.
On the combat side of the game, Heru added targeting priority to all warships. Now ships fire on the closest target, depending on their ROE.
I worked on combat logic for minelayers, and differentiated the weapon levels for each faction.
Heru added explosions and began to add visual ship damage. EXPLOSIONS! I’m very happy with the explosion effect. We need to make some adjustments to another aspect of the explosion but will circle back to that later.
We re-implemented visual ship damage. As warships take damage, pieces of the ship literally fly off. I really like the effect. I spent a lot of time going through all of the warship models and making them destructible. This was a big effort and the heavy lifting is done. We need to polish a few bits and we’ll be done.
Since I was working on so many ship models, I also added new ships to the game that I’d been planning for some time. The Empire now finally has frigates and destroyers! I also made visual adjustments to several models. The minelayer and gunboat were redesigned to make them more in line with the design styles of the other Empire warships. Similarly, the Corp sandship and sandwyrm are now visually similar and more easily identified as Corp. The end result makes it easier to spot warships and which factions they are from.
Alexander took a break from Unity tutorials and built out several of the new ship icons, which look terrific.
I worked on an improved visual effect to indicate when you are plotting a course to a ship.
I also adjusted collision boxes on all the normal ship models to be more consistent and easy to select. Adjusting collision boxes for damaged ship models is next.
And lastly we now use an algorithm to determine the cost of each weapon based on its stats. That’s allowed us to begin working on the final fleet information display (which holds a lot of functionality), and then we will be set up nicely for developing the trading system. More on that in the next updates.
Well, I think I covered everything. It’s great to see the list of things to do getting smaller every day, but we have a lot more work ahead. The game continues to improve. I am having a lot of fun and filled with energy. Thank you backers SO MUCH for the kind words and patience you have shown.