Starship Builder - UI Modes

This is a somewhat experimental release of Starship Builder, focused primarily on trying out different levels of control that players have over ships, systems on ships, and people in ships.

Here's a rundown of what's changed:

• Added two separate "modes":
• Combat: Allows you to select and give targets to specific weapons. Left-click and drag to draw a box around and select the weapons. Right-click on a target to focus-fire on that target.
• People: Allows you to select and give orders to specific people. Left-click and draw a box around the people to select them. Right click on a system order some of the selected crew to operate that system. Hold U to select only those crew without any orders.
• Ship movement (when in "Movement" mode) is back to right-click.
• Crew can now be ordered to operate specific systems such as weapons, thrusters, ammo supplies, and cockpits.
• Crew's Quarters have been removed. All parts requiring crew now automatically start with their required crew. Crew can also be added and removed manually in the Builder. Hold P when placing a part to not create the default number of crew for that part.
• Crew must be assigned to specific Ammo Supplies. Those crew will then supply ammo to nearby weapons.

Here's a screenshot of the player selecting a handful of cannons:

And here's a screenshot of the player selecting a handful of people: (If you look closely, you can also see lines indicating the paths that the people are travelling.)

Here are download links for PC and Mac versions of this build.

I'm unsure yet whether the player should have this level of detailed control over ships, and I'm especially not sure about whether the individual crew members should be directly controllable or whether they should be completely automated. The direct control of crew in this build seems unnecessarily tedious, so I think I'm leaning towards totally automatic for the future.

Starship Builder - Crew Congestion & More

It's been a couple weeks since I last posted about Starship Builder, mostly because my progress since then has been lots of little improvements and not many big new features. But all those new improvements have added up, and I also have working on a significant new mechanic that I'd like to talk about, especially with regard to how it's programmed.

Here's a rough list of what's changed since the last post:

• Added crew congestion mechanic. (See below.)
• Replaced that ugly purple grid with a much nicer space background. A simple grid is overlayed on top of the background.
• Bullets fired from cannons now inherit the ship's velocity. (This is more physically realistic.)
• Tons of bug fixes and performance improvements.

Feel free to download the latest PC and Mac builds.

The significant new mechanic I mentioned above is "crew congestion". Essentially how it works is that, whenever two people are passing through each other in opposite directions, they will slow each other down. This is to emulate tight corridors where two people have to squeeze past each other to get by. But the people are smart, and they will try to avoid other people going in the opposite direction by taking a different route if they can. The result is that creating double-wide corridors or alternative paths can significantly increase the efficiency of your crew.

In the previous version of Starship Builder, a single person wanting to travel from point A to point B used a basic A* pathfinding algorithm to determine the shortest path from A to B, taking into account only the distance between points and travel speed (the rate at which the person can move through different parts of the ship, such as corridors vs thrusters).

In this new version, the A* algorithm is still used for pathfinding, but it also takes into account an estimated "congestion level" for each grid location. A grid location's congestion level is used to reduce the assumed speed at which the person can travel through that location. If the assumed speed is low enough, then the A* algorithm will naturally attempt to route around that location.

The way that congestion is estimated for grid locations is inspired by the way that ant colonies lay down scents to mark paths leading to food. After an ant finds a source of food, the ant will return to the colony, laying down a weak pheromone trail on its way back to the colony. This trail is a small suggestion for other ants to follow. Most ants won't follow, since the trail is very weak, but a few will, and when they find the food, they'll return, laying down more pheromone over top of the trail. As more and more pheromone is laid down, more and more ants will follow it to the food.

Congestion estimation in Starship Builder is inspired by these ant colonies, but it works in almost the exact opposite way. Whenever a person plans a path from point A to point B, a "virtual pheromone" is instantly applied to the entire path, but instead of persuading fellow crew to follow the path, it actually dissuades fellow crew from following the same path. The more virtual pheromone there is on any given grid location, the slower the "assumed speed" will be when the A* pathfinding algorithm runs. So the more people that travel along any given path, the more likely it will be for others to try to take a different path.

Starship Builder - Crew & Ammo

My biggest accomplishment this week has been to add crew and an "ammunition" mechanic to weapons for my Starship Builder game prototype.

Your ship now needs crew for most systems, such as weapons and thrusters, to be able to operate. Crew can now be added by placing "Crew's Quarters" rooms into your ship. Each Crew's Quarters comes with a set number of crew, who will automatically find systems to operate.

Additionally, your ship's cannons can now only store a limited amount (5) of ammunition. If a cannon runs out of ammunition, then a crewmember must hand-carry a "ammo ball" from a nearby "Ammo Supply" (another new kind of room) to the cannon. (Yes, this is way in the future, but for some reason there are no systems to automate this.) This way you have to think about placing Ammo Supplies near enough to cannons so that they don't run out of ammo in the middle of a fight.

While crew can travel through any part of the ship, they travel much faster through corridors than through any other parts. If you want your ship to operate efficiently, then you'll have to think a lot about planning your corridors to give your crew quick access to the ship's systems.

Changes from the previous version:

