itch.io

Thanks for playing. Several people have said  that the t got stuck on level 7/8 so I'll try to adjust the difficulty level there.
It shouldn't require holding a directional button to fold mid-air. That sounds like a bug.  I'll look into it. 

Thanks for playing. Yeah, lv35 has some issues. I'm working on some new features that will make the solution for it easier to understand but it will take time. Feel free to skip the level.

Thanks for playing.You can press E again to stop grabbing the block. Perhaps there should be a button prompt as some people have missed this.

You can also just hold the direction to push it. There should be no need to multi tap it. The game just doesn't register the button press till it stops pushing. 

I agree that it's a bit easy to accidentally restart with R being so close. I'll try to find a more reasonable binding.

This quite funny.  I haven't played warioware but I assume this is inspired by it since it jumps between short minigames.

The art is very cute and cohesive.

The audio is polished and fits each minigame.

The story sequences are funny.  I feel that some of the sections lack buildup. Like you just randomly start cooking or shake your head to music.

I think it manages to do everything it sets out to do. Congrats on finishing your GGJ entry.

The shooting is fun. As Steventus said, more gameplay-changing powerups would be good. In a lot of survivor games, they increase the player's arsenal with a lot of weapons/ability powerups. That goes a long way towards making each build/run unique. 

I think the art assets are fine but the color theme lacks contrast. I haven't played devil daggers but it has red accents on black enemies which contrasts a lot. Here the floor is blue. The hittable parts of the enemy is blue. The transparent red body makes it even harder to see. I would suggest rethinking the color scheme here.

Trance music is a great choice for a survivors like game as they tend to be "zone-out" games. With some more SFX it would improve a lot.

Overall, it's a fun entry. As a programmer, I totally understand the pain that is art. Picking a  good color palette can help a lot in that regard. 

I meant that a button to rotate the camera by 90 degrees would make it easier to align the camera for jumps.

Thanks for playing. I guess I got a bit used to playing the game in the editor with no sound haha. I'll try adding some royalty free stuff as some other people suggested.

Thanks. I wanted to make it intuitive and accessible to even to people who don't play puzzles. It's great to hear that you enjoyed it.

Thanks for playing all the levels!  Yeah it's bit too much for a demo. It's pretty much a  playtest at this point. Originally I planned for like 40 levels but it just kept growing haha. I plan to release a proper demo with a more focused set of levels.
Yes I also feel that lv35 is hard to understand at that point in the game. I added it to build up to the fold entry ability but it's hard to understand before entering folds. I plan to make it easier to understand and/or updating the level in the future.

It's a bit better when you do that. But the game occasionally wants you to jump across the xy plane instead of just the x or y axis. The side cam doesn't work for that so I wasn't incentivized to switch. Maybe a 90 cam rotate button would help.

I like the toybox aesthetic. The models fit the artstyle well

The jump is hard to gauge due to the camera perspective. It wasn't a huge issue since the game doesn't have that many tricky jumps.
The note properties/jump distance is only indicated by the color only. Which makes it hard for color-blind people. It'd be good to differentiate the notes visually on the ground and on trampolines.

The BGM is good but gets a bit repetitive over time.

I liked the different mechanics. In instrument that grew in size was pretty cool.

Overall, it's a solid entry.

A card based investigation game is an interesting concept.

The graphical style is polished and cohesive. The one suggestion I'd put is that the orange accent color you use doesn't contrast well with the background. This makes the text highlighted in that color unreadable.

As Maui has said, the tutorial portion stretches a bit long. I felt that the first tutorial stage didn't give a good idea of the whole game. The second level made it much clearer. I think you can merge those two levels.  

The resource management could use some balancing. Activating cards requires a limited resource. But you lose the card quickly as you move between areas. When the card is lost that resource is also essentially lost which feels bad.  I think it'd be better to have the buffs expire as you do actions. 

Overall, it's a very polished entry with a lot of room to expand design-wise.

Tried out your demo. Some feedback:
The controls are smooth. The models and animations feel good.

As the dotplus mentioned, arrow keys + mouse is awkward to play for most people. In fact, the first thing I did was to rebind it. In unity you can enter the multiple bindings for the same action. I recommend binding movement to WASD/IJKL etc. common combos so that people can play quickly regardless of their keyboard.

The camera is definitely hard to get used to. It had a tendency to snap to either the top of the character or below it. The former makes it impossible to know where you are going/see nearby platforms. When it's below the character, it clips through the ground and is even harder to see. As I haven't worked extensively in 3rd person games, I can't give too much suggestions but you could try separating y axis sensitivity(and decreasing it) and clamping the angles. There are a lot of GDC talks on platformer cameras so you could try researching that.

