Tuesday June 25, 2013
Here we are, at the end of our journey. Matt and I have worked tirelessly on this project for the past 16 weeks, and we are very proud of the things we accomplished. We both learned a ton from making this game from the ground up and we have become better programmers for doing so. You can find the website for the game at LINK where you can see some information about the game, Matt and myself and view the trailer we made for the game. There is also a download link on the website so you can try the game for yourself and let us know how you like it and what we could have done to make it better. I will admit that the game is very short, but the point of this class was to take an idea from concept to code and make it work. We did that and our game came out really good.
I hope you enjoyed reading about the game and, at least, my ideas behind the game. You got to see some code that no one else got to see. I also hope you learned something or got a different view on something you already knew. Thanks for reading. Until next time.
Tuesday, June 25, 2013
Wednesday, June 19, 2013
Dev Blog #6
Wednesday June 19, 2013
Here we are, down to the final week of development. Matt and I had our weekly meeting with our professor on Monday and he seemed really happy with what we had. He only had a few requirements of us. The two major ones are animations during battle and a gear system. The battle animations are an easy fix. All we need to do is create either another sprite sheet for each monster or make more cells in their existing sprite sheet that has a few frames in it. The frames would alternate between the entity being drawn and not drawn, and when played would give a flickering effect. The gear is a little bit trickier. Matt has to create a new menu that will show equipped gear and I have to make sure that the items draw in the correct slots. That shouldn't be too bad. Then I have to make sure the gear affects the stats correctly, which won't be too bad either.
Matt also has to send me his information for the website and has to create the trailer for the game, as I am handling the website. We also have to make posts to our Career Web Portfolios with information about this project, as DeVry is making that a bigger part of our curriculum. We shall see how this week plays out. Until next week.
Here we are, down to the final week of development. Matt and I had our weekly meeting with our professor on Monday and he seemed really happy with what we had. He only had a few requirements of us. The two major ones are animations during battle and a gear system. The battle animations are an easy fix. All we need to do is create either another sprite sheet for each monster or make more cells in their existing sprite sheet that has a few frames in it. The frames would alternate between the entity being drawn and not drawn, and when played would give a flickering effect. The gear is a little bit trickier. Matt has to create a new menu that will show equipped gear and I have to make sure that the items draw in the correct slots. That shouldn't be too bad. Then I have to make sure the gear affects the stats correctly, which won't be too bad either.
Matt also has to send me his information for the website and has to create the trailer for the game, as I am handling the website. We also have to make posts to our Career Web Portfolios with information about this project, as DeVry is making that a bigger part of our curriculum. We shall see how this week plays out. Until next week.
Thursday, June 13, 2013
Dev Blog #5
Thursday June 13, 2013
Sorry for this blog being late. I totally forgot last night to write one. This week I will have a code snippet to show you guys in illustrate one of the issues with OOP that can be somewhat frustrating to fix if you don't know where to look.
The problem stemmed from a bug Matt and I were having with items. You could use items just fine and buy items, but that is where the problem reared its nasty head. When you would go to buy potions from the merchant, the game would show you buying 1 potion and then get stuck at 2 potions left in the shop. If you left the shop interface and opened your inventory, there were 2 potions there, even though the game only showed you buying 1. If you used 1 potion or both, the amount in the shop would go down to 1. It frustrated me for days. Finally, I had a breakthrough two days ago.
I saw that we weren't giving the player a brand new version of the item he was trying to buy. We were essentially copying the exact item the merchant had, which is not a good idea in languages like Java. Java passes everything by reference by default, so if you gave the player an item directly from the merchant, those two items were tied together in memory. So, my idea was to set a bunch of variables to hold the data from the item you were trying to buy and then pass those to the constructor for the Pickups class. Then, that Pickups constructor was used as a parameter for the giveItem() function that is part of the InventoryManager class. I will show you in the code snippet below:
This is only a partial code snippet, but it illustrates my point:
if(tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getStackable())
{
int i = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemID();
int d = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getDefence();
int a = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getAttack();
int h = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getHealth();
double s = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getSpeed();
String n = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemName();
boolean b = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getStackable();
int m = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getMaxStack();
String type = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemType();
EntityManager.getInstance().getDaniel().getInvManager().giveItem(new Pickups(i,d,a,h,s,n,b,m,1, type));
}
Blogger isn't the best on HTML tags, so I just pasted in the code. If it is difficult to read, I apologize. The initial if-statement checks to see if the item you are trying to buy is stackable. Why, you ask? Because stackable and non-stackable items are handled differently by the engine. Above this initial if-statement there is another one that check to see if the item you are trying to buy is already in your inventory. If it is, there is a different part of the code that just adds 1 whenever you buy that item. If it isn't in your inventory, the engine creates a brand new object (you can see this happening in the last line of the code) and places it into an arraylist.
Moral of the story: Be careful about how you pass object around. It could have some nasty consequences that will leave you with a ton of headaches over such a simple coding error.
Sorry for this blog being late. I totally forgot last night to write one. This week I will have a code snippet to show you guys in illustrate one of the issues with OOP that can be somewhat frustrating to fix if you don't know where to look.
The problem stemmed from a bug Matt and I were having with items. You could use items just fine and buy items, but that is where the problem reared its nasty head. When you would go to buy potions from the merchant, the game would show you buying 1 potion and then get stuck at 2 potions left in the shop. If you left the shop interface and opened your inventory, there were 2 potions there, even though the game only showed you buying 1. If you used 1 potion or both, the amount in the shop would go down to 1. It frustrated me for days. Finally, I had a breakthrough two days ago.
I saw that we weren't giving the player a brand new version of the item he was trying to buy. We were essentially copying the exact item the merchant had, which is not a good idea in languages like Java. Java passes everything by reference by default, so if you gave the player an item directly from the merchant, those two items were tied together in memory. So, my idea was to set a bunch of variables to hold the data from the item you were trying to buy and then pass those to the constructor for the Pickups class. Then, that Pickups constructor was used as a parameter for the giveItem() function that is part of the InventoryManager class. I will show you in the code snippet below:
This is only a partial code snippet, but it illustrates my point:
if(tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getStackable())
{
int i = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemID();
int d = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getDefence();
int a = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getAttack();
int h = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getHealth();
double s = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getSpeed();
String n = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemName();
boolean b = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getStackable();
int m = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getMaxStack();
String type = tempNPC.getItems().get(ShopInventory.getMerchantSlot()).getItemType();
EntityManager.getInstance().getDaniel().getInvManager().giveItem(new Pickups(i,d,a,h,s,n,b,m,1, type));
}
Blogger isn't the best on HTML tags, so I just pasted in the code. If it is difficult to read, I apologize. The initial if-statement checks to see if the item you are trying to buy is stackable. Why, you ask? Because stackable and non-stackable items are handled differently by the engine. Above this initial if-statement there is another one that check to see if the item you are trying to buy is already in your inventory. If it is, there is a different part of the code that just adds 1 whenever you buy that item. If it isn't in your inventory, the engine creates a brand new object (you can see this happening in the last line of the code) and places it into an arraylist.
Moral of the story: Be careful about how you pass object around. It could have some nasty consequences that will leave you with a ton of headaches over such a simple coding error.
Wednesday, June 5, 2013
Dev Blog #4
Wednesday June 5, 2013
This past week Matt and I submitted our QA build for testing. We spent a lot of hours the day and night before fixing bugs and implementing features that needed to be tested. When we were done, we submitted the build to our professor. Monday rolled around and our game was there, up and running for people to test out. It really is an amazing feeling seeing something you worked so hard on being tested and critiqued by others. All of the people that I watched test the game seemed to like it a lot, although there were a few bugs that were unintended. First off, the area boss was unbeatable. No matter what you did, you couldn't beat him. That was my bad. I overestimated the amount of stats the player would get by killing all of the other enemies in the area when I set up that feature. Although, the battle system worked beautifully. There was a funny bug that was discovered through testing.
The bug stems from me not range checking the damage done during battle. In this build, it is possible to do negative damage, which would add health to your enemy. The lower level enemies were also able to do negative damage to you, which would heal you. Another bug came from almost the same thing. When trying to select the Use option on an empty inventory slot, the game would crash. This came from the game trying to check an element in an array that simply wasn't there. I fixed that bug earlier, and it was a simple fix.
Matt and I have a lot of work to do over the next few weeks. We have a lot of features to fine tweak, balance to do on monsters and levels to create. It is going to be a hectic next few weeks trying to get everything done in time for our presentation in Week 8.
This past week Matt and I submitted our QA build for testing. We spent a lot of hours the day and night before fixing bugs and implementing features that needed to be tested. When we were done, we submitted the build to our professor. Monday rolled around and our game was there, up and running for people to test out. It really is an amazing feeling seeing something you worked so hard on being tested and critiqued by others. All of the people that I watched test the game seemed to like it a lot, although there were a few bugs that were unintended. First off, the area boss was unbeatable. No matter what you did, you couldn't beat him. That was my bad. I overestimated the amount of stats the player would get by killing all of the other enemies in the area when I set up that feature. Although, the battle system worked beautifully. There was a funny bug that was discovered through testing.
The bug stems from me not range checking the damage done during battle. In this build, it is possible to do negative damage, which would add health to your enemy. The lower level enemies were also able to do negative damage to you, which would heal you. Another bug came from almost the same thing. When trying to select the Use option on an empty inventory slot, the game would crash. This came from the game trying to check an element in an array that simply wasn't there. I fixed that bug earlier, and it was a simple fix.
Matt and I have a lot of work to do over the next few weeks. We have a lot of features to fine tweak, balance to do on monsters and levels to create. It is going to be a hectic next few weeks trying to get everything done in time for our presentation in Week 8.
Subscribe to:
Posts (Atom)