New Shipyard: Big improvements to the ship editor

by Jonah on July 2, 2018

As the first part of the game I created way back in 2013, the ship editor was easily the most naively designed and coded section of the game. My planned redesign of the interface in the never-completed Alpha 1.0 version addressed some of the problems, but the fix was only surface deep. Underneath the new coat of paint, the method of storing and rendering ship designs was still basically unchanged, bringing numerous problems with it. The problems are pretty technical but the extremely simple version is that in the old game, individual systems had no way to store their own variables; everything except their location was defined by the system type. When I later moved on from this concept, I had to come up with awkward, hacky ways to make new ideas work within my own old code. One example of this was “free form” systems, which were really just a blob of separate 1×1-tile systems which changed their sprites to appear connected. Another example is the decorative slope pieces, which were all essentially the same thing with different sprites, but there was no way to store a “direction” variable so each one had to be a completely separate system type.

Working on the new Shipyard, I’ve learned from those old mistakes and designed the ship editor to allow for individual systems to store their own data and determine their own stats instead of all being exact copies of a master template. For example, it’s now possible to have true variable-size systems, which can be a rectangle of any size and are still treated as a single system by the game. This is possible because they can each store their own size variables, independent of each other. You place them by drawing a box the way you would use the rectangle tool in MS Paint.
Similarly, systems like the decorative slopes which have the same stats but different visual styles can now be combined into a single system type with an individual direction variable. In this screenshot, there are only two different system types (1×1 and 1×2 slopes), each with four possible styles that can be cycled with the scroll wheel similar to how weapon directions worked in the old game:

Shipyard Remake: Friendship ended with Java, now C++ is my best friend

by Jonah on June 30, 2018

When I started the original Shipyard, I only knew how to program in Java, a language which makes it very easy to slap together something basically functional but not particularly efficient. This was only exacerbated by my lack of experience. To pick one of many examples, the game’s graphics were done entirely with Java’s built-in graphics and user interface library. This relies entirely on “software rendering,” or performing graphics calculations on the CPU instead of the graphics card, which means the CPU has to do two jobs while the graphics card sits idle, its potential wasted. I didn’t understand this at the time, naively assuming that the computer “just knew” what part of the code did the graphics and assigned it to the graphics card. This poor use of resources limited how many objects could be on screen at once and how complicated they could be. The big-pixel retro style, originally a stylistic choice, increasingly became necessary to cut down on complexity and get a smooth frame rate.

The new game will be written in C++ instead of Java, using a free library called SFML (the same one I used to make that 2D tank game for school back in the day) to handle the graphics. SFML uses the computer’s hardware more efficiently allowing it to draw much more complex graphics and still run more smoothly than the old game. Here’s just one example, using a shader (a small program that runs on the graphics card) to simulate lighting on a shape in real time, regardless of what direction it’s facing:

On the top left is the base color, or what the shape would look like if it was perfectly lit from every angle. Right of that is the “normal map,” which tells the shader what direction each pixel is facing by representing X, Y, and Z coordinates with the red, green, and blue channels of a color. On the bottom is the final product, which as you can see stays lit from the top even as it rotates continuously.

In this picture I’m using a more complicated shader to do several things which had to be done manually in the old Shipyard:

Determining the silhouette of the exterior based on the interior plan of the ship
Creating the “bevel” effect on the systems that don’t have an exterior design
Applying lighting to the ship to make it look three-dimensional
Drawing a black outline around the whole thing

What this means for you, the player, is that instead of having to manually place both the interior systems and exterior tiles, all you do is place the systems and the game automatically creates the exterior from that. Of course, this does limit your creative freedom over the style of the exterior, but I have some plans to remedy that which I’ll discuss in future posts.

What Happened to Shipyard?

by Jonah on May 20, 2018

