next »

[Equalizer]

I've noticed that when there are many large ships in Bounty mode the game start to run slowly. (Note: I do have an old computer so this probably is less of an issue for other people.)

I assume this is because of the number of crew that path finding needs to be run for. I was wondering how many ships and how large ships you are trying to support in the future because it seems that there could be a scaling issue.

[Walt Destler]

I've noticed that when there are many large ships in Bounty mode the game start to run slowly. (Note: I do have an old computer so this probably is less of an issue for other people.)

I assume this is because of the number of crew that path finding needs to be run for. I was wondering how many ships and how large ships you are trying to support in the future because it seems that there could be a scaling issue.

Number of crew running around (and pathing) is probably the biggest performance issue right now. The other two big issues are physics (ships are composed of many individual colliders within the physics engine all moving around at once) and weapons searching for targets to shoot. I think I can greatly improve performance in all three of these areas, but it hasn't been a super high priority for me, and probably won't be for a while longer.

If you don't mind sharing, I'm curious what your computer's specs are.

[Equalizer]

I was running this on a laptop that has an Intel Core 2 Duo CPU T9300. It is spec'ed to run at 2.5GHz but it probably only maintains around 1.6GHz due to heat throttling. It also has an old graphs card but it doesn't register significant load so I doubt that has any impact.

The computer's capabilities are maybe comparable to that of a modern ultra-light laptop.

[Walt Destler]

I was running this on a laptop that has an Intel Core 2 Duo CPU T9300. It is spec'ed to run at 2.5GHz but it probably only maintains around 1.6GHz due to heat throttling. It also has an old graphs card but it doesn't register significant load so I doubt that has any impact.

The computer's capabilities are maybe comparable to that of a modern ultra-light laptop.

Thanks for the info! Yeah, the game is much more CPU-dependent than GPU dependent, so your results don't surprise me.

[Walt Destler]

Today I released StarWright 0.6.0, which (in addition to a handful of other improvements) features the game's first active defensive system: the Shield Generator!



Until today, the only defensive additions you could make to your ship were the lowly armor tiles. Armor tiles are useful for protecting the innards of your ship from enemy fire (and especially from penetrating cannon rounds), but, since weapons and thrusters have to be placed on the exterior of your ship, armor was a limited use in protecting those kinds of systems.

The Shield Generator changes that, providing protection for your ship's exterior, but at a hefty cost in credits and power. As you can see in the above screenshot, the shield generator (the purple room next to the big cannon) projects a curved force field in a 90-degree arc in front of your ship. This force field blocks all incoming enemy fire attempting to pass through the arc, while allowing your own shots to pass through unimpeded.

Of course, as powerful as the shield generator is, it's not without some serious drawbacks to prevent it from being imbalanced:

• The shield only protects against shots passing through its limited 90-degree arc, meaning that, without extra shield generators, you could be flanked from the side where the shield won't protect you.

• While the shield blocks incoming weapons fire, it does not actually prevent enemy ships themselves from passing through. So if an enemy ship gets close enough that its weapons fire from within the shield's arc, then the shield will do nothing to protect you.

• Shields use a lot of power while operating. Not only is there a substantial per-second power drain just to keep the shield operating, the shield also loses power quickly as it absorbs enemy fire. And once a shield generator runs out of power, its protective force field will shutdown until the generator can be fully re-powered, leaving a sizable window of opportunity for the enemy to destroy the shield generator or the other systems it was protecting. Keeping a single shield generator powered during an an enemy attack can require many crew working hard to carry power from a nearby reactor or power storage.

• The shield generator itself is very weak and is easily destroyed once its force field shuts down. This leaves a potential weak point in the perimeter of your ship through which enemy rounds can penetrate and damage your internal systems.

One mechanic not yet implemented that I'm considering adding is heat buildup. The potential reason for this mechanic is that it's theoretically possible for a ship to have so many shields and enough crew and power to keep them active that you'll never be able to bust through; and if your ship also has impenetrable shields, that could cause a stalemate. A potential solution to this kind of stalemate is to, as the shield takes enemy fire, have it build up more and more heat until, eventually, the shield generator either deactivates or maybe even explodes.

I have not added this heat-buildup mechanic because I don't want to make the rules for shield generators unnecessarily complex and less intuitive unless I'm absolutely sure that they're needed. If you find that you're getting into these kinds of stalemates while playing, then please let me know!

As always, I encourage you to download StarWright and post your feedback!

[wizered67]

Hi, I just tried out the new update and I'm liking the shields! Are new updates incompatible with old saves? I tried playing on an old save and it gave an error when it auto-saved. I understand if it doesn't work with old saves but maybe there could be some indication which saves are incompatible? I can PM you the error message if you want. 

