The Basics of Engine001 Design

Engine001 has been the deepest, most flexible and powerful 2D game builder I have yet to try. The builder has gotten better over the last few versions I've used, and to have a concept that I know works fine on paper show up flawlessly on Engine001 is a great pleasure.

The main way to endure Engine001's labyrinthine menus as a beginner is to stay near the entrance. Here are a few practices I've used to make stable and appealing games:

1. Experimentation: Build a sandbox game.

The best thing about Engine001 is that it is hard to make a game crash with simple drag/drop/edit scripting. Still, it can happen, and if you're a purist, it's best to work outside of a game you want to publish and fine-tune and error test. The Test Map option is a welcome addition to Engine001, but reloading a ton of assets every time can make testing a single concept take a bit longer. I've found it better to use a sandbox game with one main level and most of the assets deleted or never included.

2. Efficiency: Use custom events with plug-in variables and/or collections.

When you find a script you like for one situation in the game, see if you can adapt it so that it can be used in other situations and with minimal configuration. For example, let's say you have a teleport spell that will take a user to the safe part of one level. If you want to define one safe sport for each level, you could script a chain of if...thens that will repeatedly say "If the player is in level A then position the player in spot X,Y,Z." For a few levels, that works fine, but it becomes a waste of time adding more branches and you can do a lot better running things with fewer steps. With a little planning, you could do it like this:

1. Give each level a scripting ID of 1, 2, 3, 4, 5, and so on (or A, B, C, D, etc.; whatever works).

2. Create a collection with the scripting ID of each level. You can do this easily in a map's starting script, or at the start of the game (go to the System Triggers --> Introduction section to add code).

3. In the collection, get the position of the scripting ID that matches the current level. For example, if you have levels A, B and C, A would be position 1, B would be position 2 in the collection, and C would be position 3:

"A B C"

1 2 3

4. Create a collection of comma-separated and @-separated X and Y coordinates for each level. For example, you could have:

"1,1@32,200@234,101"

for the above three locations. A junk character like @ will separate your pairs of coordinates. Then, in the System Settings, in the Introduction script area, you could run a loop like this:

• While the collection does not equal "" (an empty collection):
• Cut off the leftmost part of the string until you reach a @. Remove the @ symbol, and add the remainder to a collection.

So you will have two collections: the scripting ID collection (A B C) and the coordinates collection (1,1 32,200 234,101).

Then, when you use the teleport spell, you'll check for the position of the current map's scripting ID in the first collection. Let's say you use the teleport spell in level A. A is the first entry in the collection of A B C. So it has a position of 1. Then all you do is pull the first entry out of the coordinates collection. Use a Position Actor to bring your main character to position 1,1 and you're done.

The same process can be done with zones. For example, if you have multiple identical objects scattered across the map, have them refer to the same custom script. Let's say you want to keep track of hit points of various fortifications. You can give each zone its own hit point variable, and its own armor rating, and when that zone is hit, you can have all the processing sent to the same custom script. Just make sure it returns a processed variable to the original script.

3. Interaction: Constantly entertain, constantly conform to natural feedback. Give cues. Don't confuse.

One of the levels in my game works perfectly. When a player walks into an invisible force field, he's pushed back and loses a hit point. There's a crackling sound. But the most important thing is that it's BORING. There is absolutely no visual hint of the force field. It's an entirely lifeless, dull series of hallways. You can learn from memory, but it's frustrating.

The solution I will be putting in will involve animated tiles. I don't want the tiles to show the location of every force field at every given moment. However, I do want them to flicker. To do this, I'm going to create three special tiles. One will flicker on and off every three frames. Another will only flicker every eight frames. Yet another will flicker on the fifth and seventh frames. And I will randomly replace one tile with another every few seconds, so that there is a chaotic feeling to the electricity.

The purpose of a game is to give someone plenty to do in a virtual environment. I try to have at least three or four things to do in a typical one-screen level, and often more.

While I do try to present interactive objects a player can work with, I always want there to be something out of the ordinary in the interaction. One game I have starts in a darkened house. Sure, you can use a computer after turning on a power switch. That's basic and obligatory. But sending the player a creepy, anonymous online invite to visit an asylum in a nearby town... that's different. There's a creaky spot on the floor. In the beginning, it can't be manipulated, but an item several screens down is heavy enough to break through it. What's under this old house? Not just the usual basement appliances... but a hidden passageway leading to a burial ground and the asylum, walled off and isolated for centuries.

