Ну, можно, конечно, js. Но на шарпе на юнити писать удобнее - под него лучше заточено API, он чуть быстрее (вроде), меньше костылей в синтаксисе, да и всякие лямбды, генерики и т.д. JS там не настоящий, а просто интерпретация шарпа для рантайма Mono с синтаксисом js'а. Можно и на нем, конечно, плохо не будет, но зачем, если есть более удобный для таких задач язык?
Unity3d (C#). Можно еще попробовать Unreal Engine (C++), но он несколько сложнее и язык хардкорнее, выбирать его нужно скорее при наличии команды опытных разрабов. Инди игра для души - unity лидирует.
Вот в том и проблема - в создании инди игр лишь иногда линейный матан нужен (векторы, кватернионы, матрицы и т.д.), физика разве что в космо/авиа симуляторах может пригодиться. По крайней мере если движок не сам пишешь (а для создания игры в одиночку это верный способ перегореть, особенно без обширных знаний и опыта).
Странно, я о ЛЭТИ много негативных отзывов слышал, хоть и поучавствовал (и даже выиграл) в одной их конференции. Внутри все довольно обшарпанно, но самого процесса обучения не видел. Знакомые говорят, что КТ слабее чем у других ВУЗов, кому верить?
Спасибо, это как раз вписывается в концепцию "очереди" - учитываются и "важность" оборудования и его потребление. Суть в том, что игрок может менять распределение энергии при необходимости, но при желании нажать кнопку и выполнить распределение автоматически.
Было предложено вот такое решение проблемы разрастания класса корабля:
В базовом классе оборудования разместить метод Active(Ship ship), который будет считать действие для данного оборудования, реализовывать в наследниках. И в классе корабля разместить только переменные - ту же скорость, например. Когда кому-то нужна, например, скорость, запускается проход по всему оборудованию и выполняется их метод Active, обновляются перемнные. Ну не знаю, лично мне кажется это не очень хорошее решение - в классе корабля все равно куча переменных, лишние сложности, постоянный пересчет, проблема неопределенности - результат активности прибора может зависеть от другого, а оно может быть еще не пересчитано.
Интереесное решение, спасибо. Каркас мне не нужен, все равно мне это нужно написать для своего корабля. Выглядит интересно, попробую сделать такое для корабля. У меня даже проще - проводов нет, только потребители и генераторы. Тогда можно выстроить своеобразную очередь потребителей в зависимости от важности системы. Спасибо.
Энергия в ваттах, отдельно в виде количества она не хранится - только потребляет / вырабатывает, все упрощено. У меня такая проблема - то ли просто у каждого прибора в списке сделать поля inputPower и считать все независимо, проходами по всем приборам, как вы написали, либо применить нечто более сложное, связать их как-нибудь. Может графы какие-нибудь, даже не знаю.
Моя психика сломана: оказывается к листам можно индексный оператор. Почему-то на прошлые мои попытки IDE ругалась, когда как раз первый вариант с i-- хотел реализовать. А сейчас вроде прокатило. Спасибо, пробую.
С копией не проходит - во время выполнения цикла элементы взаимодействуют между собой, если работать с копией, то обрабатываемый элемент может либо быть уже удаленным, либо взаимодействовать с удаленным.
Вот с итератором я и не понял - как? Понятно, что из foreach нельзя, в этом и затык.
