SEQ.BREAKER DEV JOURNAL # 11: PRODUCTIVE 24 HOURS

Seq.Breaker's new art direction has proven to be very refreshing. I've started the entire game over again and already:

• I'm half-way through with the designs of the first level, now cryptically called Mission Four.
• I've created the basic movement code for the player character, and added some kickback for the weapons.
• I've thrown out the old life-bar system in favour of a two hit point system, in which the extra hit point-- represented by a circular force-field-- regenerates over time.
• I've created the very simple HUD and eliminated the need for both a map screen and a radio support character.
• I've created most of the enemy types for the first level and implemented an enemy respawning feature that's so simple, I can't believe I didn't think of it before. This I will share with you:

This explanation is going to sound a little wonky to people who aren't familiar with Game Maker, so fair warning. It's also going to be a few paragraphs before we get to the respawning fix.

As mentioned before, the game is not a scrolling platformer; rather, the player sees each room as one whole. When they leave one room, the game cuts to the next, and so-on. Some games that utilize this approach, like Alexitron's excellent Metroidvania game The Power, take the form of dozens of different rooms, with room-switching collision objects that are coded to take you to different rooms depending on where the room is located.

While it works for him, I'm not really a fan of that approach. I find that it makes the movement too clunky; jump from one room into the next, and your jump isn't continued but comes to a dead halt. What I've done instead-- which is something I also did in my game Run Jump-- is that I make each level its own "room" (as the Game Maker program defines a room) into which I place an invisible object upon which I center the view-- that is, the game's "camera". This way, we only see one screen's worth of information.

At the borders of the screen-- top, bottom, left, and right-- I have four more invisible objects. The left and right objects are one pixel wide and 320 pixels tall, while the top and bottom are one pixel tall and 640 pixels wide. That is, these invisible lines run the entire perimeter of the screen, and when the player collides with them, they're coded to move the center camera object one screen's worth of pixels in the proper direction. The four lines themselves are coded in their Step Events to always always always be a certain number of pixels away from the camera object, and so they naturally move with it. This distance is actually a twelve pixels more than the margins of the screen for each line; otherwise, if the player moved right and the screen/lines jump right, they'd be right in the middle of the left line, and the screen would jump back and forth. (The back-and-forth jumping is still a bit of an issue moving vertically, so I'm still working on the proper fix.)

One problem with having an entire level active at the same time is that it can cause quite a bit of slow-down-- especially if there are projectile objects to be found. The solution is to input a "Destroy Self" command in the "Outside View 0" Event for each projectile object.

That Event is also the key to respawning enemies (see, I told you we'd get to it!). In games in which a given level or area is a whole bunch of rooms, respawning enemies is as simple as re-entering (and thus re-creating) the room over again. But because my level is really one giant room, I don't have that luxury; if the player backtracks through an area after having killed all the enemies, she'll be faced with lots of empty content. And nobody wants that.

And so, in the Destroy Event for each enemy, I have it set up to Create a new object at 0,0 relative-- that object being called "enemy_1_respawner" or "enemy_2_respawner" and so-on. That invisible object will do nothing while the player is on the screen, but as soon as they leave-- taking the camera object and the view with them-- the Outside View Event for that object will kick in, commanding it to Change Self Into (whatever the enemy type was, "yes" for performing events).

Insanely simple, but very useful.

Anyway-- as you can see, it's been a busy twenty-four hours. Perhaps a little too busy; the wife isn't exactly happy about me spending this much time in the computer room. :-O