Unity programming "Galaxy Raiders 3" future

Циклы / Массивы

http://metanit.com/sharp/tutorial/2.4.php

___________

DOTS

http://unity.com/ru/case-study/nordeus-megacity

DOTS Unity

Создавайте высокопроизводительные алгоритмы на C#

DOTS : удобная песочница для разработки безопасного многопоточного кода ,

повышающего производительность, оптимизирующего тепловыделение и

энергопотребление мобильных устройств игроков.

кроме того, переход от объектно-ориентированного

к информационно-ориентированному

подходу упрощает вам многократное использование кода, а другим позволяет

легче понять и дополнить его при необходимости.

http://unity.com/ru/dots

Создавайте сложные миры быстрее

Используйте мощь стека DOTS

не отказываясь от знакомых вам методов работы.

Новая Функция : Conversion Workflow

позволяет преобразовать объекты GameObjects в экземпляры одним щелчком.

а во время выполнения вы всегда можете заглянуть в Entity Preview Inspector,

чтобы увидеть, как система DOTS

превращает объекты GameObject в экземпляры.

в итоге вы получите хорошо оптимизированные, удобные в использовании данные, необходимые для привычной работы с игровыми объектами.

наша новая экспериментальная функция Unity Live Link

также позволяет работать над контентом в режиме игры

без создания новой сборки для каждого раза.

Игру можно будет проверить на целевом устройстве в реальном времени,

улучшая ее еще быстрее.

Пакеты DOTS

Некоторые из пакетов DOTS все еще имеют статус предварительной версии,

но они уже могут оказать значительное влияние на важнейшие с точки зрения производительности элементы ваших проектов.

Придерживаясь курса переработки базовых систем Unity на основе DOTS,

мы постоянно добавляем в стек новые пакеты,

постепенно доводя уже добавленные

до готовности к профессиональному применению.

загрузить

DOTS : Data Oriented Technology Stack

Entity Component System

Unity DOTS : высокая производительность, и удобный редактор

unity dots performance intro

файлы на андроиде andorid files

чтобы писать файлы на андроиде, надо в настройках

Player Settings->Other Settings->Write Permission

указать External(SD Card).

тогда появится возможность сохранять не только в

Application.persistentDataPath, но и прямо

в корень папки

Android -> "/storage/emulated/0/"

... из соображений производительности

лучше использовать GetComponent

с типом вместо строки ...

однако иногда вы не сможете получить доступ к типу,

например, при попытке доступа к сценарию C# из Javascript .

в этом случае вы можете просто получить доступ к компоненту по имени,

а не по типу .

using UnityEngine;

public class GetComponentNonPerformantExample : MonoBehaviour

{

void Start()

{

HingeJoint hinge = gameObject.GetComponent("HingeJoint") as HingeJoint;

if (hinge != null)

hinge.useSpring = false;

}

}

___________

в Unity есть переменная

Application.persistentDataPath

это папка, в которую можно через проводник указать свои ресурсы.

так же можно скачать ассеты с сервера, положить в нее через

File.WriteAllBytes/WriteAllText

и затем грузить с диска .

___________

GameObject.GetComponent

public Component GetComponent (Type type);

Parameters

type@param type Тип возвращаемого компонента.

Description

Возвращает компонент типа type, если он прикреплен к игровому объекту

и null, если не прикреплен.

... Использование

gameObject.GetComponent

вернет первый найденный компонент, а порядок не определен.

если вы ожидаете, что будет более одного компонента одного типа,

используйте вместо этого

gameObject.GetComponents

и прокручивайте возвращенные компоненты,

тестируя какое-то уникальное свойство.

___________

using UnityEngine;

public class GetComponentExample : MonoBehaviour

{

void Start()

{

HingeJoint hinge = gameObject.GetComponent(typeof(HingeJoint)) as HingeJoint;

if (hinge != null)

hinge.useSpring = false;

}

}

___________

public T GetComponent ();

Description

Дженерик функции. Для получения дополнительной информации

смотрите страницу, посвященную Дженерик функциям.

using UnityEngine;

public class GetComponentGenericExample : MonoBehaviour

