Python ONLY challenge - Create a third person camera with only KX_PythonComponent, no logic bricks

[gregg_ii]

I have a python challenge that I haven’t been able to figure out yet.

Goal Overview:

Create third person camera movement for a “PlayerCube”.

What I have so far:

• PlayerCube object (in the scene) with an attached bge.types.KX_PythonComponent external python script
• PlayerCamera camera object (in the scene)

The “PlayerCube” is just the default cube that has one cone-shaped side to indicate its front-facing direction.

This “PlayerCube” has an external python script attached to it as a game component (bge.types.KX_PythonComponent). Inside this KX_PythonComponent.update(), python script is detecting when keyboard keys are pressed and handling WASD movement for the “PlayerCube”.

Also, this KX_PythonComponent.update() method, the rotation of “PlayerCube” is applied when the Mouse input moves on the horizontal (left / right) axis.

So the “PlayerCube” turns with the Mouse movement and moves with the WASD keyboard keys.

Besides the “PlayerCube”, object there is also a “PlayerCamera” in the scene.

Goal, (what I’m asking for help with):

Is there a way to ‘attach’ the “PlayerCamera” to the “PlayerCube” so that the camera is always looking at the ‘back’ of the “PlayerCube”?

More detail:

When the player moves the Mouse to turn “PlayerCube” (left / right) I also want the camera to rotate in a sphere…
…while always looking at the ‘back’ of the “PlayerCube”.

Stipulations

To make this challenging, is there a way to do this completely in python

• (no logic bricks and
• no python scripts attached to controllers in logic bricks).

I’m trying to make everything happen inside KX_PythonComponent rather than use any logic bricks or logic scripts, to make the script more portable, ie, just create your Player, your camera, then attach the game component to the player.

…

What I’ve Tried:

Here is a sample of some of the python code I’ve tried:

inside KX_PythonComponent.start() (the game component attached to “PlayerCube”)

scene = bge.logic.getCurrentScene()
camera = scene.objects["PlayerCamera"]

scene.active_camera = camera 

camera .useViewport = True
camera.setViewport(0,0,
   int(bge.render.getWindowWidth()),
   int(bge.render.getWindowHeight())
)

# applyRotation does nothing when previewing the game after pressing 'p' to play
camera .applyRotation((0, 0, .02), True)

but I have not had any luck even moving or rotating “PlayerCamera” / camera, at all.

Summary:

Is there a way to make the “PlayerCamera” act as the third person camera for “PlayerCube” with python only written inside KX_PythonComponent?

You can access the source code and the .blend file here:

https://bitbucket.org/gmilligan/upbge-learning/src/master/game_files/06_camera_follows_player/

Thank you for any attempts you may make to solve this challenge!

[Villi89 (Viktor)]

Hi if you need view only third person - add empty - empty make parent you cube(player collider) make for camera parent empty and stand camera in need position - position back frome player collider. If you need get empty use script
own = cont.owner
empty = own.children[‘Empty’]
this need for next rotation camera to X axis and copy rotation Z axis. I upload for you example - python component for upbge version 0.2.5 maybe this help for you setup rotation you camera
UPBGE Python Components Demo.zip (219.1 KB)

[gregg_ii]

Thank you!

This is a great example to learn from.

One important thing that I learned from this example:

• Before playing the game with the ‘p’ key shortcut, I have to make sure I’m already looking through the camera (numpad 0).

The reason why I could not move my camera with python is because I was not already looking through the view of the camera…

Here is a way to use python to switch to the ‘camera view’.

import bpy


def look_through_camera(camera):
    scene = bge.logic.getCurrentScene()
    scene.active_camera = camera

    for area in bpy.context.screen.areas:
        if area.type == 'VIEW_3D':
            area.spaces[0].region_3d.view_perspective = 'CAMERA'
            break

Since this code uses the module import bpy I don’t want to use it in my game.

I read that using bpy in an UPBGE game would force you to package blender source code along with your exported game so I think I read, using import bpy is bad practice in UPBGE…

If the only way to do this in UPBGE is to manually toggle the view_perspective with numpad 0 that’s alright too.

But if there is a way to switch the view_perspective with python, I’d rather use python.

Question:

• Is there a way to change the view_perspective in native UPBGE code (without bpy)?

Thanks again for your example! It helped me learn this important information.

[Daedalus_MDW]

interestingly, the new upbge has full access to bpy functionality (but might not work). older 2.7x builds will simply not work with bpy at all, it will import error on an exported game.

