Projects I Won’t Finish A Game Development Log

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.