Archive

Tag Archives: gamedev

2019 Summer Awful Jam: 60 Seconds

2019-07-05
Game, Programming, Status

“Your theme is… 60 Seconds!”

And so the brain storming begins. I feel like anything that doesn’t explicitly involve time-travel of some sort will get dinged by the Theme-Adherence police, and besides, time travel is fun.

I’ve never made a game with time travel before, but it presents plenty of opportunities to do novel things. At the very least, even if the mechanics aren’t original, I can do things like make the player character switch from replay to AI-driven if the player interacts with his/her previous self or force players to avoid interacting with their previous selves by avoiding line-of-sight and such. All of this is predicated on Terminator-style time travel, where the player goes back into a previous timeframe and can never return to their original. Minute Physics calls this “new/changed history” time travel and I’d call it ‘forked history’ time travel. The other form would be self-influencing time travel, where you happen to see yourself from the future coming in to your present.

I tried a lot of architectures. It began with the simplest thing I thought would work: A controller component would record keypresses and emit signals. The parent object would listen for signals on the child component and act as though it were receiving input. This worked, but it was hard to jump to a specific point in time.

The next thing I tried was a ‘global manager’. Each actor had a ‘get state’ and ‘set state’ method. In record mode, actors would append to their history. In replay mode, they’d pull from history and set state. Things got complicated when it came to handling travelling backwards in time and then interacting differently. It was easy to go back to a time and replay, but it wasn’t easy to go back, replay, and record at the same time. That part was necessary if we wanted to see ourselves and interact in tandem.

The third thing I tried was similar to the first. Each actor would be a deterministic function of time. We ‘set time’ which consists of taking the time and setting state accordingly. Functions are determined as only a function of the current timestamp. That works fine. After playing with it, however, it’s really hard to make puzzles for it.

Shown Here: Player Jumping Backwards in Time and Seeing Other Selves

I’m going to try the Tracer-style time travel thing where the player can go back 60-Seconds into their previous state while the world stays as it is. This is closer to the self-consistent/non-branching timeline.

Thematically, I really want to rip off Zero-Wing and do a terrible translation of the plot. Character has a time-travel device that sends him/her back 30 seconds, but it has a 60-second recharge. The player got a lethal dose of radiation and needs to go back to save him/herself. The goal is to get past unity and into the net-time-gain territory. Either a recharge of 29 seconds or a jump of 61 seconds.

Action Adventure Camera Solutions in Godot

2019-02-17
Game, Programming

Cameras are hard. If you’ve ever found yourself fighting against a camera that would really like to pivot in a direction you don’t want it to, you’ve been on the receiving side of this technical difficulty. The reason behind your struggle is simple: spiteful developers.

Not really. Or at least probably not. The fact of the matter is that making a camera which balances the atmosphere of a game, moves quickly enough to keep up with the player, moves slowly enough to not move around with the player’s jitters, and accounts for the corner cases like a player getting teleported — it’s not a simple thing.

I’d like to talk about the different methods I’ve been experimenting with in Clearing Skies. This is as much a journal entry for me to see what I’ve tried and why it works or doesn’t work as anything else. I hope that someone may find some insight in it.

Approach 0: Strap the camera to the player.

This is the simplest and most straightforward approach to moving the camera. Wherever the player moves, the camera follows.

  • Simple! Easy to implement and understand.
  • Basically no corner cases where movement will be odd.

There are some drawbacks, and they’re not too hard to see. When the player shakes or moves about drastically (like if she shakes after a shock or hit), the camera is liable to jitter along with her. Shaking the camera is a good way to induce nausea or eye strain in the player. Additionally, you lose the sense of level depth. The entire space is continuous. This is fine, generally, but for the first dungeon in particular, this felt to me like it shrank the space considerably.

  • Can cause eyestrain for sudden movements.
  • No way to add ‘cinematic’ elements on transitions between rooms.

Maybe there’s an easy solution to the rapid movement problem? Indeed, we can try…

Approach 1: Smoothed Camera Movement.

The camera smoothly transitions between where it is and where the player is located. This solves a lot of the issues with the player shaking rapidly. It’s like attaching a spring to a camera gimbal.

  • Still easy to implement.
  • Reduces eye strain from rapid motion.

The downsides are visible in the gif above. The biggest issue we run in to is the rapid movement of the player between rooms. The camera has to spend a few frames catching up to the player location on transport to a distant location. This can be solved by snapping the camera (disabling smooth on transition), on setting a max threshold before the camera teleports, or a few other tricks. No matter what, it’s a bit more involved than simply assigning a location, and it still doesn’t give us the cinematic room sweeping we want.

  • Camera has to catch up on long moves.
  • No cinematic controls.

Approach 2: Camera Zones

When the player character enters an area, the camera’s bounds are set to match the region. This means the camera moves smoothly inside the zone, sliding to follow the player and ‘transitioning’ when the player moves between regions. I like the way this looks — it divides the map in such a way that it makes things appear larger than they are.

  • Looks good. Cinematic.
  • High degree of control over where the camera moves. Can cut off areas outside of the map to avoid wasting screen real estate.

It’s not perfect, though. Transitions are very abrupt and might cause issues with visual tracking of the player. It’s also very cumbersome to implement, as the zones need to be defined manually:

Furthermore, troubles come in the way of overlapping rectangles. Not the region on the bottom where it may be necessary for two zones to overlap. Plus, when we finally leave the map, the bounds for the camera will need to change. Lastly, when we change the camera bounds, we lose the ability to smoothly transition between states.

  • Possibility of weird edge cases when moving between zones.
  • Time consuming to put together regions.
  • Not clear how to restore full camera zone when leaving dungeon.
  • No smooth transitions.
  • Visual tracking is hard on screen switches.

In a more perfect world, I’d love to be able to define small pins which act as boundary keepers for the camera, then, if a distance is exceeded, have the camera quickly tween to the player location and return to tracking. I don’t have a solution for that worked out yet, however. Time will tell if I get it solved.