Hello there, it’s Super Massive Awesome Robot Time! This week we shall be taking a look at movement.
Continuing from last week’s post, we had the prototype character and a handful of animations – a good place to begin playing with the controls and feel of the game.
In SMAR we are looking to give the player a hell of a lot of agency over their Robot. The controls are key in making this happen along with a few other considerations. Using conventions from modern games, we are using a game pad with the following inputs:
- L thumbstick – Run
- A – Jump
- X – Dash
- Y – Shoot
- RT – Slide
(xBox Controller buttons)
The reason for keeping the controls fairly standard is to help players learn the game. Hopefully this lowers the bar for entry, reducing the learning curve as much as possible. This sort of thinking helps us adhere to the old ‘easy to learn, hard to master’.
Jumping was an interesting topic to tackle, it was shocking just how much I took this for granted in games! Questions such as –
- Should we allow players to jump after falling?
- Should we allow variable height jumps?
- Should we allow you to double jump?
- Can you jump, air dash, double jump and air dash again?
– gave us a lot of areas to being experimenting with.
All this freedom however does mean that the player can break things a little. For instance, an air dash propels you incredibly fast in a single direction. However if you hit the ground (air dash into a hill), the momentum flings you high in the air through the super acceleration. It’s a cool trick – unexpected, but defiantly a keeper!
Bullets were another interesting issue. Initially they would collide with each other, allowing for you to essentially shoot an enemy’s bullets out of the sky. Although kind of cool, it actually ended up with you having a ‘hadoken’ exchange with every enemy you encountered.
Dashing became our ‘fun’ button. Apart from making your Robot move like hot snot, it also makes you invulnerable to bullets. You can’t shoot, so it adds to an interesting risk / reward decision for the player when they encounter enemies. It also makes walking up hills a lot less laborious!
One of our major decisions was our approach to animations. There are generally two schools of approach at the moment, physically driven and what I refer to as ‘plain’.
Physically driven animations use the animation to drive the movement of the character through the world. For instance, if the character’s animation takes a step forward, the skeleton, collision, world position, etc, updates into a new position. This is an incredibly powerful technique used to great effect in games like Uncharted and The Last of Us.
The ‘plain’ approach only updates the look of the model. Nothing else is touched, so things like world position are not changed by animations. This is a much older approach to animation and relies on other systems to move the character model through the world. Although this gives more control over the input, you often end up with problems such as the feet slipping and awkward blending.
In the end we ended up using a hodgepodge of systems. The physical system was used to blend animations and control states, however all movement is provided from specific code. It is not ideal, but for the sake of the prototype, this works out ok in 8 out of 10 situations. Committing to a single system would have improved quality, but would have taken much longer to implement.
With the controls all hooked up we can now move our wee Robot around, which is all kinds of awesome. The next considerations were frame rate led.
Most folks accept that there is a perceivable difference between 60fps and 30fps – often concerning the responsiveness of inputs. Playing around with the prototype, locking the frame rate at different levels, 60fps did ‘feel’ better. For a less high-speed action focused game, 30fps, or even 24fps could be acceptable – assuming you are doing the correct things necessary to generate images at those frame rates.
There is lots of back and forth about frame rates. It is an interesting topic. If we look at it from a processing perspective (the time allowed to generate the next frame):
- 24fps = 41ms
- 30fps = 33ms
- 60fps = 16ms
- 120fps = 8ms
- 240fps = 4ms
You can see the diminishing returns for the time to process a frame (e.g. 24fps would allow for 10 times the amount of information to be processed in comparison to 240fps).
The most obvious difference is the amount you can place on screen. With a modern differed-rendering approach we found that you can easily spend up to 50% of your rendering budget on post processing effects. These include fancy things like antialiasing (edge smoothing / jaggie removal), ambient occlusion (object contact shadowing), bloom (intensifying bright spots), colour correction, motion blur, etc. These effects cost more the larger your target resolution.
Assuming 60fps, this allows for 8ms to process all of the game logic and process all objects to draw, with the remaining 8ms being used for post processing. Considering a decent anti-aliasing solution may cost 1ms – 2ms, you can quickly eat through your processing budget!
Motion blur is cool effect that occurs in photography during the exposure of a frame. While the shutter is opened, light is scattered by a fast moving object. In movies, this allows for 24fps to feel smooth, while tricking the eye into believing it is seeing quick movements. In 2D animation, stylised frames can mimic motion blur, often letting you get away with frame rates as low as 6fps. This is linked with what is often referred to as the suspension of disbelief, specifically in this case, what your brain will accept as believable motion.
In games, as there is a feedback loop, lower frame rates generally do not hold up so well. Visually you may be able to get around this with an excellent motion blur implementation. Gameplay wise, to get the same suspension of disbelief that you can get in animation, generally you need to remove as much of the disconnect between player’s input and the virtual world’s reaction to it.
In SMAR we often would find fast motion would create a great difference between two frames, leading to strobing. Motion blur is used to help reduce this artefact, although it is usually not commonly used at 60fps.
If played at 30fps, motion blur helps mask some of the difference in visual make up of a frame, but there is still a perceived disconnect from input, making the Robot feel sluggish.
Question, comments, queries, thoughts, musings? Drop us a line and I’ll do my best to work any answers into an upcoming ramble.
Till next time!