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.
Showing posts with label GSP 361. Show all posts
Showing posts with label GSP 361. Show all posts
Tuesday, April 23, 2013
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.
Friday, March 29, 2013
Development Blog #3
Friday, March 29 2013
Well, I guess I can announce the working title of our game. We have decided to call it Project: Dimension for the time being. Hopefully next week I will have some code snippets to share, as that is when the real development work will begin.
This week Matt and I worked on our file I/O system that is going to help us keep the processing time of the game down. What we are doing is storing all of the NPC, monster and item data in separate text files. At game initialization, the game reads in these files and creates objects with the data that is stored in the text files. These objects are the stored in different array lists that are a part of the InventoryManager class and the EntityManager class. We feel that this way is best as it allows us to create more items/monsters/npcs on the fly, without having to hard code anything in. We did, however, run into one major problem.
The problem is still persistent as I have not figured out how to fix it yet. The issue arises when I try to test this file I/O system with some dummy data. The data is read in fine and stored into the array before being passed the the portion where the object is created. Once it hits the creation step, the program crashes and gives me a "No OpenGL data in the current thread". I know that this means I am trying to use something from the OpenGL library before OpenGL is initialized in the program, but I cannot for the life of me figure out where the error stems from. I think it has something to do with the way we are handling textures in the code, but we are in the process of changing over to sprite sheets. Sprite sheets may help avoid this issue as there will not be a separate texture file for each object. The data passed from the text file will have to contain some data on where on the sprite sheet the texture for the object is located. I have a feeling the sprite sheets are going to make this a heck of a lot easier. I am not a graphics guy, so it is somewhat of a foreign language to me. However, I am confident that Matt will be able to walk me through it the next time we meet.
Well, I guess I can announce the working title of our game. We have decided to call it Project: Dimension for the time being. Hopefully next week I will have some code snippets to share, as that is when the real development work will begin.
This week Matt and I worked on our file I/O system that is going to help us keep the processing time of the game down. What we are doing is storing all of the NPC, monster and item data in separate text files. At game initialization, the game reads in these files and creates objects with the data that is stored in the text files. These objects are the stored in different array lists that are a part of the InventoryManager class and the EntityManager class. We feel that this way is best as it allows us to create more items/monsters/npcs on the fly, without having to hard code anything in. We did, however, run into one major problem.
The problem is still persistent as I have not figured out how to fix it yet. The issue arises when I try to test this file I/O system with some dummy data. The data is read in fine and stored into the array before being passed the the portion where the object is created. Once it hits the creation step, the program crashes and gives me a "No OpenGL data in the current thread". I know that this means I am trying to use something from the OpenGL library before OpenGL is initialized in the program, but I cannot for the life of me figure out where the error stems from. I think it has something to do with the way we are handling textures in the code, but we are in the process of changing over to sprite sheets. Sprite sheets may help avoid this issue as there will not be a separate texture file for each object. The data passed from the text file will have to contain some data on where on the sprite sheet the texture for the object is located. I have a feeling the sprite sheets are going to make this a heck of a lot easier. I am not a graphics guy, so it is somewhat of a foreign language to me. However, I am confident that Matt will be able to walk me through it the next time we meet.
Thursday, March 21, 2013
Development Blog #2
March 21, 2013
Earlier this week I finished up coding the Inventory system and the Entity system. The inventory system handles all of the inventories, including the hidden ones that allow monsters to drop items when they die, if we choose the implement this feature in the future. The entity system has 3 classes derived from it, being the Player, the NPCs and the Monsters. There is also an entity manager and an entity generator that control the generation of all of the characters and monsters in the game at initialization. The manager does not, however, control the player. The player is going to be its own object outside of the entity manager.
In our meeting today we talked about some ideas for how we are going to implement maps into our game. My idea was to make a giant image of the entire game world, and then create some sort of coordinate system in order to determine the player's position and what portion of the game world is visible to them. This turned out to be a bad idea, as it would take a lot of extra coding in order to get this to work. The idea that Matt and I settled on is to create a text file with symbols inside of it. The symbols will be arranged in the order that we would like the tiles that they represent to be in. This is how we are going to create our playable areas, for now. We are going to have to create tiny (32x32 or 64x64) tiles for this to work, which should not be that hard.
I have to begin creating some artwork for the game. I am going to create some item sprites and weapon sprites for us to test our File I/O system with, so we know that it works. We also need to test drawing the objects to the screen, to see if we need to adjust our code or rethink the way we are handling textures.
Thursday, March 14, 2013
Development Blog #1
Thursday, March 14
This week Matt and I started to really hunker down into the code of our game. He has been working on getting a menu system to work in the Light Weight Java Game Library (LWJGL). This is the same engine that Minecraft runs on, so we are certain that this choice in engine is going to make our lives a lot easier. I have been working on the base classes for almost everything in our game. We have two base classes called Entity and Item. Entity is extended by Player (the main player), NPC (game npcs) and Monster (game monsters). Item is extended by two different types, Equippables and Pickups. I chose to write the code this way, as Equippable items have certain features that regular Pickups do. Also, Equippables are not stackable, which is one of the main differences between the items in our game. There is also an EntityManager and an EntityGenerator that will handle all of the entities within the game and handle dynamic spawning of entities. The IventoryManager handles the player's inventory, as well as the monster's inventory if we decide to make the monsters drop items when they are killed. It is a Singleton design, which allows each object to have only 1 instance of the manager inside it at any given time. We have not decided on the style of our artwork and graphics yet, but we are getting to the point where we need to. We will need to know if we are going to use things like sprite sheets or not, and what the resolution of the artwork is going to be. I like 8-bit, but for this game it may be too low-res.
Right now the biggest problem I am having with the code is inside the InventoryManager. In this class, there will be a function to remove an item from the inventory. The problem lies in distinguishing between the two different types of items, as the Pickups type has the ability to be stackable, and we do not want the entire stack (if there is one) to be deleted when the player uses an item from the stack. Matt and I are going to brainstorm on this tomorrow when we meet for our weekly work session.
This week Matt and I started to really hunker down into the code of our game. He has been working on getting a menu system to work in the Light Weight Java Game Library (LWJGL). This is the same engine that Minecraft runs on, so we are certain that this choice in engine is going to make our lives a lot easier. I have been working on the base classes for almost everything in our game. We have two base classes called Entity and Item. Entity is extended by Player (the main player), NPC (game npcs) and Monster (game monsters). Item is extended by two different types, Equippables and Pickups. I chose to write the code this way, as Equippable items have certain features that regular Pickups do. Also, Equippables are not stackable, which is one of the main differences between the items in our game. There is also an EntityManager and an EntityGenerator that will handle all of the entities within the game and handle dynamic spawning of entities. The IventoryManager handles the player's inventory, as well as the monster's inventory if we decide to make the monsters drop items when they are killed. It is a Singleton design, which allows each object to have only 1 instance of the manager inside it at any given time. We have not decided on the style of our artwork and graphics yet, but we are getting to the point where we need to. We will need to know if we are going to use things like sprite sheets or not, and what the resolution of the artwork is going to be. I like 8-bit, but for this game it may be too low-res.
Right now the biggest problem I am having with the code is inside the InventoryManager. In this class, there will be a function to remove an item from the inventory. The problem lies in distinguishing between the two different types of items, as the Pickups type has the ability to be stackable, and we do not want the entire stack (if there is one) to be deleted when the player uses an item from the stack. Matt and I are going to brainstorm on this tomorrow when we meet for our weekly work session.
Subscribe to:
Posts (Atom)