next »

[Zorg]

Hi,

i'm fiddling around with the idea of a small Point-and-Click Platform Game.
So i threw together this very small prototype of the player's controls.

I'd be nice if you would test it out directly (Unity Web Player)
and tell me if the main mechanic works for you,
which kind of improvement is needed,
or why it will never work (be fun).



Controls: Mouse only.

I don't want to explain the controls at this point,
please test it and tell me if they work without explanation.

This is my first attempt to build a game in Unity.
Please be honest and constructive.

[rj]

hmmm

the mechanic is interesting, actually, but i'm not sure it lends itself to a platformer.

case in point: i got frustrated because i kept moving to the right and clicking up at the ledge on the left, and the ball wouldn't make a jump. in a traditional platformer, i'd have the controls to myself, so i'd be able to jump when i pleased and hopefully time it right enough to get on the thing.

i think either the system needs to be reworked/made tighter (i will say it works really well for that small gap) or you need to build a game around it in such a way that it's not frustrating

the controls didn't need explaining, though, i got it more or less instantly

i will say i just felt like i was playing a weird adventure game because of the interface; maybe finding a happy medium between "platformer" and adventure would be a good use of this mechanic?

[quisseh]

Your concept works, and I was able to get comfortable with it fairly quickly without instruction.

However, like rj mentioned, it can get frustrating. For me, the most frustrating aspect was the loss of precision. Precision is extremely important for platforming.

I have two ideas that I think could work together to help with the precision problem.

1. Track the cursor and constantly display possible trajectories of the ball based on current cursor position. This gives the player an idea of what types of jumps they could actually make with split second accuracy. Precision platforming is all about quick decisions. To show the player their jumping limits, the line of trajectory could disappear if the cursor is too far away from the ball.

2. Double jumping. Explanation of why this is necessary: in a standard platform game, if I am overshooting a jump, I can modify my horizontal velocity in mid air using a directional pad and correct myself. In this game, I can't do that; I can't change direction until I hit the ground. I need a way to correct myself quickly. If you implement double jump, I will be allowed to make one minor adjustment to my jump which will allow me to fix my mistakes and keep moving quickly. If you really want to make sure this double jump is only used for corrections, you can, for example, cut the force of the second jump in half (so the player moves half the distance of the original jump).

[Quicksand-S]

I agree with quisseh's points and suggestions. Strangely, I actually don't have anything to add for once. I'm curious to see what you'll do next with this prototype.

[ActiveUnique]

It took a moment to tell why the ball wouldn't jump  . I think maybe this was already said, but in different words. I'd like more control over where I'll land.

The test-level was small, but I would predict there are initial challenges to be had with precision jumping, climbing, standing on a switch, and moving underneath things.

[Zorg]

Thank you all for your initial feedback!

@rj™: I don't have a high precision highspeed platformer in mind. You are right, the world has to be designed to fit the lack of precision controls to prevent frustration. At the moment, the level is not optimized for the controls. But i think it's possible to design levels which have enough room for non-accurate jumping. For example adding enough landing space behind a gap or designing a lower ledge which does not exceed the jump height to the max. I'll add an illustration below.

@quisseh: Displaying trajectories would be a solution, but i think it may be too simple if you constantly see the exact movement waypoints. It's a bit like a cheat mode in a pool billard game, right? But there is a bigger problem: i am not very good at programming, i simply don't know how to approach this. See illustration below.
I did not think of double jumping before nor any other possibility to correct the jump in mid-air. Good point, it's very common in platformers. I don't like double jumping very much in general. Maybe i'll later apply a force towards the target (yellow gem) to enable some correction. At the moment it would interfere with my programming of the jump. See below.

@Quicksand-S: I was sure if i would only get one response to this thread it would have been written by you. I was lurking some time in the forums and i noticed you are always giving feedback to everything. I have a vague direction for the game in mind, but maybe it will be boring and frustrating instead of fun, we'll see. Feedback is very valueable. Maybe you have some comments to the upcoming illustrations?

