Not much to this, mockup for a touhou-like
-Player sprite
-Bullet tracking and generation w/ a few spiral patterns
-Hold X to slow movement and view hitbox
0 comments
itch.io link:
https://tekkamansoul.itch.io/loto-the-avatar
^
Go here if you want win/linux/osx binaries!
UPDATE 2/14!
It's sort of finished! With music! (Scroll down for dev notes!)
What it is:
A fan's demake of Ultima 1 crossed with Dragon Quest 1. You play as Loto* and your goal is to save the princess and kill the evil wizard Mondain.
INSTRUCTIONS:
Arrows move. You interact/talk/attack by bumping into things.
(O) opens the magic menu where you can cast Hoimi (Heal) and Gira (Firebal).
(X) cancels/closes.
You can only save at Castle British by speaking to Hawkwind.
Your boat may get lost if you die in a dungeon, so be careful!
What you can do:
-Save and load
-Buy a boat and sail
-Use magic
-Reach the max level of 8
-Buy weapons and armor
-Visit the four magic signposts (and get a secret weapon!)
-Delve the four dungeons and kill the four big beasties
-Collect the four magic orbs
-Get the jail key
-Rescue the princess
-Kill the Dragonlord Mondain
..and thats where it stops! Game over, you win.
DISCLAIMER:
This borrows heavily from properties owned by Origin, Enix, EA, and Square-Enix. I made all of the content within the cart but the IPs do not belong to me in any form.
I also would not suggest using this cart as a programming example. I am terrible at coding and this cart is nothing but proof.
glhf
(*not really, you play as their descendant, since that's who you are in DQ1, but eh)
-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-
Development notes!
-There's no actual menu system in the game, but one probably would have saved space. What happens now is draw calls that just plop a rectangle on screen with text and modify key behavior. (Technically this is all a menu/gui system is, but designed properly instead)
-NPCs (and teleport squares) take up a large amount of space, at least in regards to tokens. Taking out one or two is enough for several lines of valuable code, so I had to delete some just to make space for the final bit of code.
-Strangely enough, I never came close to hitting the character limit. I went over compression limit on the cartridge many times, but that was easily fixed by shortening variable names and refactoring. The reason why this is so strange is because the dungeons in the game are stored in strings; 16 total screens, each containing 255 characters (or 4080 chars) that can't be shortened or modified - yet it fits in that 15k cart storage just fine!
-Enemies don't use A* pathfinding, but if they did, it would probably be way more efficient and take less tokens. Right now, they move towards the player one square at a time, and if they're blocked, they might try to move left or right. That's it, and it works fine, but could be better.
-Enemies are actually procedurally generated. Their stats are based on player level and what random monster sprite is picked. They all behave identically, excepting the ones that can pass over water (which was done with a simple sprite flag!)
-Drawing all the 8x8 sprites by hand and manually preening the coastline was totally worth it.
-This doesn't use OOP at all, but for my next Pico-8 RPG I will loo into seeing if it is worth the cost in tokens.
I've used a couple composing programs that have had a toggle to only let you key in notes that are within the musical scale you select. For instance, if you have the toggle enabled to CM, you could only key in CDEFGABC and all intermediate notes would do nothing. It's a helpful tool for composing melody and for people like myself who aren't great with theory and I think melds great with the pico8 design schema.
Would it be possible to get such a feature?
Thanks!
Hey all! First post!
Huge thanks to Lexaloffle for making such a fantastic piece of software. I love the nostalgia.
I'm also a gigantic fan of the steganographed cart format. It's awesome! One thing I have been obsessed with doing is calculating the theoretical kilobit storage of different games. I've seen pico-8 carts (in p8.png format) range from 8kb/64kbits (the minimum?) to about 55kb/440kbits for jam-packed carts (Alone in Pico, Dank Tomb).
In the spirit of our favorite consoles of yore that used to advertise the size of the carts on the packaging, could it maybe be a new feature to add the theoretical kbit size on the .p8.png files?
From how cartridge hardware would have been assembled, I am assuming the following possibilities:
64 (~8kB)
128 (~16kB)
192 (~24kB)
256 (~32kB)
320 (~40kB)
384 (~48kB)
448 (~56kB)
Thanks, and happy coding!!
