Log In
Name:
Pass:
Online Members (0)
No members are currently online.
Current Interguild Time:
Fri Mar 29 2024 2:29 am
Member Chat Box  [click here to enlarge]
Recent Posts and Comments
« Forum Index < Platformers Board

DroidFreak36
[?] Karma: 0 | Quote - Link
Friday, May 4 2018, 7:22 am EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
I have a few ideas I'm thinking about for physics changes I might implement in HATPCR 0.6.0 and I figured I'd post them here to get some feedback on them.

(1) Coyote Time: A concept used in other platformers, but not yet in HATPC. It allows you to perform a jump within a few frames after walking off an edge, to make jump timing easier (and less frustrating). Pretty simple to implement. I actually already have the inverse of this in the game - if you press the jump key within a few frames before hitting the ground, you'll jump on impact as if you jumped on the exact frame when you hit the ground.

(2) "Edge Diving" rework: I like the concept of edge diving (pulling up Hannah's legs to land on edges she'd otherwise hit), but at the moment its implementation is rather opaque to the player, since the edge diving animation usually lasts only a few frames and it automatically triggers itself. I'm thinking maybe instead of being automatically triggered, edge diving could be triggered manually by pressing the up key while Hannah is in midair. The details and limitations of this would have to be worked out, but it could add another element of skill to the game in knowing when to hit that edge diving button. A few ideas for possible limitations:
    (a) Can only be triggered while falling (with at least a little bit of downwards velocity): Might be necessary to prevent people from being able to make 4 block jumps using it. IDK.
    (b) Lasts only a limited time: Could make it more of a choice of when to use it (so people don't use it all the time)
    (c) Lose horizontal velocity (similar to duck jumping): Another possible way to make it only useful in certain situations and make it require some timing
    (d) Something else?

(3) Remove up & down key look mechanic (in favor of free look): If I'm gonna add new movement mechanic(s) that use the up key and the down key is already used for movement, then it might make sense to disable the look up & down mechanics using the up & down keys (and only allow looking with the new free look mechanic). Not necessary, but might make things nicer so that you don't accidentally look up and down when you mean to use movement mechanics.

(4) Edge climbing using the up key: It's no secret that I've been looking for ways to allow climbing up 1-tile inclines without jumping. Another possible idea for that would be to allow players to sort of dive onto the edge using the up key and a modified form of edge diving. Of course, this would break certain levels (in particular any level that uses 1-tile inclines in one-way doors), but it should be possible to allow for those sorts of level-making mechanics via some other method (maybe a tile that acts like a one-way wall). I'm just throwing the idea out there.

(5) Reduced midair maneuverability: This change mostly comes to mind as I think ahead to implementing HATIC sliding mechanics (for the HATIC campaign). Clearly if I want the sliding mechanic to make sense, the reduced maneuverability you get when on ice would also apply to midair maneuverability, and ideally any changes to midair physics for the HATIC campaign would apply to all campaigns & levels. Probably the new midair acceleration would be something similar to your horizontal acceleration underwater rather than instantaneous acceleration like it is ATM. Of course, this probably would break some levels, especially ones that make you fall down while avoiding stuff. Those types of levels could still be made, but they'd have to account for the lowered horizontal acceleration.

Thoughts? I'll probably implement most of these if only to try them out in my dev version, and then push the ones I like to the release version so that you guys can try them out. Of course, any of these can be reverted if they cause too many problems.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
DroidFreak36
[?] Karma: 0 | Quote - Link
Friday, May 4 2018, 7:44 am EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
BTW (4) would probably be in replacement of implementing stair & ramp tiles. It'd be a lot simpler to implement, since I wouldn't have to deal with pesky diagonal collisions. I might implement a sort of macro-sized stair block that's actually a platform in conjunction with a one-way wall to give basically the same functionality you'd get from stairs without the diagonal hitbox.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
Rocketguy2
[?] Karma: 0 | Quote - Link
Friday, May 4 2018, 11:32 am EST
God wishes he was me

Age: 21
Karma: 38
Posts: 850
Location: Clinging to the last whispers of life in my decaying body
pm | email
I quite like the look of 1 through 4, but I'm not sure about 5, I quite like the mid-air movement as it is, so I wouldn't really like decreasing it


Can you feel your heart burning?
Can you feel the struggle within?
The fear within me is beyond anything your soul can make, you cannot kill me in a way that matters
krotomo
[?] Karma: +3 | Quote - Link
Friday, May 4 2018, 12:15 pm EST
The Shepherd

Age: 23
Karma: 249
Posts: 4066
Gender: Male
Location: My chair
pm | email
(1) Coyote Time: This seems like a good idea. It would probably help to make the platforming (especially in fast-paced speed sections) a lot smoother.


(2) "Edge Diving" rework: At the moment, edge diving only occurs when the player just barely misses the top of the edge of a platform. There's such a small range (in terms of where the player lands) where edge diving actually takes effect, that it's nearly impossible to predict mid-air whether or not an edge dive is necessary to complete a jump, so to have edge diving be triggered by a separate key right now wouldn't make much sense to me, if you're arguing that it would add an element of skill to the game. I would agree that this feature has potential, but you would have to increase the effectiveness of edge diving a lot compared to how it is now for it to be a good idea to dedicate a separate key to it IMO.


(3) Remove up & down key look mechanic (in favor of free look): Adding free look would require too much input from the player in my opinion and would feel unnatural. At the moment the up-down look mechanics feel smooth and natural because they use the same keys as for movement.

Also, if you want to avoid people accidentally using the up-down look mechanics, there are some alternative solutions. From how you describe the player using the up arrow key to perform an edge dive, they would only be pressing the key for a split second, so you could simply add a delay so that the player has to hold down the up or down arrow key for a little bit before the camera begins to pan. Alternatively, you could restrict up-down looking to when the player is standing on a surface, as using the up-arrow key for edge diving would only happen while mid-air.


(4) Edge climbing using the up key: Not necessarily against this one, but I'm not exactly sure what it would add; it seems like a pointless feature to me. You can easily just place a ladder tile next to a 1-tile ledge for the same effect.


(5) Reduced midair maneuverability: I think this would be a really bad idea. Adding acceleration to mid-air platforming would make any trap that involves rapid switching between left and right while mid-air impossible, while not adding much. From what I can tell, limiting mid-air maneuverability would add some depth in terms of how the player has to manage their speed, but take away a lot more from the complexity of traps and puzzles that can be made, which is the entire appeal of HatPC.

For example, the first trap in Parallax: https://www.youtube.com/watch?v=OPkkuD1xoxk. Notice how in order to hit the crates the player has to rapidly switch between left and right directions: limiting maneuverability mid-air would make this unnecessarily difficult or impossible. This isn't just a one-off example, anyone here will tell you that mid-air maneuverability is necessary for a huge number of traps. Even basic jumps like these would be a lot harder:

Code:
xx 
x  
x  
xx 
x  
x  
xxx
  
shos
[?] Karma: 0 | Quote - Link
Friday, May 4 2018, 7:19 pm EST
~Jack of all trades~

Age: 31
Karma: 389
Posts: 8273
Gender: Male
Location: Israel
pm | email
1. same as kor.
2. "
3. "
4. I don't think this is necessary, but if you do want to add it (perhaps as optional) then perhaps the amount of time the spacebar is pressed can do? a tap-hit on space would be a 1-tile high jump, barely to climb that step, a slightly longer space would be say 2.5 high, and a full click would be the regular 4?

5. meh. If any, get the g-value set so that hannah speeds up as she falls, instead of maintaining a constant speed. This way the left=right maneuverability would also vary relatively, despite not changing at all.


DroidFreak36
[?] Karma: 0 | Quote - Link
Friday, May 4 2018, 11:00 pm EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
'krotomo' said:
(2) "Edge Diving" rework: At the moment, edge diving only occurs when the player just barely misses the top of the edge of a platform. There's such a small range (in terms of where the player lands) where edge diving actually takes effect, that it's nearly impossible to predict mid-air whether or not an edge dive is necessary to complete a jump, so to have edge diving be triggered by a separate key right now wouldn't make much sense to me, if you're arguing that it would add an element of skill to the game. I would agree that this feature has potential, but you would have to increase the effectiveness of edge diving a lot compared to how it is now for it to be a good idea to dedicate a separate key to it IMO.

There are a few cases in particular where edge diving comes in handy
(a) Getting across 1 tile wide gaps in floors
(b) Slipping into 1 tile high gaps in walls (this behavior was disabled with the automatic edge diving in 0.5.0 but you can use it in 0.4.4 and it'd be usable with manual edge diving)
(c) Making certain long and/or high jumps. IIRC since HATPCR 0.4.4 it's not actually possible to make a 3 up + 3 over jump without edge diving, since I made terrain edges squishier (and thus made jumps like that a few pixels wider)

I think the main reason why it's so unclear when edge diving is needed ATM is that the animation (and the state itself) only kicks in AFTER your feet fall past the edge, so it's rarely active for more than a frame or two before you land or fall past the edge. Reworking it as I described would make it a lot more transparent when it is and isn't active, so it's be a lot easier to get used to when it is and isn't needed. I could increase the effectiveness of it more by making Hannah sort of grab onto edges while in this mode, but I think it's already quite powerful, just not all that easy to see in action.

'krotomo' said:
(3) Remove up & down key look mechanic (in favor of free look): Adding free look would require too much input from the player in my opinion and would feel unnatural. At the moment the up-down look mechanics feel smooth and natural because they use the same keys as for movement.

I think I'm gonna add free look in 0.6.0 regardless of whether I remove the vertical look from the movement keys because it's necessary to balance out the variable game window sizes I'm implementing - I want players in every window size to be able to see the same total amount of the level (regardless of how much of that fits on their screen at once). And I don't think it'll feel that unnatural. It'll only really be useful when not under time pressure (e.g. not needing to move), but I'd say the same generally applies to the current vertical look mechanic. If necessary, I can probably make it so that the player can free look while the game is paused.

'krotomo' said:
(5) Reduced midair maneuverability: I think this would be a really bad idea. Adding acceleration to mid-air platforming would make any trap that involves rapid switching between left and right while mid-air impossible, while not adding much. From what I can tell, limiting mid-air maneuverability would add some depth in terms of how the player has to manage their speed, but take away a lot more from the complexity of traps and puzzles that can be made, which is the entire appeal of HatPC.

For example, the first trap in Parallax: https://www.youtube.com/watch?v=OPkkuD1xoxk. Notice how in order to hit the crates the player has to rapidly switch between left and right directions: limiting maneuverability mid-air would make this unnecessarily difficult or impossible. This isn't just a one-off example, anyone here will tell you that mid-air maneuverability is necessary for a huge number of traps.

As I explained that change would be more for feature parity with the planned HATICR (or whatever we end up calling it) physics than for the direct benefit of HATPCR physics. TBH I don't much care for floaty physics much either but if I'm gonna implement reduced acceleration on ice in a world where you can instantly change direction in midair, that just makes no sense. I think that's part of the reason why the original HATIC physics seem so wonky, because it has a mix of instant and delayed acceleration. So... I think I'll try it out, and if it seems awful maybe I can limit the floaty midair physics to HATIC-style levels exclusively. Although that really makes no sense either because Hannah would lose her ability to instantly accelerate in midair overnight when you play through the campaigns and get to the HATIC part. We'll see.

'shos' said:
5. meh. If any, get the g-value set so that hannah speeds up as she falls, instead of maintaining a constant speed. This way the left=right maneuverability would also vary relatively, despite not changing at all.

I don't really see a reason to remove the terminal velocity. I'm not really trying to limit the max angle you can fall at, I'm just trying to make the horizontal acceleration in midair more in line with HATIC-style sliding mechanics.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
Yimmy
[?] Karma: 0 | Quote - Link
Saturday, May 5 2018, 1:30 pm EST
Resident Goody two-shoes

Karma: 72
Posts: 1625
Location: Climbing In Your Windows
pm | email
None of these are bad mechanics; we just all hate change. If you're attached to them, making a second version of hatpc reborn (like an experimental version) so you can have more creative freedom is an option.

Quote:
I think I'm gonna add free look in 0.6.0 regardless of whether I remove the vertical look from the movement keys because it's necessary to balance out the variable game window sizes I'm implementing - I want players in every window size to be able to see the same total amount of the level (regardless of how much of that fits on their screen at once). And I don't think it'll feel that unnatural. It'll only really be useful when not under time pressure (e.g. not needing to move), but I'd say the same generally applies to the current vertical look mechanic. If necessary, I can probably make it so that the player can free look while the game is paused.

This still isn't balanced??? If I make a speed trap where you need to see the whole screen it'd be easy for someone with a full view, but if I have a smaller window size I'd have to fumble with free look whilst also trying to deal with a speed trap, making it far harder. (unless im misunderstanding?)
Quote:
As I explained that change would be more for feature parity with the planned HATICR (or whatever we end up calling it) physics than for the direct benefit of HATPCR physics. TBH I don't much care for floaty physics much either but if I'm gonna implement reduced acceleration on ice in a world where you can instantly change direction in midair, that just makes no sense. I think that's part of the reason why the original HATIC physics seem so wonky, because it has a mix of instant and delayed acceleration. So... I think I'll try it out, and if it seems awful maybe I can limit the floaty midair physics to HATIC-style levels exclusively. Although that really makes no sense either because Hannah would lose her ability to instantly accelerate in midair overnight when you play through the campaigns and get to the HATIC part. We'll see.

Slipping on ice but instantly changing direction midair doesn't make sense but neither does jumping 2.5 times your height. I've played games where the ice levels work exactly like that (can't name em off the top of my head though) and it's far more pleasant than ice levels with less air maneuverability.
the reason the hatic physics are wonky is because ice doesn't reduce traction. ice just boosts you forward whenever you let go off the arrow keys (you literally don't slip if you hold up). also it isn't consistent when the jumps keep momentum from the ground or not.


Spoiler:

Interguild discord!! People use it!!
DroidFreak36
[?] Karma: 0 | Quote - Link
Saturday, May 5 2018, 2:41 pm EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
'Yimmy' said:
None of these are bad mechanics; we just all hate change. If you're attached to them, making a second version of hatpc reborn (like an experimental version) so you can have more creative freedom is an option.

Yeah, it's possible that I could add an option you can set up in the level codes to use physics closer to the original HATPC, although it still wouldn't be exactly the same. ¯\_(ツ)_/¯

'Yimmy' said:
This still isn't balanced??? If I make a speed trap where you need to see the whole screen it'd be easy for someone with a full view, but if I have a smaller window size I'd have to fumble with free look whilst also trying to deal with a speed trap, making it far harder. (unless im misunderstanding?)

Well, yeah, it's possible that there could be situations in which a wide FOV and speed are both required. That's why I mentioned the possibility of free look while the game is paused as a sort of band-aid solution to that problem. There's no way to make sure it's perfectly balanced while having a variable game window size, but I think that having a variable game window size will make it much nicer in general.

'Yimmy' said:
Slipping on ice but instantly changing direction midair doesn't make sense but neither does jumping 2.5 times your height. I've played games where the ice levels work exactly like that (can't name em off the top of my head though) and it's far more pleasant than ice levels with less air maneuverability.
the reason the hatic physics are wonky is because ice doesn't reduce traction. ice just boosts you forward whenever you let go off the arrow keys (you literally don't slip if you hold up). also it isn't consistent when the jumps keep momentum from the ground or not.

Excellent points. It might turn out that having instant midair acceleration but reduced ground acceleration actually feels fine. I'm sort of dubious about how well that'd work because it removes a lot of the impact of the sliding mechanic when you can just hit the jump key and immediately accelerate. But yeah, the original HATIC mechanics were weird for a lot of reasons which is why I'm trying to see if I can make them feel better.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
DroidFreak36
[?] Karma: +3 | Quote - Link
Wednesday, May 9 2018, 1:42 am EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
Here's a video showing some physics stuff I'm trying out: https://www.youtube.com/watch?v=KZA9sdqLULA

* Coyote time of 2 ticks (you can press space within 2 ticks of walking off an edge and still get the jump)
* The slipping off of edges mechanic is suspended while in horizontal motion (like it is while crouching in 0.5.0)
* You can press up while in midair to dive - like edge diving in 0.5.0 except manual
* Diving cannot be canceled by releasing the up key - once you begin diving, you are committed until you land
* Diving locks your left and right input keys so that you will accelerate up to top speed in the direction you're facing but won't be able to change direction or stop until you land
* Reduced midair acceleration. Currently uses the same algorith as swimming horizontal acceration but 33% faster
* Holding up while walking into a one tile tall wall will cause you to perform a short jump that will vault you over the wall (in combination with diving, which will trigger as soon as you jump because it uses the same key)
* Jump impulse reduced from 15px/t to 14px/t. Due to the other changes, you can still make all the same jumps including the 3x3 jump as demonstrated in the video (although in order to make 4 block jumps onto platforms you have to dive).

P.S. - Camera movement isn't implemented at all in that dev version, so don't mind the choppy camera. I just made it follow Hannah directly as a temporary measure until I actually port the camera movement code.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
krotomo
[?] Karma: 0 | Quote - Link
Saturday, May 12 2018, 10:35 am EST
The Shepherd

Age: 23
Karma: 249
Posts: 4066
Gender: Male
Location: My chair
pm | email
Nice to see these new features in action.

I like the implementation of coyote time, as I mentioned earlier. The new diving stuff seems like it would take a while to get used to, though it doesn't necessarily seem bad. I still think that if you are going to implement these changes to edge diving, that edge diving should be buffed so that it's more significant than it is currently.

I was definitely expecting something more drastic with the mid-air acceleration change, like something from a Mario game or something. At the moment the change is noticeable from looking at the video but doesn't appear game-ruining, so I don't think it would be a bad idea to release it as is and have it be tested more in-depth. Still, I agree with yimmy that trying to create consistency with ice slipping mechanics isn't a great reason to significantly limit mid-air maneuverability.

As for the variable game window feature, I'm not exactly sure how you're thinking of implementing it. Would increasing the size of the window increase your FOV without increasing the zoom? Or would both adjust? In general, I'm not keen on the idea that players should be encouraged to pause the game in the middle of a speed trap... it would completely ruin the pacing and intensity.
DroidFreak36
[?] Karma: 0 | Quote - Link
Saturday, May 12 2018, 5:04 pm EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
With the variable game window feature, once the game window exceeds a certain size in either dimension, the game kicks into 2X zoom. So the size is roughly normalized between large and small screens. And in general the amount of the map that is visible is higher than in vanilla HATPC. I don't think it's likely people will have to pause in order to look at the map, but there won't be exactly the same view distance on all window sizes, so making the total area that can be seen (with free look) the same across all window sizes makes it as fair as possible. There'd still probably be a disadvantage to pausing during a speed trap, but ideally nothing that needs to be reacted to during a speed trap would be a surprise - it'd either be easily visible or visible from before the speed trap was started.




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
krotomo
[?] Karma: +1 | Quote - Link
Thursday, May 17 2018, 10:59 am EST
The Shepherd

Age: 23
Karma: 249
Posts: 4066
Gender: Male
Location: My chair
pm | email
Variable game window size seems questionable to me because I can't see anyone choosing to play at a window size that will give them a disadvantage, making it a somewhat unnecessary feature. It also leaves the issues that you mentioned earlier, where people at different window sizes see different amounts of the screen.

I don't like the implementation of free look as a solution to this problem with variable game window size. For one, I don't think variable game window size is necessary, so to implement free look because of variable game window size is also unnecessary. Also, as yimmy pointed out, people with larger windows would still have an advantage even with free look.

In addition, free look comes with its own set of problems:
1) The level designer should be able to know how much of the level the player sees, so that they can organize the layout in a way that directs the player's attention towards certain areas and away from others. This is a problem with both variable game window size and free look.
2) Giving the player that much input on the camera control would force them to think way too much about something that, in my opinion, should be smooth and natural. If the player can activate free look at any time, they will end up constantly thinking about pausing the game to look at the map, instead of being focused solely on navigating the traps and puzzles. You will likely see players habitually pausing the game if you implement the pause to free look feature.
3) There's something magical about the unknown. It really feels like an adventure when you have no clue what sort of trap or puzzle is around the corner. Having unlimited free look means players will scan the entire level at the start and see the whole layout beforehand. From then on, the cave will seem less like an exploration and more like a task. There would also be no way to implement secrets, unless you add additional features.
4) As I mentioned before, the pause to free look feature would be bad for the pacing of the level. The player shouldn't be encouraged to constantly interrupt gameplay, as that ruins the immersion and the general flow of the level. My issue with people pausing during speed traps isn't about balance, it's about how a speed trap is supposed to be thrilling and action-packed, and how players pausing the game to look around would completely kill that.