{

void Start()

{

HingeJoint hinge = gameObject.GetComponent<HingeJoint>();

if (hinge != null)

hinge.useSpring = false;

}

}

___________

public Component GetComponent (string type);

Parameters

type@param type Тип возвращаемого компонента.

Description

Возвращает компонент типа type, если он прикреплен к игровому объекту

и null, если не прикреплен.

интересует обмен данными между скриптами проекта как реализовать?

если нужно из одного скрипта получить доступ к переменным другого скрипта как это возможно?

1 : всем видны переменные типа Паблик 2: передавать данные нельзя нужно использовать броадкаст или другие методы

3: иной вариант ...

этот вопрос возникает когда в игре все зависит от позиции экшн-скрипта, и

нужна общая база данных переменных всего проекта , чтобы любые скрипты

могли читать эти переменные и воссоздавать параметры сценам

согласно таймкоду экшн-скрипта и т п.

несколько способов :

1) public static переменная;

2) GameObject.Find , GetComponent<>;

3) SendMessage;

___________

юнити обмен данными между процедурами

обмен данными между скриптами

https://docs.unity3d.com/ru/current/ScriptReference/GameObject.GetComponent.html

___________

___________

скрипт на первом объекте :

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class Obj1 : MonoBehaviour

{

int i;

void Start()

{

i = 1;

}

}

___________

скрипт на втором объекте :

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class Obj2 : MonoBehaviour

{

public GameObject Object1;

int Obj1_i;

void Start()

{

Obj1_i = Object1.GetComponent<HingeJoint>().i;

}

}

___________

Голограмма на shader graph unity3D

alicewolfraider@gmail.com

Система Конфигураций : для Игровой Программы теперь доступны различные виды

Типов Конфигураций : игровой механики : разные Конфигурации Звукового сопровождения

плюс Графическое Сопровождение и геймплейная механика на разных формулах тоже доступна

и все можно сделать выбрав :

в Интерфейсовом Меню пункт Выбор Конфигурации

который можно содержать в Приложении под Паролем , после чего он Появляется или из него дать доступ ВИП-Пользователя по Ключам Доступа (его некую часть - вроде Maps)

самый интересный из моментов ,когда вкусное оставляется на потом ... это Аспекты

Аспекты : когда Геймплейная Система имеет уже достаточное количество всего и вся

которого уже очень много и наступает то самый сложный момент

при котором с огромной БазойДанных справляться становится все сложнее и сложнее :

ведь зачастую хочется изменить вот здесь и вот здесь и чтобы еще и применить

на типичные Объекты – которые оказываются вовсе не типичными, а даже вовсе разными , но у которых есть Однотипные Поля или Типичные Сущности которые мы можем назвать

МультиСущности состоящие из Сущностей которые Состоят из Компонентов

(но до компонентов нам как вроде и дела нет) и мы

обращаемся прямо к Сущности самой МультиСущности

и тут в этом деле нам помогут Аспкеты которые помогут

все это совершить в нашей БазеДанных

то есть в Интерфейсовой Базе Данных : ИБД : когда мы уже только летаем по Базе Данных

МультиСущность : МС

Поле Аспекта МультиСущности_№11 <адрес-указатель> Аспект_ИД_МС№ <адрес-указатель> <адрес-указатель> Поле Аспекта МультиСущности_№21

здесь Поле Аспекта МультиСущности_№11 это просто Аспект_МС_№11 и тоже Аспект_МС_№21

Аспект_МС_№11 <адрес-указатель> Аспект_ИД_МС№ <адрес-указатель> <адрес-указатель> Аспект_МС_№21

здесь сам Аспект_ИД_МС№ хоть и принадлежит МультиСущностям причем обоим сразу

но является Адресным Объектом с собственной структурой как МультиПолевойОбъект :

который принадлежит List_Aspects то есть Списку Аспектов и БД Аспектов (Таблица Аспектов)

то есть Аспекты принадлежат сами себе : как инструментарий , храня двунаправленные указатели : peer-to-peer :на себя и на Объект

можно Передвигаться по Списку Аспектов

связывая через МультиАспект нужные Поля МультиСущностей причем каждая МультиСущность имеет свой собственный Список МультиАспектов

