This code makes use of a different kind of custom function, called a METHOD.
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!
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.:
position_empty(), etc. For special circumstances, consider also the “advanced collision detection” functions (e.g.,
- 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:
- Your LEM has a finite amount of fuel as it attempts to land on some lunar surface;
- The player guides her ship, using a main (vertical) thruster and two smaller horizontal thrusters, towards a promising surface for touchdown.
- 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.
- 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).
I’m still working through the questions, examples, and problems you’re sending my way. I’ve got a few more things to upload too, but I’m out of time today, and can’t get back to this until Sunday early AM.
With that in mind, and hoping to reach the broadest possible audience, here is a quick video that reviews the loop I’m using in my quick Whack-A-Mole mock-up.
As I say, there are a few more things coming, but probably not until tomorrow AM.
Note: The video is still uploading to Vimeo and I don’t have an address for it yet. It should be the first video on this list, however: https://vimeo.com/user102714129. It may not be visible until 7PM on Saturday (today).
Finally: Here’s a copy of the source code for Space Gophers Something Something, the code I discuss in the 45 minute video, above.
for() loops are so important to understand thoroughly. This tutorial shows you how I create the side of a building by making a window out of a sprite, and then carefully calculating how to squeeze as many on the surface of the building as possible. Download the code below.
Once the windows are installed, you’ll notice that you can mouse over them to turn the inside lamps on — but they’ll go out in a random amount of time.
The blinking blue star is my “controller object” — it builds the building, etc., but doesn’t do anything after that. Note that the building surface itself is just a sprite I’ve dragged onto an independent “Asset” layer — not the “Instances” layer itself. I can do that because the building doesn’t have any code to run. Just the windows (which are placed programmatically on the “Instances” layer, where their code can run.
If you have time, there is a tiny bit of code in the Mouse Enter event that deals with setting an Alarm — a timer — that can be useful.