Bravemark Camera Snaps

I built a camera snap system that provides flexible Mega Man style camera transitions between screens within the same room. Figured I’d share my Gamemaker Studio 2 code for anyone who wants to use a similar mechanic in their games.

I used Shawn Spalding’s tutorial on cameras in platformers, then built additional logic into my camera object to achieve the snap effect. My camera snaps to a camera snap object (an invisible yellow dotted outline that’s the same size as my viewport named “oCameraSnap”). So if I just drag and drop it into my room, it shows an outline of how the camera will snap once the player enters the area within the yellow dashed lines.

Here’s the code I use in my camera snap object. Make sure you have the variable named “follow” to equal the player object (sorry if this code’s not super optimized, I’m a designer first, developer second):

if instance_exists(oPlayer)
{
    with (oPlayer)
    {
    // Check if in a camera snap. If so, follow the snap, not the player.
        var current_snap;
        current_snap = instance_place(x, y, oCameraSnap);
        if (current_snap != noone)
        {
            other.follow = current_snap;
        } else //If not in a snap, follow the player.
        {
            other.follow = self;
        }
    }
}

Camera Logic-------------
//Update Destination
if (instance_exists(follow))
{
        xTo = follow.x; 
        yTo = follow.y;
}

// Update Camera Position

var deltax = (xTo-x);
var deltay = (yTo-y);

//Prevent camera from slowly drifting when close to player
if (abs(deltax) < 3) deltax = 0;
if (abs(deltay) < 3) deltay = 0;

x += deltax/15; 
y += deltay/15;

x = clamp(x,min_x+view_w_half,max_x-view_w_half);
y = clamp(y,view_h_half+buff,room_height-view_h_half-buff);

// Update Camera View
camera_set_view_pos(cam,x-view_w_half,y-view_h_half);

You can see the camera snap mechanic in action here. If you’re struggling to implement it in your own game, message me on Facebook. I’d be happy to help ya out.

Request a Demo

I’m always looking for playtesters. Let me know if you’d like to playtest level 1 and I’ll send you a demo! All I ask for is your candid feedback.

Making Level 1 - Laying Bravemark's Foundation

Hi friends. I’ve been working on this video game on and off for the past 6 months (definitely hundreds of hours spent on it already) and I’ve decided it’s time to start sharing my work. It’s a technical 2D platformer (titled Bravemark) that I’m building in GameMaker Studio 2. I created the artwork, wrote and recorded the music, and coded every part of this game thus far. Needless to say, it has been a massive learning experience. My main sources of inspiration for this game stem from the Super Mario World, Donkey Kong Country, and most notably Celeste.

Platformers are far and away my favorite type of video game, and I love a good challenge. Celeste really hits that sweet spot for me. It’s extremely challenging, but for the right reasons. Never unfair. Enables the player. Provides mercifully frequent checkpoints. Beyond that it has a compelling and sincere story.

Designing the Player Experience

Anyway, I could go on for hours about the brilliance of Celeste, but back to my own game. From the beginning, I knew I wanted to make a difficult platformer. This targets a somewhat specific audience: Gamers who are well-versed in expert play who enjoy, well, platformers. An audience in which I shamelessly fit. As a User Experience designer, I’ve approached this game from a “player experience” standpoint and followed the design principles I laid out based on my own research in the field of 2D platformers.

Design Principles

Bravemark will:

• Be exceptionally difficult, providing engaging and satisfying challenges for advanced players

• Empower the player to move and interact with the level in many unrestrained ways

• Achieve difficulty through fair level design rather than limiting the player character’s abilities

• Strive to accommodate the player’s intended input, even when actual input erroneously differs

• Provide synergistic character abilities to further empower the player

• Tell a compelling and engaging story with deep character development and relationships

That fourth point about intended inputs might require some clarifying. I’ll give a common industry example. In platformers, it’s common for players to push the jump button slightly after they walk off a ledge. Depending on the game, this can result in players walking off the ledge unintentionally and feeling cheated that the player never jumped. In Bravemark, I’ve implemented a large window of time in which the player can still jump, even after walking off the ledge. It’s so generous that you can actually see the dust animation several pixels away from the ledge if you time the jump late enough. This has no negative impact on the feel of the game, nor does it appear unprofessional. It does however, empower the player and prevent them from ever feeling like they were robbed. This design in platformers is commonly called “Coyote Time” in indstruy, getting its name after the Looney Toons character who can hover in mid-air after walking off cliffs. Beyond Coyote Time, I’ve already built in many other player affordances to make Bravemark feel fair - most of which should hopefully go unnoticed by most players. Naturally I’ll make more affordances as I continue to build new levels.

Affordances

Here’s a list of some of the affordances I’ve built in thus far:

• Coyote Time: Allow the player to jump several frames after they walk off a ledge

