About this blog
Journal of my game development as Brass Watch Games.
Entries in this blog
Just a mini-update this time, nothing too major. The biggest change is that in simulation mode the test cube will act as an engine, pushing the boat forward. In addition to this, there are a bunch of small changes made to the editor:
Machinery will appear in a translucent "preview" mode before being placed.
Scroll wheel now rotates machinery.
Machinery snaps to the horizontal grid by default, making it easier to line it up with the center of the ship. This can be toggled by pressing G.
Machinery will only be highlighted when you're looking at it instead of all the time (eventually, you'll click to select machinery and be able to change options for them, for example the caliber and barrel length of a cannon).
Right click deletes a surface or machine depending on which mode the editor is in.
Also I got a new video editing program so now I can fast forward through building the exact same boat again.
It's been more than five months since I started working on this update. I never intended it to go on this long, but trying to implement shuttles increased the development time drastically. Eventually, I decided to push shuttles back to another update and release the new version with the feature that are working. I'm not going to rewrite everything I've already said once, so if you want to read more about the update, you can see my blog post here.
To download the update go to the game's official page. You can either download the full game archive, the launcher which will automatically check for future updates.
NOTE: The increased file size of the new version caused problems with the old launcher, so I had to update that as well. If you get an error with the launcher saying "The files received from the server are corrupted," redownload the launcher and try again.
[color=rgb(51,51,51)][font=arial]I recently took a C++ class at community college. As part of the final exam, each student was to create a "sampler project" showcasing what they had learned. I play both World of Tanks and War Thunder, and have watched Girls und Panzer more times than I care to mention. You might say I have a passing interest in tanks. This project gave me the perfect excuse to do something with that interest. It's not much yet, but I have big plans for it. [/font][/color]
[color=rgb(51,51,51)][font=arial]You can read a little more about the project on my website. [/font][/color]
This is a project I started in Unreal Engine 4 a while back, got fed up with, dropped for a few months, and finally came back to. The project began in a Discord channel of a role-playing group for a game called From the Depths. FtD had some good ideas, but it's clunky, unrealistic, and not very well balanced. Our group in particular found it unsuitable for the early 20th-century-style naval battles we wanted to simulate. This is my attempt to do better. Needless to say this is pre-pre-pre-alpha footage and there's a lot to be done before it's ready for public consumption, but I'm quite proud of what I have so far.
The major difference of this game versus every other 3D ship construction game I can think of is that it scraps the voxel system for what I'm calling a "surface" system, because it works by placing flat surfaces whose endpoints are on a grid. This has a few advantages that made it ideal for the kind of game I want to make:
Less performance drop with large constructions (a few large plates vs. thousands of small blocks in a voxel system)
More room for player creativity as you're not limited to a finite palette of blocks
Lends itself to realistic physics and damage models
Also, since the video went up I improved the texture mapping on the meshes and added a preview of the surface you're currently placing to the UI:
Here are some references I used for the math:
Per-triangle buoyancy that doesn't rely on knowing the volume
Equations to generate realistic waves
Implementation of the above in an Unreal Engine 4 shader
After a couple months of getting nothing done, I'm back on the Unreal wagon! This time I'm showing off the beginning of what will be the "machinery" system. Machinery is anything that actively performs a function such as weaponry, boilers, or radar. For now, though, it's just these cubes with an Unreal stock "tech panel" texture.
I've also, er, changed the ocean shader somewhat. I'm not 100% happy with it, but it's already eaten more of my time than I'd like to admit, so I'm going to leave it as-is.
Shipyard version 0.8.0 or "The Combat Update" has just been released! As the largest update the game has ever seen, there is too much to discuss in one post. You can read the abbreviated version on the Brass Watch Games blog or see the full changelog at the bottom of the game's page.
If you already have the launcher, the uodate should be ready for download. Otherwise, you can get either the launcher or the full client archive from my website.
EDIT 7 April: The progress report post has been updated to include a few balance changes introduced after some personal testing. These include further increase of the ship destruction threshold and higher prices (both buying and selling) for scrap.
The combat update is still far from finished, but it's coming along nicely. Since last time, I have made a couple big changes including the addition of an entirely new resource: Scrap. Scrap is dropped by destroyed ships and is used for repairs or can be sold back to the shipyard. You can read more about it on my website.
It's come time in Shipyard to add more sectors to travel to, and to have them generate randomly rather than being hard-coded like the current world. I also wanted the sectors to display on a "galaxy map," where sectors were placed randomly rather than being on a grid. I started with this, creating an algorithm to place points on the map as if they were sectors, even though they didn't function at that time. After a couple hours of tweaking, here are some examples of galaxies it generated: [/font][/color]
[color=rgb(51,51,51)][font=Georgia]These weren't produced by the final version, but rather an earlier version that kept a large minimum distance between sectors. The current version has a shorter minimum distance which creates more variation between worlds. [/font][/color]
[color=rgb(51,51,51)][font=Georgia]My algorithm for galaxy generation isn't exactly simple, but I will try to explain it here. First, a starting sector (always called "Galactic Core") is placed in the center of the galaxy. Then, the generator picks a random angle (We'll call it a) and distance d between 12 and 32 pixels, and places a second sector d pixels away from the Galactic Core, at an angle of a. From there, it randomly selects one of the two existing sectors and repeats the process of creating a new sector d pixels away at an angle of a. It also checks to make sure that the new sector is at least 12 pixels away from all of its neighbors, and if it's too close, the new sector is not created. The same is true if the new sector is more than 96 pixels away from the center, to keep them in a roughly circular pattern. The process repeats until there are 50 sectors in the world, each no closer than 12 pixels to any other and no farther than 96 from the center. Finally, any sector within 32 pixels of another sector is considered to be within warp gate range, so a line is drawn between them to denote this. [/font][/color]
[color=rgb(51,51,51)][font=Georgia]Here's an example of something generated by the final version: [/font][/color]
[color=rgb(51,51,51)][font=Georgia]Once that was done, it was time to code the internal generation of sectors. This was, thankfully, much easier to do. All the internal generation algorithm had to do was place one each of the basic stations (warp gate, item shop, and shipyard), as well as a random number of other objects (planets, item crates, etc.) on a 2D grid. No real fancy stuff, just a random X and Y value for a predefined set of objects. Sectors also generate with a random "style" attribute which dictates which background image to use. This is, again, just a random integer with nothing fancy under the hood. [/font][/color]
I know I really should be working more on Shipyard, but I'm just having too much fun with this tank.
The tank is now a real object with some degree of physics. It can be controlled with WASD, and the gun will aim at your mouse. The physics were done using JBullet, a Java port of the Bullet physics library (originally for C++). The mouse aim was done using what in professional circles is known as a giant heap of trig. I actually spent several hours trying to figure out why I wasn't getting the right values from the formula, only to realize that I had forgotten to convert from degrees to radians and back again, as LWJGL uses degrees but Java's Math class deals in radians. Earlier I had a ton of fun (the sarcasm is tangible) learning about quaternions and how to convert them to something recognizable to humans.
I realize now that it's hard to see the grass texture as a point of reference, but trust me, the tank is really moving. It's a lot clearer in-game, but the video rendering process made it blurry.
[color=rgb(51,51,51)][font=arial]Music by Kevin MacLeod (http://incompetech.com/) -- Available under a Creative Commons license. [/font][/color]
In my last post I showed off an extremely early version of a project in which a simple boat could be constructed from triangular surfaces. Since then I've made a lot of progress in all aspects of the game.
New features/improvements include:
"Design" and "Simulation" modes split into separate levels
Design mode now has a symmetry option, as well as the ability to view the vessel in wireframe to see the borders between surfaces
Internal "compartments" are now handled properly; buoyancy calculations are disabled for sides of surfaces not on the exterior
Designs can now be saved and loaded
Main menu, almost like a real video game
My plans for the immediate future are something like:
More tools in the editor to speed up building
Different materials to build with, each with different densities and other stats
Ability to change "thickness" of surface (not rendered visually, but affects weight and eventually armor value)
It's been a while since I posted one of these, mainly because I've been working more on the Sooper Seecret Tank Project than on Shipyard over the last couple weeks. However, as Shipyard is still my primary focus, I figured I had better share what I have done. [/font][/color]
[color=rgb(51,51,51)][font=arial]A close friend of mine, who also happens to be an aspiring game developer (you can find his work here), suggested that I add this. He thought the current mouse controls were clunky (I didn't mind because I mostly use WASD), and proposed an auto-move or auto-path system to set your ship to move to the selected tile. So, that's what I added. In version 0.8.1, if you hold shift and right click, your ship will automatically move to the selected tile taking as many turns as it needs to do so. You can also cancel auto-move before it's finished by hitting space. [/font][/color]
[color=rgb(51,51,51)][font=arial]Toggleable Map Grid [/font][/color]
[color=rgb(51,51,51)][font=arial]Another suggestion from my friend, he said the grid in the navigation screen was visually distracting. However, I argued that it was useful to know exactly how far away objects are from your ship. So, the solution? Make it optional. From now on, it is off by default but can be toggled with F2. By the way, F1, takes screenshots while F12 opens the debug screen. Speaking of which... [/font][/color]
[color=rgb(51,51,51)][font=arial]Debug Commands [/font][/color]
[color=rgb(51,51,51)][font=arial]Currently, the debug window is only an output log used to see what the game is doing at any given time. However, I've added a new functionality for the coming version: commands. Most games have them in some form, and I figured that Shipyard would benefit from than as well. The current commands are as follows: [/font][/color]
help -- Lists available commands.
describe - Describes a specific command.
givecreds -- Gives the player credits equal to the given number.
givescrap - Gives the player scrap equal to the given number.
tp -- Teleports the player to the given tile. First number is X, second is Y coordinate.
warp - Warps the player to the given sector by ID number.
repair - Repairs the player's ship to max HP.
fillcrew -- Fills the players crew to capacity, but does not allocate them to systems.
[color=rgb(51,51,51)][font=arial]Size Limit [/font][/color]
[color=rgb(51,51,51)][font=arial]The size limit that I talked about a while ago in my outline for 0.8.1 has also been implemented. Now, while in the interior view of the shipbuilding screen, there is a border that dynamically adjusts whenever you add or remove systems, regardless of where in the 48x48 grid you start your ship. As stated in the outline, the Class 1 ships have a size limit of 16x16, Class 2 ships can go up to 32x32, and the soon-to-be-added Class 3 will be able to use the entire 48x48 grid. [/font][/color]
[color=rgb(51,51,51)][font=arial]Armor Types [/font][/color]
[color=rgb(51,51,51)][font=arial]With shuttles on the way (though still not currently functional), I decided to implement light and heavy armor types. All weapons have a preferred armor type, and will receive penalties for attacking the wrong type. Currently, only the Twin Autocannon prefers light armor, while every other weapon prefers heavy. Ships are classified as heavily armored, while shuttles will be lightly armored. This means that, due to type penalties, the Twin Autocannon is more effective at dealing with fighters than some weapons with higher base damage. It has also had its base damage doubled to 24, making it just as (in)effective against ships but giving it a purpose in dealing with enemy fighters. [/font][/color]
[color=rgb(51,51,51)][font=arial]As I've already said, shuttles are still in progress and are not functional in-game items yet. However, I have made the sprites for a couple of them: [/font][/color]
[color=rgb(51,51,51)][font=arial]On the left is the Trans-Atmospheric shuttle, which will be used to send away teams down to the surface of planets as it can function both as a spacecraft and an atmospheric craft. On the right is the Light Fighter, a basic attack vessel which prefers lightly-armored targets (see above), making it ideal for intercepting enemy shuttles and fighters. [/font][/color]
[color=rgb(51,51,51)][font=arial]Right now, I am continuing to work on shuttles and hopefully I'll have something usable in-game for the next one of these development posts. [/font][/color]
This is a quick post to show off some of my progress toward the Combat Update. First, I've completed the new ship movement system and the controls associated with it. Right clicking now turns your ship by 1/8 turn per click until it faces the mouse, and once it's facing the right way each click moves it one square in that direction. The arrow keys are much simpler: left and right rotate the ship while up moves you in your current direction.
I've also started working on the Ship Management screen, which displays information about the ship and allows control over some of the inner workings. Crew and upgrades aren't implemented yet, but the "Overview" tab displays the ship (and is smart enough to center it regardless of where on the grid you built it), and shows tooltips with information about the system you hover over. To demonstrate the coloring and stat penalty system, I randomized the HP values for the second image.
Yeah, it's nothing huge, but it's a step in the right direction. As you can probably guess by the version number in the top right, I'm planning to release smaller, preparatory updates before making the final leap of the combat system.
There's a new progress report posted on my website. The latest changes include crew repairing systems, improved crew and power distribution, and pirates which actually fight back. Expect to see more news over the next week, as school has gone on spring break meaning I actually have some free time to work on game development.
I've been a bad developer the last couple days. Instead of working on the stuff I promised for the next update, I've been doing something not completely different, but somewhat tangential. I have, as it turns out, been working on coding a launcher for Shipyard. At the moment, it will show the changelog, download the latest version, check for newer versions, and run the game. It won't be winning any beauty contests, but it does its job.
You can download it here to try it out. You need Java to run it and an internet connection to download the game and retrieve the changelog. So far, it's been tested on two computers, both running Windows 7 64-bit, with no problems.
Here's a screenshot for the skeptical:
As for the game itself, I'll get back to working on it. Version 0.7.2 has already been released, featuring the ship overview screen, new movement system, and a few other changes. You can expect one or two more of these smaller updates as I prepare the game for the addition of the combat system, coming in version 0.8.0 (Or maybe Alpha 1.0.0, if I'm feeling extravagant).
It's been a few weeks and multiple game updates since I posted here. I've instead been posting my progress on my own website, but I figured I'd remind everyone here that I'm still alive and that Shipyard has been coming along nicely since last we saw it. In fact, the release of version 0.7.4 concluded the series of "preparation" updates, and it's time to move on to the real Combat Update: version 0.8.0.
I don't care to copy-paste every progress report since the launch of the new site, but I will go over the more important changes. So, without further ado...
The ship management window now allows you to change your ship's crew and power. Currently, you can do it as often as you like. However, in the coming version, you will only be able to save your changes once per turn.
There's a new weapon: the Railgun. The Railgun is a high-damage, high-complexity fixed ballistic weapon, and the new largest weapon in the game at 5x5 tiles.
There are now AI ships in the world. At the moment, they'll follow you around harmlessly. Of course, that will all change in the coming update...
There's also a new station: the Academy. Currently a placeholder, it will eventually allow you to hire both generic crew and officers.
[font=arial]All that is in the game right now, but now we come
to the stuff from the coming update. I haven't got much finished, but I have the beginnings of the combat screen. You can't attack yet, but it wil[color=rgb(51,51,51)]l list your weapons and tell you (A) if they can fire and (B) if no, why they can't. In this case, my ship has a Railgun and two Torpedo Launchers which are facing the wrong way to fire at the enemy ship:[/color][/font]
You can download the latest version and read in greater detail about the game on the Shipyard page of my website.
Recently, I've been working on an up-to-now secret project in addition to Shipyard that I would share if it went well. Well, thus far, that seems to be the case, so here's a little sneak-peak of what I have so far:
I'm not going to give any details yet, but I will explain what's going on in the video. You are given a (currently untextured) 3D model of a tank, which you can fly around and look at. You can also control the turret rotation and gun elevation/depression using the arrow keys. It's not much, I know; the important thing here is that it has 3D graphics -- something I've never personally experimented much with until now.
Like Shipyard, the game runs in Java. However, rather than using Java's built-in graphics API the way Shipyard does, this demo uses LWJGL. The code is, at this point, cobbled together from various tutorials, but as I get more used to OpenGL, I find myself relying on them less and less. The next step will probably be to add some sort of simple game world and make the tank actually playable. I already have various plans for the finished product, but I'm going to keep those to myself until I'm certain I can actually make them happen.
Today, I worked on adding animations to ship combat in Shipyard. I only have two so far, but more are coming soon. Here's a video showing them, along with various other features of the update:
I've always felt that "nerdboy64," while perfectly fine for a forum username, was a little too informal for proper game development, and I think we can all agree that it isn't the sort of thing I'd want emblazoned on a convention booth ten years down the road. Thus, I've decided to rebrand myself as the infinitely classier Brass Watch Games. Click the logo below to go to the new website:
BWG will be the new home of Shipyard and any full games that come after it. I've even rigged up a redirect link at the old location so that people who find older posts will be sent to the new site.
I will also be posting news of new versions and other announcements there, and since I don't seem to have the ability to create multiple developer journals, you'll have to check the site if you're that interested. More "technical" stuff will still go here, of course, as the majority of viewers probably don't want to see it.
Welp, that's it for this announcement. Now it's back to working on the actual game...
First of all, I want to say that this is not a professional endeavor. I am very much an aspiring programmer, and this is very much an "in my free time" sort of project. Though I am quite proud of it and hope people like it, I just want to say that I don't claim to compete with some of the far superior things on this site. In short: keep your expectations low.
Now that that's over with, allow me to introduce my project. Shipyard is the temporary title of a science-fiction themed, turn-based strategy game which I have been working on for about six months now. The gimmick (and the origin of the name) is that the player builds their ship from individual systems such as crew's quarters, weapon controls, engines, etc. on a 2D grid. Combat is not yet implemented, but it will be based around strategically disabling your enemy's systems until the vessel as a whole is crippled.
Here are some screenshots of the shipyard screen, showing the interior, exterior, and weapons editors:
I am currently working on random world generation and the ability to save game files (ship designs can already be saved separately) for the next version, and I am quite happy with the results:
Warp Gate interface, allowing transport between sectors:
Sector map showing locations of player, planets, and stations:
World saving isn't ready to show yet, as I have the main code done but still have to design the UI.
If you want to play around with what little I have, there's a download at http://nerdboy64.com/shipyard/. The game runs in Java so you may get an antivirus warning about the jar file. I can't really tell you to discount such messages, as that would only beg the question, so go ahead and trust your better judgement.
As an extension of the customization mechanic, one of the main features of Shipyard is its combat system. As it makes its way into the real of "real game," I figured it was about time I got to work on that mechanic. As of yet, the only coding I've done has been preparatory; however, I have been making plans for how the system will work when I get to the actual implementation. Below is an explanation of the concept as it currently stands. Not all of it is directly related to combat, but it is all has some effect on it and is therefore coming in the "Combat Update."
NOTE: Because very little actual coding has been done, this will be somewhat of a wall of text. If you are impatient or simply hate reading, you might want to check back when I have some actual progress.
Engaging an Enemy
To engage an enemy vessel, you must be within one tile of their ship (diagonals included). Clicking on the enemy will bring up a context menu, just like every other object in the world, with an option called "Engage." Clicking this will bring up an exterior view of the ship and a list of the weapons on your ship. From here, selecting a weapon and a location on the enemy ship will cause that weapon to attack the enemy.
Each turn, you are allotted a number of "weapon control" points equal to your weapon control stat, and every weapon has a firing cost in these points. Thus, no matter how many weapons you have on your ship, you can only fire as many per turn as your WC stat allows. If you have a single Small Weapon Controls system, giving 8 WC, you could fire eight Twin Autocannons or four Small Gauss/Plasma Cannons. Regardless of your WC stat, the same weapon can only be fired once per turn.
Turrets, Fixed Weapons, and Ship Rotation
Currently, the game does not consider the direction of your ship and allows you to move in any direction at any time. The limit for how many tiles you can move is the ratio of engine power to total mass of your ship. If you've looked through the image files, though, you may note that "shipicon.png," which contains the icon used by the navigation menu to represent your ship, shows the icon facing in eight different directions.
This is because, along with combat, the movement system is being effectively overhauled. You will still be limited by your thrust to mass ratio, however you will only able to move in the direction your ship is facing. Rotating your ship will count as a movement, even though you stay on the same tile. You will also be able to move diagonally with only one unit of movement (so that you don't have to constantly turn-move-turn-move and so on).
"But wait," you ask, "how does this relate to combat?" Well, dear reader/player, it will affect which tiles you can attack with which weapons. Currently, every weapon in the game is classified as a "turret," meaning it can fire in any direction regardless of the way your ship is facing. However, when combat is added, a new class of weapon will be implemented: fixed weapons. Fixed weapons are, as the name suggests, fixed relative to your ship. If, for example, you have a fixed weapon facing forward and an enemy 90 degrees to the right, you will not be able to attack them with that weapon unless you pay the movement cost to turn and face them. This does not mean that all fixed weapons must face forward, though; it would be entirely possible (though somewhat silly) to create a 27[sup]th[/sup] century ship-of-the-line with rows of fixed cannons down either side. With this setup, you would have to pull alongside your enemies to attack them rather than face them directly.
Damage and HP vs Crew
Say everything goes right and you fire a weapon at an enemy ship. Let's assume both ships are in perfect condition to start with. You might not know what system you hit, but whatever it is, you will take away some of its hit points. Most systems will receive a 50% stat penalty upon reaching 30% of their max HP (at which point the system is considered "heavily damaged"), however some (like bridges and crew's quarters) will not. If you continue attacking the same spot and manage to reduce its hit points to zero, the system is "destroyed" and the penalty goes up to 100% on applicable systems.
However, there is another factor which determines the effectiveness of systems: crew. Ships will now have a certain number of crew available, capped by their crew capacity stat. Ideally, you will have enough crew to fill the requirements for all of your ship's systems. However, if you have less then enough, you will have to distribute crew according to what you think is most important at the time (for example, diverting crew from engines to weapon controls when engaging an enemy). Systems which are have less than enough crew will receive a penalty proportional to the number of empty crew slots. For example, a Small Weapon Controls with only four crew will receive a 4/8, or 50%, penalty to its effectiveness.
Your crew are not invincible, however. Even if a ship has enough room in its Crew's Quarters for, say, 64 crew, those crew members can be killed by attacking the system they are currently manning. Different types of weapons will deal more HP or crew damage, but a system with less HP will offer less protection to the crew inside. I haven't designed the exact formula for this, but for systems with most of their HP, crew damage shouldn't be a major problem.
Weapons are already divided into three categories, though only two are currently represented ingame. These categories are ballistic, energy, and explosive. Ballistic weapons are the middle-of-the-road kind, firing a solid projectile which does equal damage to systems and crew. Energy weapons are the "futuristic" ones, using superhot plasma or high-powered laser beams to attack the enemy. These deal extra damage to a system's hit points; however, since they don't involve a significant impact, they are less likely to kill crew. Explosive weapons are the opposite, using an explosive charge to create shrapnel that is lethal to crew but does less damage to HP.
Generally, the trade-offs between equivalent ballistic, explosive, and energy weapons will keep them roughly equivalent in effectiveness. However, since crew damage depends on system HP, explosive weapons are far more specialized than the other types.
First of all, if you've made it this far without skipping anything, congrats to you--you've made it through more of my writing than I can can handle myself. This "Combat Update" is shaping up to be the biggest the game has ever seen, and rightly so. Of course all of this is subject to change, but it should provide a general idea of what I'm going for.
When I first added the ability to save ship designs, the system I used was, to put it bluntly, not very good. The format it used was just a text file, and loading relied heavily on things like line breaks. When opened in a text editor, it looked like this, only longer:[code=nocode:0]name:Light Cargosystem:0:7:4system:1:7:6system:3:7:9system:9:6:4system:9:6:5system:9:5:5system:9:5:4weapon:2:10:6:2weapon:2:10:8:2weapon:2:10:10:2weapon:2:10:12:2weapon:2:6:6:6weapon:2:6:8:6weapon:2:6:10:6weapon:2:6:12:6tile:28:5:4tile:32:5:5tile:4:5:6tile:4:5:7tile:4:5:8tile:4:5:9tile:4:5:10tile:4:5:11tile:4:5:12tile:1:6:4
Basically, the game would read one line at a time, split the string at every occurrence of a colon, and look at the pieces. If the first string was "system," it would look for three integers: an ID corresponding to the system type, an x coordinate, and a y coordinate. Tiles and weapons were much the same, except the latter had a fourth value for the direction in which it was aimed.
It worked well enough fat the time, but I think you can see why I had to change it. First, it wasn't expandable. Sure, I could add a new named series of integers for different ship parts, but I would have had to recode it entirely from scratch to work with, for example, a full world save. It didn't provide any sort of standardized framework, only a simple system for a single job. Second, it was generally clunky. There was no organization, and designs were loaded in real time as the file was read. This meant that there was no "middleman" where data could be both saved and retrieved, without having to constantly open new input and output streams.
This had to be remedied before I could work on world saving, so I set out to create a new system which presented a standardized file format that could be re-used for anything I needed to save. The first thing I did was switch from plain text to binary, under the assumption that it would be more efficient. I don't have any evidence as to the truth of that, but seems to make more sense to save, say, a numerical value in binary rather than the characters that make up the number.
I also wanted it to be organized--no more making lists of things and relying on the order. I wanted every data point to have a name, and the ability to put related data into groups. Basing my new system off my experience modding Minecraft (which isn't known for technical efficiency, but hey, it's all I know), I created what I call the "data tree" system.
A data tree can store any of Java's basic data types, and more importantly another data tree. By nesting data trees within data trees, related data could be grouped together. This is where the system gets its name--a diagram of a data tree would look somewhat like an actual tree, with every branch being a new subgroup of data. When writing to a file, every piece of data is saved with its name, value, and type, so that when reading it back into the system it can be properly parsed without having to assume that things will be in a certain order (like the old system did).
Once data is stored or loaded into a data tree, it is contained in a HashMap correlating its name to its value. The map stores everything as plain Objects, but there are methods called getInt(), getString(), getGroup(), etc. that cast the data to the proper type. This assumes the thing reading the data knows what type it is. However if that is not the case, there is a method called getGeneric() that returns a plain Object. From there, calling getClass() will allow the user to figure out what kind of data it is.
Replacing the ship saving system with data trees was easy. I needed a string for the name and sub-groups for systems, weapons, and decorations. The systems and weapons groups contained their own sub-groups, each with the data for an individual component of the ship. The decorations group was even simpler, only containing the coordinates and ID numbers of the decorative tiles that made up the outside of the ship. This was easy because systems and weapons are all a part of the same class, and are different only in the stats passed to them as arguments. World saving, however, was more difficult because different objects (with a lowercase "o," as opposed to Java Objects) had truly different behaviors, meaning they needed their own classes. After much thinking, I settled on a system by which each object class was assigned a numerical ID which was saved with the object. When the object's data was read back in, the game would find its class based on the ID saved with the object, then cast it to that class. I had to do a lot of crazy bollocks with Java reflections, but in the end I got a system that worked quite nicely.
If anyone is interested, I'd be happy to post the source code of the applicable classes. Until that happens, though, I'm omitting it just because this post is already much longer than I had planned.
A few days ago I posted a dev journal with some images of characters I had created for Shipyard. At the time they were just mock-ups made in an image editor, but I liked the idea so much that I decided to go ahead with it. The process was a lot more involved than I had expected, but in the end I managed to come up with a crude but functional first-implementation. Not all the features are complete, but what I have so far is not too shabby in my opinion.
Default color settings, male and female versions:
Something a little more colorful:
Since it uses full RGB, you can do some truly horrendous stuff as well:
[s]Next on the ol' to-do list is to create different hair and clothing styles to allow for deeper customization. I'm going to, at the very least, have all the styles from the mock-up versions. [/s](Done! See below.) I'm also considering making each "style" an actual character class, which might provide different stats to your ship. For example, military mightgive a bonus to crew combat, while a merchant might get better shop prices and more starting cash. Nothing is set in stone, but the more I think about it, the more I like the idea.
Welp, that's all for today, folks. If I'm feeling particularly bored or people show enough interest, I might post something about how I did it. For now, though, I'd best get back to some actual coding.
Update: Since I posted this, I've added and changed several things. First, I've cleaned up the textures quite a lot. Second, I've added support for different hair and clothing styles as I was talking about in the original post. I only made one more set of each, but with the code in place the rest is just content generation.
As you can see by their expressions, these two are simply overjoyed to demonstrate the new options:
Recently I've been thinking about adding character creation to Shipyard. The character wouldn't do anything on their own, but the image could be used in dialog sequences and just add a little extra personality to the game. I haven't done any actual programming yet, but I've been having a lot of fun making mock-ups of various outfits in Paint.net. The reason they all look mostly the same is because, eventually, the character editor will have a set list of hair styles and decorations, which rely on having a consistent base to get the right look. The colors will be modifiable via RGB sliders for individual components (top, bottom, hair, etc.).
Here are some of examples I've come up with:
Generic "spacey" uniform.
Military-style uniform, different skin and hair colors.
Something a little less formal, maybe a colonist or a "space cowboy," a la Firefly.
On the other hand, she might be an affluent merchant or some sort of diplomat.