@Activeunique: Lack of precision is noted. For climbing i'm thinking about enabling wall jumping (easy to implement). I'm aware i have to prevent situations which can't be handled with the controls. At the moment i don't have industry-levels with switches, cogs an moving platforms in mind, i'm trying to go for a relaxed, natural, casual direction.

-----------------

Some technical illustrations:

Movement, as-is state


I used an overlap circle for the groundcheck. On ground a simple clock-wise torque is applied if the target is on the right and anti-clock-wise torque if the target is on the left. At the moment jumping is only restricted by two conditions:
1) The target must be higher than the player
2) It has to be possible to jump from the current position to the target with a limited initial velocity (impulse).
All obstacles are ignored in the jump algorithm resulting in infinite jumping against ceilings or against walls for example.

Precision?


In addition to improving the controls i want to compensate the lack of precision with a forgiving level design.

Better rolling?


Nobody mentioned the camera jittering which occurs if you place the target in the ground below the player. It drives me crazy! I'm planning to reduce the torque towards zero if the player is on the same x-position as the target which should solve this problem.

Better jumping?


I think a simple solution for a small improvement of the jumping behaviour is to ban flat high speed jumps by limiting angles (a or b). Another improvement would be to prevent jumping into the direction of the slope the player is standing on.

Trajectorys?


I think i could write an algorithm to display case C problems. B and A: no idea. :/

[Quicksand-S]

I think one issue I had was just that it's unclear what the jump-range is. If I click within range, the "character" jumps, but if I'm out of range then it just tries to move there. I think that it should always try jumping if I've clicked up high and it's within a certain horizontal distance of the target point. That would make jumps up to ledges (like on the right side of the test map) much simpler to pull off, I think. Actually, I think that might solve my only real issue with the jumping.

The only "problem" I currently see with that method is that it would take away the only option available to me for stopping on a slope. Right now, I can put the goal out of reach and watch the ball move back and forth try to reach it. If "out of reach" just made my ball jump endlessly, then I'd have no way to stay put. Maybe that's not a problem, though. It is a ball, after all, so rolling down slopes is expected.

It might be worth considering only having the ball jump once per goal, so if the jump misses then it won't try jumping again and again.

Another improvement would be to prevent jumping into the direction of the slope the player is standing on.

That might be a good idea, although it's kinda fun to leap up hills.

B and A: no idea.

How about having it that if the goal is lower than the ball, then it tries its best to stick to the ground rather than jumping?

[Zorg]

@Quicksand-S: I let some friends try out the prototype without telling them what to do and learned a lot from their initial actions. You are quite right, the jump range is unclear. They tried to click higher for a higher jump which resulted in rolling, not jumping.

I did a small calculation to find out in which area you would have to click to get an immediate jump response with the current controls. Excel says it's a circle:



This should definitely be corrected to some sort of a rectangular form which is obviously more intuitive (restricting vertical and horizontal jump velocity individually).

+ Jumping only once per target may be a good idea.
+ Leaping up hills should still be possible.

I don't understand what you mean with "try its best to stick on the ground". Not rolling down ledges if it would lose ground contact? If you place the target below the ball it will never jump and tries to roll to the target's x-position so stopping on a slope is and will be possible this way.

Thanks again for your feedback!

I'll try my best to present a reworked version in some days (have to work for money, too).

[Quicksand-S]

This should definitely be corrected to some sort of a rectangular form which is obviously more intuitive (restricting vertical and horizontal jump velocity individually).

I'm of the opinion that the player should be able to click anywhere and have the ball attempt to move/jump to that spot. Naturally, it shouldn't always succeed and should have limits to how far it can jump, but players will learn that limit more easily than they'll learn, "If I click here, it will jump and if I click 1px higher it won't."

I don't understand what you mean with "try its best to stick on the ground".

I'm thinking it might be a good idea to apply some downward force, so that the ball won't fly off little bumps/hills from the physics if the player is trying to make it go down.

