![]() ![]() The black stuff on the top is just my laziness. If run on-calc, there isn't as much flickering. Obviously, the speed is a little fast, but I cranked it up for the screenshot. I added a functioning health bar and collision detection! I also added scoring, too, but you can't see what your score is (yet). ![]() hurry up! <3 If I can do all of this (plus collisions, a menu, and scoring) in a reasonable amount of bytes, I'll also do a water spriteĪfter a short break, I made a lot of progress today: TheLastMillennial expressed interest in SAX and in the thread above to do the piranha sprite, so I'm letting him do that. He does this little prancing thing, and it's greatĬonveniently (and intentionally) all three frames share the same upper part (only the legs/feet change) and are entirely reversible, so I can save almost 2.5kb (compared to having 3 full-body sprites for each direction) by writing a fun sprite routine. Just for you, as a little post easter egg, here, have a preview (it only goes once): (let it remain secret, or I'll delay release by a week hehe). ![]() I'm working on a three-frame running animation just for looks, too. But it's fine, I'll probably scale him up programmatically so the piranhas aren't half his size. He's super tiny (this is a 2x scaled image so that you can actually see him without hurting your eyes). I'm not entirely content with it and I'll probably change him a little eventually. This is before I put him through convpng, we lose some detail in the hair afterwards, but I'm not going to go to 16bpp just because 8 pixels in the hair are weird. Huge update! I finished the player sprite and added him in to the game. I don't think I'm going to release my source just yet, I want to get more of the core mechanics done first. Apparently this is caused by the fact that I was using an OS routine ( _GetKey) to add manual pauses between the redraws, so it won't be in the final program. In the screenshot, the battery indicator is drawn and I happened to switch to the next row almost immediately after it did it. All of the ones after the initial screen are generated pseudorandomly by a custom routine. This is opposed to the TI-BASIC game, because it generates more squares and goes slightly faster as you play, but this is a little tricky to do and I can make it just as difficult by speeding up more. I'm triggering the changes manually, but eventually it'll go on a clock, speeding up as you play more. I took that screenshot yesterday, when I started the project, I made all kinds of fun additions today! Now, the screen will scroll with new rows being pseudorandomly (but deterministically, I want all games to be the same) generated on the fly. Each "piranha" is represented by one bit in memory (each row is a byte), so changing them is super easy. I'm going to change them into piranha sprites later.Īll of the rows on shown there are not random, they are just patterns I made to show off the drawing capabilities (I have checks to make sure that a row of 8 piranhas will never happen in-game). The lines on the screen are debug features, I'll change them so they look better eventually. This is a demonstration of how the game is going to look. I couldn't afford to do this in the TI-BASIC version because of speed, but here switching to 8 will actually make it faster because of how I plan to implement movement (I think it's really clever, I'm going to use circular bit shifts and then an and instruction to check for collisions). I've also chosen to do 8 lines instead of six. I've shifted from a circular layout to a flatter layout, because it makes my math so much easier. Now that I am learning Assembly, I think it would be fun to try and port this TI-BASIC game over. It's also not the one being worked on in this thread.) Here's a demonstration of that game: (Reminder, this is not a "released" program, it's buggy and stuff. Occasionally, some dots will not be shown (this is a bug, err, feature), so you have to look at the number in the top to see how many dots are on your row. (You have to switch rows to dodge the dots) There's also a score multiplier/difficulty feature. You get points for how many dots are on your row, but you lose if a dot makes it to the end of the row that you are on. There are 6 rows of "dots" on the screen, and you can switch around rows. It's not a good enough game for me to release it into the archives, but it's relatively simple and fun. Earlier this year, I created a small TI-BASIC game that I creatively titled "Dodge". ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |