forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)

- Проекты C++ (http://forum.boolean.name/forumdisplay.php?f=56)

- - TatEngine (http://forum.boolean.name/showthread.php?t=17554)

Ответ: TatEngine

я уже удалил,
дождусь лучше версии, где не будет глючить прорисовка рабочей области
а пока проверю комп полностью

Ответ: TatEngine

Цитата:

Сообщение от pax (Сообщение 244841)

Ответ: TatEngine

Почитал новые туторы и взглянул на редактор еще раз. Оказывается нету проверки типов входов и выходов при соединении, было бы очень клево ее добавить, а то получается что можно назначить что хочешь, куда хочешь...

Ответ: TatEngine

выложил тулзы под макось, разработка проектов и движка потихоньку переходит на опенсорс репозиторий, showcase дорос до 9 комерческих проектов, но большинство пока под NDA :( надеюсь скоро появится время продолжить серию базовых туториалов и сделать демо проект

Ответ: TatEngine

как дела у движка и какие на нем выпущены проекты под какие платформы? будут ли новые туторы, желательно по всем доступным компонентам движка.
вобщем тему надо обновить :)

Ответ: TatEngine

Цитата:

Сообщение от dimanche13 (Сообщение 265902)

проекты в основном делались под iOS, сейчас есть :

Lil Flippers
Flora : Jewel Quest
Dream Gym (пока тут не начинали маркетинговую компанию, но как только будет presskit то я расскажу подробнее)

была куча проектов не под издательство : презентации, конференции и тд, и так же всякие поделки которые не вылились в нечто более серьезное

в основном в движке более менее всё обкатано, но нашлись некоторые очевидные проблемы с тулсетом : он неудобный в некоторых случаях

мы собрали большой опыт в разных use cases с разными движками и хотим сейчас их систематизировать в универсальном тулсете - llgm (аналогия с llvm - low-level game machine), основная идея в том что WYSIWYG для игр работают не достаточно хорошо, например задача : вставьте 500 анимаций и назначьте их разным объектам, нужно еще поискать редактор в котором это будет удобно делать, и задавшись целью написать тулсет которым хочется пользоваться мы погрузли в R&D

в основном за всю историю IT самые сложные и разнообразные use cases были в редакторах текста, люди придумали очень мощные инструменты для редактирования текста : latex, vim, regexp, etc, потому мы решили использовать текстовое представление как основное, сделать некий markup language для игр

за основу markup language мы взяли qml (http://en.wikipedia.org/wiki/QML) - json подобный язык на котором внезапно удобно писать, declarative + reactive programming + scripting, и перекраиваем его для нужд realtime, назвали его game markup language - GML

оно выглядит примерно так :

Код:

material

{

  id: sprite_mat

  texture

  {

    file: "foo.png"

  }

  shader: "sprite"

}



sprite

{

  material: sprite_mat

  transform.x: 100

}



sprite

{

  material { texture.file: "bar.png" }

  transform { x: 50; y: 100 }

}

сам язык очень похож на json, стараемся сделать даже так чтобы GML был надмножеством json (любой json код - валидный gml код), можно будет переводить gml в json и обратно

сейчас изучаем использование этого языка, некоторые вещи делаются очень быстро в тексте, некоторые вещи делаются очень наглядно в unity-style редакторе, а некоторые возможно сделать только в excel (вставка 500 анимаций), представление в виде objects with properties позволяет легко переходить из одного вида в другой и обратно

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

основной фишкой llgm мы стараемся сделать абсолютную универсальность и простоту - GML будет полностью schema-driven без хардкода каких либо имен или структуры, потому можно будет подстроить тулсет под ваш движок, или вообще делать импорт\экспорт из существующих движков

по самому движку tatengine : есть планы по его рефакторингу, нужно обновить тулзы по работе с ide, добавить task-driven многопоточность, вынести геймлогику в скрипты и тд

так и не решили пока с гуи, возможно declarative + reactive programming упростит создание гуи (в QML оно достаточно просто делается), но это пока только догадки, production бывает ломает любые догадки =) возможно попробуем тупо встроить chrome чтобы забыть наконец-то о гуи

ps. дальше еще будет =)

Ответ: TatEngine

Какие преимущества у GML над JSON'ом?

Ответ: TatEngine

Цитата:

Сообщение от moka (Сообщение 266294)

Какие преимущества у GML над JSON'ом?

удобнее писать руками, удобнее читать глазами, меньшая избыточность, lazy syntax, ну и да - комментарии в коде

разделителем может быть : или , или ; или его вообще может и не быть

например :

Код:

// gml

sprite { transform { x: 5 } }

sprite { transform { y: 20 } }

// json

Код:

[

{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 5 } ] },

