Dev Blog #7

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.

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.

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.

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.

Dev Blog #3

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.

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.

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.