Cosmoteer 0.9.0 - Name Change, Exterior Customization, and more!

On Friday I released version 0.9.0 of StarWr--er, I mean Cosmoteer. Here's the big-ticket improvements since my last post...

New Name (version 0.9.0)

Yes, the name has changed! "StarWright" was always intended to be a temporary name. The full name is now Cosmoteer: Starship Architect & Commander. But I imagine most people will just say "Cosmoteer".

Choosing names is hard, and coming up with a name for this game was no different. (And it could still change again!) An ideal name is short, easy to remember, evocative, descriptive, and not used by another game. In my opinion, "Cosmoteer" is short, pretty easy to remember, and evocative. It's also, somewhat shockingly, not used by any existing game I could find. It's not, however, very descriptive of what you actually do in the game (build ships and fight other ships), and so that's where the Starship Architect & Commander subtitle comes in. Ideally, someone seeing the game's page or logo for the first time will read the subtitle and understand the basic premise of the game, but can still use the much shorter Cosmoteer when actually referring the game in conversation.

Performance Improvements (version 0.8.1)

I spent a good couple of weeks improving the game's overall framerate, especially when there are lots of large ships in the game at once. This involved using a performance profiler to find which functions were taking so much time and finding ways to do less CPU work in those functions. There ended up being two big areas where performance was greatly improved:

Rendering. While Cosmoteer/StarWright has never pushed the video card particularly hard, the CPU side of rendering (that is, the code that sends commands and data to the GPU) was using a considerable amount of CPU time. By finding particularly slow functions and rewriting them, I reduced the amount of time the CPU spends rendering each from from over 50% to about 20%.

Crew. Large ships can have hundreds and sometimes even more than a thousand individual crew on them. Most of these crew are constantly running around the ship carrying ammo and batteries. Each of these crew needs to decide what job to do, figure out how to get there (pathfinding), and then actually move to their destination.

The pathfinding code was already pretty well-optimized, so I didn't improve that much. But the algorithm that assigns crew to jobs was rewritten from scratch and is now both much faster and does a better job of assigning crew to all jobs on large ships.

Additionally, in previous versions of the game, every single crewperson on every ship was "updated" every single frame, moving a tiny bit towards their destination. But updating thousands of crew every frame was very expensive, and so the current version of the game only updates crew every 1/8 of a second and moves them a greater distance every update. In more practical terms, this means that, if the game is running at 60 FPS, it can update about 7-8 times as many crew as it could before! And if you're wondering why they still look silky-smooth, that's because their movement is smoothed out by the GPU.

Tutorials (version 0.8.4)

I've always known I would need some sort of in-game guide or tutorial to help players understand how to play. While I've tried to make the user interface and controls as intuitive as possible, there's frankly no way that most players will be able to figure out everything in a game this complex. I was originally planning to create the tutorials much later when the game was much closer to completion, but I got frustrated knowing that any friends of acquaintances I told to go download the game would probably not be able to figure it out without me standing over their shoulders.

So I decided to bite the bullet and create a simple tutorial system. As I was designing the system, I had a few goals in mind:

1. It needed to be clear and descriptive. Duh.
2. I didn't want to have to create any kind of special missions or in-game content for it, since that content takes a lot of work to make and would likely have to be thrown out and recreated multiple times as the game evolves. The tutorials needed to work with the existing game content.
3. I wanted players to be able to go through the tutorials at their own pace or even ignore them entirely. This means that access to game features and content can't be blocked simply because the player hasn't done a tutorial. It also means that the player should be able to be able to experiment and play with what they've just learned from a tutorial without being forced to move on to the next one before they are ready.

(Notice that I had no explicit goal to make tutorials "fun", since that would likely require special content to be made for the tutorials.)

Here's a brief description and explanation of the tutorial system I came up with that I think satisfies these three conditions:

When the player loads Cosmoteer for the first time and starts a new game, they are given the standard Model-1 starting ship and full access to the user interface. In addition to that, there's a small "How to Play" section in the upper-left corner, underneath of which there are one or more tutorial topics that the player can access.

The player can completely ignore or dismiss (by clicking the X) a tutorial if they don't want to view it. But clicking on one of the topics will expand it, showing (hopefully) clear and concise instructions with some accompanying informational graphics.

The tutorial never actually asks or requires the player to do anything. It simply trusts that the player will read the tutorial and experiment with the controls until they are comfortable and ready to move on. When they are, clicking the "Got it!" button will hide the tutorial.

As players play the game, certain actions (such as defeating an enemy or opening a particular interface panel) will cause a new topic to be offered to the player to read at their leisure.

