Doubloons! Main PageDownload

Doubloons! is a game where you are a pirate captain, commanding your ship and crew to take over and plunder enemy ships. At your disposal are cannons, bilge pumps, rowboats, grappling hooks, gangplanks, and a load of angry pirates.

Your goal is to attack your opponent’s ship, steal their gold, sink it, and sail off into the sunset (in that order). You control the pirates through orders you give them, and then the pirates will complete the task to the best of their abilities. Combat effectiveness may change during battle due to grapeshot, inability to swim, and injury from swords.

The controls are listed above each ship on the play screen, start with Vs. Mode so that your opponent doesn’t do anything. You control the pirates by giving them orders.

For example you hit the “man the cannons” button and the game will pick an idle/defending pirate and make him load the cannons. Later, you can hit the “decrement cannon loaders” button and the game will remove one of your cannoneers.

The game ends when a player has no pirates left and one of the ships has sunk (Not necessarily that player’s ship!), or when one of the ships escapes from the other by sailing off the edge of the screen, or when you press ESC. After this, each player is scored by gold possessed, pirates killed, damage dealt, and whether their ship survives or not.

Progress Update

Got Game Maker 7 installed. Its event system is miles ahead of what MMF had, though it took a couple tries to get things working the way I wanted to.

Here’s what I have so far:

  • Cars that can move towards the top of the screen at different speeds: 1 tile per second, 2 tiles per second, or 3 tiles per second
  • Lane changers and accelerate/brake tiles that affect the cars correctly
  • Car creators that create a car once per second

There isn’t a UI yet for placing any of these things once in the game, so I’m laying them out in Game Maker’s scene editor. All this was about 3 hours of work. Game Maker is almost frighteningly efficient.

Future Traffic Programmer, Pt. 2

This is a follow up on the earlier post about Future Traffic Programmer, which has the unfortunate acronym ‘FTP’.

I need to refine my design, since there are still a couple areas that are ambiguous. Namely, how the game processes over time and how it simulates the movement of the vehicles. To get a better feel of how to design this type of puzzle game, I’m going to look at a couple games that use similar concepts.

Lemmings – Each lemming is controlled after they pop out of the hatch, instead of placing something into the level beforehand. Everything resolves down to pixel-precision – there aren’t any exact solutions to any of the levels, since the lemmings move fast enough that there is some variance to where they build, dig, and so on. The goal of lemmings is much more how to deal with the terrain in clever ways, rather than directing traffic. Lemmings can move at different speeds depending on their task.

Chu Chu Rocket – This game uses a square grid where you place arrows that direct mice from their starting places to a rocket launch pad. The challenge mainly comes from directing traffic, since there are enemies that can eat the mice. Each unit moves one tile per time unit.

Star Wars Pit Droids – Colored pit droids have to be guided to their color coded exits on a hexagonal grid. You place arrows to control their movements. There are some other aspects as well, but I can’t remember the specifics since it was a long time ago that I played it. Pit Droids is very much a traffic control challenge because you can’t let the droids run into walls or eachother.

The Lost Mind of Dr. Brain – There is a puzzle in one of the Dr. Brain series of games where there is a robot on a square grid, and you place programming cards intofunction areas to instruct the robot to perform tasks. You have to avoid obstacles and enemies as well. There’s an online version of this called Light Bot, which is not as challenging but still fun. The big challenge in these titles is to get the robot to do everything it needs to do in as few instructions as possible, and you can use nested function calls to get a lot out of a couple simple commands. The commands are issued one at a time, at a rate of one command per time unit, and each command takes one time unit to complete.

Considering these, I believe Future Traffic Controller would work best with a (mostly) strict tile/timing system for the cars, otherwise it could end up as a mess with solutions that almost work, but for a single car that clips the edge of another’s bumper at some point, requiring transmitter tiles to be readjusted pixel by pixel to fix. That type of gameplay isn’t very useable when you have to place tiles with a mouse.

So, each action that a car takes will take at minimum one simulation ‘tick’ in game. The cars can still appear to move smoothly of course, just as Chu Chu Rocket does with its mice. Different car speeds can be simulated by having a slow speed be 1 tile per tick, medium and fast being 2 and 3 tiles, respectively. Higher speeds would be possible, but that would only cause the levels to be stretched out, without increasing their complexity. Lane changes will take two ticks to complete, so that the car will actually occupy two tiles during the intervening tick. This prevents cars in adjacent lanes from both going left at the same time, which hardly happens on the road, and is incredibly unsafe to boot.

Combining lane changes with the speed of a car means that a slow car moves two tiles forward as it goes one to the side. Medium and fast cards go four and six tiles, instead.

