Wednesday May 29, 2013
This past week was an exciting one. Matt and I revised the game code to allow it to read in levels the same way the level editor reads in levels. We also got the game to display multiple monsters on the screen at the same time. We were also able to interact with both of those entities separately, which is a major stride. Matt began creating the QA level in the level editor and it will be finished by the end of the week. We are going to work on implementing code that would randomly disperse the monsters around the QA level and spawn more over time. We want people to be able to level up at least once or twice in order to test balance with the experience ratios and the stat upgrades when people do level up.
I may end up tweaking the experience per level before testing begins. I think it is going to be really high if I leave it the way it is, but I have not tested it yet. Friday will be interesting as that will be our first glance at how the testing level will work out. We should have everything we need for the level to work correctly. Matt just has to take care of allowing the player to see their stats and experience in a menu. He designed the menu system, so I do not like messing with it. It is a rather complex framework, but it works really well.
Wednesday, May 29, 2013
Wednesday, May 22, 2013
Dev Blog #2
Wednesday May 22, 2013
This past week Matt and I finalized the level editor for our game. It was a major triumph seeing the output from the editor in the correct format, after coding the save function once. The only change I had to make to that function was making it output the actual number, not the data stored in memory at that location. Minor flaw, but nonetheless it was practically a one shot success. In programming, nothing feels better than getting something right the first time.
I ended up rewriting the whole battle system, which included moving the damage calculations out of the battle state and putting them into the player and monster base classes. This gives direct access to the stats of each entity, instead of having to access them in long strings of function calls in the battle state. I also had to rewrite some other functions inside the player and monster classes, which meant moving some of them into the base Entity class, of which monster and player are extended. Simple ones that every class needed to have, so the move was inevitable and I am glad I did it now.
For next week, Matt and I are going to finalize the text parser we have for reading in data, creating an area for the QA testing portion of the class that will include enemies and an area boss and creating some assets. The player will be able to level up in this testing area so we can tweak the leveling process.
The leveling process was written by me haphazardly. I found some formulas online for experience gain and experience needed for the next level, and I adjusted one of them to output much less experience. Basically, I cut it in half.
More next week after we get the testing level set up and ready to go.
This past week Matt and I finalized the level editor for our game. It was a major triumph seeing the output from the editor in the correct format, after coding the save function once. The only change I had to make to that function was making it output the actual number, not the data stored in memory at that location. Minor flaw, but nonetheless it was practically a one shot success. In programming, nothing feels better than getting something right the first time.
I ended up rewriting the whole battle system, which included moving the damage calculations out of the battle state and putting them into the player and monster base classes. This gives direct access to the stats of each entity, instead of having to access them in long strings of function calls in the battle state. I also had to rewrite some other functions inside the player and monster classes, which meant moving some of them into the base Entity class, of which monster and player are extended. Simple ones that every class needed to have, so the move was inevitable and I am glad I did it now.
For next week, Matt and I are going to finalize the text parser we have for reading in data, creating an area for the QA testing portion of the class that will include enemies and an area boss and creating some assets. The player will be able to level up in this testing area so we can tweak the leveling process.
The leveling process was written by me haphazardly. I found some formulas online for experience gain and experience needed for the next level, and I adjusted one of them to output much less experience. Basically, I cut it in half.
More next week after we get the testing level set up and ready to go.
Wednesday, May 15, 2013
Dev Blog #1
Wednesday May 15, 2013
Matt and I are off to a great start. Over the spring break Matt began working on a level editor that we can use to quickly and accurately create maps that have the correct data we need for the game to run. It is almost done, he just needs to implement the export function that will write the data to a text file and will allow us to read in that text file into game data.
I worked this week on adding in functionality to the player and monster classes that allow for leveling up and experience gaining. This is really not as hard as it sounds. It was merely adding in a few variables in both classes, their respective setters and getters and some other functions that are either for debug purposes or that give us added features that may or may not stay in the final build. I have to focus next on re-writing the entire battle system to move the damage calculations into the monster and player classes. This will allow us direct access to the stats of each entity without needing multiple functions calls if we keep it in the battle state. I also need to implement the experience gaining system for when the player defeats an enemy. Matt is going to work on getting items to randomly drop from defeated enemies. A message box will pop up saying something like "Entity dropped an item! Would you like to take it with you?" and the player will be able to select yes or no. That statement is generic and will contain specific elements like the enemy's name and the name of the item that was dropped. We figured that this way was much easier to accomplish than actually having an item drop on the ground and be visible to the player. It is less coding and a lot of games do it this way.
Matt and I are off to a great start. Over the spring break Matt began working on a level editor that we can use to quickly and accurately create maps that have the correct data we need for the game to run. It is almost done, he just needs to implement the export function that will write the data to a text file and will allow us to read in that text file into game data.
I worked this week on adding in functionality to the player and monster classes that allow for leveling up and experience gaining. This is really not as hard as it sounds. It was merely adding in a few variables in both classes, their respective setters and getters and some other functions that are either for debug purposes or that give us added features that may or may not stay in the final build. I have to focus next on re-writing the entire battle system to move the damage calculations into the monster and player classes. This will allow us direct access to the stats of each entity without needing multiple functions calls if we keep it in the battle state. I also need to implement the experience gaining system for when the player defeats an enemy. Matt is going to work on getting items to randomly drop from defeated enemies. A message box will pop up saying something like "Entity dropped an item! Would you like to take it with you?" and the player will be able to select yes or no. That statement is generic and will contain specific elements like the enemy's name and the name of the item that was dropped. We figured that this way was much easier to accomplish than actually having an item drop on the ground and be visible to the player. It is less coding and a lot of games do it this way.
Tuesday, April 23, 2013
Development Blog #7
Tuesday April 23, 2013
This is going to be a very short blog. I worked on fixing what I could in the GDD, and sent it off to Matt for approval and for him to add a couple screenshots of certain menus that we did not have programmed the first time we submitted the GDD.
We also worked over Skype on implementing the shop feature and sounds. Matt walked me through how to use the code he wrote for our menu system, as I have yet to really touch it. He has been handling all of the menu stuff, and it is about time that I learn. We got the shop feature working and were able to see the bought item in the player's inventory.
That is all for this session and GSP 361. I will be writing again on the development of Project: DImension (still a working title) when GSP 362 starts up in a few weeks. Until then, happy coding.
This is going to be a very short blog. I worked on fixing what I could in the GDD, and sent it off to Matt for approval and for him to add a couple screenshots of certain menus that we did not have programmed the first time we submitted the GDD.
We also worked over Skype on implementing the shop feature and sounds. Matt walked me through how to use the code he wrote for our menu system, as I have yet to really touch it. He has been handling all of the menu stuff, and it is about time that I learn. We got the shop feature working and were able to see the bought item in the player's inventory.
That is all for this session and GSP 361. I will be writing again on the development of Project: DImension (still a working title) when GSP 362 starts up in a few weeks. Until then, happy coding.
Saturday, April 20, 2013
Development Blog #6
Saturday, April 20, 2013
So here we are, down to the wire on this project. The Alpha build presentation is coming up on Wednesday and the game is shaping up to be something really neat. Matt and I are both very proud of the fact that we wrote an entire game engine from scratch that is mostly non-game specific. It could be applied to any other game we wanted to write, with minor changes.
The final things we are taking care of are implementing the shop feature for the city level (we already have the merchant drawn on the screen, just need the functionality), drawing the enemy on the battle screen (we already have the player drawn), allowing the player to move between the city and the forest level and implementing interaction between the bear enemy and the player in the forest level that will initiate a battle. These are all very easy to implement and will take minimal code to accomplish. I want to take this time to thank Matt for all of the work he did with the heavy graphics portion of this project. I am not a graphics genius by any means, and he made something so simple and easy to use. I look forward to completing this project next session with him.
Looking forward, Matt is going to write a level editor over our spring break which will allow us to quickly create levels for the game (as for now the are hard coded into the game itself). This will spit out a text file with symbols in it, which will then be read in by the file i/o system we have in place. The symbols will correspond to a specific tile, and that tile will then be drawn on screen. We also want to add in small touches to different aspects of the game, like animations during battle so you can see both the player and enemy attacking. We also want to implement the team feature we designed in the early stages of development which would allow the player to have a team of animals and people to help them fight their way to the end of the game. I may or may not post something here for download that you would be able to test out and see what we have. That might come at the end of next session, when the game is fully developed.
So here we are, down to the wire on this project. The Alpha build presentation is coming up on Wednesday and the game is shaping up to be something really neat. Matt and I are both very proud of the fact that we wrote an entire game engine from scratch that is mostly non-game specific. It could be applied to any other game we wanted to write, with minor changes.
The final things we are taking care of are implementing the shop feature for the city level (we already have the merchant drawn on the screen, just need the functionality), drawing the enemy on the battle screen (we already have the player drawn), allowing the player to move between the city and the forest level and implementing interaction between the bear enemy and the player in the forest level that will initiate a battle. These are all very easy to implement and will take minimal code to accomplish. I want to take this time to thank Matt for all of the work he did with the heavy graphics portion of this project. I am not a graphics genius by any means, and he made something so simple and easy to use. I look forward to completing this project next session with him.
Looking forward, Matt is going to write a level editor over our spring break which will allow us to quickly create levels for the game (as for now the are hard coded into the game itself). This will spit out a text file with symbols in it, which will then be read in by the file i/o system we have in place. The symbols will correspond to a specific tile, and that tile will then be drawn on screen. We also want to add in small touches to different aspects of the game, like animations during battle so you can see both the player and enemy attacking. We also want to implement the team feature we designed in the early stages of development which would allow the player to have a team of animals and people to help them fight their way to the end of the game. I may or may not post something here for download that you would be able to test out and see what we have. That might come at the end of next session, when the game is fully developed.
Friday, April 12, 2013
Development Blog #5
Friday, April 12 2013
Today was a long, laborious day. Matt and I worked on a lot of bug fixes and polishing of the framework that we know works. I had to re-write the entire Sound engine today, as something was going on with Lightweight Java Game Library and OpenAL. Something about corrupted files inside the LWJGL libraries. I have no idea. So, Matt did some research and found that the Slick util libraries handle OpenAL on their own as well (as, I guess, Java supports .wav files out of the box on its own). It turns out, there was about half as much code needed in order to write the Sound engine using the Slick utils.
So we tested the Sound engine, and lo and behold, it worked flawlessly. We tested it with playing two sounds at once, and it handled that beautifully as well.
I also spent a lot of time re-writing the way we are reading in data from text files. Originally, there was an outer While loop and an inner For loop that handled the saving of data from a text file into actual objects. The problem was that the loop seemed to both reset itself and would never exit the loop (that one was purely my fault, as I never closed the BufferedReader after I was done using it). I ended up redoing the loops and using two While loops to get the job done. It is ugly and hacky, but hey, it works. I just now have to figure out how to exit a try-catch without throwing an exception (because the try portion completes successfully but it still goes on to the catch due to a bug that I am trying to fix).
Today was a long, laborious day. Matt and I worked on a lot of bug fixes and polishing of the framework that we know works. I had to re-write the entire Sound engine today, as something was going on with Lightweight Java Game Library and OpenAL. Something about corrupted files inside the LWJGL libraries. I have no idea. So, Matt did some research and found that the Slick util libraries handle OpenAL on their own as well (as, I guess, Java supports .wav files out of the box on its own). It turns out, there was about half as much code needed in order to write the Sound engine using the Slick utils.
So we tested the Sound engine, and lo and behold, it worked flawlessly. We tested it with playing two sounds at once, and it handled that beautifully as well.
I also spent a lot of time re-writing the way we are reading in data from text files. Originally, there was an outer While loop and an inner For loop that handled the saving of data from a text file into actual objects. The problem was that the loop seemed to both reset itself and would never exit the loop (that one was purely my fault, as I never closed the BufferedReader after I was done using it). I ended up redoing the loops and using two While loops to get the job done. It is ugly and hacky, but hey, it works. I just now have to figure out how to exit a try-catch without throwing an exception (because the try portion completes successfully but it still goes on to the catch due to a bug that I am trying to fix).
Saturday, April 6, 2013
Development Blog #4
Saturday, April 6 2013
I apologize for this being late, as I totally dropped the ball on posting yesterday.
So, this week Matt and I wanted to focus heavily on getting our battling system up and running with some dummy data. And lo and behold, we succeeded. Below you will find a code snippet from the battle system we are using:
do{
if(playerTurn == true)
{
while(playerTurn == true){
KeyListener();
Display.update();
Display.sync(60);
if(chosenAttack != null)
{
enemies.get(0).setHealth(enemies.get(0).getHealth() - calcDamage(chosenAttack));
//check to see if enemy is dead
if(enemies.get(0).getHealth() <= 0)
{
enemies.remove(0);
}
playerTurn = false;
}
/*if(chosenItem != null)
{
playerTurn = false;
}*/
}
enemyTurn = true;
}
if(enemyTurn == true)
{
Attack a = enemies.get(0).getAttack(Vector.random(0, 3));
player.setHealth(player.getHealth() - calcDamage(a));
System.out.println("The enemy did "+ calcDamage(a) + " points of damage.");
playerTurn = true;
enemyTurn = false;
}
Display.update();
Display.sync(60);
}
while(player.getHealth() > 0 || enemies.size() != 0);
If that looks a little ugly, both the Blogger formatting and the actual code, I know. I tried for hours to get something onto Blogger that would look like a scrolling code box, but nothing wanted to work (and I am not a web programmer).
So, what you see there is the meat of our battle system. There are a few portions missing, as I worked on it on Matt's laptop towards the end of our meeting yesterday and forgot to grab a copy of it, but you get the gist. The first portion of the code, which you cannot see here, checks to see which attacks the player has enabled out of their repertoire of attacks. This forces the player to only have 4 attacks available to them during any battle. They can change these attacks outside of battle, but not inside. The other part you do not see is the code where we determine who goes first, the player or the enemy, based on their speeds. That part is fairly straightforward, so I will not go into detail about it.
What you see above is how the actual battle system works. It is encased in a do, while loop in order to keep the battle going until either the player dies or the enemy dies. The chosenAttack variable you see stores the attack the player chose from the menu that shows up during battle. We needed a way for the UI to interact with the game, and that was the solution we came up with. The piece of code you may not understand is this portion:
Attack a = enemies.get(0).getAttack(Vector.random(0, 3));
This piece of code sets an Attack object a to a random attack pulled from the attack ArrayList that every monster has. The Vector.random is a function Matt built in order for us to be able to generate a random number between a minimum and maximum value. The enemies.get(0) is a hacky piece of code we are using at the moment until we get actual data to work with. It pulls the first object from the enemies ArrayList that is local to the battle system. When we have actual data to work with (which means, more enemies to fight at any given time in a single battle), this portion of the code will change to reflect whose turn it is in the battle.
Hope you all enjoyed a look into the code of our project in its current stage, and if you have any questions, leave a comment below.
I apologize for this being late, as I totally dropped the ball on posting yesterday.
So, this week Matt and I wanted to focus heavily on getting our battling system up and running with some dummy data. And lo and behold, we succeeded. Below you will find a code snippet from the battle system we are using:
do{
if(playerTurn == true)
{
while(playerTurn == true){
KeyListener();
Display.update();
Display.sync(60);
if(chosenAttack != null)
{
enemies.get(0).setHealth(enemies.get(0).getHealth() - calcDamage(chosenAttack));
//check to see if enemy is dead
if(enemies.get(0).getHealth() <= 0)
{
enemies.remove(0);
}
playerTurn = false;
}
/*if(chosenItem != null)
{
playerTurn = false;
}*/
}
enemyTurn = true;
}
if(enemyTurn == true)
{
Attack a = enemies.get(0).getAttack(Vector.random(0, 3));
player.setHealth(player.getHealth() - calcDamage(a));
System.out.println("The enemy did "+ calcDamage(a) + " points of damage.");
playerTurn = true;
enemyTurn = false;
}
Display.update();
Display.sync(60);
}
while(player.getHealth() > 0 || enemies.size() != 0);
If that looks a little ugly, both the Blogger formatting and the actual code, I know. I tried for hours to get something onto Blogger that would look like a scrolling code box, but nothing wanted to work (and I am not a web programmer).
So, what you see there is the meat of our battle system. There are a few portions missing, as I worked on it on Matt's laptop towards the end of our meeting yesterday and forgot to grab a copy of it, but you get the gist. The first portion of the code, which you cannot see here, checks to see which attacks the player has enabled out of their repertoire of attacks. This forces the player to only have 4 attacks available to them during any battle. They can change these attacks outside of battle, but not inside. The other part you do not see is the code where we determine who goes first, the player or the enemy, based on their speeds. That part is fairly straightforward, so I will not go into detail about it.
What you see above is how the actual battle system works. It is encased in a do, while loop in order to keep the battle going until either the player dies or the enemy dies. The chosenAttack variable you see stores the attack the player chose from the menu that shows up during battle. We needed a way for the UI to interact with the game, and that was the solution we came up with. The piece of code you may not understand is this portion:
Attack a = enemies.get(0).getAttack(Vector.random(0, 3));
This piece of code sets an Attack object a to a random attack pulled from the attack ArrayList that every monster has. The Vector.random is a function Matt built in order for us to be able to generate a random number between a minimum and maximum value. The enemies.get(0) is a hacky piece of code we are using at the moment until we get actual data to work with. It pulls the first object from the enemies ArrayList that is local to the battle system. When we have actual data to work with (which means, more enemies to fight at any given time in a single battle), this portion of the code will change to reflect whose turn it is in the battle.
Hope you all enjoyed a look into the code of our project in its current stage, and if you have any questions, leave a comment below.
Subscribe to:
Posts (Atom)