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.

Coco & Co Final Presentation

We just had our final presentation for team Coco & Co and our game WAY. The semester was a blast and we're incredibly proud of WAY. Here's a link to the presentation video (we're the 2nd video). Wish us luck for the IGF!

http://www.etc.cmu.edu/siliconvalley/blog/2010/12/10/final-presentations-fall-2010/

Sad note from Future Walt circa 2011: We didn't get nominated for the IGF. :-(

Happy note from Future Future Walt circa 2012: We just won the IGF!! OMG!!! Hurray!!!!! :-D

TIGJam

Future Walt is totally not retroactively posting this from the future. Also, it was written by Paulwei originally for the ETC SV blog, but Future Walt totally thinks it's worth sharing.

Team Coco & Co. was at The Independent Game Jam (TIGJam) this year.

If you’re an Indie Game nerd, you would have loved this event. The event housed around 50 indie game developers at the Hacker Dojo in Mountain View. Some people had experience and some people were complete newbies. It was a little intimidating going into the game jam. There are all these people that, if you know who they are, they’re indie game superheroes. The first time I saw them, I was totally geeking out. Then you get to know them and really, they’re just regular people like you and me.

Our first day, a stranger sat down across from me, shook my hand and introduced himself as Ron. It wasn’t until later that day that I realized I just shook the hand of Ron Carmel of 2DBoy, the creators of World of Goo.

Other superstars included former ETC Alums, Kyle Gabler, and Kyle Gray. Derek Yu, the creator of Spelunky was also there.

Anyways, we set up shop, we got to work and it was a very productive 4 days. We were able to test our game with some fun people and everyone enjoyed our game once they figured out the mechanics.

Our advisors, Jiyoung and Carl stopped by Friday afternoon to check it out. They stayed for a bit, talked with some people, took some pictures and even got to play a pre-XBLA version of Spelunky before they left.

Aside from the great atmosphere, there were some fun events that happened throughout the jam.

First off, there was a movie being shot while we were Indie Game, the Movie is set to come out sometime next year. Our team was right next to where people were interviewing all these indie developers so you might actually get to see our screens, backs or even faces in the background of the movie.

There were a few nights where we had a single elimination tournament for all to see. The third night was a Madhouse tournament in which Paulwei got into the finals and lost pretty badly. The fourth night was a Nidhogg tournament where Chris got into the finals and lost. These small losses will bring a big win in the near future (fingers crossed).

Every night there were different talks from different developers about what’s on their minds. Scott Anderson talked about getting more people into games. Derek Yu had the same message about being all inclusive and never burning bridges. These were all very off the cuff talks that made it great to hear from all these different people about the industry that they love.

Believe me, making indie games is definitely a labor of love.