Also, I’m going to start adding a different screenshot from You can Double JUMP at the top each post related to the game. It’ll make the posts a bit nicer than the wall of text I normally do, plus it’ll force me to show something new each time 🙂
First and probably least exciting to show is a new addition to the path system in the form of bézier curves. These allow two points to have a smooth curve between them that can be manipulated using two handles as shown in the picture below.
All the static objects in the game can be linked to a path and there’s a few ideas I’ve been waiting try out, the most obvious of them being moving platforms. The picture below also shows the new object that draws paths as lines and nodes. This will show the path that objects take so that players know what to expect at a glance.
Multiple camera boundaries
Previously I could only add one rectangle to each level which defines the limits of where the camera can go and this was fairly restrictive in how I could structure a bigger level while keeping the camera under control. With this feature I can place multiple boundaries and select which one should be used when the player touches a trigger.
This something I’ve been putting off for a while but what I didn’t see coming was, it needed a complete re-write of the camera system because the bugs that popped up were really messy to fix. So, after one very long day of coding, I gave the camera system a much needed clean up and upgrade. Each sub-component of the camera system (player tracking, bounds clamping, change bounds smoothing etc) is now separate to the camera. This is so that the desired target camera position is calculated beforehand and the camera can smoothly track this target position. This new method also gets super bonus points as it also slows the cameras approach to the edge of the camera boundaries instead of stopping dead on when the camera hits the edge.
Some people incorrectly think that when a game is in 2D, it’ll be a breeze to run but all graphics cards have a “maximum” pixel fillrate. Roughly speaking, the fillrate tells you how many pixels can be rendered to per second. The problem comes in for 2D games where you want to render many layers for background and foreground elements and generally these layers span the whole screen which means a lot of pixels.
You can Double JUMP use to render each of the three tile layers (background, active and foreground) to separate fullscreen textures which are then rendered to the screen. The world tiles alone were eating up the fillrate but by using a feature in pixel shader verson 3.0 I can now render the back, active and front tile layers directly to the screen which completely negates the need to render three 1280 x 720 textures. The frame rate has improved on one of the levels from 360 to about 550 frames per second! This massive increase should finally stop my Dad’s laptop and others from keeling over due to an over abundance of unnecessary pixels 😛
The map screen is something I’ve been giving a lot of thought over and it’s probably had the biggest influence so far on designing the levels. I’ve mentioned before that I want to add an interactive map screen but also I don’t want it to interrupt the flow of the game too much. This is the main reason why I’ve opted for longer levels with checkpoints.
It’s still very early and it only has the most basic functionality but the world maps will offer a choice of paths to take based on one of three things: player choice, finding secret exits and how many gems collected on previous levels similar to New Super Mario Bros on DS.
Hope you like the new features, please let me know what you think and I look forward to showing more and also to finally getting round to producing a video with a snippet of the latest tracks from Tim N 😀 (Check his stuff out on Soundcloud)