# Question
Title: How do I get players to say "no" when they are afraid of missing out on sidequests or XP?
In my RPG, I have a companion NPC who is overconfident in his abilities and lacks self-control. I wanted to create a few situations where the player needs to reign them in and tell them "no". One such situation basically boiled down to this:

> Companion: Hey boss, I want to do this really stupid thing that will almost certainly make things harder for us down the road and possibly jeopardize our goal. Is that okay?
>
> Player Choices:
>
> * Yes, go ahead!
> * No, don't do that!

My hypothesis was that the vast majority of playtesters would choose "No". To my surprise, the vast majority *chose "Yes"*! And then when the consequences played out and indeed made things worse, playtesters wanted to reload from an earlier save point and pick the other option (choosing "Yes" wasn't game-ending, but it did mean that a perfect outcome wasn't achievable).

When I asked the playtesters why they chose yes, they made it clear that they understood that saying yes was undesirable and saying no was desirable. They also weren't seeking a challenge or anything. Instead, the most common thing I heard was:

> I was afraid that if I said "No", then I'd miss out on a sidequest or XP.

One of them even said that in other RPGs he played, the only way to get a 100% playthrough was to say yes at every opportunity, and so they assumed that was the case for mine.

I don't want players to assume that saying "yes" is always the right answer, and for now, I'd like to keep the situation of having to tell the NPC "no" every once in a while. But I don't know how to overcome these player expectations and their fear of missing out of content, especially without just flat out saying "this isn't like other games, you won't miss out if you say 'no'".

So how do I get players to say "no" when they are afraid of missing out on sidequests or XP?

# Answer
> 194 votes
That is a common concept in nearly all existing videogames: you either say *yes* to accept a new quest or *no* to not take it. Players get used to this pattern by encountering it over and over, and finally simply start to assume beforehand that this pattern is also true for your game.

A good example of handling this problem is **Deus Ex: Human Revolution**. In the beginning of the game, the player is told to not waste time exploring and rush in for the quest, or else "people will die". Many players simply assume that comment is simply an "*in-game immersion*" statement which wouldn't affect the gameplay at any rate. Consequently, not two minutes after they are told that hostages were killed and they are too late, thus *breaking the pattern players were used to* very early in the game while still allowing them to rollback the two minutes they already spent exploring and instead prioritize the quest.

That could be a solution in your case. If many players think your game follows already established patterns, show them that it does not! Give them a small quest (or better yet, a few of them) that would require players to reason and use their judgement to make a choice, so that they get used to the new concept. You could also display a "help window" during the first time they get a quest that "*not all of the quests should be taken*" or "*player shouldn't agree to everything they're told*". Once they are familiar with the concept, throw in your important quests, which they will immediately recognize as one of the problems they'd have to think about.

Another thing you might want to consider: if there is an important decision for players to make, give them as much information as possible and give them the time to think. That is, instead of having an NPC make a simple statement that looks like a quest offer ("Let's try this totally silly thing!"), elaborate on what they're offering and allow players to inquire for details and possible drawbacks. Make it feel like an important decision to be made, and your players will treat is as such.

# Answer
> 130 votes
Change the options to Left-Right rather than Yes-No.

A Yes-No choice is an option. Add this extra bit in or ignore it. A Left-Right choice is a choice. You can have this or that, but not both.

So instead of having a single character offer an option, have two characters offer conflicting paths. Make it clear that either way the play will miss out on some content.

I think this is likely to be treated as the classic good vs evil play style choice that many games offer. ie, players will assume that the story will remain essentially the same but with a different ending/character dialogue and put the choice down as a 'no right answer' dilemma.

So you may need to either tweak your 'bad' choice so it is not completely negative, or show players early on that there are game ending mistakes and they are expected to play it in a rogue-like way.

Also maybe you are just making a bad game. If you get to the very end after hours of game play and find that I can't enter the evil lair because I did/didn't do something seemingly innocuous hours ago. Is that fun?

Sure it might be realistic and challenging, but a lot of people will stop playing and write you a bad review at that point.

You would really have to make it clear that your game is more of a puzzle and you expect them to have to do multiple play throughs to solve it.

# Answer
> 43 votes
A way to show which answer is the "right one" without taking away the choice, would be to weight the options through meta-information.

Instead of just showing one "yes" option and one "no" option you can provide a list of options for the side you prefer.

For example:

1. No. You're going to get yourself killed.
2. No. We don't have time for that.
3. No. That would put all of us in danger.
4. Yes. I don't care if you're going to get yourself killed.

In addition to providing a hint, which option is considered the better one, it also gives you a chance to restate the consequences of the decision.

The above answer also takes advantage of a second learned convention from modern gaming: "Don't judge logically, judge empathically". The "right" choice, more often than not, is the one that is empathic towards another characters plight. The phrasing of your answer should be done in a way, that makes it clear that this is the better choice for the character you're talking to, not just yourself.

# Answer
> 22 votes
I love these because there's always a multitude of ways to do this.

* The first thing that comes to mind is to not make it such a blind choice. If it is a decision that *has the potential to ruin a perfect ending*, perhaps it's worth making the "no" choice look like a "yes" choice. Something like:

> Hey, I think we should go do this ridiculous thing that will probably have a really bad impact on our future decisions!
>
> 1. Yeah, I don't think that's a good idea, let's pass on this one.
>     2. No, you're totally right, let's go do this ridiculous thing that will totally ruin our perfect score!

