Worklog for Foppy
BattletrackReturn to Worklogs
| Battletrack is finished!|
I have uploaded a version to Kongregate so people can compete for a high score. You need to be logged in to your Kongregate account for the scores to be submitted.
Battletrack on Kongregate
It can also be played on my homepage:
And last but not least I have submitted the game to the Monkeycoder website!
Battletrack on Monkeycoder
- game over when player car wrecked
- music on title screen
- option to turn music on/off with M key
- text on instructions screen
- text on scoring screen
- score: points for crippling car, destroying car
- score: bonus points for completing game
- picture of track on next race screen (small pictures of past and future tracks next to it)
- local hi-score
- using fixed (non-alpha) bitmaps for hud backgrounds
I made a short piece of music for the title screen using Fruity Loops. Now what is needed is another song for the next race screen, and one or more tunes for during the race. These will be played with lower volume. There will also be some atmospheric sound effects during the race, and effects for crashes, firing, hits etc. Once I have the music and sound and Kongregate score submission working, the game is complete!
| Graphics for the four tracks the game has are now finished:|
(Click to view full size)
- player has to end at a certain minimum finish position to continue to next race
- minimum finish position displayed next to current position
- picked lap count so each race takes about same time
- informative text on next race screen: race number, lap count, minimum finish position to continue
- informative text on race-over screen: end grid, red line under minimum finish position, current score
- score: points for shooting car
- score: points for each lap depending on position
- score: points for completing race depending on position
- displaying score during game
- dark background for in-game information
The dark background for the in-game HUD is currently implemented as a transparent black rectangle, drawn over the track graphics, but now that the track graphics are finished I plan to replace this with a non-transparent image that is constructed from a screenshot of the current implementation. That will then also contain the non-dynamic part of the HUD, words such as LAP and POS which are currently drawn separately.
- cpu drivers now use gun
- better finish position results in better start position in next race
- point out player car at start
- point out car behind and in car front each time player passes finish line
- car has smoke trail when first energy bar almost gone
- car has fire trail when second energy bar almost gone
- finished cars disappear
- buttons on title screen: start, instructions, scoring
- scenes from game as background images on menu screens
CPU drivers using gun: They will fire random length salvos after random time intervals. The car that is behind the player (in terms of race position) will use shorter intervals, and thus fire more often, to make it more difficult for the player! There is no defense against bullets other than avoiding them. Each car gets a fixed number of bullets at the start of the race, there is no reloading. Guns can only be used after the first lap.
Pointing out car in front and behind: A green circle and a red circle will be drawn for a short moment under the cars that are one position ahead and one position behind the player, respectively. I was thinking about having each car's race position be drawn next to it when it passes the finish line, but this red/green approach is simpler and works, as it quickly shows the player which enemy cars are important.
Two energy bars: If the first energy bar is gone, the car can still continue but at a slightly lower speed. If this happens and you still have to complete several laps, chances are you will be overtaken. When the second bar is also depleted, the car is destroyed. For the player this means game-over. The smoke and fire effects are added so that the player can see which cars are close to being crippled or destroyed.
I am working on a 4th "theme" which is "forest/jungle" and currently looks like this. The track layout is to be changed. There will also be more trees and other plants in the finished theme.
- cars may swerve when hit by gun
- explosions (flashes) for collisions
- sparks for scraping collisions
- gun flash
- display energy
- display remaining bullets
- slippery oil from damaged cars
- oil track
I added a particle class for the flashes and sparks. The oil spots use a separate class. They have their own list because I need to do collision detection between the cars and the oil spots, and having them in a separate list makes that more efficient. The oil tracks are again normal particles.
A new video, not yet containing oil effects and displays:
W.I.P. video 2
- basic versions of menu screens: title screen, next race, race finished, game over, game completed
- changed grid size from 10 to 8 cars
- more space between cars at start
- start race sound (beep beep beep BEEP)
- 3 different tracks now, I think I will make 5 in total
- collisions with walls are now of 3 types:
1) Scraping; no loss of speed; sparks will fly
2) Between scraping and frontal; some loss of speed, small explosion
3) Frontal; all speed gone, backward impact, bigger explosion
- player has gun (next step is to also let cpu cars use gun)
- cars lose energy and slow down when hit by gun
- all energy gone: car turns into wreck
The sparks and explosion effects still have to be added. Driving into the wall will also cost energy.
Below is a picture of the "stadium" track, I think I will change the green color. In this picture I have just destroyed two cars, turning them into wrecks. In the final game it will not be so easy. The cars will have fewer bullets and at the same time they will have more energy. It should all be balanced so that at the end of an average race there may be a few wrecks on the road.
- more colorful tiles
- edges on wall tiles
- more car graphics
- counting laps
- position in race
- upper limit on delta time
- using mean delta time factor
Counting laps: When a car enters or leaves the starting tile (the one that has a finish line drawn on it) the program checks from which direction the car was coming. When traveling in the correct direction, a lap is added, but not when the player has been "cheating": When traveling in the opposite direction, this would amount to "cheating", and a negative lap is counted. When the finish line is crossed in the correct direction, if any negative laps were counted previously, these are counted down first, before a positive lap is again added.
Position: The cars are in a custom made linked list so I can easily change their positions in that list. On every logic update, the progress each car has made is compared to the progress of the previous car in the list. If the current car is further on in the race, their positions in the list are swapped. The end result is a list in which the cars are sorted on their progress. (Progress = laps done + how far they are in the current lap, counted in tiles.) Now I go through this list one more time to assign actual position numbers, starting at 1.
Delta time: The game uses delta time, and I noticed that visiting another tab in the browser and then returning to the game would cause a leap forward in time, sending cars outside of the game etc. This was solved by putting an upper limit on the time measured for the current frame. I also noticed that HTML5 animation would be a bit sluggish. This was solved (it seems) by using the mean of the previous and new delta time factor, so it is smoothed out a bit.
| I made a little video:|
W.I.P. video 1
It shows the AI steering mechanism as well as the edges of the track that I'm working on. These graphics will be replaced with some that look a bit better and have more colors.
I started this new racing game in Monkey, called Battletrack, to avoid getting bored with my other game. It's a 2D single screen top-down racing game in the style of Super Sprint and Badlands. At the moment it can display a tile-based track on which human and computer controlled cars drive around.
The tracks are stored in the game as strings. Each character in the string indicates where to go next from the current location while constructing the track. This is an example:
Local route:String = "rrrddrrrddddllluullllddllluuuuuurrr"
Starting from position 5,2 on the screen, the track goes right, right, right, down, down, right, right, right, etc. The result is this track:
Every tile that is not part of the road is a solid wall, so cars can't leave the track.
The driver can steer, and apply throttle and brake. The game keeps track of direction a car is "looking". It also keeps track of the direction a car is actually moving. The moving direction is changed towards the looking direction at a rate that is dependent of the car's speed. This means you get a low-grip effect when moving fast.
Computer drivers AI
I made a game like this in Director (Shockwave) once (called Vredestein Racer, it's still on a number of game sites), where I had a mode in which I would drive around the track and have waypoints recorded. The AI would follow those waypoints. The advantage of this approach is that you get a smooth racing line. However this is a lot of work. In Battletracks I decided to make the AI able to drive around any track. This is made possible also by the use of tiles instead of a more free layout. Every tile has the track direction encoded into it (using the information from the track configuration string above).
As the AI cars approach a corner, they first aim for the outside of the corner. As they get nearer to the corner, the point at which they are aiming will move slowly towards the inside of the corner, also based on the car's speed. As soon as they drive onto the corner tile, they will do a quick search along the track towards the next corner tile, which will be their next target. They also adjust their speed, braking if necessary, as they approach each corner. Another reason for braking is a large difference between the current direction and the target direction. In other words, if they miss the mark and have to steer very sharply, they will also brake. The lower speed will make it possible to steer sharply. The end result is a car that drives around the track fairly naturally.
Car to car collisions
In car to car collisions, the game first checks the distance between two cars. If this is smaller than the sum of their diameters divided by two, the cars collide. Then it compares the angles at which the cars are driving. If the difference is greater than 90 degrees, this is considered a "frontal" collision. Both cars lose most of their speed and an impact is applied to both of them, so they typically bounce back from each other. If the collision is not frontal, the car driving into the other car loses a little bit of its speed. The other cars receives an impact. So this is like when a car bumps into another car from the rear. The end result is not an advanced physics engine but it is usable in this game.
|Blitz BASIC Founders Fund|