🎯 Хорошие новости для всех, кто ждал возвращения в опасный и загадочный океан. Продолжение знаменитой выживалки обрело более конкретные сроки. Релиз в раннем доступе действительно состоится этой весной.
🎯По информации портала IGN, команда Unknown Worlds наконец готова поделиться точными планами. Разработчики подтвердили, что их новый проект отправится к игрокам уже в мае.
Эту новость лично сообщил действующий глава студии Стив Папутсис в своем обращении к коллегам и фанатам.
Как продвигается разработка
1/5
🎯Оказывается, последние девять месяцев были для студии очень продуктивными. Этот период прошел с тех пор, как в команде произошли небольшие кадровые изменения. Судя по всему, они пошли проекту на пользу.
Папутсис рассказал, что за это время команда не сидела сложа руки. В игру добавили много нового: свежие сюжетные повороты, неизведанные биомы под водой и, конечно, новых морских обитателей (некоторые из них наверняка снова захотят вами пообедать).
Главное, что игра уже успешно прошла внутреннюю проверку у издателя Krafton. Это значит, что руководство довольно результатом и согласно, что проект практически готов к выходу. Осталось доделать последние детали, и можно будет нырять с головой.
Я соло-разработчик. Решил поделиться тем, что у меня получается. Делаю игру, вдохновленную Undertale. Знаю, что многие советуют начинать с маленьких платформеров, но у меня к ним просто душа не лежит — я бы в такое сам играть не стал. Поэтому сразу взялся за крупный проект.
О разработке:
Движок: GameMaker. Выбрал его, потому что программирую я не очень, а там низкий порог вхождения и куча гайдов.
Команда: Я один. Конечно я пробовал искать людей, но попадались либо школьники (которые работают только на каникулах), либо сомнительные персонажи. А т.к у меня нет денег, достойных людей мне не удалось найти. В итоге решил всё тянуть в соло.
Что сделано: Потратил уже больше 1000 часов. Пришлось с нуля учиться кодить, писать музыку и сценарий. Сам я художник, рисую в пиксель-арте, поэтому графика — это то, во что я вкладываюсь больше всего.
Как менялась игра:
Раньше проект выглядел вот так:
Сейчас фрагмент игры выглядит так:
Текущее состояние:
До релиза даже тестовой версии ещё далеко. Сейчас плотно сижу над сценарием. Честно скажу, от перегрузки мозги иногда дают сбой, тяжело даже просто рисовать, не то что придумывать диалоги. Вдохновляюсь примером Темми Чанг.
Я в детстве часто играл в Zuma и подобные игры. И однажды подумал: "А почему бы не сделать свою? Только добавить туда всего, чего мне самому не хватало". Спойлер: я недооценил масштаб трагедии. То, что казалось простой задачей, обернулось сотнями часов копания в коде, рисованием спрайтов в три часа ночи и дикими плясками с бубном вокруг оптимизации.
Но я справился (надеюсь 😅). И теперь хочу рассказать, почему в эту игру стоит залипнуть.
Что за зверь?
Механика классическая, но, блин, работает же! По извилистой дорожке ползет очередь из разноцветных шаров. У меня есть пушка, из которой я стреляю такими же шарами. Цель — составлять комбинации из трех и более шаров одного цвета, чтобы они взрывались. Если цепочка доползет до конца — я проиграл.
Но я напихал туда столько всего, что сам иногда офигеваю:
300 уровней. Да, вы не ослышались. Триста. Я рисовал их, тестил, перерисовывал и снова тестил. Каждый мир — новая локация, от зеленых джунглей до мистических храмов. Путешествие получается знатное.
Стратегия. Если вы думаете, что это просто "кликай быстрее", — нет. Придется включать голову. Иногда надо специально оставить один шарик с краю, чтобы потом обрушить всю цепочку. Когда ловишь такой момент — чувствуешь себя гроссмейстером.
Плюшки и препятствия. Я добавил бонусы, чтобы облегчить вам жизнь (замедление, бомбочки, авиаудар), и препятствия, чтобы ее усложнить (лед, камни, всякая чертовщина). Сам же потом мучился, проходя собственные уровни. Баланс — штука тонкая!
Атмосфера
Мне хотелось, чтобы глазу было приятно. Я не профессиональный художник, но старался подбирать сочные цвета и делать анимацию лопающихся шаров максимально вкусной.
Ликбез для новичков
Вдруг кто-то первый раз видит такую игру:
Целься и стреляй: Нужно соединять шары одинакового цвета по три штуки.
Не спи: Шары ползут неумолимо. Допустишь до финиша — проиграл.
Чистка: Чтобы пройти уровень, нужно уничтожить все шары на дорожке.
Комбо: Бей не абы как, а с умом. Устраивай цепные реакции — будет и приятно, и очков много.
В общем, я вложил в эту игру душу. Надеюсь, она вам зайдет так же, как зашла мне (пока я ее тестировал в сотый раз). Если найдете баги — пишите, не стесняйтесь! Я тут один, но я чинимый.
Заходите в Zumma Travel Deluxe, постреляйте шариками от души. Составите компанию одинокому разработчику! 😉
Недавно на Хабре вышла статья «Почему наш язык — худший язык для программирования». Автор справедливо отметил проблему двусмысленности естественного языка (ЕЯ) и предупредил, что программирование словами приведет к хаосу.
Я начну с неожиданного: автор оригинальной статьи абсолютно прав.
Он прав, если мы говорим о программировании заклинаниями (vibe-coding) — популярном сегодня подходе, когда человек пишет в окно чата: «Сделай мне интернет-магазин с красивым дизайном», а потом тонет в неконтролируемой лапше сгенерированного кода. В формате свободной болтовни с ботом естественный язык для написания кода действительно ужасен.
Но естественный язык можно использовать по-другому. Можно не просто болтать с ChatGPT — это ошибочный метод программирования на естественном языке. Его надо использовать как основу для строгих декларативных спецификаций.
Инструменты вроде CodeSpeak (публичная альфа-версия от создателя Kotlin Андрея Бреслава, о которой я подробно писал в своей статье) уже сегодня демонстрируют свой огромный потенциал: если загнать естественный язык в рамки контрактов, он способен стать лучшим, самым высоким из доступных нам уровней абстракции.
Будущее разработки: перекладывание JSON-ов или контроль смыслов через ИИ?
Эволюция роли разработчика: от ручного управления синтаксисом до архитектурного контроля смыслов с помощью ИИ.
Переход от ручного кодинга к управлению спецификациями: почему естественный язык становится новым инструментом архитектурного контроля смыслов, а роль разработчика трансформируется в валидатора ИИ-систем.
Миф №1: «Придется писать в 10 раз больше текста»
Оппонент утверждает, что для точного описания логики на английском или русском потребуется в 10 раз больше слов, чем в коде. Практика CodeSpeak доказывает ровно обратное: объем того, что поддерживает человек, сокращается в 6–10 раз.
В CodeSpeak вместо написания кода вы пишете спецификацию в Markdown-файле .cs.md. Это не роман и не поток сознания. Это структурированный естественный язык, упакованный в жесткий Markdown-формат с четкими разделами (входные данные, структура вывода, требования).
Взгляните на реальный пример спецификации из моей статьи:
``` # EmlConverter
Converts RFC 5322 email files (.eml) to Markdown using Python's built-in `email` module.
## Accepts
`.eml` extension or `message/rfc822` MIME type.
## Output Structure
1. **Headers section**: From, To, Cc, Subject, Date as `**Key:** value` pairs 2. **Body**: plain text preferred; if only HTML, convert to markdown 3. **Attachments section** (if any): list with filename, MIME type, human-readable size
## Parsing Requirements
- Decode RFC 2047 encoded headers (e.g., `=?UTF-8?B?...?=`) - Decode body content (base64, quoted-printable) - Handle multipart: walk parts, prefer `text/plain` over `text/html` - For `message/rfc822` parts: recursively format as quoted nested message - Extract attachment metadata without decoding attachment content ```
Здесь нет синтаксического шума, бойлерплейта или ручного управления памятью. Здесь описана чистая бизнес-логика и контракты ввода-вывода. LLM (например, Claude Opus) читает этот файл, генерирует код и тесты. Синтаксис программирования не умирает — он просто поднимается на уровень выше, скрываясь под капотом LLM-компилятора.
Миф №2: Ловушка зеленых тестов
Автор оригинала пугает нас тем, что всего через десяток-другой изменений проект превратится в «клубок», где новые фичи ломают старые, а нейросеть пишет неправильный код, который проходит такие же неправильные тесты (ведь машина выполнила двусмысленный запрос формально верно).
Это реальная проблема, но она решается жесткой архитектурной изоляцией, которую, например, предлагает CodeSpeak или другой аналогичный инструмент разработки.
В CodeSpeak ИИ не работает в режиме «перепиши мне всё». Обычно он ограничен рамками одной или нескольких связанных спецификаций. Изменение логики парсинга писем никогда не сломает модуль оплаты, потому что LLM работает строго в границах локального контракта.
А как же тесты? Да, LLM пишет их сама. Но здесь меняется роль человека: он становится архитектором смыслов. Разработчик больше не ищет пропущенные запятые в Python-скрипте, он проводит ревью спецификаций и сгенерированных тест-кейсов. Двусмысленность устраняется на этапе согласования требований человеком, а не на этапе генерации.
Миф №3: «В точных науках нужен строгий формализм, а не слова»
Оппонент ссылается на аппаратные ограничения и математическую точность. Да, если вы пишете драйвер для видеокарты или ядро СУБД, вам нужен Rust или C++.
Но 90% софта в мире — это бизнес-логика. И здесь уместно вспомнить, как работают сами математики. Дональд Кнут в «Искусстве программирования» дает алгоритмы в строгом MIX-ассемблере, но обязательно подробно объясняет их на естественном языке.
В точных науках формулы нужны для строгого доказательства, а естественный язык — для передачи интуиции и смысла. Математики не общаются только формулами, иначе они бы не поняли друг друга.
В программировании будущего будет точно так же:
Человек использует естественный язык для проектирования архитектуры и бизнес-правил.
LLM берет на себя «механические вычисления» — трансляцию этих правил в Python, Java или Go.
Комментарии в коде — лучшее доказательство
Вспомните самую сложную и запутанную часть вашей кодовой базы. Скорее всего, над ней висит огромный комментарий на естественном языке.
Почему? Потому что код отвечает на вопрос «как», а естественный язык отвечает на вопрос «зачем». Код не способен передать высокоуровневую мотивацию и граничные случаи так же емко, как это делает человеческая речь. И именно эти комментарии сегодня помогают LLM-моделям при рефакторинге не терять суть задачи. Так почему бы не сделать эти «комментарии» самим источником истины (Source of Truth)?
Эволюция языков программирования не остановится на Python
Мы уже прошли долгий путь: машинный код → ассемблер → C → Java/Python. Каждый шаг — это отказ от ручного контроля в пользу более высокой абстракции.
Делегирование рутины компиляторам — это естественный прогресс. Да, пока мы находимся на этапе тестирования публичных альфа-версий подобных инструментов, но LLM — это просто следующий, сверхмощный компилятор, который уже сегодня понимает естественный язык без критических галлюцинаций, если его загнать в достаточно простые рамки формализма спецификаций.
Естественный язык в виде неструктурированной болтовни — действительно худший инструмент разработчика. Но естественный язык, упакованный в достаточно строгие контракты с автоматической кодогенерацией и тестами — это лучший язык программирования. Он детерминирован рамками модуля, он понятен бизнесу, и он позволяет инженеру быть инженером, а не синтаксическим принтером.
Пришло время перестать бороться с естественным языком и научиться его правильно готовить.
Что думаете? Готовы ли вы делегировать написание кода LLM, оставив за собой контроль контрактов, или продолжите вручную перекладывать JSON-ы до пенсии?
