keyP

Ah interesting, not come across that term for game design, thanks!

It would be interesting to see if that was a game design decision to allow for the game to be more dramatic.

There's something called "Coyote Time" which is named after Wile E. Coyote and him staying in the air for a few seconds before gravity takes effect. Often in platformers, there's an invisible collision box added after cliffs so that if the user was slightly late pressing jump at the edge of the cliff, they would still make it as the invisible collision box would provide an extra step. It's an example of improving gameplay and game feel without being realistic.

Merry Christmas HN!

It can be a large topic dependent of the type of game, whether physics and such is involved etc... but I bookmarked this article from before which gave a good overview

part 1: https://medium.com/@qingweilim/how-do-multiplayer-games-sync...

part 2: https://medium.com/@qingweilim/how-do-multiplayer-game-sync-...

Indeed you can, but the idea is that a raycast is still needed. I should've been more specific in that it doesn't mean the projectile system can't do it but the idea of raycasting allows for that additional advantage cheaply and easily.

I'm working on the bullet system for a game right now and another advantage of hitscan I think, that wasn't explicitly mentioned in the article, is that you can get objects behind objects to then determine if the first object should absorb some of the bullet damage. For example, an enemy behind a wall may still damage but not as much as if the shots were fired directly at the player.

When you send out the raycast and get a list of all objects hit, you can iterate over the objects hit and reduce damage value until the first enemy object is hit (pending any distance restrictions).

I think you misinterpreted what was written.

> "A lot of “casual” games end up using the hitscan method as it simplifies the learning curve for most beginner players. But what about games that aim to create an “immersive and realistic” shooting experience? They cannot achieve their goals within these constraints. We need to use an alternative method."

It's not saying casual games are the only games to use hitscan but it's usually easier and quicker to implement hitscans than projectiles (and more intuitive for casual gamers).

Half Life and Halo both use the hybrid system depending on the weapon, as written in the article.

Are there any technical details about attack?

I like it, nice clean look. I cloned and installed from source (Firefox) and works fine, haven't tested installing from the store but I imagine it's the same.

Small typo in the readme under the Firefox instructions. It says go to the "about:debugging" section and click "This is Firefox" but it should be "This Firefox" (no 'is').

It has 126,603 subscribers at the moment, I'm not sure how many of those you've interacted with but I've never really had any issues. Then again, like I say, I don't visit often so not much I can add to this post.

Happy to be corrected but not sure what Microsoft has to do with the subreddit, I assumed it was run by non-MS related developers.

Either way, I rarely visit that subreddit, not sure why people opt to post programming questions there instead of Stackoverflow.

Small tip, the url isn't masked and shows it's a WIX site. This doesn't mean it's inherently bad but it seems less professional for a site that accepts payment so you may want to mask the domain to show "fortyq.com".

The GitHub Actions Runner has just been open sourced https://github.com/actions/runner

I mainly use it as the vertical scrollbar when coding. However, I do find it useful if I'm going through log files or files that have blocks of "shapes" formed by the text. It makes it easier to scroll down to the relevant section.

I've not had any particular reason to specifically use this but I found Robin Hood Hashing to be quite an interesting concept. It improves performance by essentially reducing the distance from the key to its matching key-value pair.

Advantages listed from [3]:

- The number and variance of look-ups are reduced

- Searches can be ended early, since 'hits' are found much quicker

- The flat array structure eliminates need for linked lists or pointers: reduces misses and overhead

- Even finding non-existent elements is fast

- This method approaches O(1), meaning the most efficient search

[1]Part 1: https://www.sebastiansylvan.com/post/robin-hood-hashing-shou...

