Tonight ive been reading up on something that struck me while i was pondering the options I have for storing game data. If I create a new guest object at regular intervals, how do I make sure they arent sticking around, especially if I intend to simulate large numbers with any combination of ai activities.
Luckily there are some great summaries of the Java garbage collector that didnt get too science heavy for me. When a reference to a variable is lost, either through scope, reassignment or to lack of use, Java checks the programs memory for any variables or methods that may still have access to that memory address. Those suffering from abandonment are removed from memory by a low priority thread in the jvm. My problem was then, are my guests being deleted when they leave or were they living on. In order to figure it out I had to have my guest class increment a static counter each time its Constructor was called, and my Hostess class keep a tab on the number of guests at active tables. The first revelation found was that the hostess was creating groups even when the queue was full, and discarding them when they were rejected. While this wouldnt have been a huge memory problem, it was a simple fix to ensure the groupGenerator was not called unless the queue had room for more groups. After that I went about cutting ties to any groups that were done eating and had 'paid'. To do this I created a method in the Guest class to null any modified variables. This method was probably overkill! After any guests were gutted, the Group itself breaks ties with the Guest array, and the table breaks ties with the Group by disbanding. While any performance changes are probably negligible, it was good to think about the data being stored and how I want any large objects to kill their data before disconnecting from use in the game.
Luckily there are some great summaries of the Java garbage collector that didnt get too science heavy for me. When a reference to a variable is lost, either through scope, reassignment or to lack of use, Java checks the programs memory for any variables or methods that may still have access to that memory address. Those suffering from abandonment are removed from memory by a low priority thread in the jvm. My problem was then, are my guests being deleted when they leave or were they living on. In order to figure it out I had to have my guest class increment a static counter each time its Constructor was called, and my Hostess class keep a tab on the number of guests at active tables. The first revelation found was that the hostess was creating groups even when the queue was full, and discarding them when they were rejected. While this wouldnt have been a huge memory problem, it was a simple fix to ensure the groupGenerator was not called unless the queue had room for more groups. After that I went about cutting ties to any groups that were done eating and had 'paid'. To do this I created a method in the Guest class to null any modified variables. This method was probably overkill! After any guests were gutted, the Group itself breaks ties with the Guest array, and the table breaks ties with the Group by disbanding. While any performance changes are probably negligible, it was good to think about the data being stored and how I want any large objects to kill their data before disconnecting from use in the game.
Today I also began sketching out a plan for the task system and how it could be implemented. Using tasks and a queue will allow me to break ai into much smaller chunks and simply list the steps needed to complete a task. It also allows me the future ability to add task transfer from one ai to another, effectively creating a means for waiters to really communicate and help each other out. I want to really have a good plan laid out before any of that system goes into the code though, id rather get the head scratching done before than during!
No comments:
Post a Comment