# Question
Title: How to prevent the "Too awesome to use" syndrome?
When you give the player a rare but powerful item which can only be used once but is never really *required* to proceed, most players will not use it at all, because they are waiting for the perfect moment. But even when this moment comes, they will still be reluctant to use it, because there might be an even better moment later. So they keep hoarding it for a moment which will never come.

In the end, they will carry the item around until it is outclassed by other, more readily available resources, or even until the very end of the game. That means that such one-shot items don't provide any gameplay-value at all. They are simply too awesome to use.

What can you do to encourage the player to make use of their one-shot items and not hoard them?

# Answer
> 15 votes
Thank you all for your answers. There are some great ideas between them. I decided that instead of accepting one of them, I decided to collect all ideas from the posts above, summarize them in one answer, and accept this answer as reference for future readers.

Reasons why players hoard:

* They develop a habit to solve certain situations using certain tools. When they have a tool which can only be used once, they will never develop a habit for using it. As a result they forget that they actually have this tool.
* They don't know what the item is actually doing, so they aren't aware when they are in a situation where it could be useful.
* They don't want to do a mistake and prevent further progress by using an item too early.

How to prevent it as a game designer:

* Give the player a hint when in a situation where a certain one-shot item would be useful
* Make it possible to re-obtain the items after use.
* Give the player so many one-shot items, that each individual one doesn't seem that valuable and irreplaceable.
* Add severe consequences to dying (more than having to reload the last savegame), so that the player will use one-shot items when desperate.
* Don't make them single-use. Add a long cooldown to items instead or allow them to be recharged with another resource, so that the player can use them multiple times.
* Make it impossible to hoard them. When the player is aware that they will lose the item anyway, they will use it sooner. This could be done by adding a time-limit, removing them after completing the level or severely limiting the number of items which can be carried at a time.
* Punish the player for hoarding too many one-shot items, so that they will be motivated to get rid of them soon.

# Answer
> 172 votes
You could try to use arbitrary hacks like level/time limits. This however won't actually make people use them; it just means that they'll throw them away when they hit the level/time cap. It's also terribly arbitrary and artificial.

You could try to just tell the player "Hey, remember that thing I gave you? Have a go with it now!" But that's horribly inelegant even if you can manage to do it in character and story appropriate dialog (and if you don't forget to check to see if they already used it).

You could simply make later encounters so difficult that they effectively *can't* proceed unless they start burning through their rare one-shots. But then, if they used them all up earlier, they're boned. And that's all *your fault* as the game designer for not telling them that they weren't supposed to use them yet.

The fact is this: people are creatures of habit. Rare, one-shot items, by their very nature, *cannot* be habitually used. So people will not be in the habit of using them; they will be in the habit of *saving* them.

So you should look at your game design and ask yourself a question: what *good* does it do to have rare, one-shot items in the game at all? What game design purpose do they serve?

Resource management isn't really served by such items, since they are so few in number that people can't really manage their use. Take a typical RPG level, a dungeon of some sort. You buy one-shot items at the store beforehand to stock up. And you hope that you have enough to last you through the level. You have to manage your limited resources, knowing that you can't just easily get more without backtracking.

Rare one-shots don't help with that. You can't buy them, so they aren't part of money management. They're too rare to get in the habit of using. And they're rare enough that using one is a *major* investment.

Whatever purpose you intend for rare, one-shot items to have, I imagine that there's a better way to achieve that purpose with a different item.

For example, let's say you want the player to have access to some huge effect powers. Area damage, heal-all, whatever. But you don't want them to be able to buy large stocks of it, as it would make the game too easy.

Make a *rechargeable* item. A staff of greater damage dealing or whatever that has only two charges, but you can recharge them in town (for a fee of course). Then, they will be encouraged to actually use them, since they know that they can at least recover the charges later. Thus they get into the habit of using it; it becomes a part of the game for the player.

You can even upgrade the item later, with greater charge capacity. It also makes it less likely that they used them all up on unimportant stuff, since they can recharge them at designated locations.

Also, if the item is rechargeable and therefore reuseable, the player has the chance to *practice* with the power. Which means that you can now make the ability something more than the typical boring "do lots of AoE damage" or "heal lots of life on all characters" or whatever. You can make the way in which the player uses it affect how effective it is. Obviously that depends very much on the nature of your gameplay. But the main point is that, if the player can practice with it, then they can build skill at using it. So you can make it a skillful ability.

# Answer
> 50 votes
Like Byte56 suggested, limiting how many of a given type of one-shot items a player can carry pushes players towards using them. Another possible push is to make the game so difficult without one-shots that players are practically forced to use them. This of course also means that you have to make them reasonably available and provide some means for the player to acquire more if they run out at a critical point, this could be by letting them run from the fight to go back and buy or farm for more, or by dropping such items for pick up during battles, so that all the player has to do is dodge until enough items have been dropped.

Think of ammo in shooters or health potions in RPGs, both are pretty much mandatory to use, but they don't cause any problems because they are supplied in surplus. Though they are perhaps not as exciting as a rare one shot item.

A different take on the matter is to provide non-consumed items with long cooldowns instead, like 15 minutes. Effectively that is maximum once per battle, and only for use in some battles if the player want to go at a reasonable pace. But the player always know that if the effect is really badly needed in some later battle they can just wait for the cooldown before entering the fight.

# Answer
> 49 votes
Add downsides for holding on to the item. There are many ways to do this:

* **Small Inventory Size**: hanging on to the item without ever using it costs one precious inventory slot. Players that use the item quickly will be able to bring back more loot, spend less time agonizing about what to drop, etc.
* **Burden Penalties**: hanging on to the item 'burdens' the player character. Players that use the item quickly will have have more stamina/faster movement/quicker recovery/lower taxes/whatever.
* **Opportunity Cost**: hanging on to the item forces you to do things the hard way. Players that use the item appropriately, instead of holding on to it, don't have to waste other precious resources (like money, or the precious resource of not dying). Even more effective if costs accrue interest, with early costs being harder to recover from.
* **Decay**: hanging on to the item decreases its eventual effectiveness. Technically this already happens, since early items tend to be weak later on, but making the item explicitly get weaker adds a concrete incentive to use it quickly.
* **Accumulating Risk**: hanging on to the item risks events with low, but constant over time, probability. Maybe potions are slightly unstable and blow up now and then, maybe enemies can attempt to steal the item and then use it against you, maybe you get targeted specifically by thieves because you have such a cool item, etc.

# Answer
> 22 votes
If you, as a game designer, know when the opportune moment arises (eg. boss battle), I would give a cue to the player. This could be a character saying "Sure could use that BFG right about now", or even a tool-tip reminding you that the weapon is awesome. Sometimes, players will just forget that the weapon is there, so a little reminder at the right time can help.

# Answer
> 18 votes
Short Answer:

Have something more valuable than the item that the player can lose if they hesitate to use the item. EG You might use your single-use invincibility potion to save you from death in a game where death is permanent.

Long Answer:

I think the only games in which such an item can work are ones where there is some form of persistent punishment for failure: Things like permadeath, loss of money/exp/stats on death, limited lives before having to restart the game (that's pretty outdated, but whatever). So when the player gets stuck or comes up against a challenge that they are likely to fail, they have an incentive to skip part or all of this challenge using the super item.

You could look at a lot of old arcade shooters, where you where often given about 3 bombs to use per life and could not recover any more. Bombs where valuable, but not as valuable as lives. Players would never use them unless it was necessary, but they wouldn't hesitate if they thought it would prevent them from dying. The same principle can be applied to single-use items, as long as there is something more valuable that the use of such an item can protect.

In a lot of games, failure is not really penalized and therefore there is no reason to use rare resources. There is no reason to use limited resources to prevent the loss of a life when you have infinite lives. I suppose you could add a particular encounter to the game that forces the items use (like the Master Ball in pokemon), but that can fall into **guide dang it** territory.

Making the game more difficult is not a solution, as players will not have the item for the vast majority of their playtime. "If *this* is hard now, I should save the super-weapon for when it's even worse!"

EDIT: As zzzzBov points out below, you could also make the item itself disappear upon death. Which would certainly make players more likely to use it.

# Answer
> 16 votes
I think looking at it from the "this item is too powerful" point of view is missing the point a bit. In my view, it's more about hoarding items because they're *limited*. A good example of this problem happening is in a game like Skyrim where you can make potions. Sure, 5% fire resist for 5 seconds isn't terribly powerful by almost anybody's standards, but it still accumulated to the point where I didn't want to get rid of them because 1) they were a limited amount and 2) I couldn't predict the future.

So that being said, I would look at the problem as a way to mitigate hoarding behavior.

One of the most successful approaches I've seen is to take the items away from the player at known intervals. For example, make it so you get consumables inside dungeons, but once you leave the dungeon the consumables go away. That way, the item can't be hoarded because it isn't permanent. Since you don't have persistent consumable inventory beyond the dungeon, the user doesn't feel that the item has as much value.

Alternatively, you could also do things like dramatically limit the number of single use items the player can carry. The logic being that if you don't use the items you're leaving a bunch of consumables behind. It isn't as good an approach as forcing the items out of the user's inventory, but it might also encourage the user to churn through their items.

# Answer
> 10 votes
When creating any item for your game (rare-single-use-only or not), you need to think carefully about what that item is really for -- why is it in the game? What purpose does it serve, and how does its presence make the game better? If you can't answer those questions, **it probably shouldn't be in your game**.

In this case, rare portable single-use-only items are usually placed into games as a safety valve against mistakes in the game design. That is, we balance the game as best we can, but if a user finds a particular single challenge which is just too much for them, they can use the item to avoid becoming stuck and continue to progress in the game. This works in exactly the same way and for the same reason that puzzle games will often include a "skip up to 'n' levels" feature.

If players don't use this sort of rare one-use-only item, that's *not a bad thing that needs to be fixed*; it means that your game wasn't so difficult that they had to use the thing to become non-stuck.

# Answer
> 7 votes
If the item is too awesome to be used, then the difficulty of the game is too low.

Alternatively, the player might be insecure about using the item because he doesn't precisely know the benefit of doing so.

# Answer
> 7 votes
I think a good example of a well-implemented version of this type of item is the Master Ball from the original Pokemon games. For those that are not familiar, allow me to give a quick summary...

The Masterball was a one-time-use super item that could capture a Pokemon 100% of the time, no matter how much health it had left. You only came across one in the entire game. Other types of balls had a capture rate well below that of the Masterball and usually only worked on a weakened Pokemon.

Sure, some users may have saved the item and never used it, but most users that I know used it on one of 4 extremely hard to catch Pokemon (Mewtwo, Zapdos, Aritcuno, or Moltres). That's not to say nobody saved it forever... but overall, I think this item had a pretty good balance.

That said... here are some options/suggestions for creating your own super item.

## Don't make the super item too powerful

Even super items need to have limitations. Have you ever played an RPG where you could kill the final boss by simply using an all-powerful item, avoiding the fight completely? I personally have not. A super item should not be so powerful that it takes away a user's sense of accomplishment.

## Make the super item have drawbacks

Remember the Warp Whistle from Super Mario 3? It allowed you to skip past vast sections of the game. The benefit? You got to finish the game faster/more easily. The drawback? You missed out on some fun levels! To bring this idea to modern gaming... perhaps certain game endings/storylines can only be encountered by beating a certain boss the old-fashioned way, instead of using the super item. (Note: this sort of contributes to the too-awesome-to-use problem as opposed to relieving it, but I thought it was worth including anyway)

## Only allow the super item to be used in dire situations

Perhaps a super item only becomes available when the user's character is below 15% health. At this point, the user would likely be willing to try anything to avoid losing! An example of this is super moves in various fighting games (such as the Fatal Fury series) that can only be used when a character is very weak.

## Use storytelling to guide the user as to when to best use the super item

While this example is a bit of a stretch... FPS games come to mind. Say a user finds a rocket launcher, which is obviously overkill for a single armed guard. However, suddenly there is a cutscene with a massive, chain-gun shooting, rocket-launching helicopter flying around wreaking havoc! Most players will instinctively pull out the rocket launcher instead of trying to beat the helicopter with a normal gun. Let's say they already wasted the rocket... perhaps you could require them to sneak around the helicopter instead of shoot it out of the sky?

Anyway, just a few ideas.

# Answer
> 7 votes
I have funny idea about your problem, maybe include some description with funny story from which you can tell that if the item is destroyed it will be randomly placed on the map again. So basically player can find this item only if he does not own one :) Also achievement with "super legandary item holder" and "super legendary item user" would help, the achievements are really great to make players do what you want (I am talking from the players perspective).

