Jorge Castaneda: Get Ready For An Overhaul; End of Month 2

On the last week of Month 2 I took an adventure through refactoring code to add a feature and solve a bug. For those unaware refactoring is the act of going back to old functioning code and rewriting it to make it better in some quality. This could be performance, code could be running too slowly, or modularity, the code may depend on too much other code and therefore be unable to be reused, or maybe to overwrite old functionality, getting rid of/ replacing old code that is no longer needed, or various other reasons. In this case it was both for performance and to overwrite old functionalities.

The Bug:

I identified a soft error that was preventing the merger from activating when hit by certain lasers. The merger was ignoring specific lasers. So I tracked down a commonality between these lasers. It turns out they all had the same identification number. Since they were all saying they were the same laser, the merger was ignoring the copycats. This all came from how Ids were currently being adjusted. The Ids were being incremented in every new laser with the exception of splitters which were adding 100 and 1000 to the other two lasers it produced. in that case when you sent a laser through a splitter and those into two other splitters an over lap occurs between the laser that get 1 and then 100 added to it and another laser that gets 100 and then 1 added to it. That is problematic. Thankfully there was functionality I had already planned to add that could be used to solve this issue. Object pooling.

Pool Parties and performance:

An Object pool is a system for adding some early processing to ease future processes. There is a cost to instantiation, the creation of objects and their associated components. Every time you instantiate the computer has to build an object from scratch add all its components and run all of its starting code, and fill all the variables with preset values. This is a costly process. The more components and the more child objects an object has then the more cost in making it. Now in a normal setting what most do is just instantiate objects when they are needed. This is actually fairly optimal if the instantiation is only required a few times per scene. However in the case of objects that you know will be instantiated and destroyed constantly this is not optimal. Like in the case of our lasers. However there is a good work around for this poor performance. Object pooling. A process akin to recycling. First at the beginning of a scene you estimate the number of an lasers that will likely be in the scene at a single time. Then you instantiate that many lasers from the get go and you store them out of sight and inactive. Then when you need them you distribute them from the pool to place they are needed. When they normally would be destroyed instead you return them to the pool. The cost of pooling is simple: the cost of creation is taken early on but less objects are created in total.

Squashing the Bug:

Now that the laser pool is created how can it help with that bug from earlier? The issue was that lasers did not have unique identification. This was because we were making the lasers as they were needed and then assigning them ids based on the previous laser’s id. However with the implementation of a laser object pool the lasers were no longer being created. They already existed. This means that they could all have unique ID’s assigned to them before any laser transform uses them. Therefore making it impossible for id overlap to cause issues.

Overwriting Old Functionality:

So you have an object pool and an old implementation that doesn’t use it. Its time to overwrite the old functionality that creates, destroys, or changes the Id of a laser (since that would defeat the purpose). Unfortunately for me that was a massive overhaul but while I was at it I refactored some of the code that was less then favorable. Like the splitter was way larger than it need to be and unwieldy when it came to choosing the color each nozzle will fire. As well as fixing an earlier bug when rotating a splitter when there are 3 lasers. I basically told the rest of the group not to touch and laser related classes for a day and a half. However it worked almost immediately.

So that is how I solved a game breaking bug as well as upping the performance of the game. I am pretty happy with this last build of the month.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s