Friday, March 25, 2016

Alt Review: GDC: Side Scrolling Cameras

[Alt Reviews is a review of some topic but with my own spin on it.  I.e. I learn from the topic, and mix my own experience and ideas into it.  I do this mentally on all learning content, but I'm sharing it for others benefit as well.]

At GDC 2016, Itay Keren gave a presentation called "Scroll Back: The Theory and Practice of Cameras in Side Scrollers."

Physics Base

2D camera movement is more important that typically realized.  For instance, in many games, a camera is simply affixed to a focal point and never moves off.  An upgrade, is adding minor physics to so that the movement is smoothed out with tethers and springs.  Another upgrade is leading the view, where if you are in a vehicle and picking up speed, the camera might move out to let you see farther ahead, while keeping the vehicle far behind.  Itay's presentation talks about the importance, value and methods of implementing deeper layers of leading and controlling the camera for players.

Itay starts out talking about how the eye works and how the brain recieves images.  First pointing out that the center of our vision and the edge of our vision have different response systems.  The center is very clear, focused, and lower speed.  While the outer/edges is faster, but less attuned to specifics.  It makes assumptions about what it sees.

He brings up 3 topics that are intertwined

  • Attention - Make sure the camera shows all things that are important.
  • Interaction - Make background movement tightly bound to controls. (Paralax BG's for instance)
  • Comfort - Ease of contextualizing background changes.
Issue: How to eliminate unpredictable bumps?  Below is ordered from earlier/lighter methods to newer/more exact methods.  (Its not that one method is better than the other, but that each can have practical value depending on your game design.)
  • None.  The camera is locked to the unit.
  • Vertical or horizontal snapping.  I.e. the camera freely follows the character along 1 axis, but the other is locked.
  • Camera Window. I.e. the camera stays put until the player moves just outside of the camera window.  The window is smaller than the screen.
    • With Lock: This forces elements to move with the camera when needed.  Like Street Fighter.
    • Works best with Zoom To Fit
  • Platform Snapping.  I.e. The camera remains locks when there is nothing for it to do.  Once the player jumps and lands on another platform, the camera quickly (not instantly) moves vertically to that next section.
Next he talks about using the physics to smooth the production.  I tend to use Impulse (small measurable unit of speed) and Velocity (direction * speed).  I.e. as you move, the unit is the target.  As you move, the camera first moves slowly, then picks up speed every frame until it catches up to the target.  (Turns out he talks about this a moment later, as Lerp Smoothing.  :) )

  • Forward Focus.  I.e. the camera will show more ahead of the player.
  • Dual Forward Focus.  I.e. if the player turns around, the camera switches to provide more space in front of the the direction they are facing.
    • Threshold triggered.  I.e. The character can move back a little before triggering camera movement.
  • 2D Forward focus.  Any direction the player moves.  the camera moves a little ahead of the player.  Requires smoothing physics for the player control and the camera with Lerp based velocity.
  • Target Based focus.  I.e. giving some camera shift based on targets.  such as are the targets in view and important?  Is the mouse over a target?
  • Position Averaging.  I.e. focus on multiple players on the screen who both always show up in the same view.  like gauntlet
  • Shake.  I.e. Lack of control, something emphasizing the player's lack, or the impact something just had, because the whole world shakes.

The Directors Chair


Next Itay moves on to Directed Paths.  Everything so far has been based on game play focused camera movements.  I personally have provided very little direction in my game development.  A major distinction, is that (typically) the game play focused camera controls are all code based.  A programmers makes them happen as expected.  While a Director's perspective puts more control in front of a level designer.

Note that with the Director's perspective, your still coding all the camera movements, but you are providing tools for the designer to make changes to that mid game.
  • Region Based Anchors
    • Level or areas in a game change how the camera focus works.  
    • If a portion of the game is mostly vertical, then the camera option changes to focus on vertical assist.
  • Zoom To fit.  
    • zoom in/out to show/focus on key elements in a scene.  
    • Example for boss levels
  • Cue Focus
    • Attractors found in levels that try to shift the camera to it based on its distance from the player.  
  • Center Region/Camera
    • Focuses on player, but takes an value between the target and the center of the region.
    • This gives a sense of where you are in the region, because the camera movement compared to the unit position helps express your location.
  • Camera Track
    • The camera follows a set track in the game, and moves to keeps its closest position along that track to the player.
    • Gives feeling of control of the camera, while allowing the designer complete freedom to setup each angle, zoom/pan, etc...
  • Gesture Cues
    • Focuses either on actions, or elements in the game, where the camera perspective changes to better show something.  For instance as you hang on an edge, the camera focus might switch from side scroller, to emphasize downward fall more.
    • This may also focus on player events, like picking up an object to temporarily highlight the object over their head, or a particular attack, that if it catches, will run several slow motion hits.
  • Cinematic Paths
    • Predefined set of paths, outside any player control, that shows things happening, 
    • This might emphasize an even just off scene event, that helps the story along.  You don't control it, but its very important for story/emphasis.
    • This stops actually cut scenes and allows the game to move on without scene loading.


Italy then goes on to talk about Mushroom 11, and all the camera modes that went into it.  I strongly recommend reviewing it.  I'm planning on organizing these thoughts a little further, and write up some code examples, perhaps a Lynda or Udemy class to show it.

So here is another link to "Scroll Back: The Theory and Practice of Cameras in Side Scrollers." I strongly recommend watching it, as Itay goes into far more detail and explanation on each area.


Saturday, March 19, 2016

Knock Out PoC Update 1

I took on a new proof of concept, similar to match 3, except that you blow up anything you click on, and all connected pieces of a similar color.  Everything here represents about 6 hours of work.


The ball prefab is just a sphere with a rigid body, with the Z constrained.  I had initially tried placing an empty quad in front and behind but found this was better for performance & visuals.  The first PoC was just to get a bunch of them filling up a screen, and as the video above shows, that was completed well.  Because its physics based, and not defined slots, there is some variance in how they line up.


Next I added click to destroy.  Easy enough, using OnMouseEnter/OnMousExit to set a bool and if that is set, onclick, destroy(gameObject).  But destroy wasn't visual enough, so I added a simple explosion.  A while ago, I picked up the asset FX Mega Pack from the asset store, and I'm using modified version of one of their explosions.

Next I daisy chained all the touching (or close to touching) items of similar color and separated the destruction by a fraction of a second each, so you can see the chain effect.


Lastly, I added a bunch more block types and a score system.  You get 1 point for each block, but each daisy chained item gets you the number of points as its position in the destruction.  so 1 block = 1 point.  2 blocks = 2 points (1 + 2) and so on.  

Thursday, March 17, 2016

Truck Ride PoC Retrospective


Reminder, Trick Ride PoC was just a Proof of Concept.  It was intended to end and not be base code.  Here were some of the good and bad's along the way:

Good:
  • Unity's 2D Wheel components (Wheel Joint 2D) were easy to implement and get a wheel started.

Bad:
  • Terrain modulation was tough.  I didn't come up with a full solution for this as the proof turned to pixelation, but trying to smooth out the terrain like hill climber was tough to do.  I have ideas, but not that include handling the pixelation.
  • Unity's 2D Wheel Components had no natural way to separate them.  Each wheel is connected to a separate script.  Each script has to be connected to the rigid body of the vehicle.  So if you have a script that's going to control front and rear wheel separately, then you have to base it off position, which doesn't work if you start the vehicle upside down or tilted greatly. Unity's drag/drop solution won't work.  
  • The Joint was a little too hard to use.  it didn't seem to have a "flex range".  Something to stop it from moving too far from the wheel well.  I had it move over 50 away from a vehicle that was only 3 long.  Made no sense, and was hard to control.

Fun:
  • The game peaked in fun for me as I was climbing steep terrain, with awkward grip that worked really well to reach around to the other side of a block and then pull me over.  It felt like something was there, but I couldn't enhance it any more.  I think I was a little too focused on getting the physics to work better for speed, and could have gotten more out of the climber if I let it focus on slow movement with challenging terrain.

In the end, I'm glad I tried this, but its time to try another proof.  Something quick and easy to expand on, until I get caught up in something insanely fun.

Wednesday, March 16, 2016

Create your own 3D RTS in Unity


Its LIVE!  There is a course on Lynda.com now called "Unity 5: Build a Real-Time Strategy Course" that you can attend.   If you don't have an account there, you can get a free trial here.


I could have done multiplayer, but I decided to go with an AI instead. I've shown ways to add new AI capabilities with ease, using a relatively straight forward AI system.  You can control how easy or hard it is by a making the AI slower or have it make poor decisions.  


Its a playable RTS, where you can battle an AI player, (or multiple if you add more enemies), define AI starting points and resources, control the camera movement, hide enemies on the mini map, add actions to units, use actions to control the technology tree, determine safe points to build, navigation and a lot more.

Try it out now! ~ Unity 5: Build a Real-Time Strategy Course

Tuesday, March 8, 2016

Truck Ride PoC - Update 6 - BG and more Pixelly crashes. (Slow motion wreck)


I've added a background, and more pixels for the crashes.  Below is a slow motion explosion.  Perhaps I'll mess with the time on this, so slow motion explosions are part of the game, not the recording process.


Truck Ride PoC - Update 5 - Crumble Physics


As the 'Pixel' transformation is gaining more traction, I've been thinking about how I can take more advantage of it.  Crashing is a great concept, when the pixels all become separated from their base, and scattered with the velocity of the vehicle just before it crashed.

While I don't have the Crash Event wired into the physics, (so I'm using [space] for now) I do have the transfer of physics from the body to the pixels working great!





