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.

Posted in Board and Card Games | Tagged , | Leave a comment

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.

Posted in Board and Card Games | Tagged , , | Leave a comment

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
EndTiles
Level 30 20
……………
….p…..p…
…bbbbbbb
EndLevel
etc

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.

Posted in Game Dev, Programming | Tagged , , , | Leave a comment

Delays

I found a copy of Visual Studio 2003 on my desktop, which might help me to actually get some work done. However, I should probably buy the damned program already and install it on my laptop, to facilitate development. Actual motivation is out the window!

At this rate I might have something programmed by 2009.

Posted in Game Dev | Tagged | Leave a comment

Visual Studio Setup

The Platform SDK is always useful to have.

And here is the DXFramework.

Posted in Programming | Tagged | Leave a comment

Java Ass-Kicking

I think I’m going to try to develop Grocery Panic on a different platform, since Java for cell phones is giving me a lot of trouble. C# or C++ it is. I’m going to do some research and prototyping tomorrow, as long as Rock Band doesn’t lure me away.

Posted in Programming | Tagged | Leave a comment

Design Documents

I spent some time today working on a design document, the fruits of which you can see here: Grocery Panic.doc

Excerpt:

The X
Don’t put the cans on top of the eggs.

Summary
Foodstuffs are falling into a paper bag from an ever-rotating conveyor belt of edible goods. Your job is to pack the bag without destroying anything. Certain items are fragile, and must be placed very carefully. The less empty space left, the better. Each bag will be more difficult to pack than the last!

Conveyor Belt
The conveyor belt carries items before they are dropped into the pit. The conveyor belt starts off the right edge of the screen and ends at the top-center of the playing field.

At regular intervals determined by the conveyor belt speed, new items are added to the conveyor belt from the right side of the screen. They should move along the conveyor belt until they reach the end, where they stack up awaiting use by the player. Stacked items occasionally jiggle, to represent how agitated they are.

Whenever an item is placed, the next one is immediately picked off of the conveyor belt and placed at the very top-center top of the playing field, even if that item was not already at the end of the conveyor belt.

When the conveyor belt is filled with stacked items, they will blink red, and if another item is added, they all fall off into the pit, which will cause many things to be crushed by accidental poor placement. This may cost a player the game.

Posted in Game Dev, Grocery Panic | Tagged , , | Leave a comment

Grocery Panic Development, Pt. 1

Panic!

Just starting work on a recent idea: Don’t put the cans on top of the bread. That’s the gameplay behind this simple tetris-clone where you pack groceries into a paper bag. Each item has a weight, strength, and shape (flavor? price?). If you put an item on another item, if the weight is greater than the other item’s strength, the weak item is squished.

Examples:

Watermelon – 4 Strength, 4 Weight
Can O’ Soup – 4 Strength, 3 Weight
Cereal – 3 Strength, 2 Weight
Eggs - 2 Strength, 2 Weight
Banana - (Tastes delicious and has an odd shape) 2 Strength, 2 Weight
Bread – 1 Strength, 1 Weight

You can put a can on a cereal box, and a cereal box on a can. You can put a box on some eggs, but not on bread. If you put a watermelon on a loaf of bread you are a fool. The groceries will come down off of a conveyor belt, and you move and rotate them in the style of Tetris. Once the bag is full, you get points for each item in the bag, demerits for holes in the middle, and NO TIPS whatsoever. This is a union store, buddy.

That’s it for now, here are some pieces of art that I didn’t crop:

Posted in Game Dev, Grocery Panic | Tagged , , , , | 1 Comment