# Answer
> 7 votes
Chain the item to the location where it's to be used. If you can't take it with you, better use it where it's located.

This is actually quite common. Many shooters for instance have fixed gun emplacements. Powerful in the area they're located, but you cannot put them in your inventory.

# Answer
> 6 votes
1. Make the item not so rare and add it some cap. Let the player know that the it will be helpful at some points and there will be more ahead, if the player won't use it he is gonna waste it after the cap is reached, like heavy weapon ammo in ME2.
2. Make the item auto-use. In Metal Slug more effective weapons replaces the current weapon until it run dry of ammo, then you return to the usual, boring, infinite ammo, gun. This could apply to healing, invencibility, damage buffs, etc.
3. Make it needed. In a setting where healing is hard to come by, an item that fully heals the player is awesome and **will** see use. If you give the player awesome bombs with splash damage, make sure that there is cluster of enemies to tempt the player to try and explode them all at once.

# Answer
> 6 votes
A simple solution would be to make this special item available in-game for a limited time.

For instance in 2012 Jagex (creator of Runescape) added a special item called the "DeathTouched dart" it could kill any opponent with just one hit. It has been said that it will be removed on some unspecified date.

> http://runescape.wikia.com/wiki/Deathtouched\_dart

That way, most players used their darts and their purpose has been fulfilled.

Another example from my game experience comes from an old game called "Star Wars Jedi Outcast Academy II", I remember that I aquired some rare items like Seeker drone, which were supposed to help you fight your enemies. Due to their rarity I have kept them until the end of the game, hoping they can help me fight the final boss, but to my dissapointment it hasn't even left a scratch on him. In that case I would simply make them more common.

# Answer
> 6 votes
If you really want people to use the item and it's super-rare, consider making it come in a three-pack: one to waste on a test, one to use, and one to hoard. Or a two-pack, if people can reload easily to get back one used to test.

If you want to make sure they don't all get used at the same time, you can then give it a cooldown.

# Answer
> 6 votes
Players should use an item when either (1) they can replace the item for a cost which is lower than the cost averted by using it, or (2) the cost of not having the item available later will be greater than the cost of using it immediately. I don't like it when games punish the player for conserving resources in any fashion beyond the fact that players naturally don't benefit from things they don't use. I also dislike it when games arbitrarily confiscate conserved items. Instead of doing such things, games should try to convey to the player the idea that if an item will be needed, it will be possible to replace it, though perhaps at the cost of having to do some otherwise-unnecessary side missions. If the player can, given time, earn an unbounded amount of in-game currency, an item might be sold in the "arcana" section of a shop where e.g. the first MagicWhatzit costs $1,000; the second costs $1,200; the third, $1,500, etc. rising at a rate which is noticeable but not overly frightening. Such rules could encourage reasonable conservation without encouraging excessive hoarding, since players could have a sense that if they can avoid using a MagicWhatzit, they can avoid having to run a 10-minute side mission to get another one, but if running a ten-minute side mission would be easier than getting by without a MagicWhatzit, then they should use it.

This ties in with an economic principle, which has real-world consequences as well: if one wants people to perceive a resource as having a significant but not limitless cost, they must actually pay the cost if they use the resource. If squandering a resource will mean that a players has to spend some of their real-world time running a not-terribly-exciting side mission to get it back, players will have an incentive not to squander it. If the game were to let the player skip the busy-work, that incentive would vanish. While it may seem that an ideal game should avoid giving the player busy-work, such busy-work may encouraging sensible resource management in a way that can improve a player's overall enjoyment and satisfaction.

# Answer
> 4 votes
I like the ideas of Rechargeable item and item with a Cooldown, but, as Nicol Bolas said, that doesn't make people use them. In fact, to disagree a bit with him, as I'm more inclined to hoard a rechargeable item than one with a cooldown.

The Cooldown is tricky too. If it's too short, maybe the attack shouldn't be too powerful or it will ruin the game's balance. If it's too long, players may save it for the "really tricky and hard boss" that may never come. Are the players aware of the coming challenges? Can they see the enemy before engaging them? See MOBAs (DOTA, LoL, etc). A character's ultimate attack is the big powerful attack, that has the biggest cooldown. A player may or may not engage an enemy depending on whether the ultimate attack is recharged or not.

My take on the matter is a bit more "gimmicky". What about an item with a cooldown that "levels up" the more it's used. It starts weak, or with only one effect, and with use it gets better. With some time invested by the player it may become a really powerful item and a viable strategy. It also plays with the players curiosity, making him want to discover the new abilities.

# Answer
> 4 votes
Excellent question. I don't think I've ever used an elixir in a Final Fantasy game, which is a perfect example of your point.

The real issue is that most games are really easy. Random battles are never hard enough that you have to use an item mid-battle, and bosses aren't much harder. The standard method is to attack until you win, then heal after the battle is over. Getting low on HP isn't uncommon, but getting low on MP is. Most games are more about grinding than strategy.

If you want users to use their good items, you can use a combination of techniques such as these:

* Make magic less powerful
* Make MP drain a common attack
* Make magic important, but limit it's use to a few characters
* Use attacks that severely damage multiple characters at once
* Have optional, hard bosses

The problem is that after the first hour or two of most games, magic is effective enough that you never have to use items again. If you make heal spells less powerful than items then it will force players to use more of their good stuff in battle. Make the good heal spells really expensive, and the cheap ones less effective than items.

Give enemies attacks that devastate multiple party members at the same time. In order to heal everyone quickly enough to avoid being killed, items will be necessary. This is especially true if most the characters don't have healing spells. If the attack also drains MP, then players are more likely to use their best items rather than waste multiple turns restoring both HP and MP.

Another way is to put really hard, optional bosses deep into a dungeon, where it's not possible to go back to later. Put the boss next to a save point, and make the battle hard enough that they'll lose a few times. In this case it's clear to the player that this is one of those moments that they've been saving their best stuff for. After losing two times already, they'll use their elixir rather than risk dying again.

# Answer
> 4 votes
I like the Path of Exile model where rare one shot items double as a form of currency. The added utility means that if you don't want to use the one shot item yourself, you could always trade it for a permanent item of equal (subjective) value.

Furthermore, I think it's important for games like these to gradually progress in difficulty to a point that is essentially unbeatable. When you get near the limit of your character, there will be a real need to use every last rare one shot item to get every last statistical boost you can. In exchange for using your rare items you have the chance to progress further in the game than most people have and join an "elite" group. That could be accomplished by being a higher level, having flashy visual effects, or even just a leaderboard.

# Answer
> 3 votes
Tell the player in advance when they are going to get a refill. Maybe the first or second time they will assume there is a boss battle between now and then, but after that they should get the hint.

Alternatively, make using the weapon so fun that they don't WANT to save it.

# Answer
> 3 votes
This shouldn't really be a problem if the game is enjoyable enough that the player wishes to play again.

They *will* use it the second time.

I draw this from my own recent experience playing *Lord of the Rings: The Third Age*, not having played any rpgs since Final Fantasy III (or 5, it was a translated rom on MAME) over ten years earlier. The first time through, I used no items except healing potions (and only until the magical healing could be employed). Second time, I had a sense of how many items one could hold, how often they appear, and context for where they would be useful.

They're just exploring a smaller *sub-* universe first.

---

On the other hand, you *could* try making the first super-item *necessary* to pass some challenge (or enemy) very early in the game (just once), and then leave the rest optional. This should encourage the player to keep a lookout for where the super-items are useful. Of course making it necessary makes it integral to the whole game and may affect many other decisions (player *must* acquire the item or have the ability (clue) to go back and get (find) it).