Monday, March 7, 2016

Truck Ride PoC - Update 4 - Pixel Climber



So in this version, I got rid of the polygon collider for the frame, and the circular colliders on the wheels.  Then I placed 2D Box Colliders on all the "Pixels".  This allowed them to operate like squares and gain unique abilities that round tires don't have.

Around 18 seconds in, you'll see it pull itself over a hill, by allowing a front pixel to sink past the end and pull the back end over.  A grip the round tires could not make.  This is opening a lot more options in the Blocky realm of casual game play.  I'll see about expanding on those.

* Another update, is the terrain is all based on the pixels as well.  I spent about 2 minutes creating a simple "pixel" square, and now EVERYTHING in the game uses it. 

*Another update is that the ground is complete now.  A top layer of grass (made of 1 pixel) atop a depth of dirt (made of 10 pixels) 

* Another update is that the vehicle control is now in the player's hands.  So far stopping/slowing are very *slow*, but I'll improve that. 

Friday, March 4, 2016

Truck Ride - PoC Update 3 - Blocks.

So I'm testing out a new perspective on the game play.  Taking hill climber and adding an 8Bit feel to it.

The truck pixelated in the new game mode.


I slowed it down, so the tire movement stands out more.  I attached square textures all over the tires and frame of the body, and then created a really simple script that locks the rotation in place:


Finally, I stopped rendering the original textures and colored the squares to what I want.  I think I'll keep up on this proof for a bit.  It's starting to feel fun.  I'll chase that.  :)