Against my best judgement, I decided to sprite the character
this is a version of the run cycle of the sprite in gif form
it might need a slight recolor in order to differentiate the background legs from the foreground, but that comes LATER
This was an especially helpful video for figuring out how sheep run (thats right: accuracy!) Basically, in walking, sheep (and I suspect goats and related animals) move their legs in a front left, back right, front right, back left fashion (they could obviously lead with their rights as well, this is a looping walk). The issue that then arises is thats a lot of frames. It wasn't actually, but on watching the animation, It felt slow to me, which makes sense because I was basing it of of sheep walking. Okay. So how do they run?
After watching the video, I realized that when running, the difference in leg movement lessens and eventually its just the front legs and the back legs propelling the animal forward (animal thrust forward back legs, plants them on ground, uses new stance to extend front legs further, shifts weight to front legs in order to thrust forward back legs, repeat. It's the same way dogs or cheetahs run)
but I wanted to get a design down because actual animation was going to be an obstacle that I wanted to get out of the way quickly (by doing it now, I can recode this kind of thing quicker, later)
this is an earlier version of the sprite, when it was still 32x16 pixels: 
So actually, I enlarged the player character to 64x32 (technically, lengths that are multiples of 16 are only a formality so my sprite is actually 46x32 to prevent weird collision gaps on the sides) Mainly I did this because:
1) I realized how tiny 32x16 pixels is and
2) I was frustrated that such a small resolution was not giving me room to make the player character bounce as in the the top version
I think I'm leaving the blocks 16x16 though because I stand by my opinion of blocks being chunky. It shouldn't really make a difference in how I code it, anyway
I know, I know, this is pedantic stuff and I shouldn't waste time on it, but what actually wasted my time was integrating it into my code (I banged out the sprite in like an hour, no problem).
I wasn't sure how to do so, outside of transporting every file using pygame.image.load("filename").convert_alpha(), so I was trying to use fancy os commands that I found online. BUT it kept on giving me errors (actually, the biggest holdup was when I figured out that the reason it couldn't begin to access the files was because I forgot to move the file to the folder where my images were).
Long story short: I just typed out pygame.image.load("filename").convert_alpha() 10 times for the 4 frames of the running animation, plus the standing sprite, all doubled for left and right.
And then I was having this issue where only the first two frames of the running animation would start. After fiddling with the code for an hour or so, I realized that there was something resetting the animation, preventing the full animation from playing . It was that I put in a piece that made the sprite go to the first frame in the animation whenever there wasn't collision on the bottom (so, whenever the sprite was mid-jump)(I did this because the first frame is the sheep, legs outstretched, basically I wanted it to be leaping during a jump). HOWEVER, this was triggering even when the sprite was touching the ground (I think this is because at the end of every update loop, it would set the "onGround" boolean to false so that it wouldn't interfere with the next iteration's check and this caused it to jump back to the first frame almost every loop).
I think If I want this to function correctly, I need to make a way for the machine to tell when the character is in a jump, other than "not touching the ground". Though technically, this is cosmetic (i mean, the flailing legs in the air just feels bad, scoob), so I will stuff it away for later. It goes onto the devlog for safekeeping!
****(REVISIT THIS)****
I've been thinking about this that I said in the last post:
"Additionally, I'm going to need to figure out how to differentiate between different types of platform blocks, when it comes to skinning them (obviously graphics comes later, I'm still at a rectangles-and-squares phase, but I think it's better to consider this now before I have to shuffle something later. )"
And I'm thinking that it might be the best in the long run to try to write a code that does this for me instead of individually assigning every block a type. By this i mean like in the conventional tileset paradigm you have corner blocks and center blocks and edge blocks. I can either in the level map assign corner blocks a different variable or something (maybe in an auxiliary array) or I can try to write a piece of code that goes "this platform block has one to the left of it and one to the top making it a right corner piece" or something like that.
Well actually, this isn't a long run it's a two week game jam... So I guess it depends on my scope. Ah, my scope. So it might just be easier to hand-type arrays for that kind of thing. hmmm. But actually since strings are treated like arrays already it might be easy to automate.... hmm.
So my goal for tonight and tomorrow is to work on the two things I said yesterday that I wanted to achieve that I didn't start today (actually, I got more done today than I thought I would, though this is not completely congratulatory cause I'm still goin! The grind doesn't end!!)
1. level design. This is still... more or less an amorphous concept as of now
2. changing between screens. this is kind of hand in hand with the previous one, but who am I kidding I need to do this BEFORE i can design levels so I know my limitations.
Last thing: concept stuff:
I'm thinking lambs for the sheep that you collect. And I'm torn between making a pastoral, grassy tileset or dreamy, surreal tileset. I'm not going to be mr. scope and say both unless I like have bunch of downtime that I can't possible funnel into something else (that's not happening)
Maybe its like purple grass. hmmm. Anyway that's where I am.