Reference no: EM133116894

Task Description

You will build a "road-crossing" game. We provide some examples to guide you but you may be creative within the restrictions we describe here.

Note: the attached videos are an important part of the description and this page may receive updates to clarify certain points up to 2 weeks before the due date. Nothing will change, but things may get clarified.

Is our demonstration of the concepts described here. You are encouraged to create your own graphical style or even to repurpose the mechanics in a new context. You should submit just one program with as many features as you can get done. We provide a demo at the bottom of this page.

Features Required

We have listed the features you should implement each week by which you will have learned the material to tackle this feature. Note that you do NOT have to submit your work every week. Only two submissions are there - checkpoint and final submission. See unit schedule for exact dates.

The display window in the program you submit must be 1200 pixels wide and 400 pixels high. All subsequent tasks must be done in a scalable manner, using width and height instead of the actual value those system variables hold, so that the program would work even if the display window size was changed from 1200x400 to, say, 900x600.

Vehicle Design:

You should have a solid horizontal line at y = height/4. This will be refined down the track. More information as we go along in the session. You can't just have an ellipse or rectangle for a vehicle. You should have a nicer design to resemble a car/ truck/ bicycle/ motorcycle, etc. As a guide, you should have at least four to five elements in the vehicle that collectively represent it clearly.

Also, Instead of a vehicle, it can also be some other alternative character, like monsters, space invader characters, asteroids, etc.

There must be a vehicle on the top left of the display window above the solid horizontal line, such that no part of the vehicle is outside the display window, or below the horizontal line.

Instead of using fixed values (like 50, 80, ...), we strongly suggest you use relative values (like height/4, width/8, ...) otherwise refactoring code after subsequent weeks' work is added will be, well, painful.

Note: You can not use images (i.e. Plmage, sprites, png, jpg, gif) for your player. They must be made from Processing shapes (ellipse, circle, square, triangle, arc, etc).

Movement: Week 3
The vehicle should move from the left of the display window to the right and eventually off the screen.

Reset: Week 4
Once the vehicle is completely off the screen, it should "reset". That is, go back to somewhere to the left of the screen. This location should be reasonable so that within the next second or so, it comes back from the left and starts moving to the right of the display window.

Pedestrian: Week 4
A pedestrian should be displayed right down the middle at the bottom of the screen, such that no part of the pedestrian is outside the screen. Again, you can only use Processing shapes and no images.

Move pedestrian: Week 4
The pedestrian should go up, down, left or right when corresponding keys are pressed. Each time it should move by the height of the lane.

Collision-Detection: Week 5
If the vehicle hits the pedestrian (and this should be reasonably accurate), the pedestrian dies (oh no!) and the game ends. A Game Over screen should be displayed and no further events (keys or mouse) should result in any change.

Lanes: Week 6
The solid horizontal line at y = height/4 from week 2 should be replaced with a dashed line.

Scoring: Week 7
Each time the pedestrian successfully crosses the lane (goes above the display window), the score should increase by 1 and get displayed on the bottom right corner of the screen.