next »

[Pineapple]

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

Thank you for the game!

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.

Ha, I suppose you can never please everyone. I do think having both options would be ideal though. Maybe right click + shift could have one behavior and right click without shift could do the other?

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.

Ha, I hadn't realized. Cool. Did it explain that in the tutorial pop-ups and I glossed over it? I remember it describing the right click and drag behavior, but not specifying that without dragging it will only maintain distance. If not it might be helpful to explain that too.

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.

Yeah, there have been a couple times when I even wondered if it might have been more cost-efficient to sell a ship than to buy more fuel even with the partial return, but fuel costs little enough that I haven't had to resort to that sort of thing yet. I still think a slider in gameplay options could be cool though, or maybe just a few preset difficulty options where the return is 100% on Easy, and more unforgiving on Hard.

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

Gotta love mod-friendly games

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.

Exactly what I was hoping for, actually. Do you accept suggestion blueprints?

[Walt Destler]

Maybe right click + shift could have one behavior and right click without shift could do the other?

That sounds... reasonable. Only complaint is it's not really intuitive. (But there are already a bunch of advanced controls bound to holding keys, so maybe I'm overthinking it.) I can probably throw an icon on to indicate whether you're in world-relative or ship-relative mode.

Did it explain that in the tutorial pop-ups and I glossed over it? I remember it describing the right click and drag behavior, but not specifying that without dragging it will only maintain distance. If not it might be helpful to explain that too.

The tutorials do not explicitly explain that, no. I guess I assumed people would figure out the default behavior before getting to the advanced tutorials. Apparently not a great assumption. :p

I still think a slider in gameplay options could be cool though, or maybe just a few preset difficulty options where the return is 100% on Easy, and more unforgiving on Hard.

Difficulty options sounds good. They could also effect the amounts of money and fuel that are awarded, as well as aggressiveness of the A.I.

Do you accept suggestion blueprints?

I've been hesitant to include ship designs from other people before talking to a lawyer about the legal implications of that. However, you could make a mod and post it on the official forum, and I'm sure the other players would love it!

[Pineapple]

The tutorials do not explicitly explain that, no. I guess I assumed people would figure out the default behavior before getting to the advanced tutorials. Apparently not a great assumption. :p

At first I think that is what I assumed, but then once it got to the advanced behavior, from the graphics that appear when you right click regularly it seemed like it was just choosing the orientation it was already at and would maintain it.

I've been hesitant to include ship designs from other people before talking to a lawyer about the legal implications of that. However, you could make a mod and post it on the official forum, and I'm sure the other players would love it!

I'll have to do that!

What I typically do for open source code projects I work on is distribute the code under a license where the only constraint is pretty much "don't lie about where it came from", and if I end up posting mods I'll do the same or something similar. (I'm fond of the zlib/libpng license in particular.)

[Walt Destler]

At first I think that is what I assumed, but then once it got to the advanced behavior, from the graphics that appear when you right click regularly it seemed like it was just choosing the orientation it was already at and would maintain it.

A lot of people get confused by the distance circle and don't understand what it signifies, so I may just get rid of it entirely. In cases when a ship- or world-relative angle is given, I have an idea for how to show that in a clearer way.

What I typically do for open source code projects I work on is distribute the code under a license where the only constraint is pretty much "don't lie about where it came from", and if I end up posting mods I'll do the same or something similar. (I'm fond of the zlib/libpng license in particular.)

I think I would be comfortable including ships that were released under a well-known OSS or Creative Commons license.

[Walt Destler]

Last week, I released version 0.11.4 of Cosmoteer. Despite only being a minor bump in version number, this release has lots of new stuff! The changelog lists all of the many improvements and bug fixes in this version, but the ones I want to talk about here are the greatly improved visual and particle effects.

In order to realize my vision for how I wanted the visual effects to look, I knew that I would first need to completely rewrite Cosmoteer's particle code, because the existing particle code was both slow and too inflexible. By using some very low-level C# code (utilizing some great new C# 7 features), I was able to create a new particle system that is not only more flexible than the previous version, but it is also much, much faster. The new particle system can handle about 100 times the number of particles as the old system while maintaining the same framerate.

The new particle system has allowed me to create much more interesting and exciting visual effects for weapons, thrusters, and explosions.

The first visual effect I upgraded was for the thrusters:




This is a pretty big improvement from the previous thrusters, which for performance reasons had far fewer particles. (The quality of these GIFs aren't great -- you should load up the latest version of Cosmoteer to check out all the new effects for yourself!)

Then, I upgraded the visual effects for when the various weapons fire:











It's hard to see in the above GIFs, but the appearance of the laser and bullet projectiles has also received a significant upgrade.

Lastly, I upgraded all the various weapon impact and part explosion effects:










(You may notice in that last GIF that, when the reactor is destroyed, the explosion also destroys much of the surrounding ship parts. This "collateral damage" is a new gameplay mechanic intended to make you think more carefully about where you place reactors, ammo factories, and cannons, all of which cause collateral damage when destroyed.)

If you're worried that your computer can't handle all the new particle effects, then fear not, I have a trick up my sleeve! Most of the particles you see above are actually "pre-rendered" as simple sprite frame animations. The sprite animation serves as the "core" of the effect, providing most of the visual punch. On top of the core sprite animation, extra particles (such as debris pieces and smoke clouds) are created to give it more visual interest and variety. But these extra particle are entirely optional and can be turned off by disabling the "Fancy Particles" option in the game settings. With this option turned off, Cosmoteer actually renders fewer particles than in previous versions while still looking significantly better.

[Pineapple]

Very pretty. I especially like the idea of collateral damage, it'll be interesting to see how it affects gameplay!

[wizered67]

Great work and I'm happy to hear that you made it to be able to run on as many computers as possible. Always looking forward to seeing more updates of this game!

[Walt Destler]

This past Wednesday I released live to the world version 0.12.0 of Cosmoteer, and oh boy was this a big release! It's got new weapons, new defenses, a new game mechanic, and some great user interface improvements.

Missiles

Probably the most exciting new feature is missiles. Missiles are long-range homing weapons that do high damage in an area-of-effect wherever they hit.






Unlike the other weapons, which require line-of-sight to their target, missile launchers can be safely tucked away on the sides of ships, thanks to the missiles' own homing and obstacle detection systems.

Similar to the cannons, missile launchers require their own kind of munitions -- that is, "missile parts". These missile parts are manufactured in a "missile factory" and then each missile part is hand-carried by the crew to the missile launcher.



Each individual missile is made out of four individual missile parts, and each crewmember can only carry one missile part, so it takes a lot longer to load a missile launcher than it does to load a cannon.

If you take a close look at the missile launcher itself, you might notice that there are only two possible locations for doors, and they're on the sides of the launcher instead of in the rear as one might expect. The "in-fiction" justification for this is because crew have to be able to reach the missile tubes to load them and therefore the only place the control panel could go was against the back wall. But there's a also a game design reason for this: I like to make different ship modules have various different sizes and door access locations so that you, the player, have to think more about the layout of your ship. I want designing a good ship to be a lot like solving a jigsaw puzzle, trying to get all the pieces to fit right. If all modules were the same size, it would be a lot easier to design a perfect ship.

Point Defense Systems

While very powerful, there is one major disadvantage of missiles: They can be shot down by the new "Point Defense Systems" that were also added in 0.12.0.




Point Defense Systems (PDS) are tiny automated gun turrets. They can't damage enemy ships, but, unlike other weapons, they can shoot down incoming missiles that come too close to them. PDS fire rapidly but are fairly inaccurate, and so it is often a good idea to cluster several PDS together to create a "wall" of gunfire which can shoot down almost all incoming missiles.

A ship without any PDS will be very susceptible to long-range missile fire from enemy ships.

Electro-Bolt

The missile launcher isn't the only new weapon in 0.12.0 -- it also adds the "Electro-Bolt". This is a short-range weapon that fires bolts of electricity. While this electricity does little damage to enemy ships, any systems that get hit by an electro-bolt will be drained of some of their power. As such, electro-bolts are an effective counter against enemy energy weapons (laser blasters, ion beams, and other electro-bolts) and shields (when the electro-bolt hits the energy field it's treated as-if it hit the shield generator itself), but not effective against projectile weapons like cannons and missile launchers.



Fire

Version 0.11.4 added a feature where reactors and some other modules would cause collateral area-of-effect damage when destroyed. 0.12.0 extends this feature such that these modules also often start fires on the ship when they are destroyed. Additionally, cannons can also cause fires when their super-heated ammunition rounds are able to penetrate inside enemy ships.



Once a fire starts, it will continue burning until the module that is on fire is destroyed or the fire is put out. While crew can still walk through fiery areas, they do so much slower than normal and, worse yet, have a chance of being killed.

If a fire is not put out quickly, it is likely to spread to neighboring rooms. Fire spreads through open interior spaces and doors, but it cannot spread through walls or armor, or over exterior structure. Because fire will spread through doors but not walls, it may not be such a hot idea (pun intended) to put doors everywhere you can, because you will be helping fires spread faster.