<адрес-указатель> : может быть как указателем так и адресом (хоть WWW) по надобности можно иметь столько полей сколько понадобиться и их ИД не забыть (Уникальные TAG -и)

9 : имея Пикчу Объекта (графическое представление в *.jpg ) можно его подгружать как мы и говорили , но вот выводить на Экран нужно использовать x y (z) позиции не в Статике

а уже именно в Динамике : но как именно – а именно как в Cтатике ... Поля Позиций Объекта

10 : Поля Позиций Объекта : они неизменны у ОбъектаСущности ,

мы просто обращаемся к ним постоянно при ГлобальномАпдейте для нового Изменения Анимации и прочего ,хотя и при этом это просто идет Апдейт Анимации который вызывается в какой-то момент ,

и тут есть нюанс что Игровая Логика изменяет только сами координаты в Полях

а сам Апдейт Анимации служит только для Вывода на Экран обращаясь ко все тем же полям и мы даже не замечаем как он Происходит, но при этом контролируем весь процесс

11 : остается только взять Базовый Объект и создать его Копию присвоив ему ИД : ID N : identification number "Id"

причем Копия.БазовогоОбъекта.ИД_№ это просто ИД_№ объекта в движке Юнити / или в Собственной Базе Данных "Объектов" / иного

который остается только сопоставить с нашим Объектом_ИД_№ в нашей БД

и работать уже с ним как с нашим Объектом : причем сам ИД в Движке это просто как TAG

то есть TAG of Object : поле коннекта с Объектом в Приложении вроде Handle –а за который мы держим Объект

12 : и собственно наша Математическая Модель отражается в Приложении

и мы Получаем Геймплейный Движок на основе Фантомной Системы Сущностей

Особые Выгоды : теперь можно управлять приложением через Интерфейсовые Меню в режиме Run-Time

прямо из работающего Нашего Приложения и настраивать его как нам удобно

это дает Подгружать/Выгружать Объекты (арт и музыку и прочее вплоть до Скриптов)

можно теперь легко менять рубашки , не нужно искать в Коде куски кода ,

в БД Скриптов на основе Системы Рассчетов (как Торговля) , хранить Формулы

и прошаривать их через Интерфейсовое Меню и по сути это получился

еще и собственный Редактор Игры с которым могут работать Саунд-Дизайнеры

Геймплейные-Дизайнеры , Левел-Дизайнеры и даже Звуковики могут обкатывать на своих копиях-Приложения звуковые эффекты и прочее без знаний Кодинга , что в свою очередь ограничивает доступ к Коду увеличивая Безопасность Проекта

также позволяет работать как Far Space c Проектом ,и использовать Кодировки для Оперативной Памяти : в оперативе можно разворачивать БД или скорее часть БД

храняющуюся в закодированном виде на винчестере ... да куча мала тут просто описывать : рубашки тоже что и скины / skins

Programming code Ltd

8 : можно еще долго описывать всякие Оптимизации ,но мы напишем другое :

" Game Interface "= Game Interface Manager

можно визуализировать в процессе выполнения основной программы из параллельного потока ( потоку выполнения основной программы ) другими словами :

вроде вызывается параллельная программа на исполнение но на самом деле она и будет управляющей системой

дело в том, что в таком случае не нужно делать еще одно (не одно) " окно ": handle 's ...

GameInterfaceManager <==> <==> AI( Physical_of_virtual_world )<==> Special_System (SS<++>oriental_position_vision )

+ Список Activate_components ---> Game Interface Manager

вообщем нужно Контролировать Список Активных Объектов в наличии у Программы что и будет первоначальным моментом Оптимизации для Кодинг-Разработки ..

5 : как видно что мы от процесса повального Апдейта Всего и Вся перешли к Логике

то есть сам Апдейт происходит от Логики , мы назовем ЕЕ

Глобальная Логика Апдейтов : то есть Глобальный Апдейт всего остального произойдет

не ранее чем Отсканируется Глобальная Логика : пока не произойдет ее обновление (апдейт / re-fresh | UpDate)

то есть мы как в TBS : turn base strategy