[Walt Destler]

Hi, I just tried out the new update and I'm liking the shields! Are new updates incompatible with old saves? I tried playing on an old save and it gave an error when it auto-saved. I understand if it doesn't work with old saves but maybe there could be some indication which saves are incompatible? I can PM you the error message if you want. 

I generally try not to break old saves, but sometimes it's unavoidable since the game is changing so much.

However, if an old saved game no longer works, you should get an error (not a crash) when *loading* the old saved game, not when saving it. So in your case, there's definitely some sort of bug going on, which I definitely want to look in to.

It would help me greatly if you could send me both the saved game itself and the log file after you get the error. Those files are located at:
C:\Users\[username]\AppData\Roaming\StarWright\Saved Games\
C:\Users\[username]\AppData\Roaming\StarWright\log.txt

Thanks!

[Walt Destler]

Hi, I just tried out the new update and I'm liking the shields! Are new updates incompatible with old saves? I tried playing on an old save and it gave an error when it auto-saved. I understand if it doesn't work with old saves but maybe there could be some indication which saves are incompatible? I can PM you the error message if you want. 

I generally try not to break old saves, but sometimes it's unavoidable since the game is changing so much.

However, if an old saved game no longer works, you should get an error (not a crash) when *loading* the old saved game, not when saving it. So in your case, there's definitely some sort of bug going on, which I definitely want to look in to.

It would help me greatly if you could send me both the saved game itself and the log file after you get the error. Those files are located at:
C:\Users\[username]\AppData\Roaming\StarWright\Saved Games\
C:\Users\[username]\AppData\Roaming\StarWright\log.txt

Thanks!

I managed to track down one bug that would cause a crash during saving after loading an old saved game. That bug (and a couple others) have now been fixed in 0.6.1, which you can download here: http://starwright.waltdestler.com/

[Equalizer]

Have you considered making ships damage each other when they collide?

This would make stalemates not happen since a player could have their ship ram the enemy ship if weapons aren't cutting it. Other than resolving stalemates it could open up more possible strategies.

[Walt Destler]

Have you considered making ships damage each other when they collide?

This would make stalemates not happen since a player could have their ship ram the enemy ship if weapons aren't cutting it. Other than resolving stalemates it could open up more possible strategies.

The original prototype actually had collision damage. It turns out that it's pretty hard to balance and to get feeling right, but I haven't ruled it out. (And there's currently a weakness in the ship AI that makes ships frequently bump into each other, which I'll have to fix first.)

I've also thought about having actual "melee" weapons (think giant buzzsaw asteroid grinders that work equally well for chewing up enemy ships) to give the player more options for very close-range combat.

[Walt Destler]

Today I released StarWright 0.7.0!

This latest major release adds the 'Ion Beam Emitter' weapon:



The Ion Beam shoots an extremely powerful (and power-hungry) beam of ion energy that will quickly rip holes in enemy ships. It is currently the most powerful weapon in the game in terms of how much damage it can do every second, and it's particularly effective at sawing ships into pieces.

But as powerful as the Ion Beam is, it does have some key weaknesses:

• Unlike the other weapons currently in the game, the Ion Beam Emitter is so heavy that it can't be mounted on a turret and thus must be fixed directly to the ship's hull. This means that the ion beam can only shoot in a straight line (as determined by which way the ship is facing), and thus is very difficult to aim with any precision.
• Firing the ion beam uses a lot of power very fast. If you want to keep the ion beam active for more than a few seconds, you'll need a lot of power being constantly delivered to it.
• Unlike the other weapons, the Ion Beam Emitter is very weakly armored, making it a potential Achilles' heel through which enemy fire can reach the inside of your ship.
• While the Ion Beam Emitter is only two spaces wide, it is four spaces deep, three of which cannot be traveled by crew. This may force you to re-think your ship's layout and cause issues with ammo and power delivery to other systems.

Please feel free to download the game and post your feedback!

[Walt Destler]

Yesterday I released StarWright 0.8.0. The main focus of this release was to greatly improve the user interface (or "user experience" to use the trendy modern term) for designing and constructing ships. This is the culmination of the U.I. work that started with 0.7.1 (the ship "info card" in the corner) and 0.7.2 (the separate repair and crew management U.I.s), which I will also talk about in this post.

Let's back way up first, and talk about the original U.I. for constructing ships: At the beginning of time (StarWright's lifetime, anyway), designing starships was done using a user interface that was completely separate from the gameplay:



