И вот мы здесь! Добро пожаловать на первый урок.

В этом уроке вы создадите ваши первые акторы и будете введены в основы Akka.NET.

Основные понятия / предпосылки

---

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

Вас интересуют игры? Хотите создать игру но не знаете с чего начать? Тогда вам сюда. В этой статье я рассмотрю простейший физический движок, с построения которого можно начать свой путь в GameDev'e. И да, движок будем писать с нуля.

Мой странный творческий путь занес меня в разработку игр. Благодаря отличной студенческой программе от IT-компании, название которой СостоИт из одной Греческой МАленькой буквы, сотрудничающей с нашим университетом, удалось собрать команду, родить документацию и наладить Agile разработку игры под присмотром высококлассного QA-инженера (здравствуйте, Анна!)

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

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

Введение

В первой части статьи мы рассмотрели импорт спрайтов в Unity3d и некоторые особенности импорта.
В этой же статье я хочу поговорить о Листах Спрайтов (SpriteSheets).

SpriteSheets как они есть

SpriteSheets значительно облегчают работу со спрайтами и анимацией. Эта функция позволяет разбивать спрайты в одном файле на отдельные кадры анимации. Слишком заумно и много букв. Внизу иллюстрация.

Здравствуйте, уважаемые читатели.

Сегодня мы хотели поговорить с вами на тему «все новое — это хорошо забытое старое» и вспомнить об акторах, описанных Карлом Хьюиттом еще в начале 70-х. А все дело в том, что недавно вышла вот такая книга:



Она довольно объемная — в переводе должна получиться более 500 страниц.

Несмотря на подчеркнутую элитарность книги (Akka и Scala), ее автор Вон Вернон (крупнейший специалист по DDD) уверен, что архитектурные паттерны, описанные в этой работе, вполне реализуемы на .NET и C#, о чем рассказывает в приложении. Мы же размещаем под катом перевод статьи, автор которой допускает перенос акторной парадигмы на язык Java. Поскольку рейтинг книги на Amazon стабильно высок, а тема универсальна, просим поделиться вашими мнениями как о ней, так и об акторной архитектуре в принципе.

Данный материал изначально был подготовлен в качестве раздела статьи “Первые шаги в Robocode”, но я решил вынести его, т.к. он значительно увеличивал размер и без того большой первоначальной статьи и не является базовым и необходимым для осуществления первого шага. Если вы сразу заинтересовались вторым шагом или постепенно доросли до него, то прошу под кат.

Данная статья посвящена широко известному методу Монте-Карло, который основан на теории вероятностей и математической статистике, в физике элементарных частиц. Так же, я расскажу, как можно разыгрывать дискретные и непрерывные случайные величины методом Неймана, а на закуску посмотрим, как применять ММК в ФЭЧ.

Сразу замечу, что моделирование будет производится в САВ WM, которую я применял (не так давно) в своей первой статье.

^{В ситуации полной и беспросветной задницы власть в AI сразу забирали военные, и это иногда спасало партию.}

Для нашего AI Шакала пришлось написать целых 4 разных AI, каждый из которых отвечал за свою задачу. А затем они собирались вместе и голосовали за то, что же делать пиратам на поле в этом ходу.

Вся эта сложная система понадобилась, потому что у нас не было единой оценочной функции. Грубо говоря, AI бывают двух типов: когда понятно, как численно оценивать вашу позицию, и когда это совершенно непонятно. Та же партия в Го в определённый момент превращается в поединок интуитивных догадок, то есть сваливается в неалгоритмизируемую по сложности и по неопределённости задачу.

Давным-давно мой преподаватель профессор Сербин рассказывал байку с сыроваром из Европы. К этому обаятельному толстяку приезжали автоматизаторы и спрашивали, как он делает такой вкусный сыр. Им нужны были эвристики для температуры, густоты и так далее. Сыровар опускал палец в мягкий сыр, медленно и кайфно чертил там дугу, улыбался во всё хитрое лицо и говорил: «Ну как вы не чувствуете!».

Алгоритмизировать процесс гости так и не смогли. Так вот, разработка шла так: мы чертили дуги и хитро улыбались, а парни проигрывали нам в настольный Шакал. И мечтали, что за них отомстит AI.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Если вы хотите научиться программировать первоклассные игры, вам просто необходимо изучить язык С++. Эта книга поможет вам освоить разработку игр с самых азов, независимо от того, есть ли у вас опыт программирования. Гораздо интересней учиться, когда обучение превращается в игру. Каждая глава книги описывает самостоятельный игровой проект. В заключительной главе вам предстоит написать сложную игру, которая объединяет все приемы программирования, рас-смотренные в предыдущих главах. Книга идеально подойдет для начинающего программиста, планирующего не только как следует освоить непростой язык С++, но и поупражняться в программировании игр. Цель данной книги — познакомить вас с языком С++ в контексте программирования игр. Хотя невозможно представить себе такую книгу, которая сделала бы вас мастером в двух столь объемных темах, как программирование игр и язык C++, это издание пригодится вам в качестве вводного курса.

Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

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