If you still want to keep free look despite all of these issues, then it might be a good idea to implement it in the form of something like this viewfinder feature from Celeste. Basically, it's a tile that lets you scan a room in free look from that point. This could be a solution to every one of the four problems I listed above:
1 & 3) You could make it so that the range of the viewfinder is set using an event. By picking two coordinate points, a level creator would be able to set a rectangle area for which the viewfinder could be used. This would allow the level designer to more easily direct the player's attention to certain areas of the level, more so than if you were to simply limit the range of the pause-free look feature. It would also allow the level creator to keep players from scanning the entire level, and revealing later rooms or secrets.
2) Free look would be limited to use at viewfinder tiles, so the player won't constantly be thinking about pausing the game to look around, and can instead focus on the actual level. A visible viewfinder tile also communicates very clearly to the player when exactly they should take control of the camera, instead of them having to worry about it at all times.
4) A viewfinder tile would solve the pacing issue. The level creator could place viewfinder tiles only in locations where the player is not in the middle of a trap or puzzle. Since free look could only be used at viewfinder tiles, there wouldn't be any jarring interruptions to the gameplay. It's also much more immersive to have a physical thing that Hannah interacts with to look around compared to having time abruptly stop.
shos
[?] Karma: 0 | Quote - Link
Thursday, May 17 2018, 11:13 am EST
~Jack of all trades~