The final complication, and there always is one, is the priority of operation of triggers that you place. I want them to be triggered before the transmitters they are hooked to are triggered, so that when two cars in adjacent lanes hit a trigger and a transmitter at the same time, the transmitter is affected by the trigger.

Similarly, triggers that operate on other triggers should fire off from the outside in – this way anything you place on the road will take all of its multitude of triggers into account before deciding whether it is activated or not. This will allow for some complex (and hopefully not confusing) chains of toggles and other triggers that hook into a bunch of transmitters, resulting in some fancy traffic patterns, and of course their resulting puzzles.

So, where do the cars come from, and where are they going? The levels will be laid out as stretches of expressway, with cars coming from either the main trunk or entering later along the road from entry ramps on the left and right. Similarly, cars will be able to leave the level from exit ramps or by continuing straight along the main trunk. Complications can be added by having the highway expand or shrink lanes, or by having sections of a lane blocked by construction. The goal here will be to get cars from wherever they start to the exit location that they desire, shown by color coding on the car and the appropriate exit.

One type of puzzle (or portion of a puzzle) that will come up a bunch is the concept of traffic weaving – given lines of traffic in two adjacent lanes, where people from one lane want in the other, and vice versa. There are two steps to solving this type of puzzle. The first and hardest step is to get the lanes lined up so that no car in one lane is directly adjacent to one in the other lane. Once that’s sorted, it’s a simple task to put a lane changer in each lane, coded to affect only cars that actually want to get over to the lane they aren’t in. Getting the lanes properly lined up can be easy if the traffic from each comes in a regular fasion at a medium speed, since you can put a brake transmitter directly before an accelerate transmitter in order to put one lane out of phase with the other. If the traffic is uneven, you’ll need to use triggers to adjust the phase of particular cars based on whether there is a car adjacent to them or not. If both lanes are irregular, this may become supremely difficult!

There are two ways to score a successful solving of a puzzle here. One is by how long it takes for all the cars to exit the level, which puts an emphasis on putting the cars at their maximum speed, where you have less time to change lanes. This represents increased economic productivity when people can get to work quicker. The other way is to score based on the number of transmitters used, since they cost money and the transportation department has a budget to keep. Some levels could even feature a limited total budget or limits on certain parts, which is a common feature of puzzle games.

With those issues sorted out all I need to do is find an engine to write this in. I’ve been planning on looking at Gamer Maker 7, since it has a big community and a lot of successful releases, though I could probably make it in MultiMedia Fusion if needed, since the graphical requirements of this design aren’t very restrictive. The tricky parts are probably going to be writing the trigger code so that it affects things in the right order, and creating a good drag/drop interface for placing all of the transmitters.

I need to put some pictures up in this piece, this is a lot of plain text to read.

Future Traffic Programmer

Here’s an idea for a game I’ve been working on for a while now.

It’s the distant future of highway traffic control. Your job as a traffic programmer is to make sure that all of the autodriver cars make it to their correct destinations without crashing. Orders are sent to cars from transmitters placed beneath the pavement in individual lanes, and the transmitters can query a car to get its current speed and destination.

Your task is to design the placement of different types of transmitters so that all of the cars can make it through safely, and as quickly, as possible.

Here are the basic commands at your disposal to affect how the cars travel:

  • Brake
  • Accelerate
  • Lane change left
  • Lane change right
  • Take left fork
  • Take right fork

Additionally, each transmitter can be fitted with a conditional to make it only work for certain cars on the road.

  • Speed (Fast, Medium, Slow)
  • Destination (Any number of futuristic destinations relevant to the area)

There is also a special type of transmitter that sends signals to other transmitters, instead of to cars. They trigger whenever a car runs over them, but can be set up with a conditional so that they only trigger when certain cars go by. Whenever it triggers, it can either turn off, turn on, or toggle another transmitter.

The trigger transmitter can be used in combination with a lane change transmitter to create a “safe merge” – set up the trigger in the destination lane, so that whenever it has a car over it, the lane change transmitter shuts off. This will prevent cars from accidentally merging into other cars.

Another thing you can do with a trigger is to split one lane into several. Place a trigger in front of a lane changer in the same lane, with the trigger set to toggle the lane changer each time a car hits it. This way every other car will change lanes. It could come in handy!

One final wrinkle is that certain types of vehicles supercede the automated highway system entirely – you won’t be able to issue commands to them, but they will still set off triggers so that the automated cars will be able to avoid them if you are a clever programmer. These autonomous vehicles will usually follow a set path or even remain in a single lane at a constant speed, so they will generally be easy to plan around.