You may have noticed that this website hasn’t been awfully active lately, with only one off-topic post in 2017 and none this year. There are many reasons for this, not the least of which being poor overall mental health sapping my motivation to take care of myself at a basic level, let alone develop video games. I have, occasionally, still had intermittent bursts of inspiration to work on things, including a full 3D shipbuilding game in Unreal Engine 4, which you can check out on my gamedev.net profile. But what about Shipyard? As I remember, I had hoped to release one last, glorious update before officially putting the game on hold, but even that never happened and the last actual patch was more than three years ago.

The thing is, when I started Shipyard, my only programming experience was Minecraft modding. I was entirely self-taught and had an attitude of “if it works, it’s good enough,” with no regard for things like optimization and good code style. A couple times during my absence, I did have ideas for new directions to take the game. However, the old code is such a disgusting mess of bad design that adding anything new would require rewriting huge sections of it. The more ambitious the change, the more old code would have to be demolished and rewritten to allow for it. It would almost be easier to make a whole new game…

I still wanted to finish Shipyard, but I was never going to get anywhere with the mess that was the old version. Instead, I’ve decided to scrap it entirely and start with a clean slate. This way, I can incorporate all my current programming skills and make the best game I can, unhindered by old mistakes. The project is currently less than two weeks old so I don’t have anything cool to show off, but I’ll (hopefully) post more as I make some actual progress. The one thing I can tell you right now, at least, is that it won’t be made in f***ing Java.

Blog? Building a USB ship’s wheel controller (Part 1)

by Jonah on May 31, 2017

Several months ago I had the idea to build a ship’s wheel controller for playing games like World of Warships. They make racing wheels for car games and flight sticks for plane games, so I thought it would be fun to build a ship’s wheel and engine order telegraph that I could plug into my computer for playing ship games. I started picking out parts, but didn’t have nearly enough money for them so the idea was shelved. A few weeks ago was my birthday, and among other things I got a bit of money to spend on whatever I felt like. I remembered this idea and decided to put serious effort into it.

(Yeah, it’s not actual game development, but it’s game related so it made more sense to post this here than on my other website. Sue me.)

Basic Design

I decided the controller’s functionality would be divided into three main units:

The main wheel, which would sit on the desk directly in front of me. This would control the steering of the ship.
The engine order telegraph, which would be on a stand off to my left. This would control the speed of the ship.
A console with a joystick and a number of buttons and switches for aiming, firing, and activating abilities. This would also be the “brain box” which receives input from the other units and connects the entire setup to the computer. This was originally going to be free-standing to my right, but since aiming is an intensive task and my left hand won’t be in use most of the time, I decided to sacrifice a little bit of realism and have the thing sit on my lap, in front of the wheel.

Once I knew vaguely what I was doing, it was time to start ordering parts.

Picking Parts

The first round of parts (everything that came from Sparkfun) neatly “knolled” in the style of Adam Savage

The Main Wheel

Despite being the centerpiece of the build, this part isn’t especially complicated. It just had to spin and measure the rotation around that one axis. The most challenging part was finding a way to allow it to spin continuously in either direction. Most regular potentiometers (input knobs, like you might use to adjust stereo volume) can’t even go a full 360 degrees, let alone continue spinning indefinitely. This isn’t strictly necessary from a gameplay standpoint, but I like the idea of flinging the wheel wildly while bellowing “HARD TO STARBOARD!” and just letting it spin, so I wanted to find another solution. While perusing the catalog of Sparkfun (whom I heartily recommend if you’re thinking of doing this kind of project) I stumbled upon something called a “rotary encoder” which fit the bill: it was a device for measuring angles that allowed for continuous movement. Plus, it was larger and beefier than your typical dinky input knob. I ended up buying a cheaper version from a supplier on Amazon, but the principle remained the same.

The rotary encoder is the big round thing that looks like a motor

