Project IV: Lunar Lander

Project narrative

Land your Lunar Excursion Module [LEM] on the surface of the moon. This is a storied and much beloved game from early digital video-gaming (ca. 1969).

Here’s a re-creation of the earliest iteration of the game — text-based!

https://lunar69.uber.space/lunar.html

And a good overview of the game’s multi-platform history:

Project Requirements: Code

  • Make use of basic collision detection in GameMaker (esp. recommended,e.g.: place_meeting(), position_empty(), etc. For special circumstances, consider also the “advanced collision detection” functions (e.g., collision_point(), collision_line(), etc.);
  • Make use of at least two different sound effects that are synced to player or game behavior;
  • Make use of at least two cameras (e.g., one close-up and one distant; one on the game field and one trained at a control panel, etc.);
  • Make use of at least one simple particle generator (built by you, and not part of the GameMaker physics engine proper).
  • Special Aside: Your code should NOT MAKE USE of the BOX2D PHYSICS simulator in GameMaker.

Advanced Options: Code

  • Consider using procedurally-generated terrain via an implementation of Perlin Noise or Perlin’s more recent innovation, Simplex Noise.
  • Game data should be clearly and intuitively modeled for the player. While a purely numeric dashboard is a good start, for example (displaying remaining fuel, rate of descent, etc.) a graphical presentation of that information — in the form of dials, gauges, etc. — might make it more fun.

Project Requirements: Gameplay

Please consult any of the variants upon the original Lunar Lander (Atari) for game-play ideas. In essence, here’s how gameplay proceeds:

  1. Your LEM has a finite amount of fuel as it attempts to land on some lunar surface;
  2. The player guides her ship, using a main (vertical) thruster and two smaller horizontal thrusters, towards a promising surface for touchdown.
  3. Feel free to vary difficulty (randomly, or by level) by varying (1) gravity, (2) fuel reserves, (3) rate of fuel consumption, and/or (4) how rigidly you evaluate a “soft landing” versus a crash.
  4. The pleasure of this game — aside from its simulative nature — is the tight integration between our input (thrust) and the moon’s pull (gravity, inertia), as both are understood vis a vis our dwindling resources (fuel).

Introducing Project Two

Whack-A-Mole

Our first effort at integrating some sense of gameplay into a project.

Whack-A-Mole was hugely popular in the 80’s and 90’s, especially at kids’ entertainment restaurant chains like Chuck E. Cheese (“Where a Kid can be a Kid!”) and even at more adult-oriented venues like Dave & Busters (“Welcome to Hell”).

In the physical version of the game, usually between 4 and 9 moles, gophers, etc., randomly emerge from fixed holes in the ground.

“I cannot cope with any of you any longer, and neither the games nor the buffalo chicken wings will suffice to numb my pain. Please let me leave.”

Physical versions of the game were extremely popular in arcades, especially with young children and guys in their mid-twenties (go figure). A large rubber mallet was typically used to strike the emerging rodents on the head, sending them back into their burrows.

Our Version

The Nature of Your Gameplay

Regardless of the options you include in your code (see below), you need to begin with a fairly basic set of questions: What kind of experience are you providing to your player? What are you requiring of her? What are you giving her in return?

My suggestion: As you are getting started, write down an answer to that question in your code comments. Keep going back to it, asking: Am I building the experience I intended?

This game offers us an opportunity to think about the kind of experience we want to build out of the generic “whack-a-mole” theme. Of course, it is important to observe that each of the gameplay suggestions (below) require increasingly complex code. Complexity doesn’t always (or even usually) mean “good.” A very simple but very solid game, with reliable interaction, is almost always preferable to a cool but utterly unplayable mess. Remember: We still play PacMan and Space Invaders because they are essentially “perfect.”

Gameplay possibilities, from simple to complex

  1. Your game is a game that emphasizes immediacy of reaction, but demands no real strategy on the part of the player;
  2. Your game is a game that demands some very simple strategic decisions from your player: She can’t hit two gophers simultaneously, for example, so she must choose the most valuable one to clobber, etc.);
  3. Throughout gameplay, your player makes choices of varying risk: For example, whacking a multicolored gopher sometimes (e.g., 25% of the time) makes all of the gophers move at 15% of their regular speed, or triples their point values, but most of the time (75% likelihood) ends up speeding up the gophers, temporarily rendering her hammer limp, or reducing point values;

Alternatively, consider more puzzle-oriented gameplay

Nota bene that in my experience, puzzle-oriented gameplay often makes for code that is more difficult to balance and harder to polish to perfection.

  1. Your game borrows some elements from puzzle-style games, but remains action/reflex oriented: E.g., your game stipulates that you cannot hit two gophers of the same color consecutively;
  2. Your game pushes further away from an action/reflex-style game into the realm of more advanced puzzle-style problem-solving.

Baseline Requirements

Requirements for our version are fairly minimal. Remember what we’ve said about working towards the “minimum viable product.”

  • 5 fixed holes and 5 independent moles/gophers;
  • Click on a gopher to send him back into his burrow and score points;
  • Choose: The game lasts either (1) n seconds or (2) however long it takes to bash n gophers;
  • The gophers should randomly appear and disappear from sight (and are only bash-able when visible);
  • When a gopher is successfully struck, there should be at least one (ideally more) indication of success;
  • The game should begin by telling the player to “get ready,” followed by a pause of (say) 3 seconds;
  • The player should always have a sense of where she is in the game. For example, the game might display time remaining; required points remaining; remaining gophers; or some combination of these (depending on the nature of gameplay in your iteration).

Some Advanced Options

If you are comfortable accomplishing the tasks above before the due date, consider adding one or more of the following characteristics to your game.

Making the Gameplay More Interesting

I strongly suggest that you engage with these options only after completing achieving “minimum viable product” (above) and that you add these one at a time.

  • Add a splash screen and a final score screen;
  • Add a theme song that plays throughout;
  • Add sound effects to gameplay
  • Animate your gophers (moles or whatever): Make the varmints react to being clicked, give them idle animation, etc.

Small-Scale Gameplay Change Suggestions

  • Incorporate false or dangerous targets (e.g., a bomb);
  • Create an animated hammer to use in lieu of a simple mouse pointer;
  • Special effects appear when hammering, missing, running out of time, scoring bonuses, etc.;
  • Increase difficulty over the length of gameplay;