Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411276 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:03:59 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperDesignWho is holding The Camera? (now done)
Pages: [1]
Print
Author Topic: Who is holding The Camera? (now done)  (Read 784 times)
Pfotegeist
Guest
« on: April 10, 2016, 04:00:38 PM »

The experiment was the entire purpose of this topic. While attempting, I learned a few tricks with cameras, 3d manipulation, and programming. For me it's been beneficial.

After some reflection I think I can be more serious about the result. No, more interaction doesn't make everything realistic.  It is guaranteed to become more complicated, by no means does that make it better.

Who is holding the camera? It's not a bad question.


original post
----


I'll translate it.

At the center is an AI that does what it wants, Bunny. It won't think very hard. If it sees a carrot and it's not afraid, it eats the carrot.

A camera holder Ga predicts what the character is about to do, just based on what Ga sees. Ga remain constrained to one height and obstacle limitations trying to keep a good view of a bunny and any carrots in the same shot.

There are other camera holders Gn with different angles and constraints. They request a transition which takes place if the player is quiet not making actions. Reason, the shot would be impossible to navigate with the camera shifting repeatedly while everyone (every G enabled) and the player are controlling the actions on screen.

Alternative cameras are set up ahead of time by a level designer, or the dev, these are only meant to be temporary cameras. A carrot may lie in wait. A closeup of the bunny's paw becomes very interesting. Someone is ringing your doorbell. This is more suited for a cinematic angle.

The player has control over something like a third obedient character, the direction indicator. It attempts to rally the main character directly to the Player set goal. This and the goal represent the player's actions the most, so from a design point of view, this is the player. Sorry if that's confusing.


I have tried some camera options which aren't as great, and I don't get good camera angles. Looking for things to use and imitate now.
« Last Edit: May 24, 2016, 04:02:21 AM by Pfotegeist » Logged
Pfotegeist
Guest
« Reply #1 on: April 11, 2016, 07:14:30 AM »

 
    PRE EXPERIMENT PHASE ABSTRACT
I can test my hypothesis by having as many things flying, jumping, running, bouncing off walls, hovering around, looking for good viewing angles, relaying information to whoever is holding the camera. The holder moves to find the middle ground with the best view and the Character.

The AI camera holder has a goal to watch the character.

Objects with their own goals can look for many different things and try to predict if the camera holder should move with them. Think of some of these as a tidal forces pushing you and others are helpful lookouts.

how many objects are visible,
how long can they move as-is before the view is blocked, pre-casting
how much of their gaze is taken up by the main Character,
how close they are to the camera holder
where are all the important nooks a bunny-nose can find?
what are the potentially captivating locations that you can see from where you are standing right now?

    SUPPORTING FACTS
The program should work without a bottleneck. More objects increase processing expense. Understand Database Relations Many-to-one, and one-to-one allows everything to relay its info and keeps the expense linear rather than exponential.

The setup is N Moving objects, 1 Camera holder, 1 Character, 1-N Directional Indicators, 1 Player Goal. (N:1:1:1-N:1)

I do some research (see below) but don't find anything that aids or alienates the idea. So I further explained it above.

Three C's are encouraging but only proves anecdotally a correlation to player enjoyment.

    RESEARCH

Genuinely helpful, prior research.
Visibility Transition Planning
   Synopsis: Precomputed globally. Occlusion and focus points are used with a real-time camera to avoid clipping and getting better angles tracking target.
   
   https://www.youtube.com/watch?v=8G0xfyDGLsk?
   
   And a pdf.
   https://graphics.ethz.ch/Downloads/Publications/Papers/2009/Osk09/Osk09.pdf
   
   
Encouraging, anecdotal evidence. Doesn't really prove or disprove anything.

http://tvtropes.org/pmwiki/pmwiki.php/Main/CameraScrew

Three C's
   http://blog.digitaltutors.com/character-controls-camera-3cs-game-development/
   Character, Controls, Camera
   
   Source Bias: Article lauds the three C's quite a bit, claiming they are the determiner for initial player experience in-game, the predictor of experience throughout the entire game.

   

