I need help :(

Hi
I tried to make game like "Tasty planet" where you eat things and you become bigger, but i have a problem in one script. So i have no idea how to make a player eat a thing only if he is big enough.
I wish you will be able to help

 

Compare the two value how big is the player ..and how big it need to be to eaten

 

Yeah but "how big is player" how to write it :/

 

well that's up to you.. you could have simple int represent the player size and same go for things that need to be eaten

 

Easiest way would be to have a

float volume

variable on edible objects, and a

float edibleVolumeMax

variable on the player.

You could then write a method so that when the player grows, its edibleVolumeMax increases. That way you're only testing against a static edibleVolumeMax, and only changing the value when the growth occurs.

 

So under if what should i write?
(I am newbie sorry :/)

 

Psuedocode for how I'd approach it:

Code (csharp):

1.  
2. class Player
3. {
4.     static float edibleMaxVolume = 0.0f;
5.  
6.     void UpdateEdibleVolumeOnGrowth()
7.     {
8.         this.edibleMaxVolume = //some equation, maybe based on the size of the player
9.     }
10.  
11.     void OnTriggerEnter(Collider object)
12.     {
13.         if (object.gameObject.Tag == "Edible")
14.         {
15.             TryEat(object.gameObject);
16.         }
17.     }
18.  
19.     void TryEat(GameObject edible)
20.     {
21.         if (edible.GetComponent<EdibleObject>().volume <= this.edibleMaxVolume)
22.         {
23.             // do stuff to player
24.  
25.             // destory eaten object
26.         }
27.     }
28. }
29.  
30. class EdibleObject
31. {
32.     static readonly float volume = 1.4f;
33. }
34.  

 

Well that doesn't work i think i will surrender

 

Didn't take much to make you give up. Developing games is very difficult and requires a ton of persistence. Even seemingly simple games can take years of effort. And there is a lot of failure along the way. Frankly if you let small failures defeat you so easily, you will never make a game.

 

It certainly works if implemented properly. What @Xepherys posted you is pseudo code - ie not an actual implementation (tho pretty close) but a showcase for how he would approach the problem. It's still up to you to implement it properly, meaning you have to update the involved values, and make sure the other objects have an EdibleObject component and so on.

However, and most importantly, saying "it doesnt work" is just about as helpful as the title you chose. Meaning not at all. If you want actual help for a problem, try an actual explanation so people can help you. Also, giving up as soon as something does not work on your first try wont get you far in game development. Last but not least, if this game is currently too hard for you to tackle, then try something more simple. There are lots of great tutorials out there for getting started with Unity and C#.

 

I didnt meant to surrender in making a game but in making that script

 

What you need is another if statement in the one you've got, which checks the player's size and the "eating" only happens if the condition is true. This was laid out well in Xepherys' post.
Definitely take some time to run through the intro tutorials, they will answer a lot of these kinds of questions.

 

Hah, I get it, sometimes after beating your head on the desk long enough you just need to move on to something else. Work on some other aspect of the game, then come back to this with fresh eyes.

I don't know what your level of coding experience is, but I offer this advice: coding something new is always difficult. I don't mean a new game or new app or new project, but some functionality that it utterly new to you. I write and maintain two ever-growing applications at work for my day job. Been writing and rewriting them for five years now. The difference between my code then and now is... vast. Every time I need to add a new feature that is not at all similar to anything I've done, it takes some trial and error. We have senior engineers that work on our product that have been slinging code for decades and sometimes they still end up with a head-scratcher.

Learning to code builds on itself. You learn something specific (Hello World!), then you learn something conceptual (console I/O), then something newly specific (a Hang Man game), then something conceptual (storing and retrieving data). Every failure is a lesson learned. It sounds all motivational poster-y, but it's the truth. I've been DEEPLY frustrated with a class or method only to step away and come back a month later with some new tool in my belt and breeze through it by approaching it from an entirely different angle.

 

The simplest way I can think of is to compare the scales of the two objects (assuming they're both the same size at scale 1,1,1)

I see you're increasing all axis when it grows, so you can just check one axis of both objects to determine who's bigger like this:

Code (CSharp):

1.     private void OnTriggerEnter(Collider other)
2.     {
3.         if (other.gameObject.Tag == Tag)
4.         {
5.             if (transform.localScale.x > other.transform.localScale.x)
6.             {
7.                 transform.localScale += new Vector3(increase,increase,increase);
8.                 Destroy(other.gameObject);
9.             }
10.         }
11.     }

I'm also assuming that this script is attached to both gameObjects, so this guy can eat or be eaten.

 

Big thanks
That was what i was looking for thank you bro

 

I... don't recommend this. For this to be true, you'd have to make all of your models sized to scale rather than sized to the world. I'm thinking about this from the perspective of something like a Katamari game. For this to work, you'd have to make 1,1,1 be a default size rather than a default scale, and size every model accordingly.

E.g. - you use the player at his normal size as the default sizing. So, you make a telephone object. At it's 1,1,1 scale, it's the same size as the player, but you scale the GO down to whatever... 0.1,0.1,0.1 so that it's "phone sized". Then, right off the bat, the player can interact with the phone. Let's say there's also a tree. You make the tree player sized as a model, and that's 1,1,1, then you scale the GO up to say... 10,10,10 so that it's tree sized in the scene, and once the player has grown to 10,10,10 it can interact with the tree.

The problem is that scale in Unity is designed to encompass a measurement of distance/volume. When you start rescaling almost every GO to make it the "right size", you end up breaking other things. Physics can be much more difficult to work with this way. Lighting can get really wonky. Even colliders can start to get difficult unless you're using mesh colliders (which is incredibly expensive as compared to primitive colliders).

Obviously the ability to scale objects to different sizes is useful, but using that method for most objects makes both modeling more difficult and coding more difficult. You're far better off putting in the small amount of time up front to create a volume system of some sort (or even to statically assign a volume float to each object type) and code to that standard than you are to just have your scales all crazy.

 

@Xepherys i get what you’re saying. Just trying to give this guy a quick simple solution because it sounds like he’s new and just trying out some things. If you’re working with really simple objects like cubes and spheres this approach is fine. Once you start bringing in more complex objects then you’d want to rethink it for sure.

You could say I was applying KISS and YAGNI Principles based on the small amount of background information I was given