not much functionality has been added, but the sprite classes were significantly restructured as were the drawing methods and collision detection.
First I changed collision detection to masks instead of the default rects. Masks uses the bitmask of each sprite instead of the rect. This defaults to interpreting the sprites image to make a bitmask which means I needed the sprite to have an image variable so I added one and an update to it in the draw functions of the sprites. This caused issues with collisions though because it used every pixel in the sprite, and the sprites should only collide on their bottom half (they are 2 tiles tall). So I made custom black and transparent bitmask images to use. Objects (rocks) have one too so that sprites can't walk into the 'cracks' in between them.
So now I had sprites with image variables, and could set their rect variable to the full image size since they weren't used for collision detection anymore. this means I could use the draw and clear functions of groups. So before this was the process: filling the screen black, drawing the map, drawing each sprite, then drawing the map with all sprites at correct pos.
Now I can skip drawing the map every time, and instead have each group clear, which draws the map only over the place where it last drew the sprites. then each group draws all of its sprites. This fixed the sluggishness, as drawing the large map image every time was too much.
I also removed one skeleton who was being spawned into the rock wall.
Now that the map surface is not redrawn every cycle, I will look into using the surface's scroll function instead of redrawing the screen black and the map surface in its new position. I could draw both once with that, and just scroll the map surface every cycle.
collision detection, kills player and skeleton if they collide, skeletons will change directions if they are going to collide with other skeletons or walls (rocks), and player doesn't move if they will collide with rock
still working on an easy way to make the maps
right now the background (any images that don't need blocking or layering with player and enemies) is just one whole image, and the rock walls are created from a large coordinate list.
I implemented map scrolling by having two surfaces, one which is the actual display screen, which is colored black every game loop cycle, and then a surface which contains the whole map image which is reloaded every cycle, then the players, rocks, and skeletons are drawn on it, and the whole thing is pasted onto the screen with coordinates based on the players coordinates.
This works as far as amking a scrolling map larger than the screen with the player staying in the middle, but it seriously slowed the program down and I'm not sure what to do about that.
@cemkalyoncu: If you mean the professor guy yeah I can do that,
@C. Nilsson: Those are sweet! I was actually thinking about how it needed gates
@gr3yh47: I didn't make a draw gun animation, I figured for most uses you would want an immediate firing reaction when the player shoots. I might be able to do something though.
As for the bow animation, it has the character standing sideways, so I just took the normal standing base and edited in the arms from the side and front bow, so the bow animations won't match, but it might be easy to edit the bow clothes and standing clothes together of any given clothing set.
One thing to note if you decide to use the flashlight: it's on three layers, flashlight has the bases for towards, away, and left and flashlight#1 has the light. Flashlight 2 is the right facing base.
problem is fixed.
not much functionality has been added, but the sprite classes were significantly restructured as were the drawing methods and collision detection.
First I changed collision detection to masks instead of the default rects. Masks uses the bitmask of each sprite instead of the rect. This defaults to interpreting the sprites image to make a bitmask which means I needed the sprite to have an image variable so I added one and an update to it in the draw functions of the sprites. This caused issues with collisions though because it used every pixel in the sprite, and the sprites should only collide on their bottom half (they are 2 tiles tall). So I made custom black and transparent bitmask images to use. Objects (rocks) have one too so that sprites can't walk into the 'cracks' in between them.
So now I had sprites with image variables, and could set their rect variable to the full image size since they weren't used for collision detection anymore. this means I could use the draw and clear functions of groups. So before this was the process: filling the screen black, drawing the map, drawing each sprite, then drawing the map with all sprites at correct pos.
Now I can skip drawing the map every time, and instead have each group clear, which draws the map only over the place where it last drew the sprites. then each group draws all of its sprites. This fixed the sluggishness, as drawing the large map image every time was too much.
I also removed one skeleton who was being spawned into the rock wall.
Now that the map surface is not redrawn every cycle, I will look into using the surface's scroll function instead of redrawing the screen black and the map surface in its new position. I could draw both once with that, and just scroll the map surface every cycle.
So updates
collision detection, kills player and skeleton if they collide, skeletons will change directions if they are going to collide with other skeletons or walls (rocks), and player doesn't move if they will collide with rock
still working on an easy way to make the maps
right now the background (any images that don't need blocking or layering with player and enemies) is just one whole image, and the rock walls are created from a large coordinate list.
I implemented map scrolling by having two surfaces, one which is the actual display screen, which is colored black every game loop cycle, and then a surface which contains the whole map image which is reloaded every cycle, then the players, rocks, and skeletons are drawn on it, and the whole thing is pasted onto the screen with coordinates based on the players coordinates.
This works as far as amking a scrolling map larger than the screen with the player staying in the middle, but it seriously slowed the program down and I'm not sure what to do about that.
Screenshot attached
Here is a screenshot, not much to look at right now
Nothing new to report becauseI spent most of the day trying to get this git stuff to work
Speaking of which, I now have the files for this game here:
https://bitbucket.org/FeralFantom/manor/overview
This will be rpg-stlye as far as moving and interacting with objects by pressing a key
no levels though, and no combat, if you run into an enemy, you lose life/sanity and they disappear, if you run out of one or the other its game over.
puzzles will be things possibly like mazes, hidden series of switches, and putting together clues to figure out what to do next.
The player will also be able to access a 'journal' which has all the clues they have found.
I will work on getting code up and screenshots and stuff
You are a god among men
@cemkalyoncu: If you mean the professor guy yeah I can do that,
@C. Nilsson: Those are sweet! I was actually thinking about how it needed gates
@gr3yh47: I didn't make a draw gun animation, I figured for most uses you would want an immediate firing reaction when the player shoots. I might be able to do something though.
As for the bow animation, it has the character standing sideways, so I just took the normal standing base and edited in the arms from the side and front bow, so the bow animations won't match, but it might be easy to edit the bow clothes and standing clothes together of any given clothing set.
Did an FBI type guy who was easy because hes just a recolor of the other dude I did, but I also decided to give him a pistol to shoot.
I used wulax's bow animation to get the arm angles for shooting.
Finished the hurt cycle for the dude:
I have no idea how to work the hat in the last frame, really it should be falling off, but there is no room in the image.
I might just have the guy be hatless.
Also finished the crpyt tileset along with a darker grass and dirt set to make a more night feel.
Made this mockup using C. Nilsson's graves and wulax's skeleton:
going to second that leafless tree request
still working on the male death animation
also doing a crpyt stlye building that wil probably be able to be used for more
not sure if I will do the woman
did a background image of like an open book
The desk is really crappy but im satisfied with the book
Hello again, it is me, anon#2, now with name!
Finished the professor sprite to a passable quality at least:
I edited the towards jacket a bit as per wulax's reccomendation
Going to take a breather and attempt a female from same era next oh and also death animation.
Anyways, here is the xcf file again, might be the same link but just in case:
http://dl.dropbox.com/u/87204861/professor_walk_cycle.xcf
One thing to note if you decide to use the flashlight: it's on three layers, flashlight has the bases for towards, away, and left and flashlight#1 has the light. Flashlight 2 is the right facing base.