Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Mobility! The accessible precision platformer - OUT NOW!

A topic by Auroriax (Tom H.) created Feb 25, 2016 Views: 8,138 Replies: 47
Viewing posts 1 to 20 of 42 · Next page · Last page
(2 edits) (+1)


I love precision platformers, but they've always been really difficult. Mobility is my attempt to make the genre more accessible, with different difficulty settings, accessibility options, and a browser version. (Die-hard fans, though, can also ignore all that and just play everything on the highest difficulty. Your choice!)

In Mobility, every platform is a switch you activate upon contact. The goal in each level is to activate all platforms, making each level a little puzzle, especially when you're attempting to score a new record. In the story, these rooms are engine rooms on spaceships that you (a repairman in training) has to fix.

I made this game over two years, in my free time during my game design study. While I am not charging for this game, if you enjoy it consider voting with your wallet to support me with making more games in the future. Mobility! was released on the 17th of February, 2018. You can play it here.

               

What follows below is the original first post of this thread, put online on the 25th of February, 2016.

Mobility! combines the super tight controls of Super Meat Boy with the extensive moveset of the 3D Mario games. The goal is to touch every platform on the level once by either landing or walking on it, or sliding down from its side.

https://gyazo.com/1051b451d0ac20ff2191d3b1c36cf7e2

The game aims to provide a fun experience to new players of the genre by it's inclusion of multiple difficulties and checkpoints, and tries to satisfy the profs with a solid competitive experience with replays, leaderboards (WIP) and secret super difficult levels (WIP). The levels will be accessible via a mini hub which doubles as a training ground and will hide some secrets of its own. This GIF shows a level that flows very well, but I'm also planning levels that require more routing to achieve the best time.

Updates on this 'log will mostly focus on game design, with an occasional extra topic every now or then. I'm trying to update it every week or so. Mobility! is developed using Game Maker Studio, by Tom 'Auroriax' H. (@AmazingcookieNL) and a very large amount of apple juice.

(+2)

https://gyazo.com/1db76aa92a49d907c8d807a03d6e1398

Been working on a new level which uses the plasma conveyors (mid-air conveyor belts!) heavily. I'm quite happy with the result!

My brother has also joined my team to design levels. He's also a hobbyist game designer and helped me out in the past building levels. I was using Bitbucket + Sourcetree already to sync the project between PC and laptop, and it was surprisingly easy to add him to the project and set up things for him. (Kudos to the Bitbucket team!) Here's his work so far:

https://gyazo.com/7d0a861d99db0907ba483a0a96dcbde3

Tons of bugfixing today. Moving platforms are always difficult to get entirely glitchless in a platforming game. And if you get hit with a spike, if you hit a block while the level transition was playing, the blocks you would hit would still get colored in.

Have I told you about our reset level button? In most time trial focused games, you have two keys to quickly reset the level. One is restarting from the last checkpoint, and one is for restarting the entire level and the timer. Personally, I often mix these up. If I'm used to quickly running levels, for which I often do a full reset if I make even the slightest mistake, when running a harder level I often press level reset instead of checkpoint reset, which prompts me to restart the level with no undo.

So in Mobility I came to the solution that pressing [R] resets to the checkpoint, and holding [R] for ~0.3 seconds resets the level. This works quite well, actually, and solves the problem for the most part.

Okay, bonus short story!