будем действовать По-Турово – на какой базе-платформе чем организован Тур не столь важно или по Времени Обновления : мы можем установить его в зависимость от Кадров (FPS) , хотя это не столь Логично , в сравнении с тем как если бы мы установили его от Логики Игры

а сами Кадры останутся для Логики Анимации (как отдельной части)

6 : Ноды : это и есть тот самый Мутэйбл который будет как Мутейбл-Контейнер

7 : заметим что мы здесь не говорим о каких-либо Классах и прочем ,ибо

все это описано в БД (Базах Данных : БД Объектов) причем в любой конфигурации « как вроде в Таблицах Экселя » или Интерфейсовых Таблицах самого приложения (как БД)

Персонаж : Поле_ИД_перса , Поле_Именования_перса

Поле_Списка Сущностей : ИД_перса : Адресс в БД_Сущностей

Поле_Аспектов : ИД_перса : Адресс в БД_Аспектов

Графическое Отображение : ИД_перса : Адресс в БД_ГрафОбъектов

здесь Адресс в БД_ГрафОбъектов означает что мы в этой БД

храним Адресс где храниться сам ГрафОбъект : к примеру 3Д или в 2Д объект

описано в этой же БД_ГрафОбъектов , и там адресс может ввести в Папку с *.JPG

мы указываем мульти-звездочку на случай если это Анимация

как Набор ДжиПэгов для Анимационного Набора : должна быть указана Нумерация на арт-картинках прям на названии файла (обычно отдельно переназывается)

и их останется при Инициализации Приложения подгрузить в Оперативную Память

да вообще можно использовать Оверлейно управляя Памятью компьютера (но не касаясь ее)

выгружая и подгружая по необходимости содержа Оптимальное Ядро Данных всея приложения

некая Сущность

4 : мы прибавим немного определений вроде Трансформ и Мутэйбл разделив их

Трансформ : понятие о Трансформации Объекта - если объект трансформируется

под ситуацию получая Данные для Себя или других Объектов , но при этом он

может присоединять не только Данные в Поля Своих Сущностей ,но и прибавлять к себе Сущности : (компоненты – здесь Сущность может состоять из Компонентов)

допустим Объект добавил Сущность «+20% Торговли»

это просто прибавилось Поле

которого до того не было ,но было его Поле Торговля

из которого Путем Копирования

или попросту использования Полиморфизма в Процессе исполнения программы образовалось новое поле у Сущности Торг

(мы специально отделяем название Сущности от Его Поля)

.. откуда взялось «+20% Торговли» :

это мы используя Дипломатию наняли Партнера

у которого тоже есть Мэйн Поле Торговли и его Базовая Торговля 20% цельно без

всяких плюсов и прочего : теперь у нашего Персонажа его

Торговля = Базовая Торговля 20% + «+20% Торговли = 40% Торговли

заметим что формула так и работает на самом деле : плюс в формуле в которой по-сути формульный_плюс добавляет то что за скобками (а вдруг там минус или вообще «Умножить»)

и здесь если будет «умножить» то разве так должна быть формула внутри программы :

просто понятно что Функция Бонуса должна быть описана отдельно и Базовые Моменты считать правильно согласно очередности : высчитать Торговлю потом присоединить Бонус ...

Мутэйбл : если Объект оставил от себя только часть своих Сущностей или вовсе одну которые куда-то переходят другому Объекту , то это будет Мутейбл_ID_№ (название) к примеру , на Арене один Персонаж_Z21 победил другого Перса_M11 – что-то от того

Перса_M11 осталось (допустим это Фэнтези РПГ вроде ДаркСайдерса) и перешло к Z21 : так и запишем : Мутейбл_ID_№17_от_ПерсаМ11

Мутейбл_ID_№17_от_ПерсаМ11 : или скорее как НаборСущностей

ввиде Мутейбл_НаборСущностей_№17_от_ПерсаМ11

в Глобальном Смысле :

Апдейт Логики. Перса_M11

Трансформ. Перса_M11

теперь Трансформ. Перса_M11 говорит что Трансформ=EpiEnd.Mutable

значит создаем Mutable от Перса_M11.Трансформ.EpiEnd