You'd hop into the "Builder" and design your ship on a grid. When you were happy with your design and wanted to test it, you'd press the "Save & Test" button, which would switch you to a testing game environment where you could spawn enemy ships to test your ship's combat prowess against.

And then I watched

in which he persuasively argued that user interfaces are hampered when the user makes a choice but the feedback from the user interface about that choice is delayed. I realized that StarWright (called "ShipBuilder" at the time) suffered from the same delay in that the player didn't see the effects of their design changes until they actually hit the "Save & Test" button. This was unlike most other "construction" games such as SimCity in which you can immediately see how placing a building effects things like power, water, and roads. And so I decided to merge the ship editor and gameplay environment into a new environment that I called the "Sandbox":



In this new environment you could add a part to your ship (like a cannon) and very quickly see how that new part interacts with the simulation of your ship as a whole (crew running over to operate it) and any problems that it has (crew can't get any ammo to it). (I wrote about this change more extensively in a blog post from way back in 2012.)

This was a really big improvement! Being able to watch a ship operate as it was designed really made learning the rules of the ship simulation much more intuitive, and players felt like they were making much more informed (and successful) ship design decisions.

Now let's fast forward again by a few years (I had a job, okay?) to late 2015, as I was beginning to ramp development on StarWright back up to full speed. Up to this point, there was no real challenge or economy in the game; it was just a free-form sandbox mode where you could build whatever you want. And while creative/sandbox modes in these kinds of games are great (yes, I plan on keeping the "Creative Mode" forever and ever), my ultimate vision for the game was that the player would start with a small ship, earn money by going on missions and defeating enemy ships, and expand their own ship over time.

But this caused a couple of conflicts with how ships were built:

• Adding parts to ships needed to cost money, but the player shouldn't be forced to waste money when they accidentally place a part in the wrong location or if they change their mind halfway through an in-progress design.
• It needed to be easy and convenient for the player to restore a partially-destroyed ship back to its intended design.

My solution to these two problems was to introduce the "Blueprint" mode, which separated a ship's design (i.e., its blueprints) from its current physical condition:



I talk more about the Blueprint mode in another blog post, but to summarize how it solved these two problems:

• Players would make modifications to the ship's blueprints instead of the ship itself. The player could freely modify the blueprints without being charged any money. Once the player was satisfied with their design, they pressed the big "MAKE IT SO" button on the right, and -- voila! -- their ship was updated to match their blueprint design and the appropriate amount of money was subtracted from their funds. (If you're thinking, "But Walt, wasn't being able to immediately see the results of design changes a good thing? Why get rid of that?", then my only response to you is, I wish you were there to remind me of that in Nov. 2015!)
• While a ship could take damage and have parts of it completely destroyed, its blueprints would remain unaffected. If the player wanted to repair their ship back to its intended design, they could just open up the Blueprints mode and click "MAKE IT SO" again.

The first problem I realized that blueprints had was with repairing: While it was definitely A Good Thing that players were able to easily repair their ship back to its original state, I quickly discovered that players (including me) would often do the following:

• Fight and defeat an enemy, taking some damage and earning some bounty money.
• Open up the Blueprint mode and design some awesome additions for their ship.
• Realize they can't afford their new awesome design, and so decide to go earn another bounty.
• Want to repair their ship, but realize they can't without undoing all their glorious design work!
• Get really angry.

And so I decided to add a "Repair" option. When this option was selected, pressing the "MAKE IT SO" button, instead of making your ship's physical condition match its blueprints, would make your ship match how it was the last time you pressed that button.

And this is how it's worked for the past few months. All problems solved?

Of course not:

• I realized (again) that players were having a harder time designing their ships because they weren't getting immediate feedback from the game simulation on their design changes. Somehow, in my excitement to make Bounty Mode work, I had forgotten that immediate feedback was A Really Good Thing.
• The "Repair" option next to the "MAKE IT SO" button was both confusing and limiting. Confusing because it was a very important feature that was buried as an option inside the Blueprint mode user interface despite having, literally, nothing to do with blueprints. And limiting because it was an all-or-nothing choice; there was no option to selectively repair only certain parts of your ship.

And so I embarked on my weeks-long journey to fix these two problems...

First up, I decided to dedicate a separate user interface to repairing ships; a U.I. which would be accessed by its own "Repair" button sitting co-equally right next to the "Build" button.

And so I started to work on-- screeeech, halt! ... Nevermind. Instead, I decided to first implement another U.I. feature that I'd been wanting for a while. Even though that feature wasn't really necessary to solve the above problems, its code would be very intertwined with the code for solving the above problems, and it'd take less time to implement it before solving those problems than after. This feature was the Ship Hub:



