x-post from Cemetech, horizontal lines indicate different postsEarlier this year, I created a small TI-BASIC game that I creatively titled "Dodge". It's not a good enough game for me to release it into the archives, but it's relatively simple and fun. There are 6 rows of "dots" on the screen, and you can switch around rows. 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. (You have to switch rows to
dodge the dots) There's also a score multiplier/difficulty feature. 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.
Here's a demonstration of that game: (Reminder, this is not a "released" program, it's buggy and stuff. It's also not the one being worked on in this thread.)
Now that I am learning Assembly, I think it would be fun to try and port this TI-BASIC game over. So that's what I'm doing.
I've shifted from a circular layout to a flatter layout, because it makes my math so much easier. I've also chosen to do 8 lines instead of six. 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 [mono]and[/mono] instruction to check for collisions).
Here's the first actual screenshot:
This is a demonstration of how the game is going to look. The lines on the screen are debug features, I'll change them so they look better eventually.
The green dots are placeholders, too. I'm going to change them into piranha sprites later.
All 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). Each "piranha" is represented by one bit in memory (each row is a byte), so changing them is super easy.
I took that screenshot a few days go, when I started the project, I made all kinds of fun additions recently! Now, the screen will scroll with new rows being pseudorandomly (but deterministically, I want all games to be the same) generated on the fly.
Here's a new, updated screenshot:
I'm triggering the changes manually, but eventually it'll go on a clock, speeding up as you play more. 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. All of the ones after the initial screen are generated pseudorandomly by a custom routine.
In the screenshot, the battery indicator is drawn and I happened to switch to the next row almost immediately after it did it. 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.
I don't think I'm going to release my source just yet, I want to get more of the core mechanics done first.
Since I wrote the above stuff, a lot has happened! I added player movement and the rows are now on a timer! I haven't done sprites for the player or the piranhas yet, but that is the next big step.
The program is about 450 bytes right now, but I think I can get this down quite a bit. It doesn't seem like a lot (to me, at least), but we don't have all of the features done yet. The sprites are probably going to be at least half of the whole program.
Huge update! I finished the player sprite and added him in to the game.
Here's the sprite I made for the player. His name is Robert, and he's adorable.
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.
I'm not entirely content with it and I'll probably change him a little eventually.
Here he is
in situ:
He's super tiny (this is a 2x scaled image so that you can actually see him without hurting your eyes). But it's fine, I'll probably scale him up programmatically so the piranhas aren't half his size.
I'm working on a three-frame running animation just for looks, too.
Conveniently (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.
TheLastMillennial expressed interest in IRC/SAX and in the cemetech thread to do the piranha sprite, so I'm letting him do that.