[Zorg]

This should definitely be corrected to some sort of a rectangular form which is obviously more intuitive (restricting vertical and horizontal jump velocity individually).

I'm of the opinion that the player should be able to click anywhere and have the ball attempt to move/jump to that spot. Naturally, it shouldn't always succeed and should have limits to how far it can jump, but players will learn that limit more easily than they'll learn, "If I click here, it will jump and if I click 1px higher it won't."

I think we are talking about the same thing. I added a green border to the last image which outlines the new jump-immediately-area.

I'm thinking it might be a good idea to apply some downward force, so that the ball won't fly off little bumps/hills from the physics if the player is trying to make it go down.

The downward force would make it harder for the ball to roll up a hill which is already very slow. But it's an interesting idea and points in the same direction as controlling the jumps in mid-air. I'll think about it.

[Zorg]

Hey there!

I did not have much time yesterday but i tested the new controls (and produced some bugs, too):
http://zachau.info/krams/unity/platformer/platformerv02/

The jump works like this now:



New jump conditions:
+ target is higher than the ball
+ target is within a defined x-range (green arrows)
+ the jumping angle is not too horizontal (i displayed the jump angle in the console before and by chance it was below one degree which resulted in a massive jump towards a slope and out of the map. The ball only jumps 1-2 unity units high but it passed besides the lava object, which is 100 unity units wide.)

If the target is too high, the ball will jump as high as it's possible anyway (blue dotted line). The ball should jump only once per target (which does not work sometimes, i guess i messed up the execution order). Rolling is still the same.

I think it's an improvement, the controls feel better now. Did i already say thanks for your valueable feedback?

[jiitype]

I was surprised how good the controls felt, I spent a few minutes just clicking around watching the ball jump. This has potential

[Quicksand-S]

The jumping works great. Nice job.

I only had two "issues" with the latest version.

-Sometimes it feels really strange that the ball gets a "boost" while moving almost horizontally. I'm guessing that's actually a jump, but because the angle is so shallow it just comes across as a sudden burst of speed out of nowhere and makes the movement feel jerky.

-The ball doesn't slow down after passing the goal. If I click the top of a hill, it'll zoom up there and right back down the other side without even trying to stop. This could naturally be made part of the game, but I personally would appreciate at least a little bit of braking.

[ActiveUnique]

I like clicking above the maximum jump height, it's a bit more reliable.

What I've discovered this time is the waypoint vanishes in most instances when the ball actually jumped, but not always. Leaving points inside walls I was able to keep it jumping repeatedly to the same spot.

Another thing is the waypoint also disappears after the jump is completed if I jump and try to click again right away changing the location, which I am not sure about.

That's all that seems relevant. Extra: I right-clicked and found a menu with full-screen option. No single buttons on the keyboard seemed to do anything.

[Zorg]

@ugabuga: Sounds good, thanks for testing an the kind words.

@Quicksand-S: This boost should not occur on horizontal ground (because the jumping angle is restricted). On slopes it's possible to jump into the slope or parallel to the slope. The gradient of the slope is currently not taken into account, but i'm planning to avoid too flat jumps completely.
I did not think about stopping after a jump, yet. The rotation of the ball is heavily damped in general and torque is only applied on ground. Maybe i could add backward rotation if there is no new goal set while the ball is still in air so the ball will brake when touching ground. I'll think about it but i'd like to program other things first.

@ActiveUnique: Yes, the waypoint disappearing/not disappearing sometimes and the possibility to produce an infinite loop is a bug. I know the reason why it occurs, i simply did not program properly.
The menu should be a standard unity menu. I'm planning to stick to one click/tap mouse/touchpad controls, i did not assign any keyboard controls, yet.

---

Today i tried to get some editor scripts running to triangulate meshes from polygon colliders and saving the gameobjects including the generated meshes as prefabs for level generation purposes. The main problem is that i always produce errors if i try to update the meshes (trying to save a mesh which already exists).

[Caulder]