*Or*, have them rare but not solitary and have a maximum that can be held (like 1). If the player can only hold one, but finds more that can't be picked-up, that should encourage their use.

*Or* have NPCs advise them to make use of the item. *Shopkeeper: I see you have the magic acorn of instant death; when you face the great monster in the wood, use that on him, but only after he gets splashed with water.*

# Answer
> 3 votes
There are many potential answers, but really you need to ask why it bothers you if a player decides that they want to store this item for a later date. When players invest time and energy into a game, they do not want to feel in some way forced to use an item at a certain time and this is why there was a big backlash against Quick Time Events (QTEs).

Whilst you will always get some users hold onto that rare super item, you will get others who use it first chance they get regardless. It is some happy medium between these two extremes that I believe you are looking to promote and that will not be achieved by either punishing a user for not using the item, or by rewarding them to such a degree that early use unbalances your game.

The most effective answer is to make it so the item is not so rare that the player will never see it again if they do use it. If it is also clear the item will not provide any real benefit in endgame boss battles then that deals with the tendency to hold onto things just for the big bang at the end.

I believe the real answer falls to careful selection of the properties of the item, the benefits it will provide and what limitations get placed on those benefits. this will get you to the happy middle ground where most players use the item before endgame, whilst you will always have some that never use it and some that use it the second they get it.

# Answer
> 3 votes
**Quake 2** solved it quite well with the quad damage powerup.

* you can carry only one at a time.
* you can activate it any time you want, and it will quadruple the damage you deal for the next 30 seconds. It's the most powerful and useful item in the game, you can easily defeat even the toughest bosses, but it's also useful for huge hordes of powerful enemies.
* it is rare, but can be found several times in the game.

This means that hoarders will sooner or later find another one they can't pick up. If that new one is close to the beginning of the level (and it usually is), and they can't pick it up, then they know that they can use their own somewhere in the level and then they can backtrack and pick up the other one if needed.

This made me actually use it in tougher fights, and knowing myself, I might not have used it at all, maybe except for the final boss, if I could have carried more than one of them.

# Answer
> 2 votes
I have no professional knowledge in this field. A simple programmer, but an ex professional Gamer for Consoles.

The trick here is to make these too awesome to use items, Multi use items. The player will immediately feel the urge to use one, but never feel terribly scared to lose them all. It gives you the understanding of what i does early. I play a little different than others, because I need to know the aspects of the items I collect.

The biggest example I have would be the Divine Blessing currently in Dark Souls. You have the opportunity to get 2-3 per entire play through. It's fantastic for quick healing, reducing bleed up, poison, curse...all trivial for in game, but it's full heal in less than 7 frames makes it incredible for pvp (even though healing is frowned upon...trivial comment) and for hard boss fights.

I received 1, and used it immediately not knowing what it did. Never received another one. boom.

Give 3 uses, and you won't need to truly worry about them saving it forever. They will understand what it does, and when they want to use them.

Now if this item is purely unbalanced. I simply say, don't do it. No player enjoys an unbalanced/unchecked weapon...in any game.

Can you imagine having a golden gun through all of 007? How did you feel about CS AWP users? Majora's Mask had the Fierce Diety Mask...but it was checked to 1 fight, and a ton of effort to get.

Normally it's a good idea to avoid "too awesome to use" items...A few approaches successful games took...

Call of Duty approach- You get this gun in these situations on these gametypes. Use them while you can because they aren't permanent. I just used all my ray gun, but i'm alive. an there is a chance I could get it again.

Borderlands approach - Give them a rarity weight and make the power within 1 standard deviation of the mean of the draws of the level you're at. If you get one, you won a digital lottery.

Dark Souls Approach - If its badass, you still have to have the stats for it. Make them earn the right to use it. THIS SWORD IS AMAZING...but need STRENGTH...50? 0.0

Halo Approach - Limit the uses, balance by making the power is available only with skill (sniper rifle has a faster turn speed unscoped), and allow it to be regained.

Platform Approach - Limited TimeFrame, instant Activation.

Fighter Character Unlock Approach - Different Attack Sets, Weakness to Certain attack types (special, quick, strong, ect)

So far balancing is really key here for weaponry. If it's a weapon, you probably shouldn't OP it. Otherwise the community will wreck the name of your game, Mortal Kombat's no weakness Kabal shot it's followings lifespan in half.

Truly, depends on the situation but if you really want to get someone addicted and invested in the game. You can follow even the blackhole of success's right now "Rage Of Bahamut"...don't play it. but you can study it.

They use old Psychology standard. The more effort you put in the better stuff you get...sometimes. Don't reward them for every little thing, but in non determinant intervals reward them. They'll play more and more, knowing there is a chance. I'ts still up to you on how you want to implement it.

# Answer
> 2 votes
The most common reason for hoarding it is that the user doesn't know what is the best time to use it. so, one simple way is to name it in such a way to make it obvious where its best use lies. The more generically powerful an item is, more the likelihood that the user will hoard it as he cannot zero in on its optimal use.

# Answer
> 2 votes
**Make other items more expensive to acquire if they have an awesome item.**

Shop owners may notice this item on a character and assume they have access to great riches, and since they have so much money the merchant can overcharge a bit.

# Answer
> 1 votes
Another solution to the problem would be a one time pass/fail event that doesn't affect the storyline, but could cause benefits.

For example, a town that has some unfinished research that could benefit you, which is under attack and if lost, game would continue, but you wouldn't get the tech that it would've given.

Of course, it would have to be pretty much a no win scenario w/o the use of the 'too awesome to use' item in order to force the use of the item. (similar to Luser Droog's, but I think avoids the 'necessary' drawback.

# Answer
> 1 votes
why have such items in the first place? Rethink your system to where you don't have to choose between things that last forever and things that can be used only once.
Have things wear down over time, at which point they either have to be repaired or replaced. More powerful items can be made to wear down faster, and/or be more expensive to repair and create (if you have a crafting system).
Ryzom did this very well, having a highly involved crafting system where the best items in the game would require rare resources that could only be harvested at specific times in seriously high risk locations, often requiring teams of people just to protect the harvesters against the local mobs.
It could take weeks to gather the resources to craft one of the best weapons or armour pieces in the game (over time of course people started hoarding the raw materials, some guilds even going so far as to harvest things they didn't need in order to deny them to others).
Combined with storage options that allow enough inventory to keep items for special occasions, this created both a lively trade between players (it took a lot of effort to learn to craft those items too, so the number of people capable of doing it was low and not always the same as those who could harvest the raw materials) and provided an option for people to have different equipment sets for different occasions (which was essential, as different mobs required different armour and weapons to combat, and for pvp different gear was required again, harvesters needing different gear again for that).
The game may still be up, haven't played it in a few years though, might go and take a look again. Good memories.

# Answer
> 1 votes
I would advise against using such items. Or maybe if you do use them, than just let them exchange it for a decent amount of gold / score at the end (or when item is obsolete). So if you ended up hoarding it, it doesn't become completely useless.

Personally when I see such items in games, it makes me quite upset. The reason is if I use the item, and still died, I wasted it. If I don't use the item, it will just take up room forever. Sometimes I just toss the item away or use it on next stupid thing, so I don't have to worry about it for the rest of the game.

# Answer
> 1 votes
This is a very interesting question. Happened to me a lot when I was playing games myself!

I'd say you can never penalize players for not using the item, they won't like the game if you do. You should not alter the item neither, e.g. making it rechargable makes it a different kind of item. Instead give the player something for using the item. Not something he can use, but something immaterial that he/she wants. I think the best would be an "achievment".

E.g. you have a nuke-it-all bomb that kills all your enemies. For using this item, give the player an achievment "Seen a nuclear explosion and lived to tell about it".

# Answer
> 1 votes
Not swamping players with loot is a crucial first step to getting players to recognise, store and use the special item at a good time... in conjunction with many very constructive viewpoints offered here, including limiting carrying and usage, and economic interplay.

**Cognition**

Often, players don't use what they're given because *there is just too damn much loot*, too much chaff and not enough of real value, dropping constantly. Sacred II is one example of this. Nearly everything was magical; rarely was a new drop worth swapping out for.

In order for something to appear "special" it has to (a) stand out visually from the rest and (b) even if visually distinct, not be a needle in the haystack of "items which I'll put aside for later use". This means *pacing* special drops.

In most games, items are represented by 2D icons only, and in those like Skyrim where they are full 3D objects, so many objects are so heavily visually embellished that it's hard to tell the "special" from the "mundane". I find the general visual trends of a lot of modern, "loot-heavy" games to be overwhelming, even draining. There is often too much to process. Lower budget games seem to be *better* in this sense, since they have an art budget that only allows simple art styles. **Simple is *good*.**

**TL;DR Cases for different games over time**

As you look over Action RPGs you see a trend of increasing drops, which has largely contributed to irrelevant drops. One of the worst games for this was Sacred II. Just about everything was magical, yet almost none of it was worth swapping your current items out for. D2 had special graphics for uniques but sadly reused graphics for higher level base items, once again reducing cognition.

If you go back to games like Darkstone and Diablo I, or earlier games like Shadowlands, you begin to see far fewer magical items, and far fewer items per se. This sort of approach enables easier cognition of the really special items, like Windforce or Messerschmidt's Axe. In Moria and Angband, there is a good sliding scale on this, with almost all mundane items early on and almost all powerful items near the end of the game.

Baldur's Gate, an RPG in the traditional 80's/90's CRPG mould, somehow always had me using the special items. I learned to trust BG that way, as I found that specials were absolutely worth using and conferred substantial bonuses. This may be in part due to the well-defined D&D combat systems.

# Answer
> 1 votes
**Break the rules**

This question arises from the already standard item system in most of the RPG games. The perfect example would be potions, there have been many memes regarding the collecting of potions, because **"I might need them later"**.

Every RPG producer had to face the problem and many have failed. This comes from the wrong understanding that

> "The item system works like this and it **has** to work like this, because every other game does it like this!".

But it doesn't. And **The Witcher 3** proves it.

In The Witcher 3 the potion system works differently. Here you have a limit of potions you can carry, but after using them you can refill them anytime outside of battle using alcohol.

> "But there will be no fun of searching for that legendary potion/item!"

You are right. After using your potion there will be no fun of searching for it again. However if not the system - the player wouldn't even use the item - meaning **there would be no fun either**. Players often prefer to die and fight again than to use that "too awesome to use" item.

This system brings a different "fun mechanic" though. Instead of searching for that potion you used in a fight, you will spend your time searching for an upgrade of that potion. It can even introduce additional quests to the gameplay.

---

### In your case

There may be a thousand solutions to your problem and it's usually a bad idea to force a player to do something by external limits, like time limit or to reward player for using the item. Tynan Sylvester covers the topic in his book Designing Games: A Guide to Engineering Experiences. So before adding artificial rewards or punishments you should really consider advantages and disadvantages of that.

I already brought up the topic of potions in The Witcher 3, so to reflect it on your situation you could **design the item to be "craftable"**. Let's say - you found that legendary weapon and will not use it in a fight, because you will lose it forever. But in our situation finding this item also allows you to **craft it later**. Or if the item was something magical - it allows you to **summon it in a magic location**.

It not only won't reduce the fun of using this item - it might increase it hugely by adding new mechanics to the game.

In any case you should still balance the item - "awesome" shouldn't mean "gamebreaking". If it is a single use item which kills a dragon in a second then it probably needs balancing anyway.

# Answer
> 0 votes
If an item is *too good* to be at least *rare* (such as the Megalixer), yet it is a 1-use/expendable, yeah players are going to hoard it.

This isn't *really* a problem. Your game is cooler for having awesome rare items that don't manage to break the game. And there's always the 1 in a million chance that a player would find such an item *useful*.

But if these ultra-cool unattainable non-usables still bother you, it sounds like the item may need to be:

a) reduced in effectiveness and made more common

b) made *at least replaceable* (if at an astronomical price)

