rbwhitaker / indy-500 Goto Github PK

We need some maps to use in the game. The structure of the map, ultimately, will come out of #1, but the importing logic needs to be defined as a part of this issue, and one or more maps need to be created.

Whoever does this work can do whatever they want, but I can imagine just building our own really simple text-based format. Maybe something like:

Easy Track // First line is the title
24x40      // The size
X,10,True  // Defines a character used in the map, the max speed, and whether crossing into it should result in stopping
.,1,False
           // Blank line to separate metadata from map data
XXXXXX     // The map contents itself
X....X     // This one isn't sized right and should actually probably fail to load.
X.XX.X
X.XX.X
X....X
XXXXXX

If a player is telling their vehicle to move forward, then it should accelerate. This doesn't have to account for turning or crashing into walls or anything. Just go!

This probably also requires allowing resizing the window.

It would be good if the rendering component of the game could support any size window and any size map.

The track is 24x40 in the original game. That's a reasonable default, but we want to allow for boards of other sizes too.

• Grid-based thing to represent the squares on the board.
• The ability to represent different types of terrain (asphalt, dirt, ice, etc.)
• Each terrain type needs metadata about things like drag and/or top speed, whether crossing into it brings you to a standstill, and possibly more (color?).
• Some way to define the start/finish line, but perhaps other lines as well. For example, it might end up making sense to have each track have several lines that cross the track (only one of which is visible) and we track crossing each of several lines around the loop to ensure the player is actually going around the loop. These lines might also serve as a way to help the AI know how to make its way around the track, because it can navigate these instead of having to do freespace planning.

In the past with these collabs, we often don't get a full UI and menu system built. That's typically lower priority than the actual game mechanics.

In these cases, it is nice to be able to have the game's configuration definable in a config file (JSON or YML or even XML or our own key-value pair or entity-attribute-value format, as long as it is easy to parse). This can be useful for changing what mode of the game to run without having to build the full UI to configure it. Instead of building a UI, you close the program, edit the config, and launch it again.

Whoever does this work should feel free to pick any of the above, or anything else that you like. (If you're doing something crazy, bring it up for discussion.)

But we could do something like:

[Window]
FullScreen=True
Width=1920
Height=1080

[Debug]
Enabled=True

[GamePlay]
Mode=Race
Laps=5
Map=Basic

We'd add new properties as we build the functionality.

I don't know what this looks like, but maybe there's a way to do mouse input. It might be worth a try to come up with a workable scheme if somebody is interested.

This is the first step in a simple menu system. The game should launch in the main menu, and then when the player starts a game, it should transition to the game. And that is it right now.

We need to define the basic properties of a player's car, including things like:

• position
• heading angle
• speed
• size

If somebody has an Xbox controller that they want to try to implement a control scheme for, they should do it!

Builds on #4.

The vehicle can turn based on the rate that the player is turning it.

This doesn't have to worry about collision detection with anything.

The goal is to get around the track a set number of times. You win if you're first to do that.

Some fancy graphics would be nice.

We need to define an IPlayer that captures how a player interacts with the game. This can then be implemented by an AI player, a keyboard player, a mouse player, a gamepad player, a networked player, etc.

This probably needs to give the player a chance to see the game time and the current state of the game (including positions of all vehicles and their speeds, etc.) and have it provide back to the game their instructions (rate of acceleration, brake (?), rate of turning).

This should probably be broken down into smaller pieces. But some places where a few particle effects might go a long way:

• Crashing
• Driving in dirt
• Hitting the target
• Marking the "It" player
• Finishing a lap

We need to be able to draw the basic game board and the cars where they are at.

In the original game, when you go off the screen, you wrap around. We should do this too.

You could easily add in new types of cars to choose from that have different turning rates, different acceleration rates (even for different terrain types), and different multipliers on max speeds.

We'd probably want to also visually distinguish these types from each other.

A target generates randomly. First player to touch it gets a point. First to N points wins.

I feel like the modes in the original game are a good start (and I haven't listed the ice rally yet) but designing additional modes would be a cool thing to have as well.
Some of these might demand other properties on the track, the vehicles, etc. We can do that if there's an interesting game mode that we want to do.

It might be fun to allow for more than 2 players. 4 shouldn't be too hard. If we're doing networking, 8 or even 16 might be possible... (Maybe we need other modes for this and other maps.)

When you're not "It", you collect points over time. When you're "It" you have to try to crash into the other player. Doing so will make them "It" and you start collecting the points.

(If we're allowing more than two people, we might need to reverse this a little, so that the person who is "It" is being chased by the masses, so that only one person is accumulating points at a time.)

Builds on #5.

If you cross a boundary, you should come to a stop.

Being able to play this game across the network would be fun. (It's probably not my personal top priority, but if somebody wanted to even spend the entirety of their time doing this, they should do it!)

If somebody does this, they can feel free to tackle it anyway they want, but I might suggest the following:

• We make an interface for the game state.
• A networked client (not the host of the game) has a proxy object that implements the interface.
• The client's proxy gets updates from the server (I'd suggest serialize some message or state object to JSON (lots of things know how to serialize and deserialize this) and updates its state as a proxy.
• The input from the client gets sent back to the server, which sees it as a "NetworkPlayer" that implements IPlayer like the xbox controller, keyboard, and AI players.
• I'd suggest using UDP with a sequence number as a part of the message. If a packet gets lost, well then good riddance. We don't need reliable delivery. We'll send the next packet. But the sequence number ensures that if a packet shows up late, we can ignore it.

Maybe somebody wants to do a camera that tracks the vehicle (how do you do this when the game wraps around? It's doable, but not trivial) and then do split screen for N players. Given the way you steer the vehicles (relative, rather than absolute--but now that I think about it, that might be a good way to build the input scheme) it might be easier with a camera that tracks the player's position and heading.

This might be the easiest one to implement, and while we're developing, we're all going to have a keyboard. Left/right for go and space for accelerate? Or anything else. (Also maybe allow for keyboard mapping in the config as a separate thing.)

We need some sound effects for the motors. It would be especially cool if this could change pitch based on speed (and gear?!).