Shipyard is now available to download on itch.io as well as this site! This isn’t an update, just an alternate way to acquire the game. You also have the option of adding a payment for the game. This is 100% optional but it motivates me to continue developing the game and helps me pay for college and power metal albums.
Bit of a short news today, just wanted to post something so it didn’t look like I’d vanished from the Earth once again.
The basics of the weapon changes are now working: all systems have a (currently hard-coded) armor value which affects the damage they take from different weapon types. Kinetic weapons work with an all-or-nothing system, energy weapons divide their damage by the armor value, and explosive weapons deal damage to an area but damage is divided by the square of the armor value. Right now with kinetic and energy weapons, attacking free-form systems is still inefficient as leftover damage is not distributed to neighbors, however I plan to change this before releasing the update (which is still a long way off).
Also, I’ve begun to implement the ability to rebind keys. At the moment, only movement (WASD), wait (Space), and the navigation screen hotbar are rebindable and there’s no built-in system to change them (you have to look up the codes and edit a text file). Once again, though, I plan to change this before the update is finished.
It’s been a long time. Like, a really long time. Like more than half a year. Yeah… Sorry about that. I can’t even say I’ve been especially active either. Between starting my first year at university and various other real-life engagements, as well as a general lack of inspiration, development of Shipyard has been at a complete standstill for most of that time. However, I’m finally climbing back on the wagon with the intention of finishing alpha 1.0 before putting the game officially on hold to work on smaller, more manageable projects.
Since I’ve been inactive, I’ve been playing a lot of games. In what can be very loosely described as research, two in particular–World of Warships and From the Depths–have grabbed my attention and given me some fresh ideas that got me interested in working on Shipyard game again. Specifically, they’ve given me idea regarding how to deal with weapons now that the majority of systems are free-form.
Armor and Weapon Type Changes
Right now, a system’s only defense is its hit points, which has a number of negative effects on gameplay. Since the beginning it has been possible, and indeed optimal, to focus fire on an enemy ship’s rectors to quickly disable all of its defenses. This is a cheap tactic that requires little in the way of skill and, once you figure it out, makes the game significantly less enjoyable. Additionally, since free-form systems are really just 1×1 systems with very little HP under the hood, weapons that deal a lot of damage in a single shot are wasted on them. I’m planning sweeping changes to address these problems.
The first of these changes: armor. In addition to hit points, which represent the integrity of the functional parts inside a system, systems will also have an “armor” stat representing the thickness of solid metal protecting the outside. At first, each system will have a hard-coded armor value, but eventually I plan to allow the player to control the armor thickness over different parts of the ship. At the moment, reactors and engines have the most armor because they are the most important systems to protect. Each weapon type will behave differently when confronted with higher armor values:
- Ballistic weapons, which are being renamed to kinetic weapons, will have an “armor penetration” value, and will work on an all-or-nothing basis. If the weapon has enough penetration to punch through the enemy’s armor, it will do its maximum damage to the system. If not, it will do zero damage.
- Explosive weapons’ damage will be spread out over multiple tiles regardless of the target’s hit points. However, its damage will drop sharply with higher armor values–perhaps even being divided by the square of the target’s armor. This means that they are only effective against lightly-armored parts of the enemy ship.
- Energy weapons will target a single tile like kinetic weapons, but rather than the all-or nothing system, their damage will be merely reduced by armor rather than negated entirely. The reduction will not be nearly as sharp as with explosive weapons, though. Whereas explosive damage is divided by the square of the armor value, energy damage will scale linearly.
It’s hard to remember even where I left off; I’ve had to go back and read my old posts to remind myself what I was doing all those months ago. Hopefully, though, I manage to stick with it and get the update out in a reasonable time. No promises, but for the moment anyway I’m feeling pretty inspired.
It’s been a while since I posted a true development news–more than two months in fact–and it’s time to rectify that!
Internal System Map
One of the most important changes in the new update is also one of the most boring to explain. In the current version, a ship’s systems are stored in a one-dimensional list. If the game needs to find the system at a particular tile (in two dimensions), it needs to go one-by-one down the list and check each system to see if the tile is within its boundaries. This worked fine when systems were large and few, but now that there are potentially hundreds of tiny free-form systems, there is a much longer list to go through. I found that this caused the game to lag, especially when painting a large area.
The system map fixes this problem. What is the system map? I’m glad you asked! The system map is a two-dimensional grid corresponding to the tiles in your ship, with each tile containing the ID number of the system which occupies it (or -1 if it is empty). When you place a system, the map is automatically updated with its ID number in every tile that it covers. This way, the game only needs to check the map to find the ID number of the correct system, and can then jump directly to its position in the list. This cuts out a lot of unnecessary operations, and thus significantly reduces lag.
New Ship Editor
Part of the reason I mentioned the system map is that it enables an important feature of the new ship editor: continuous painting. In the current version, placing multiple systems requires repeatedly clicking. Again, this wasn’t a major problem with large, fixed-size systems but it quickly becomes infuriating with free-form ones. The new ship editor allows you to paint continuously by holding down the mouse button. “But that’s so obvious!” you say. “Why didn’t you do that already?” The main reason was to do with the system-list lag mentioned above. Because each system needs to check that every tile within its boundaries is empty before being placed, it used to require that laggy one-by-one list checking. As I discovered when I first implemented it, this made the paint function painfully clunky. Now, thanks to the system map, the check can be done fast enough to make painting as convenient as it was intended to be.
Oh, right, I haven’t actually posted a screenshot yet. Let me fix that:
You’ll note a few things about the new editor:
- The construction area takes up the entire screen, with the tools being small objects on top of it. No more tiny viewport limiting your view to a ninth the size of the construction area.
- Hotbar to quickly switch between tools as well as interior/exterior views.
- Systems list is large enough to show the full name of the systems, and has them organized alphabetically.
That’s all for now! I’ll keep working though so I have more to show before another two months has passed.
This isn’t a regular development news so much as a general rambling on my efforts as a game developer. I don’t expect everyone to read every word, so the important parts will be written in bold.
Shipyard was released as a “tech demo” exactly two years ago today. Since then, its development has been a slow, meandering journey wherein I think up new features that would be cool to have, and pile them on haphazardly. I’ve often taken long breaks from development because I wasn’t inspired around any particular feature at the time, and equally often I’ve tried to implement awesome-sounding features before the game is ready for them (cough shuttles cough).
A couple days ago, I was discussing game design with my good friend and fellow game developer Shayne Hayes (www.shaynehayes.net). Even though I’ve been doing this for longer by a couple years, he already has two complete games to my zero, and during that discussion I realized why. When he started his games, he started out with a clear idea of what he wanted those games to be, and all he had to do was implement it. On the other hand, when I started Shipyard, I set out with a grand vision but no concrete plan. As a result, I ended up bumbling around, making stuff up as I went along. If game development were a road trip, then my friend started out with a map and a list of directions, so all he had to do was drive from point A to point B. I, meanwhile, set off with nothing but a sense of adventure, and ended up driving in circles. It’s become clear to me now that this style of development is not going to work if I want to get anywhere as a game developer, and I’ve decided to make some big changes.
After Alpha 1.0, Shipyard is going on indefinite hiatus.
I still have every intention of finishing Shipyard, but after the next big update, I’m going to shelve it until I have a clear plan regarding what I want it to be, and how I’m going to get there. When I finally return to it, development should be much quicker because I’ll have a concrete goal to work towards. I’ll know what I want from the game, I’ll know what I don’t want from the game, and it will just be a matter of making it happen.
In the meantime, I’m shifting focus to smaller, simpler projects.
When I first started Shipyard, I was a novice programmer, and it was that skill that was the bottleneck in development. Now, my coding talent is much more mature, and it’s the lack of design focus that’s holding me back. So, while I take the time to decide what I want from Shipyard, my efforts will be shifted to smaller games–games that I can design, program, and release in a matter of months rather than years. That way, I can build a repertoire of finished projects to show for all my years of development.
I’m going to start selling games.
No true artist wants to charge for their work. In a perfect world, basic needs would be taken care of and we could all do what we love because we love it, and nobody would need to charge for anything. However, this world is far from perfect. I’m starting college in less than a month, and here in America that isn’t cheap. Plus, I can’t mooch off my parents forever. Even if I could in the practical sense, I don’t want to become the stereotypical nerd who lives in his mom’s basement until he’s forty. As stated on my “About” page, it was always my intention of making games as a career, not just a hobby, and I hope to move Brass Watch Games in that direction over the course of the next year. If memory serves, I promised that Shipyard would always be free, and I plan to uphold that. However, any new developments in the foreseeable future will be released for profit.
That’s it for now, folks. I hope you understand the reasoning behind my decisions, and I’m excited to see what the future holds for me as a game developer.
Since I started BWG, I’ve been posting development videos to my personal YouTube account, where they get mixed in with all the Minecraft mods and random other crap that I post. However, I’ve finally decided to do the professional thing and make a separate, “official” channel for all BWG-related videos. There’s nothing on it yet, but I’ve been considering starting up a weekly development news video series. If that happens, it would likely replace the “whenever I feel like it” development blogs I have going right now, although I may post a text summary or additional “footnotes” here to accompany the videos. As usual, nothing is set in stone just yet, but thus far I’m liking the idea.
I’ve been doing a lot of work on Shipyard over the past few days, and although Alpha 1.0 is still a long way away, I’m making progress much faster than I expected.
First and foremost, I now have free-form versions of weapon controls, crew’s quarters, and cargo bays implemented. In the case of weapon controls, it’s still very clunky because I haven’t done anything about the crew and power interface yet. However, the visual aspect is in and working even better than expected. You can see all of the new free-form systems in this screenshot:
Second, even though it wasn’t on my official outline, I’ve begun the process of adding a greater variety of systems and weapons to play around with, including the first class 3 ship parts. I started, or course, with the class 3 bridge. At 6×6 tiles, 3000 credits, 8 mass, and a crew and power requirement of 11 and 12 respectively, it’s quite a hefty system. However, the advantage is that you can use the full 48×48 build space as well as any of the new class 3 parts currently in development.
As for weapons, I’ve been adding new weapons as well as going back and redesigning old ones. I’ve completed the gauss cannon set, with new textures for the existing small and medium variants, plus new large and “mega” versions. The mega version is 8 by 8 tiles in size, require 16 weapon control to fire, and deals 240 damage per shot. As such, it takes the crown of highest single-shot damage from the Railgun.
Additionally, I’ve added a turreted torpedo launcher. It does the same damage as the regular one, only it has a turret. In exchange, it has a higher complexity rating and it physically larger (5×5 as opposed to 3×3). It looks like this:
I’ve been spending a lot of time building ships with these new parts, but I’m quickly realizing the limitations of the current build screen. As such, the new ship-building screen is going to be high on my priority list over the next few days. I’ll also be expanding and revising the plasma cannon family, as well as adding some new weapons. One thing I’ve been considering is a set of non-turreted ballistic weapons which are smaller and less complex, in exchange for losing the turret. Far-future ships-of-the-line, anyone?
Okay, I’ll admit that I didn’t get straight to coding after I posted my outline for Alpha 1.0. That’s because, at the time, it was nearing the end of the school year and teachers were doing their very best to cram as much busywork as they could possibly into that last month and a half. Now, however, the school year is over, and I’ve got no shortage of free time–some of which has been spent working on Shipyard.
If you read–or even skimmed–my rambling, essay-length outline, you’ll know there’s a lot to get done before Shipyard is ready to go into alpha. So, I figured I’d start at the top with free-form systems. Before I wrote the first line of code, it took a lot of thinking and scratch work to figure out how I was going to implement it. I’ll spare you the details, but suffice it to say it took a several sketches in Paint.net and a considerable amount of math to nail down. Once that was done, I was ready to start coding. The first system to get the free-form makeover was the humble corridor. While not the most exciting system in the game, it is the simplest, which made it a good starting point to get the concept locked in.
Here’s a short video demonstration of the new free-form corridors:
So how do free-form systems work? Well, I’m glad you asked! Behind the scenes, free-form systems are actually discrete 1-by-1 systems, which change only in appearance when placed next to neighbors of the same type. This is especially easy for corridors, which have no stats, no hitpoints, and no crew or power requirement.
But what about systems that do have a crew and power requirement? Nobody wants to individually allocate one crew member or power unit to thirty separate tiles of the same system! The solution: tie crew and power to types of systems rather than individual tiles. Once implemented, this means you only have to allocate crew to weapons, engines, etc. in general, and the game will handle the rest.
Well, that’s it for today! Check back soon, because I plan to be doing a lot of work on the game this summer.
Now that I’ve fixed my server troubles (or, at the very least, delayed the inevitable), I can get back to work on proper, content-adding updates for Shipyard. I’ve been giving it some thought, and I feel like it’s ready to proceed from the “pre-alpha” stage into the “alpha” stage. In a tradition that I started with version 0.8.1, this post will serve as a general plan for the new features and content coming in Alpha 1.0. As always with these early plans, anything written here is subject to change.
WARNING: Wall of text inbound!
Free-Form Systems (And Related Changes)
Currently, all types of ship systems come in fixed sizes. This limits the amount of creativity you can have when building ships, for no real logical reason. Thus, for Alpha 1.0, many systems will be changed from fixed sizes to being free-form. Adjacent tiles of the same system will automatically merge into a single system. Stats will be calculated by some base value times the number of contiguous tiles. Crew’s quarters and weapon controls will definitely be changed to this mechanic. Bridges and engines will definitely remain fixed. Other types may or may not be changed to free-form depending on how the implementation takes shape. Cargo bays and corridors are already essentially free-form, and all they need are new textures. In order to make this work, however, some major changes will need to be made to several game mechanics.
Although I could, with the current system, simply make a 1×1 version of the weapon controls system, crew and power management would be a nightmare. You would have to manually allocate a single crew member to each individual tile. With the new free-form mode, crew will not be allocated to individual systems but rather types of systems (weapon controls, engines, etc.). In Alpha 1.0, crew assigned to a system will be considered to be “working” the system, meaning they are actually operating it rather than repairing it. Free crew will automatically repair all damaged systems evenly, and will not contribute to the effectiveness of the system. You will also be able to tell your free crew to “focus” on a particular system type if you want it repaired at a higher priority. There will be a cap on the maximum rate of crew repairs to prevent players from spamming crew’s quarters for invincibility.
Hitpoints and Weapon Damage
Another problem with simply having separate 1×1 systems is damage. Damage to a system when it already has 0 HP is wasted, and with small systems, weapons like the railgun would be a pointless waste of weapon control points. In the new system, damage will be dealt to individual tiles rather than whole connected systems, and extra damage will be spread out to adjacent tiles. The HP of a system type will be based on the combined HP of the individual tiles that comprise it. Crew damage will work similarly, with the total being calculated by some sort of population density formula. I don’t want to go into too much detail, but in general, more weapon base damage still means more crew damage.
Overhauled Ship Editor
The ship editor was literally the first part of Shipyard I developed, way back in summer of 2013. Back then, you couldn’t even save and load your designs, never mind actually build and use them in the game world. Despite the progress the game has made since then, the ship editor has remained largely unchanged aside from adding a few extra buttons. In my own personal experience playing the game, I have started to find it clunky and annoying to use. Now, I think we can all agree that if the developer finds their own game tedious to play, some changes are in order.
Problems with the Current System
- The viewport, at 16×16 tiles, is very small and annoying to work with when designing large ships.
- The system and weapon lists force you to hover over each item to see what it does, since they don’t show any stats. They’re also incredibly disorganized, listing things in the order they were added to the game rather than by any sensible system such as alphabetical by name, by minimum ship class, by stats provided, and so on.
- The exterior editor requires you to click on each tile you want to change, when quite often you want to cover a large area all at once.
- The stat panel to the right isn’t very useful. It’s just a big pile of numbers that eat up screen space but don’t have much relevance to gameplay.
- The save/load/build/etc. menu buttons also take up a lot of screen space. Surely they don’t need to be visible 100% of the time, considering how infrequently they’re used.
- The interior, exterior, and weapons view buttons are similarly much larger than they need to be.
- This only really affects me, but behind the scenes, the ship editor is coded like… well… like I coded it a year and a half ago. I’ve improved greatly as a programmer since then, but the ship editor remains an inefficient fossil of my less-experienced self.
Changes for Alpha 1.0
- The building grid will take up the majority of screen space, with other components being arranged to maximize the use of space.
- System and weapon lists will be organized to show items in some meaningful order. They might even allow you to change the order, similar to the way you can sort files in Windows Explorer.
- The exterior view will allow you to “paint” tiles by clicking and dragging, allowing you to edit large areas without giving yourself carpal tunnel syndrome.
- Stats will be moved to a separate tab alongside interior, exterior, and weapons. They will also be changed to be more relevant to the game in its current form.
- The save/load/build/etc. menu will be changed to a window that can be opened when you need it and closed when you don’t.
- The buttons to change between the interior, exterior, weapons, and now stats screens will be changed to a tabbed menu like the one in the ship overview window of the navigation screen.
- Everything will be rewritten from the ground up to be more efficient behind the scenes.
I mentioned in my outline for the last update that officers might be coming in 0.8.1. However, with all the problems with implementing shuttles eating my time, I never even got started on them. Now, I’ve decided to make them a possible feature of version Alpha 1.0. Officers are characters that act a bit like upgrade items, but with a few key differences.
- You can hire as many officers as you have Officer’s Quarters systems, similar to shuttle bays.
- Officers are people. People must be kept happy. Thus, if you want your officers to provide the best bonuses, you will need to keep them happy. Some might not take kindly to excessive violence. Sometimes two officers won’t get along with each other (for example, a pirate and an ex-space-cop). All of them, however, will need to be payed.
- The stat bonuses provided by officers will be generally better than those provided by upgrade items.
- Officers will be randomly generated, unlike items which are hard-coded.
- Officers will earn experience toward improving their stats, while items are fixed.
Shuttles for Real, Maybe
Shuttles didn’t make it into the last version due to unexpected troubles in their development. Finally, after five months, I decided to cut them from the update and release what features I had completed. With so many fresh, new features to work on for Alpha 1.0, I can’t promise they’ll make this update either. However, the progress I made is still there, just hidden, so anything’s possible.
Other Potential Features
Free-form systems and the new shipyard editor will be the main features of Alpha 1.0, but along with them I have some other ideas which I’ve been tossing around. These may or may not make it into the update depending on how much time they take.
- New items which are not available in stores, but instead must be crafted from scrap and other items. Because of the added difficulty of acquiring these items, they will be generally better than those easily purchasable in shops. One possible way to do this would be to have a “workshop” system, which would craft items faster the more crew and power were assigned to it.
- A second hotbar on the navigation screen, this time to the right of the HP gauge to make it symmetrical, to which items and shuttles can be assigned for quick access without having to go into the cargo hold and shuttle bay menus.
- Character skills for your character, making them essentially a free officer. This might involve some sort of skill tree and/or XP system–I haven’t thought too much about the finer details.
- Changes to the way the inventory system works, with each cargo bay storing one item as opposed to one kind or item.
- Changes to the way spaceship data is stored and saved to fix bugs like enemies spawning with less than full HP and reduce the size of ship data files.
- Sound effects. With the inclusion of Paul Lamb’s sound library, a solid framework for playing sound effects is already in place. All I need to do is add them.
- Exterior armor. This will allow you to make a system more resistant to damage, at the cost of increased weight (and therefore ship speed).
- Crew injury and medical bays. When a system is attacked, crew may be merely injured rather than killed. The medical bay will be a new system which can heal them after a certain number of turns.
First of all, congrats on making it this far through my wall of text. Unless, of course, you just scrolled down to the bottom. Don’t worry, I’d probably do the same. Either way, I’m excited to get to work on Alpha 1.0. As it will be a huge update with many changes, it will probably take a long time to complete. However, once released, the result will go a long way toward a finished game. I’ll keep posting here as I begin to implement the new features, but until then, happy building!
…dang that last bit sounded cheesy.
That’s right, folks! After five months, version 0.8.1a is finally ready to go! As always, it is available both as a full download and through the launcher. Despite the long wait time (which was at least partially my fault, as I’ll explain below), it is only a minor bugfix update to get rid of the crippling “negative crew” effect experienced by some players. Development of actual content updates will resume soon, and I already have some fresh new ideas for how to improve the game. Anyway, I feel I should explain what actually happened:
After several months, what was originally meant to be a “hotfix” is now a very, very cold fix. After doing a considerable amount of mucking around with FTP, it seems there is a sooper seecret limit on the file size that can be uploaded. When the music was added, I rather naively included in in full, uncompressed .wav format because it was the easiest to use from a coding standpoint.. However, this inflated the game size from a meager 790 kilobytes to over 100 megabytes. For those of you not familiar with nerd jargon, that’s almost 150 times larger. The limit just so happened to be large enough to allow me to upload one such file, but not two. While I can’t do anything about the storage limit, I can convert the music to a smaller file type. This will allow me to upload version 0.8.1a and subsequent versions. However, it isn’t entirely future proof, and there may come a time when the sooper seecret storage space quota comes back to bite us in the hind quarters once again. To help delay the inevitable, once version 0.8.1a is uploaded, version 0.8.1 will be deleted from the server. This shouldn’t be too much of an issue since 0.8.1’s bugginess is the reason for the new version to begin with.