Thanks for playing. Yes it's a bit hard to know where you are wrt the level once you're inside a fold. I plan on adding stuff (a preview of where you exit the fold + a "3D" view of the level) to improve that.

As for the lack of sound, I worked on this by myself and simply didn't anyone to help out with audio. I intend to continue working on the game and work with a musician.

Thanks for playing. I totally understand. I also originally made compress(space) for a jam(LD54) and couldn't vertical folding and other cool stuff due to time constraints. I'd definitely like to play a more fleshed out version of yours.
The fold preview took some time to get right. People had complained that it was hard to know which parts were foldable before so it's good to know that it's currently working.

I wasn't part of the jam but I had to check it out since I had also made a space folding puzzle game and this didn't disappoint.

You move around the boxes and can fold anything between them. This limits the ability in a good way and the puzzles make you see each level in a new way.

The folding has the right amount of screenshake and is very satisfying. The jam was solo AFAIK and it's very impressive what you've managed to do in terms of visuals, audio and game feel. In particular the BGM was very relaxing.

I'd like to see different types of folding(ex: vertical). Also, since you have to move around boxes to make the circuits. I imagine it could be tedious to move stuff to make a long folding line. A way of bypassing that would be to have boxes that can connect regardless of distance(ex: boxes with the following property: if two boxes are in same row or column, they connect regardless of distance).

There have been a few other games utilizing space folding as a mechanic. If you plan on expanding this further you can look at them(or mine lol) for ideas. 
Overall , great job!

Thanks for the image. Yes that left marked tile can't be folded since the selector would have to start at one of the columns the player occupies. There is a in-game rule that "you can start folding from an occupied tile". Though laser turrets/flags etc. allow it, the player occupied tiles don't. I had to skip that due to time constraints during the jam.  I will fix that.

You can't fold across occupied tiles. The tile the player is in is also considered occupied. However, the player can be in the middle of two tiles and both will be considered occupied. I agree that it can be a bit finicky. I'll be reworking that in future versions to make it more intuitive.

I currently have a lot of ideas for the space compression mechanic and am working on a post-jam(and perhaps even a full game). The full version will be a separate game on itch. So in order to be notified when that's released, I recommend following me on itch.

Thank you! Yes, I do plan on adding a one click unfold option. Dragging to unfold lets you partially unfold which may be useful in some puzzles. I think it's possible to have both.

Unique concept. Had fun killing the player in various ways.

You can use the powers in the initial cutscene. Which was hilarious because I killed the player before the cutscene ended. Then I had to kill him "properly" again.

The timer text doesn't stand out. Like some other people, I assumed that the text at the top left was the timer. It took a while to realize that it was the one on the right... I think some sort of animated hourglass icon would be a better fit to represent your remaining powers. 

Great job!

Cool concept!

I totally understand the lack of time for designing puzzles. I also made a puzzle game for the GMTK jam in 2020 and I really had to cut scope. 

A suggestion would be to have a button to highlight interactable  objects  in the scene. Otherwise you have to hover your mouse over every pixel in the screen.

I think this can be expanded into a small, full game with each level being focus on some hilarious gimmick like what the golf. Would love to see a post jam version of this.

Neat take on the the theme.  I like the idea of balancing resources to get gold or give out quests.

The quests currently don't seem to have a level recommendation so it's a gamble whether a traveler will succeed or not. Showing some sort of percentage of success would also help the player make proper decisions. Also, you can only interact with each traveler once. You never know what the traveler wants before you have to give it(and you may not even have the resource at that moment). I think the player should have the chance to accept or deny the request after seeing it.

I think this is a pretty solid entry with lots of chances to expand. Good job!

I like the tag team aspect of taking down the player together. 

Seems a but buggy though. The player was shooting in a straight line. I just killed him by shooting from the sides. No swap needed.

The art is pretty cool. I also like the idea of playing as death but protect people. 

It was hard to understand whether I was attacking at all since there was no attack animation. A simple slashing animation and some juice would greatly improve the game. I would also decrease the attack cooldown. 1.8 people die every second(or so google tells me) and this version of the grim reaper seems a bit out of shape.

It took a  while to understand that I was controlling the spikes/traps to kill the monster. First run I just won mashing buttons. I didn't even realize I was killing the bots with the spikes. The level continues for a bit even after the bots are killed which was confusing. I would recommend adding death animations(like the bots  exploding) to indicate that they died.

Cool concept though. Can see this working well with some polish.

Simply but very polished. Just moving the fly around is fun. The pixel art is great and the SFX is funny and satisfying(splat!).

Simple but enjoyable. If this is your first game, then good job!

