The Pacman Project: Keyboard control with constraints
This project is what you get when you combine:
- Keyboard control
- Using jQuery and animation
- Object constructors with methods and properties
- Complex data structures to hold map data
- Navigation with arrays
In addition to the user interface from your last assignment, use complex data structures, keyboard control, animation, and object constructors to allow the user to navigate the maze, without allowing the user to go through walls.
- Your motion code and constraint checking should be inside the Ms. Pacman object constructor.
- You will need to create your mazeObject and Ms. Pacman objects globally so they can be seen by all your functions.
- In order to separate your processing from your output, you will have to make intermediate methods to your Ms. Pacman object. For example, a keystroke may trigger msPacman.tryToMoveUp(). msPacman.tryToMoveUp() would then check to see if it is clear to move up one cell, and then call msPacman.animateUp() afterwards. Keeping msPacman.tryToMoveUp() separate from msPacman.animateUp() will help you program game play in the next assignment.
- There is an error in the hallWall code. See if you can fix it. (Automatic points to people who create their own map arrays.)
- There are tunnels on the left sides of the map. Make your code allow wrap-around movement so that moving off the edge of the map teleports you to the other side.
Have I mentioned lately that
console.log()commands help you debug your code a lot? Just sayin'.
Saving your work
Please save your work as "
Evaluation (out of 10)
- ___/1.5 — Well-modularized function pipeline with separate initialization/input/processing/output
- ___/1.5 — Successful use of objects, arrays, and complex data structures to constrain motion
- ___/2 — Object constructors with properties and methods for the motion of movable items on the map
- ___/3 — Successful motion within the walls of the map, including wrap around motion through side tunnels and array fix
- ___/2 — Well-commented code with good indentation, commenting (including "INIT:", ...), and style
Do it with style
Avoid long blocks of code
Having long blocks of code are a pain to read, and an even bigger pain to debug.
Here is a simple rule: if you have a function that is getting longer than 12 lines of code, you should seriously consider spinning off blocks of code into their own functions.
This is especially important if you have nested loops or long
if ... else if chains.
Debugging long blocks of code is a particularly painful experience that is best avoided.