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.

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.