Similar Topics, Research, Tangents. I'll look at these again.
   
Camera was a buzzword in 2009
   Apparently it was, because motion controls.
   http://www.wired.com/2009/06/camera-e3/
   
Player-gaze Topic

Automating Camera Control in Games Using Gaze
Cameron Alston, Arnav Jhala
2014-06-18
   http://www.aaai.org/ocs/index.php/WS/AAAIW14/paper/view/8864
   
   

Research Bias: Skipping tutorials that say "this is a camera in video games" in different words.
More control than real-life camera? Best examples of "this is a camera"

real advertisement application
   http://cameras.reviewed.com/features/the-perfect-camera-only-exists-inside-a-video-game

Predicted Player Bias: Some players may not care if a camera is difficult and would rather direct it. Strongly considering optional controls.
Logged
Pfotegeist
Guest
« Reply #2 on: April 20, 2016, 12:52:59 PM »

This 3D camera experiment turns out to be in a much less explored game design territory than initially assumed. Right, it looks like, I don't know if it is. I don't know enough to understand why. Maybe on-rail cameras are easier? Based on ref. 1 there's clearly a variety in sidescrolling games.

There are some basic physics and object programming which were non-existent in earlier games. Of course, I can acknowledge that.

3 OBJECT CHAIN
So far,
the Camera Holder is given one motion, it moves to match a position and rotation of a character. On click I place the target indicator. The direction indicator is constantly trying to move to the target, bunny follows it, a camera assistant "wagon" in tow holds a regular over the shoulder camera view.

Basic setup complete.

Also there's a physical arrow I added for the camera to look at and a blue rabbit running back and forth for gratuity.

disclaimer: 3D screenshot edited to look simpler and more my style.


CONTROLS
I also had time to review the controls. There's the matter of simplifying player input. My controls start with one-button click only. So that's all I'm going to mention this time.

Clicking to select things and move places is basic functionality.

There's also potential for grabbing the 3d world and dragging, crawling, pushing the edges of the screen, nudging camera. These are not my style as control in every game I've seen, they were extra sloppy.

At ref. 2, I found this interesting.
 
Quote
Automatically rotating the camera to look around the corner for the player as they walk that way. But that removes the control of the camera from the player and is not practical in say, a 4 way tunnel intersection(which way do you rotate without knowing where the player is going?  What if there is something interesting directly in the middle too?).

 I was inspired, because I thought this was a good idea for an assistant task as far back as a couple of days before reading it. I had some clumsy results just getting my version of the over the shoulder camera working.
 
 Instead, why not use a macro for the game control? A player could move and indicate any arbitrary direction from the initial selected point (for a camera, or a camera holder, to look) with one button press and dragging. I'm calling this type of macro control a bunny ear (tm), seen in the image as the arrow. Of course dragging could also be used for many other pleasing effects so don't let bunny ears hold you back.
 
 Having a secondary effect or consequence for performing a necessary action is called a side-effect. A bunny ear is a necessary and/or pleasing side-effect which must take the context in which it's used into account.

Now that this ordeal of ingenuity is just beginning, I have some results.

I'm missing methods that would allow indirectly pushing the camera holder or redirecting it. I doubled back and questioned if those are really helpful. Any additional character class can behave distracted or physically get pushed around with better context.

PROGRESS
While developing any character assisting a 3D camera holder there are distinct problems.
1. Mechanical ingenuity. I lost sight of designing the characters while trying to design something that can hold it so that's a major issue at this moment.
2. Acquiring the camera. This is probably a matter of fine-tuning. Which is the next problem.
3. Needing context. I won't be able to progress further without being absolutely sure the character is serving a purpose in a given context.
4. The similarities to having a camera snap and remain constrained on-rails. That's the basic idea.

If the difference is undetectable by the player, but there's an undeniable quality, then I would be satisfied.

If using a chain of objects to carry the camera or steer your player-character is good enough, go for it. I'm going deeper.
 
More research.

