1. Object creation I don't let the game directly create objects? For two aspects: 1> Who needs to create a game object? Who is it to manage? 2> Who will delete the game object? 3> This way, the disk saving function of the C object can also be reused. (This must use RTTI)
Think about how the object in the bomber game is deleted, mostly not deleted by the creator. For example, if the object is on the flame, most of it receives an event or other external factors. Therefore, it is not deleted due to event builders such as characters.
In addition, if the characters have a heart-sensing, it is possible to remotely detonate the bomb. In the intuitive look, the characters just notify the bomb one event. There is also no object producer (character) to delete the generated object (bomb).
Also, if the creation and deletion of the object is done in the same place, you can manage the memory area of the object, without having to allocate memory space for each generated object.
Therefore, the specific creation of the object is just the live-related management code, is not the code of our game logic.
2.ID Manager Because I need to join the network function, the operation of the game object uses ID instead of a pointer. If I use ID, I don't want to have too much impact on performance, so I have not used Map. Use the arrays of C directly. The purpose of ID reference count is to prevent some people from reference to a ID, but this ID is redistributed (not just released). Then reference the object will use the wrong ID.
Conclusion: 1. Object creation and deletion, whether it is data read from the disk or the object generated inside the code. Uniform use an interface cgamefactory.2. All objects have an integer ID in the unique non-repetitive, and use it ID is the subscript of the C array (efficiency)