• Added "Crew's Quarters" rooms that each come with 8 people.
• Added "Ammo Supply" rooms that store an infinite amount of ammo.
• Ammo must be hand-carried by crew from Ammo Supplies to the cannons.
• Click on any cannon or thruster to deactivate or re-activate it. (Deactivated systems don't require crew.)
• Limit of 32 thrusters. Also added "wide" thrusters.

You can download this latest build for PC and Mac.

Starship Builder - Guns & Asteroids

This past week I added cannons and asteroids to my "Starship Builder" game prototype. Cannons are a new piece that can be added to ship designs, and asteroids are targets for the cannons to shoot at.

A ship brimming with cannons:

And the same ship blowing up some asteroids:

You can download PC and Mac builds of this new version and try it out for yourself!

Here are all the big changes from the previous version that I can think of:

• You can now add cannons to your ship in the builder.
• In the simulator, press R to spawn an asteroid at the mouse cursor.
• If an asteroid hits your ship, it will do serious damage!
• Parts of your ship can be destroyed by asteroids, and your ship can actually break into multiple pieces!
• Right-click in the simulator to move your ship. (Hold and drag to adjust orienation.)
• Left-click on an asteroid to target that asteroid specifically. Otherwise your weapons will automatically target nearby asteroids.

Starship Builder - Early Designer Interface

In a previous post I talked about an idea I have for a new game. In this game players are able to design their own space ships by placing rooms, weapons, engines, corridors, and other systems onto a grid. Everything in the game is very flexible (you can make ships of any shape, size, and configuration) and dynamic (realistic physics, weapon damage is inflicted to specific components on the grid). You can read a more detailed description in that post.

I've started to implement a very rough prototype of an interface "builder" that allows you, the player, to design your own ship and then test it in a separate "simulator" mode.

Here's what the "builder" looks like right now:

Future Walt asks you to please excuse the really horrendous purple grid background.

And here's the "simulator" showing the ship from above flying through space:

If you want to try it out yourself, here are links to PC and Mac builds.

Some basic instructions:

1. The first piece you place must be the "Cockpit". You can place it anywhere. (Click on "Cockpit" on the left and then click to place it onto the grid.)
2. Continue adding corridors and thrusters. These must be placed adjacent to already-placed pieces. Make a ship in whatever shape you want! But keep in mind that the thruster physics are fairly realistic, so if you want your ship to be maneuverable, then make sure to place thrusters spread out in various locations and facing various directions.
3. Press the < and > buttons to rotate the selected piece before placing it.
4. Hold the middle mouse button and drag to pan the view. Use the scroll wheel to zoom in and out.
5. When you want to test your ship, type in a name and press the "Save & Test" button.
6. Once in the simulator, click the left mouse button to move your ship to a location in space. Hold it and drag to adjust your ship's orientation.

March of the Matryoshkas

I teamed up with my good friend Jan Stec and my new friend Andy Brown for this year's Global Game Jam, in which small teams make games in only 48 hours. (Counting sleep!)

We made a fun little game that we call March of the Matryoshkas. You can play it in your browser right here.

March of the Matryoshkas is a "one-button rhythm puzzle game" which won the Pittsburgh, PA sub-jam's "People's Choice" award. The original idea was to create a game about fashion and runway models, but it eventually iterated into a game about Russian Matryoshka dolls. Bizarre, I know. ;-)

Starship Builder - Idea & Thruster Algorithm

I have an idea for a game that I've been wanting to make ever since I was a kid. I've actually tried to make it several times as a pen & paper tabletop game, but it's just too complex of an idea for pen & paper. It's only recently that I've become a good enough programmer to tackle the idea as a computer game, and so I've been thinking more about it lately.

The core idea of the game is that the player designs and builds a space ship on a 2D grid. Think SimCity, but instead of placing buildings and roads onto a grid, you're placing corridors, weapons, engines, crew's quarters, and other ship systems onto the grid. Unlike many games, which only let you place systems onto pre-assigned "hardpoints" of the ship's hull, my game will allow the player to completely customize the ship's size, shape, and the location of internal systems.

Where you place engines, weapons, and other systems on your ship will really matter. Engine physics will be accurate, so that you have to actually think about exactly where the best place to put that thruster will be. Weapon damage will be localized, so that weapon fire from an enemy ship will strike a particular part of a ship and damage whatever systems are there. You'll have to think about what systems you want to put near the outside of your ship, and what systems you'll want to protect deeper inside.

Inside the ship will be dozens, possibly hundreds of crew members scurrying about from one system to another, keeping everything operational. You'll have to think about the corridor layout inside your ship so that your crew can easily travel from one system to another.

The key to this idea is that the player has complete flexibility and customization when designing ships. The only game I know of that even barely resembles this is Captain Forever. But Captain Forever is a fairly simple arcade game, whereas my game, if I ever make it, will be much more of a tactical strategy and simulation game.

I actually just threw together a very rough prototype to prove to myself that I could solve what I think will be the hardest programming problem to solve: that is, how to make a ship realistically fly to a desired location no matter where the player places the ship's engines and no matter how many and what size they are. Future Walt laughs at his past-self's naiveté. This was far from the hardest problem to solve. You can try out this prototype right here.

The algorithm I came up with actually seems to work pretty well. Sure, it could use a lot of tweaking and some higher-level intelligence, but basically I think it proves that I can make it work within a larger game.

The basic algorithm works like this, assuming you have a number of thrusters that each can be "activated" from between 0.0 and 1.0:

1. Calculate a desired force to exert on the ship (X, Y, Rotational) based on the desired location and/or velocity.
2. Build a list of all the thrusters on the ship and sort it by how much more closely a change in the thruster's activation can bring the ship's current force to its desired force.
3. Iterate through each thruster in that sorted list, setting its activation to the value that brings the ship's current force as close as possible to the desired force.
4. Repeat steps 2-3 at least a few times so that the thrusters can "approach" and eventually "settle in" to a near-optimal set of activation levels.

This whole algorithm is run once every frame to constantly adjust the thruster's activation levels.