Войти
ПрограммированиеФорумОбщее

Детские вопросы по Unity ( В чем преимущество Scriptable Object как переменных? ) (3 стр)

Страницы: 1 2 3 4 511 Следующая »
#30
3:50, 31 дек. 2018

tac
> зачем эта пустая сущность?
она общая для всех сцен.
Если посмотришь в основной код, то нигде Scene1 или Scene2 напрямую не вызывается. (за исключением инициализации или загрузки, где нужна конкретика)
И кстати класс scene не обязательно делать абстрактным.

Это такой принцип ООП - если есть нечто общее, то оно выдлается в класс, а конкретные реализации будут от него наследоваться.


#31
(Правка: 4:02) 3:53, 31 дек. 2018

tac
> дальше важнее string[] action ... что? а слабо было два параметра , почему надо
> годать, что в первом элементе, что во втором? оригинальное нарушение магических
> значений в коде ... и не лучше ли enum вместо string уже сделать?
ну это же текстовая адвентюра.

Все команды вводятся текстом, а значит их придёться парсить
take ammo
take sword

string[] action - просто массив строк (команда, распиленная по пробелам).
Можно разбить на два параметра:
string action
string[] params
...но будет ли особой смысл?!

а вот это enum уже не расширяемо.

#32
3:59, 31 дек. 2018

skalogryz
> Если посмотришь в основной код
ок, тут согласен, остальное завтра ...

#33
3:59, 31 дек. 2018

tac
> ммм .. ээ. я чето не понял, а код работает? break в case уже писать не надо?
там return-ы.
ты можешь написать break после return-а, но наткнёшься на ругательство компилятора о недостижимом коде.

#34
(Правка: 4:04) 4:04, 31 дек. 2018

skalogryz
return там под условием

skalogryz
> уже не расширяемо
как  только написал в коде if (action[1] == "pikes") уже не расширяемо

#35
4:04, 31 дек. 2018

tac
> первый стилистический больше, но нафига
> class Program
> {
>   class GameState
а в чём проблема со вложенными классами? это вполне естественная вещь для Шарпа.
мне же хочется в один файл уместится. Или я вопрос не правильно понял?!

#36
(Правка: 4:07) 4:05, 31 дек. 2018

tac
> как  олько написал в коде if (action[1] == "pikes") уже не расширяемо
не расширяемой с какой стороны?
со стороны Scene2... ну может быть :)

а вот при добавлении Scene3, 4 ... ну или бизнес языка, не придёться впихивать новые значения в "enum".
(вообще сцены можно будет подгружать из .dll-ок! плагины, DLC... при этом основой .exe может не меняться). Но на самом деле такие плюшки, к текущей теме не относятся.

#37
4:06, 31 дек. 2018

tac
> return там под условием
и ещё в default.
я предлагаю списать такие вещи на кривость самого C#! xD

#38
4:06, 31 дек. 2018

skalogryz
> мне же хочется в один файл уместится
а что мешает два класса написать в одном файле, зачем их вкладывать? логика в чем?

#39
(Правка: 4:10) 4:09, 31 дек. 2018

tac
> а что мешает два класса написать в одном файле, зачем их вкладывать? логика в
> чем?
типа так написать

class GameState { ...}
class Program { .. }
пожалуйста, можно и так. я не против.
можно же дальше пойти и сказать, что всё что относится к игре в отдельный файл, и вообще в отдельный namespace, но опять же не цель.
логика моих действий (со вложенным классами) простая - быстро написать на основе предложенного решения в нуль посте.
#40
4:09, 31 дек. 2018

skalogryz
эээ не .. я посмотрю завтра внимательнее, но лопух тот кто return в switch использовал, а не язык .. но там больше того, вы проверяли, оно не должно работать как задумано ..

помним да правило об однойточки выхода из метода? ато нафига тогда goto изначальное критиковать )

#41
(Правка: 4:14) 4:12, 31 дек. 2018

tac
> помним да правило об однойточки выхода из метода? ато нафига тогда goto
> изначальное критиковать )
пфф... я могу и в академический стиль

 bool res = false;
 switch (action[0])
 {
     case "take":
         {
            ...
             res = true;
         }
    case "open": {
             ..
             res = true;
         }
 }
 return res;
и если бы я писал на Паскале, то писал бы именно так.
Но это Си-образный язык, и return XXX там... принято эксплуатировать.
#42
(Правка: 4:14) 4:13, 31 дек. 2018

skalogryz
> типа так написать
ага ... просто нафига люди усложняют сущности я не пойму .. это же должно иметь смысл ... вложенные классы, не несут никакой смысловой нагрузки , но позволяют написать вот такую странную конструкцию

PrintHelp();
    if (current != null) current.PrintHelp();

#43
(Правка: 4:17) 4:15, 31 дек. 2018

tac
> ага ... просто нафига люди усложняют сущности я не пойму .. это же должно иметь
> смысл ... вложенные классы, не несут никакой смысловой нагрузки , но позволяют
> написать вот такую странную конструкцию
я не согласен с термином "странная" конструкция.
Она не странная, она ограничивает/определяет область видимости.
Вот и всё.

Вполне может помочь при правильной огранизации программы. В данном случае она "достаточно" правильно организовано. GameState используется только там ))

tac
> PrintHelp();
>     if (current != null) current.PrintHelp();
это тоже не "странная" конструкция.
Смысл этого кода такой:

  • печатаем хелп (общий для игры)
  • если находимся в какой-либо комнате - печатаем хелп, специфичный для этой комнаты.
  • #44
    (Правка: 4:26) 4:21, 31 дек. 2018

    skalogryz
    > печатаем хелп (общий для игры)
    не по вашей ли логике это должно быть в классе Scene? общему для всех, и печатание должно проводиться одним вызовом не зависимо от сцены?
    if (current != null) current.PrintHelp();

    а уже если переопределили и надо общую справку вызвать сделать внутри base.PrintHelp() ? не сокрытие ли это ненужных деталей реализации? и не зря ли мы подвесили static методы уйдя в глубокое структурное программирование

    а область видимости определяет namespace и модификаторы доступа, напига концепция вложенных классов, чтобы больше ошибок допустить?

    Страницы: 1 2 3 4 511 Следующая »
    ПрограммированиеФорумОбщее