Age: 31
Karma: 389
Posts: 8273
Gender: Male
Location: Israel
pm | email
Window size reminds me of the hatic glitch. I had a vid on that..
It is solved if you simply change the tile ratio..this will barely change anything, maybe help large sizes with jumping off ledges super accurately.  


DroidFreak36
[?] Karma: 0 | Quote - Link
Friday, May 18 2018, 1:31 am EST
HATPC Reborn Dev

Age: 30
Karma: 200
Posts: 491
Gender: Male
Location: droidfreak36.com
pm | email
Ok, @krotomo, imagine you're on a 1080p screen. Which of the following sizes would you rather play HATPCR in?

Spoiler:

Spoiler:

Spoiler:

If you want maximum FOV, you'd pick the third one. If you want the game to fill your whole screen (or as much of it as a browser window can), you pick the second. But I don't think anyone would really pick the first one given the choice. Being stuck in a tiny window isn't something people want from games these days, or something people really wanted back then either, it was just a limitation of the technology of the time. If we can expand the game to fill the whole window, why would we stick with the tiny original resolution?

It's not "necessary" but it makes the game way more user-friendly and will probably make it have a broader appeal because I expect people used to modern games to much prefer it to playing HATPCR in a 440*600 window. It's not "necessary" for me to play games in fullscreen instead of tiny windows either, but you won't find me ever choosing to play them in a window smaller than my screen size except in extreme cases where my PC can't actually handle the game in fullscreen. Variable game resolution is a standard QOL feature of modern games, so I'm not going to go back on it just because it might make things unfair.

