Warning: The following post contains plenty of shaking GIFs – I’m not sure if that counts as a health/epilepsy risk, but it might make you feel a bit weird if you stare at them for too long, so please exercise caution…
Lately, one of the big things I’ve been working on is pulling the rest of the Ambience story together, now that most of the gameplay and mechanics seem to be in place. It’s taking quite a while though, and seems to be working out more like an extended project than an afternoon’s work.
At the moment I’ve been putting together a cutscene which plays after the player faces the Wind Guardian. In this scene, there’s a decision you have to make – whether to stand your ground against Foss’s Henchmen and defend the Wind Guardian. What’s interesting about it is that your choice seems not to have much effect on the immediate outcome – but instead it’s used to probe the player’s personality and attitude, and has lasting consequences later on.
While working on this scene, I took the time to sit down and fine-tune a few general appearance things. (I think this is the reason why these cutscenes take so long. Not because I don’t know how I want them to look, but because I keep running into things to fix.) For example, take the relationship between the screen-shaking effect and the mugshot of whoever’s talking.
In the Ambience demo, the mugshot shakes with the screen, while the textbox stays in the same place so the text can be easily read:
The reason why the mugshot moved with the view was because the mugshot was a separate GM “object” (that’s what other languages like C++ and Java call a “class”), which was located in a specific spot in the room and drew the mugshot at that location. However, in hindsight I really wasn’t too happy with this, and figured that things would look better if the mugshot and textbox both stayed still.
To achieve this, I first tried changing the x and y-position of the actual mugshot object to counteract the camera shake displacement. However that didn’t work out well, for various reasons – this was mostly due to conflicts with the mugshot “fly in/fly out” mechanism and the way my camera shake scripts worked.
So I sat back and thought for a bit about how I could “work smarter, not harder”, and come up with a better solution.
(On that note… problem solving is actually a really big component of game dev. I’d say for me at least, it probably takes up at least 50% of time spent developing – coding, spriting, and all the other heavy lifting takes up the rest.)
In the end, I stopped trying to change the actual location of the mugshot object in the room, but instead changed the place where the mugshot was drawn in the view. In GameMaker, objects have various “Draw” events available to them, so I just changed up my mugshot-drawing script to make the draw location counteract the camera shake, instead of the actual object position.
When I first implemented this new script, I quickly realized I forgot to get the mugshot’s eyes to counteract the camera shake as well as its body:
Of course, I fixed this up pretty quickly. The final result looked like this:
I also had to make sure the camera shake displacements and draw location were both integer numbers of pixels, to prevent the mugshot from being drawn with these strange blurry outlines.
On an unrelated note, I also had to give myself a break after completing this – staring at those shaking screens for 1.5 hours would probably make anyone feel a bit weird…