«Спор возможен там, где истина закрыта. В бесплодных спорах можно бесконечно обсуждать, что в комнате находится закрытой дверью. Но стоит дверь открыть, и ясно станет всем и спорить не о чем, коль каждый истину увидеть сможет»

Владимир Мегре



Статья посвящается Зацепину П.М., выдающемуся инженеру Алтайского государственного университета, под чьим чутким руководством многие студенты, включая автора статьи, постигали магию инженерного творчества.

Введение

Спор о возможности использования в программах оператора GOTO ведётся уже очень давно (официальным его началом признана статья Дейкстры «О вреде оператора GOTO», опубликованная в 1968 году [2]). Через три года мы будем праздновать 50-летний юбилей этого спора. Это хороший повод, чтобы наконец-то «расставить все точки над i» и прекратить спор.

Цитата в эпиграфе выбрана неслучайно. Она в точности отражает текущую ситуацию в споре про GOTO. В нашем случае «комната за закрытой дверью» – это понятная всем постановка задачи. Пока, к сожалению, такой постановки задачи озвучено не было, поэтому споры и не угасают. Противоборствующие стороны спорят хоть и о схожих, но всё-таки о разных вещах, поэтому и не могут найти компромисса.

Давайте займём в этом споре нейтральную сторону, и беспристрастно во всём разберёмся. Рассмотрим доводы «противников» и «защитников» оператора GOTO и решим, «кто из них прав, а кто виноват».

Есть такой парень Влаада Хватил. Он живёт в Чехии, любит играть и время от времени выпускает какую-нибудь мелкую штуку. Несколько лет назад очередная «мелкая штука» взяла и порвала рынок сначала Чехии, потом Европы, а потом и США. Ну и наш немного.

Он сделал игру «Космические дальнобойщики», второй тираж которой почти не доехал до магазинов – разобрали на предзаказах. Третий тираж ждала вся Европа – я помню, в Праге продавец в магазине назвал мне точное количество дней до поставки. Они там считали каждый час и вели тетрадку учёта предзаказов. Толстую.

Этой игрой Влаада добавил новый атом в список механик настолок (что случается раз в пару лет) – механики реального времени для походовых игр. Так вот, я поговорил с ним о разработке, в особенности – о том, какие грабли были при переносе его игры в приложение.

Получился разговор вообще о том, что делает игру интересной. За жизнь такой.

Когда-то давно мне понадобился парсер математических выражений на C#. Конечно, скачать готовую реализацию — не проблема. Но вот только Интернета у меня в те годы не было. В итоге абсолютно без раздумий и без теоретических основ парсеров, конечных автоматов и прочего он был написан через регулярные выражения. Минут за 10. Стоит отметить, что нужны были только арифметический действия и скобки. Поддержка тригонометрических функций и прочего не требовалась.

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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

Корутины (Coroutines, сопрограммы) в Unity — простой и удобный способ запускать функции, которые должны работать параллельно в течение некоторого времени. В работе с корутинами ничего принципиально сложного нет и интернет полон статей с поверхностным описанием их работы. Тем не менее, мне так и не удалось найти ни одной статьи, где описывалась бы возможность запуска группы корутинов с продолжением работы после их завершения.
Хочу предложить вам небольшой паттерн, реализующий такую возможность, а также подбор информации о корутинах.

Привет Хабр!

Относительно недавно на кикстартере завершился сбор денег на новый инструмент для игроделов, но на Хабре это не было освещено. Spine —программа для создания скелетной 2d анимации. Этот инструмент будет интересен не только инди-разработчикам и начинающим гейм дизайнерам, но также опытным игрокам рынка. Простота в использовании и притягательный дизайн создают впечатление творящегося на экране волшебства.

Всех заинтересовавшихся прошу под кат (много картинок).

Сегодня я поделюсь своей наработкой игры «Maze». В этой игре реализован алгоритм DFS. На днях мне поручили сделать курсовую работу по Алгоритмам, а именно по DFS в лабиринтах. Отказываться было нельзя. Пришел домой, выпил чашечку крепкого кофе и начал творить.

Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и наслаждается полученным результатом. Но вскоре он понимает, что для того, чтобы управлять менюшкой, хорошо бы знать закрыто оно сейчас или нет. Мы-то с вами тут программисты опытные, все понимаем, что нужно добавить флаг. Не вопрос, флаг есть.

var opened = false;

Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:

var opened = false;
var animating = false;

function onClick(event) {
  if (animating) return;
  if (opened) close();
  else open();
}

Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

Знакомьтесь, это Вася.

При разработке нам понадобился простой конечный автомат, желательно уже реализованный. Из списка реализаций, который предложил гугл, выбрали этот, за простоту и компактность. Используем у себя, в целом FSM неплох. Далее под катом перевод оригинальной статьи автора из Греции Tasos Giannakopoulos. Я не переводчик, поэтому я старался передать смысл, иногда объясняя суть своими словами, за что извиняюсь перед перфекционистами.