I’m alright with circuits, but a woodworker I am not, so I went and ordered a pre-made novelty ship’s wheel off Amazon. The sellers are very adamant it’s for decoration only, judging by their answer to another Amazon user who asked if it could be used on an actual boat. However, it has a perfectly good round hole in the center, and I figured it wouldn’t be too hard to shove a wooden dowel in there and drill a smaller hole to fit the shaft leading to the encoder. It’s supposed to arrive tomorrow as of this writing.

The Engine Order Telegraph

This was the simplest part by far, at least in terms of electronics. It didn’t have to rotate continuously and would be under a lot less physical stress than the main wheel, so a simple rotary potentiometer would work just fine. I’ll have to fashion a lever to fit the shaft instead of a regular knob, but I’ll get to that in a future post.

The Console

This is the most complicated part, not just because it’s the brains of the entire setup but because of the sheer number of inputs it would need to handle. I was already familiar with Arduino microcontrollers (tiny computers for controlling robots, sensors, etc.) so I decided to build my system around one of those. There are many different Arduino boards, some official and some third-party (of which some third-parties are more reputable than others). The one I settled on was Sparkfun’s own Arduino Pro Micro, which had all the features I needed, like built-in keyboard and mouse emulation and generally being, well, micro.

The next important part was the joystick. I wanted something pretty big and beefy, not one of the dinky thumb-pads found on most ordinary controllers. Ideally it would also be analog, allowing for more precise control than just “on” or “off.” Unfortunately I couldn’t have both, as the only joysticks that were big enough and analog were found on industrial wholesale sites that were probably geared for large-volume sales. Ultimately I went with a claw-machine joystick from Sparkfun because it satisfied the first requirement, plus it could be bundled into the same shipment as most of my other parts instead of having to pay separately.

I also bought a whole pile of little buttons to be used for various things such as selecting armaments and activating abilities. These were cheap and simple; the real challenge was finding a way to read 8-10 buttons, plus the 5 outputs from the joystick, on an Arduino board that has a limited number of I/O pins. Once again, my friends at Sparkfun (I swear I’m not paid to say this. I mean, c’mon, maybe 3 people will ever read this post) had the solution in the form of a multiplexer circuit, essentially a way to turn 5 wires into 16 using 4-bit binary to select a line and a fifth line to read it. The only restriction was I couldn’t use more than one at the same time, but that wasn’t an issue in my case.

Testing the Pro Micro and multiplexer with some LEDs. My phone auto-generated this GIF which is why it doesn’t loop perfectly.

Other Stuff

I needed a way to connect the inputs on the console to the outputs on the two other units, so I found some handy 6-pin connectors and some 6-wire cable to go with them. The cable turned out to be solid-core (one piece of wire) rather than stranded (several smaller wires twisted up together), which made it stiffer than I’d hoped and a real pain to work with. I’d have bought some different cable but by the time I discovered this I was out of money and eager to start the project. I also picked up a wall socket power supply, because I was worried that the small amount of power that comes out of a USB port might not cut it.

Bonus picture: Tank [top] and Katyusha [bottom] love this big piece of green paper that came in the first box of parts

I forgot to tell you I worked on another game too!

by Jonah on September 12, 2016

About half a year ago my friend Shayne and I made a text adventure game for a game design class we were both taking. It’s actually been available to play on at brasswatchgames.com/disorient-express/ for most of that time but I never remembered to mention it or make a page for it… until now!

Click here to play!

Also check out Shayne’s website, he’s been doing this for one year less than me and already has four finished games (including this). Plus he was quite the successful Minecraft mapmaker back in the day.

Shipyard is now on itch.io!

by Jonah on June 5, 2016

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.

Shipyard Development News 4 May 2016: Weapon Changes v1 and Rebindable Keys

by Jonah on May 4, 2016

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.

Shipyard Development News 4 April 2016 — Back From the Dead Edition

by Jonah on April 7, 2016

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.

Shipyard Development News 5 September 2015

by Jonah on September 5, 2015

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.

Shifting Focus

by Jonah on August 26, 2015

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.