[2]Part 2 (slight update based on suggestions in part 1's comment): https://www.sebastiansylvan.com/post/more-on-robin-hood-hash...

[3]https://study.com/academy/lesson/robin-hood-hashing-concepts...

According to the paper cited in this article, they may not be as dumb as you think

https://www.psychologytoday.com/gb/blog/animal-emotions/2017...

If you're in a startup with shares, I guess it indirectly does.

Either way, having engineers focus on more stimulating projects has its own intrisic value for the engineers themselves. Additionally, it reduces the likelihood of burnout because whether the business needs to know how much is automated is up the manager, as long as the team is delivering the agreed tasks by the deadline, the business doesn't necessarily need to know that the team had some slack. It's these slack moments testing, refactoring, and experimenting can happen - things often downplayed by business until stuff hits the fan.

> "lazy" developers aren't generally lazy, just bored

Well said, this has been my experience as well and so I also encourage automation as much as possible. I guess it depends on the business and tasks to do but there's generally no shortage of work in the backlog and if work can be automated, more resources can be spent on adding tests and new features.

If the tasks are straightforward, I often find it helpful for new starters to take on some of the automation projects. It allows them to get to grips with the pipeline a bit more and gets them to ask questions to other developers to clarify things, all whilst providing immediate value.

> I had someone tell me that programming isn't real work before

Haha, I don't even understand what metrics the person was using to consider something "work". A pilot sits throughout the flight but I think it's fair to say their working...

I wouldn't say it's hate towards JS but I think the evolution of JS vs the evolution of web and its use cases have not increased at the same velocity, latter being faster. JS has had to have a lot of scaffolding added to increase its use but WASM now comes in with the understanding of the modern requirements. However, I don't think it's either one or the other, it'll depend on the use-case.

I can't imagine JS will go anywhere anytime soon, especially since it still needs to be called from DOM manipulation,but the ability to code a full stack in a single non-JS language and run it at near-native performance is going to be very useful as more apps become web based and complex. Even from a skills point of view, you can now have backend and front-end developers skillsets are slightly more merged so easier to swap around resources.

I'm travelling at the moment so please bear with me with the timings but email me at thekeyboardp "at" gmail "." com and please lets talk mate

This was my experience too, and after speaking with recruiter friends, often the company doesn't know where this person would sit. The title is still quite new and whilst the job spec may imply technical, the reality often is that they still just want a full on Product person who happens to know some coding (as opposed to a full on coder who happens to be involved in product). I've generally just had to go in as an engineer and be promoted by showing them what TPM's value is first hand.

I've had this happen to me and seen it happen as a third party. It's a cultural issue and whilst I can see that difficult to change in large companies, startups with this mentality often demoralise developers quickly IME.

This is often how waterfall projects are/were run in large companies historically but now companies want agile everywhere but they don't implement the right processes to facilitate it. You end up with behind closed door decisions, promises made by PO that it will be done in the next sprint, and at no point has anyone with either the courage or technical know-how stepped in to point out that it's not feasible.

Agreed, same experience for me as an engineer and it's often the engineers who get the blame as their output is the most tangible in that chain of command.

I believe this is why some of the best Product Owners I've worked with have some understanding of the technical side so that they can push back at the point of feature request rather than accept everything to please business/the client and lay it at the feet of engineers a few weeks down the line.

For this reason, I think the engineering manager/technical product owner type of role should start becoming a bit more common especially in startups, where I've seen first hand, POs brought in who subsequently drive products into the ground that were initially engineering led (and which raised the investment in the first place).

> Conversely, when such feedback and communication is overlooked or ignored, over and over, engineers often stop giving it even when they are interested.

This is true but I find if I can explain why the feedback was overlooked, that can help diminish the negative feeling. It hasn't happened often in my experience but sometimes when it has, if the idea is feasible and won't detract too much from the critical path, I would push the business team a bit harder to allow it so as to avoid the constant ignoring feeling that can happen.

Thank you, I like to think so. A lot of how I manage my teams come from my experience as an engineer and seeing all the approaches that demoralised my friends and colleagues.

A lot of it isn't a complex secret, it's really doing what you pointed out - make people feel appreciated, listened to, and actually part of the company as a whole as opposed to just a resource. This can be as simple as being more transparent as to why a feature has been requested, even if it's counter-intuitive to reason, or giving context as to where the roadmap is heading so that they're aware on why they're working on something.

I've met Gergely, the author, a couple of times a while back and he's a great guy and I think we work in a similar way. In the majority of my roles I was initially hired as an engineer but then moved to engineering management and the points highlighted in the article are very familiar.

I often found that features would be requested from product owners/business and developers would implement it no questions asked but at lunch time, developers would rant about the requested feature's value. When asked if it should be brought to the PO's attention, I often saw the attitude of it not being their problem, they're getting paid either way (whether that's a company culture issue, general developer apathy, or burnt by past experience of questioning management is a different question). I think product-engineers feel a bit more invested in the product and have the soft-skills to influence or provide feedback in a manner conducive to business listening.

In my teams, I try to foster this type of communication and I've noticed a lot more developers opening up and providing valuable product-orientated feedback which often has an upward positive spiral of them feeling more appreciated and speaking more. Naturally a lot of engineers still want to just code and go home but team culture can really highlight and encourage engineers who may not be confident to speak up initially.

Ironically, as someone with more engineering experience on paper, it's been tricky to find a job directly as any form of product or engineer manager, I always had to go in as an engineer then be promoted after a year or so which isn't always ideal (or referred via a friend). I feel Product and Technical skills are still often considered mutually exclusive a lot of the time but I think that's inertia from when technical skills were still considered a cost to the business.

I agree, it's no where near bulletproof, but it's about raising barriers as well as updating the tool once workarounds are found. I don't see an easy solution to this issue but in most of the cases (including the ones in this article) I've seen to date, a simple URL scan would've caught them let alone more complex methods.

Highly obfuscated code would raise suspicions, especially in similar cases found in NPM packages.

E.g. in Python, obfuscators I've come across tend to replace characters with non-Latin unicode chars, which should raise flags when found in a predominatenly latin based source code.

One thing I've always thought would be a good idea is a tool (either local or part of the pip/other packet manager download process) that greps and prints out all URLs and IP addresses within the code, including common encodings. Additionally, any lines that uses any transfer protocols (like HTTP requests) should be highlighted too as IP/urls can be encoded. Any HTTP request, for example, to suspiciously encoded URLs could raise flags.

The official library itself could have a "urls" file which has a list of urls that are expected and so anything that doesn't match can be questioned.

Whilst this won't solve the issue 100%, it raises the difficulty barrier to implement outgoing network calls.