The general idea behind the Ship Hub was that it'd be the place on the screen where the player would go to interact with their ship in any way. The dark rectangular card shows a silhouette icon of the ship, it's name, and some other basic information. (And the '...' button exposes some lesser-used options that used to be in the super-awkward alt-right-click menu.) Above the informational card would be all the buttons to access various ship features, such as the ship design U.I. and, eventually, repairs and crew. The Ship Hub was released in version 0.7.1.

With the Ship Hub completed and out-of-the-way, I did, finally, implement the new repairing U.I.:



The "Repair Mode" is accessed by clicking the green wrench icon next to the Build button.

The cool thing about Repair Mode is that it shows you exactly which parts are damaged or destroyed with a red wrench icon for damaged parts or a red overlay for missing destroyed parts. Clicking on a damaged or missing part will repair that specific part. Or you can simply click the big "REPAIR ALL" button to fix everything at once!

I'm pretty happy with this new Repair Mode user interface. It's much more easily accessed and prominently displayed, and it is also much more flexible since you can, optionally, pick individual parts to be repaired. Repair Mode was released in version 0.7.2.

Also released in 0.7.2 was a little U.I. for managing your ship's crew:



This shows you your current number of crew relative to the number of crew your ship can carry. And it has three buttons for adjusting the number of crew: The first button adds one crew, the second button fills your ship up to its maximum crew capacity (or as many crew as you can afford to hire), and the third button fires one crew. That's it!

This also wasn't strictly necessary for solving those two big problems, but it was easy to implement and is nice to have. Eventually I plan on having individual crew members with different ranks and abilities, and this user interface will be fleshed out to manage them.

0.7.3 and 0.7.4 were interim bugfix released that I put out while I was working on revamping the user interface for designing ships.

With repairing ships handled via a completely separate interface, I realized that the only major design impediment to letting the player directly add and remove parts from their ship was the risk of them wasting money by making accidental mistakes or backtracking on their design. And then I realized that the only reason this was actually a problem was that removing a part didn't refund the full cost of adding that part in the first place (it refunded 75%). And so I made the decision to refund the player the full original cost when removing a part, and now the player can undo any design change they make without having wasted any money. (I had originally added the 25% "deconstruction" tax as a way to incentivize picking a design and sticking with it, but I think being able to directly modify your ship and freely experiment is worth getting rid of the tax.)

And so with that last design hurdle out-of-the-way, I split ship designing into two separate modes: Direct Edit mode and Blueprint mode...



Blueprint mode isn't much changed from how it worked these past few months: You can freely make modifications to your ship's blueprints without regard for cost, and then when you're happy with them, you press the "MAKE IT SO" button. In fact, Blueprint mode has gotten even better, because now it will let you temporarily place blueprints in illegal locations as you plan things out, so long as you fix any problems before clicking "MAKE IT SO".



Direct Edit mode on the other hand is brand new. In this mode you directly add and remove parts to and from your ship, being charged or refunded as you go. (And behind-the-scenes, the blueprints will be kept up-to-date with your changes as well.) It's somewhat more restrictive than Blueprint mode in that you can't make any change that would put your ship into an illegal configuration. But on the flip side, you can see the immediate effects or problems of any changes you make, such as whether crew can access a room or whether a laser cannon has power.

Both modes are accessed by clicking the "Build" button in the lower-left above the ship information card. The Direct Edit mode will be shown by default (although if you prefer Blueprint mode, you can make it the default in the settings), and you can then switch to Blueprint mode by clicking the blue blueprints button that expands out from the build button.

There are some restrictions to when you can use Direct Edit mode that don't apply to Blueprint mode. In particular, you can't use Direct Edit mode during combat or while in debt. In addition, if your ship has any destroyed parts, those parts must be repaired before entering Direct Edit. And if you've made any modifications in blueprint mode, those modifications must be either committed or discarded before returning to Direct Edit mode. (If you open the ship designer and Direct Edit mode is unavailable for any reason, Blueprint mode will be shown instead.) These restrictions are necessary to make sure that you can't make any changes in Direct Edit mode that would break either the Blueprint or Repair modes.

I also took the opportunity to improve the design experience of both Direct Edit and Blueprint modes in some nice ways:

