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 chess.com'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:
- Abstract Strategy Game
- Two Players
- Special 'King' piece is put in check to win the game
- Pieces capture the opponent's pieces by moving into them
- Each piece has a different type of movement (described here)
- Some special moves can be made (Pawns moving 2 squares, castling, en passant, pawn promotion)
- Board is 8x8
- 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:
- First Person Shooter
- One player or two players cooperatively
- Fighting against aliens
- Player has health and shields, the shields recharge
- Vehicles are used in combat by one or more players at a time
- Players can hold only two sets of weapons at a time
- Players can use grenades as long as their weapon only takes up one hand
- 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:
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):
- The piece may move 1 space in any of its directions.
- If there are any moves left, the player may repeat step 1.
- 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.
- 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.
Visual Studio set upSprite loadingSprite animation- Animation description format (txt)
- Animation loading
- Level displaying (tiles)
- Tile description format (txt)
- Level description format (txt)
- Level loading
- Level editor (basic)
- Controller movement
- Collide with level tiles
- Run
- 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.
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.
Visual Studio Setup
The Platform SDK is always useful to have.
And here is the DXFramework.
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.
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.
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:
