Я в общем-то и не спорю с тем, что это общепринято и что sender полезен. Я о том, что EventHandler появился еще до generic делегатов, поэтому Object в качестве типа sender был оправдан. Но в современных версиях .NET в таком приеме уже и смысла нет. Одну проблему даже решили - добавили EventHandler, чтобы не приводить к наследнику EventArgs, но этого же мало. Хотя и исправить сложившийся порядок уже нельзя.
Впрочем, это, видимо, скорее дело вкуса/кодстайла, я больше опасался каких-то скрытых технических подводных камней, но вроде как их и нет, спасибо за ответы.
Уже не первый раз слышу хорошие отзывы об этой библиотеке, видимо стоит ее изучить)
Но все же и обычными нужно уметь пользоваться при необходимости, т.ч. все же интересно, почему все используют EventHandler там, где проще и чище будет с Action.
В данном случае я сам себе гейдизайнер, да и вряд ли геймдиз будет думать над технической реализацией взаимодействия Модель - GUI, видимо не очень понятно вопрос сформулировал, но да ладно.
Спасибо за ответ, в моем случае это космический корабль, в котором есть некий набор оборудования (сопла двигателей, реакторы и т.д.), а логика примерно такая же получается, разве что чуть больше контроля над состоянием потребителя.
Правда, я, наверное, не совсем правильно сформулировал вопрос - поведение в любом случае будет таким же, просто вопрос, в какой части кода делать проверку - в модели или представлении. Вариант с обработкой в модели (второй) сейчас отлично заработал, вопрос больше философский, просто поинтересовался, не будет ли это сродни swallowing exception и прочим подобным вещам. Но вроде в данном случае особых проблем это не вызывает.
Михаил Усоцкий: т.к. использую под unity3d, пока не готов выкладывать 25$ за форк открытой библиотеки, когда существуют альтернативы. Как оказалось, использовал устаревший форк jsonfx)
За GUID спасибо, буду изучать.
А по поводу сохранения - просто еще не реализовал сериализацию этого дела. Делаю игру под юнити, без сетевого взаимодействия, т.ч. только простая (относительно) механика save/load, там ввести дополнительные способы задать id при десериализации не проблема (а какой-нибудь DataContractJsonSerializer вообще сам приватный id восстановит, но идея использовать объекты, распакованные им напрямую без использования конструктора мне кажется не самой хорошей, хотя возможно я и ошибаюсь).
Спасибо за ответ, видимо действительно велосипед выдумываю. Вообще, были мысли, что такая реализация GetHashCode будет немного быстрее + исключит совпадение хешей у разных объектов, но возможно я просто не вижу каких-то проблем, т.ч. оставлю дефолтную. Да и Equals получился медленее, чем ReferenceEquals, странно, что сразу не заметил.
Геометрическую сторону вопроса уже более менее описали, но вот в массив лучше никого не закидывать, у нас тут ООП/КОП. На врага повесить скрипт, который проверяет (каждый кадр, видимо), находится ли он за пределами экрана, и если да, то перемещающий свой маркер на вычисленные координаты. (с точки зрения производительности лучше будет некий pool маркеров, но можно и просто в префаб врага его личный маркер положить и двигать/включать/отключать).
Оптимизация: выкинуть interselect, идти по листам, если словарь не содержит элемента, добавить со значением 1, иначе инкремент. Потом выкинуть всех, у кого количество <2. Вроде так быстрее должно быть, хотя все равно много операций со списками.
Стоит добавить, что у меня не стоит задачи подгружать данные динамически (для чего как раз удобны БД) - все игровое состояние сохраняется и загружается полностью, не по кускам. Для игры с огромной вселенной типа Elite такой подход может быть слишком накладен и понадобится загрузка данных кусками, что без БД, наверное, не слишком удобно.
Пример - minecraft, с его загрузкой чанками.
Впрочем, это, видимо, скорее дело вкуса/кодстайла, я больше опасался каких-то скрытых технических подводных камней, но вроде как их и нет, спасибо за ответы.