In this alternative we make it more clear that the "default" option of "yes" means skip it, and that "no" is not the best option. (You would obviously reword it to fit better, but this is the basic idea.)
* As mentioned in other answers, build a pattern of the "yes" decision not being appropriate. You can do this on a game-wide level, or just for this NPC. Add a couple other side-quests that have minimal impact, but work in the same way offered by this same person. If the player sees that their two *previous* "yes" options had a net-negative effect, they might reconsider a "yes" option here. (Especially if the net-negative effect here is more adequately shown, such as **"Yes, let's risk this *\<really important thing\>* on your silly idea."**
* Build a slightly longer dialogue on the decision, where the player asks some more important questions:

> Hey, I think we should go do this ridiculous thing that will probably have a really bad impact on our future decisions!
>
> + Doesn't that influence \____ in a horribly negative way?
>
> Well, probably, but what *else* are you going to do?
>
> + Will I gain any more valuable skills/items/what-have-you?
>
> I don't think so, I'm pretty sure we'll get nothing out of this.
>
> + Then why would I do this?
>
> Because it'll be super fun!
>
> 1. Okay, I think this is a bad idea but let's go ahead. *(Possibly meta-game about not needing to do this quest, or give the player a meta-game description of the conclusion the character came to based on the questions.)*
>     2. Nah, I think I'll carry on with our traditional path.
* Give them the opportunity to back out when they start seeing that this decision is bad. There's not much to elaborate on here, but you can possibly provide "tips" or such that show this idea is not going to have a positive gain.
* And lastly, you could give them *two* side-quests to do, "Yes" being the *bad idea* and "No" being an alternative *good idea*. This would mean they can choose between `A` and `B`, and gain equivalent experience/completion in each. (Thus, there's no *need* to choose `A` to get 100% completion.)

> Hey, I think we should go do this ridiculous thing that will probably have a really bad impact on our future decisions!
>
> 1. Yeah, let's do that.
>     2. No, let's do *\<this other thing\>* instead.

# Answer
> 11 votes
I find your argument for the Option-less version very compelling, but lacks the insight, why a player would choose the easier option.

As your play tester stated, they feared they might miss on content: XP, items, quests... What that means is, you have to show the players what their options really are.

On way could be the direct way. Tell them directly what each option means. This is more a meta way of doing things.

> * Yes, do that! (You may not be able to complete some quests, no bonus XP)
>
> + No, don't! (Normal gameplay)

And now you might see, why you don't empower the player at all, by choosing one of these options. Why pick one option, if you know you don't get anything, but just loose? Why shoot yourself in the leg, if you don't get a fancy new bionic leg afterwards? You basically just punish your player for doing the wrong thing. That's why the players reloaded the game to change their decision.

The other way would be to show the player beforehand, what his decision could mean. So before the player first had the option of saying no, this Npc could have done something similar without asking, and you find him in a dangerous situation with a broken quest item, killed enemies (that won't give Xp any more) and so on. This way, the player might realize that this might be worse if he does that again and might say no. Problem is, games teached us to do reckless but cool actions, with bonus items, archivements and what not, so this might be not as compelling as the meta approach.

# Answer
> 11 votes
Answered per @trlkly's comment suggestion:

You are presenting a "yes vs no" dichotomy to your players. A lot of the time, this is fine; players regularly run into scenarios where they have to make a choice and there are immediate consequences for that choice. This does not appear to be one of those times.

In this scenario, you've got a companion who wants to go do a Stupid Thing. Depending on what that Stupid Thing is, the companion could either do it later, or do it next time. If it's something that arises during an exigent circumstance, offer the player the choice of:

> "I don't think that's a good idea. Maybe next time."

If it's something that can be delayed (like "I want to address an elephant in the room" or "I want to flip this switch to release a horde of bad guys", give the player the option to say:

> "Not yet. Let's do it on our way out/later/next time we see one of those switches".

That would tell players accustomed to doing every possible scenario "you can come back to this later/it will be offered again later; you don't have to do it right now".

As a player, I really appreciate these opportunities because I do hate to miss out on potential XP/game play, just like your testers. This would solve the problem you're having of players complaining that they can't achieve optimal results simply because they're playing in a style different from one you've anticipated.

In other words, you are recognizing that the player values experience over logic or efficient game play, and you're allowing them to move forward the way *you* want (do the logical/efficient thing to get the perfect score), while still offering them the opportunity to play the way *they* want (organically and whimsically).

The downside to this is that it may require a bit more development time to implement the option later on down the road in the story line.

# Answer
> 5 votes
The key is to help players see trade-offs, specifically **content-access trade-offs**. Players, especially on a first run, usually care a lot more about experiencing everything than getting high scores. Since games almost always allow you to recover from mistakes, it makes the most sense to accept every quest, saying yes to everything, accessing all the content a game has to offer. You need to break this mindset by showing that it is impossible to do everything in a single game.

One example that did this well is Stardew Valley. Early in the game, you discover that you can buy a membership to JojaMart, but you probably do not have the money to buy the membership at that point. Soon, before you would normally save enough for the membership, you find out about what the old Community Center has to offer and are told that it will be torn down if you buy the membership.

Many will still want to see what happens when you choose a worse choice, though. I know *I* would be willing to start a new game file and choose the bad option just to trigger a new cut-scene or line of dialog. If you make it clear though, that by choosing the better option, they wouldn't be missing any more content than they would by choosing the worse option, most players would choose the obviously better option the first time through, unless they already saw a friend pick that option.

# Answer
> 4 votes
I think the first thing you have to realize is that whichever reason you write software for you users, you have to *learn* from them and adapt in a strict feedback/development circle, instead of *teaching* them how you meant your game/product to be used. That said, there are still ways to adapt both your needs and the common sense (I've learnt how many times the common sense differs from that of a single point of view). A good solution in your case require a little bit different approach to the game mechanics: instead of *having the things going worse* when the player took the wrong decision and make them wish to

> reload from an earlier save point and pick the other option (choosing "Yes" wasn't game-ending, but it did mean that a perfect outcome wasn't achievable)

you could have the players somehow ending up at the same point as they where before the wrong decision was made. So they would simply progress *slower* and not *worse*. We play games for having fun and forget than wrong real life decision are irreversible. Since the early days of gaming, players where brought back to where they fail to leave them the possibility of succed in the best possible way. Player want to feel successful in games, want to feel better and have always the opportunity of making the things going better. You could argue that in action/combat game they simply fail if they did not behave better than the opponent/AI, but action/combat games either have a quick rollback option when there is a storyline, or the players simply could start another match to play better and achieve the best performance. Develop the story so that wrong decisions make player waste time and not have things going wrong.

**For example: if the wrong option is to bring an item to the evil dude, after completing the wrong task, a sudden intervention of an NPC hero would rescue the item and bring them safe in the hands of the NPC that issued the task.**

About the XP rewards, you could have wrong option reward X points, and good option reward Y points; if players take the wrong decision they will rewarded X point for that and Y-X when the they take the right one at a later time.

Having players play more time in your game won't make them feel frustrated as having them feel they made something irremediably wrong.

# Answer
> 4 votes
A lot of answers give good ways to indicate to the player the consequences of the action, and guide them in making the choice knowing those consequences. Even doing this, you'll still have players wanting to pick the yes option and watch their NPC face the consequences. *Some people just want to watch the world burn...*

**Make the bad choice unique and interesting (Fail with style)**

Since some players are going to pick the option anyway, you can **make the content worth the mechanical cost**. For an example take Stellaris. If your empire delves into psionics too deeply, you are eventually presented with the option of using your psionics to summon massive powers. You get a huge mechanical boost for 50 years, at which point overpowered enemies will spawn and methodically wipe out all life in the galaxy. The game indicates "DON'T DO THIS" when it gives you the two options. People still pick the second option to see what will happen.

Some ways you might incorporate this into your scenario:

* The NPC gets a cool cutscene. He may be overconfident, but he fought with bravery. Overcoming the complications created will be satisfying knowing you honored his bravery
* The NPC has a falling out with the PC. The failure has affected the relationship with this NPC, and now **he** is the complication as the player tries to continue on the main mission
* The goal is jeopardized. Optional side quest A has now become a mandatory quest in order to save any hope of succeeding. (Could also be an exclusive quest, only available if player chose the bad option)

The main thing is to make it so that the player does not regret their decision, **despite the complications it created**. If you can do this, the choice becomes more difficult, more meaningful, and will make the final victory more sweet.

# Answer
> 3 votes
Train them how cause and effect of choices works in your game. In training, tutorial, instructions, and/or at various points players will encounter when starting to play and learn the game, give them clues, information, and experience about the types of choices and their consequences that will be present in later play, perhaps even with some examples that contradict training your playtesters are showing you they have learned in other games.

You might also want to think carefully about how your experience & reward systems work (for example, you could consider giving an appropriate reward as well as the natural consequence of doing the smart thing).

And you could also consider what the effect of the save game mechanic is on your choices and their effects. Making an unwise decision is much less tempting when you expect to actually be stuck with the consequences as opposed to expecting to be able to be allowed to try anything and then pretend it didn't happen and restore from a saved position with zero consequences.

# Answer
> 3 votes
My first thought is to not present the situation in a yes / no fashion. For instance if the player is already on a quest & needs to arrive on time to complete it, you might present the choices as:

* Option A: tell \[NPC\] that the current mission is too important to jeopardize in favor of doing \[poor choice\]
* Option B: send word to \[quest giver\] that you and \[NPC\] are going to do \[poor choice\] & you are forfeiting the current mission

The second thing I would consider is having prior experiences to guide the player. For instance the first time the player concedes to the NPC maybe the stakes are low & there's a clear, negative consequence. Each subsequent time raise the stakes & on a few occasions, include a bit of flavor text that reflects back on what happened last time. Not only does this provide some clear signalling to the player, but it's also a bit more realistic in that it's common for an accumulation of bad choices to cause progressively bigger problems.

Next, consider having an early example where the player doesn't have a choice. By this, I mean include some narrative beat or plot point in which the clearly demonstrates how deferring to the NPC's poor decision making has an undesirable result. As the designer, you'll need to weigh this option carefully, as taking control away from the player can often leave a bad impression.

Finally, if you plan to offer some sort of new game plus (NG+) option, you could make certain decisions mandatory the first time through, but give control back to the player in subsequent play-throughs. NG+ play-throughs are often intended to offer additional challenges. Allowing the player to opt into a hard experience by deferring to the NPC might be a natural, less contrived way to do that.

# Answer
> 3 votes
Do you have a second NPC with them?

I suggest that the first such decision you offer should be of little consequence. If the player chooses the 'bad' option, and after the harm is done, have the second NPC comment that the decision was kinda stupid.

As an aside, I also suggest that you reward a bit the 'bad' decisions, giving your players a bit of comedy/goofyness for having chosen the 'impulsive' action.

# Answer
> 2 votes
The choice currently looks like this:

* Yes! Let's do some extra stuff I couldn't do otherwise and get back to the normal gameplay afterwards.
* No. Let's skip the extra stuff and do the normal gameplay I could have done anyway.

Who wants to skip out on the extra gameplay that you've programmed in for the player? Who doesn't want to experience as much as possible? Who doesn't want to adventure?

Of course players will pick choice "Yes".

So, what you need to do is make it more like:

* Yes, let's risk the endgame doing this \[extra\] stuff. We won't be able to do \[additional\] stuff though.
* No, let's do \[additional\] stuff instead. Even though we miss the risky \[extra\] stuff at least we get to do \[additional\] stuff.

Originally you had the choice "Do you want to do X and then Y or just Y?"

Now you have the much harder no-right-answer-choice "Do you want to do X or Y?"

Let the player know that picking "No" is going to let them experience gameplay they can't experience if they pick "Yes".

# Answer
> 2 votes
Based on my experience and games like "Until Dawn" or "The Stanley Parable", I learned the "easiest" way to make your players think and decide carefully is to give them choices with "consequences" very early on.

**Attention: Small "Until Dawn" Spoiler**

Like in Until Dawn, you would get early on choices where something "terrible" would happen. When I understood it correctly, there is one spot where you can choose what you want, but these two persons will die no mater what, because they are part of the story. Don't think that any following choice would be just "ehm.. just choose one", but like of "what are the worst possible outcomes for each choice". There also was a point in the game that said "don't move" (the controller), but it somehow bugged and slightly moved upper until it reached the end and counted as movement and two characters just plain died.. (I'm sorry guys). I completely changed my way of "sitting" so I could guarantee that the controller won't move the next time.

**Spoiler End**

It's been a while, but I can remember a bit that in "The Stanley Parable" there were similar choices where one can lead to a.. bad outcome.

So my plan would be to give the player a few choices in the beginning, where choosing "yes" would make the NPC angry or won't let you continue if you choose "yes" the whole time and only let you continue if you also choose "no". Based on your game you could also decide to implement critical questions that will change the following contents by a huge way (like Until Dawn where a character can even die for the whole storyline).

# Answer
> 2 votes
Though not strictly an RPG, Tropico handles this quite well through the character of Penultimo. Early in this game, this character - your closest advisor - will horribly screw up multiple times without your input, and you will feel the consequences. Only later he starts asking permission or providing options for his schemes.

Not only does the above set a precedence for being careful with this guy, but in Tropico specifically they make sure that all options chosen at the very least have a comparable fun factor, so 'bad' consequences don't become as much of a burden through compensation by comedy. In addition, even when he screws up, Penultimo always feels he can turn it around somehow - an attitude which actively prevents reloading behavior.

So, yeah, in short:

1. Set Precedence
2. Reward both paths, but play into different rewards (resources vs comedy, in this case)
3. Make consequences longer-term, so to see it play out reloading is not an option.

# Answer
> 2 votes
Introduce the NPC's terrible character flaws early on with decisions which result in something less permanent or more easily backtracked. You could really have fun with it and write something which would be memorable, teaching the player to consider the downside more carefully and, as a bonus, make the game stand out.

For example...

> The NPC makes an irresponsible boast as to his drinking prowess. He bets he could drink that big fellow over there under the table. Your options are:
>
> * "Go ahead, I dare you!" (for the hell of it)
> * "I'd take that bet" (could earn some coin)
> * "Let's just grab a pint and plan our quest" (essentially no)

If you used either of the "yes" responses, (optional bet amount dialog box) then your companion drinks to the point of blacking out. In your adventures the next day, the NPC will be of varying degrees of uselessness (read: random value from a range based on last night's events).

Possible combat situations? In the midst of battle, he goes to take a turn and instead vomits, inflicting minor damage to himself. You instruct him to use an item on you, but instead...

> "Sure thing, Boss." *hic--!*
> **rummages in sack**
> "...Wait, what was I doing?"

...and/or gives you an item at random instead of what you asked for.

The pub scene above or other similar bad decision making could result in the NPC explicitly ignoring your directions when adventuring.

> *You:* "Okay, we're going right here."
> *NPC:* \*wanders left\*

At that point, you have no choice but to follow him and make sure he doesn't get into trouble.

Essentially just insert situations which firmly establish that always saying "yes" for the sake of the content is *not* the best course of action and could instead hinder your future play options. Gradually ramping up the absurdity of the NPC's decision making prompts or including an insta-death situation (with the option to go directly back to that box, of course) would cement the idea that your decisions have consequences.

# Answer
> 2 votes
One approach would be to have a second NPC who acts as the voice of reason. Then, instead of asking the player to choose between "Yes" and "No," you're asking the player to choose one of two courses of action, one of which is clearly more reasonable than the other.

The advantage to this - that it's the sort of decision players are used to making in RPGs - is also the downside. It's not very exciting, is it?

But here's an alternative:

* Early in the game, the player has to choose to side with the poor-judgement character or a second, more reasonable character. The player can choose either. The path of reason is the obvious right choice, but even if the player chooses wrong, the consequences are fairly minor.
* Later, the choice comes up a second time. It works exactly the same way as before.
* Finally, near the end of the game, there's the big choice you mention. The "voice of reason" character is not present. (Maybe they're dead or otherwise unavailable as a direct result of the impulsive character's recklessness?) And so: the player gets a real Yes/No question! But now, the player has already learned to say no to this particular character - they're used to siding with the voice of reason, but this time they have to step up and *be* the voice of reason, which means overcoming their own FOMO - it's a challenge for the player as well as the character, which ups the ante, but it's a challenge the player was carefully groomed for, hopefully without their realizing it.

Then, once the player says "No," the payoff had better be good. I don't mean a good in-game reward - I mean something exciting and dramatic that makes the player feel they're on the "right course" through the game, so they're not sitting around wondering what they might have missed out on.

# Answer
> 1 votes
Require the player to perform an in-game action other than simply clicking on an option or pressing a button.

Your NPC might say, "I'd like to go on this dangerous quest that will probably get me killed. I need to borrow the trans-dynamic hyper forcefield generator."

To engage in the side quest, the player *must go into their inventory, select the trans-dynamic hyper forcefield generator, and transfer it to the NPC*.

Requiring the user to engage in this extra effort makes the action more meaningful to them, and it emphasizes that *he is doing something out of the ordinary* and that *he could suffer a loss* (obviously with respect to losing the generator, and more remotely losing the NPC).

# Answer
> 1 votes
Late answer, but if you want your players to acknowledge the differences your game has with the "general" case, teach them!

Early in the game, add a choice where \[Yes\] has bad consequences, but non-lasting ones. It could cost them some money to repair what they broke. Or they could be lectured by a guard/policeman about their behavior. As the game progress, add some more cases where the bad consequences increases in intensity or last longer.

It can cost them money, get them to be lectured, get them into a more difficult fight, make them lost a part of the reward, apply a condition on them, hinder them with a temporary debuff... If they already encountered choices where yes have bad consequences, they'll thought more on their following choices.

# Answer
> 1 votes
Make them have to supply the guy.

Companion: Hey boss, I want to do this really stupid thing that will almost certainly make things harder for us down the road and possibly jeopardize our goal. Is that okay?

Player: OK

Companion: OK, I need 4000 fruit, 3200 bolts of cloth, 7 boats, 16 horses, 4 mules, 32 firearms... Gather this for me while I prepare myself!

Player: Forget it!

# Answer
> 1 votes
To add to altskop's comment: (insufficient rep to add directly)

You can build up to this concept gradually as part of educating players as to how your game works. For example: Present an early-game option with a foolish "yes" option. Let them take it, make something obviously bad happen, but let them recover most of the way easily, but to the point where they are *slightly* worse off for the decision, and they know it. Later on, present another foolish "yes" option. If they take it, make it sting, make it really clear that it was directly as a result of their action, it's going to take some effort to recover, and they'll never *completely* recover. By the time the foolish "yes" option comes around a third time, perhaps the crucial one you want to include, your players will understand that saying "yes" to foolish options comes with a price.

Another concept that people tend to be familiar with is the "Are you sure?" option to reconsider a potentially bad action. An NPC suggests something foolish, and the player chooses "yes". At that point another NPC speaks up, strenuously objects to the plan, and the player is presented with a choice that essentially says "Are you sure you still want to proceed with this plan?". Players will generally recognise this last-chance option for what it is, and if they take it anyway, it will have been a deliberate choice.

I hope this helps.

# Answer
> 1 votes
Make the players suffer for their actions. Imagine a quest, where the king sends you to get an elixir from the alchemist far, far away, that will cure his daughter. Later on, when returning with the elixir, the companion might suggest that while you're in the area, you could check out some place that has loads of loot and should be totally unguarded at the moment. If the player decides to check it out, he will find some mediocre loot there, and when coming back home, he will learn that the king's daughter has died because the player was too late with the elixir. From that point on, the player will learn not to always trust the companion and wage the possible benefits of detours vs the primary quest.

# Answer
> 1 votes
In the tabletop RPG, one of the traps that awaits for beginner GMs is not following the rule:

**Don't expect the player to figure it out. Don't expect the player to be smart and use brain.**

The whole game you give him quests. Yes is accept, No is reject. Why would he think that **this particular encounter** is different?

If you want the player to know what the options are, teach it to him. Several times.

You can't expect the player to fear the consequences if he doesn't know they are there. If you always provide player with Yes/No scheme, where saying Yes will benefit them - they won't expect the punishment, even if the very antagonist comes in with an offer to help them kill player's parents.

The game is not a real life. People don't treat their choices like they would in real life. You need to outsmart the players to make them happy. One of the blogs that talk about this is this one.

What are the potential solutions? Varying on what you want to achieve:

* You may want to introduce some quests that punish players to show them that accepting all quests is not desirable.
* You may want to blow the situation out of proportion - make it crystal clear that it's not a good idea to help these guys.
* Drop the choice or make it ilusory. If there is absolutely nothing positive coming out of the other choice, leaving it might not be a good idea after all.
* Consider adding some NPCs or player's friends who will help him by being the voice of reason ("Are we **really** going to rob the bank when we might need Mayor's help later?")

As I said, Tabletop RPG players deal with it all the time, although you have greater control when you're DM. You need to alter the way you present the situation to the player to get satisfactory outcome.

# Answer
> 0 votes
Instead of 'no', offer the choice to do it later when stronger/better equipped/etc. - this makes it clear that the player won't be missing out gameplay/xp, but that this is an unnecessary challenge. You can improve this effect by wording the options appropriately: "Yes - we will be severely outmatched for no significant gain, but I'm up for a challenge!" against "No - we will come back to this when our equipment is more appropriate/we have disabled their defenses/they are asleep/..."

# Answer
> 0 votes
I honestly think that, no matter what you do, players will want to try both options. I would want to see what would happen. The content is there, so I want to see it. Unless you make a bunch of choices where they'd just have to go back and play the game again making the opposite choices, they'll want to save, try the bad choice, and then come back and do the good choice.

So that's my suggestion. Make enough choices where they'll want to just replay the game and try the other choices, rather than feel the need to do it right then.

Either that, or just let them save and try it. They know it's a bad choice, so let them make it to see, while giving them the ability to then go back and do what they really wanted to choose.

---
Tags: game-design, rpg, npc
---


# Question
Title: How do I know the data has arrived at server without requesting every frame of the game?
I have a game where I have to get data from the server but the problem is I don't know **when** the data will become available on server. So I decided to use co-routine and hit server at **after specific time** or **on every frame**. But certainly this is not the **right, scale able and efficient approach**.

Now my question is that **how do I know that data has arrived at server** so that I can use this data to run my game. Or how should I direct the back-end team to design the server in an efficient way that it responds efficiently.

Our back-end team currently uses REST Web services with JSON with Python. And they want to push data to my unity player without my frequent requests.

# Answer
REST is not the right paradigm for bidirectional communication, because with REST you can not send data which wasn't specifically requested. Hammering the server with repeated requests is not a good solution because it generates lots of unnecessary network traffic and still gives you additional delays up to the length of your hammering interval.

But there is a workaround: Long-Polling. The client makes a request and the server artificially delays the response until there is something worth sending.

If you don't want to do long-polling, you might want to use a different technology. When the game is browser-based, then Websockets would be a solution. An established websocket connection allows both client and server to send data at any time.

When your game is not browser-based, then you might want to implement your own protocol on raw TCP or UDP sockets.

You flagged this question with `unity`. When your game client is programmed in Unity, you could use the Unity network system which internally uses WebSockets when you export as a HTML5 application and UDP on most other platforms.
> 7 votes

---
Tags: unity, c#, python, rest, webservice
---


# Question
Title: Can Unreal Engine Blueprints do everything C ++ code can?
Can Unreal Engine Blueprints do everything that C++ code can?

Or are there limitations and some stuff you can't do in Blueprint and only using C++?

# Answer
> 8 votes
No.

C++ functionality in the Unreal engine is exposed to Blueprints explicitly, using macros in the C++ source code to identify functions and types that are Blueprint-accessible. Using that mechanism, the native aspects of the engine are exposed directly or exposed via ease-of-use wrappers to Blueprint.

Therefore there are portions of the Unreal Engine that aren't accessible to a Blueprint which may be accessible to C++ code.

This may or may not be a practical problem depending on what you actually need to do. Low-level rendering and physics APIs aren't directly exposed to Blueprint, for example. If you need to twiddle around in the guts of the engine's functionality via those APIs, you'll want to drop down to C++, either in your game code or even by modifying the engine code directly.

But if you're mainly concerned about higher-level gameplay logic and flow, you can almost certainly do everything you'd want via Blueprints.

---
Tags: c++, unreal-4, blueprints
---


# Question
Title: How to tell when animation is finished playing without events in Unity
I'm using the newest version of Unity. I have a turn based RPG type of game so everything is very sequential. The actor jumps in front of another actor, plays his melee attack animation, then jumps back. Currently I use events on the animation to tell when the attack animation is complete. The 2 side effects of doing it this way are:

1. I have to go into each animation and make an event at the end of them. It would be ideal to NOT have to do this. It would seem I should be able to just check in code if a certain animation is finished playing.
2. The control flow of my attack code becomes awkward. My attack method is a coroutine so I can read it very sequentially and it makes sense. Having this event to tell when the animation is complete ruins that flow. I have to basically make a bool variable and inside my finished event set it, and in my attack function do a while loop after I play the animation checking for that bool variable to change and yielding out until it does. Requiring this event ruins the logical flow of attacks. If I have many animations for whatever reason things get messier.

I noticed the Animator component doesn't have an isPlaying() like some other answers suggested. I think those answers were for older version of unity and older just playing animation clips not using the new Animator component.

There must be a better way to do this.

# Answer
> 3 votes
If you have named all of the attacking states identically, you can check the name of the currently playing animation:

```
//Start animation

//Ensure they are in the "Attacking" state *before* getting to this loop
yield return null;
while (animator.GetCurrentAnimatorStateInfo(0).IsName("Attacking")) {
    yield return null;
}

//Animation has finished

```

Note: that `0` refers to the layer of animation you want to check. If you happen to be on multiple layers (which seems unlikely to me for this type of animation), make sure you are checking the correct one.

Alternatively, you can set the tag on the relevant states, so that you can use `IsTag` instead of `IsName`, and not have to change the name of the states, if that would be a problem.

**EDIT**

It may be necessary to wait for more than a single frame before `GetCurrentAnimatorStateInfo` returns the "Attacking" state. In that case, you may wish to replace the first `yield return null` with its own loop:

```
//Start animation

//Wait for them to enter the Attacking state
while (!animator.GetCurrentAnimatorStateInfo(0).IsName("Attacking")) {
    yield return null;
}

//Now wait for them to finish
while (animator.GetCurrentAnimatorStateInfo(0).IsName("Attacking")) {
    yield return null;
}

```

# Answer
> 2 votes
My answer is based on events.... But not on events inside Animators clips!

You have the possibility to attach scripts to Mecanim's states if you want to know when the control flow is entering / leaving your state. For example :

```
using UnityEngine;
using System.Collections;

public class MyAnimatorState : StateMachineBehaviour
{
    public delegate void MyEvent(bool entering);
    public event MyEventHandlerHandler MyEvent;

    override public void OnStateEnter( Animator animator, AnimatorStateInfo stateInfo, int layerIndex )
    {
        if ( MyEvent != null )
            MyEvent( true );
    }
    override public void OnStateExit( Animator animator, AnimatorStateInfo stateInfo, int layerIndex )
    {
        if ( MyEvent != null )
            MyEvent( false );
    }
}

```

Then, in a script attached to your gameObject :

```
public Animator animator ;
private MyAnimatorState animatorState;

private void Start()
{
    // Don't call this line in Awake, it won't work
    animatorState = animator.GetBehaviour<MyAnimatorState>();
    animatorState.MyEvent += ( entering ) => { Debug.Log(entering) ; };
}

```

Source : https://unity3d.com/fr/learn/tutorials/modules/beginner/5-pre-order-beta/state-machine-behaviours

---
Tags: unity
---


title: Different Behaviour between ++ and += 1

text:
# Question
Title: Different Behaviour between ++ and += 1
```
void AddItem(Item item)
{
    int indexOfDuplicateItem = System.Array.IndexOf(itemsInInventory, item);

    if (indexOfDuplicateItem > -1)
    {
        quantityText.text = (stackSize[indexOfDuplicateItem] += 1).ToString(); // Problem occurs here
    }
    else
    {
        for (int i = 0; i < numSlots; i++)
        {
            if (itemsInInventory[i] == null)
            {
                itemsInInventory[i] = item;
                GameObject itemImage = Instantiate(itemImagePrefab, slots[i].transform);
                itemImage.GetComponent<Image>().sprite = item.itemSprite;
                quantityText = slots[i].GetComponentInChildren<Text>();
                stackSize[i] = item.itemQuantity;
                quantityText.text = stackSize[i].ToString();
                return;
            }
        }
    }

```

The indicated line behaves differently if I write `quantityText.text = (stackSize[indexOfDuplicateItem]++).ToString();`

I'm a relative beginner to both C# and Unity. Can someone explain why the behaviour of `(stackSize[indexOfDuplicateItem]++).ToString()` is different from `(stackSize[indexOfDuplicateItem] += 1).ToString()`?

using += 1 to increment behaves correctly, but ++ ends up being the correct answer - 1.

# Answer
This is expected behaviour given the usual syntax for `++`, which has been around since the language B (circa 1969):

* `variable++` is a **"post-increment" operator**, ie. "Return to me the current value of the variable, then increment that variable *afterward*"

So an expression containing this construct gets evaluated with the *old* value of the variable, before it was incremented.

This is useful in a loop where you want to ensure the *next* use of a variable is incremented, eg...

`int p = 0;
for(y = 0; y < height; y++)
 for(x = 0; x < width; x++)
 pixel_buffer[p++] = GetPixelColor(x, y);`

This loop will write to pixel\_buffer\[0\] first, then each subsequent index in turn.
* `++variable` is a **"pre-increment" operator**, ie. "Increment the value of the variable *before* returning it, then return to me its new value"
* `variable += 1` is an (augmented) **assignment expression**. When it's evaluated, the whole expression gets run (incrementing the variable), then the resulting value of the variable is treated as its return value. So it behaves similarly to `++variable`
> 3 votes

# Answer
This is most likely because of how the `++` operator works. The `++` operator works in two steps:

1. Returns the value if the variable
2. Increments the variable

This means that when you do `stackSize[indexOfDuplicateItem]++` it first returns `stackSize[indexOfDuplicateItem]` THEN increases the value by 1. It's the same as writing this:

```
quantityText.text = (stackSize[indexOfDuplicateItem]).ToString();
stackSize[indexOfDuplicateItem] += 1

```

This is a small test case:

```
>>> int i = 5;
>>> Console.Write(i)
5
>>> Console.Write(i++)
5 // STILL 5!
>>> Console.Write(i)
6 // Now 6!

```

To circumvent this you could put the `++` *before* like so: `++stackSize[indexOfDuplicateItem]`. This will increment the value by 1 and then return the value. This should give the desired result.
> 2 votes

# Answer
Consider the following:

```
int i = 0
strings[] myArray = ["a","b","c","d"];

...

Debug.Log(myArray[i++]); // Evaluates i first, which is zero -> log = "a"
                         // Then add 1 to i

Debug.Log(myArray[i++]); // Evaluates i first, which is 1 -> log =  "b"
                         // Then add 1 to i

```

Now we can also do ++ on the left side

```
int i = 0
strings[] myArray = ["a","b","c","d"];

...

Debug.Log(myArray[++i]); // add one to i first, then evaluate i -> log =  "b"

Debug.Log(myArray[++i]); // add one to i first, then evaluate i -> log =  "c"

```
> 1 votes

---
Tags: unity, c#
---


# Question
Title: How to implement a button when the player is in the trigger
I have implemented this code and it works but i wanna make this work only if i enter the trigger and press the UI button. Right now it is changing scene automatically so, i want to press the button and then change scene. I know how to do this for PC game but not on Android game. I hope you can give me a hand.

**Script**

```
public class ButtonScript : MonoBehaviour {

    //public Button btn;
    private bool door = false;
    public bool hasCollided = false;

    public void Update () {

        if(door == true){
            SceneManager.LoadScene("InventoryScene");
            //SceneManager.LoadScene ("Scene1AToBathW");
            //Application.LoadLevel("Courtyard1F");
            //gameObject.transform.position = new Vector3(x,y,z);
        }

    }

    public void OnTriggerEnter(Collider other){
        if(other.tag == "Player"){
            //btn.gameObject.Setactive(true);
            door = true;
            hasCollided = true;
        }
    }

    public void OnTriggerExit(Collider other){
        if(other.tag == "Player"){
            //btn.gameObject.Setactive(true);
            door = false;
            hasCollided = false;
        }

    }

}

```

# Answer
```
    bool xx= false;
public void OnTriggerEnter(Collider other)
{
        xx= true;
}
public void OnTriggerExit(Collider other)
{
xx=false;
}
void mybutton()
{
if(xx) changeScene();
}

```

so call mybutton with your UI button. buttons work the same in phone like pc
> 0 votes

---
Tags: unity, c#
---


# Question
Title: Wait until continuing inside a function with a coroutine in Unity
I have a base class called Ability and then children classes for each ability like BasicMeleeStrike. I have a turn based game so the Do() method of each ability does it's logic sequentially. I'm trying to make coding a little nicer looking in each child ability class and I want to not have to yield out from in them but call base class functions that will do the operations over time but I want them to wait until they come back to the child class Do() function but what I have doesn't work. Is this possible?

```
class Ability{
   public virtual IEnumerator Do(Actor target){}
   protected IEnumerator JumpToTarget(Actor target){
      yield return StartCoroutine(_JumpToTarget(target);
   }
   private IEnumerator _JumpToTarget(Actor target){
      // inside here I tween to a location so it's yielding return null until it's done
   }
}

class BasicMeleeAttack : Ability{
   public override IEnumerator Do(Actor target){
      JumpToTarget(target);
      anim.Play("attack");
   }
}

```

No jumping happens but the attack animation plays. When I put a breakpoint on anim.Play() it's hit right away. Is there a way to make it stay inside JumpToTarget(target) until it's finished without having to do a yield inside BasicMeleeAttack's Do() function? I just think it's much friendlier to not have to code that for all my actions.

# Answer
> Is there a way to do this without StartCoroutine()?

Sure, you can step the `IEnumerator` manually.

```
var nestedRoutine = JumpToTarget(target);
while(nestedRoutine.MoveNext())
    yield return null; // Wait a frame and check again next time.
                       // Note that this ignores what nestedRoutine yielded!
                       // If it's waiting on a WWW to download, and we don't
                       // handle that case ourselves, we'll pump it too early.

// Execution resumes here once JumpToTarget finishes all its work.

```

But this seems like substantially more work than just

```
yield return StartCoroutine(JumpToTarget(target));
// Execution resumes here once JumpToTarget finishes all its work.
// This correctly handles all yield return types that Unity accepts,
// since we're letting the Unity engine handle the yielding logic.

```
> 2 votes

---
Tags: unity
---


# Question
Title: Moving inventory items around causes reference problems
I'm in the process of implementing an inventory system in my game.

The script which is most important to this question is InventorySlotManager.

```
public class InventorySlotManager : MonoBehaviour
{
    ItemData itemData;

    const int numSlots = 20;
    Item[] itemsInInventory = new Item[numSlots];
    [SerializeField] GameObject[] slots = new GameObject[numSlots];
    [SerializeField] GameObject itemImagePrefab;
    int[] stackSize = new int[numSlots];

    void Awake()
    {
        itemData = GameObject.Find("Item Manager").GetComponent<ItemData>();
    }

    void Start()
    {
        AddItem(itemData.coin);
        AddItem(itemData.silverRing);
        AddItem(itemData.coin);
    }

    void Update()
    {
        if (Input.GetKey(KeyCode.Alpha1))
        {
            AddItem(itemData.coin);
        }
        if (Input.GetKey(KeyCode.Alpha2))
        {
            AddItem(itemData.silverRing);
        }
    }

    void AddItem(Item item)
    {
        int indexOfDuplicateItem = System.Array.IndexOf(itemsInInventory, item);

        if (indexOfDuplicateItem > -1)
        {
            Text quantityTextOfDuplicateItem = slots[indexOfDuplicateItem].transform.Find("Item Image(Clone)").gameObject.GetComponentInChildren<Text>();
            quantityTextOfDuplicateItem.text = (++stackSize[indexOfDuplicateItem]).ToString();
        }
        else
        {
            for (int i = 0; i < numSlots; i++)
            {
                if (itemsInInventory[i] == null)
                {
                    itemsInInventory[i] = item;
                    GameObject itemImage = Instantiate(itemImagePrefab, slots[i].transform);
                    itemImage.GetComponent<Image>().sprite = item.itemSprite;
                    Text quantityTextOfNewItem = slots[i].GetComponentInChildren<Text>();
                    stackSize[i] = item.itemQuantity;
                    quantityTextOfNewItem.text = stackSize[i].ToString();
                    return;
                }
            }
        }
    }
}

```

This does what you'd expect. (The bit in Update is just there temporarily for testing.) When an item gets added, the function checks to see if one already exists in the items array. If not, then the for loop is executed and the item is added to the items array, an item image game object is instantiated in the corresponding index of the slots array, etc. So far so good, everything behaves properly until I start dragging items around in my DragHandler script.

So I press play, my inventory has two kinds of objects in it (coin, and silver ring). They each display their correct quantities (stack sizes) as I keep adding items. Then, I move the coin from slot 0 to slot 5 and attempt to add more coins to the inventory. It stops working because the line `Text quantityTextOfDuplicateItem = slots[indexOfDuplicateItem].transform.Find("Item Image(Clone)").gameObject.GetComponentInChildren<Text>();` returns null at that point.

What is the best way to fix this such that this reference won't become null if I move the item to a different slot after it gets added to my inventory? I think I either have to map the items array to the slots array or store all of these values, e.g., items, slots, quantitytext, in one array. Is this correct?

# Answer
> 1 votes
The first thing is to break down your lines when you have Find() queries, array accesses, and other things that could be null so you can know which part causes the null reference:

```
Transform slotTransform = slots[indexOfDuplicateItem].transform;
Transform foundTransform = slotTransform.Find("Item Image(Clone)");
Text quantityTextOfDuplicateItem = foundTransform.gameObject.GetComponentInChildren<Text>();

```
* `slots[indexOfDuplicateItem]` could be null
* `slotTransform.Find("Item Image(Clone)")` could return null

I suspect some of your objects are not named exactly **"Item Image(Clone)"**.

---

It's also better to avoid using `Find()` when you can.

To do this save `itemImage` in a class or struct, as well as `slot`, `stackSize` and any other information you may want to manage per inventory slot.

```
public struct InventorySlot
{
   public Item item = ??? enum or class ???;
   public int stackSize = 0;
   public GameObject gameObject = new GameObject();
   public Image image = null;
   public Text text = null;
};

InventorySlot[] inventorySlots = new InventorySlot[numSlots];

```

This will make it a lot easier to manage your arrays.

You probably also want to use a combined stack+item struct instead so you can manager stacks better.

For example you can create a function to split a stack:

```
public struct ItemStack {
    public Item item = ???;
    public int stackSize = 0;

    // return a new stack which is 1/x th of this stack. (eg: with 4: return 1/4, this stack keeps 3/4) default is two halves.
    public ItemStack SplitIn(int divider=2)
    {
      ItemStack r = new ItemStack();
      r.item = item;
      r.stackSize = (stackSize + divider - 1) / divider; // round up
      stackSize -= r.stackSize; // remove form current stack
      return r;
    }
};

```

---
Tags: unity
---


# Question
Title: In AGK2 Basic, how would I attach a camera to the player charater?
I've started making a game in AppGameKit and I'm using Tier 1/AGK2 Basic. I'm trying to make a sort of endless runner. I've made it so that the player stays still and the rest of the world moves around them to create the illusion that the player is what is running forward. I then use a global variable to control all movement relative to the player.

There must be a better way to do this, though. Like if I were to attach a camera to my player character. How would I do something like that?

# Answer
A 2D or a 3D game?

I would not move the world: it's messy. You would not only have to move the scene, but also the non player objects in it.

Instead I would move the player.

Every frame, I would update the camera so that it is always behind the player.

Looking at AppGameKit, it has a method `SetCameraPosition()` and `SetCameraLookAt()`.

Just get the player object's position and direction it is facing. Then place the camera a certain distance behind, above, and optionally left/right of the player. And point the camera at it.

You can link the camera hard, this way. Or add a little softening in it by blending the desired and current camera position so that it will lag a little when player starts running faster.
> 0 votes

---
Tags: sprites, camera
---


# Question
Title: Subdivided Icosahedron Hex/Pent grid efficient rendering?
How to performantly display a hex/pent grid on a subdivided icosahedron?

I have a subdivided icosahedron planet used as the "board" for a strategy game. It usually has anywhere between a few thousand and a hundred thousand tiles depending on the size the user inputs to the map generator.

Basically, I cannot brute force this and do a simple bounds and depth check, because of the sheer numbers of tiles.

I am storing the grid in a 2D array for simplicity. I understand that, on a 2D map, you simply do something like the following to draw a hex map:

```
for(int x = cameraX; x < viewportWidth; x++)
{
    for(int y = cameraY; y < viewportHeight; y++)
    {
        if(x % 2 == 0) //For the 2D array to work properly we have to offset every other row by +1 world coordinate (assuming each tile is 1*1 world coordinates)
           grid[x][y].render(x+tile_width, y);
        else
            grid[x][y].render(x, y);
    }
}

```

And that to draw a wrap-around world you would check the absolute distance from the camera's position.

Eg:

```
//This sets up the variable that tells the game what hex tiles to draw.
if(camera.x - viewportWidth < 0)
{
    camera_rX = camera.x - viewportWidth;
    cameraX = grid.length + camera_rX; //We will add this to the cameraX value because the result should be a negative value if the prerequisite if statement is met. The "cameraX" variable is used for viewing calculations, while the "camera.x" variable is used for camera positioning. Err... I think this makes sense.
}

```

# Answer
> 2 votes
First question that comes to mind: does the hex-planet change a lot during gameplay? If the planet is mostly static, and just the inhabitants on it move around a lot, I would definitely not render the tiles separately.

I've made a hex-planet game myself. And in this game the planet is just two draw calls, one to draw its faces, and one to draw the edges.

This way I don't have to iterate over the tiles to render them.

For the stuff on top (trees, rocks, etc) I use instanced-rendering, so that in one drawcall, all pine-trees e.g. are rendered in a single go. I am not sure what you are using for rendering (question tags don't mention a render system), but if it is OpenGL or OpenGLES3 then look into `glVertexAttribDivisor()` and `glDrawArraysInstanced()`.

It gets trickier if the tiles change a lot during gameplay. Let's say you frequently change the colour of the tiles in the world. Then I would still have a single VBO to represent the entire planet, and just update that VBO every frame with the correct colours before rendering, as described above.

---
Tags: libgdx, mathematics, rendering, tilemap, hexagonal-grid
---


# Question
Title: Don't know what to do with XML file and Spritesheet (Swift 3)
I'm new to spritesheets and game development in general. I have two files: 1) a .png spritesheet with tons of sprites and 2) a companion XML file with coordinates, anchor points, image names, and animation info.

The spritesheet appears to have no order, and I cannot make sense of the organization of the XML file (which does not appear to contain the dimensions of the seemingly different-sized sprite images)

My question is: How do I use these to make sprite animations? It appears the work has been done for me, but I have no idea how to use it.

In particular, I would like to use this with Swift 3 SpriteKit.

I would be satisfied with exporting all the sprites into separate images with the appropriate names. Is that possible? Thank you for your help!!

# Answer
> 0 votes
While I was testing with my sprite sheets in unity3D , i had similar problem, but the xml had only co ordinates to the sprites and none were animated. the link below was referred for the scripting and handling, so it might come in handy for your reference too.

Link To the tutorial

But I am not sure how the same thing can be handled with Swift 3 , but if this method works fine , there might not be a necessity of the SpriteKit.

Cheers,

---
Tags: spritesheet, xml, spritekit, swift
---


# Question
Title: pre-load new scene in unity async but don't show it
I have a top down dungeon crawler in 3D where I show one room at a time. Each room is it's own unity scene. Each room has an exit point that when clicked I fade the screen, load a new scene and then fade in the screen. What I'd like to do, but not sure how, is to pre-load the next possible scenes (note the S, there will be 2 but could be more. 2 because it's the next room or the previous if the player decides to go back) while in one scene. I know the scenes that are possible to get to, but how can I pre-load but not show them and because there is more than 2, I assume if they go in one direction, there is a pre-loaded one that I need to unload. Overall I want to do this to make a faster/smoother transition between rooms, but I want the one room at a time for artistic style.

# Answer
> 2 votes
1. Parent everything in each room's scene to one (or a few) root GameObject(s) that can serve as a point of reference for the room as a whole.
2. Place a script on these roots with an `Awake()` method that switches off its own GameObject using `gameObject.SetActive(false);` \- Now as soon as the room is loaded, it will disable its own rendering & gameplay before it has a chance to affect anything or appear on screen.
3. When it's time to show that room, re-enable its root object(s) with `gameObject.SetActive(true);`

Your roots' `Awake` methods can register them with the corresponding exit points from the main room, so they're easy to find when you need to show them or unload them.

---
Tags: unity
---


# Question
Title: Determining and Re-Considering Trapped Targets when Path-finding
I have a game that has multiple path-finding agents (A\*) with a grid based map. The player can change the map by constructing walls, floors etc. and the agents will move to construct what the player has requested. I call the tasks that an agent will move to complete build tasks.

I have implemented a simple distance heuristic for when the agent is deciding which build task to pursue. Since there can be 100's of build tasks in the game at any one time, it's not really possible, as far as I can discern, to do a flood-fill to check if the task is reachable for a particular agent before doing a path-finding exercise.

At the moment, if an agent struggles to find a path to a task (for example, imagine the player has surrounded the agent with walls so it cannot escape a room), the task is stored as something that cannot be reached and a new item is looked for. I also flood-fill from the task and maintain a region which contains the task so that any other tasks in this area are not considered.

My problem is, **how can I determine when an item can be released from the cannot-be-reached store or when the locked region can be cleared from consideration?**

I though about doing some sort of timed expiration so that an item that cannot be reached will eventually be re-considered but this solution has several problems. Another idea I had was to path-find from the target to the agent every so often and if a new path is possible, clear the item and let it be re-considered. Neither of these solutions seem optimal and I feel I am missing something obvious...

Here is a rather lacking diagram of the problem I am trying to convey.

# Answer
Break your graph up into connected components *(See also)*.

*(Image source)*

This will have a high initial cost, but recomputation is cheap: when a wall is added, check if it disjointed a connected component; when a wall is removed, check if it connected two-or-more disjointed components. Then to check if one tile can be reached from another, just check if they're in the same connected component. You only need to recheck a "trapped" target when it's part of a component that was just connected to another.

Another option, which would also help with quickly finding the path once you know it exists, would be to use HPA\*.
> 2 votes

---
Tags: game-design, ai, path-finding, terrain, grid
---


# Question
Title: Highlighting shader but using touch points/mouse
I have done the following highlighting shader using GLSL. What I want to do is getting the mouse coordinates and "start" the highlighting from that point. is that possible ? What's the math or the idea behind doing that ? https://youtu.be/8etJho4agpg

# Answer
In the vertex shader (or on the CPU) what you'll want to do is transform your screen space coordinate into an object space coordinate. Or you could use a ray trace, tracing a ray from the screen point out of the camera, so that it hits the geometry and returns that point in world space (which you can easily turn into object space in your vertex shader) see https://docs.unity3d.com/ScriptReference/Camera.ScreenPointToRay.html for what I mean (I know your not using unity but it explains it better). Once you have this point then in the fragment shader subtract (or add) this point to the vertex position/uv used to calculate the highlight and it should make it expand out from the mouse.
> 1 votes

---
Tags: shaders, glsl
---


# Question
Title: How to render a bevel effect with SDL2 Texture?
I develop 2D games using CodeBlocks (C++) with SDL2.

I can load a texture (ex. a gray square) and render it to the screen. All is fine. If I want to change the color of the square? Yes, I can do it. I can rotate too, without an issue.

But here's what I'd like to know:

I'd like to render the square border with a bevel effect. This is for displaying icons on the screen: I'd like to avoid having to load 2 images, one for the icon picture (with a transparent background) and one for the bevel; I'd like to add the bevel effect on some parts, dynamically in the program.

How can I do it?

# Answer
> 0 votes
One way to do this is to generate a signed distance of each pixel from the edge. You can then use the distance as a height. You can clamp the heights to a maximum which will give you a flat area in the middle. Valve Software published a paper that shows a clever way of generating the signed distance field using small textures, and it might work for you also.

# Answer
> 0 votes
Do you write your own shaders for your game? If so, your fragment shader can just modify the texel from your image, based on which edge it is closest to, and how close that is.

Here's a sample I wrote in shadertoy that does just this.

It just scales up or down the RGBA based on the edge identified as closest.

Doing it in a shader saves you from having to composite your image with a bevelling overlay.

---
Tags: c++, sdl2
---


# Question
Title: Does Apple allow different versions of the same game on the App Store tailored for different regions?
We are currently in negotiations with a Chinese company to give them the right to re-sell our game in the Asia region.

Now for the Android version they want to sell it trough their website because they want to utilize China specific payment systems. This can be easily achieved by adding an activation system to the app and generating keys for the users who paid.

My problem is with the iOS version. As far as I know there is no way to install an app on iOS outside the app store environment without having a jailbroken phone. Can I just give them the archive of the app from XCode and have them upload it trough their own app store account? Will this cause a problem with Apple that basically the same app will be on the store twice with a different bundle ID?

# Answer
> 0 votes
The literal answer to your question is probably yes. I’ve had multiple versions of an app on the App Store (one paid, one free).

If you are trying to bypass the App Store in any fashion, the answer is no.

---
Tags: ios, appstore
---


# Question
Title: Single handler vs multiple handlers for the Command Pattern
I'll be soon implementing for the first time a Command pattern to catch general events about the world of the game I'm developing

Since I haven't found much info about this particular issue, I'm asking if it makes more sense to have a single 'catch-all' class which will eventually process any type of event or to offload events to different types of Queue

e.g. player related Commands will be offloaded to the Player class, enemies related commands will be offloaded to the Enemies class, and world/terrain related commands (such as chunk creation) will be handled by WorldGen

Normally, this would break the idea of having a 'receiver' object as a constructor parameter of an instance of a Command, but does having just a single 'catch-all' class more maintainable than partitioning the command handlers?

Is it maintainable in a convoluted game to have just a single catch-all class to execute every type of Command? Wouldn't it be easier to optimize the usage of more threads by having different command handlers?

# Answer
A single handler would have a lot of dependencies, where as multiple handlers can be better compartmentalized.

Personally, I take it one step further, and make the handlers non-exclusive: events may have zero, one or multiple handlers listening for it.

If you make a system where handlers can subscribe to messages, then a single event (e.g. a hand-grenade going off) can generate responses from different parts of the game.

* The sound system may catch that event, and play a loud boom.
* A damage system may catch it and look for damaged players.
* A particle system may catch it and generate a flash and smoke.
* The leaderboard/achievement system may catch it, and unlock the achievement "Grenade"
* etc.

Set it up so that the event-generator does not need to know about any subscribers. The event is just generated. How many listeners there are, if any, is of no concern to the code that generated the event.

This creates nice code with few dependencies, because the code where a grenade is made to explode, does not have to depend on particle-system code, sound-code, or any other code that gets triggered via one or more handlers.

Because subscriptions are optional, it also means that if, for instance in debug runs, a system is not brought up, everything still keeps working. There are just fewer handlers listening to the event. You can run without the leaderboard-achievement system, or without the sound system, and nothing would break when a grenade explodes.
> 3 votes

---
Tags: game-design, architecture, design-patterns, patterns
---


# Question
Title: Unity graphics lagging and leaving a trail
The following are pictures of what I am describing. This happens both when I have normal lighting, graphics on low, render distance on short. I have a graphics card that can run games like Starcraft II easily. It appears to be the top of the screen that is most often affected by this lag. The lag is also seen on terrain. It happens when I build and set quality to low as well. Even if I change the camera angle. Camera movement is irrelevant. Although I am using position to make the camera not momentum. Any idea what might be causing this?

And the following is what it cuts to when the renderer catches up:  **It only appears when the background is either not rendered, or very far in the distance.**

Yes I have tried restarting unity, yes I have restarted my computer.

Here is the image with the camera settings:

# Answer
> 2 votes
The problem is that I changed the Skybox to a black material that is not a "Skybox" even though it works. Never again will I ignore warnings:

---
Tags: unity, rendering, graphics
---


# Question
Title: Collision Resolution of Axis-Aligned Bounding Boxes that Change Size
I am developing an action platformer in Python, with Pygame. That said, my question is a general one about collision resolution strategies.

I use an axis-aligned bounding box for the purposes of collision detection. The bounding box changes sizes depending on the sprite's action and the frame of the action's animation.

When I update my sprite's position, I first update the y-coordinate, check for and resolve collision in the y-direction, then do the same for the x-coordinate. When I resolve collision, I simply move the bounding rect's sides to align flush with the appropriate walls.

Because the bounding rect changes sizes throughout my animations, I am noticing buggy behavior in certain situations when the frame moves from a smaller one to a larger one. The change of frame results in the sprite intersecting a wall and his position is resolved such that he falls off the map.

Here is a diagram illustrating the problem:

It doesn't matter whether I resolve in the x-direction or the y-direction first. They result in reciprocal buggy behavior when the next frame is wider or taller, respectively.

My question concerns general collision resolution strategies for axis-aligned bounding boxes that change size and shape. **What are the best algorithms for collision resolution that avoid this issue?**

Here are some of the functions and values I have access to:

* colliderect -- tests if two rectangles collide
* collidepoint -- boolean that tests if a point collides with a rectangle
* rect.topleft, rect.topright, rect.bottomleft, rect.bottomright, rect.center, rect.centerx, rect.centery -- various points on the rectangles
* rect.left, rect.right, rect.top, rect.bottom -- values for the sides of the rects
* various vectors
* in short, the usual stuff

Apologies if this question is a dupe. I imagine it is a pretty common one, though I couldn't find anything that helped me specifically.

# Answer
In brief there are two ways of doing this. Both are relatively fast and simple to run.

**Method 1**
If the AABB (axis aligned bounding box) changes every frame because of animations, then you can simply wait until after the sprite has been moved and the next frame of the animation has played before resolving the collisions

```
def MainLoop():
  #Update the position
  rect.center = rect.center + velocity

  #I don't know how you are doing your animations, but play the next frame here
  Animate.PlayNextFrame()

  #Now you want to check for collisions as normal now that everything has moved in the frame we can check for collisions once
  CheckCollisions()

```

This means that the collision detection occurs only once animation and the movement has occurred. This prevents the need to do collision detection more than once per frame **and** takes the animation into account.

**Method 2**
Make a dummy aabb for collision detection that follows the main character which has a fixed size. This will occasionally result in some minor intersection between the character and the wall but in most cases it looks fine.
This is also relatively easy to implement and very fast to run.
> 1 votes

# Answer
**You probably don't want to change the sizes of your bounding box.**

Even if it works correctly, you'll an issue where players will "move" without player input:

This makes the controls feel slippery and inaccurate .

While you can change bounding boxes safely in some cases, for the average case you'll want to keep the bounding box the same size. Usually, small amounts of sprite overlapping looks fine, as long as it's on the Y axis (See Legend of Zelda the Minish Cap). If you're still intent on changing the size of the box, I would recommend a second check to see if your new animation frame *also* doesn't collide with any walls.

The pseudo code would look something like this:

```
def CollisionPreCheck(rect,wall):
  theta = 0.001
  if(collidePoint(rect.centerx + (rect.width / 2), wall))
    rect.centerx = rect.centerx + (rect.width / 2) + (wall.width / 2) - theta;
  if(collidePoint(rect.centerx - (rect.width / 2), wall))
    rect.centerx = rect.centerx - (rect.width / 2) - (wall.width / 2) + theta;
  if(collidePoint(rect.centerY + (rect.height / 2), wall))
    rect.centerx = rect.centerY + (rect.height / 2) + (wall.height / 2) - theta;
  if(collidePoint(rect.centerY - (rect.height / 2), wall))
    rect.centerx = rect.centerY - (rect.height / 2) - (wall.height / 2) + theta;

```

What we're doing here is a second collision resolution phase. If any of the points are colliding, I just bump the center point back, so that it looks like you're still touching the wall. I'm assuming that no point will have changes too drastically from the last time we've checked, and that your geometry won't be too complex. A major way that this can break is if the wall is too thin, which will cause the rect to teleport to the other side of the wall.

**However, what I recommend, is to split the idea of a character into physics and visual parts.**

The visual part will simply teleport to the location of the physics object every single frame, after you've handled movement. This lets you play with other cool visual effects - see juice it or lose it \[ https://www.youtube.com/watch?v=Fy0aCDmgnxg \] for an idea of what I mean. Many of the techniques they describe are far easier once the gameplay and visuals are separate.

When using this technique, you are accepting a small amount of sprite overlap. In my experience players usually don't notice. If they do you'll want to either make the animation less dramatic, or use the method I outlined above.
> 1 votes

---
Tags: collision-detection, python, collision-resolution, pygame, bounding-boxes
---


# Question
Title: Use Unity Handles for interaction in the scene view
I want to give an object with a specific script arrows to do special functions in the scene view. I have gotten Unity to render the arrows but I have no idea how to actually handle mouse events. The docs appear to say that I should be able to identify what receives a mouse down event by calling `HandleUtility.nearestControl` however when clicking on different arrows in the scene view I get the same ControlId (which i'm guessing is the gameobject itself). How are you supposed to know/deal with mouse events properly?

Code:

```
[CustomEditor(typeof(Script))]
class SceneGui : UnityEditor.Editor
{
    void OnSceneGUI()
    {
        if (Event.current.type == EventType.Repaint)
        {
            Transform transform = ((Script)target).transform;
            {
                Vector3 pos = transform.position + Vector3.left * 2;
                Handles.color = Color.yellow;
                Handles.ArrowHandleCap(3000, pos, Quaternion.LookRotation(Vector3.left),
                    2, EventType.Repaint);
            }

            {
                Vector3 pos = transform.position + Vector3.right * 2;
                Handles.color = Color.red;
                Handles.ArrowHandleCap(3001, pos, Quaternion.LookRotation(Vector3.right),
                    2, EventType.Repaint);
            }

            {
                Vector3 pos = transform.position + Vector3.forward * 2;
                Handles.color = Color.blue;
                Handles.ArrowHandleCap(3002, pos, Quaternion.LookRotation(Vector3.forward),
                    2, EventType.Repaint);
            }

            {
                Vector3 pos = transform.position + Vector3.back * 2;
                Handles.color = Color.cyan;
                Handles.ArrowHandleCap(3003, pos, Quaternion.LookRotation(Vector3.back),
                    2, EventType.Repaint);
            }
        }
        else if (Event.current.type == EventType.mouseDown)
        {
            Debug.Log(HandleUtility.nearestControl);
        }
    }
}

```

# Answer
> 2 votes
It turns out that you need to call the `Handles.ArrowHandleCap` function with the `EventType.Layout` in the relevant `Event.current` slot. So with that you call the same function again and that will do all of the click calculations for you.

For the control ID you should also use `GUIUtility.GetControlID(FocusType.Passive)` as that will give you a temporary id that is valid and won't clash with other stuff.

```
[CustomEditor(typeof(Script))]
class SceneGui : UnityEditor.Editor
{
    private const int arrowSize = 2;
    private const float CenterOffset = 3f;

    private int leftId, rightId, forwardId, backId;
    private Transform trans;
    private bool cached = false;

    private Direction selectedDirection = Direction.none;

    void OnSceneGUI()
    {
        if (!cached)
        {
            trans = ((Script)target).transform;

            leftId = GUIUtility.GetControlID(FocusType.Passive);
            rightId = GUIUtility.GetControlID(FocusType.Passive);
            forwardId = GUIUtility.GetControlID(FocusType.Passive);
            backId = GUIUtility.GetControlID(FocusType.Passive);

            cached = true;
        }

        if (Event.current.type == EventType.Repaint)
        {
            {
                Vector3 pos = trans.position + Vector3.left * CenterOffset;
                Handles.color = selectedDirection == Direction.west ? Color.magenta : Color.yellow;
                Handles.ArrowHandleCap(leftId, pos, Quaternion.LookRotation(Vector3.left), arrowSize, EventType.Repaint);
            }

            {
                Vector3 pos = trans.position + Vector3.right * CenterOffset;
                Handles.color = selectedDirection == Direction.east ? Color.magenta : Color.red;
                Handles.ArrowHandleCap(rightId, pos, Quaternion.LookRotation(Vector3.right), arrowSize, EventType.Repaint);
            }

            {
                Vector3 pos = trans.position + Vector3.forward * CenterOffset;
                Handles.color = selectedDirection == Direction.north ? Color.magenta : Color.blue;
                Handles.ArrowHandleCap(forwardId, pos, Quaternion.LookRotation(Vector3.forward), arrowSize, EventType.Repaint);
            }

            {
                Vector3 pos = trans.position + Vector3.back * CenterOffset;
                Handles.color = selectedDirection == Direction.south ? Color.magenta : Color.cyan;
                Handles.ArrowHandleCap(backId, pos, Quaternion.LookRotation(Vector3.back), arrowSize, EventType.Repaint);
            }
        }
        else if (Event.current.type == EventType.layout)
        {
            {
                Vector3 pos = trans.position + Vector3.left * CenterOffset;
                Handles.ArrowHandleCap(leftId, pos, Quaternion.LookRotation(Vector3.left), arrowSize, EventType.layout);
            }

            {
                Vector3 pos = trans.position + Vector3.right * CenterOffset;
                Handles.ArrowHandleCap(rightId, pos, Quaternion.LookRotation(Vector3.right), arrowSize, EventType.layout);
            }

            {
                Vector3 pos = trans.position + Vector3.forward * CenterOffset;
                Handles.ArrowHandleCap(forwardId, pos, Quaternion.LookRotation(Vector3.forward), arrowSize, EventType.layout);
            }

            {
                Vector3 pos = trans.position + Vector3.back * CenterOffset;
                Handles.ArrowHandleCap(backId, pos, Quaternion.LookRotation(Vector3.back), arrowSize, EventType.layout);
            }
        }
        else if (Event.current.type == EventType.mouseDown)
        {
            int id = HandleUtility.nearestControl;

            if (id == leftId) selectedDirection = Direction.west;
            else if (id == rightId) selectedDirection = Direction.east;
            else if (id == forwardId) selectedDirection = Direction.north;
            else if (id == backId) selectedDirection = Direction.south;
            else selectedDirection = Direction.none;
        }
    }
}

```

Note:

For anyone that wants to use this code while running the code in this answer my Unity decided to have a heart attack and died. After restarting it the behaviour of this was different. It stopped redrawing while the mouse was moving so I had to add a small line to redraw the editor script while the mouse is moving! see `HandleUtility.Repaint()`.

---
Tags: unity, gui
---


title: How to make a merge animation in Unity?

text:
# Question
Title: How to make a merge animation in Unity?
I've seen a merge animation in a mobile game which you can check here;

https://youtu.be/G7l24Wtdcxw

You can observe the animation when the tiles combine.

Can it be done in Unity3d, may be using shaders? Or, do I need to use a 3d app like Blender?

# Answer
This is done by covering/swapping the tiles with another set of tiles that will be animated, replacing them on screen, then playing animated tiles in sequence.

You will need to prepare animated tiles.

They can be animated in many ways: Scaling the GameObject with a script, shaders modifying the pixels opacity and/or model scaling, pre-animated meshes (e.g.: In Blender), procedurally animated meshes, animated texture sequences, animated vector graphics (e.g.: SVG)...

Which way to use to animate depends on your preference, available tools, skill set, artistic direction, and which is "best" is entirely a matter of opinion (Questions that demand opinion-based answers get closed).

However, no matter which animation technique you use this is the sequence of events to achieve a similar result to the video linked:

The red overlay tiles are transparent for demonstration purpose. In reality you'd want them opaque to cover the original tiles.
> 3 votes

---
Tags: unity, animation, blender
---


# Question
Title: How to account for acceleration when aiming projectiles?
How do I aim a constant speed projectile to hit a target if there is a constant acceleration vector acting on it? (For example, the wind and gravity from Worms.)

# Answer
Let be the position of the target relative to us, and let be our (the projectile's) velocity relative to the target. The speed of the projectile and the acceleration vector are constant. We set up the usual equation of motion:

This is now simply a biquadratic equation, which we can solve for with the usual quadratic formula, and take the square root again to get :

The lesser and greater positive real roots are the *minimum* (shallowest) and *maximum* (steepest) flight times of the projectile, respectively. Both of these will exist if there is any solution. We can then just plug them back into to recover the actual velocity vector. We're normally looking for the minimum flight time solution, but if e.g. there's a hill in the way, the maximum time solution might be able to shoot over it.
> 10 votes

# Answer
If you are only interested in calculating a launch angle assuming you have a turret that rotates through an azimuth in the horizontal plane and elevates its barrel at angle theta, there is another equation you can use. Assume you have a coordinate system where x points North, y points vertically, and z points East. Assume the turret is at the origin and the target is at (x0,y0,z0). The target is stationary and the projectile speed is v. The angle is calculated using the equation below:

where C = x02 \+ z02 and D = g(x02 \+ z02)/(2v2)
> 0 votes

---
Tags: mathematics, projectile-physics, trajectory
---


# Question
Title: Getting a sampler of the default rendertarget (null)
I've been working on a mod for "Duck Game" that adds dark levels like in Spelunky.

I read this guide on how to make shaders, but in my case I don't have access to the draw method and since the game isnt drawn in a rendertarget first I can't do the same blending as he did.

I wrote my own shader that sets the alpha based on the average color value, looks like this:

```
float4 PixelShaderFunction(float2 coords: TEXCOORD0) : COLOR0
{
    // TODO: add your pixel shader code here.
    float4 color = tex2D(s0,coords);
    color.a = 1-((color.r + color.b + color.g)/3);
    return color;
}

```

And it looks like this in game:

I personally isn't satisfied with how this looks but to make it like in the tutorial (which is way better) I would need to get the sampler of the main draw (with current rendercontext set to null).

Is there a way to get the pixels on screen so that I can use it like in the tutorial?
I'll also accept answers with better ways of doing it.

# Answer
> -1 votes
Ok, so I'm not an expert in XNA, but provided it uses standard GLSL then you might be able to do:

```
if (color.a < cutoff)
{
    discard;
}

```

This would mean that you don't alpha blending but you can still do alpha clipping where you discard the pixel if it's not opaque enough (based on the cutoff variable). If it uses HLSL then the equivalent would be:

```
clip(color.a-cutoff);

```

I hope this helps,
-Thomas

---
Tags: shaders, xna-4.0
---


# Question
Title: Gizmos.DrawMesh does not render anything
I would like to draw a procedural mesh as a gizmo:

```
Gizmos.DrawMesh(mesh);

```

however this does not render anything no matter what. I can confirm that the mesh in question is a correct one by both `GetComponent<MeshFilter>().mesh = mesh` assigning it to Renderer and rendering it using default material and `Gizmo.DrawLine` drawing it edge-by-edge.
No error are logged in debug window, setting position or flipping triangle orientation has no effect neither. Version of Unity is 5.6.2f1. Am I missing something?

```
void Start ()
{
   GetComponent<MeshFilter>().mesh = mesh; //renders without any problems
}

void OnDrawGizmos()
{
   Gizmos.color = Color.red;
   Gizmos.DrawMesh(mesh);//nothing rendered
   //renders without any problems
   for (int i = 0; i < mesh.triangles.Length / 3; i++)
   {
      Gizmos.DrawLine(mesh.vertices[mesh.triangles[i * 3 + 2]], mesh.vertices[mesh.triangles[i * 3]]);
      Gizmos.DrawLine(mesh.vertices[mesh.triangles[i * 3]], mesh.vertices[mesh.triangles[i * 3 + 1]]);
      Gizmos.DrawLine(mesh.vertices[mesh.triangles[i * 3 + 1]], mesh.vertices[mesh.triangles[i * 3 + 2]]);
   }
}

```

# Answer
> 2 votes
Unity does not recalculate normals automatically, which in combination with the default material not requiring normals to render caused the confusion. Either

```
mesh.normals = Enumerable.Repeat(Vector3.forward, mesh.vertices.Length).ToArray();

```

or

```
mesh.RecalculateNormals();

```

will do the trick.

---
Tags: unity, mesh
---


# Question
Title: Unity Performance: How many Materials per Object?
I have learned that a Mesh with 4 Materials each 1024x1024 in Size is somewhat slower than a Mesh with 1 Material 2048x2048 in Size? In my usual workflow I tend to seperate different Materials into different Materials so an Object tends to have around 2-8 Materials. I have created more than a hundred Assets like this.

Is the performance dramatically affected by this? Is it acceptable to upload such Objects to sites like turbosquid or sell them on Unity Asset Store or will the buyer behead me after noticing?

Window Textures need to be transparent, Metal / Wood / Concrete need different smoothness settings. As far as I know Unity doesn't support Gloss maps.

# Answer
There is roughness setup, so Unity does support it. And it depends on a shader that is written, Unity doesn't have to support anything except shader language (as far as my understanding goes).

Yes, it does have a performance hit. For every new shader, it needs to calculate that shader on GPU. Objects with the same material share the same shader which means some things aren't calculated twice.

Conclusion: it's always better to keep the number of materials & shaders as low as possible if it doesn't change the final look, if it does change it then it's just a matter of what is more important at the project stage - performance or look.

Normally characters in AAA games have from 2 to 3 materials attached. One for skin, one for clothes, one for eyes. Props and other objects usually have 1 material, but some of them might require different shader or setup, so it's possible that they might have some maps or more materials/shaders.

Personally, I would be upset if the asset that I bought required many unnecessary materials. Also, I would think that it is not even unwrapped, so you can't change the texture or delete materials.
> 2 votes

---
Tags: unity, textures, performance
---


# Question
Title: Would a company take a game pitch seriously if they were pitched a fully finished game?
Let's say hypothetically that I had a fully realized and functioning game using a well known IP (a character from Nintendo or from another company, for instance), where the game is finished and wouldn't have any development time, would they entertain the idea to release it?

It would be made with their characters so I would have no right to it (in the case of money) but would they entertain the idea if they found it good and fresh.?

I have seen answers to this question saying a definite *no* for they were presented an idea of a game and not a completed product. And I know most people would want compensation for there time, but if it's already done and bug tested, play tested and polished, would they entertain the idea if they found they wouldn't have much to do on their end and I would not seek any rights to the design?

# Answer
> 7 votes
Most of the same legal entanglements exist for trying to pitch finished projects as exist for trying to pitch "ideas." So your chances here are slim.

A game *development* company likely wouldn't be interested at all, simply because they are not in the business of publishing finished games... that's what a publisher is for. Unless the company is fully-independent, it's very likely they couldn't make the decision anyway, since they don't usually own the intellectual property.

A game *publishing* company might, since that's more in line with what they actually do. However, most of them are unlikely to entertain solicitation from unknown developers, and many of them are unlikely to be pleased with the fact that something was built using their intellectual property without permission. IP owners tend to have plans for their IP themselves, and don't need you to take it off in some random direction they don't want.

It also extremely unlikely, for the same reason, that they would consider this game "finished" even if you do: they may want their own modifications to support their future IP plans, or plans to push certain technologies they may be invested in, et cetera.

If you want to pitch an idea for a game based on a publisher's IP to a publisher successfully, you probably:

* want to come at it without a "finished" product; something far along is fine, but if you present it as something that needs no additional work and thus has no opportunity for their input on their own IP you'll likely just get a cease-and-desist order.
* don't actually want to *incorporate* their intellectual property in your pitch prototypes. Use placeholders and explain in the pitch itself that you'd like it to leverage whatever IP. This demonstrates respect for their property that you don't necessarily show when you just use it without asking and them come to them afterwards.
* want to have a portfolio of games you've shipped already, or be part of a company that has developed games that sold already (and speaking officially on behalf of that company) so that somebody will actually give you the time of day in the first place.

---
Tags: business
---