то самый Мутейбл_ID_№17_от_ПерсаМ11

осталось присоединить его к Персонаж_Z21

или через Трансформ.List.Мутейбл_ID_№17_от_ПерсаМ11 (добавив в Список Сущностей)

или через саму Мутацию Объекта : здесь мы обнаруживаем что вариаций как организовать этот процесс Целое Множество , как и организация к Доступу Сущности

Phantom Entity System

Фантомная Система Сущностей

Компонентная Система Сущностей

по факту ЕЕ не видно из редактора Юнити и даже понятия схожи вернее даже тождественны ,

но обозначают другое нежели это идет в обычном понимании (или в функциональном.)

Рассмотрим более подробно что оно и как же есть :

1 : в обычном понимании Объект состоит из Полей которые называются

в некотором роде Компонентами Объекта – почти любого Объекта ...

в котором (главная фича всей этой заморочки с компонентами) что все части равноправны :

могут быть а могут не быть. т.е. в любой момент любую часть можно выкинуть и по идее ничего не должно случится :

например можно любую часть рамки выкинуть (мнение некоего кодера)

но в Фантомной Системе Сущности Объект состоит из Компонентов

как Сборка из отдельных Частей ... (все это уточнится что же Это в процессе описания)

2 : для скорейшего понимания нужно выйти на Глобальный Уровень Управления

Глобальный Апдейт : все Объекты ,как Компонентная Система Сущностей из которых они состоят - здесь Сущность и есть цельная Часть Объекта – будут проходить Общий Апдейт

через Систему Глобального Апдейта : .. это означает что все Объекты которые нужны в данный момент - иными словами Задействованы – будут получать Новые Данные в свои Поля во все Свои Сущности : то есть будет проходить Изменения Данных Объектов

под которым подразумевается получение Данных в Сущности Объектов которые образовались путем Вычисления Формул (данные) или прочих изменений в Игровом Приложении

что значит Задействованные Объекты : это те которые Активированные на Данный Момент

хотя это не совсем тоже что OnAction – просто некая схожесть могут же быть и Не_Активы

3 : ну вот получили мы доступ к Глобальному Апдейту , а каков толк как бы от этого и что должно произойти в сущности : на самом деле для Объектов это будет некой Трансформацией

ибо мы пляшем от того что у Объекта данные Статичны изначально ,а теперь ДД : Данные Динамичны (ДД) : у Игрового Приложения куча мала Апдейтов

глобально

апдейт аи системы,

апдейт анимационной системы (коллайдеры),

апдейт физ.двигла,

апдейт колижн системы

рендер

есть аи у которого своя аишная сцена, в которой есть разные аи компоненты, он умеет апдейтится, и апдейтить по необходимости компоненты,

есть анимационная систем которая умеет апдейтить свои компоненты, которые от состояния объекта умеют устанавливать, блендить, кросфейдить анимации,

которые апдейтят трансформы, есть физдвиг у которого своя сцена со своими физмоделями, физ компонент - это контроллер который апдейтить трансформ-ы

есть колижн в котором есть соотв. компоненты, которые также апдейтят трансформы .. "колижн" это учет столкновений

стоп-стоп-стоп : это же просто набор всего и вся , вроде как добрались до бесплатного и давай понеслась вперед – Все Апдейтим – причем все подряд без разбору – все катит !! тут компоненты и друг друга апдейтят и все вроде круто ...

во-первых : для чего ради городили мы огород – вот же есть колижн-система – а у нас Компонентная Система Сущностей : и тут если колижн-систему оставить саму на себя то она превратиться в невероятно неуправляемый поток данных , который как счетчик будет тарабанить в циклах и там уже ничего разобрать не будет возможности , здесь просто нужно воспользоваться доминирующим преимуществом и превратить саму эту колижн-систему в Анти-Колижн Систему и взять рассчеты по управлению колижн-системой на себя : просто организовать Рассчеты в Коде для колижена ...

..но это мы как бы забежали вперед ,

хотя по другому возможно будет сложнее понять.

для Крупного Боя с Множеством Пехоты с Копьями лучше спешится избавившись в ближнем бою от обстрела войдя вплотную с противником