In order for your crew to put out a fire, your ship must have a Fire Extinguisher, preferably one close by to the fire.



Your crew will automatically go pick up a fire extinguisher, bring it to the fire, and use it to put out the fire. Fire extinguishers only have limited use, so it can help to have several fire extinguishers handy to put out big fires.




Conveyor Belt

A Conveyor Belt is a transportation system that helps crew move around large ships more rapidly. The conveyor belt moves only in one direction, and as long as a crewmember walks in the same direction as the conveyor belt, they will move 50% faster than normal. But if the crewmember walks in any other direction, they will go at only 1/4 their normal speed.



Because a conveyor belt only helps movement in one particular direction, it is not generally advisable to put them in 1-wide corridors, because any crew returning down the corridor will be slowed down to 1/4 speed, as well as impeding the speed of everyone else trying to go the "correct" direction. Conveyor belts are however often great for ships that are large enough for double-wide corridors, so that one side can travel in one direction and the other side can travel in the opposite. Crew are generally pretty smart about pathfinding and will almost always use the correct side of a double-wide corridor.

Because crew are pretty smart about picking the fastest path to get from point A to point B, you can also use corridors as a form of "indirect control", influencing the paths that crew will choose to take to and from their destinations.

Aesthetic Armor Pieces

For the past six months or so, Cosmoteer has had a little 1x1 triangular half-sized armor piece. Since it's half the size of regular armor, it doesn't have great protective value, but it's nice when, for aesthetic reasons, you want to make a ship with semi-rounded corners or diagonal edges. Version 0.12.0 adds several new shapes of armor to give even more aesthetic variety to ship shapes:



The first of these is an even-smaller quarter-sized triangular armor piece that's useful for adding details or for when you want a pointy tip on the front of an odd-width symmetrical ship.

The other two are both 1x2 triangular armor pieces (which are mirrors of each other) that are useful for making gentler or sharper slopes than the 1x1 triangular armor. There's two of them because, unlike the 1x1 triangle, there's no way to rotate a 1x2 triangle so that it looks "flipped" either horizontally or vertically.

Mirror Mode

For a long time, players have been asking for an easier way to create symmetrical ships, generally a "Mirror Mode" that would cause any changes on one side of the ship to be reflected on the other side as well. I'd been somewhat resistant to this idea, simply because the game already had a "copy & paste" feature that supported mirroring when pasting. However, watching videos of the game Navalia, which does have a mirror mode, convinced me that it was a feature worth spending a couple days to make work. And so 0.12.0 adds a mirror mode to Cosmoteer's ship designer, which works with all ship construction tools (including copy & paste!) and is available in both the floorplan designer and the exterior painter.




Mods

Lastly, I want to mention that Cosmoteer now has official support for "mod packages". This isn't actually a new feature of 0.12.0 (it was launched in 0.11.7), but I haven't talked about it yet.

Cosmoteer stores all of its game data inside easy-to-edit text files in its "Data" folder. These text files allow almost all game rules to be tweaked and for new ship modules and weapons to be added. However, until mods were introduced, player-created additions to the game required destructively editing the files in the Data folder. This made it hard to install (and uninstall) mods, and any game updates would erase any changes made by mods.

The "mod packages" introduced in 0.11.7 solved both of these problems. Mod packages are self-contained folders that contain special code to "edit" the base text files in-memory after the game is loaded without actually modifying the files on-disc. Since each mod has its own folder, and the text files in the base game aren't ever actually modified, it's very easy to install and uninstall mods.

Cosmoteer even has its own "Mods Manager" for installing and uninstalling mods and turning them on and off:

[Walt Destler]

Given the lack of updates for the past couple of months, you'd be forgiven for thinking that I had stopped working on Cosmoteer. Thankfully, you could not be more mistaken!

I've actually been working on one of the biggest new features in the history of Cosmoteer: Multiplayer!

Those of you who have been following Cosmoteer for a really long time probably know that the original prototype versions had support for multiplayer in which players could design ships and battle them with their friends. But I realized that having to support multiplayer was dramatically slowing down the development of Cosmoteer, including development of singleplayer-only features. And so I removed multiplayer support from the game's code, hoping (but not expecting) that one day I would be able to bring it back.

Well, that day has arrived! I am incredibly proud and excited to announce that multiplayer is returning to Cosmoteer!

In this first version, multiplayer is a simple team-versus-team battle of up to 8 players spread across two teams. Each team has a certain amount of money (configured by the host) to spend on a fleet of up to 5 ships per player (or fewer, as configured by the host). Then the game starts and the players control their own ships, attempting to destroy the other team's fleet. The game ends and one team is declared the winner when either the other team's fleet is sufficiently destroyed or the timer runs out.



