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

Squash Game and the Component Based System

26/3/2013

0 Comments

 
I have taken a step back from the inner workings of the renderer and decided to start implementing some more game specific stuff, as I was moving onto things that were potentially not that useful for the squash game. 

I've always wanted to implement a component based system since I saw one my friends at Uni create one for his third year project. So I did some research into what the actual concept and the general design for a component based system is and it turns out it seems to change from person to person. The theory somewhat stays the same in the fact that instead of having a hierarchical design ( i.e. Base Class Pet, with derived classes of Dog and Cat ) it has a design based heavily on the Has-A relationship ( i.e. Entity Has a Bark Component ). There are many advantages for and against the component based approach and it really is a case of suiting the design to each specific game. The main reason I leant towards this is essentially for the re-usability, as once you have written a renderable component then in the next game that just needs to be included into the project and away you go.

My Component Design

Okay so I'm going to talk about my specific implementation of the component system mainly for clarification in my own head and also to help anyone else out there who is looking for examples.
Picture
You may have noticed that my design differs somewhat from what most people envisage the component design model as. I have got three main objects rather than two. I have the Entity, Components and these other objects called DataComponents. The idea is essentially that Components are pieces of logic that do one specific thing, Data Components are just pieces of data that can be shared between various Components and an Entity is simply a container for both these objects. You may wonder why I have gone for this approach and the answer is simply my method for working around the issue of shared resources. For example a Mesh or Matrix will more than likely be needed for most Entities( but not all ) and may need to be accessed from various components such as the Render Component or a Physics Component. Due to this people have often just placed the Matrix or Mesh in the base entity class but I think this defeats the purpose of the component system some what. My approach leaves the Entity Class as basic as possible and allows the components to still have access to the shared resources. It does have some downsides though such as having to keep a reference count for the Data Components and dealing with destruction of itself.

The Main Loop

I've spoken about the general design but it may not seem that obvious so I will explain a general game loop using my component system. 

while( gameIsRunning )
{
    ClearMessages();

     HandleInput();

     UpdatePhysics();

     UpdateEntities();
}

so that is the basic game loop but it doesn't really explain what is fully going on. So here is a general run through: 
  1. The Messages for all the Entities from last loop are cleared. 
  2. Input is taken from the keyboard and a message is fired to the appropriate entities. (i.e. MoveMessage).
  3. The Physics is calculated and the Entities matrices are updated.
  4. The entity update loop starts, each entity runs its components in order of priority, passing in the list of messages which that entity has received.
  5. That component then goes through all the messages getting the information out of the messages that it knows about and then using that information to change its own or the shared data in some way. 
  6. The component that is ran last is always the Render Component to ensure that no transformations are made after it has been rendered.
That is the basic loop for my component system, there are some things I found that don't fit well with the component system such as the Physics and the Rendering. I have got the rendering as a component but due to this it is a naive rendering approach that doesn't perform any advanced techniques such as batching or instancing. The physics currently just updates the matrix for the object directly using the Matrix Data Component which the rest of the components then use so it is always accurate. 

This is only my initial design and will more than likely change but for now this is working and allows the flexibility and reuse I have been wanting.

Cheers :)
0 Comments



Leave a Reply.

    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