обычно Титул Рыцаря означает что это Военный ..

в играх аля-скайримах существует мастер кожевник и мастер охотник

или проще сказать охотники шкуры сдают кожевнику , а тот делает

кожаный жупан под доспехи - и это тоже Кожаные Доспехи / Кожаная Броня

или если есть руда , то тогда при наличии кузнеца можно получить Кольчугу

причем если Мастер Кузнец то - если он Мечник (воин-на-мечах) , то можно

получать и мечи и при обучении такой мастер-кузнец может ковать доспехи

обязательно уже с подмастерьем , ибо дело трудное ..

так это и есть сценарное развитие ака сценарной ветки

все можно расставить в приоритете

Кожаные Доспехи

Кольчуга

Доспехи

по силе брони / Класс Брони

Тяжелая Броня : Доспехи + Кольчуга + Кожаные Доспехи

Средняя Броня : Доспехи + Кольчуга / Доспехи + Кожаные Доспехи / Кольчуга + Кожаные Доспехи / Кожаные Доспехи + Кольчуга

Легкая Броня : Доспехи / Кольчуга / Кожаные Доспехи

и все можно уже применять , когда это расписано и можно крафтить в игре

сюда же оценка компьютером сразу Класса Брони разодетого персонажа

Тяжелая Броня / Средняя Броня / Легкая Броня

некие отличия ,например : Кожа сверху дает дополнительную защиту от Стрел - взякость ,

но без ничего под кожей - вроде кольчуги - само по-себе оно так не поможет , или же болты арбалета вязнут в кольчуге и хорошо соскальзывают с лат , но прохлопывают кожу и стрелы иногда соскальзывают с лат и иногда пробивают их - если нет ни кольчуги , ни кожи

то все это уже ранения персонажу , причем с кольчугой/кожей максимум ушиб или ничего : здесь влияет что в каком порядке одето

против стрел выгодно доспехи-кожа ,

в ближнем бою от прорезных ударов по доспехам выгодна кольчуга

и кольчуга выгодна всегда

против разрезных ударов мечем / прямых ударов кинжалов

далее кольчуга + кожа против болтов почти без урона

на средней и дальней дистанции ,

а доспехи против болтов будут изнашиваться быстрее

причем от стрел почти не изнашиваться - когда если доспехи не пробиты , и т.д.

тогда и гемплейная механика крутится , и сам геймплей стремится к реализму внутри самой игры , игра становится реальной игрой

реально круто !!

Латы : под этим подразумеваются доспехи но на самом деле Латы это Крепкие Пластины Брони

из железа или даже кости

которые одеваются / накидываются поверх Экипировки Персонажа

болты сминают Доспехи , а Латы уже почти нет

Стрелы никогда почти не пробьют Латный Бронник

и с высокой вероятностью соскользнут с Доспехов

Кольчуга держится долго но должна иметь

кольчужный капюшен и кольчужный подбородок

и часто без капюшена имеет смысл длина / высота

самой Кольчуги : должна зарыть шею и покрыть бедра

если нехватает Длины Кольчуги : то ее можно скомпенсировать

за счет Кольчужных Рукавиц / Шлема с "Подзатыльником"

латные налокотники и поножи тоже помогут делу ...

для Копейных Аренных Всадников : Жустин Арена

имеет смысл в о'Круглых Доспехах для большой скорости

когда по ним сложно попасть и тем более пробить стрелами

и даже болтами : но под Доспехами лучше иметь Кольчугу

и быть Рыцарями - а обычные Всадники "Шевалье"

зачастую имеют просто Кожаные Доспехи под Железными Доспехами

так как Плести Кольчугу гораздо дольше чем Вырезать Кожу / сшить

Баллок :

кинжал с усиленным клином, предназначенным для пробивания доспехов.

Это название он получил благодаря моде носить кинжал на поясе спереди.

Был весьма популярен в Скандинавии, Англии, Шотландии в XIII—XVII веках.

Баллок использовали для самообороны купцы, ремесленники и другие представители среднего класса.

