Fractured Soul: response to feedback
Cosmologicon on 2011/04/27 04:44
of Multiverse Factory
I can see that a lot of work was put into it, great work.
I can't figure out it came out from a "random-people" team who never worked together. Very very good job.
Superb entry, especially the puzzle design.
Very nice platformer puzzle game.
A thoroughly enjoyable game.
A really great game.
love the game mechanics. Nice game
Had tons of fun playing this!
The sounds were quite fitting. The background music is a good match too.
This is great! Well done!
Very well made game.
The graphics and visual effects of sprite during the jumps were amazing. background sound was good too.
Great puzzles that made me think.
Thank you! It's definitely helpful to know what we got right. The judges mostly agree that our game idea, sound/music, level design, and overall implementation (nuts and bolts) were good.
Now on to the suggestions for improvement....
Walk cycle is broken
Would benefit from a bit more variety in the scenery
Bland environment
The disparity between the detail on the character sprite/statues compared to everything else was noticable
I found the interludes unimaginative
Some of the humour was a bit... lame
I for one agree with all of the above. The graphics and the writing were the two major content-related issues I had with the game, and I wrote about them in the postmortem.
Act I "tutorial" felt a little longwinded
Fair enough. We'll see about cutting it down. Maybe spread it out so that the tutorial doesn't all appear at the beginning.
Disturbing camera
The camera jumped around a lot
I expected to get a lot more negative comments about this. I also think the camera is disturbing, and at the same time we wanted you to see what a button does when you push it. We've gotten some suggestions about how to get both, still not sure what's best.
YOU NEED TO BE ABLE TO WALK PAST A DARN PORTAL WITHOUT GOING IN
I'm a bit puzzled by this. Did you not realize you can walk around the lobby levels by going just underneath the portals? Maybe a different tileset would make this clearer.
I think most puzzles would be equivalent if you could just drop a statue and wouldn't have to start from the gate again.
an undo button would be nice
We'll consider starting where you drop a statue, and hopefully address the repetitiveness one way or the other. But for now I'll just say, there are subtle issues involved that you probably wouldn't think of until you've tried it. There are challenges that only work if you respawn at the start. For instance Ascension could be beaten with four statues if you spawned next to the last statue you placed; many other levels are the same way. As for an undo button, none of the mechanics that made it into the game would be broken by adding that feature, but there are other mechanics I hope to add that would.
Jumping feels a bit odd, probably due to the tile system
lack of solid platforming physics (for example you want to move a little and fall into a pit instead).
The sprite was difficult to control when jumping around the blocks, margin of errors was too little.
The grid-aligned physics helped most of the time, but sometimes got in the way and made the game feel glitchy.
We'll see what we can do. The whole point of the grid-aligned physics is to remove the margin of error with placement. Either you can make a jump easily or not at all. There should be (almost) no jumps in the game that require any skill. Probably the best thing for making it easier to control is getting some playtesters to try out a variety of settings.
cool idea, but needs work
the game is boring when you do the same level for 8th time.
not very fun
Just little platform game without goal.
Thanks for the feedback, not sure what we could do about it. We're definitely open to suggestions you might have as to how to improve the fun or goal!
similar to Braid to which it compares unfavorably
Okay, I'm sorry we couldn't make a game as good as Braid for pyweek. ;)
Thanks again to all the judges, and to richard! See you next time!
(log in to comment)
Comments
Cosmologicon on
2011/04/28 12:16:
There are two situations where being grid-aligned matters: placing statues and making jumps. I wanted the character to move more or less freely, but not let you place a statue anywhere you couldn't, or make any jump you couldn't, if your motion was restricted to a grid.
For placing statues the solution is, when you press space, he walks to the nearest grid-aligned point and then places the statue. I think this works out fairly well; the only time it might be an issue is when you're standing more than 50% off a ledge and press space. He walks off the ledge instead of placing a statue anywhere. (We chose not to have him place a statue upon landing, since that's probably not what you wanted.)
Making jumps is harder. When you start a jump and you're not grid-aligned, the game detects how much of an "advantage" you've given yourself by not being grid-aligned, ie, the number of pixels past the last grid square you start on. During your jump's ascent, it subtracts off this advantage, until when you're at the apex, you've lost all the advantage. This had some subtleties as far as changing directions during a jump that affected an early release of the game, but I think we fixed it.
Now, that's all feasible, but there's a problem. In order for this to work, the player needs to able to get the character onto a grid-square fairly easily. If you're jumping from the head of a statue, you need to be able to get aligned with that statue. My initial solution was, every time you stopped moving, to either have him snap back to the last the grid square (if you were only slightly past it), or continue walking to the next grid square. ldle thought this looked natural if you were walking, but not if you were jumping. I agree, so we compromised by only having the auto-alignment happen when you stop walking but not when you stop jumping. I don't know if you noticed, but it's impossible to stop walking and not be aligned. This makes it fairly easy to, for instance, stand at the last grid square before the edge of a cliff.
I think I may tweak things some more to make it even more natural, but what do you think about the pyweek version? Did you find the movement mechanics glitchy?
mauve on
2011/04/28 16:50:
superjoe on
2011/04/28 21:18:
This worked perfectly - no complaints here.
"...we compromised by only having the auto-alignment happen when you stop walking but not when you stop jumping."
This was easily detectable when playing the game. This caused me, as a player, to try to jump and land in a position that put me closer to the edge of the cliff.
"When you start a jump and you're not grid-aligned, the game detects how much of an "advantage" you've given yourself by not being grid-aligned, ie, the number of pixels past the last grid square you start on. During your jump's ascent, it subtracts off this advantage, until when you're at the apex, you've lost all the advantage."
I had no idea this was true. I don't think it's feasible for the player to figure this out while playing, you would have to read about it like I just did. So this means that the puzzle mechanics worked perfectly and it was not possible to cheat (at least with regards to jumping location). However, not knowing this fact made the physics feel "glitchy." It's the best word I can find to describe the game removing the "advantage" and me not understanding what's going on.
Tee on
2011/04/29 01:04:
Placing stone statues is perfect. I knew that statues were being placed into cells of a grid, but it never felt strange.
Jumping, on the other hand, had a noticeable effect. Not when you're stopped and you jump, that works great, but when you're walking between cells and you jump (while keeping the horizontal arrow key pressed). What happens is that it looks like there's a horizontal force against you in your ascent, then in the descent it disappears, so it doesn't have that nice parabola shape.
Now that you've explained how the jump works, it makes sense. Have you tried making the adjustment uniform throughout the whole jump? Be careful that this might allow the player to reach places he's not supposed to, though. Another suggestion to ease this problem would be to discreetly snap back a few pixels at the beginning of the jump and snap forward a few at the end of the jump. I'm sure there's an amount of pixels that's discreet enough to not be noticeable.
On another note, I noticed someone complained about portals. I didn't mention it in my comment, but it was a slight nuisance to me too. About four times I accidentally entered a portal, then I had to wait for the level to load, then for the camera to scroll around, so I could finally quit and get back to the level selection screen to wait for the floating platform to bring me to the level I wanted to enter. At the first one or two times I hadn't realized that touching a portal would automatically enter it, because I always pressed up to enter a portal. I thought you had to do that because, well, every time I pressed up I was entering a portal. :) Still, after I realized my mistake, I still entered the portal accidentally a few times. But it's maybe because I'm a jumpy person, and on the level selection screen I kept jumping for fun, and before I could realize it I was falling near a portal, and, oh no, I'm in the wrong level. It's up to you if you want to change this, though. I personally don't think it's too bad, but by your comments there's a player who was more bothered by it than me, so it might be worth it. It may also be worth it to allow the player to quit a level during the camera scroll.
Anyway, excellent work. :)
Tee on
2011/04/29 01:09:
richard on
2011/04/29 01:13:
Cosmologicon on
2011/04/29 05:13:
@superjoe: [auto-alignment on walking but not jumping] was easily detectable when playing the game. This caused me, as a player, to try to jump and land in a position that put me closer to the edge of the cliff.
Well, there's a sign in the first level telling you that won't do you any good. Not sure how we could make it any clearer without completely demolishing the fourth wall. Still, I understand why a player would be hesitant to accept it. No question it's a strange mechanic. (I tend to like strange mechanics. That's probably why I can never get the hang of physics libraries: they always want to do everything "right".) Anyway, we'll think about it.
@Tee: when you're walking between cells and you jump (while keeping the horizontal arrow key pressed). What happens is that it looks like there's a horizontal force against you in your ascent, then in the descent it disappears, so it doesn't have that nice parabola shape.
Right, that's exactly what happens. So you noticed it. It's actually pretty extreme; I think we had to nullify up to 70% of your forward motion in order to keep the impossible jump impossible. The main issue is that the jump in question - three over and one up - is almost achievable when you start grid-aligned. Even a small boost would let you do it. Tweaking the horizontal and vertical speeds of a jump, as well as the acceleration due to gravity, could change this. I think that this, along with a combination of your suggestions, would be best. I'll probably eventually have to sit down with paper and pencil and write out exactly how all these parameters interact, and optimize to minimize the glitchiness.
Anyway, I hope it's clear that a lot of thought already went into this, but it could clearly use more, so comments like this help a lot! :)
@Tee: on the level selection screen I kept jumping for fun, and before I could realize it I was falling near a portal. It's up to you if you want to change this, though. It may also be worth it to allow the player to quit a level during the camera scroll.
Yeah, I like that. Thanks!
mauve on
2011/04/29 10:37:
superjoe on
2011/04/28 07:10:
"The whole point of the grid-aligned physics is to remove the margin of error with placement. Either you can make a jump easily or not at all."This is a great idea but I'm not sure it's even possible to implement. That is, if you want your character to move around smoothly on the screen. Either your character has block-aligned coordinates or not. If so, then you can't have him smoothly transition from block to block, he has to move one block at a time . Or if not, then any time you try to snap his coordinates to a block, it will feel like a glitch.