Here’s an example how to make a free flight fps camera.
How it works: There are 2 scripts…
fpsfreecamera.py
FPSFreeCamera class, is a reusable class (can work under any circumstances as long as it is instantiated and given the correct parameters to functions). It contains keyboard and mouse input handling, and provides movement to camera (this class does what it says).
updatecamera.py
This is script is the entry point for our input sensors (2 sensors = mouse + keyboard). The sensors are connected to this script, the FPSFreeCamera class is instantiated, and then you code a “pipe”, of the sensor name to the appropriate class function.
i.e. if you have the MouseMove sensor activated then you will need to call the updateMouseRotation function.
Why is this example built this way:
It’s a clever way to reduce script clutter and provide a better structured way for handling stuff (if you think that it could be called a “design pattern” then I would call it that way too :D).
For example:
- Logic nodes are clean (no cluttered), grouped by same functionalty (camera movement). This is a good way to have structured node design.
- Scripts are clean (no script clutter). Although it’s very fast and easy to setup a script for a sensor (1:1), soon you will be cluttered with scripts that will give you troubles (variable sharing, unstructured code…) That’s why is good to combine scripts based on common functionality (even if they are not the same), for example I did combine Keyboard code with Mouse code but this happened to support the Camera movement.
Keeping these principles into practice making games with Blender seems like a piece of cake, go ahead and code 20 classes for your game. No need to be afraid! As long as you have solid structured classes and global access to object variables you can build anything.
Cheers!
Attachments
FPSCamera.blend (454 KB)