zpchavez / lvv Goto Github PK

Create a base car class that can be extended for cars of different shapes and sizes.

Create a static and/or dynamic obstacle that has a collision body defined by a polygon, rather than a simple circle or rectangle.

I've been thinking about how to enforce driving on the track. Here's what I've come up with.

1. Create a track marker object. Track markers will be non-physical objects that mark the center of the track.
2. Track markers will normally be invisible, but in the demo they will appear as red dots that turn green as you drive past them.
3. In addition to a coordinate location, markers have a direction associated with them (probably just up/down/left/right is sufficient).
4. Markers only activate if a player's car has gone from being on one side of the marker to the side of its defined direction.
5. Markers have a range at which they can be activated. After driving too far off the track, they will no longer be activated.
6. Markers have a prescribed order in which they are meant to be activated.
7. Markers may be skipped, but a maximum may be defined for how many markers may be skipped.
8. If too many markers are skipped, the car is eliminated (in the demo the car might be returned to the last marker it legitimately activated).
9. The start/finish line marker is a special kind of marker. When driven past in the opposite direction, the game enters a state in which markers will not be activated It needs to somehow block markers behind it from being activated at the start of the race, even if the player immediately heads in reverse (so no winning the race by driving back and forth over the finish line). When the player has activated most of the track's markers and passes the finish, all markers reset and the lap counter increments.
10. The demo will feature a simple rectangular "track". When a lap is completed, the markers will turn red again and a lap counter will increment.

As a reminder, here's how MM works.

First to 8 wins, or leader after 3 laps. If there's a tie, additional players are eliminated and sudden death starts.

2-player (or team)

Both players start at 4 points. Winner gains a point and loser loses a point.

3-player

1st place gets 2 points,
2nd place gets 0 points
3rd place loses 2 points

4-player

1st place gains 2 points
2nd place gains 1 point
3rd place loses 1 point
4th place loses 2 points

Autocorrection

It's difficult to straighten out again after turning. When you've stopped turning, the car should snap to the nearest, say, 15 degrees.

Realism

It's currently possible to spin in a circle without otherwise moving, which makes no sense. Rotation should only be applied when velocity is not zero.

I'm thinking of doing:

• A comb
• A razor
• Floss
• An open bottle of pills on its side
• Dynamic pills
• A box of something

Everyone disappears and no winner is declared

Maybe we should make the game dimensions a wide-screen ratio so that fullscreen really is fullscreen?

Some tiles represent cliffs. When driven over, the player should return to the last track marker. Scaling can be used to animate the car falling. See this and this for examples.

Image layers placed in the Tiled editor will appear in the game.

Everything that can be set in the track loader form should be settable in query params.

I noted some weirdness with free-for-all scoring. Sometimes the winner will lose points instead of gaining them. Once it said "BLUE WINS!" even though red had filled their points bar. Both of these examples occurred in four-player games.

This could be useful for tracks that use an image layer as the background. The polyline tool in particular could be used to outline parts of the track that should act as obstacles.

I'm thinking we could use full tubes of toothpaste for jumps. I'd like implement some way that you can enter the tube at the lowest point, and from there you can drive off the sides or jump off the end, but approaching from the sides or the end results in a collision.

Update the current car-driving example to include some stuff to run into. Let's start with just circles and squares.

I want to make an obstacle that looks like a spilled hand soap bottle, and then have various shapes and size of spots of spilled soap that serve the same purpose as the "rough" terrain.

I'd like to create a json object shape that we can use to define different level layouts. Here's a rough idea of what I think it could look like to start:

{
    playerStartLocations : [[250, 200], [350, 200]...],
    obstacles : [
        {
            type: 'DynamicObstacle::ClownNose',
            x : 50,
            y : 150,
            rotation : 45
        }
    ]
}

We'll need to expand on it as we add more features (e.g., race markers, more interesting backgrounds).

I'm thinking that obstacle types can be defined by stating a key that corresponds to the factory, and then that factory's key for that object type, delimited by something like ::

Implement a type of tile that limits speed when driven over

Create a new game state that demos multiple cars (at least two, ideally four), each of which can be controlled using separate gamepads.

Phaser throws out a lot of data when loading tilemaps. Additionally, tilemaps contain data that would be useful to having during State.preload(). We can avoid needing to duplicate information from tilemaps that is either not imported, or is imported too late, by including them as modules instead of having Phaser load them via XHR.

I've done this on my branch for #17. Works really well.

The small jumps created by the Q-tip obstacle #51 are hardly noticeable. I'd like to try adding and/or replacing the current scaling effect with some kind of translation effect and maybe add some kind of shadow.

Some tiles represent ramps. When driven over, the sprite should be scaled up in size to simulate being in the air. While in the air, the player is immune to cliff tiles (#17). Handling should also be different while in the air: turning, accelerating, and breaking should not be possible. Air time should be correlated with the speed of the car while crossing the edge of the ramp tile.

Allowing the player to jump over obstacles may be difficult because of the question of what to do if the player lands while still over the obstacle. If I remember right, it seems like MM never placed ramps in places where this might happen. We could just do the same.

Implement a type of tile (e.g. oil or ice) that reduces friction when driven over.

Create an obstacle factory class and three obstacle classes, one each for the dynamic boxes, static boxes and the giant clown nose.

We may want to look into this alternative tilemap implementation that is supposed to have better performance.

It also features an easy way to turn map objects into p2 physics bodies.

https://github.com/englercj/phaser-tiled

Although the goal is procedurally generated tracks, I think it will be very difficult to generate them completely from scratch. Instead, how I picture it working is that tracks will be composed of shuffled tiles, with each tile being human-designed to interlock with other tiles. The simplest map could just to two halves, with multiple possible left-tiles and multiple possible right-tiles. Perhaps obstacles can be generated in a separate process that is more from-scratch, adding to the possible combinations substantially.

This issue will be the first step towards accomplishing this. It will include:

• Two new options will be added to the menu, Track Editor and Track Loader
• Track Editor brings up an interface similar to this example but with some sort of tile selector.
• The editor will also allow the placement of track markers and the finish line.
• The initially displayed map will just be dirt.
• There will be a save button that will be disabled until a finish line and at least one track marker are placed.
• There will some sort of tile option that can be used to delineate the track. Maybe some sort of pebble, if keeping with the dirt theme. I don't know what it could be for the bathroom theme. Based on how well the toothbrush obstacle turned out, I'm going to leave this up to you.
• When the save button is clicked, a download will be generated in the form of a data URL.
• The file will need to be saved to assets\tracks, and since the browser can't read the file system, the new track will need to be manually added to assets\tracks.js.
• The saved track can then be loaded from the track loader and driven around.
• Track markers should be updated so that they are invisible, unless enableDebug is called on the Track object.

In this initial feature, there will be no tiles or randomizing. No obstacles either, for now. Thoughts?

I want the Q-tip obstacles to delineate the track, and for them to be such that you can drive over them, but it does slow you down to be driving over them all the time. My first thought is to have you jump if you hit them fast enough, or slow down otherwise. I think I'll try implementing that and see how it feels.