c) made *not expendable* but given a really long recharge time instead

d) taken out of the game altogether

# Answer
> 0 votes
Just as an aside, some players are very sensitive to this. Personally, I have a habit of always ignoring finite consumables specifically for this reason. Potions are generally used in a pinch, but temporary stat-boosting consumables are something that I both avoid using (to not rely on them) and never sell (in case I need them).

I am aware that I take this to a bit of an unhealthy degree; and you may not be able to coax *every* player out of doing this. It is the inherent nature of limited uses to urge the player to be sparing.

I'm mentioning this because I'm writing this answer in a way that it addresses what would get *me* to reconsider my conservative approach to consumables, as I suspect I'm an extreme example of this.

**Expiration timers** really work well here.

Player who hoard are ones who do not like to waste things. If things automatically waste over time, then *not* using those things will also be a waste that the player wants to avoid.

This ensures a symmetrical tension by at the same time not wanting to use an item immediately and not at a more appropriate time; while at the same time putting a cap on how much time is appropriate to wait for a better opportunity.

If a player isn't all that bothered by wasting a resource, they don't have to even consider this. They're already liable to use the item willy nilly, and are not planning its usage in the long term, so the expiration will not ruin any plans (since they didn't have any).

If a player is very bothered by wastage, they will be bothered by wastage on both ends of the spectrum, and will therefore be incentivized to be on the lookout for the most appropriate time to use it, but that standard of "most appropriate" will be lowered as you get closer to the expiration date.

If a player falls somewhere in the middle, they will be *somewhat* likely to use the item quickly, *somewhat* plan to use it at a more appropriate time, and will be *somewhat* impacted by the item expiring.

In other words, the experience on how and when to use the item is always "fair" in relation to how the player themselves chooses to use the item (liberally, conservatively, or inbetween).

# Answer
> -2 votes
Maybe it'll will work in "super-need" situation. e.g.: a-bomb got 2000 points of splash damage, typical mobs got only 100 health points and easily beaten with sword. but here comes boss with 2500 health points and his minions. you can't beat him... or you can, if you use your a-bomb. then boss will stay alone with 500 health points, so you can (not so) easily kick his ***.

# Answer
> -2 votes
You can punish the player for carrying it, either by taking up many available slots, or slowing him down, you can make him unable to use other weapons when carrying it, and you can make the vending price low. Also, you could make the ammo of a radioactive type, which decays so its strength is reducing while carrying it.

---
Tags: game-design, inventory
---


# Question
Title: How do I export from Blender into Unity with textures?
I have a Blender model, it has a texture on it created with "Images as Planes" addon.

If I open the shading tab I can see the texture and material are there.

When I save the Blender model in the Assets folder of Unity, I don't see that it created a separate materials file with it, not sure if it is saved internally.

I know in order to import a model with textures I need to create a Textures and Materials folders in Unity.

So I added the two folders and placed the Texture used for Images as Planes into the Textures folder.

However, Unity only imported the model, there is no texture on it.

What do I need to do for Unity to import both the model and texture?

# Answer
> 2 votes
The easiest way to do this was to go to `File → External → Data → Pack Resources`

Then `File → External → Data → Unpack Resources`

Choose `Write/Overwrite current`

This created the texture folder and imported into Unity correctly.

---
Tags: unity, blender
---


# Question
Title: How to deal with insane amount of shader variants waiting to be compiled in Unity >= 2021.2 / URP >= 12?
Since Unity 2021.2.0b7 (that is, URP 12.0.0), there has been a well known problem with absurd number of shader variants wanting to be compiled for even a somewhat simple shader (i.e. shaders generated by Shader Graph, e.g. basic Lit Shader Graph, or even a copy of basic URP Lit shader), due to the amount of new keywords processed with `#pragma multi_compile` \- with exact numbers being in the range of tens of thousands to millions shader variants. While the related Unity dev team tried and still tries to fix this issue, there is no official solution available so far, and the problem still affects all the users of URP \>= 12, including (but not limited to) 2021.3.x LTS, 2022.1.x stable branch and all current alphas/betas, up to at least the semi-official 2023.1.0a4 (last one I tested).

Since the actual compile times for such amounts of shader variants go into hours-days-months (depending on actual shader complexity and build power available) which is often prohibitive to normal development (i.e. for me to test my shader code), what can I do now to reduce the amount of variants (and thus build time) to a reasonable value until the fix is available (which may be e.g. somewhere in 2023 in some alpha build etc.), and to possibly circumvent this problem in other similar cases?

# Answer
> 5 votes
*Note: Variant Prefiltering landed in 2023.1.0a14 and is being backported to other LTS versions. It's not perfect yet (a lot of variants are processed anyway), but you will notice a reduction of time of about one or two orders of magnitude after having it.*

Currently, the issue with too many variants and abysmal build times can happen because of two reasons:

1. you actually have too many shader variants needed for your scene, due to e.g. different quality settings spanning through too many options (quite unlikely, and mostly unsolvable in a way other than optimizing those options),
2. you're unlucky enough to use a stock Unity shader code, either by using Shader Graph or `#including` / copy-pasting some of their shader code.

While the amount of permutations for a decent range of quality settings etc. can be indeed high (note that this is usually a multiplicative process), this particular problem usually happens because Unity Editor doesn't recognize the keywords actually (un)used in your scene and doesn't strip them properly from the build. An example offending code from `Complex Lit` looks like this:

```
            #pragma multi_compile _ _MAIN_LIGHT_SHADOWS _MAIN_LIGHT_SHADOWS_CASCADE _MAIN_LIGHT_SHADOWS_SCREEN
            #pragma multi_compile _ _ADDITIONAL_LIGHTS_VERTEX _ADDITIONAL_LIGHTS
            #pragma multi_compile_fragment _ _ADDITIONAL_LIGHT_SHADOWS
            #pragma multi_compile_fragment _ _REFLECTION_PROBE_BLENDING
            #pragma multi_compile_fragment _ _REFLECTION_PROBE_BOX_PROJECTION
            #pragma multi_compile_fragment _ _SHADOWS_SOFT
            #pragma multi_compile _ _MIXED_LIGHTING_SUBTRACTIVE
            #pragma multi_compile_fragment _ _SCREEN_SPACE_OCCLUSION
            #pragma multi_compile_fragment _ _DBUFFER_MRT1 _DBUFFER_MRT2 _DBUFFER_MRT3
            #pragma multi_compile_fragment _ _LIGHT_LAYERS
            #pragma multi_compile_fragment _ _LIGHT_COOKIES
            #pragma multi_compile _ _FORWARD_PLUS
            #pragma multi_compile_fragment _ _WRITE_RENDERING_LAYERS

```

As one can easily calculate, that by itself gives a multiplier of 2^10 * 3 * 4 * 4, i.e. 49152 (roughly 50k), to the amount of needed variants, if the keywords aren't stripped before the build. For a reason (yet) unknown to me, the actual stripping doesn't happen for them (regardless of what the official post of Unity shader team said here), even if the keyword is indeed always on or always off in the scene/URP settings.

The most efficient solution would be to either use a plugin/asset that allows to handle this (or even write a stripper plugin oneself) automatically (e.g. via `IPreprocessShaders` or similar). Still, if you're OK with fixing the problem by hand, the actual solution is quite simple:

1. determine the actual keywords applicable to your shader in your scene, and which of them are fixed, and which ain't (e.g., if you don't have SSAO enabled and don't want to enable it - or if you have it enabled, and want to always have it like that),
2. try to reduce the amount of the actual multi-keywords (variants) to a reasonable number, taking into account their multiplicative nature (i.e. a single keyword and on/off multi gives \*2 variants and build time), and bear in mind that you'll have to have about 10-100 variants anyway, even with the aforementioned keyword completely fixed, depending on your scene & build, and that you can have troubles compiling more than 100k variants regardless of the build machine specs,
3. remove/comment out the `multi_compile` lines with keywords that you don't want to have enabled at all; remove/comment out the variants you don't want/need and/or replace the `#pragma multi_compile` (or `multi_compile_fragment` etc.) with `#pragma shader_feature` etc. (see the docs for more info)
4. ???
5. profit.

In my case e.g., it would look like this after the edits:

```
            // -------------------------------------
            // Universal Pipeline keywords
            #pragma multi_compile _ _MAIN_LIGHT_SHADOWS _MAIN_LIGHT_SHADOWS_CASCADE /* _MAIN_LIGHT_SHADOWS_SCREEN */
            #pragma multi_compile /* _ _ADDITIONAL_LIGHTS_VERTEX */ _ADDITIONAL_LIGHTS
            #pragma multi_compile_fragment /* _ */ _ADDITIONAL_LIGHT_SHADOWS
            // #pragma multi_compile_fragment _ _REFLECTION_PROBE_BLENDING
            // #pragma multi_compile_fragment _ _REFLECTION_PROBE_BOX_PROJECTION
            #pragma multi_compile_fragment /* _ */ _SHADOWS_SOFT
            // #pragma multi_compile _ _MIXED_LIGHTING_SUBTRACTIVE
            #pragma multi_compile_fragment /* _ */ _SCREEN_SPACE_OCCLUSION
            // #pragma multi_compile_fragment _ _DBUFFER_MRT1 _DBUFFER_MRT2 _DBUFFER_MRT3
            // #pragma multi_compile_fragment _ _LIGHT_LAYERS
            // #pragma multi_compile_fragment _ _LIGHT_COOKIES
            // #pragma multi_compile _ _FORWARD_PLUS
            // #pragma multi_compile_fragment _ _WRITE_RENDERING_LAYERS

```