edit:
heres all the things a bge camera object can do: (hint: camera.perspective)
http://shuvit.org/python_api/bge.types.KX_Camera.html

[gregg_ii]

Thanks! I am now setting camera.perspective in my code.

Adding camera.perspective = True is important since I never want my game view camera to show a ‘flat’ orthographic view.

I’m wondering if in UPBGE, we don’t really have to care about what type of view mode is being used in which region… because an exported game technically has only one view region.

I’m new to UPBGE so I have more to learn…

I think it’s alright if I’m able to save my game so that the player is always looking through the camera, rather than blender’s default 3d viewport camera that you get when you open blender (not a camera object).

I will experiment with exporting the standalone game to see if my theory is correct… I should be able to toggle on the ‘CAMERA’ view that looks through my “PlayerCamera” with numpad 0 then export the game that will always view the scene through “PlayerCamera”.

Thank you for everyone taking a look at this interesting python bge question!

I may post more to this thread if it’s relevant to the topic and could help others find information.

[Villi89 (Viktor)]

yes, you’re right, everything that works from bpy falls under the license and requires you to publish the source code of the game - there are many ways to get around this - for example, create an executable file that will launch something and contains a bpy module, then you just publish the code and source code - for example, the logic of launching another blend file bge.logic.startGame(path + “menu.blend”) and it turns out that you are not violating the license - the only thing that may not be very good is the open blend files - anyone can look at them and use them for themselves, but this is not a very scary situation. You always assign camera in you scenes
scenes = bge.logic.getSceneList()
scenes[‘HUD_Scene’].active_camera = scenes[‘HUD_Scene’].objects[‘Camera_HUD’]
scenes[‘Game_Scene’].active_camera = scenes[‘Game_Scene’].objects[‘Player_Camera’]
scene list get for you full control for assign cameras in standalone scenes in game and not using bpy modules - this working in bge modules, most of your questions can be solved due to the API engine - just look at the documentation on the issues you are interested in more often and in 90% you will find a solution there

[Daedalus_MDW]

the only settings that effect the game are in camera properties panel (right below outliner). i generally would say not test your game using the P shortcut and only launch “standalone player”. this will start your game in the active camera (regardless of viewport) with those camera settings and most closely match the experience of an exported exe.

i recommend setting the camera fov setting to degrees over default millimeters. degrees is more understood in gaming circles where mm is for simulating a real camera.

[gregg_ii]

@Daedalus_MDW

standalone player

Very helpful suggestion to use “standalone start” instead of pressing ‘p’.

I didn’t know this was an option, but I found it after you recommended it.

It pops up a separate game window and previews the game as if it’s exported.

This will be very useful to make sure my preview is showing me what the exported game will look like.

I will also configure my camera to match standard units

[gregg_ii]

This helps get me on the right path to understanding the license.

I feel good knowing there are ways of managing the license of the parts of the game that are unique. It sounds like there is a way to license the unique artwork and assets…

As you mention, the unique custom code may also be licensed if it’s executed in a special way… I don’t fully understand this yet. I will research and experiment with it more.

Here is the documentation I found: https://upbge.org/docs/latest/manual/manual/release/licensing.html

The Blender part of the game will fall under the GNU GPL License, but a separate license can be applied to the custom parts of the game, it sounds like.

I managed to export what I have so far using the Save as Game Runtime addon described here:
https://upbge.org/docs/latest/manual/manual/release/blender_player.html

It looks like the export creates all of the Blender .dll files and license for you. The game .exe won’t run (properly) without all of the files. If you have any python scripts, they need to be included along-side the game’s main .exe file, as well. I’ll experiment with alternate ways to package these custom python scripts in case I want to make a game that doesn’t expose these custom scripts… I think that’s allowed by the license, although I’m not 100% knowledgeable about this license topic yet.

[Villi89 (Viktor)]

I would say this - all your blend files are your property, as well as your animation models and python scripts, if they do not use bpy modules, it follows that if you compile an exe file from a blend file, it is licensed under the GPL license and you are obliged to show the source code to this exe - however, there is a little trick that was suggested when the game engine was under development by Rosendal - if you make an exe file to start that will launch for example a menu file and show the source of this file - then you will not break anything, just think of the exe as the key to launch your game. And yes, you can always create your own player that will launch your starter file - such examples were on blenderartist and some guys did it - then you can even use bpy modules since they are not compiled under the GPL license