Hey Everyone!
My name’s Lewis and for the last almost-two years I’ve been doing the programming for Oceans. We’re using GameMaker: Studio 2 for development, just because it’s the software that both myself and Zane felt most comfortable using.
Oceans has changed a lot since the GIFs and Screenshots that have been previously shared, most notably in that it’s now a sidescroller rather than a semi-top-down game. I think we both agree that it was the right decision - for reasons that I’ll let Zane explain if he wants to - and that apart from this change, the core concept and feelings behind the game are the same that they’ve always been.
Oceans still aims to be a cinematic experience set in a beautifully alien world. I’ll leave it there because I’m not sure how much I’m meant to be saying
Anyway - I thought it might be a good idea to start writing short posts about development every now and then, seeing how this is meant to be a devlog and all.
A short disclaimer: Some of the content in the GIFs below, such as animations and character movement are still a little WIP. Also, the level these GIFs take part in is a super ugly test level I made using some blocky tiles - the actual game’s levels are just as good looking as before (actually, they probably look a bit nicer!).
The past couple of weeks we’ve been working on the game’s climbing system. Zane has been clear since the very beginning of development that our goal is to create a cinematic experience. To that end we’ve done our best to make movement feel weighty - climbing was a nice way to accomplish this whilst also keeping the vertical elements within the levels. The alternative would have been to have more exaggerated jumping that you see in more traditional platformers, but that wasn’t really what we were going for.
You can see an example of the Player scaling a wall below. You just run up to it, hold the interact button and away you go!
In the test level there’s no way to tell what walls are climbable and which walls aren’t, but Zane is working on some visual indicators for the proper levels.
In the code I detect a climbable wall by checking for a certain tile in our zoning tileset. Checking for specific tiles is super easy in GM2, so it seemed like a good way to handle our collision and different level properties. This is especially true when you consider that I don’t ever touch the level design - that’s entirely Zane’s area of expertise - so having an easy way to be able to mark certain sections as climbable, swimmable, solid etc is really nice. It’s great for quickly prototyping new areas too.
Once I’ve detected a climbable surface, it’s just a matter of snapping the player to it and swapping to the climbing state. Once the Player is climbing things get a little trickier, though. The Player’s climbing animations have all of their movement baked in to the animations themselves. This means that when the Player climbs up a ‘rung’ (my just-made-up unit of climbing, it’s about 8 pixels in game), the animation plays and then I have to adjust the Player’s position to match the final position in the animation. This isn’t too difficult, it just takes some time to tweak offsets and make sure everything lines up. For the animations with larger movements, such as the dismount animation (shown below), it’s possible to get flicker when changing sprites. This is because the Player’s sprite changes to that of the next state a frame before his position updates to the top of whatever he’s climbing. This results in a single frame of the Player’s idle animation hovering next to the climbable wall. The solution I’ve found is to just delay the swapping of the sprite by frame - this gives the Player’s position time to update, eliminating the flicker.
We’ve also added in wall-jumping of sorts. It’s not your traditional wall-jumping, so you can’t rapidly ascend two opposing walls, it’s more of a horizontal leap for reaching distant platforms, or other walls you can climb.
You can see that Zane has had to make two variations of almost every climbing animation, due to the fact that the Player can stop in two different positions, with their left hand leading, or with their right hand leading. You can see an example of this in the GIF above when the Player leans away in preparation for the wall-jump - the lean animation changes depending on the climb position. Lucky for me I just keep a variable that I flick back and forth as the hands swap positions, then I can play the right animations at the right times.
That’s going to be it from me for now! Thank you all for taking the time to read this post, I hope it was at least a little interesting. Hopefully next time I’ll be able to talk about some of the jumps we’ve been working on, and the insane amount of tweaking that’s gone into making them feel good.
Cheers!