And hey, pretty much anyone *can* run the game in the maximum FOV resolution if they want to, or at least something very close to it, so if someone designs a level that for some reason requires people to have a massive FOV during a speed section (which seems like bad level design to me anyways) they can set their windows to that size to compensate. The "maximum FOV" window size would be precisely 800x1300, so even if someone has a tiny 720p screen (720x1280) they're pretty much at the maximum FOV window size when fullscreen. Most screens are 1080p at least, so they game kicks into a higher zoom level at fullscreen, but you can reduce the window size to get below the zoom threshold as shown above.

As for free look in particular:

Quote:
1) The level designer should be able to know how much of the level the player sees, so that they can organize the layout in a way that directs the player's attention towards certain areas and away from others. This is a problem with both variable game window size and free look.

That is actually (mostly) solved by free look. The point of free look is that the total distance/area that the player can see (while using free look) would be identical  between window sizes, so no matter how much snooping players do, designers can put something outside of their FOV. The possible downside when compared to vanilla HATPC would be that the view distance, while fixed, would be significantly larger than in vanilla HATPC. If you read the original thread on changing the game resolution, I also proposed a possible solution to that - implementing a shroud feature that allowed level designers to conceal sections of the level until the player got close to them.

Quote:
2) Giving the player that much input on the camera control would force them to think way too much about something that, in my opinion, should be smooth and natural. If the player can activate free look at any time, they will end up constantly thinking about pausing the game to look at the map, instead of being focused solely on navigating the traps and puzzles. You will likely see players habitually pausing the game if you implement the pause to free look feature.