You're playing as a dungeon infested by pests(the enemies) that you want to get rid of. As the dungeon, you play  by spawning the enemies(which are the cards).  To win, you need to play cards in a way that matches the hero's  sequence of actions.

I agree the game could convey this a bit better. Some players do seem to think that you're supposed to kill the player even though that results in a game over screen...  

Quite a funny take on the theme. The way everything works is intuitive. 

I would also recommend having some method to adjust mouse sensitivity. I've also made an FPS for a jam before and there is always a portion of players who have problem with mouse sensitivity. Just letting the player adjust the sensitivity with a keyboard button goes a long way. 

Overall, good job!

That's a good suggestion. You pull enemies from the "deck" randomly so you can sometimes end up with a hand of advanced enemies at the start. If we do make a post jam version, a proper tutorial and ramp up would be in our priority list.

Hilarious take on the theme. 

 think the camera perspective and controls makes it too hard to aim the lure. This could've worked with a normal 3rd person cam, Or perhaps a 2D version of this would've worked better.

Even though it's using existing assets, I think you did a pretty good job using them together. Good job!

I think this is a pretty interesting take on the theme. However it is quite easy to cheese by trapping the player within a box. The objectives shown at the end screen help with alleviating that. I think the game can be improved by showing them as the game progresses as additional goals.

Nice!

Actually there is one thing I'd  like to check. The store page lists webgl support but  I can't verify that since the demo version doesn't allow builds yet, Does it really work in webgl? Because from my experience, webgl and jobs don't go well together.

I might make BulletSettings an inherit-able class, sure! Probably not before the jam, though, there's a ton of editor code behind it. I didn't really anticipate people wanting to add much more functionality to that side of it 😅 is there anything in particular that it doesn't do that you'd like it to do? I modelled it mostly off the particle system, though there are a few missing things (like animations and trails, etc - incredibly difficult to implement but I'll get around to it eventually...)

Understandable. Currently there is not that much I can think of outside of the line issue.

For the line, I'll make it so it has a slightly different editor when num sides is set to 2. How would you want it to behave in that case? Like, what parameters and what should change?

I think simply not having the radius act as an offset when num sides = 2 would be enough.  Radius can be used to represent the length of the line. I think the particle system does it that way too.

I'm not sure what you mean here. What would you want it to do differently? The BulletManager script only handles rendering and collision, movement is done via a multithreaded Job and everything else is handled in BulletSettings.cs (the SetValues function). You're welcome to change the movement there!

I don't think you should take one person's advice here. My needs may not match others. Anyways, the setvalues function provides a sufficient interface but the function is not virtual. So any person who modifies this directly may have problems integrating when you update the package. Ideally, you'd have some base abstract class for BulletSettings that the user can inherit from to write their own BulletSettings class that's completely independent. Again, that's just my opinion. 

When you say a preview for the shape, do you mean wire lines outlining the shape? It should already preview the bullets in the desired shape, right?

Yes. If the shape is set to a pentagon with some radius, it should show the pentagon.  IDK if preview does this already but it gave me errors(bullets were spawning correctly in play mode though) when I tried it.

I have editor coroutine installed.

with my old object-pooled approach I only managed about 500 bullets on-screen before performance dipped below 30fps on console, which really sucks for a bullet hell game!

I mostly make stuff for pc so yeah that might've  caused a bit if the bias there haha. 

Got it working. Need to play with it some more but here are my thoughts from now:

1. Spawning bullets along a line is problematic.  I set the spawn dir to "directional" and set the "num sides" to 2 to simulate  a line. But radius expands the line/edge length(bigger polygon) and the offset from the center of the bullet manager(since it spawns along edges). This results in appropriate behavior for a polygonal shape but not for a line. So there should be someway to specify a line shape separately.
2.  Would appreciate a gizmo preview for the shape when the bullet manager is selected. Kind of hard to visualize otherwise.  The above issue with spawning on a line took longer to understand because of that.
3.   The bullet controller is sufficient for jam needs but most people may want to add their own bullet controllers. 
4. Rendering the bullets without using gameobjects is a good, performant approach.  I haven't run into performance issues(yet) in my plain ol' pooled bullet setup but this'd surely save a lot of time when I need that many bullets on screen. I would totally buy this if I could integrate just the rendering and collision features with my own bullet movement controller. 

I found this to be helpful for figuring out how to design patterns. Especially part 4.

https://sparen.github.io/ph3tutorials/ddsg0.html

I also second all of jason-indie's advice.

Sorry to hear that. I can't test mac builds since I don't have the hardware but I can make and upload a build if you want to try it out.

Thank you! Feel free to check out the full version too. It has a lot more mechanics with QOL improvements. I also had a lot of fun creating the story!