Have fun at your new job as a future traffic programmer!

Game Explorer

In chess, there are huge depositories of games past, which can be explored using powerful tool such as’s Game Explorer. Using this web program you can play moves and see what the winning percentages are for each move that comes after it. There are over two million games in the database, all from master-level players. Many of the games in this database follow what are known as main lines – over half of those games have e4 as the starting move. For those unfamiliar with chess notation, this is moving the king’s pawn two squares forward.

What use is a chess database? For one, it makes it easy to see what your future chances may be, and how popular each line of reasoning is. Because of this, most chess-playing engines use what’s known as an opening books, a type of chess database, to improve their play during the beginning part of the game. Likewise, people playing correspondence chess often use chess databases to avoid making blunders, and to look ahead to see what their opponent (who also is using a database) might play.

If you follow through a couple of moves it’s easy to find an opening sequence that has rarely been been played before at the master level – these are known as ‘novelties’ or ‘theoretical novelties’ in chess. Many of these novelties are weak moves, but there are countless undiscovered complexities in chess, and some chess players enjoy exploring this new territory. If you play one of these novelties, computer and human player alike will have to throw away their chess database as well – since there is no more data to be drawn upon!

The corresponding idea in game design is to use a sort of novelty, innovation, or new technology to differentiate one game from another. It would be interesting to be able to locate novelties in game design, in a similar way to how they are discovered in chess. Let’s take a look at a hypothetical design database which allows people to explore different types of designs and see what other projects made similar decisions, if anyone had actually made that design decision before.

Instead of chess moves, this design database has a sequence of design decisions, starting with the most important, overarching themes of a project, with following decisions refining and polishing the overall design. A design sequence for chess could be like this, in order of importance to the game:

  1. Abstract Strategy Game
  2. Two Players
  3. Special ‘King’ piece is put in check to win the game
  4. Pieces capture the opponent’s pieces by moving into them
  5. Each piece has a different type of movement (described here)
  6. Some special moves can be made (Pawns moving 2 squares, castling, en passant, pawn promotion)
  7. Board is 8×8
  8. Pieces start out arranged in a particular manner

The order is important, since you can make changes more easily to the later items without greatly affecting how chess feels and plays. An example of this kind of change was a variant developed by Bobby Fischer some time ago in order to combat the rote memorization of opening systems in chess. The variant is known as Chess960, where the arrangement of the back rank of pieces is randomized (with some restrictions) before the game. The result is a game which plays almost exactly like chess, but places more emphasis on creativity and talent, rather than memorization and preparation.

On the other hand, you could hardly alter the earlier elements without changing the feel of the game, though depending on how they are changed it could still be considered a chess variant. Shogi has differences in 4, 5, 6, and 8, though it’s still recognizibly a type of chess – it’s also called Japanese chess.

Let’s take a look at another decision sequence:

  1. First Person Shooter
  2. One player or two players cooperatively
  3. Fighting against aliens
  4. Player has health and shields, the shields recharge
  5. Vehicles are used in combat by one or more players at a time
  6. Players can hold only two sets of weapons at a time
  7. Players can use grenades as long as their weapon only takes up one hand
  8. Special items can be found which are used to enhance the player or detract from enemies

It should be pretty apparant that this game is Halo, though you wouldn’t be able to tell which one unless someone expanded the sequence with more and more finer points. Taking the assumptions that come along with being a FPS game (running, jumping, ducking, aiming, shooting) you can get a pretty good idea what is going on in the game and how the combat plays out. Compare it to Gears of War, which has a similar design, though it is an over-the-shoulder camera, and I would probably replace the vehical combat with an item about the cover system, since that is what’s important about the combat. There are other small changes as well, regarding the weapons held, grenades, and special items – though these are farther down the list, and ultimately less important than the earlier ones.

Another interesting comparison would be the differences between checkers and chess. I’ll leave that as an exercise to the reader (because I am a jerk).

In conclusion, I think it’d be neat to have a database of games listed in this design sequence format, so you can pick one or two early (large) decisions and see what kind of games show up in the filtered list, including stats such as their critical and financial success, detractions, and links to similar games that differ in a bigger decision rather than a smaller one.

Movement Rules

I was working on puting the movement rules of various pieces in a way that there won’t need to be many specialized rules. Here’s what I came up with.

Each piece has five different basic attributes:

  • Movement points
  • Rotation points
  • Choice points
  • Range
  • Direction

Movement points are used to move the piece in the direction it is facing. You have to complete all of your moves before you rotate, I’ll go over this more later on, but allow rotations at any time during the move pretty much negates the importance of Direction for the pieces.