{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 20 } ] },

]

еще думаем над всякими плюшками типа string literals и raw strings (как в C++), что позволит писать GML в UTF-8, а на выходе получать строку в UTF-16 или 32, а raw strings позволит не экранировать символы в теле строки и писать там скрипты любой сложности прям внутри GML файла

например :

Код:

script

{

text : R"(

// lua script

print("wow");

)"

}

стараемся упростить все до предела чтобы на нем именно ХОТЕЛОСЬ писать, есть много красивых инструментов, а любимых очень мало

так же в schema-driven будет много экспериментальных вещей : lazy types, lazy nested objects, lazy scripts и тд, но это не относится к синтаксису языка

например :

Код:

/* сам объект sprite по schema требует чтобы к нему был присоединен объект типа transform, у sprite для этого есть дефолтное поле с именем transform которое принимает ссылку (bind в терминологии qml) на объект с типом transform */

sprite 

{

  // но если мы опишем объект с типом transform в теле sprite то gml сам его подхватит и прилинкует к полю transform

  transform { }

}



sprite

{

  transform { id: a }

  transform { id: b }

  transform : a // спрайт будет двигаться трансформом A

}



sprite

{

  transform : transform { x : 5 } // nested objects

}



spr // вместо указания полного типа можно указывать только первые буквы, да и еще убирая гласные (эксперимент)

{

  trn { x: 5 }

}



spr

{

  trn.x : 5 // можно обращаться к полям объекта через поля-ссылки

}



spr

{

  trn.x := math.sin(t) * 50 // если вместо : написать = или := то парсер будет ожидать nested script, выражение с = выполнится во время загрузки, выражение с := будет выполнятся каждый кадр (reactive programming)

}

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

Ответ: TatEngine

Цитата:

Сообщение от jimon (Сообщение 266295)

Код:

// gml

sprite { transform { x: 5 } }

sprite { transform { y: 20 } }

// json

Код:

[

{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 5 } ] },

{ "type" : "sprite", "childrens" : [ { "type" : "transform", "x" : 20 } ] },

]

Чем не:

Код:

sprites: [

  { "transform": { "x": 5 } },

  { "transform": { "x": 20 } },

]

Цитата:

Сообщение от jimon (Сообщение 266295)

Код:

script

{

text : R"(

// lua script

print("wow");

)"

}

Код:

/* сам объект sprite по schema требует чтобы к нему был присоединен объект типа transform, у sprite для этого есть дефолтное поле с именем transform которое принимает ссылку (bind в терминологии qml) на объект с типом transform */

sprite 

{

  // но если мы опишем объект с типом transform в теле sprite то gml сам его подхватит и прилинкует к полю transform

  transform { }

}



sprite

{

  transform { id: a }

  transform { id: b }

  transform : a // спрайт будет двигаться трансформом A

}



sprite

{

  transform : transform { x : 5 } // nested objects

}



spr // вместо указания полного типа можно указывать только первые буквы, да и еще убирая гласные (эксперимент)

{

  trn { x: 5 }

}



spr

{

  trn.x : 5 // можно обращаться к полям объекта через поля-ссылки

}



spr

{

  trn.x := math.sin(t) * 50 // если вместо : написать = или := то парсер будет ожидать nested script, выражение с = выполнится во время загрузки, выражение с := будет выполнятся каждый кадр (reactive programming)

}

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

Это не будет языком, а будет "разметкой".
Да и любая попытка "упростить" требует создание каких либо механик, а они в 90% не оправдываются продакшаном и имеют ограничения. Которые в итоге вынудят других разрабатывать свои велосипеды.

Те же schem'ы, всегда имели % разрабов их не уважающих.

Ответ: TatEngine

Цитата: