Today I finished up the prototype version of my world tile system. The system works like so: an image is loaded with the pixel width and height of the world. The world dimensions are set to the image width and height, and then the pixel values are transferred into the world virtual 2D array. The renderer then interprets this data into the respective tiles. This from of loading world data (from an image) is something I learned from Notch, the creator of Minecraft, through his code.
It took awhile to get this work, as I had memory errors when trying a string-based approach. After trying to debug the code for awhile, I gave up and posted to Stack Overflow, where they found the error within minutes -.- . I suppose I have a lot to learn. Once I had got the loading working, I then did a simple hard-code of tile handling inside the rendering system. The image approach is much easier, safer, and more reliable.
Next, I think I will try to refactor the code so that it is more dynamic (currently, the tileset is hard coded into the game). Then I think I will work on collisions or animations.
Tuesday, August 14, 2012
Sunday, August 12, 2012
World Constructor
This time, I fixed an annoying heap corruption error in my world loading code. The code gets a pointer to a loaded string from the string input method, then uses it according to an algorithm to load a virtual 2D integer array of tile ID's. It turns out that I had one symbol wrong: I used '+' instead of '-' in my algorithm (actually a big deal). This caused weird memory problems that showed their ugly faces when I tried to delete the string, leading me to believe that the problem was in my loading method memory management (side note: the loading method was changed because according to Stack Overflow you aren't supposed to return a pointer to a std::string). Lesson learned: everything can be the problem, so don't leave anything out. After that, the loading method seemed to work just fine, but I couldn't test it because console output isn't working with SDL (it outputs to a file but there is no output).
Next, I will hook up the world data to a tilemap and graphics. I will have to pull the tiles from a sprite sheet, but I've done that before. I'm thinking I might use a map<int,SDL_Surface*> data structure, maybe in the world class or in an art class.
Next, I will hook up the world data to a tilemap and graphics. I will have to pull the tiles from a sprite sheet, but I've done that before. I'm thinking I might use a map<int,SDL_Surface*> data structure, maybe in the world class or in an art class.
Saturday, August 11, 2012
Intro, Animation, World
This is a web log of my efforts to clone and to extends The Legend of Zelda: A Link to the Past.
My goals for this project are:
-Write it in C++ (to learn)
-Make the gameplay as close to the original...
-Then extend and change it into a different game
So far, I have an extremely basic version going. I have an animation system worked out, as well as basic player movement. The animation speed is much to slow, though, and will have to be sped up. The next thing I am going to work on is getting a tileset and world map up, and then will work on collision.
One of the largest problems I see ahead is how to base the collision with the animation. The player location is stored as an (x,y) coordinate, and the player sprite is blitted downwards and to the right. This makes collision when walking easy, as I can just make a static bounding box for the collision area. However, once you factor in the swing of the sword, you get possibly two or more bounding boxes in different directions. The bounding box for the sword depends on the direction that the player is facing. I could just hard-code the sword swing in, but I think creating a more dynamic solution would make coding enemy attacks in easier. I may make a weapon class that contains collision and bounding box data, then have a pointer in the entity that holds it. This won't be completely dynamic, as it would be compiled and not a file, but it will work well enough.
The world map will be easy (I hope). I can simply store a 2-D integer array for the tile types, then have a tileset map to the sprite as well as any other data. This will make loading and changing easy. I might want to add in a command system to the game so I can load different maps and execute different code without having to recompile.
My goals for this project are:
-Write it in C++ (to learn)
-Make the gameplay as close to the original...
-Then extend and change it into a different game
So far, I have an extremely basic version going. I have an animation system worked out, as well as basic player movement. The animation speed is much to slow, though, and will have to be sped up. The next thing I am going to work on is getting a tileset and world map up, and then will work on collision.
One of the largest problems I see ahead is how to base the collision with the animation. The player location is stored as an (x,y) coordinate, and the player sprite is blitted downwards and to the right. This makes collision when walking easy, as I can just make a static bounding box for the collision area. However, once you factor in the swing of the sword, you get possibly two or more bounding boxes in different directions. The bounding box for the sword depends on the direction that the player is facing. I could just hard-code the sword swing in, but I think creating a more dynamic solution would make coding enemy attacks in easier. I may make a weapon class that contains collision and bounding box data, then have a pointer in the entity that holds it. This won't be completely dynamic, as it would be compiled and not a file, but it will work well enough.
The world map will be easy (I hope). I can simply store a 2-D integer array for the tile types, then have a tileset map to the sprite as well as any other data. This will make loading and changing easy. I might want to add in a command system to the game so I can load different maps and execute different code without having to recompile.
Subscribe to:
Posts (Atom)