PhilippTheProgrammer

I am making a game where the user can click on various entities to select them.

I am using the MeshPicking plugin for that with the MeshPickingSettings { require_markers: true, ray_cast_visibility: RayCastVisibility::VisibleInView }, by assigning a Pickable component to any entity that can be selected and setting an event handler via .observe with a function like fn set_selected_entity(evt: On<Pointer<Press>>) { ...

Now I would like to implement the ability to unselect the currently selected entity by clicking into empty space where no entity can be found.

How can I detect that the player made click that was *not* observed by any `Pickable` entity?

One workaround I consid

So if you are considering to register a trademark for your game or your company in the EU or an EU member state, now would be a good time.

More Information

Application Portal

I assume you should all be familiar with the boxleiter method to estimate how many sales a game has on Steam. You simply take the number of reviews and multiply it by 35 (yes, different people come to different boxleiter numbers, depending on what games they consider from what timeframe). While this doesn't give you an exact number, it gives you one that should at least be in the correct ballpark.

But is this method accurate for DLC as well? I would assume that the psychology for reviewing DLC is different from that of reviewing the base game. Does DLC have a different sales/review factor? Or is the meth

I have a system that:

• currently runs on the Update schedule
• processes a very large amount of entities
• takes enough time to compute that it is a major performance hook
• doesn't actually need to run every Update for every entity. It's probably OK if it runs only about every 100 updates per entity, as long as it knows how much time elapsed since the last update for that entity.

Now I could of course run the system on a timer that only updates it once per second, but then I end up with a lag-spike once per second.

What I would like to do is run it every Update, but have each update only process 1% of the entities. Then the next update processes the next 1% and so on. The system of cou

Source: [pricing update FAQ](https://unity.com/pricing-updates):
* Changes only apply if you build your game on a future version of Unity ("LTS versions shipping in 2024 and beyond"). So if you use the currently available versions, the old license conditions apply.
* The runtime fee is no longer based on "installs" but on "initial engagements" per user, which in practice means per-download for free-to-play games or per-sale for pay-to-play games.
* Repeated installs by the same user and pirated copies will **not** count as engagements, but buying the game on two different stores does. Someone playing a WebGL build on a website **does** count as an engagement (Which is actu

I have been playing GI on and off again over the past couple years. I took a long break and now I am considering to give the game another try. However, there is one thing that tells me not to. And that is, ironically, the feature that is supposed to cause me to return to the game.

The thing is, I know from the last couple times I took a break from the game, that the next time I log in again, I will get the Stellar Reunion Returnee Event. I am going to receive some really nice daily login rewards and rewards for ticking a couple boxes of utilizing game features over the next couple days.

The problem is, though, I am not sure if I am willing to commit to playing the game that much over the n

The game design YouTube channel Extra Credits really dropped in relevance over the past few years, but they still create a good video once in a while. Now they created a followup to their fail faster video from 2014:

Fail Faster 2: Fail Better - Iteration & Feedback

The video is about the importance of admitting to yourself and your team when your game design ideas don't work and how to stay in the right mindset to be able to change your plans instead of clinging to failed ideas out of pride.

tl;dr: A space management game with multiple sectors. Should each sector be a separate ECS World, or should I explore other options?

I am currently prototyping a space management game.

The game universe is supposed to consist of many isolated "sectors", each one populated by space ships, stations, planets and other space stuff moving around in them and going about their business. Sectors are connected with each other through "jump gates", which allow ships to travel from one sector to another. There should not be a way to just fly from one sector to another directly (as they are supposed to be light-years apart).

Most interactions between objects should only happen with objects in