By creating a tutorial that can be experienced at the player's pace, I hope that it will adapt to the individual preferences of many kinds of players.

New Backgrounds (version 0.8.5)

The original starry blue background (which was a a public domain image from NASA) was fine for telling you that you were in space, but because it was a single static image that never changed from game to game or as you played, it was ultimately pretty boring and repetitive.

I have replaced that original background with three different styles of dynamically-generated backgrounds: Blue, Red, and Gold. These three styles add some game-to-game variety, and even within a style the background will change game-to-game.

Additionally, these backgrounds feel more alive and dynamic thanks to a subtle twinkling of stars (yes, I know that stars only appear to twinkle because of Earth's atmosphere, but I thought it looked nice). There's also a small amount of parallax as you pan the view that makes some stars and nebula appear farther away than others, giving a nice sense of depth.

A potentially nice thing about having computer-generated backgrounds is that I now have the ability to generate as much background as I need. For example, until now I haven't wanted to ever rotate the camera because then the player would have seen the edges of the background image, but now I can rotate the camera because more background can be generated as-needed.

Purchasing Additional Ships in Standard Mode (version 0.8.7)

It's always been possible to control multiple ships in Creative Mode, and while it has also always been technically possible to own multiple ships in Standard (Bounty) Mode, doing so involved getting a piece of your ship blown off and then building onto the blown-off piece. I've always intended to let the player control multiple ships at the same time, but now you can simply buy any ship whose design you've previously saved as long as you have enough money.

DirectX 11 (version 0.8.9)

StarWright used to be written on top of Microsoft DirectX 9.0c, which is now about 12 years old and no longer has great support from graphics hardware manufacturers. Indeed, some players were getting frequent crashes that I was unable to reproduce and had no way of figuring out how to fix.

I made a decision to upgrade to DirectX 11, hopeful that doing so would solve those crashes and make the game a lot more stable. Thankfully, the two weeks I spent upgrading the code to use DirectX 11 proved worthwhile, because all of those crashes have stopped.

There are a couple other improvements as well, besides the better stability:

1. The player can now change what monitor the game runs on without restarting the application.
2. DirectX 11 is a more efficient graphics API, and I saw framerate improvements of up to 50% compared to DirectX 9.

Note that the game doesn't actually require a DirectX 11 graphics card and should still work fine on older DirectX 9.0c+ graphics cards.

Customizable Ship Exteriors (version 0.9.0)

And lastly, we have the biggest new feature in months: Ship exterior views with aesthetic customization.

I had two big goals with this update:

1. Make ships feel more tangible and real.
2. Let players customize their ship's appearance.

Make ships feel more tangible and real. Until now, ships have been these strange flying floorplans in space that shoot each other. Because of this, ships didn't really feel like physical, tangible objects flying through space:

And so I added an "exterior view" that is shown by default but can be toggled on & off by the player:

Already this helps the ship feel more present, physical, and tangible, even though its appearance is rather plain. My original prototype for exteriors didn't have any windows, which made ships feel much less alive and uninteresting, so I added windows to most parts which give you glimpses of the activity going on inside.

Let players customize their ship's appearance. Adding exteriors to ships also created a great opportunity to allow players to customize those exteriors. But the question then became, in what way can players customize their ship's appearance? I wanted to give players as much control over painting their ship as they have over building their ship, but not so much control that players would feel like they have to nitpick over every pixel or that less-artistic players would be intimidated. I also wanted to make sure that players who weren't interested in going deep into appearance customization could still make cool-looking ships with just a few clicks.

So I first added the ability to set a base paint color and "wallpaper" pattern, which already provided a good amount of aesthetic options:

Players who didn't want to go deeper into customization could just pick a color and pattern they like. But for players who wanted more fine-grained control, I added what I call "decals":

Decals are small shapes, icons, letters, numbers, and symbols that the player can stamp onto their ship. There are actually two "layers" of decals (Decals 2 is on top of Decals 1), and each layer has its own color that can also be chosen by the player (all decals in a layer have the same color).

Most decals are only the size of a single tile, and many of the decals are basic shapes that can be combined into larger designs however the player wants.

With the base paint color and two decal colors, the player can pick three colors for their ship, which allows for a good but not overwhelming amount of flexibility.

Another advantage of this system is that it's easy to save and swap "paint schemes", allowing multiple ships with the same decal layout to still look radically different:

A downside of allowing this level of appearance customization is that it's very possible to make ships that just look really ugly. But I think that this downside is a small price to pay in a game that's all about player customization.

Overall, I'm quite happy with how customizable ship exteriors turned out. As always, I welcome your feedback!