Jordan Bonser
  • Home
  • CV
  • University Work
    • Second Year Work >
      • Top-Down Shooter
    • Third Year Work >
      • Terrain Analysis Project >
        • Terrain Analysis Tool
        • Game Demonstration
      • Post Processing
      • Android Application - Sports Centre
  • Projects
    • Unity Development >
      • Lerpz Tutorial
      • Dare to be Digital Entry - "Lit"
      • Unity Game
    • Geometry Instancing
    • Road to Eldorado
    • Level Editor
    • OpenGL Work
    • JBEngine
  • Blog
  • Tutorials
    • Flask Session Timeout

Development Blog

Space Invaders: Physics with Basic Collision Detection

16/9/2015

 
So today I set about implementing the Physics with my Entity Component System. I initially looked at Unity's implementation for some guidance but I wasn't entirely happy with their approach. They separated the physics actors into two categories:
  • Rigidbodies
  • Colliders

This is not the same concept as in Physx, which is the reason I didn't really like it. In Physx there is simply PXRigidStatic and PxRigidDynamic actors. I instead went for the option of having a flag to decide at creation whether you want a static or dynamic object which I also do for kinematic objects.

At the moment I have 3 new components and one new system. the new components are:
  • PhysicsBoxComponent
  • PhysicsSphereComponent
  • PhysicsPlaneComponent

I did try and attempt to have 1 PhysicsComponent but as Box, Sphere, Plane and eventually Capsule have such varying parameters it made it quite difficult. The main problem is that my component classes cannot very easily be polymorphic due to all the CRTP that goes on. 

The alternative would be to have all the variables as part of the class i.e.
SphereRadius
BoxHalfExtents
PlaneNormal 

as private members and then have a Type value that would determine which values you want to look at. 
** Thinking about it I might try this instead. ** 
I can't imagine the properties for physics objects are likely to change much, and there is likely to only be about 5/6 different physics types anyway: sphere, box, capsule, plane, mesh and trigger. That is if I even bother supporting all of those. 

It would make the streaming slightly more difficult as there would be branching rather than a straight value for value copy.

Anyway I'm wobbling on, here is a simple video showing the player character hitting the invisible boundary walls that I have put in:
As you can see in the video there is some sliding that happens which is probably due to the fact that I alter the player position myself based on input rather than using forces. I may have to lock one of the axis to sort this out. 

There are still a few things I need to think about:
  1. Now re-thinking whether to use 1 Component with a Shape Type value.
  2. Altering Physics Materials, currently all objects use the same default material.
  3. Collision Filtering, this is something that I have been thinking about quite a bit.

The collision filtering is really interesting. I have been wanting to come up with a nice generic solution. Currently you can add a filter group and filter mask to any actor. So you choose which group it is part of and then choose all of the groups that you would like to register collisions for. 

I was thinking of creating a set number of filter groups for the engine and then have the user of the engine deal with collisions at a higher level using ECS game logic. The problem is I can't think of generic enough groups to make this useful. 

Anyway I'm fairly happy with progress and I'm hoping it can continue on.

Cheers :)
 

Space Invaders: Physics Revisit

10/9/2015

0 Comments

 
So I've started looking at the physics implementation that I currently have in the JBEngine. It uses Physx but when I initially integrated it I must have literally got it working for the exact case that I needed it and then left it. I think that came from my inexperience in programming in general.

After looking through the code and playing with a few things I have managed to get the enemies to have box collision shapes and also have the update from physics to game scene working fairly well. 

I will definitely need to re-factor quite a bit of this code to get it to work in a way that would integrate a little easier with an Entity Component System. I have been thinking a little about my current design and have also made the code that was already there a little more flexible. 


Picture
I also got to look at this beauty again as well... The Physx Visual Debugger! It is pretty finicky to manoeuvre the camera but it does show a clear representation of your physics scene which is really good. Unfortunately I couldn't get a video of the physics objects moving so this screenshot will have to do. 

I think the next post will be mostly about the design that I am going to implement before I dive in and start coding. I don't want to make the same mistake as last time ;) 

As another note the fact that Unity uses Physx and also an Entity Component System may make my life a little easier as I can see how they have done it and take some guidance from that.

Would be great to get this physics work integrated fully and in a flexible way soon.

Cheers :)
0 Comments

    Archives

    May 2020
    April 2020
    January 2020
    November 2019
    October 2019
    September 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    August 2018
    July 2018
    June 2018
    March 2018
    January 2018
    June 2017
    February 2017
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    February 2016
    January 2016
    December 2015
    November 2015
    September 2015
    August 2015
    July 2015
    June 2015
    March 2015
    January 2015
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012

    Categories

    All
    2D
    3rd Year Project
    Agile
    Android
    Angular
    Animation
    API
    Apple
    Apps
    Arden
    Async
    Awesomium
    C#
    CI/CD
    Clean Code
    CMake
    Cocos2d-x
    Colour Match
    Compilers
    Cross Compiling
    Cross-Compiling
    Databases
    Design
    Development Tools
    Docker
    Electronics
    Examples
    Flask
    Flask-Login
    Fmod
    Game Development
    Godot
    GUI
    Hackathon
    Hacktoberfest
    Hardware
    Home Life
    IBM
    Inspired Gaming
    Instancing
    Ios
    Javascript
    Jbengine
    Kata
    Level Editor
    Linux
    Microsoft
    Mobile Development
    Monogame
    Moodster
    Motivation
    Networking
    Objective C
    Opengl
    Open Source
    Organisation
    Physics
    Physx
    Pi
    Planning
    Post Mortem
    PyGame
    Python
    Quart
    Quasar
    RakNet
    React
    Road To Eldoarado
    Scripting
    Scrum Master
    Sessions
    Session Timeout
    Social
    Sound
    Space Invaders
    Squash Game
    Squash Game
    Streaming
    TDD
    Team Leading
    Test
    Test Driven Development
    Travis
    Unity
    Unity Development
    VSCode
    Vulkan
    Web Applications
    Worklife
    WSL
    XML
    XNA / C#

    RSS Feed

Powered by Create your own unique website with customizable templates.
  • Home
  • CV
  • University Work
    • Second Year Work >
      • Top-Down Shooter
    • Third Year Work >
      • Terrain Analysis Project >
        • Terrain Analysis Tool
        • Game Demonstration
      • Post Processing
      • Android Application - Sports Centre
  • Projects
    • Unity Development >
      • Lerpz Tutorial
      • Dare to be Digital Entry - "Lit"
      • Unity Game
    • Geometry Instancing
    • Road to Eldorado
    • Level Editor
    • OpenGL Work
    • JBEngine
  • Blog
  • Tutorials
    • Flask Session Timeout