Controls: Arrow keys only.
Hi all,
Here's my first finished Pico-8 cartridge, "Material Girl", which is also my first finished game (of hopefully many more!).
It's a goofy little puzzle game that's sort of a mashup of a dating sim and JRPG-style combat.
It's a very simple game, but it took me a long time due to being distracted by my day job and perhaps spending too much time overengineering the underlying code :P Due to code size limits it's definitely about finished, I could push it a bit further with a minimizer but I'm relatively happy with it.
I built mini libraries for keeping track of persistent sprites, promises, and doing complex sequences of tweens. If anyone has interest in using this code feel free, or let me know if you want me to clean it up and extract it into a separate file for easier reuse. They do take up a good chunk of space so they only make sense if you want many sequential and overlapping tweens on things like position, scale, etc. Since this game is turn based on animation-heavy it made sense for me but it probably won't make sense for a platformer or something like that which is more based on real time input.
The code is here and it's running here with mobile support via an on-page D-Pad.
Happy to hear any constructive feedback, I know the sound effects are kind of poor and it could use more music but I did what I could haha. Hope you enjoy it!
you forgot the http:// in front of your links :)
i love the animations of the sprites, the blobby ones (with the zoom) really gives the illusion that the resolution is higher than it is :O
Thank you! I've fixed the links. And thanks for the kind words about the animations lol, too many hours were spent trying to juice as much as possible out of that 😛 I've gotten feedback that the different detail levels of the sprites is unpleasant but i think I've improved it since then so hopefully it's more interesting than annoying now :)
Oh crap there's a bug where you can walk over the buildings... guess i deleted too much code while i was trying to make it fit in the code size haha, I'll fix that when i get home sorry!
Hey jcwilk, I had a quick look at your code and I noticed you have comments mentionning .lua files, like a program would have taken those and mashed them into the cartridge.
Do you have some kind of IDE to do that? That makes me very curious about your workflow.
Great work on the animations by the way! Otherwise I have no clue how to win over the third and fourth guy
Ok, fixed the bug forgot to add a return (my "mother language" is Ruby which doesn't require explicit return statements, bites me sometimes with lua and javascript lol)
@Jackamikaz - Thanks! Would you mind elaborating on how the animations helped vs the 3rd and 4th guy? I'm really interested to figure out how what does and doesn't work for conveying hints like that, this game has been a great learning experience so far about giving info to the player indirectly.
As far as the comments you mentioned, good eye and yep I have a pseudo-compile step because I could stand the fact that pico-8 forces you to put everything in one file so I just jimmy-rigged a very simple ruby script to combine code from multiple files.
You can see it here: https://github.com/jcwilk/material_girl/blob/master/compile.rb
and it gets run over and over whenever it detect any files have been changed in the directory via this script: https://github.com/jcwilk/material_girl/blob/master/auto_compile.sh
The way it works is for any file in the directory, it reads through the file and looks for a comment like "-- start ext some_file.lua", if it sees that then it takes everything between it and the "-- end ext" comment and replaces it with the code from some_file.lua that is between "-- START LIB" and "-- END LIB".
It sounds a little bit awkward/complicated but it's actually very simple in practice. A huge advantage of this is that I can make a library for doing tweens and such, and then in that library file I can put a bunch of code that "tests" the library code as a fleshed out .p8 file so that I can run it specifically and make sure that certain edge cases are working as expected, but then my little compiler program just extracts the library code part and copies it into the main material_girl.p8 file so that they "share code" that way. You can see an example of that here: https://github.com/jcwilk/material_girl/blob/master/sprites.p8#L397-L470 none of that highlighted code is actually used in the main "compiled" program, it's just for debugging my complicated tween stuff. (that test code may or may not work right now though, haven't run it in awhile)
There's also a huge benefit to it because something I kept running into when I was using an external editor with pico8 was that the following would happen:
- make changes to some sprites in pico8
- switch to editor and make some changes to the code and save
- switch back to pico8 and save
That third step would overwrite the code changes, and then my editor would reload the file with the changes, so if I hadn't checked in my changes to git lately then my recent work might be lost.
Since my current workflow means that everything in the original file is just copied there's no risk of that, the only things that I save to the main file are the pico8 sprite/sound/music/etc data.
There's probably a more elegant way to achieve the same workflow, or there's probably a tool out there that does it better, but the script I wrote is very short and I know exactly how it works so it works for me :) Hopefully that makes sense, happy to clarify further if it doesn't.
Amazing! You basically implemeted your own include preprocessing :) , simple but so efficient. You make me want to have a look at ruby because that's the second time I see someone using it kind of casually but for a high effect.
About the third and fourth guy, when I read that there's some animations that convey hints I though "Oh animations actually matters! I'll try again" but then I couldn't see any difference. To me, the guy animates just to bump the girl out, otherwise he's always like a stone. Text hints don't do much either for me, and I get bumped even when I withdraw a little so this command feels useless.
Yeah ruby's simple and to the point syntax is very useful for quick little utility scripts like that. I had to exclude it from working on the .p8.png file though because it ran into an issue with the encoding on the png data. I'm sure if I looked into it a bit I could find the right way to handle that but I just excluded the png file from the script and moved on. I just save to the png before publishing anyways.
Oh sorry I misread your comment, thought it was saying the animations helped but it was just saying you were getting stuck in the shoe store. Someone elsewhere just gave feedback that they got stuck there also so you're not alone, lol.
The trick is to pay attention to what has changed since the last battle. Each battle adds a new mechanic to make it more challenging than the last battle, usually that also comes with a new ability to address the new challenge. In the third battle a limitation is added to dazzle, withdraw is tied to working around that limitation and the text gives you a bit of a hint when you're running into the limitation also.
I think a little bit more intro text before each battle would be helpful to give implications about how the battles are changing, but unfortunately I'm out of room with filesize.
[Please log in to post a comment]