• Small damage hit boxes: There are at least 4-5 pixels on the edge of any damage object that don’t actually damage the player. The player is only damaged when it’s clear they’re done for.

• Large target hit boxes: Some elements require precise aiming. For example, in level 1, the activation flowers need to be hit with a launched seed to activate. The collision check between the seed and the activation flower is big, allowing slight misses to still count in favor of the player.

• Deer Jumping: There’s an input buffer that looks for a player attempting to jump before they hit the ground. So if you hit the jump button too early, you’ll still jump when you land per your intention.

• Higher jumps when running: Just as is industry standard per games like Super Mario World, if the player gets a running start, they will jump higher.

• Forgiving wall-climb hit boxes: The player doesn’t have to be fully high enough to grab hold of a wall. So long as the upper half of the player is in range, the character will still grab hold.

• Directional activation wall ejects: In level 1, when the player is in an inactive wall right when it activates, the wall will eject the player in a direction cohesive to their intended trajectory. For example, if a player is over half-way through an inactive wall while they are moving, the wall will eject them to the right upon activation. As the intended trajectory is circumstantial (i.e. sometimes players want to go up, left, right, or down) I’ve custom built each specific activation wall to eject in the most predictable direction.

• Large lower bounce boxes on springs: If the player jumps upward to bounce on a spring (bounce flower), the character’s feet need only be within 10 pixels of the bottom of the flower to activate the bounce. This basically means you only need to get the character’s knees high enough to complete the jump.

• Plenty more affordances I can’t think of off the top of my head.

Initial Play Tests

All of these things were built into the game before I put it in front of someone else to play test it. Contrary to my better judgement, I also fleshed out a lot of the artwork and music before testing so the play test level looks about as polished as it will in its final state. Thankfully, things like artwork and music generally don’t need to change after finding usability issues in testing video games.

Regardless of the order in which I did everything, the first couple play tests I ran went super well. I used both questionnaires and observational techniques to gather my findings. I found a ton of valuable insights, both validating and condemning. Many of my affordances made the play tests super fun. In the post-test questionnaire, both participants said the game felt extremely fair while still being very challenging. Even after just 30 minutes of playing, each player noted that they felt expert at the game by the end of the level, despite the many deaths they accrued along the way. It wasn’t until after the tests were over that I explained some of the affordances to them. It was commonly an “aha” moment, helping them realize why it seemed the game helped them become better players.

Conversely, some of my designs had the opposite effect. Deer jumping, for example, had too big of a window, causing the player to jump when they didn’t actually want to. This caused them to jump into spikes or off ledges on accident. So the buffer there needs to be shortened.

In the post-test questionnaire, I asked 3 basic questions for each obstacle in level 1 (using a 1-5 scale):

• How fun was the obstacle? (1 = boring, 5 = super fun)

• How clear was the obstacle? (1 = very confusing, 5 = very clear)

• How difficult was the obstacle? (1 = very easy, 5 = very difficult)

I found that the sweet spot in obstacle was a 5 in fun (duh), a 5 in clarity (also duh) and a 3-5 in difficulty. If an obstacle was too easy, it wasn’t as fun. If an obstacle wasn’t super clear, it was unfairly difficult. So an ideal obstacle would be a 5,5,4. A boring obstacle would be a 1,5,1. And an unfair obstacle would be something like a 2,1,5. Using this rating system, I was able to weed out obstacles that just straight up sucked, and edit ones that could be far more fun if they were just a little more clear or fair. In future tests, I’m planning to add the question “how fair was the obstacle?”

What’s Next

Putting together level 1 laid the foundation for the rest of the game. It forced me to address issues in my physics logic, and surfaced player needs that will carry throughout the rest of the game (i.e. generous checkpoints). Now that I have so much of the foundation built and there’s a continually lower learning curve for me as I get better at GameMaker’s coding language and pixel art, I’m hoping levels 2-8 will come faster than level 1.

Each level will use creative ways to build on the launch seed mechanic to create new and challenging obstacles. Level 2 is already underway. In it, I have ignition blocks that turn the seed into either a fireball or a snowball. From there, the seed behaves differently with level elements depending in the hot or cold state it’s in. More to come on that!

If you’ve made it this far into the post, thank you! I’m always looking for play testers, and I’d be more than happy to send over a demo to get your feedback. One nuance though, I’m developing this game on a Mac and currently don’t have a PC. So I can only build this for Mac right now. I’ve found the best way to play this game is with a bluetooth controller connected to your Mac like a mouse (I use a Nintendo Pro Controller).

One day I’ll have this game available on PC, and my ultimate goal is to get it on the Nintendo eShop. there will probably be a Kickstarter down the road to get the funds for licensing and the like. I’d cry tears of joy if I saw Bravemark’s thumbnail on my Switch menu next to the likes of Celeste, Mario Maker 2, and Hyper Light Drifter.

Request a Play Test