Realistically, I don't see many cases in which players will pause the game to free look around. It requires the player to be in a time-sensitive section and exploration mode at the same time. I don't think level designers should ever make a situation where the player is pressed for time and also has to look at far-away objects to progress or find a secret at the same time. Expecting a player to be both exploring and running for their life at the same time is just bad level design. Anything the player has to react to in timed sections really ought to be visible either before the timed section starts or immediately visible to the player while in the timed section. Curious players could look around during timed sections if I allow free look while paused, but I wouldn't expect it to be common. It's basically only something people would use if level designers forced them to, or if they failed to scope out an area they should have prior to triggering a timed section.

Quote:
3) There's something magical about the unknown. It really feels like an adventure when you have no clue what sort of trap or puzzle is around the corner. Having unlimited free look means players will scan the entire level at the start and see the whole layout beforehand. From then on, the cave will seem less like an exploration and more like a task. There would also be no way to implement secrets, unless you add additional features.

I never said there would be unlimited free look. Players would only be able to free look within a certain distance of their character, and level designers could make liberal use of shroud (if I end up putting it in) to conceal practically the whole level from them if they so desire.

Quote:
4) As I mentioned before, the pause to free look feature would be bad for the pacing of the level. The player shouldn't be encouraged to constantly interrupt gameplay, as that ruins the immersion and the general flow of the level. My issue with people pausing during speed traps isn't about balance, it's about how a speed trap is supposed to be thrilling and action-packed, and how players pausing the game to look around would completely kill that.

