This text is displayed if your browser does not support HTML5 Canvas. This text is displayed if your browser does not support HTML5 Canvas. This text is displayed if your browser does not support HTML5 Canvas. This text is displayed if your browser does not support HTML5 Canvas.

Rally Spaceway (Alpha, 33.h)


Try these game styles:
Rallye Speedway (Track1),
(test) test2 test3 test4
Lunar Lander (Track1),(Track2),(Track3)
Skramble (Track1)
Jump&Run (Track1)

other games Rallye Speedway, but in Space.
circles=good | squares=neutral | triangles=bad
thrust strength is based on distance of click (seen from centre)
thrust direction is based on where you click (seen from centre)
click to shoot, keep pressed to keep the thrust.

Development scratchbook

DONE player bullets (game objects) only shoot when click, fire in direction of looking
DONE player bullets kill (some) enemies. Maybe have hollow triangles for shootable enemies
DONE checkpoints (map objects)
DONE bullets travel over flats, held up by towers
DONE shootable terrain?
to do: Timer
plan: scoring somehow taking into account time, remaining fuel, tokens collected
on halt: energy level
DONE number of lives
DONE: restart without full reload.
partly done: using more of screen, menu/display
plan: in-game editor and/or way of incorporating text files
FIXED: could circumvent one-way and crossing tiles

DONE (but probably not optimal) Biggest issue is correct tiling and allowing the playing field (and the star layer) to wrap around.
might be better to use a drawing function for the stars. Maybe just randomly make a few white dots wherever you go?

DONE could even introduce two star layers at different speeds. or a baselayer (milky way-like) that doesn't move

DONE The angle between the centred player and the mouse pointer/touch is the thrust direction.

DONE navigate along a 2D racecourse. the playing field is generated from an ASCII map of the course, similar to the course editor in Rallye Speedway.

DONE: The player ship stays in the middle but rotates so that it points the current movement direction (or is circular, not sure yet (circle with arrow inside?)), the thrust indicator points in direction of the thrust, obviously. Actually, that is not obvious. One could argue the inner arrow should be pointing its trajectory or be its centerline. But do we need that? just leave it a circle.
Still debating returning to time delay for angle. The rotation happens instantaneously, but for acceleration/deceleration I have implemented a PT1 behaviour effectively. I feel with instant rotation, an indicator is not really needed, but that is easy to change back.

DONE: The magnitude of the thrust is based on distance between touchpoint and spaceship.
future idea: give extra (style) points for drifting, when the Schwimmwinkel is beyond a certain value.

DONE: Tracks format could be ASCII based, 0 = track and then 1...9 are levels of drag, colour coded. level 8 could be stopping the ship and level 9 destroying it? Letters could refer to obstacles and decorative objects.
Should have at least two tracks to start: Track01 (from the original Rallye Speedway) and "Nordschlyfe".

DONE (and expanded upon): Each character refers to a tile of a certain size, say 150% of the ship diameter? That will have to be tested. Diagonals will have sqrt(2) the width. Probably okay to live with.
Depending on the visible area of the map, only the used tiles are drawn. (this does not to work yet)
This is basically DONE but I don't know if the way it is being done is CPU efficient.

REJECTED: It would be cool to have png tiles that are then combined into one big map via php. (but we'll go with a more abstract style at first.)
apparently that can be done with JS and canvas:

var img=document.createElement("img");

Alternative way to do animations and use GPU?
REMOVED better idea to leave gamemap in numbers, otherwise needs to be string/char and conversion. Hm. Starting place could be 10+X and its colour derived from X. This will need some more thoughts as to what is the best approach. Problem with that is that the gamemap no longer aligns on screen. maybe second map with special things. Or just a starting position. or could dedicate some of the 10 digits to special things like the single file traffic of the original.

DONE converted to string now, makes drawing easy, then convert to number and decode when drawing. To do:

DONE death when touch

DONE must touch
REMOVED (for now) -death when touch too fast
DONE narrows
DONE Reflection: different bounce level

removed: smartphone input through tilting the device? Otherwise touch obscures the screen when going up-ish. DONE: have second square area which is the touchpad, so that touching finger does not obscure the view.

DONE: collision detection (and detection of friction underneath) is based on centre location
(except narrows)

DONE: can we build "towers" onto tiles by having rectangles with shadows?
Cool browser games:

"new" games:
DONE: Rally Spaceway / Moonlander (death if touch wall), gravity / Skramble (sidescroll, death when touch, high friction),

pushed back for now: space invaders (constrained to ground, enemies come from top) the basic game would work okay, but would need new enemies or at least new movement plus lots of specific stuff to make it fun
pushed back for now: constrain to ground with up = jump could be a cool jump'n'run style game (keyboard control?) - this is a nightmare for motion sickness. jump and run does not work with a fixed player and a moving world. Would be cool to revisit this later with a branch of the engine

Game and map items:
DONE Start point (set with variable)
REMOVED start direction (variable)
DONE max token number (counted from map)
DONE min token number (variable)
DONE narrows (+) - collision difficult, suggest forcing narrow x y corridor for passing
unsure: damage per second and heal per second
DONE hiding from bullets and enemies (a tile that can be flown into by player but not enemies or bullets)
DONE one way system (><^v in map)
DONE fuel
DONE enemies
DONE shooting enemies (for skramble et al)
DONEx3 pick up bullets, depleting bullets, bullet stripper?
slow down on the two tiles without "tower", more holes = less slow down.

fixed? BUG: when grinding against a wall, it is possible to slide past token and death, but not other blocks?!
fixed? BUG: can get stuck on outside corner
fixed? BUG: various tunneling bugs

issue resolved?: inconsistent player/bullet speed depending on game display/map/scale size?
Player speed is currently scaled so that using a smaller tilescale, the speed in tiles/second stays the same. However, bullet speed is set in bulletspeed=pixels/second, because speed is defined as DX and DY. this need to be adjusted. While we can argue that within one gametype, we will always display the same number of tiles per playing field area, different devices will have different resolution. fixed: in Skramble it is possible to "park" the player despite constant gravity?
fixed: bulets broken in skramble
bug: monster projectiles chase you but get reset to a wrong coordinate when the world wraps around and then catch up with you again
idea: make player projectiles reflect on reflect tiles?
change: skramble is not a real side scroller - I think we need a better way for this than gravity. in a scroller, the speed is the same, but we can change where on the screen the player is. This is not easily done with the current engine I think? This is a similar problem as with jump and run, where we need to move both the background and the player.
bug: keyboard flying in mobile mode gets player stuck in junction (for example track 0)
bug: above also happens with touchscreen
bug: speed is wrong in mobile mode - just a scaling thing or due to the mode?