You can play with anyone on the same LAN (Local Area Network) as you, and you can also play with a friend anywhere else in the world by typing in the host computer's I.P. address. (There is not yet a public online list of games, but I hope to add that soon.)



This is just the beginning! This first version lays the coding foundation for more improvements to come. In the long term, I may add entirely different game modes, such as multiplayer co-op and creative modes. In the near future, I plan to add:

• A.I. players in multiplayer battles
• Observers (for streaming tournaments)
• More than two teams & free-for-all battles
• Some sort of boundary around the playing area to prevent people from being able to run away indefinitely
• Limit price per-ship and not just total price per fleet

There's lots more details and plenty of other fixes and improvements in the full changelog.

Technical Implementation

You may be wondering why I've chosen to bring back multiplayer given the fact that I originally removed it because it was slowing down development too much. Wouldn't bringing back multiplayer cause all future development to become a lot slower?

Thankfully, the answer to that is mostly "no", and the reason for that is that I've taken an entirely different approach to implementing the multiplayer code.

The original implementation of the multiplayer code required that every single change in the state of the game (such as a ship firing a weapon, a ship moving a millimeter, a crew person walking a foot, or a bullet hitting an enemy) be synchronized among all players by sending packets over the internet. This was a huge problem for two very important reasons:

• In a game as complex as Cosmoteer with potentially dozens of ships and thousands of crew, that's a potentially huge amount data that needs to be transferred over the internet between all the players. We're talking megabytes per second of data for a large battle, which made the game really only playable on LAN or very-high-speed internet connections.
• The code for anything that could affect gameplay even in the slightest became way more complicated due to the need to send those aforementioned internet packets. For example, if I wanted a bullet to inflict 1000 damage on an enemy ship, I couldn't just call the TakeDamage(1000) function; I first had to construct a network packet with all the needed information and send it to all other players. This made working on gameplay code far more time-consuming that it would've been without having to send all those packets.

The new multiplayer code uses an entirely different approach that's called "deterministic lockstep". Essentially, this approach requires that two computers running the same version of the game with the same initial battle setup and same player inputs will simulate the game in exactly the same way. (Not even off by a millimeter, or else the butterfly effect will cause bigger and bigger errors until the game desyncs.) There are two big advantages to using deterministic lockstep:

• Only player inputs (commands issued to the ship) need to be turned into packets and sent over the internet. Everything else (physics, weapons, damage, etc...) will happen exactly the same way on every computer by virtue of them running completely deterministic game simulations. This saves massively on bandwidth, so much so that Cosmoteer now only uses a few KB of bandwidth per second.
• Code that affects gameplay no longer needs to be synchronized using packets sent over the internet, so long as the gameplay code can be written to be 100% deterministic. Writing deterministic gameplay code isn't very hard as long as you know what kinds of things to avoid (primarily code whose outcome could change based on framerate).

There are, however, some important disadvantages to using deterministic lockstep:

• The gameplay really does have to be 100% deterministic. 99% deterministic is not good enough. And non-determinism bugs can be very tricky to track down. I have written myself some pretty nice tools for debugging determinism issues, but it still took me several weeks to comb through the whole Cosmoteer codebase and convert everything to be deterministic.
• Games that use deterministic lockstep typically have more latency than other types of games. You may notice that when playing multiplayer Cosmoteer (and most RTS games) that there's a small delay after assigning a ship an order and before you see it actually respond. That's because it has to wait for the other computers to receive the order before it can process it. In action games like first-person-shooters, this would be a huge problem, but in slower games like Cosmoteer, it's not a big issue.
• Differences in how different CPUs compute floating-point (fractional) numbers can cause an otherwise 100% deterministic simulation to become only 99% deterministic, which due to the butterfly effect will ultimately lead to desyncs. In practice, this means that players running on 64-bit operating systems can't play with players on 32-bit operating systems. (Although there is a mode to force the game into 32-bits so that friends on different operating systems can play with each other.)

While these downsides are significant, none of them are deal-breaking, and are certainly preferable than the problems caused by the original way I implemented the multiplayer code.

All in all, getting multiplayer working again was a pretty huge undertaking -- one that I wasn't even sure I could pull off -- but in the end I think it has proven to be well worth it. And I'm looking forward to playing a ton of Cosmoteer multiplayer as a result!

[zenassembly]

Wow! Nice breakdown of deterministic programming. Multiplayer seems like a natural fit for this game, congrats! 

[Pineapple]

Oh no, I'm going to get sucked into this again aren't I...

A co-op mode would make me extremely happy.