Rotation points allow the piece to change its direction by increments. In a square grid there are 8 directions, and a Rotation of 4 would allow the piece to do an about-face. In a hex grid there are only 6 directions, and a rotation of 3 would allow an about-face.

Choice points can be used as either movement points or rotation points. These allow for a lot more complexity inmovement without complicating the rules.

Range is how far ahead of the piece it is able to attack.

Direction shows where the piece can move and attack without using any rotation.I got the idea for this from a chess variant where each piece had a number of directional tick marks on it, and the piece could move in those directions a number of spaces equal to the number of total tick marks on it. Here’s a diagram to explain:

Piece Diagram

In the chess variant (I should try to find out what it was called), theamount of movement points (going clockwise from the Pawn) would be 1, 2, 3, and 4. The chess variant didn’t actually have a piece as strong as this Rook, but instead had a 4-directional king that could move only a single space at a time.

Anyhow, using these five basic abilities, you can create a huge number of different pieces by picking the directions the piece can face and then generating all of the combinations of movement, rotation, and choice points that you desire. A good total for these abilities seems to be three, any more and the pieces end up covering too much range. This removes a lot of the tactical considerations and makes it behavetoo much like the FF Tactics gamesthan I am comfortable with. I’ll work on uploading some example piece movement/thread diagrams to show what I’m talking about.

One important aspect of the movement and rotation points is the order they are allowed to move in. Options include movement before rotation, rotation before movement, and rotation any time during a turn. Since rotation before movement kind of simulates having a piece with more directions, I decided that the onle scheme that keeps direction and rotation their own distinct abilities is movement before rotation.

Another decision I needed to make was when to allow attacks. I am going with attacks being part of the move, and costing a movement point to perform. While this prevents the creation of pieces that can attack but not move (without special rules), I think that such pieces aren’t really that interesting, and they’re unrealistic besides – even artillery pieces can move, albeit slowly. One side effect of allowing a free attack after moving is that the standoff distance where pieces can attack on their next turn is increased. You’d end up with a game where even the weakest piece threatens two squares out, and I’d rather keep things a bit closer together. Additionally, allowing an attack after rotation greatly increases the power of even the weakest pawn-like units, since even with one rotation the pawn’s attack squares increase by 5 or more.

To illustrate how the power of a pawn (1 move, 1 rotation, 1 range, 1 direction) changes depending on the rules:

  • Free attack, can rotate before moving: Threatens 8 squares (at a range of 2)
  • Move attack, can rotate before moving: Threatens 3 squares
  • Free attack, rotates after move: Threatens 5 squares (at a range of 2)
  • Move attack, rotates after move: Threatens 1 square

The fully-powered pawn is almost as powerful as a rook in chess (which threatens up to 7 spaces horizontally and 7 vertically), and clearly this is too strong for what is supposed to be the most basic of pieces. I definitely tend to prefer the pawn to be as weak as possible – remember that once two pieces are toe to toe, they are all equal in combat. The danger of pawns is that they take some effort to put into place, and that moving them creates weaknesses in your line.

Considering all this, here is how moving a piece happens (in order):

  1. The piece may move 1 space in any of its directions.
  2. If there are any moves left, the player may repeat step 1.
  3. If there are still any moves left, the piece may attack in any of its directions. After this the piece cannot move or attack again this turn.
  4. The piece may then use its rotation points to reorient itself (even if it attacked).

Finally, here are some notes on designing pawn-like pieces with no more than 2 combined M, R, and C. As a shorthand notation, instead of saying that a piece has 1 movement, 1 rotation, and faces in one direction, I’ll write MRD^. The ‘^’ means straight up. All pieces have 1 range unless otherwise specified, ie. Ra2, Ra3, etc.

  • MRD^ is the most basic pawn piece. It threatens one square and has 5 move choices, so that after one turn it can threaten any of 6 different squares.
  • CD^ is a slower version of the basic pawn – I don’t think it’d be very useful as a combat piece though.
  • CRD^ would be better at rotation than a normal pawn.
  • MCD^ can optionally move two squares if it decides not to rotate.
  • CCD^ combines all the abilities of the above pawns. It threatens two squares, and has a variety of options when moving that allow it to react to threats easily.

Some more powerful units, without increasing the movement or rotation:

  • MRD\/ would be a much more powerful piece than MRD^, since it threatens twice as many squares, and has 8 move choices. After its turn it could threaten any of 12 different squares.
  • MRD^Ra2 threatens two squares, and has an additional 5 squares it can threaten after its move, for a total of 11 possible threats after a move. This makes it almost as powerful as MRD\/, though by being able to fire over a square, it can be quite a bit more useful when attacking.