Изначально рукоятью служил однородный кусок дерева , однако позже для изготовления рукояти стали использовать другие материалы вроде рога, слоновой кости или полудрагоценных камней. Начиная с XV века, в рукояти стали проделывать небольшое отверстие

карман, который использовали для хранения дополнительных предметов и инструментов.

геймдизайн в программировании

можно в качестве варианта привести такую штукенцию

даже в некотром роде применимую в игровом плане при разработке

вроде диалогов или Логики НПС- ов в игре

.. в зависимости от Рейтинга Отношений

ака принадлежности к союзничеству или контр-союзничеству

в отношении персонажа или иных вариациях

2+2 = 4

Вор : 2+2 = 3 : это же очевидно , не пойман - невор : "откуп" / "подкуп"

Ревизор : 2+2 = 5 : очевидно что у вас чего-то не хватает , по-другому и быть не может

и значит должно быть больше , так где оно ?! : "взятка"

Ученый : 2+2 это либо 3 , либо 4 , либо 5 :

но 3 и 5 это уже пара вариантов ,а 4 всего один

"явно вы не правы" / "вы явно не правы"

так как других вариантов больше : "лобби"

программирование геймдизайнерам

так как геймдизайнеры все дизайнят

не учитывая аспекты программирования

то вот тема для понимания

программирования для геймдизанеров

геймдизайнерский взгляд программиста изнутри игрового приложения

просто чтобы не ждать пока найдутся желающие углубится в изучение

приведем некие базовые подходы в программировании с использованием

платформы движков , то есть как это в общем происходит в игро-движках

________________

сцена или форма

сцена : безразмерное плато как бы пустое ,но не null

форма : более ограниченное пространство - но на нее можно положить сцену

как можно положить сцену на форму : также как панель (катет-на-катет) или радиусное плато

или же сцена уже есть как безразмерное визуальное

что же делать дальше - сцена будет формой - для быстроты понимания

например , образно 3/4 экрана формы это графический экран отображения графики - форма

1/4 под формой - это панель инструментария , вроде кнопок или аватаров

на форму кладем кнопку , например , есть только значек кнопки и кнопка без-форменная

то есть кликнув правой клавишей мышки на кнопке уже лежащей на форме-панели-приложения

можно выбрать в свойствах кнопки ее форму-представление : например , квадратная , круглая , клякса

и цвет кнопки и надпись на кнопке , пользователь будет наблюдать при запуске только эту кнопку

запустив приложение и сделав клик по кнопке , далее пользователю откроется меню игры

то есть кнопка с надписью игры скрывается , а появляется меню вашей игры

как же это происходит внутри программы : нажав на кнопку , лежащую прямо на форме ,

в сервисе движка программирования открывается скрипт-меню в котором есть

шапка описание говорящее ,что данный скрипт является и назван клик-скриптом-название_кнопки

в клик-скрипте-название_кнопки можно указать , допустим , перейти на исполнение процедуры

вызывающей процедуру появления на экране меню-игры со стандартным списком действия

после чего процедура вызова появления меню на экране закончится и появится само меню на экране

само меню состоит из вертикального стека-кнопок которые можно прописать что с ними делать

например , кликнув Авторы - данная кнопка вызовет появление Меню Авторов

где записаны данные о авторах программы - они записаны на диске в файле имя_приложения_игры_инфо_авторов

для простоты понимания это файловый текст , то есть файл.txt

например , в юнити чтобы сохранять / загружать такие файлы применяют технологию JSON :

технологии либо встроены , либо в строчке кода где есть надпись uses

uses (использование) подключить модуль JSON

просто пишется-добавляется надпись JSON и все

подключаемые технологии перечисляются через запятую

они занимают память - оперативную память компьютера и потому подключены не все сразу

а подключаются только те которые нужны в данный момент , но

отключать их уже не нужно или исчезнут

так нажимая кнопки на Меню Игры можно доступаться в разные разделы игры

чтобы запустить саму игру нужно нажать Запуск / Старт игры или

выбрать Загрузить кликнув на кнопке меню

запуская игру мы включаем новую Форму Игры то есть Панель Игры

на которой будут находится объекты игры

и начинаем прописывать кнопки-объекты как ввиде объекты-персонажи или

