A game about impractical architecture.
I wanted to see if I could make big levels by randomly connecting 16x16 tile chunks. If I can manage to optimize this thing a little bit, I'd like to add more items, monsters and map bits and consider adding local co-op (that would be pushing it, token-wise).
There are a few collision issues that might cause game-breaking failures.
In any event, I learned a ton. I'd love to hear what you guys think of it!
Quick Update: I removed some of the background clutter. It felt way too busy.
z - attack
x - shield (if you have one)
left and right - move
up - jump
down - enter open doors
w - attack
q - shield (if you have one)
s and f - move
e - jump
d - enter open doors
-skeletons now have shields
-skeletons will now stop, attack and block instead of just running around
-added red slimes that are slightly tougher for some variety
-I've improved the collisions (still needs work!), so hopefully the player can't escape in ways they're not meant to.
-if item drops do manage to fly out of the map, they're destroyed instead of crashing the game
-player now only lunges forward during an attack if they are also defending (shield out)
-player continues to face the enemy if they are knocked back
-I reorganized a lot of the code and managed to shrink my token use from 7933 to 7018, so I've got more room to build new stuff. Still considering local 2player co-op
-Boom. The Pico-8 is rad.
-I've added some new equipment
-fixed the player shield
-added code to start thinking about local co-op, but I'll have to consider some kind of new HUD to show both players equipment and health. If you want to mess with the early implementation, uncomment the init_object(player, 24, 112) functions on lines 742 and 754
-tons of new stuff!
-still tweaking the collision detection against objects!
-10 new map chunks!
-including new graveyard areas!
-some new equipment!
Unless any crazy bugs pop up that I just have to fix, I'll probably fill up the space I've saved for equipment, update the HUD and Death screens to work with 2 players and call this thing completed.
-I think The Wee Dungeon now contains everything I'd hoped to implement. Time for a new project!
-Maybe I lied about being done. Been thinking about the game and how much more I can squeeze into it
-hitpoints are shown on attacks
-there's now a progression to item drops, so you don't pick up weaker equipment
-spikes don't kill you immediately anymore if you have equipment (otherwise they do)
-added a few enemies
-probably created a few more bugs, we'll see!
-inching ever closer to the token limit, i fixed the kickback that happens when you're touched by a monster.
After looking through one more time, I'm calling the Wee Dungeon done!
revised the unfair trap room.
--Thanks as always for looking! Any and all feedback is most appreciated.
This is brilliant. I played at least ten or twelve times the first sitting. I like the randomness, the fighting dynamic, and the various upgrades, though it wasn't always clear what they did for me. The graphics are very cute and effective.
I found a few of the already noted bugs, mainly the ability to go through some walls and get stuck. The music got a bit repetitive over time. Adding a little more variety, or maybe some quiet parts, would be cool.
Thanks for the kind words!
Still managing to sneak through the walls every now and then? Maybe I'll have to revisit some of the bugs I thought I'd squashed after all. Collision detection is the final boss in this one!
Also, I think you might be right about the spikes (fire).
You probably know this already, but the lerp on the camera is too slow if you fall a long distance and your guy gets off-camera for a bit.
also why is there a screen where you have to chose the correct pit to fall into? that's just mean
Currently, you can get stuck inside a slime if you land on top of one (and you can't really attack until you jump out of the slime), but this actually makes sense for slimes so you could probably just keep it that way. :L
I download 18923.p8.png, either by clicking on the picture of the name text.
I then use "folder" to open up the Pico8 folder, and move the file into it.
I do "LOAD 18923" and hit [ENTER].
I get LOADED 18923.P8.PNG (0 CHARS)
And when I do "RUN" I just get the prompt back.
When I look inside the rest of the editor, all the sprites, maps, and music are there. But the code is blank.
I haven't actually published any cartridges myself yet, so I can answer your question about how to publish it. It sounds like you're doing it right to me.
Can anyone who's published a cartridge help?
Could you try loading your own .png from this website in your Pico8 IDE and see if you see the same behavior?
Thank for trying to fix it. I'd love to see your code.
Strange, I'm not sure why that's happening.
Anyway, here's a link to download the PNG file I've been working from:
Well okay, since you were so cordial about it.
The intent was for the background elements (the chains and windows) to indicate the right choice, but overall, it hasn't been as apparent as I thought and it's definitely unfair. I made some changes to it to make a mistake potentially less costly.
In any event, I appreciate the feedback everyone's given me on this thing. I've been thinking recently about making some sort of successor to it on a grander scale, possibly in Unity (Super Wee Dungeon, or something to that effect.) It's been a blast to build and play.
Great job dude, I did something similar in my current game (not uploaded) I used 8 x 8 blocks, took the players position, and a formula to check the position block number and it worked, but I have too much code going on though (about 8 lines of code for each x and y) and then I would had to do the same for enemies and junk. So I'm just trying to figure all of this stuff out.
Your graphics are awesome, I loves those windows.
Wow, Connorses ! Grabs a bar of soap and runs after him :)
Your game is well rendered and played. May I suggest the vertical camera not track UNTIL the player is actually touching a ledge.
So when he jumps in mid-air, you do not have the camera track him UNTIL he is on a new landing. Then (at least for me) won't have that seasick feeling when jumping in mid-air.
Notice how Rayman's vertical camera only bobs a tiny bit when he jumps. It does not catch up properly until he is fully on a ledge or floor.
Falling, however, (positive movement down), the camera tracks your every pixel.
Gravity and friction can both be tightened up a bit. Or at least, the downward movement of the gravity. Seems really hard to control precisely (enough) in the air. Some of the background tiles really look platformey, like you can land on them (even though you can't)... not sure if intentionally misleading or not.
Digging the concept so far, though!
[Please log in to post a comment]