• While in either Direct Edit or Blueprint modes, the background is dimmed and a build grid is displayed underneath your ship. This should make it easier to eyeball distances and also make it more obvious when you're in design mode instead of being able to control your ship.
• The cost (or refund) of making any changes to your ship is shown underneath the mouse cursor.
• The logic that determines where to automatically add doors between parts has been greatly improved, especially when the "Overwrite Existing Parts" option is turned on (as it is now by default). It will no longer remove any doors that didn't actually need to be removed, and it's much smarter and more aggressive about adding doors as new parts are placed. This is the kind of improvement that, if it works well, you won't notice it at all!
• Adding a Crew's Quarters or Crew's Bunk in Direct Edit mode will, by default, automatically hire crew to go along with it.
• And lots of other little improvements that you can read about in the version history.

As always, thanks for playing! And please post whatever feedback you have!

[Walt Destler]

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:

• It needed to be clear and descriptive. Duh.
• 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.
• 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:

• The player can now change what monitor the game runs on without restarting the application.
• 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:

• Make ships feel more tangible and real.
• 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!

[Walt Destler]

It's been a while since I've posted here about Cosmoteer, so this is going to be a longish post as I catch up on some of the new features since last time...

Oh, but before I begin, I also want to mention that Cosmoteer now has an Official Community Forum!

Copy & Paste

I'm generally very happy with how intuitive ship design has become. When I watch new players play the game, rarely do they have much trouble figuring out how to modify and expand their ship, thanks to many iterations and improvements to the user interface

But many players, myself included, found the process of designing larger ships (especially in Creative Mode) with repeated sections (possibly rotated and/or flipped) to be very tedious, since every part on the ship had to be added individually, even if a whole section of the ship was merely a copy of another section.

Let's say that you want to build a symmetrical ship with a center fuselage and mirrored wings on each side. So you start by designing the center fuselage and one of the wings. Prior to this release, you'd have to manually design the other wing as well, being very careful to exactly mirror the original wing. But now, you can use the new "copy and paste" tool, first selecting all the parts on the left wing...



... then clicking the "copy" button (ctrl-c works, too), followed by the "paste" (ctrl-v) button, which will load the copied parts as blueprints on your mouse cursor. Once in paste mode, you can choose to rotate and/or flip the blueprints before pasting them onto your ship...



... and then you simply click to add those parts to your ship, giving us the final result:



I'm very hopeful that this will make designing large, interesting ships much easier. Indeed, I can already find myself being more creative in my own ship designs, knowing that I won't have to duplicate any designs that I want to repeat elsewhere. (It's also worth noting that the copy & paste tool can be used to copy between ships as well.)

While this may seem like a pretty basic feature, it was actually a very serious technical undertaking to get this working. Ever since I (re)introduced the now-default "live design" mode, I've had code logic to determine whether adding a single part to a particular location was legal, but there was no code to determine whether adding multiple parts in arbitrary locations was legal, which is a far harder problem to solve, because some of those new parts may only be legal because of other parts that are also being added or may be illegal because of other added parts.

Part Micromanagement

I added the ability to micromanage individual parts, letting you give them individual targets, turn them off or back on, or tell them to hold fire.

To control the individual parts on your ship, first select your ship if it isn't already selected. Then, click on a specific part or drag a box around the parts you want to select:





The user interface in the bottom-left will change to give you some options pertaining to the parts you have selected. Most parts that consume power or ammo can be turned off, causing their crew to go perform any other jobs that need doing. And weapons can be told to "hold fire", which will prevent them from shooting unless you've given them a specific target, which you can do by right-clicking on a part of an enemy ship.

Additionally, I also added "control groups" like those found in most conventional RTS games. To put the selected ships into a control group, press Ctrl-F1 through Ctrl-F8, and then press F1 through F8 to select the ships in that control group. To put the selected parts into a control group, press Ctrl-0 through Ctrl-9, and then press 0 through 9 to select the parts (of the currently-selected ships) in that control group.

Customizable Controls

I love PC games, and one of the reasons that I love PC games is because, at their best, they're very customizable. But it really bothers me when a PC game (frequently ports of console games) lack what IMHO are pretty standard PC gaming features; things like borderless window mode, support for computers with multiple monitors, support for high-resolution displays, triple-buffering, and good alt-tab handling, all of which Cosmoteer does well. But there's one standard PC gaming feature that Cosmoteer hasn't had (which I've been a bit ashamed about, as an avid PC gamer), and that is customize keyboard controls.

Until now!

Cosmoteer now lets you customize pretty much every control in the game. Want to change the hotkey for opening build mode to Shift-B? You can do that! Want to set Q as a shortcut to select the Crew's Quarters in build mode? You can do that! Want to make shift-tilde-apostrophe act as a left mouse click? Well, you're insane, but you can do that! There are currently 134 different actions that can be assigned to keyboard keys or mouse buttons, and each action can have two different key/mouse button combinations set to it.