I think this has a good deal of potential. Especially as a touch-based game. I too think that clicks inside terrain should be negated. Using momentum as a mechanic would be cool, like to smash enemies or break through blockades. 

[Zorg]

@Caulder: I'm not sure about the gameplay at all, at the moment i'm going for avoiding instead of killing/smashing enemies (which do not exist, yet).

---



http://zachau.info/krams/unity/platformer/platformerv03/

Controls: Mouse only.

Third version. Did not have much time to work on the game, lately. But i had fun playing around a bit with low-res assets.

+ added some sprite assets
+ added a fade-in and fade-out script (video tutorial by brackeys.com)
+ target diamond sprite is now set inactive an disappearing on jump
+ added very basic water using linear drag
+ added basic (non-interactive, cosine) fish and floating platform behaviours
+ added placeholder background and a basic parallax effect

- the map is still very small, not very much to see/explore there.

Maybe i'll open a new devlog thread in the devlogs subforums, if i manage to turn it into a game.

[Quicksand-S]

I'm not a huge fan of the ball or flower graphics, but that's just personal preference. They're made fine. I do think the water could stand out a bit more. I didn't notice it until my ball got slowed down by it.

Anyway, I really like the current controls. You didn't mention changing them, but I don't remember them being so good/predictable/consistent. Outside of water, ball always seems to go where I want it to and rarely jumps earlier than expected. It's pretty impressive.

I only really had two issues with this build. I found it misleading that the ball bounces at the start but isn't actually bouncy at any other point, and that the water was annoying to get out of. I would generally expect upward movement in water with a streamlined object to be faster, since buoyancy gives you a bit of a boost. I could be wrong about that, but it just felt off to me and I think that a little boost would make navigating through areas with water go more smoothly. You could even potentially make it part of a "puzzle", with the player having to use water to launch onto higher ledges.

[Torchkas]

I honestly think the ball should be made a lot dumber.

Right now there's simply too much of a lack of control. Your ball reacts whenever you click somewhere on screen, but it doesn't respond in an obedient manner. Instead, it tries to figure out through some AI how to get to that point. This means that as a player you don't actually get to decide how your ball gets to that point.
I think this completely ruins the gamefeel. As a player you feel like you aren't very much in control of the ball. Instead some other unnatural force (not gravity or water) is deciding when your ball gets to jump.
I honestly think it would be better if there was a separate jump button. Or if the game simply wasn't point and click, but that you could change the point you want to go to at any time without having to constantly reclick. Having the character, that the player controls, have a complex AI that you'd normally see with enemies is just not something I'd recommend putting in a platformer.
You see, a platformer is all about control. The entire satisfaction behind traversing obstacles in a platformer is that you are the one who made the character traverse those obstacles. It wasn't some math that decided when to jump.
Speaking of which. I really recommend against jump arcs with a high jump like this. It's usually better if the player can change their direction in mid-air because with a high jump arc it is less easy to dictate where you'll land the moment you jump.
I was first going to criticize your flaws in the level design, but I realized that most of the punishment that I got out of it was caused by the lack of control I had. I do think it would be for the better if you changed the controls around.

[Kiwisauce]

I think Torchkas hit the nail on the head with their analysis of why this feels off-putting as a platformer. The controls feel fairly smooth in the most recent demo, but I never felt that I was controlling the ball myself. The vibe that I got from this most strongly was some weird platformer-RTS hybrid, since I felt like I was just directing a unit that sometimes did exactly what I wanted it to but often didn't.

My advice might be a bit radical, but here it is: drop the jumping mechanic, and drop the AI. Another way to pull off this concept might be to use a grapple or something. You could totally have tight mouse-only controls if your main way of getting around was to grapple yourself to platforms and bits of terrain, and I feel like it could lead to some pretty neat-o level design.

This would, of course, be a different game than the one you've been presenting. I feel kind of bad for suggesting this after looking at all the fun you've been having with math to get this to work smoothly, but those are my thoughts, so there you go!