And when a player is going through a process to solve a puzzle, or clear a level, I try to make the game constantly respond, instead of showing a long, uncontrolled sequence. The video you see is a rough draft of a level I've completed.

The final tasks and actions include:

• Approaching a computer, tripping an energy barrier in the process
• Examining an ancient computer
• Turning on a power switch
• Learning about a nanotech experiment that is locked away
• Unlocking the organism
• Riding around in it
• Destroying the computer with it
• Crossing through the barrier
• Smashing some computers with a crowbar until the power goes out
• Exiting the newly opened door.

... all in under a minute, once the player has the hang of it. Which leads me to advise...

4. Realization: Understand the limits of endurance and frustration.

Some people are not born game players. When they depersonalize into a video game, they feel they are in a hostile, unresponsive environment. You will need to balance their experience with those of skilled and elite gamers, who can walk into an empty room, push a sliding tile just right, solve a runic riddle and kill the beast in the maze below unarmed.

How can you do this? I try to make the basic challenges fairly easy, so that it's possible to sail through a game as a beginning gamer who is willing to learn a set of constant, simple game rules. But for the gamer who wants deeper immersion, I put in extra off-the-path interactions that, when followed to an extreme, yield extra danger, challenge, and reward.

5. Nitpick, nitpick, nitpick: Playtest exhaustively, write down what irks you, and eliminate it and any aftereffects.

A game can be hampered by so many things. The flow of time can be choppy. Graphics can be unimpressive or confusing. Rewards can be too generous for the work done, or stingy enough to kill. What is perfectly scripted from a coder's standpoint can still be sorely lacking to the end user.

Playtesting in 001 can be a long, drawn-out game of whack-a-mole. One concern, once addressed, can spawn two others. Still, all you can really do is play your levels repeatedly, and see if they pass these criteria:

1. Are the processes they use clear to the player? Are the graphics and animations understandable?

2. Is there enough fun stuff to do and discover?

3. Does the environment react strongly enough to a player?

4. Are there any processes that a player likely wouldn't do that cause error messages or fatal errors?

5. Are there any parameters in normal processes that, when they exceed certain ranges, cause similar errors?

6. Do the sounds and visuals integrate, or do they come across as a mixed bag of free resources?

7. Do the rewards provide a sense of progression through the story, as well as improved gameplay?

8. Does it take too much time and/or effort to advance through the levels?

9. Are there any sequences that negatively avoid cause and effect? For example, does crashing a car into a wet floor sign stop the car and make no impact noise?

6. Personal growth: Push outside your comfort zone in scripting. Discover how to use a function or event you've wondered about in each new game. Risk getting eye-rolled in the forums if you need, just make sure that the answer you're looking for hasn't already been addressed.

7. Customization: Create "custom" floor, low and high tile sets for fill-in creations and new interactive objects. For convenience you can dump all your custom images in the top-listed tile sets you have of each type, but if you're going to be switching out tiles and tile sets, it might be cleaner to keep custom sets, especially if a half-full tile set starts to overflow with custom tiles.

8. Customization, part two: Add custom sound and music.

Making decent 8-bit graphics can still be a little daunting to new users, but I think it's easier to get the hang of doodling up and editing your own scenery than coming up with convincing, cleanly recorded and appealing sound and music. Maybe you have more of a creative bent toward sound production, but since Engine001's music editing is limited to pitch and volume, you'll need to be have decent final sound files to upload.

For those like me who need a little outside help with sound, there are a few options. A few purple, yellow and green indie Web 1.0 sites with so-so sounds can still be found with a bit of searching. SoundSnap.com is a favorite of mine; I get five free downloads a month with my "old skool" membership, and when I find must-have sounds, I either favorite them and wait a month, or buy them pretty cheaply. And for open source music tracks, CCMixter.org is awesome. No dickering with fussy licences here. All you need to balance this new influx of awesome with is your game's file size. A lot of people start getting a little reluctant to download your game when the sound files are five to ten times the size of a basic 001 game. Another way around this is to just use loops instead of full songs; in the level above I used a 15-second sample.

So those are my recommendations for making something in Engine001. Just don't be afraid to push the envelope, be original, and think about what your gamer will be experiencing. More importantly, experience it yourself.