Customizable controls are great for those of us who really like to personalize our gaming experiences, but they're also really important for making the game accessible to people who have physical disabilities; customizable controls allow them to tailor the game's controls to their own abilities so that they can still play and enjoy the game, even if the default setup doesn't work for them.

Oh, and also, by popular demand, WASD is now supported by default (in addition to the arrow keys) as a way of panning the game view. (And some existing shortcut keys got moved as a result.)

New Main Menu Design & Layout

The Main Menu has received a bit of an overhaul:



Now, the most-commonly-used options (New Game, Load Game, and Exit) are at the top of the screen, while lesser-used options are at the bottom. The primary purpose of this change is to create more room for options to be added as the game expands. I've already used this newfound room to add a "Community" button, which takes you directly to the online forum. Eventually I may add more options, such as multiplayer and mod settings.

Multi-Language Technology

Until this release, most of the text displayed by the game was written directly into the game's source code. This worked fine while the game was in the prototype stage, but it made it impossible to translate ("localize") the game into other languages. So I spent a couple days building a system to allow all of the game's text to be loaded from an external file, which can then be translated into other languages. While currently the only included language is English, it's now possible to translate the "en.txt" file into other languages and simply drop them into the "Data/Strings" directory. The game will automatically detect the additional languages and allow the player to switch between them in the Settings menu.

Here's an example of what the "en.txt" file looks like:

[Walt Destler]

Some new major features I've gotten done in the past few months:

Bounty Hunter 2.0

For about the past year, the standard mode of play, "Bounty Hunter", has been pretty simplistic. You, the player, start with a single ship and destroy enemy ships in the immediate vicinity to earn money which can then be used to upgrade your own ship or purchase additional ships. As you destroy enemy ships, additional enemies spawn nearby, and as your own ship or fleet increases in power, the larger, more powerful enemies swill spawn as well.

This simple kill-reward-upgrade-repeat loop has been fine for testing and iterating on the core ship construction and combat gameplay mechanics, but it honestly wasn't very engaging for the player. Killing an endless stream of ships over-and-over again in the same location with little choice gets repetitive really fast.

Bounty Hunter 2.0, while not solving all of the issues of Bounty Hunter 1.0, seeks to create a much stronger foundation upon which further improvements can be built. Instead of playing in a single location with an unlimited supply of respawning enemies, the game is now played across a large galactic map:



Each location in the galaxy map (the green icons) has only a handful of enemies, and they don't respawn as you destroy them. Instead, once the player destroys all of the enemies in a location, they must move on to another location. Each location has a small colored "shield" icon that indicates the strength of enemies present there:



In Bounty Hunter 1.0, the game itself determined the difficulty of enemies that the player would face, which meant that for many players the enemies were either too easy or too difficult. This new system gives the player a degree of choice in what strengths of enemies they will face, and lets the player pace their own difficulty curve.

More importantly, this new galaxy map now provides a strong foundation on which more gameplay can be added. In the future, as the player explores the galaxy, they will encounter space stations to trade with, pirate bases, asteroids to mine, vessels in distress, and more. These features will be added to the game over time as they are developed.

The galaxy map itself is procedurally generated, usually with 4-6 solar systems full of planets and moons. Each location is "attached" to a nearby planet or moon, which then appears in the background during gameplay to give visual variety and a better sense of location. The planets, moons, and stars themselves are procedurally generated using Perlin Noise. Blue, red, and yellow nebulas also abound in the galaxies, which determine the color of the background during gameplay.

F.T.L. Drives

In order to move from location to location within the galaxy, the player must construct at least one F.T.L. (Faster Than Light) Drive on their ship. Once constructed, the FTL drive allows the player to perform jumps to other locations.



Jumping, however, is not free. F.T.L. Drives use a new kind of "fuel" resource. Like credits, fuel is earned from destroying enemy ships, and then it is spent to perform an F.T.L. jump. The amount of fuel spent is determined by the distance of the jump, the size of the ship(s) making the jump, and the efficiency of the ship's F.T.L. Drives.

Efficiency is a new concept in Cosmoteer that determines how much fuel is used when an F.T.L. jump is performed, and its gameplay purpose is to make the number and placement of F.T.L. Drives on a ship a strategically important decision. When adding an F.T.L. drive to a ship, the game displays a green/yellow/red overlay indicating which areas of the ship are close to an F.T.L. drive (green) compared to which areas are far from one (red).



The farther (more red) areas greatly increase the amount of fuel need to perform an F.T.L. jump. And so to minimize the amount of fuel used, the player will want to place multiple F.T.L. drives around their ship in a variety of locations, making as much of the ship green as possible.