I agree that players shouldn't be forced to pause while in action-packed sections, nor do I expect that allowing them to will make them do it unless they have a reason to. I mean, in situations with tight timing, doing it would actively hurt them by making them lose the fraction of a second it takes to get back into the gameplay from being paused. I mean, pausing is already in HATPCR, but you don't find yourself pausing to look around your screen and plan during speed traps, do you? It's more or less the same thing with free look, the only difference is the amount of area that the player can see while paused is expanded (and equalized between window sizes).




Quote:
Rictory for Ralkyon!

HATPC Reborn home page
Yimmy
[?] Karma: 0 | Quote - Link
Friday, May 18 2018, 10:51 am EST
Resident Goody two-shoes

Karma: 72
Posts: 1625
Location: Climbing In Your Windows
pm | email
option 2 is leagues better than option 3
Honestly,  what I've been wondering the whole time is why you need variable fov when you can just scale the image.

Quote:
if someone designs a level that for some reason requires people to have a massive FOV during a speed section (which seems like bad level design to me anyways)

How is that bad level design? From their perspective they're just taking full advantage of the games fov.

Quote:
That is actually (mostly) solved by free look. The point of free look is that the total distance/area that the player can see (while using free look) would be identical  between window sizes, so no matter how much snooping players do, designers can put something outside of their FOV. The possible downside when compared to vanilla HATPC would be that the view distance, while fixed, would be significantly larger than in vanilla HATPC. If you read the original thread on changing the game resolution, I also proposed a possible solution to that - implementing a shroud feature that allowed level designers to conceal sections of the level until the player got close to them.

Better yet, don't have variable fov or free look! Two birds in one stone!
I also feel a shroud feature would add a lot of tedium to level design
Quote:
Realistically, I don't see many cases in which players will pause the game to free look around.

Nah. It just boils down to personality. I guess you might not, but others (such as I) would really struggle to resist the urge.  Why not do it when it gives you a clear advantage? Why actually explore if I can just move the camera?
Quote:
I mean, pausing is already in HATPCR, but you don't find yourself pausing to look around your screen and plan during speed traps, do you?

yeah thats because we can look around to the full extent without pausing which wouldn't be the case with free look.


Spoiler:

Interguild discord!! People use it!!

« Forum Index < Platformers Board

In order to post in the forums, you must be logged into your account.
Click here to login.

© 2024 The Interguild | About & Links | Contact: livio@interguild.org
All games copyrighted to their respective owners.