объекты-ландшафта на форме игры

то есть объекты хоть большие хоть маленькие это теже кнопки ,

ландшафт-плато это большущая кнопка-панель

на нее как на панель расставляются объекты

все объекты как кнопки по клику получают Фокус Объекта (Данного)

то есть вроде Базовый Клик по Игровому Объекту

с него можно начать контролировать действия объекта

выбрав Путь Объекта - вроде мы кликаем мышкой по Плато-Кнопке

в данный момент может возникнуть необходимость прокрутить движение объекта

как в анимации-объекта так и в само передвижении объекта

то есть анимация-объекта настраивается отдельно , а

передвижение - это процедура исполнения функций передвижения

в программировании сначала идут Процедуры , а рассчеты ведутся через Функции или иные процедуры

передвижение это уже Логика Передвижения - например , при матричном варианте сетки передвижения

вроде икс-игрек то будет вид Movie_matrix(gameObject_focused)

при гексагональном то будет вид Movie_hex(gameObject_focused)

вместо focused можно подставить Избранный Объект ввиде Default | Kind :

каинд , выбранный / избранный

то есть тот который мы выбираем путем Перебора Объектов

используя вертикальный Стек списка объектов игры

и так далее используя процедуры прописываются действия объектов

например , продвинутые пользователи в роли геймдизайнеров умеют левел-дизайнить

убирая камни с ландшафта или расставляя деревья ,

реке можно повесить скрипт стремина-течение в какую сторону

но это сродни визуальному программированию в котором нету циклов которые используются внутри программирования

в принципе , подключение скрипта в визуальном программировании к объекту

сродни подключения технологии в движке

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

Кряж : для программирования игр такой тип гор более выгоден

так как имеет длинную вытянутость при минимальной ширине

то есть экономит память и игровое пространство

обеспечивая высокое визуальное представление в играх

стыкуя кубики к кряжам идет расширение кряжей ,

получаем уступы куда может залезть персонаж или создадим пандусы

Класс Объекта "Кряжный Кубик"

все объекты могут иметь Массовые Исполнения , но в Одиночном виде

то есть кликнув по любому уступу мы перейдем в процедуру исполнения данного кряка

Тип Кряка : вдобавок ко всему можно распределить кряки по типам

причем вверху будет сохраняться Класс Объекта

________________

как определять в процедуре какой тип кряка кликнут и

почему он находится именно там где и вы-персонаж , ввиде игрового персонажа

и где и как найти его внутри программы , и вообще что делать со всем этим и как это сделать

все эти вопросы геймдизайнер может обдумать сам

и описать свои варианты ...

мануал по космическим и фентези играм

для понимания что есть внутри игры

скорее со стороны игрока - расписанное кодером

"технологии звездных войн"

alice wolfraider arsenal

в этой теме мы рассмотрим базовую архитектуру

программирования как такового и не только по Юнити

а и общие понятия и принципы реального программирования

в сущности программирование в движках вроде Анриала / Юнити

есть конструкторское программирование на уже готовых объектах

чаще находящихся на сценах : то есть Скрипты крепятся к Объектам

ака Скрипты_кода крепятся к Объекту с которого происходит

выполнение скрипта в момент Апдейта : обновления логики программы

чаще это Апдейт в Юнити Игровом Приложении происходящее

по-кадрово - то есть как говорят кодеры "по фреймам" / "по кадрово"

так как фрейм это рамка экрана ... но как бы само программирование

зачастую остается именно за рамками такого конструктора

так как одна из самых больших сложностей есть момент

когда по-требуется пересложить проект .. но как это сделать

тогда нужно перегрузить все-все сотни и может в общем

тысячи объектов с разных десятков Сцен где они имею

свое начальное место-расположения и прикрепить каждому

вручную все те скрипты которые им предназначаются

так такая задача сложна даже для крупной команды

а не то что с этим справится несколько коммандос

то есть момент автоматизации программирования

также имеет место быть рассмотренным

к тому же сохранение и загрузка данных проекта

как и игровой прогрессии Игрока в Игре

есть также зачастую основополагающим механизмом

работы с проектом и игрой как таковой ...