That’s it for now.

Board Games

I started playing chess and scrabble recently, so I’ve been inspired to work on a new board game. They’re certainly a lot easier to design than video games – the constraits here are really helpful.

For one, it needs to be simple enough that someone can learn how to play the game using only a manual (and hopefully a short one),without the benefit of interactive tutorials or being part of a well-known genre like FPS that are easy to pick up after you’ve learned one.

Additionally, the entire game, all assets, rules and pieces need to fit in a single box. Imagine a board game version of golf – you could probably only fit boards for one golf course if you intend it to be big enough for someone to see clearly and play with. You wouldn’t be able to put in the number of courses that most video games have, and forget about the detail level. While 3d boards certainly do exist (Fireball Island, Mouse Trap) they are by no means easy to create, and they can be fragile as well. Most board games are restricted to pieces of cardboard and plastic.

Another constraint is that you generally want the game to be over after no more than an hour or two – less is even better! Who is going to pull out your game to play if it takes 4 hours to finish a single session?

The last constraing I could think of is that the rules can’t be too complex. There are some things that computers make very easy to do – math and formulas are so easy, that most combat formulas in computer gamesare completely hidden from the user. Some games like Civilization put it up front, but there is still so much to keep track of that it would be almost impossible to create a board game version without simplifying things like cultural influence, citizen morale, trade routes,technology, and so on.

So, here’s how my game is laid out. It’s definitely an abstract strategy game. That is, there’s no random chance, and all players have perfect information (nothing is hidden like in Stratego). Let’s call it a wargame/chess hybrid, since it’ll look like a wargame with the corresponding units living on a hex grid, and there is resource management (in a sense, there are no stockpiles to keep track of though), and there is no random chance involved in the combat.

As an example of one of the units I’ll use the simplest thing I can think of: This game’s version of a pawn.

  • A pawn takes up one space on the hex board.
  • A pawn faces in a single direction. (Other pieces can face multiple directions at once)
  • A pawn can take one of three actions during its turn. It can advance, rotate, or attack.
  • A pawn advances one space in the direction it is facing. (Other pieces can move farther)
  • A pawn rotates to face any direction.
  • A pawn can attack one space in the direction it is facing. (Pieces can attack in any direction they can move to, and some can attack at greater range)

Here’s some information about the combat.

  • All units have two combat statuses: Mobility and firepower.
  • Mobility is the ability of a piece to move and rotate. A piece is either mobile or immobile.
  • Firepower is the ability of a piece to attack. A piece is either armed or disarmed.
  • When a piece is attacked, the defending player choses which status is removed: The piece either becomes immobile or disarmed.
  • If a piece is already immobile or disarmed and it is attacked again, it becomes neutralized. It can’t move, rotate, or attack.
  • If a piece is already neutralized and it is attacked again, it becomes annihilated and removed from the board.
  • Pieces can be healed after they are neutralized or otherwise harmed. Annihilated pieces cannot ever come back!

Here’s a quick flowchart, the number is how many attacks it has to sustain:

Healthy -1-> (Immobile/Disarmed) -1-> Neutralized -1-> Annihilated

I’ll be working on this a while, and I’ve already thought of some changes while I was writing this, so there will be some new stuff later on.

TOB – First Prototype

Here’s some stuff I gotta do.

  1. Visual Studio set up
  2. Sprite loading
  3. Sprite animation
  4. Animation description format (txt)
  5. Animation loading
  6. Level displaying (tiles)
  7. Tile description format (txt)
  8. Level description format (txt)
  9. Level loading
  10. Level editor (basic)
  11. Controller movement
  12. Collide with level tiles
  13. Run
  14. Jump

The tile description format will have a list of the tiles and their component .png files, which will then be referenced in the level description format so that it can be enumerated simply.

The format might look like so (tiles with multiple frames are for a fancy-tile format that I made up):

TileName   Frames  “path.png”
BrickTiles   9 “tiles/bricks-9-3-3.png”
SmallPlant  1 “tiles/smallplant.png”

The level might look like this:
Tiles “tiles/tiles.txt”
. Background
b BrickTiles
p SmallPlant
Level 30 20

The animation format will probably look something like this:

Idle    frames 0    0     loop 0    // Loops infinite times
Walk  frames 10   19   loop 0    // Loops infinite times
Stun  frames 20   24   loop 1    // Runs once then stops
Stand frames 25  29   loop 1    // Runs once then stops

The level editor will also need a sort of collision hull editor and way to edit the non-architecture layers, including gameplay cues and monster drops, and so on.

Thoughts on Game Development