Unidrax (see last post, he's building some levels for Mobility! currently) saw the names I had given the levels so far (Vertigo, Xenon, Gold), and that inspired him to translate random words into Latin and use those as level names. This already generated some awesome names like Ostium ('door') and Magna ('big'). He comes with crazy ideas like this all the time but it's the most genius when it actually works out.

Short post! Today I implemented a new timer. (I had to write a script to draw parallelograms, but it was worth it!)

https://gyazo.com/c87f05fa45101080b96f542940bfca4b

As you can see, the current time is the most important bit of information. Above that is info that relates to the highscore. Right is the highscore, and left from that is your current time relative to the highscore. So if you beat your highscore, you can immediately see how much your record has improved. (The font I'm using is Beamo, by the way.)

And if you beat your current best time, your now-previous highscore gets crossed through!

https://gyazo.com/f6962c7d7c5604b42d7ebf25435d7313

(+1)

In AAA parcour games, the player is often led in the right direction by level design and colors. You don't have that luxury in a 2D hobbyist game, but what I'm attempting comes close. See this screenshot:

https://gyazo.com/7eb4307b75ce05021544b7b31a436145

It feels a bit messy. Unless you're used to how the game works, you have trouble deciding where to go. Which is why I introduced cables. Here's the same screenshot with cables attached to the blocks:

https://gyazo.com/b10d504cc06d63fdca7a091d83048bd6

Now, the level flow is much clearer overall. You can see where you are intended to go next, and the cables lead you past all blocks on the stage.

The winning condition of the game is touching all blocks in the level. If the goal was placed on the leftmost platform in the above screenshot, the player could've simply backflipped past the spikes left from the start position, using an unintended shorter path. (In speedrunning jargon this is called skipping.) So if competive races where done on these levels, it would be about traversing the intended path the fastest, instead of trying to do a frame-perfect (speedrunning term for near perfect timing required) trick to skip half of the course, the very winning condition closes that possibility. It might still be possible from time to time, but all major skips are closed this way.

But with this ruleset, an entirely different type of level becomes possible. One where planing a route ahead will be necessary to get the quickest time. Compare this screenshot to the ones on top:

https://gyazo.com/6d173968b83dece66e01d7d8662e8c60

This level is more open, and also contains some moving threats (the floating spikes will actually start to move as soon as the level starts). So you'll need to plan a route ahead of time to get the fastest time on these kinda stages. This level also plays incredibly different on all three difficulties, more so than the parcour-type levels.

To finish, here's another GIF from a level Unidrax made:

https://gyazo.com/ec03f714e5db3c0815a80a7dd95c9960

I'm going to put the GIFs on top of my posts from now on to grab your attention:

https://gyazo.com/5b3e10f799b0fbd6db64a43457b7dacb

Bugfixing and implementing pause functionality today! Apart from that, I updated some interfaces. Here's the new difficulty selection:

https://gyazo.com/ba94beea27f3bcabf19a00bf927c1f58

I should talk a bit about the differences between difficulties. The goal of each level is to touch all blocks on it, as fast as you can. Normal difficulty is the difficulty the game has been designed around, where you can walk or slide from the block's sides to activate it (but not from below, like you would do in Mario games). The easy difficulty puts a radius around each block, which you must enter to activate. That radius grows each failed attempt, so less experienced players can never be get stuck on a level.

On the hard difficulty, blocks disappear soon after being activated. While you can rest on the block you've just activated (the block will not disappear as long as you're still standing on it), it generally means you have to haste. In addition to that, all checkpoints are disabled, and while each level is about 20 seconds long, it still means you'll have a tough time.

The difficulty selection appears before you enter a stage, so difficulty can be selected on a case-by-case basis. While you mightn't know yet which difficulty you want before you enter, you can change it by simply exiting the level. It's much better than a game where you are asked to set the difficulty before you know how difficult the game actually is, and can't change the difficulty later on if you change your mind later. These multiple difficulties are also intended to make the game more accessable for everyone.

Some good progress since last time. Today we decided on some story and overworld criteria. The player character is training to become a spaceship repairer. As such, the overworld consists of multiple spaceships, which you can travel towards per teleporter once it's unlocked.

As such, I've been working on a way to create a map of the world that operates as automatically as possible. See here:

https://gyazo.com/08eedb3f09507cdb7fb3301543a68811

The room the player currently is in, has a brighter color than the rest. On the map you can also place notes that indicate you can access a certain level there, and it'll fetch that level's name and highscores. The second ships' design was done by Unidrax, which sent me this ship design which I then redid in the game's single-color style.

https://gyazo.com/20e515594deedf7cf23e4fe9ee01e117

And finally, we have a walking animation. [MP4]

https://gyazo.com/c96e2c593982fcd19efc3fb83f669ed8

Yesterday I worked on a way to store a replay as a saveable file. The goal is to use the GameJolt API to upload these replays with the scores to the leaderboards. As such, I am especially watchful for ways to reduce the file size of these replays to make uploading them as smooth as possible.

This is how replays work in Mobility: Once the players hits a button, the timer will start running and the playthrough will be recorded. During the level, an array is updated each step/frame with the buttons that register presses. If the player reaches the finish, the game restarts the level and starts the replay, and will repeat all button presses the player made. The game is re-enacting the playthrough.

The big upside of this replay system: very low file sizes. The game records the state of five buttons, so for the length of the replay, that theoretically means five bits (or rounded up to one bit) for each recorded frame is enough. The downside is that the replay could desync, not be identical to the original play anymore, if the game logic during the replay is handled differently somewhere in the game. Even a single desync could quickly ruin the replay. Today I've been hard at work minimizing the possibility of desyncs.

To submit the replay to the GameJolt API, it needs to be formatted as a string, but the replays are recorded in-game as an array. So we need both a script to turn that replay array into a string, as well as translate it back to an array.

This is what the script that turns the array into a string does:

- It checks for the frame which buttons where pressed, then turn that into a single number/real. (It adds one if Left is pressed, two if Right is pressed, four if up, eight if down, 16 if [R].)

- It turns that number into a single string character that represents that number. (so 1 becomes '1', 10 becomes 'A', for example)

- It adds the new character at the end of the current replay string.

It does these steps for as long as the replay array is. If you want to get an array out of the replay string, you just do these steps in reverse: take a character from the string, find out which value that character represents and set that value, and from that value, figure out which buttons should be pressed on this frame.

Next up, I'm going to look into a way to reduce the file size of that string. Right now, the amount of frames in a replay equals the amount of bytes. I'm sure I can get that smaller somehow.

And a small update to the map screen:

https://gyazo.com/5ec7509bb0d73ffde79ba8c967449aeb

https://gyazo.com/586f87fca0577026a10f3b3505b2ac30

Okay, so I managed to reduce the data size by about 40%. If two of the same characters appear after each other, it'll replace it by one character, but capitalize it. Since this data needs to be uploaded as a string anyway, this only reduces the data size as a result. I think optimizing things like this, packaging the same info in less data, is a super nice puzzle to figure out. I did something similar to Mobility's replays in the Box Kickers X's level editor, trying how to save what is an array in-game as a save-able string.

In the meanwhile I'm having another little dilemma. I even stepped in at the Indie Dev Hour for opinions. As listed before, the game has multiple difficulty levels, Easy, Normal, and Hard. Normal is the experience the game is designed around. Easy simplifies it by making it easier to activate the platforms, and makes this even simpler if the player is having trouble. Hard is the opposite, all checkpoints are removed and platforms appear shortly after they are used by the player, and is severely more punishing. Another earlier post in this dev log describes it in greater detail, but this is enough to understand my problem.

The problem is the naming convention. Hard should actually be called something like 'punishing', since it actually steps up the difficulty by quite a bit from Normal. Meanwhile, Easy should have a label like 'Beginner', but it mustn't make the player feel that he is a beginner (or 'noob'), but making him free to use it if it doesn't work the normal way (some people have that tendency against handicaps, accessibility features, or Nintendo's Super Guide). 'Normal' indicates that it's the intended experience, so that name is quite okay, unless I find something better.

It might seen as a little detail, but it's quite fun to find a solution for it and the final product will definitely be better thanks to all these small design thingies. I'll let you know if I figure out some good names.

One of my fave indie game developers Two Tribes announced that they're shutting down after the release of their final game RIVE this September. Kudos to them for being one of the reasons I got into playing indie games in the first place.

For names of the difficulty, for Easy I'll pick 'Relaxed' or 'Chill'. This indicates that it is a more relaxed or less taxing way of playing, while not necessarily indicating it's easier, although that can be derived from the name. Most likely it'll be accompanied by the byline 'For everyone!'. For Hard, I'm thinking of using the name of the game ('Mobility!') as the highest difficulty name. This is a thing done often done for osu! levels where the highest difficulty level name is a small joke that relates to the song or song name. And accompanied by the tagline 'No mercy.', this will draw in the good players while keeping the others away from a punishing experience.

In the meanwhile, my level design partner is making sure my bug fixing list stays filled. Unidrax messes around a bit and before you know it your buglist is one addition richer. It's a gifted ability of him. Today, he found out that if you hold a button and then unfocus the window, the game never registers that button being released and keeps thinking you've pressed it. We use Gyazo to quickly record and share bugs. After that I throw it on the list, and will keep it in the back of my mind when working on the game. It's never a bad idea to have (someone else) thoroughly bug test your game.

Thanks for reading!

(1 edit)

Slow progress last week. My partner was busy with a test week, so I figured I would work on my other project, a Sokoban-inspired puzzle game, which seems to be nearing completion. Talking about that seems out of scope for this 'log, but it's coming along nicely, although each individual puzzle takes a lot of effort to create.

The only new additions in Mobility apart from bugfixes were new levels, of which I'd be glad to share a GIF from.

https://gyazo.com/6a40f242b51a323f687ad84476c2cf79

I'm starting work on the overworld. It needs to be a good place to practice, not too big or difficult so it's easy to get from A to B, and act as a breather for the difficult levels scattered across the map.


Here's the dialog system. It automatically adjusts it's height depending on how big the text inside it is, which is a huge boon. Furthermore, the text is quite big, the text has shadow while to box itself is slightly transparent, which all goes into making it look cool and minimalistic. I'm planning to scatter a few of these talkative spaceship employees to give the player tips or just start some small talk.

Just finished fixing all the desyncs in the replays. It's actually pretty tough to find out what exactly is the reason the replay is not equal to the played game. As explained above, the game records which buttons where pressed on each frame, and 're-enacts' the playthrough. Often a desync is caused by values being overwritten or the key pressed of a single step before. I've been struggling with this for some time now so it's good to have this out of the way.

Spent most of the past and this week working on a Picross/Nonogram client, but it's code turned out to become so incredibly messy and buggy that it's simply no more fun to implement features into it (alongside other factors). So I hope to pick up speed with Mobility again, although I have a hard time deciding what needs to be implemented first. I'm thinking of working towards a playable demo with a part of the game all wrapped up, and use it to test and gather some feedback to shape the rest of the game. I'll see.

I don't know how I haven't seen this before, this looks great!

Thanks!

So I've been working on support for multiple characters! All characters need to fit 10x10 (or anything else in which a 8x10 collision mask makes sense), which limits it a little, but is probably a neat addition. Maybe I can also give the characters unique abilities but that's something I'll decide further down the line.

[MP4]

The first extra character to make it in is the Scarf Cat. It's one of the characters from one of my prototypes that never got finished, but I liked the character and recycled it here. I'll probably put in more characters from my previous games, provided they fit inside the 10x10 limitation... There's one little dude from a game I made three years ago that still regularly makes cameos in my games, which is probably the next one I'll add.

I've also implemented a system to send messages and feedback to me from within the game. This will allow me to gather more comments in case I would publish a demo, but will also be useful in an eventual full launch of the game. The feature was set up surprisingly fast with the GameJolt API and its corresponding Game Maker library.

Also working on implementing Sonic-like grind rails. Very tricky to get the momentum for that right, but I'll share a GIF of it as soon as I have the sloped rails working.

(1 edit)

Showing of the Scarf Cat, as well as the new grinding rails! This new gimmick is quite Sonic the Hedgehog-inspired, but operates on it's own custom set of rules.

First off, once you land on the rail, it takes your current horizontal speed, increases it a bit and locks that in until you leave the rail. It applies the horizontal speed, then checks if you've just passed a slope, and if true, it also adjusts your vertical position. And if you press [Down] while going down a slope, your speed will increase a ton, but going up a slope will decrease your speed. While you can't do long jumps or backflips from the rail, you can still jump from the rail, which you can use to correct your momentum. The grinding rails are also an excuse for me to overuse particle effects :P

It's fairly difficult to come up with ideas for gimmicks that aren't feeling too 'gimmicky', and while I feel I've done a good job on this, I definitely want to test it some more.

Been tweaking the grinding rail physics a bit. My buddy already played with them a bit and made this level:

https://gyazo.com/6b5e4572c51765f85c9f44821147f5cc

We have also been progressing with the overworld of the first ship, the 'Arrowhead'. I've been making hologram screens showing useless but cool-looking graphs. Unidrax commented on that the 'windows' in the ship looked more like the ship has gaping holes in its hull, so they've been replaced with transparent windows. We've also finished all overworld rooms on the ship.

Now, in the levels the camera follows the player perfectly, keeping him in the middle at all times. But on the overworld that makes less sense, in my opinion. This is why the overworld uses a noded camera system: every room in the ship is divided into multiple zones, and once a player is in a zone the camera targets the middle of that zone, and otherwise it targets the player. This camera system has originally been designed for a puzzle platformer (where the camera is kept still when you're in a puzzle room), but a slightly adjusted version of it also works in the Mobility overworld.

To finish for today, here's the top overworld room of the Arrowhead: https://gyazo.com/15e41368eaf51a5079e08ecdab6c6202

Looks fun so far!

Thank you!

Mobility has been catching dust a bit because I am doing work on Tahira's Tower (a puzzle game I'm also working on). I like taking on two projects at the same time! As I explained to theMeaty earlier in the week, if I get tired of working on one project, I swap to the second one. Unidrax however has kept producing levels using the grind rails and made this really cool one:

https://gyazo.com/eb728c9f20f014e612dfc039951ae381

Since I have a vacation now, I also have the time to pick up some stuff aside of those two. For example, I just released Micro Massive II, which was in a finished state for over a year, but I never found the time to tweak it to the level I wanted it to be. It's not that I didn't wanted to, I just kinda forgot about it in the light of the new games I were working on. Since I have not released any game yet this year, I found it an appropriate time to finally pick it up and put all finishing touches in. If you are interested you can grab it here.

Mobility was temporarily put on the backburner so I could focus all my attention on Tahira's Tower, which released just now! As you might know, actually finishing a game takes up a ton of time and effort, making sure everything will really come together in the final game, which is why I chose to make Mobility lower priority for the past month or so to fully focus my efforts on this other game.

Now that Tahira has finally been released, I'll continue work on Mobility! More info hopefully soon...

Viewing posts 1 to 20 of 42 · Next page · Last page