Dungeon 1990: Взгляд изнутри. Код игры
Многие кто не дошел до кода, вот как выглядит мой корявый код (многие или немногие, наверное знают, много способов сделать код лучше)
Вот как выглядят переменные. вы только гляньте сколько их (профессионалы стараются использовать как можно меньше переменных, но я не профессионал мне можно), профессионалы обычно используют объекты, но я об объектах узнал довольно поздно, когда 90% было сделано...
Ну а так выглядит функция монстров, но это только его часть запомнили youLoseBattle = true?
А вот и продолжение
Игру вы можете скачать ниже в этом посту http://gamin.me/entries/30
- 06 мая 2016, 11:18
- 05
Интересно. Не пробовал писать свой мини движок для тестовых игр? А то структура кода не оправдает себя в больших играх - сам проверял).
Нет не пробовал, я вообще о движках знаю только покрыто.
Это я уже понял, когда столкнулся с проблемами.
А ты знаешь как сделать свой движок? Я знаю что многие говорят, я движок сделаю, а потом игру на движке делать буду, а как сделать движок никто не пишет, и что из себя движок представляет.
Правильно, что не говорят. Дело трудное, но интересное. Лично я не занимаюсь сборкой движков и предпочитаю прототипирование в Unity3D.
Сборка движков может основываться либо на готовых библиотеках, например Box2D (физика 2D объектов), которые подключаются к среде программирования (Visual Studio например). Но в твоем случае то всё проще, тут текстовый квест. Если ты не понимаешь о чем я, советую почитать что-нибудь по этой тематике для java именно для текстовых квестов, много полезных статей на Хабре.
особенность движка - самописного - в том, что его можно никогда и не написать
тут лучше сначала игру написать, а потом уже вычленять то, что будет движком
Согласен, я не призываю писать движки, но структурировать код - не помешает).
я только через два месяца профессионального программирования избавился от привычки к спагетти/портянка/шаверма-коду...
Движок в javascript, это функции? Или это что-то другое?
Движок в JS – да и в принципе движок – это готовый функционал для определенных целей. В JS чаще встречается понятие фреймворк, но есть и библиотеки, и движки.
ROT.js – движок для рогаликов на JS. У RPGMaker MV внутри JS-движок, который обеспечивает всю логику и отрисовку игр на нем.
А само понятие движка сводится к тому, что а) твой код можно использовать повторно в собственных проектах и б) к твоему коду есть документированный API, через который с кодом можно работать, не ковыряя его каждый раз ледорубом.
Так, если брать текстовые игры, AXMA – и среда разработки, и движок. Но вот Twine 2 уже среда на фреймворке BackboneJS, потому что в зависимости от оформления (Harlowe/Snowman/SugarCube), у игры будет разный движок, который отвечает за макросы и интерпретацию кода.
Золотые символы!
Но некоторые забывают или не понимаю зачем оно. Кто-то просто фанится от своего движка, а кому-то реально удобнее написать игры свои (хотя опять же фан), а потом КАК РЕФАКТОРИТЬ ВСЁ ЭТО ДЕЛО и получается самописный движок. Короче. СамоДвиг не должен быть целью - целью должна быть игра (или не игра) на нём.
Да, я слоупок... в смысле... я пришёл из далёкого будущего ~ууууу~
Нет, не золотые. Я писал JK-контроллер и некоторые другие вещи совсем отдельно от какой-либо вменяемой игры. И это на Гейм Мейкере, да. Рефактор - более сложно, чем с нуля придумать модульно то что тебе нужно. Вычленять нужное из готового - так себе компромисс, за неимением лучшего.
И потом вспомни как разбираться в этом JK-контроллере :yak:
Думаю смысл слов Чешира (и что я подтверждаю) в том, что ты делаешь N игр и получаешь базу-код и именно этот код был бы основой движка.
В рамках Си\Си++ у меня чуть-чуть получилось - таскал за собой костыли. В рамках ГМ (где всё же имеет место быть слово "движок") тоже сейчас из проекта в проект набор скриптов и каждый раз меняется под нужды. Таким образом к N-ой итерации будет так сказать "движок" определённой части. Ну ладно, не движок, а "библиотека".
Или ты предлагаешь специально что-то писать без игры? Вот это и будет сомнительно. Нет, конечно можно явно это обозначить ранее (как с JK было похоже) - некий модуль независимый. А можно и наоборот - во время разработки игры (что может затянуть разработку и породить костыли) сказать "я это буду использовать и в других проектах" - так я сделал набор скриптов для пушек. Он своеобразный и я уже вижу, что нужна другая версия только лишь для удобства кодера - в игре же всё работает офигенно. (от части).
Эх, как давно не писал простыню текста :yak:
Держи простыню в ответ, раз такой умный! :yakub: Да ещё и меч впридачу!
В JK-контроллере легко разбираться - ты сам это сделал за пару десятков минут, разве нет? Причём ускорить это можно разве что наличием документации. Все переменные названы доходчиво, а остальное видно из самого кода.
Ну, если делать N игр (что делали и ты, и я, и тот самый Хейзер, и другие), то у тебя просто опыта уже появляется достаточно, чтобы писать что-то модульное. А мысль именно "надо писать игры, а из них извлекать модули" кривоватая, я об этом высказался.
Не, я ничего не предлагаю. Но определить полностью модульную контструкцию и её реализовать - это нормальная практика, когда до конца ясно, что от этого модуля нужно. Ну, типа, ZIP-архиватор (неудачный пример, но смысл иллюстрирует). В нашем случае это был бы PAR-архиватор, который ты написал, но это было в рамках КонЕ2, потому что такой тип модуля никак сложно проверить на практике без подлежащей игры.
я на js прототипирую. удобно в плане посмотреть, как разные ролевые системы будут работать.
Может не java, а javascript? Ведь java и javascript, это совсем разные программы.
Языки. Да вы правы, javascript - больше заточен на скриптинг, но думаю даже с опечаткой на java - собеседник меня понял.
А что за Box2d?
Это на случай если тебя в гугле забанили
Код самой игры что на своём движке, что на чужом будет плюс-минус одинаковым. А чтобы большой проект не разваливался, нужно просто следовать правилам хорошего тона в программировании и иметь опыт собственно программирования. Чем больше пишешь кода - тем лучше он становится.
...иногда мне думается, что некоторые люди считают написание своего движка панацеей. Сразу и геймплей лучше будет, и сделать можно больше... Ога, ога. Для начала хоть один нормальный движок хотя бы на 70% освоили бы.
мы напишем свое и лучше - считают они
а что движок это куча объектов, работа с памятью, видеопаматью, математикой и шейдерами в большинстве случаев не учитывается.
Не забывайте, что мы говорим о текстовых играх.
Ну, сделать двиг, который перерисовывает страницу, и имеет скрытые блоки я написал буквально за пару часов. Читать и качать здесь.
Написать поверх этого простенький язык, чтобы не херачить на голом JS – можно, но муторно. Можно завместо этого качнуть UnderscoreJS – там есть методы, которые в чистом JS делать долго и костыльно, и шаблонизатор.
А там остается только редактор – но это уже херачить свой WYSIWYG по принципу редактора в Twine/AXMA.
Но если после этого все-таки захочется сделать свой зык поверх JS – 13 глава книги Выразительный JavaScript вам в помощь или краткий перевод статьи на Habrhabr)
а освоение серьезного движка – это нагрузка на моск. Unity – C#, в UE2/UE3 был Unreal Script (тоже не пальцем деланный).
да в тех же GM:S, RenPy, PRGMaker и Construct (которые на первый взгляд "просто конструкторы для кипятильников") есть полноценные ЯП, которые надо-таки изучать.
с другой – более философской точки зрения – свой двиг это возможность прокачать навыки в мощных языках, которые не привязаны к движку. поверх двига можно в итоге написать свой внутренний язык, свой редактор, и тэдэ и тэпэ.
А на javascript, можно написать собственную программу? Ну с кнопками, строкой ввода кода и т.д, пример
???
AXMA и иже с ней написаны на JS. WYSIWYG на любом сайте написан на JS. Вопрос только в том, зачем это делать на JS, когда есть множество других способов.
А к примеру?
Flash?
Какой флэш?
Adobe Shockwave Flash?
а при чем тут JS?
Я отвечал на вопрос на чём можно
понял
Вообще писать приложения с GUI можно на:
Я ответил на твой вопрос?
А еще по работе столкнулся с Intel XDK и Ionic – написание Android/iOS приложений я JavaScript. Оне его собирают в .apk или нативный iOS-аппликейшон. Intel XDK может еще и в Windows 8/WinPhone 8/Amazon/Chrome App/Facebook App.
Вспомнил потому что на работе недавно обсуждали.
Я бы поставил тут и минус и плюс одновременно. Опыт и правила хорошего тона и здравого смысла решают всегда и везде. Но код на хорошем движке может быть в разы короче.
о господи, почитай про отступы, умоляю
я ему про это уже говорил
Как не самый плохой пример приведу свой код.
по ссылке на твой код пустая страница. это из той области что "лучшая программа - не написанная программа"?
Попробуй в хроме. У мозиллы почему-то с хейстом проблемы. Или у хейста с мозиллой...
Но вообще да, любой код - плохой код :D
сижу из-под хрома
И в Опере пусто по твоей ссылке.
Мда, странное что-то :) Ну, тогда пэйстбин.
А почему coffee-то?
Ну, вообще шарпы, но хейстбин как-то наркомански определяет язык фрагмента :)
А почему cucamakijo-то?
Вообще, не самый жирный список переменных, что я видел на своём веку. СБ бы обзавидовался такой скромности, у него один исходник чистого текста весит мегабайты.
Наколеночность этого проекта зашкаливает (что инди). Похвально!
Э? Обычно наоборот стараются использовать как можно меньше магических констант.