itch.io

Great idea: I've been working on something similar lately, but you pulled it off better than I would, probably. In my prototype, however, I implemented fog (as is in Flatland) and I recommend you try it out, too: it's a great addition that gives depth without introducing an additional dimension.

The only other suggestion I have is supporting arrows to rotate the camera instead of only the mouse, since it's only 1D movement.

I love this kind of games, and I loved dethrone. I'm not going to talk about what's good, though, I'll just leave some (hopefully helpful) criticism.

• The wall jump doesn't feel great. I think the height you gain is too little to feel impactful.
• Upon landing, the character slides too much IMHO. Although it adds to the difficulty of the game (which is a plus for me), it feels like you don't control it at all.
• It was extremely bold of you to implement moving platforms in a game jam. I clap you for that. However, the expected behaviour upon jumping while on a moving platform should be, IMHO, a jump with some side speed.
• Also, regarding moving platforms, I encountered a small bug. On the last level (IIRC), there's this moving platform at the bottom of a vertical corridor. Strange things happen if you jump against the right (i.e. in the direction of the movement of the platform) wall, like getting stuck to the platform.

With a XBox controller, once I enter the tutorial I can't do anything.

That aside, the game looks pretty solid. The only thing I'm missing at the moment is button configuration: I kind of prefer to jump with A and attack with X or whatever.

Also, is there any plan to add a AI to the game?

I'm totally, 100% stumped, to be honest.

Mimicking cartography, I'd love the game to be a solitaire pen and paper game, but the theme hit me hard.

I think that being bullied, almost shot to death by all his friends and uncommonly squared might play a part in it.

Oh, thank you. I'm by no means a sound designer: I've been playing around with the TIC-80 SFX generator and I found that out. Also, if you know how to play around with the TIC, you'll find out that I have a (bad) BGM ready and working.

Thank you. Did you manage to make the FUTCCGCSC smile? 

Thank you, it's one of those games that I spent more time on playing than on developing when I got engrossed in playtesting. 

I've been playing this game for a couple of days. Here's my review:

• I have this really bad habit of skipping the description when I'm about to play a game on itch. Maybe because a good game shouldn't need an explanation, but mostly because I'm lazy. Either way, it took me a good amount of time to understand what the game actually was. It's not the most intuitive of games, but once it clicks it's not hard to play and understand.
• I feel like 10/64 is just too small, IMHO. Also, 64 is a strange number: I got the feeling that you reused a Poker deck as the base (52+2 jokers) and added 10 cards, but there's no reason to do so in a digital card game. 65 with 50 dungeon cards and 15 from your deck or, maybe better, 50 with 40 dungeon cards and 10 personal ones.
• I feel like you could easily forget to watch your energy (or, at least, it happened a lot to me). In any case, you should probably put something on cards that can't be played, since once you start recognizing cards from the artworks only you will be playing them without reading the "insufficient energy for effect" box. Something like changing the color of cards without enough energy would work, too.

By the way, I'm kinda hooked to the game: are you still planning on bringing it to mobile?

I see, but that's kind of an ass move on their part, though.

As a small side note, I happened to remember it was an open source. I've never been so wrong in my life. 80€ for the base plus 100€ for the iOS exporter + 70€ for the Android exporter and 45€ for the Mac exporter is a pretty prohibitive price.

First of all I'm a sucker for the graphics, even though I can't say I've quite understood what the character is supposed to be (in some frames it looks like a man on a pogo stick, but that's definitely not the case).

In any case, it looks like it's a common platformer with no particular quirks, so here are some "off" things I found while playing:

• The controls are... unusual. Why would I want to move with WASD but still jump with up? As a dev, I always use WASD as test inputs since I more often than not have my right hand on the mouse, but that's not the case for the player, so if you aren't meant to use the mouse WASD can AT MOST be the alternative, not the main option. I'd just have both WASD and arrows mapped to the same thing and, if you insist on having a separate button to enter doors (instead of the jump button) you can use the down button which is unused.
• The jump is really nice, perhaps only a bit too tall at its max, but definitely enjoyable. However, I can't say the same for moving around: there's too little acceleration and as such it feels unresponsive. For the feel the game has, I'd completely drop the acceleration part and have immediate velocity changes, but that's your choice.
• Is there a way to let the life count go down? I start with 2 lives and, no matter what I do, I always stay at 2. Not a big problem, but still a full-fledged bug out there.
• 4 hits seem really like a lot. You can plow through all of the levels even by taking hits just by tanking through enemies. Most of the deaths come from falling or hitting spikes (which, by the way, don't seem lethal as they are. I'd try to make them longer and more pointed).
• There's a small bug when you jump and then keep the jump button pressed, you jump again when you land but the jump sound bugs out and is played multiple times. It's even worse if you jump while getting hit by an enemy and, when you land, you have both a direction and the jump button pressed, in which case the jump sound is played until you run out of invincibility frames.
• Speaking of bugs, although this might be intended, you can run off a platform and then jump even after a while after you've been airborne. Usually, this is intended with much shorter time-frames and is called "ghost jump", but definitely not with this length. Anyways, it feels great, in my opinion, so you should keep it.
• Last one I swear: you can, for some reason, get a speed up forward when you crash into a zombie from above. I don't really get based on what it happens or not.
• As a grammar nazi, you should probably rewrite "Thanks for play" into "Thanks for playing" at the end of the game. You might also want Game Over there instead of end game, but that's a personal choice all right.
• From a game design point of view, if you didn't have enough time to make enough levels, add some reason to replay through them: in my case, picking all coins did it, but at the end of the game there's no screen telling me how many coins I had picked out of how many there were. Since you have the SMB scroll (where you can't go back after the camera moved) I think you should use that to make some coins impossible to reach after you've gone past a certain point. Also, definitely add a timer: this kind of short games with strange physics are a blast to speedrun (expecially since you could abuse the zombie speedup bug), but players like to have an "official" timer to read as soon as they finish the game.

Ok, let's start: first of all, until now, this is the game that best fits the theme, IMHO. Also, the jump feels real good, so that's a plus. However, there's a good list of cons to the game. In no particular order:

• My antivirus recognized it as a virus yesterday, so I had to get it virus-checked before playing it today. Not your fault, probably Clickteam's, but still is a problem.
• The game defaults to a specific screen size and you can't change that. What's worse is that you can resize the window, which just makes the game screen float at the center kinda awkwardly. I have never used Clickteam Fusion, but I suppose that it's a low-level engine where you have to draw rects and sprites autonomously, so of course defaulting to a specific size is ok. However, it's not hard to implement a world coordinates system and use something to convert from world to screen based on the size of the window, and I'm sure Fusion has something to read current width and height of the window. If you really had to default to something, you would have been better off doing so at fullscreen, since games feel more fulfilling, IMHO, played fullscreen as opposed to windowed.
• The main mechanic is ok and I'm not good enough at the game to test that, but I fear that the moving threat could be broken when moving at extremely high speeds if you didn't cap that out.
• Some of the diamonds spawn extremely close to spikes (intersecting them) and the spike's hitbox is fit to the sprite. This is a problem game design-wisely, since you always want to let the player do small mistakes and not be punished for those if your game isn't supposed to be a rage game. I would have let the diamonds spawn in a way that their sprite doesn't intersect the spikes AND still have made the spike's hitbox smaller than the spikes themselves.
• The player floating midair is kinda awkward. You should have put a ground under them or at least moved it much further down.
• The game over screen is a tid-bit broken, as in it only shows the unit digit of your score (so if you scored 17 you'd get 7 in your game over screen). Probably that's due to the white rect being made to fit only one digit instead of being adaptive and the text being black, perfectly blending with the background.
• The replay and main menu texts in the game over screen have a strange behaviour. I don't know if that was intentional (and if so, why?), but you can only use them by clicking directly on the text. The common behaviour (which I think you implemented in the start button in the main menu) is to have an invisible rect around the text that can be clicked as a button. This is the point that confuses me the most.
• In the main menu you only have instructions for jumping (and, let me say, shift is a pretty strange choice. I would have gone with both spacebar and up arrow), which makes you think you can only do that and not move left or right. It's easy to realize that you can move left and right, but if you give control instructions, give them all.
• Also, you might want some music in the game screen, but I see that being a problem when time-restrained.

Sorry for the rant.

My screen doesn't support 1920x1080 (I don't even get the option in the Unity launcher), however 1366x768 and 1280x720 should have the same resolution as that and still I get it zoomed in instead of fitting to the screen.

Tried the game out up until level 5. However, I'm having resolution problems and a lot of the screen is cut off for me, so I can't progress to level 6.

Either way, cool theme, nice to the eye, and the gameplay feels fun, but you definitely need to fix whatever's up with the resolution. 

Also, the shape of the collider for the cereal kinda bugs me, but I think that's intended.

Which level did it? 

I agree, could have handled the physics values better. I'll try to fix that in my next version of the game.

Thank you for taking the time to review my game (and also having tried to spend some good words on it). To answer most of the points in your video:

1. I had a lot of trouble even only submitting the game. I've worked on it a whooping 3 hours after ditching the previous game prototype after realizing I wouldn't have had enough time to complete the level design for the other one. After submitting the game, this is the first time I managed to access my PC. Mind, though, that this is not meant to be a justification, but it's more of an explanation with attached apologizing.
2. I've explained in a devlog why the game has no description whatsoever, but it's nothing relevant, actually.
3. The game is absolutely lacking any kind of unnecessary (gameplay-wisely) effect. I was planning on a bouncing sound and some screen shake, other than a bare obvious BGM. Sadly, I had no time to implement any of those, but I agree they are important for the game.
4. In the aforementioned devlog, I also talked a bit about controls, but I did a small mistake: I should have hidden the mouse from the player. Actually, the way the player is meant to reset is by using the up or down arrow (and some other buttons which I don't really remember, but they should be left ctrl and spacebar). The idea of exploration should have also hit the player which had to find the controls. The main concept was having the player think "ok, the star is above me, I want to get to it, so I should want to jump, let's try it" and hit the reset button. Not hiding the mouse has been a huge oversight.
5. Physics: the game uses Unity physics. However, instead of most games, I don't simply push the ball left or right, but I actually add torque unto it. This makes for good on-ground controls and no air control (which was my first idea). However, I later added a small amount of directional push in order to add some air control that allowed for small adjustments (the last star is impossible to get without said air control, which also is the first star you get). Torque and push values (other than friction, which is much more relevant than one would initially think) were adjusted during the level design phase, but this limited me in the amount of modifications I could make. Hence, when I realized that you could climb incredibly steep edges (I think you didn't try that, but you can climb basically anything as long as you can approach it the right way), I decided to make that into gameplay instead of removing it. However, I couldn't do the same with trying to add more reactivity.
6. The problem with having a hard time seeing whether you are moving or not hit me 10 minutes before submitting the game. I wanted to stick with solid colors even where I could have avoided it by using the background loophole in the rules (which I had already abused in order to make complex platforms). I didn't know how to fix that quickly, so I left it as is. In these days I thought I could have zoomed the camera out proportionally to the player's speed. Misplay on my part.
7. Ironically, the selling point of the game was at first (in my mind) controlling a ball among platforms at high speeds (which worked once in your video). However, the relatively poor level design and the camera problem never quite gave that feeling except when the game was going exceptionally fast (the half-loop you hit at 10 minutes in the video).
8. I think I might have added an indicator of the general direction of the nearest not picked star in order to make the player not completely lost: since moving in this game is not as linear as following the arrow due to having to move according to the platforms, this would still have required you to find a way to the star of which you knew the general direction of.

As soon as I have time, I'll try to fix as many issues I can see and update the game (post-jam). If I do, would you mind trying it out again? I'd love to hear some feedback from someone who tried the first version of the game.

Yes, I decided against having a jump available because it would have conceptually been weird, in my opinion, with loops and stuff like that being in the game. 

Also, the game is designed to be ported on mobile, too, so I'd rather not add yet another button. 

After a quick playtest of the game, here are my two cents about what the game did well and what could have been improved (both within the scope of the 24 hour game jam and outside it).

The concept

I must admit I like the concept of the game: the idea of two graphic styles fighting to conquer the field is pretty nice. The game is also what's most likely my favourite genre ever , platform fighters, so I'm kind of biased towards it.

Either way, the game supplies two characters with really basic movements and two simple attacks (one is quick but weak while the other is slow but strong). As far as the attacks are concerned, I've only got praises for it: even though there's not much versatility with only two attacks, that still managed to characterize and differentiate the two playstyles.

The gameplay

One of my biggest problems with the game, though, is the movement: it seems that the out-of-the-box physics engine was used, with regular forces used for movement. While using unity's physics was definitely a good choice for such a small time window, I think that a little more focus on movement (making it snappier) would have made for a much better game (since movement is the basics for a platform fighter). Techinicalities incoming: it could have been a wise choice to manually change the Rigidbody2D.velocity vector for side movement (or, if you wanted to stick with forces, greatly increase them and use linear drag to limit max speed, tinkering with gravity if needed for vertical speeds).

I get that dashes are implemented to solve the problem of slow side movement, but either way they feel a bit too exaggerated (speed-wisely) to me. Also it feels kinda awkward performing them with the down button rather than double press of the direction you want to move into.

The user experience

Luckily Unity lets the user re-map input buttons, but I'm kind of iffy on the default choices. Either way, that's not too big a problem IF the user is used to Unity's player.

As far as the menu is concerned, it's a bit painful not being able to navigate it with buttons (since joypads are supported, too, although I did not test them). Not a big problem, either way.

Also, the post-win screen is a concept I like (and I also have implemented similar ones in my games) that lets you play around after winning, but, unless I missed it, there's no way to manually end it and have to wait a pretty long time just to move on. I think that a "press BUTTON to continue" would have been a reasonable addition within the time limits of building the game.

The in-game UI is really cute and intuitive, nice!

Small technicalities

These may seem like serious rants, but they are just small things I noticed that rubbed me the wrong way, nothing deal-breaking:

• I think that the choice of a rounded collider makes some interaction feel unnatural (e.g. standing on the edge of a platform or, worse, hitting it full-speed).
• The walls that limit the area are clearly invisible rigidbodies and the fact that they have friction feels too strange.
• Similarly, I think the ground has friction too, which is not great in my opinion: since you already have problems with side speed, it would have been better to remove friction to at least improve on-ground movement.
• Players can stand on top of each other. This, alone, makes me pretty uncomfortable, but I get that fixing  would have taken a bit more of time (it would have meant separately handling Player-Player collisions by using a different collider). However, not being able to jump while on the other player is strange enough and when it happens it wrecks the flow of the game. I don't know how you handled the grounded state, but usually it's not a hard problem to solve and most often than not involves simply adding a variable.
• The lack of linear drag makes some movements awkward (expecially dash-based ones).
• Discrete collisions are rarely a good thing in such simple games: it's easy to have the two characters bypass one another if they dash one against the other (and I think, but have not tested it, that it could be possible to break something else by speeding up that much). Rule of thumb: if the game is not resource-intensive, enable continuous collision detection on any rigidbody you can think of.

Overall

The game is definitely enjoyable and a great achievement for a group of beginners attempting their first ever game jam. Some points could have been fixed in the same time window, but it's easy to miss them when cramming through the development of a game.

I hope that everyone involved had fun with the project and will want to get better at it: I'm looking forward to see another project (perhaps at CPIT3?).