(note that in case of the stock `Lit`/`Complex Lit` shader, you'll have to do this in two places, once for ShaderModel 2.0 block and once for ShaderModel 4.5 block)

which gave me 24 variants for both Vulkan and OpenGL Core instead of 196608 variants for Vulkan and 24576 variants for OpenGL Core without the manual stripping, for a `Complex Lit`-based shader.

---

If you're unlucky enough to be using Shader Graph, it's just a bit more tricky: you'll have to, after each SG change, manually export your SG to a "normal" shader using "View Generated Shader", and then do the above steps manually. It's theoretically possible to "force" a SG shader to be generated in a different way, via injecting custom processing of `pass.keywords` (stored in `PassDescriptor pass`) when `GenerateShaderPass` method is called from `Generator()` c-tor in `UnityEditor.ShaderGraph.Generator.cs`. They are sourced from `KeywordCollection Forward` etc. in e.g. `UniversalLitSubTarget.cs`. Hard to say how worthwhile it is to go this way (note that SG package is tightly coupled with URP package which is tightly coupled with Unity version by itself...) vs just manual (or semi-automatic) preprocessing of shaders instead.

(also, note that even Unity devs considered current `multi_compile` / `shader_feature` `#pragma` system broken and problematic a couple of years before this issue finally hit us big, although for slightly-yet-not-completely-different reasons)

---
Tags: unity, shaders, unity-shader-graph
---


# Question
Title: Scene Turns purple on headset but not in editor
I have a scene that looks fine in the editor and even if I am connected via Oculus link and am running the game the plane interior comes out fine. However when I push a build through adb or app lab I get this result :

My first thought was maybe the lighting settings like maybe the light is not being baked in the scene properly. This doesn't look like the pink shader missing that Unity gives for missing shaders. Any idea where I should start looking/playing with ?

# Answer
> 0 votes
I ended up being able to solve the issue by taking off Realtime and mixed lighting options though it seems like being able to add baked lighting in there would be much faster than being overridden to Realtime lighting.

---
Tags: unity, graphics, oculus
---


# Question
Title: Implementing tension in chain/rope pulling
I'm trying to implement the movement of a chain of segments connected to each other (gravity, mass, etc. are not involved). The chain can only be dragged by its "head" segment. Each segment is represented with 2 vectors (front and back) and has fixed length. Here's my method that adjusts the position of a segment after its previous segment was moved:

```
public void AdjustLocation()
{
    Front = PrevSegment.Back;

    Vector delta = Front - Back;
    float f = SegmentSize.Width / delta.Length;

    Back = Front - (delta * f);
}

```

So it does two things:

1. Sets the front location of a segment equal to the back location of its previous segment.
2. Moves the back location towards the new front location in a straight line maintaining the fixed length.

But the result of that approach is not realistic enough. Like here:  If we pull this chain down, the rear end of it (on the left side) shouldn't move at all until this "knot" straightens out, but it follows its previous segments too much:

As I understand it, when the "head" segment is moved, it just pulls the rest with it, and there's supposed to be a tension that pulls previous segments back.

How can I implement it or make it look slightly more realistic? I've read about simple constraints that just pull objects towards each other to the middle, but I don't understand how is it supposed to work when there are many constraints. Is it necessary to implement complex physics for this?

# Answer
Ok, I think I figured it out.

I've changed the structure a little bit so that every segment is represented by two nodes.

Some pesudo structure:

```
public class Chain
{
    public List<Node> Nodes;

    public void Update(float dt)...
    private void Simulate(float dt)...
    private void ApplyConstraints()...
}

public class Node
{
    public Vector Position;
    public Vector PrevPosition;

    public Node PrevNode;
    public Node NextNode;

    public void Simulate(float dt)...
    public void AdjustLocation()...
}

```

Correcting the position of two adjacent nodes:

```
public void AdjustLocation()
{
    if (NextNode == null)
    {
        return;
    }

    Vector delta = Position - NextNode.Position;
    float distance = delta.Length;
    float restDistance = SegmentSize.Width + SegmentSpacing;

    if (distance > restDistance)
    {
        float f = (restDistance - distance) / distance;
        Vector pull = delta * f * 0.5f;

        // We don't want to pull the leading node back
        if (PrevNode != null)
        {
            Position += pull;
        }

        NextNode.Position -= pull;
    }
}

```

Then it's something like:

```
private void ApplyConstraints()
{
    int iterations = 100; // the more iterations, the more accurate the result
    while (iterations-- > 0)
    {
        foreach (var node in Nodes)
        {
            node.AdjustLocation();
        }
    }
}

```

Though even with a large number of iterations the chain was stretched when moving. So I've also implemented verlet integration, which added some inertia:

```
public void Simulate(float dt)
{
    const float friction = 0.95f;

    // Velocity verlet: x(t + dt) = 2x(t) - x(t - dt) + a * dt^2
    Vector velocity = (Position - PrevPosition) * friction;
    PrevPosition = Position;
    Position += velocity; // there is no acceleration though, can remove dt
}

```

In the chain class:

```
public void Update(float dt)
{
    Simulate(dt);
    ApplyConstraints();
}

private void Simulate(float dt)
{
    foreach (var node in Nodes)
    {
        node.Simulate(dt);
    }
}

```

And you can change the location of a node without changing its velocity like this:

```
node.Position = position;
node.PrevPosition = node.Position;

```
> 1 votes

---
Tags: physics, rope-physics
---


# Question
Title: Wrong results in Fragment shader when using clamped value
I'm following a tutorial and I want to clamp all position values of a triangle between 0 and 1 then output them as a color

this is the code for my vertex shader:

```
#version 330

layout (location = 0) in vec3 pos;

out vec4 vCol;

uniform mat4 model;

void main(){
    gl_Position = model * vec4(pos, 1.0);
    vCol = vec4(clamp(pos, 0.0f, 1.0f) 1.0f);
}

```

and this is the code for my fragment shader:

```
#version 330

in vec4 vCol;

out vec4 color;

void main(){
    color = vCol;
}

```

these are coordinates of my shape, which is a triangle (the values that are going to be clamped):

```
GLfloat vertices[] = {
    -1.0f, -1.0f, 0.0f,
    1.0f, -1.0f, 0.0f,
    0.0f, 1.0f, 0.0f
};

```

result I get is this (completely black):

result I should get is this:

# Answer
> 0 votes
Turns out I had just forgot to put a comma in vertex shader. this works now:

```
vCol = vec4(clamp(pos, 0.0f, 1.0f), 1.0f);

```

in my case this was the only problem, however, there might be other factors that are causing this issue such as wrong Identity Matrix being applied to the "model" uniform

here is a more in-depth explanation of this along with some other reasons that may cause this issue.

---
Tags: opengl, glsl
---


# Question
Title: Input reaction is slow in two player snake game
i'm trying to make a two player console snake game. One of the snakes is controled by 'wasd' and other 'uhjk'. I have two function to get the keys `getKEYS1()` and `getKEYS2()`. Only difference is the expected chars.

```
void Snake::getKEYS1()
{
    if (_kbhit())
    {
        switch (_getch())
        {
        case 'w':
            if (dir1 != down)  // 1
                dir1 = up;
            break;
        case 'a':
            if (dir1 != right) // 3
                dir1 = left;
            break;
        case 's':
            if (dir1 != up) // 2
                dir1 = down;
            break;
        case 'd':
            if (dir1 != left)  // 4
                dir1 = right;
            break;
        case 'r':  //to kill
            dir1 = kill;
            break;
        }
    }
    return;
}

```

And to move the head i use the `Move()` function for both snakes.

```
void Snake::Move(Directions dir)
{

    //getKEYS1();
    //getKEYS2();

    switch (dir)
    {
    case Snake::stop:
        break;
    case Snake::up:
        headY--;
        break;
    case Snake::down:
        headY++;
        break;
    case Snake::left:
        headX--;
        break;
    case Snake::right:
        headX++;
        break;
    case Snake::kill:
        exit(0);
        break;
    default:
        break;
    }

    //adjusting & balancing speed
    if (dir == down || dir == up) Sleep(30);
    else Sleep(7.5);

    //if sneake goes out of borders
    if (headX > width - 2) headX = 1;
    else if (headX < 1) headX = width - 1;

    if (headY > height - 2) headY = 1;
    else if (headY < 1) headY = height - 1;

    //return;
}

```

I can print both snakes to screen but when i try to move, they move with a huge delay.

```
    Snake s;

    std::vector<Snake> Snakes;
    Snakes.push_back(s);
    Snakes.push_back(s);

    bo.Render(screenBuffer);  //render borders to inner buffer
    Snakes[0].Render(screenBuffer);  //render snake1 to inner buffer
    Snakes[1].Render(screenBuffer);  //render snake2 to inner buffer
    screenBuffer->RenderToScreen();  //render all to screen
    screenBuffer->Clear();  //updating the screen
    Snakes[0].getKEYS1();
    Snakes[0].Move(Snakes[0].dir1);
    Snakes[1].getKEYS2();
    Snakes[1].Move(Snakes[1].dir2);

```

I think i call getKEYS2() but program tries to run getKEYS1() too and that's why reaction is slow. Am i wrong? What causes this problem? And what to do to avoid it? If you need more info to understand the problem, please let me know.

I'm new to C++ so i stuck a little here. Thanks in advance.

# Answer
> 4 votes
> I think i call getKEYS2() but program tries to run getKEYS1() too and that's why reaction is slow. Am i wrong?

You are wrong. C++ does not randomly call a completely different function with a similar name unless you ask it to.

The problem here is your logic. In each of these methods you get a key, any key that's been pressed, but then check only if it's a particular player's input. If that key you detected was for the opposite player, it's ignored. You're counting on `_kbhit` and `_getch` to filter to only return you one player's keys, but those functions don't know anything about that.

You perceive a delay because you're leaving it up to chance which key presses you act on, based on the order they come in.

Let's say player 1 presses and holds `w` at the same moment player 2 presses and holds `u`. For whatever hardware reason, the `u` gets detected first, so your console input buffer this frame reads `uw`.

You run `getKeys1()` and pull the first character out of the buffer, `u`, then check if it's any of player 1's keys. It's not, so you don't do anything with it. Then you run `getKeys2()` and pull the next character out of the buffer, `w`, and check if it's any of player 2's keys. It's not, so this input is also unhandled.

If the players keep holding the keys, the console will read `uwuwuwuwuw` with new characters getting added at the configured key repeat rate. So this pattern will repeat every frame until one player lets go of a key.

Player 2's input will only ever be correctly handled on frames where you're lucky enough that player 1 also pressed a key and it was added to the buffer before player 2's.

So, you need to rethink the way you're handling this input. Read the input buffer in a loop, and check the resulting character against *both* players' keys. That way, the input gets handled correctly no matter how many keys were pressed this frame, or the order they were detected and stored.

---
Tags: c++, input, snake
---


# Question
Title: Having one giant level instead of several levels separated by a loading screen
I'm making a metroidvania game. For what it's worth, I'm using Godot as the game engine, but I think my question applies for any engine.

If you look back at old games such as *Super Metroid* on SNES, the game is divided into zones linked together by gates, as shown on this picture:

When the player goes through such a gate, the screen goes black, and I assume that the new zone is loaded while the old one is deleted. You could think of it as a loading screen.

I replicated this mechanism in my game: when the player leaves a zone (by touching the side of the screen in my game), I load the new zone and delete the old one. However, I wonder if this is really necessary. After all, a modern computer is several orders of magnitude more powerful than the SNES. Wouldn't it be possible to simply have one "giant zone" that encompass the entire game?

I'm not sure at the moment how big will be my game, so it's hard to evaluate the size of this "giant zone".

# Answer
It's up to you.

"Giant zone" is technically possible, Salt\_and\_Sanctuary is just a metroidvania game with a "giant zone":

But some parts of it need to be progressive loaded. In off-screen areas you wouldn't want to run monster AI, physics, particle systems, etc, it wouldn't make sense. Going a step further, maybe you also don't want to load scene textures, scene collision boxes off-screen. You can just load what you need by the player's location, and provide some redundancy. There are multiple ways to do this, and since you're aiming for a 2d orthographic game, it's a lot easier than a 3d game. You can create the loading logic yourself, or use some ready-made plugins. But that's not the point of this question, now we come back to your question again:

> Wouldn't it be possible to simply have one "giant zone" that encompass the entire game?

It's technically possible, so the answer is **YES**. But we can find very few games that do this, the latest generation of Metroid Dread is also a series of independent rooms. Because it has more disadvantages than advantages.

Advantages:

1. It has a better sense of immersion and exploration.
2. Maybe more?

Disadvantages:

1. More **difficult** to make. In addition to the scene streaming techniques mentioned above, you must also take into account the complexity of editing a scene on a large map. You need to consider the gradient of art styles in different regions, you need to have a feasible co-dev plan (if it is developed by one person, there is no problem), and the tool support required for editing large maps (for example, displaying all the information in the preview interface at the same time, you computer will explode), etc. During the development process, the scene of the independent room has a natural simplicity.
2. **Controllability** of player movement and game values. Metroid's levels are relatively linear, and its ability-lock mechanism lets you choose among several routes. This way players don't accidentally miss certain areas, or go to advanced areas that they shouldn't be going to at the moment. Player behavior will be more unpredictable in "giant zone".
3. **Limitations of map design**. The map of "giant zone" must be in the Euclidean plane, the shape of one region will be affected by adjacent regions, which will introduce some design compromises. For example, You can see in the picture above that there are a lot of slender aisles and stairs as they need to connect the various areas. This is ugly design in a sense. Players get bored when forced to pass through these aisles. Within these constraints, creating playful scenes requires a higher level of design.
> 2 votes

# Answer
It is certainly possible to fill in whole game into your minimum system requirements (whichever you choose).

From the top of my head, one of the cons of one giant zone is that is could be prone to bugs and glitches breaking too much of the game. Imagine broken physics or a no-clip issue and suddenly player could jump to ANY part of the game. With smaller zones they would be safe-guarding against that sort of issue.

Smaller zones are also easier to manage (both for you and a player), being self-contained and smaller in size. Think of them like a chapters in a book.
> 1 votes

---
Tags: architecture
---


# Question
Title: Handling pipeline objects in both DX12 and Vulkan like graphics APIs
I have been using OpenGL and Directx11 extensively for my engine. The thing is, when I wanted to support DX12 or Vulkan, I realized that they collect all the state data in one place, removing the update of different states altogether.

This causes a problem. Let's say I have 5 different mesh layouts, 300 different materials and 5 different framebuffers with different formats. So as far as I understand, I should create a 5x300x5 different pipelines in order to support the drawing of all the permutations.

This bugs me. It forces you to create all of your data statically in the editor time.

Let's consider if I created a different lighting method, and I wanted to spawn my light at runtime. My light uses a different format from the existing lights in the scene. So what happens? I froze the game for 0-x milliseconds to compile all of the permutations just for my newly instantiated light?

I hope I'm missing something out here. Because I don't like the idea of forcing me to create all the permutation of the possible pipelines before building the game into a separate executable.

Although this does not end with the game runtime. Whenever I create a different mesh layout or import different mesh layout from .obj/.fbx file, I should create all the necessary pipelines for these mesh layouts.

Which begs further questions, questions like should I manage my existing mesh layout-material-framebuffer registry every time I begin to render.

I feel like it will demand a high level maintenance for creating the required pipelines and accessing the existing pipelines.

Before it was like

```
Iterate each camera
Iterate each mesh renderer
Get mesh and material data and render

```

and now how should I manage the rendering?

```
Iterate each camera
Iterate each mesh renderer
Get the pipeline using the mesh renderer's material and mesh ID combinations?
Use pipeline and render

```

What happens when mesh renderer's material and mesh fields changes? Should I detect and switch pipelines for that renderer?

I feel like Vulkan and Directx12 is a let down in this regard. I understand that they offer an extensive control over the device, unlike OpenGL, but it feels like it's restricting me.

I'm curious about what your inputs will be. Please feel free to give any type of feedback.

# Answer
This is a known problem with the new APIs: https://forum.beyond3d.com/threads/shader-complilation-on-pc-about-to-become-a-bigger-bottleneck.61929/

Vulkan is evolving solutions for it via extensions, such as VK\_EXT\_graphics\_pipeline\_library, which contains a statement and acknowledgement of the problem:

> The original promise of monolithic pipelines in Vulkan was to enable developers to construct all their state up front, avoiding the driver doing dynamic compilation and patching shaders implicitly when recording draw calls, resulting in unexpected hitches.
>
> The reality however is that for many game engines, requiring most of this state up front either fails to eliminate hitching, or requires precompiling so many state combinations that the size of the pipeline cache is nearly unmanageable.
>
> Games engines are typically still managing enormous sets of state and shader combinations, and this is not a purely technical problem. It is still expected and encouraged that developers will limit the number of these, but it doesn’t change the fact that at least in the short-to-mid-term, developers are having real problems that can’t be solved by telling them to reduce the number of pipelines.

Until these solutions become commonplace, you're mostly stuck with workarounds for the problem, such as:

* Consider if you actually need all of the permutations; there are probably permutations that it doesn't make sense to use together, and you surely don't need all 300 materials for each mesh you create.
* Use shader uniform values of 0 or 1, or 1x1 black or white textures, to allow you to combine permutations and reduce the number that way.
* Only create each permutation as it's needed, the first time it's used, at a cost of some runtime hitching and stalling.
* Decide that Vulkan or DX12 don't meet the requirements of your program and continue using the old APIs.
* Anything else that makes sense in the context of your program.
> 1 votes

# Answer
It may feel inconvenient, but precompiling all pipeline permutations ahead of time is how Vulkan was designed to be used. Compiling pipelines is expensive, and if you *are* able to do it all up-front it's worth doing so. If you still want to do JIT compilation, Vulkan offers "pipeline cache" objects that can let you serialize your shader permutations so that the majority of your permutations will be loaded, and only permutations that weren't captured by the cache are JIT-compiled.

Arseny Kapoulkine (Zeux) wrote a good article about this problem and the various solutions to it here (scroll down to "Pipeline Objects").
> 1 votes

---
Tags: opengl, rendering, directx11, directx10, vulkan
---


# Question
Title: Python GLFW and PyOpenGL: How to update a VBO from a thread while rendering at the same time
I'm really new to this community. I'm sorry for any mistakes in advance.I'm making a game like minecraft with GLFW and OpenGL. The problem is, I just can't render a VBO while I update it from another thread. Here is my code:

**main**.py

```
# imports
import glfw
from OpenGL.GL import *
from OpenGL.GLU import *

# internal imports
from core.renderer import *
from terrain import *
from player import *

if not glfw.init():
    raise Exception("glfw can not be initialized!")

window = glfw.create_window(800, 500, "PyCraft", None, None)
glfw.make_context_current(window)
renderer = TerrainRenderer(window)
player = Player(window)

glEnable(GL_DEPTH_TEST)
glEnable(GL_CULL_FACE)
glCullFace(GL_BACK)
# glEnable(GL_FOG)
glFogfv(GL_FOG_COLOR, (GLfloat * int(8))(0.5, 0.69, 1.0, 10))
glHint(GL_FOG_HINT, GL_DONT_CARE)
glFogi(GL_FOG_MODE, GL_LINEAR)
glFogf(GL_FOG_START, 3)
glFogf(GL_FOG_END, 10)

renderer.texture_manager.add_from_folder("assets/textures/block/")
renderer.texture_manager.save("atlas.png")
renderer.texture_manager.bind()

world = World(renderer, player)
world.generate()

# get window size
def get_window_size():
    width, height = glfw.get_window_size(window)
    return width, height

def _setup_3d():
    w, h = get_window_size()

    glMatrixMode(GL_PROJECTION)
    glLoadIdentity()
    gluPerspective(70, w / h, 0.1, 1000)
    glMatrixMode(GL_MODELVIEW)
    glLoadIdentity()

def update_on_resize():
    _setup_3d()
    glViewport(0, 0, *get_window_size())

# mainloop
while not glfw.window_should_close(window):
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

    update_on_resize()

    _setup_3d()
    glClearColor(0.5, 0.7, 1, 1.0)

    player.update()
    player._translate()

    glfw.poll_events()
    glfw.swap_buffers(window)

glfw.terminate()

```

renderer.py:

```
# imports
import glfw, numpy
from OpenGL.GL import *
from ctypes import *
from core.texture_manager import *

glfw.init()

class VBOManager:
    def __init__(self, renderer):
        self.renderer = renderer
        self.run()

    def run(self):
        for i in self.renderer.to_add[:self.renderer.to_add_count]:
            self.renderer.vertices.extend(i[0])
            self.renderer.texCoords.extend(i[1])

            _ = i
            self.renderer.to_add.remove(i)

            glBindBuffer(GL_ARRAY_BUFFER, self.renderer.vbo)
            glBufferSubData(GL_ARRAY_BUFFER, len(self.renderer.vertices), len(_[0]) * 4, (GLfloat * len(_[0]))(*_[0]))
            glFlush()
            glVertexPointer(3, GL_FLOAT, 0, None)
            glTexCoordPointer(3, GL_FLOAT, 0, None)
            glBindBuffer(GL_ARRAY_BUFFER, self.renderer.vbo_1)
            glBufferSubData(GL_ARRAY_BUFFER,  len(self.renderer.texCoords), len(_[1]) * 4, (GLfloat * len(_[1]))(*_[1]))
            glFlush()

class TerrainRenderer:
    def __init__(self, window):
        self.window = window

        self.vertices = []
        self.texCoords = []

        self.to_add = []
        self.to_add_count = 256

        self.vbo, self.vbo_1 = glGenBuffers (2)
        glBindBuffer(GL_ARRAY_BUFFER, self.vbo)
        glBufferData(GL_ARRAY_BUFFER, 12 * 4, None, GL_STATIC_DRAW)
        self.vbo_manager = VBOManager(self)

        self.texture_manager = TextureAtlas()

        glEnable(GL_TEXTURE_2D)
        glEnable(GL_BLEND)
        glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
        glEnableClientState(GL_TEXTURE_COORD_ARRAY)
        glEnableClientState (GL_VERTEX_ARRAY)

    def load_assets_from(self, other_renderer):
        self.texture_manager = other_renderer.texture_manager

    def render(self):
        try:
            self.vbo_manager.run()
        except RuntimeError:
            pass

        glClear (GL_COLOR_BUFFER_BIT)

        glEnable(GL_TEXTURE_2D)
        glEnable(GL_BLEND)
        glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
        glBindBuffer (GL_ARRAY_BUFFER, self.vbo)
        glVertexPointer (3, GL_FLOAT, 0, None)
        glBindBuffer(GL_ARRAY_BUFFER, self.vbo_1)
        glTexCoordPointer(2, GL_FLOAT, 0, None)

        glDrawArrays (GL_QUADS, 0, len(self.vertices))
        glDisable(GL_TEXTURE_2D)
        glDisable(GL_BLEND)

    def add(self, posList, texCoords):
        self.to_add.append((numpy.array(posList), numpy.array(texCoords)))

    def update_vbo(self):
        pass

```

world.py

```
from terrain import *
from player import *
from core.renderer import *
import threading
import random
import glfw

def execute_with_delay(func, delay):
    threading.Timer(delay, func).start()

class ThreadedChunkGenerator():
    def __init__(self, world):
        self.thread = threading.Thread(target=self.run, daemon=True)
        self.world = world
        self.event = threading.Event()
        self.event.wait()
        glfw.make_context_current(self.world.parent.window)

    def run(self,):
        glfw.window_hint(glfw.VISIBLE, glfw.FALSE)
        window2 = glfw.create_window(300, 300, "Window 2", None, self.world.parent.window)
        glfw.make_context_current(window2)
        self.event.set()

        renderer = TerrainRenderer(window2)
        renderer.load_assets_from(self.world.parent)
        while True:
            for i in range(self.world.to_generate):
                chunk = i
                renderer = self.world.parent

                chunk.generate(renderer)
                self.world.renderer = renderer

            self.world.to_generate = []

class World:
    def __init__(self, renderer, player):
        self.parent = renderer
        self.chunks = {}
        self.blocks = {}
        self.position = (0 * 16, 0 * 16)
        self.render_distance = 1
        self.infgen_threshold = 1
        self.block_types = all_blocks(renderer)
        self.to_generate = []
        self.player = player

        self.thread = ThreadedChunkGenerator(self)
        self.thread.start()
        self.event = self.thread.event
        self.event.wait()

    def block_exists(self, position):
        return position in self.blocks

    def _add_chunk(self, position):
        self.chunks[position] = Chunk(self.parent, self, position)

    def add_chunk(self, position):
        execute_with_delay(lambda: self._add_chunk(position), random.randrange(1, 2))

    def generate(self):
        for i in range(self.position[0] - self.render_distance, self.position[0] + self.render_distance + 1):
            for j in range(self.position[1] - self.render_distance, self.position[1] + self.render_distance + 1):
                if (i, j) not in self.chunks:
                    self.add_chunk((i, j))

    def update_infgen(self, position):
        player_pos = (position[0] // 16, position[2] // 16)

        if player_pos[0] - self.position[0] > self.infgen_threshold:
            self.position = (self.position[0] + 2, self.position[1])
            self.generate()
        elif player_pos[0] - self.position[0] < -self.infgen_threshold:
            self.position = (self.position[0] - 2, self.position[1])
            self.generate()
        if player_pos[1] - self.position[1] > self.infgen_threshold:
            self.position = (self.position[0], self.position[1] + 2)
            self.generate()
        elif player_pos[1] - self.position[1] < -self.infgen_threshold:
            self.position = (self.position[0], self.position[1] - 2)
            self.generate()

    def render(self):
        self.parent.render()
        self.update_infgen(self.player.pos)

```

Right now, it shows no errors, just hangs the window before it even starts rendering. Any help will be highly appreciated.

# Answer
> 3 votes
If you want to be able to read and write buffers while they're being used, you can use "persistently-mapped buffers". Be aware that by using them, you will become responsible for handling all synchronization of your buffer data, which will substantially complicate your renderer. Thus, I don't actually suggest trying this, especially if you are new to graphics programming.

Before you try any more advanced approaches, I recommend keeping a host-local copy of your data (i.e. in normal CPU memory) and write into that with your thread, and then use your main OpenGL thread to copy it into the buffer when it's time. OpenGL is fundamentally single-threaded, trying to interact with it from multiple threads will give no performance improvement at best, and may even harm performance.

Finally, I feel obligated to point out that due to Python's global interpreter lock (GIL), threads from python's `threading` library *cannot execute in parallel*. If you want true hardware parallelism in a python program, you'll need to either write a C/C++ extension for python (i.e. your own python module), or use the `multiprocessing` library to avoid the GIL.

---
Tags: python, multithreading, vbo, glfw
---


# Question
Title: How do map designers subconsciously lead players?
Playing a game like Uncharted I’m struck by the illusion of an open world that it feels like I’m making my own choices to walk through, but I always stumble on the next plot point or encounter, so clearly I’ve been led by the designer. How?? It feels like I’m deciding whether to go left or right or whatever but clearly I’m responding to subtle cues — what are they?

# Answer
I haven't played Uncharted, so I haven't analyzed Uncharted. What I know about it is mostly from YouTube. Something I can tell is that it is very linear. If there are options, they might be using false branches.

Anyway, I can share what I have pieced together about designing landscapes and guiding the players… But know it mostly not from Uncharted.

---

**On the language of games**

Games are a communication medium, between the designed and the player, it has a language. And through the language of games the player gets to know how the designer thinks.

Some of the language is unique of the game, some of the genre, and some is more general. And it might become second nature, to the point that you are not aware when you are picking the clues.

Some of the language of games is lifted from actual nature, such as color and shapes associated with danger or safety. *See also the psychology of shapes, the psychology of colors, and the psycology of music.* You can be more explicit, and use enemies, explosions, and so on to signal danger and have the player avoid a path.

Some of the language is transferred knowledge, from other games in the genre. And some is unique of each game.

Speaking of affordances: you want to define standard sizes, so the player can pick on which spaces they can go through, and over what things they can jump over. *And it also makes things easier for animation.*

*Games that rely on scripted sequences instead of a sandbox approach, might be expecting a particular solution from the player. The player will learn to think "what the designer want me to do". And through the language of games the player gets to know how the designer thinks. Although, we should aspire to the player thinking "what can I do" or better yet "what do I want to do" instead of "what the designer want me to do".*

---

Out of what I can tell you about Uncharted, is that it uses color as affordance. However, you need to learn it. You are not born knowing that you climb on yellow. So, you see, the same game can also be less intuitive to a less experienced player.

For example, an experienced player would try different inputs on their controller and see what they do. *And be annoyed by a tutorial.* But we don't know if a beginner would do that or not. Some might assume that what they are told is all they can do. And this might mean they miss on possible alternative ways to progress.

For an example of bad design affecting experienced players and beginners differently: you see an space wide enough to go through, and there are no visible enemies or hazards… But when do you try to go there, a cut-scene plays where enemies attack you and you die, requiring to try the area again. Were you too slow? Were you not sneaky enough? Or perhaps it is designed so that going that way is an insta-death and give you the illusion that there are more possible paths than there actually are at the expense of player frustration? Perhaps as experienced player you take the fact that it is a cut-scene as clue, but a beginner might struggle with it (or not, it depends on the person).

---

**Guiding the player**

*I suppose I don't need to talk about non-diegetic solutions (e.g. minimaps).*

I want to start on the more liminal side of the spectrum: You can quite literally tell the player about a place. In fact, many games would have a quest that makes you go there. Similarly, if there is a companion NPC, it can provide hints if the player gets lost. Also on the liminal side is using a trail of collectibles or easy to kill enemies to guide the player. And, of course, an actual path on the ground.

On a similar note, if exploring is rewarding, the players will be inclined to explore more. And rewarding here can be objects either hidden or hard to reach, but it can also be a a good looking landscape, or some dialog, or environmental storytelling, or make it a hidden shortcut.

By the way, either for the good looking landscape or other opportunities, you can take take advantage of the techniques used in photography to draw attention to the place you want them to go. And those techniques include framing, radial lines, concentric shapes, color and light contrast. And, of course, you can use motion to draw attention. *Light is also particularly useful to draw attention. For example, have a window or hole in the ceiling for sunlight to enter - or simply a lamp - that highlights an object that the player should interact with.*

*Another thing I can tell from Uncharted is that it has a cover mechanic. So you put enemies that attack the player from the direction you want the player to go, the player takes cover, and now you know the camera is looking that way. You might be paying attention to the enemies, but you can also see the path fordward.*

On a less linear game, instead of teaching players to explore, you want to teach players to keep momentum. So any side path, if there are any, is not rewarding. Instead you reward going forward and going forward fast, so players learn to not stop to explore.

To ease this, you want to make sure the path forward remains in view if the player is following it (and thus, there is no geometry occluding it, and there are no sharp turns). You may take advantage of elevation to give the player an advantage point if going downwards. Or a clear milestone ahead if going upwards.

*To have the player keep going and not stop to explore, you can also add a sense of urgency via narrative. And have music reinforce it.*

---

First and foremost, having tall structure that can be seen from afar is good to help players orient themselves. However, each of those structures can be taken as a promise to the player that they can get there. The players might be inclined to pick one such structure and start going that way, so you can take advantage of that. On a similar note, use the terrain to frame where you want the player to go, and to hide where you don't want them to go.

*By the way, the textbook frame opportunity is when the player is going through a door. But you can do it with terrain features too.*

You would also take the opportunities to reveal new destinations. For example: the player climbs on to something, or goes pass an obstacle, or opens something, so that they can now see a place that was obscured before, and of course that is the next place - or one of the next places - they should go.

Second, you can to make the terrain/architecture/structures distinct for distinct areas. *A good idea for this is to use psychology of shapes. You may also color code areas.* Thus, when the style changes, the player knows they are getting to a new are to explore. There the players will take more time to look around.

Also, you want the terrain to close into pathways and open up to to wide areas, so the player can think in terms of a discrete number of possible paths they can follow, and areas to explore. Instead of picking arbitrary directions in one giant area.

*Please notice that what I'm saying is also good for culling geometry out of view.*

*By the way, sound and music can also help signal to the player where in the world they are. Or even where to go, for example if you can hear enemies in a particular direction.*

---

You can make paths more clear by drawing lines. Either literally draw paths in the terrain (for example it can be following the side of a terrain feature), or have have repeated structures that serve as milestones. Also, avoid sharp angle that might be misunderstood as the path ending abruptly.

When the player is walking down a path, you can guess where they are looking, and that gives you the opportunity to frame other things without taking away camera control※. You can also be somewhat more subtle about the paths, for example have wildlife move in a particular direction.

※: If players need to backtrack to an area, they will approach it from the opposite direction, and that is an opportunity to show them things they might have missed on the first pass. Which reminds me, you use this to hide things you want the player to miss, and reveal them later this way. Then recurring - or good explorer - players would be able to get them early, which could be a soft sequence break.

When the player is exploring an area, you can make things stand out by their size (this comes natural if you are already using tall structures that can be seen from afar). The big structure suggest the player that there is more stuff inside, and that it is important. So it feels natural to want to explore it.

---

You can use music cues to hint the player what behavior they should have. The classic example is music for combat, and music for safety. But you can also have music for exploration, and music for linear traversal. Like I said before, you may give the linear sections a sense of urgency, and support it with music. Do the equivalent with open areas. And then the player will associate the music with the kind of area they are in, and that clues them into the desired behavior.

---

**False branches**

You can have multiple traversal options, even depicted as paths, that are not actual branches (they don't lead to new areas). Instead they either:

* Loop back over the same path. Which you could do with a one way connection or a hidden connection, so you know on which direction the player enters the loop. If it is a one way connection, it could also be opened as a shortcut.
* Dead ends. These are the small sibling of the loop, in that you can think of them as a loop where the second half is the same as the first half but going backwards. You may put optional loot there.
* A shortcut. For example, without drawing attention to it, or by making it hard to access. You can have two paths that lead to the place, except one is shorter than the other.
* A redundant path. So the path splits in two, but they are actually equivalent.
* The evident path. For this one you use everything you can to hint the player to go there.

*Since I'm saying that once open, the loop can be a shortcut, and that the shortcut could be hard to access… Instead of a one way connection, you can make the loop use a connection that is hard to traverse in one direction, but easy on the other. So it is both.*

And so the player might be exploring, and going out of the intended path, even feeling smart for finding a shortcut… But they end at the same place, not matter what.

---

**Addendum**:

You can close the path behind the player to reduce the area they have to explore to find the path forward. This is useful in games that require a lot of backtracking, but you don't want the players to try to backtrack their way back to the beginning of the game.

Also, remember you close a path in a way that requires the player to have an object or ability to open it or bypass it. You may even have such paths not naturally read as paths. So the player is only looking for them once they got said item or ability. Making them virtually invisible beforehand.
> 18 votes

---
Tags: game-design, level-design, world-design
---


# Question
Title: Does the bee move very fast in the very first frame of the game?
Does the bee move very fast in the very first frame of the game? I think the `Clock` object when it is declared, the clock starts automatically as this documentation says. And in the very first iteration of the loop, the clock.restart function returns the elapsed time since the clock was started or restarted, and it's a very quick moment so that it makes the bee move strangely fast from other frames moving forward, I guess. In other frames, the bee moves smoothly and nicely.

```
// Include important libraries here
#include <SFML/Graphics.hpp>
// Make code easier to type with "using namespace"
using namespace sf;
// This is where our game starts from
int main()
{
    // Create a video mode object
    VideoMode vm(1920, 1080);
    // Create and open a window for the game
    RenderWindow window(vm, "Timber!!!", Style::Fullscreen);
    // Prepare the bee
    Texture textureBee;
    textureBee.loadFromFile("graphics/bee.png");
    Sprite spriteBee;
    spriteBee.setTexture(textureBee);
    spriteBee.setPosition(0, 800);
    // Is the bee currently on screen?
    bool beeActive = false;

    // Variables to control the time itself
    Clock clock;
    while (window.isOpen())
    {
        /*
        *****************************************
        Handle the player's input
        *****************************************
        */
        if (Keyboard::isKeyPressed(Keyboard::Escape))
        {
            window.close();
        }
        /*
        *****************************************
        Update the scene
        *****************************************
        */
        // Measure time
        Time dt = clock.restart();
        // Set up the bee
        if (!beeActive)
        {
            // How fast is the bee?
            srand((int)time(0));
            beeSpeed = (rand() % 200) + 200;
            // How high can the bee fly
            srand((int)time(0) * 10);
            float height = (rand() % 500) + 500;
            spriteBee.setPosition(2000, height);
            beeActive = true;
        }
        else
            // Move the bee
        {
            spriteBee.setPosition(
                spriteBee.getPosition().x -
                (beeSpeed * dt.asSeconds()),
                spriteBee.getPosition().y);
            // Has the bee reached the left-hand side of the screen?
            if (spriteBee.getPosition().x < -100)
            {
                // Set it up to be a whole new bee next frame
                beeActive = false;
            }
        }
        /*
        *****************************************
        Draw the scene
        *****************************************
        */
        // Clear everything from the last frame
        window.clear();
        // Draw the insect
        window.draw(spriteBee);
        // Show everything we just drew
        window.display();
    }
    return 0;
}

```

# Answer
> 2 votes
If the problem is that the first time isn't reliable due to variable initialization between creating the clock & reading it, you can add a basic check that zeros the clock back out on the first time through your loop:

```
// note: earlier code omitted - all of that can stay the same

Clock clock;
bool firstTimeThrough = true;
while (window.isOpen())
{
    /*
    *****************************************
    Handle the player's input
    *****************************************
    */
    if (Keyboard::isKeyPressed(Keyboard::Escape))
    {
        window.close();
    }
    /*
    *****************************************
    Update the scene
    *****************************************
    */
    // Measure time
    Time dt = clock.restart();
    if(firstTimeThrough)
    {
         dt = clock.restart();
         firstTimeThrough = false;
    }

    // note: remaining code omitted - all of that can stay the same

```

The documentation for `restart` says:

> This function puts the time counter back to zero. It also returns the time elapsed since the clock was started.

On the first time through (and only the first time through), the clock gets reset twice, so the resulting time should either be zero or very close to zero. Because the `firstTimeThrough` flag is true on the first pass through the loop, the remaining iteration should behave as usual.

---
Tags: sfml, frame-rate
---