If the player ever runs out of F.T.L. fuel, they can purchase additional fuel for credits, but doing so is extremely expensive, and so it is almost always preferable to improve the efficiency of one's ship.

Because the amount of F.T.L. fuel earned from destroying enemies depends on the size of the enemy ship, as your own ship(s) grow in size, it becomes much less cost-effective to battle enemies that are smaller and weaker than yourself. (If you spend fuel to jump a very large ship to a location with small enemies, it is unlikely that you will earn enough fuel to recoup the fuel that you spent getting there.) My intent when balancing fuel costs vs rewards is that a ship with 75+% efficiency that fights ships its own size will generally break even on fuel.

User Interface Refresh

The user interface has received a complete visual overhaul -- gone are the boring gray boxes, replaced with a spacey blue-and-green theme complete with sound effects and animations.

Before:


After:


Aside from the visual changes, there are also some small-but-important changes to the actual functionality of the user interface.

First, the player can no longer (by default, although this can be reverted in the settings) simply click on or drag a box around specific parts to select them -- the player must now hold the Ctrl key while clicking. This is because my playtesting showed that many new players would accidentally click on parts of their ship and then be unable to give their ship orders, which was confusing and frustrating for them. By requiring the Ctrl key be held, it's now almost impossible to accidentally select parts without meaning to.

Second, because you can't upgrade your ship until you repair it, the game now only shows either the repair button or the build button, never both at the same time. (When your ship needs repairs, the repair button is shown in the place of the build button.) In some playtests, players got confused about why they couldn't press the build button, and so this change should hopefully make that more obvious.

Lastly, turning on "blueprints mode" is no longer a strange toggle that appears next to the build button after pressing it -- it is now a simple checkbox item in the '...' menu, and the game now remembers your preference.

[Walt Destler]

Last week I released version 0.11.0 of Cosmoteer. It, and version 0.10.7 before it, add some significant new features and improvements to the game's user interface.

The most important new feature in 0.11.0 is the "Fog of War":



If you play RTS games, you are likely already familiar with the basic concept. You ships can only "see" so far away, and anything farther than your ships' sight range is hidden in the "fog of war". In the above screenshot, the darkened areas of the background indicate areas that are too far from your ships to see.

Currently, the locations enemy ships that are outside of your own ships' sight will still be indicated with pulsing red dots, which you can see in the lower-right corner. These tell you where you need to go to find something to fight, but offer no additional details such as the size or armaments of the enemy.

The Fog of War changes gameplay, because now there's some risk involved in choosing to fight an enemy. It may turn out that the enemy is too powerful for you to defeat, and you'll need to run away. Occasionally needing to run away also has the added effect of making fast and maneuverable ships more important.

Version 0.10.7 also added a "Minimap":



The minimap is a long-requested feature that provides a simple overview of the locations of friendly and enemy ships. Unlike most RTS games which are played on a fixed-size battlefield, the playing area in Cosmoteer has no walls or borders and is infinite for all practical purposes. Therefore, the minimap automatically adjusts to show an area containing all of the ships in the game. The grid in the background always maintains the same spatial distance between lines, and so you can use the grid to estimate distances between ships.

Version 0.10.7 also added what I call the "Miniview":



The miniview is basically a "picture-in-picture" view of a single ship, allowing you to view one ship in the main view and another ship in the miniview at the same time. My hope is that it solves one of the biggest usability problems that Cosmoteer has had up to now, which is that during combat you can't watch both your ship and the enemy ship at the same time without zooming out and losing a lot of the important simulation details.

The miniview also isn't just for show, either -- you can also hover the mouse cursor over ship parts to see their health and right-click on them to target, all without having to move the main camera.

The miniview is customizable, but by default, it is automatically displayed during combat and will show either your ship or the enemy ship -- whichever one you're not looking at in the main view. When displayed, the miniview replaces the minimap, which is generally less useful during combat anyway. Both the miniview and the minimap can be resized as desired to take up more or less space on your screen.

[Pineapple]

I'm really enjoying this! I like the variety in ship parts and enemies.

Two really annoying things though:

I'd really like an option to turn off scrolling when the mouse is at the edge of the screen. I use the middle mouse exclusively and I keep accidentally scrolling when I just want to hit a button in the corner.

Some enemies are really obnoxiously hard to kill just because they're constantly strafing and the weapons can't track them, and almost every shot goes a little wide and misses the ship entirely. Sometimes I can compensate by targeting a different part, sometimes not. The game would be a lot more fun if like, my weapons would actually consistently connect with a ship that's not doing anything unpredictable.