1. Huge blog entry displaying scrolling camera behaviors including 3D camera techniques.
   
   This probably deserves a future post or even its own discussion. Good source of camera behavior ideas and inspiration.
   http://gamasutra.com/blogs/ItayKeren/20150511/243083/Scroll_Back_The_Theory_and_Practice_of_Cameras_in_SideScrollers.php
   
2. http://gawaingames.blogspot.com/2011/11/video-game-camera-movement-design.html

3. Unity C# 3rd person game tutorial using a control stick,
   mentions an over the shoulder orbitting camera inspired by Nintendo games.
   
   channel name John Mac
   https://www.youtube.com/watch?v=b0PvJ4AWvWQ?


4. Towards Real-Time Adaptive Camera Control in Games.
   A long speech with some examples. This appears to be more of a movement prediction simulation.
   
   https://www.youtube.com/watch?v=mbprHB-OIs8?

5. The notion of unmotivated camera movement has never really struck me as anything special until I read this.
   This article allows me to further the idea that individual Ai/character behaviors directing the camera with their own interests in mind can add a human element to real time scenes.
   By Paul Schrader in the March/April 2015
   http://www.filmcomment.com/article/game-changers-camera-movement/
Logged
Pfotegeist
Guest
« Reply #3 on: April 21, 2016, 09:13:12 AM »

Does connecting things like I've suggested make a big difference towards realism or usefulness or is it a Rube Goldberg machine?

Are there any 3D cameras that have attempted to take what an NPC finds interesting into account?

Has there been any other example of unmotivated camera movement in games? e.g. when player is idle... zoom in / look right / change location.

I think it was a good excuse to improve a camera I wasn't satisfied with. Maybe I'll be able to explain better later.
Logged
Pfotegeist
Guest
« Reply #4 on: May 13, 2016, 10:39:09 AM »

I don't like leaving this in limbo. I discovered that my original idea had problems, and I attempted to adjust it a few times. I'll post the newest idea and put this on hold. fyi "bunny ear (tm)" was a joke, but the concept still seems novel to me.

This is all pseudo code. Because I encourage the concept to be reused, not what I might have (or might not have) already attempted.

The camera holder. the idea is to provide a consistent default movement, the camera holder itself can have any necessary filters applied.

It can also be turned off and made to move exactly as what called it.
Code:
While on

Goes to target
Looks in direction target faces

The camera assistant. This has the calling method for camera holder. This is meant to be inherited.

Generic classes.

W/Release -> Add Release Condition with a timed delay.


I thought up a couple of utilities that would be reusable constantly.
Code:
These are reusable Utility methods SeekUtilities

Camera Fidelity Test (CFT)
Detects if a position is within min/max camera view range and within boundaries (bonus points if in perspective).
Camera Region Test
Same as CFT but you pass in a region which is tested against the position.
See Target (ST)
Using Physics casting Detects if a target is hidden from view.
Predict Collision
Calculates how long it will be before we hit something, based on speed last frame.
Zoom To Fit
Given the direction an object is facing now. Detects how far away a given camera needs to zoom in order to fit every object, or just one object.

Get Closest Point On Line Segment
If you're going to do an on-rail camera, do it right

Expert -> This brings the utility methods into use frequently.
Code:
While on
Follows a plan


In order to meet my goal I planned a more challenging idea.

Distractible -> It changes its plan slightly based on obstacles
Code:
While on

Follows a plan
Adjusts to view


View. a desired viewing direction

Assist
Code:
Using Target list (Target[]), makes a view based on all target data

By far the least attainable. Non-Assist
Code:
Using Target[]
TargetData[]  is a clone of Target[]

Using Diversion[] culls TargetData[]
makes a view based on TargetData[]

I might draw some pictures although this is on hold.

Oh. I'll restate one of the important ideas before closing. With camera assistant, you switch from one programmed behavior to another by calling and releasing the camera holder. That means you get different perspectives from different camera experts who follow different plans.
« Last Edit: May 13, 2016, 11:03:15 AM by Pfotegeist » Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic