A big step forward
I am sorry for such a late post. It has been a very long week for me and there was a lot to go over with this update.
Although it may not look like much in game, A very large chunk of the actual game has been finished this week. And a big part of that is thanks to one El Furriando, who wrote the code for spawning in and tracking the monsters stats as well as a basic AI code. It took me a little bit but I was able to integrate that code into the game as expand upon it a little bit and fix a small glitch with the old vision code.
So the majority of the code written this week builds off from the code that El Furriando wrote. I will take some time breaking down what it is doing. There will be a link toward the end that you can pull the code up, that might help you understand what it is doing and what I am talking about. :P
Although it gets a little more complicated than this I am going to give you the gist of what the monster manager is doing. To start it gets 100 timers ready and then preps a loop to tie to each individual timer to a monster. So as it is it can handle 100 monsters, which can be more but as is it needs 10kb of phoenix speak reserved already. Which means to finish this project I will need to be a silver subscriber. Which I am alright with, I had already planned on subscribing when the time was right. After that there is some initialization that happens clearing old monsters and data and setting the number of new monsters to be created and such. Then it goes on the spawner, which I find to be a really cool way to create and store monster data at the same time. So each time a timer goes off it checks which monster number will be there. It takes that number to use as the data base reference number then creates data to be stored in each of those containers. Hp, Ap, Ac, and such. When written these were hard coded but in integration I changed them to variables to work with the monster encyclopedia. Which allows very easy editing of monsters and their attributes. But I will get into that more later. So now that the monster handler has created all of the monster data it switches to an AI mode. Which at this point is just a basic random wander code that calls for a stop on movement when there is a nearby player. The Ai currently seems a little slow but that was by my asking when it was designed. They are all processed each second, but because I want to run a Action Point based system with a timed element they all currently move 33 percent of the time that they can. This system is robust as well. You can create more AI behaviors and tag them onto the end of the code and then just mark the monster type with the corresponding AI behavior. As I want the monster AI to be the biggest part of the game this makes me really happy. At the end of the code there is a simple reset of the timers. This post is getting a bit long so I won't get into how mass timers work and why the code needs to be between the setup and the reset. But a little spoiler it deals with how the dragon speak is read and processed by the server.
So after I had received that code from Furriando I had to integrate it into the system that I was already using in the game. It took a little bit of thought before I figured out how to break the code up while keeping it functional. But in the end I succeeded at that and it got fully integrated into the game. I decided I wanted to run the entire game off a single clock. So I got rid of the clock that I was originally using and set the timers used in the monster handler code at the beginning and end of the game. I took the parts from the initialization and added them to the games level initialization code. Which unfortunately is in two spots currently because of a small bug. I do plan on merging them again I just need to find an elegant solution for multiple ways to get to the initialization process. The spawner code was added to the area where I had the old spawning code. I adapted my old code to help load information from the game encyclopedia to the monster handler code. That way it can load in multiple different monsters depending on the level and other to be determined variables. And the AI code ended up in its own section, which it needs to be because it is going to become a very large part of the game. After that all got integrated in I started working on a way to put different information into the handler. The next part is a little difficult for me to explain. But pretty much when the level starts to build it checks to see what the depth is and then checks the hard coded information in the encyclopedia. The information is stored in strings and the information needs to be pulled out to be put into integers that can then be loaded into the monster handler. That is what is happening in the load mob data section of the code. It uses the markers in the string to systematically pull that relevant data and store them into holder variables. The code is repeated three times because for each level there can be three different monster types. Though with some good variable usage I am sure that it could be accomplished with one iteration of the code turned into a loop.
The last thing that I did was fix a bug that cropped up when the game clock was switched to 100 timers instead of the 10 it was running off of before. The code that that was handling the vision(the code that makes walls nearby players see through) triggered in off steps from the timers. This caused a blinking effect when players moved through the dungeon levels. To fix this when players enter the dungeon their names are added to a string. When the timer string goes off on the first timer it resets the walls to their non see through state. After that happens all the names are cycled through and makes them the triggering player. Their location can then be obtained and plugged into the vision code that makes the nearby walls see through. Because of the order and the speed that this happens it creates a seamless effect.
El Furriando's original monster handler code here
That about does it for the updates throughout this past week. Full source here
Although it may not look like much in game, A very large chunk of the actual game has been finished this week. And a big part of that is thanks to one El Furriando, who wrote the code for spawning in and tracking the monsters stats as well as a basic AI code. It took me a little bit but I was able to integrate that code into the game as expand upon it a little bit and fix a small glitch with the old vision code.
So the majority of the code written this week builds off from the code that El Furriando wrote. I will take some time breaking down what it is doing. There will be a link toward the end that you can pull the code up, that might help you understand what it is doing and what I am talking about. :P
Although it gets a little more complicated than this I am going to give you the gist of what the monster manager is doing. To start it gets 100 timers ready and then preps a loop to tie to each individual timer to a monster. So as it is it can handle 100 monsters, which can be more but as is it needs 10kb of phoenix speak reserved already. Which means to finish this project I will need to be a silver subscriber. Which I am alright with, I had already planned on subscribing when the time was right. After that there is some initialization that happens clearing old monsters and data and setting the number of new monsters to be created and such. Then it goes on the spawner, which I find to be a really cool way to create and store monster data at the same time. So each time a timer goes off it checks which monster number will be there. It takes that number to use as the data base reference number then creates data to be stored in each of those containers. Hp, Ap, Ac, and such. When written these were hard coded but in integration I changed them to variables to work with the monster encyclopedia. Which allows very easy editing of monsters and their attributes. But I will get into that more later. So now that the monster handler has created all of the monster data it switches to an AI mode. Which at this point is just a basic random wander code that calls for a stop on movement when there is a nearby player. The Ai currently seems a little slow but that was by my asking when it was designed. They are all processed each second, but because I want to run a Action Point based system with a timed element they all currently move 33 percent of the time that they can. This system is robust as well. You can create more AI behaviors and tag them onto the end of the code and then just mark the monster type with the corresponding AI behavior. As I want the monster AI to be the biggest part of the game this makes me really happy. At the end of the code there is a simple reset of the timers. This post is getting a bit long so I won't get into how mass timers work and why the code needs to be between the setup and the reset. But a little spoiler it deals with how the dragon speak is read and processed by the server.
So after I had received that code from Furriando I had to integrate it into the system that I was already using in the game. It took a little bit of thought before I figured out how to break the code up while keeping it functional. But in the end I succeeded at that and it got fully integrated into the game. I decided I wanted to run the entire game off a single clock. So I got rid of the clock that I was originally using and set the timers used in the monster handler code at the beginning and end of the game. I took the parts from the initialization and added them to the games level initialization code. Which unfortunately is in two spots currently because of a small bug. I do plan on merging them again I just need to find an elegant solution for multiple ways to get to the initialization process. The spawner code was added to the area where I had the old spawning code. I adapted my old code to help load information from the game encyclopedia to the monster handler code. That way it can load in multiple different monsters depending on the level and other to be determined variables. And the AI code ended up in its own section, which it needs to be because it is going to become a very large part of the game. After that all got integrated in I started working on a way to put different information into the handler. The next part is a little difficult for me to explain. But pretty much when the level starts to build it checks to see what the depth is and then checks the hard coded information in the encyclopedia. The information is stored in strings and the information needs to be pulled out to be put into integers that can then be loaded into the monster handler. That is what is happening in the load mob data section of the code. It uses the markers in the string to systematically pull that relevant data and store them into holder variables. The code is repeated three times because for each level there can be three different monster types. Though with some good variable usage I am sure that it could be accomplished with one iteration of the code turned into a loop.
The last thing that I did was fix a bug that cropped up when the game clock was switched to 100 timers instead of the 10 it was running off of before. The code that that was handling the vision(the code that makes walls nearby players see through) triggered in off steps from the timers. This caused a blinking effect when players moved through the dungeon levels. To fix this when players enter the dungeon their names are added to a string. When the timer string goes off on the first timer it resets the walls to their non see through state. After that happens all the names are cycled through and makes them the triggering player. Their location can then be obtained and plugged into the vision code that makes the nearby walls see through. Because of the order and the speed that this happens it creates a seamless effect.
El Furriando's original monster handler code here
That about does it for the updates throughout this past week. Full source here
Comments
Post a Comment