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

ECS: Entity Parsing, Hacky Factory Method Approach

4/8/2015

0 Comments

 
Okay so I started looking into re-implementing the entity parsing code and there was so much I didn't like about it the way it was currently done. Clearly in my previous implementation I just wanted to get something up and running as soon as possible, no surprise there. I basically had a class that had a massive switch statement based on the component name and then unpacked the xml and called the constructor. This time round however I wanted to make it as easy as possible for a user of the engine to create new components and start using them, which was the whole reason for the ECS re-factor.

First Approach

The first and main idea I found was based on an article written back in 1998 by Jim Beveridge called: self registering classes in C++. Essentially this approach used static initialisation to add an instance of a proxy object for each component to a vector which could then be used to create instances of the component itself. 

At this moment in time it is actually the way I have it working but at the time of writing this I am thinking about trying out a different method.

This approach does work at the moment and the main advantage of it is that all that needs to be done is that after the definition of the new component you just have to create a global version of the proxy templated with the new component and away you go, you can create instances of your new component based on it's name.

There are a lot of reasons I'm sceptical about this:
  • Wow does this seem incredibly hacky!!
  • From what I've read in forum posts across the internet static initialisation can cause incredibly hard to track bugs.
  • Static initialisation can act differently depending on compiler, meaning this code may not work correctly when compiled on linux( something I'm wanting to do in the near future )
  • There will be tons of globals all over the place
  • A component will always be available if it's being compiled, unless you remember to remove the global proxy declaration.

So like I said I have literally just thought about trying a different way and here it is: 

Second Approach

Essentially it will work in a very similar way, there will be the concept of a "Component Store" as noted in the webpage I have linked. This will still hold a vector of proxy objects for creating components. Instead of doing all the hacky static initialisation stuff and having global declarations of things I will just fill the vector at runtime. Right at the initialisation of the engine, before any parsing can be done the Component store will run a function to populate it's vector. This itself has a few drawbacks:
  • The Component Store will need to have a huge function adding proxy objects for all the components in the entire game.
  • The Component Store will have to #include every component in the entire game. 
  • This will cause a slow down at program start up whilst this vector is populated.
  • Every time a component is added to the game, the user will have to remember to add it to the list.

Okay that seems like quite a lot of potential drawbacks but If I was to go down the route of the first approach and then come to try and get it to build on Linux or OSX to find it doesn't work then that would require a lot more work. I actually understand how the code works in this second approach as well which is much more valuable than it seems. 

Conclusion

So I have a lot more work ahead of me, I am hoping that this next part converting to the new simpler approach won't take that long. I am really glad I did this blog post before fleshing out the components using the Static Initialisation method as it would have meant even more wasted time. 

Setting myself a deadline of next Tuesday to have the new approach implemented for Components and to have done a blog post about it.

Thanks :)
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