Zbieranie itemów lekki kod ?!

[pablos11]

Czy taki kod będzie zżerał dużo pamięci podczas grania?

using UnityEngine;
using System.Collections;

public class Food : MonoBehaviour 
{
	void OnTriggerStay (Collider other) 
	{
		if (Input.GetKeyDown (KeyCode.Z)) {
			if (gameObject.tag == ("Jedzenie"))
			{
				if (gameObject.name == ("Jabłko"))
				{
					Debug.Log ("Jabłko");
				}
				if (gameObject.name == ("Ser"))
				{
					Debug.Log ("Ser");
				}
			}
		}
	}
}

Itemów będzie o masę więcej, każdy typ itemów ma tag

1. Bronie
2. Jedzenie
3. Przedmioty
4. Narzędzia
5. Dodatki

 

Po wejściu w Collider przedmiotu i wciśnięciu klawisza "Z" skrypt sprawdza co to za TAG [Jedznie/Broń/Dodatek].

Następnie szuka w tym tagu odpowiedniej nazwy gameObjectu, czyli wchodząc w tag jedzenie, skrypt szuka co to jest za jedzenie [ser/jabłko]

I czy po dodaniu 50 różnych typów jedzenia taki kod nie zwolni mocno komputera

 

Chyba że lepiej zrobić osobne skrypty do każdego tagu żeby był bardziej przejrzysty?

[Hans Kloss PL]

Raczej się martw czy będzie zabierał dużo czasu pracy procesora. Jak nie wiesz co to else if to na pewno  

Poza tym nie wiem co tam się będzie działo po wybraniu przedmiotu, ale idę o zakład, że zamiast 50 ifów możesz załatwić to tablicą.

[pablos11]

;-; najgorsza rzecz to tablice...

 

Ale tak czy siak, podnoszenie przedmiotu, muszę sprawdzić co podniosłem aby usunąć to z sceny i dodać do eq gracza,

[MistrzMaster]

@pablos11

No to

1. Zrób sobie enuma, przy sprawdzaniu stringa możesz się pomylić, przy złym enumie dostaniesz błąd.

2. Zrobiłbym klasę abstrakcyjną Items, później załóżmy tą Food i zrobiłbym pętle po całej liście sprawdzając kolizje (nie mam pojęcia jak teraz sprawdzasz ale strzelam że podobnie) z tą różnicą, że wtedy możesz...

3. ...zrobić coś na wzór addItemToEq(items.getCaption) i tam robisz resztę(myślę, że wygląda przejrzyściej) później możesz wywołać te metody usuwania ze sceny, bo wiesz z którym itemem miałeś kolizje

 

@Edit

Inna sprawa, że chyba lepiej najpierw sprawdzać wciśnięcie przycisku dopiero później kolizje, aktualnie to pewnie wywołujesz tą metodę o wiele razy za dużo skoro i tak nic się nie dzieje bez wciśnięcia "Z"

[pablos11]

Akcja szukania co za item spowodował kolizję dzieje się po aktywacji klawiszem Z

 

Podobne mam szukanie co powoduje kolizję, szukam co ją powoduje jaki TAG [jedzenie w tym wypadku]

Potem sprawdzam które jedzenie z listy to powoduje i tyle, czy tylko przy 20 typach jedzenia nie zje za dużo pamięci

 

Dodatkowo podobny kod będzie na resp tych itemów tylko tam będzie random.value i podobny kod

[Hans Kloss PL]

Eksperymentuj, testuj czas wykonania i zużycie pamięci to sam będziesz wiedział co ma realny wpływ na wydajność. Skoro nie potrafisz oszacować zuzycia pamięci / wydajności algorytmu to takie testy będa lepsze niż zgadywanie / pytanie na forum.

[MistrzMaster]

    void OnTriggerStay (Collider other)
    {
        if (Input.GetKeyDown (KeyCode.Z)) {

Akutalnie to wygląda mi to na:

1.Sprawdzenie kolizji

2.Sprawdzenie inputu, a nie na odwrót(onTriggerStay wukonuje się w przypadku kolizji, tak?)

[pablos11]

Tak, nie chcę żeby najpierw przyciskano Z a potem sprawdzano czy wgl jest kolizja

Chcę żeby po wejściu w kolizję można było wciskać Z i wykonywać dalszy kod

 

Bo gracz chodzący i spamujący Z lagowałby se grę [minimalnie ale lagowałby] a w ten sposób kod gry nie wykona żadnego kroku aż nie wejdzie w kolizję.

 

Wg mnie jest to lepsza kolejność,

[mrufkojat]

Cześć,

 

Jeżeli za leży Ci na tym żeby najpierw był Z to proponuję w Update na słuchiwać klawiszy. Wtedy jak naciśniesz z to wywołasz metodę. Ja nazwałbym ją CheckForLoot(). Nie chce robić tego na OnTriggerStay bo to różnie bywa. Kiedyś taka koleżanka mnie o szukała, ale nie tak mocno jak np. OnTriggerExit. Sprawdź jak jakiemuś koledze tutaj odpisałem o zbieraniu itemów z ziemi. Możesz się za sugerować tym co tam napisałem.