edit: After making a very irritatingly quick ship of my own that nobody can hit, the second point doesn't hurt quite as much.

[Walt Destler]

I'd really like an option to turn off scrolling when the mouse is at the edge of the screen. I use the middle mouse exclusively and I keep accidentally scrolling when I just want to hit a button in the corner.

You can do this, though admittedly the option is a bit hard to find... Go into Settings, click the Interface tab, open the View Controls category, and change Edge Pan to Disabled.

Some enemies are really obnoxiously hard to kill just because they're constantly strafing and the weapons can't track them, and almost every shot goes a little wide and misses the ship entirely. Sometimes I can compensate by targeting a different part, sometimes not. The game would be a lot more fun if like, my weapons would actually consistently connect with a ship that's not doing anything unpredictable.

I agree, this is pretty annoying. The current algorithm works great when the target is moving at a constant linear velocity, but otherwise doesn't work well. I'll think about how to improve it.

Thanks for playing, and for your feedback!

[Pineapple]

I've been playing this more (Seriously, this game is excellent) and I have a couple more suggestions

Managing more than one ship is really hairy, for a few reasons:

Most of the time the enemy will just chase the weakest, fastest ship and ignore the others, and so the enemy gets lightly pounded while the slower ships struggle to keep it targeted, the enemy ship totally fails to keep up with the fast one. I feel like the AI should be better at recognizing which ships are actually a threat to it rather than always going for the one that only has a couple laser batteries.

Another thing that's not too bad since there doesn't seem to be friendly fire: My ships are completely oblivious to strafing across the bow of another and soaking up laser and cannon fire meant for the enemy. And I think a decent solution to this would be...

The ability to right click an enemy and drag to specify the angle a ship should attack from is good, but then the ship wastes a lot of time trying to maintain the position when all I really want is for it to keep its big lasers on the target. It would be good to be able to say, "Attack from this angle relative to world space, not relative to the ship" so that I can actually use multiple ships to flank an enemy instead of them getting tangled in each others' paths as the target turns. An option to also say, "Attack and I don't give a damn what angle you do it from" would be helpful, and probably ought to be the default when you right click without dragging.

Personally I would prefer if I could get a full refund for sold ship parts rather than a partial refund. Maybe in a future release there could be an option to specify how much you're refunded for parts?

Also - is there any way to add more enemy ship types, perhaps from blueprints I created in-game?

[Walt Destler]

Seriously, this game is excellent

Thanks so much for your kind words! They help keep me motivated.

I feel like the AI should be better at recognizing which ships are actually a threat to it rather than always going for the one that only has a couple laser batteries.

Good call. This shouldn't be hard too hard to do. I'll add it for the next release.

It would be good to be able to say, "Attack from this angle relative to world space, not relative to the ship" so that I can actually use multiple ships to flank an enemy instead of them getting tangled in each others' paths as the target turns.

Funny enough, that is how it *used* to work, but so many people asked for ship-relative angles that I changed it. But I can certainly see how having both options would be useful. I'll try to think of a way to make that work in the UI.

An option to also say, "Attack and I don't give a damn what angle you do it from" would be helpful, and probably ought to be the default when you right click without dragging.

Unless I misunderstand you, that's how it works right now. If you don't click-and-drag (or hold shift and manually adjust the angle), your ship will try to maintain distance but won't care about the angle relative to the enemy.

Personally I would prefer if I could get a full refund for sold ship parts rather than a partial refund. Maybe in a future release there could be an option to specify how much you're refunded for parts?

This is also how it used to work, but I changed it when I added the FTL fuel mechanic. Reason being, there was an exploit where you could sell most of your ship before jumping, save a bunch of fuel, and then rebuild it after jumping at no expense.

If you don't know (the game never explains this), you *do* get a 100% refund for any "newly-added" parts, where "new" is defined as "since the last time the ship was in combat or made an FTL jump". So you can experiment and undo/redo to your heart's content as long as you don't enter combat or make an FTL jump.

If you want to change this, it's easy to mod. Look in Data\Ships\base part.txt and edit the FractionalSaleRefund value.

Also - is there any way to add more enemy ship types, perhaps from blueprints I created in-game?

There's currently no built-in way, but you can mod them in. Look in Data\Bounty Mode\bounty mode.txt, and look for the Bounties and GeneratedBounties sections. You can add your own designs to either of those sections and they will spawn in the game.

A note of warning: Any changes you make inside the Data folder will get overwritten when reinstalling the game, including when upgrading to a new version. I recommend making a copy of the game folder and doing your work in there.