My "Gamedeveloper"

[DaggerBall]

Не знаю, может я не совсем в тему, потому как реализовывать то, о чем я здесь напишу, я не собираюсь, к тому же это не проект новой игры - это попытка создания твердой теоретической основы для программы, упрощающей написание игр, чего-то вроде GameMaker, но на другом фундаменте. Понятное дело, что любая программа такого рода ограничивает полет творческой фантазии , но зато позволяет угнаться за этой своей фантазией чуть большему количеству людей... но это все лирика, потому как я, как было сказано, ничего реализовывать не собираюсь - это всего лишь теория.
Итак вот они, мои идеи:
Программа представляет собой интерпретатор некоего языка, наложенный на скомпилированное и, соответственно, неизменяемое ядро. В языке, помимо стандартных int, float, bool, char, string, есть еще ref, типы для 2D и 3D графики, звука, всевозможных графических эффектов и придуманный лично мной (изобретателем многочисленных велосипедов ) тип "множество". Этот тип пока, думаю, единственный непонятный, а тот, кто понял его как set из Pascal-я малость неправ. Тип "множество" неограниченный (в разумных пределах) и ему сопоставлены три операции: add(set,element), del(set property) и set operation[\property]. Первая добавляет element в set, вторая удаляет все элементы set, удовлетворяющие property, а третья производит operation над всеми, или, если указано \property, то только удовлетворяющими ему, элементами set.
Пользовательские типы данных подразделяются только на Type (это обычный Pascal-евский record) и Class (о... а вот это уже поинтереснее).
Приблизительный вид объявления класса такой: "Classname=Class [costants;] [variables;] [functions;] end." и единственная функция над классами - Make(Class):Ref - создает локальную игровую реализацию класса, т.е. игровой объект. Также каждому классу сопоставлена переменная Classname.lockals:set[ref] - множество ref-ссылок на локальные копии класса. Тут кстати будет замечание, что consts вообще тоже изменяемые, но локальной копии от класса передаются по ссылке, т.е. изменение константы затрагивает все локальные копии этого класса, тогда как одноименные переменные для различных копий одного класса могут иметь разные значения.
Если подумать, то, по-моему, лучше бы объявлять Types, Classes, GlobalVars и GlobalConsts в отдельных окнах, а не внутри кода, дабы его не засорять, но это уже тонкости реализации...
Кроме вышеперечисленных "языковых" должны быть еще и переменные, типы и функции "из ядра" - это FramesDelay:float, Screen.(Width,Height,Maximazed,Came ra,Brightness,..), intersection(3Dgr,3Dgr):bool, contact(3Dgr,3Dgr):bool и наверное что-нибудь еще, но зачем собственно я и пишу это на форум - пожелания и замечания по шлифовке этого теоретического базиса, и ваше мнение на счет возможности реализации подобных проектов в будущем с радостью принимаются.

[Alex Cones]

А не проще ли чем изобретать "очередной велосипед" просто использовать паскаль\дельфи?

[Вадим Буренков]

А не проще ли чем изобретать "очередной велосипед" просто использовать паскаль\дельфи?

Согласен.Я сам с Game Maker не работал, но как понял его преимущество в том, чтобы делать игры особенно не зная программирования. Учить некий интерпритатор будет сложнее чем выучить Pascal.

[Гром]

Со своей стороны также добавлю, что C++ тоже хорошо подходит под ваше описание... Type и Class, полагаю, вообще есть во всех объектно-ориентированных языках программирования. Ну а "множества" - это стандартные контейнеры из библиотеки STL.

Если подумать, то, по-моему, лучше бы объявлять Types, Classes, GlobalVars и GlobalConsts в отдельных окнах, а не внутри кода, дабы его не засорять

А вот это уже обычные .h и .cpp файлы (первые содержат объявления всего, что только можно, вторые - определения и, стало быть, основную часть кода)

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

[DeKot]

Из идеи автора мне удалось вычленить следующее:
- все языки (ЯВУ) в основном универсальные, т.е. годятся и для обучения, и для БД, и для игр, мультимедии и т.п.
- программы типа GameMaker - это не программирование, а просто инструмент для реализации определенной задачи( в данном случае - для создания игровой программы);
- идея автора - в создании не программы , а среды программирования для создания игр. А это как говорят в Одессе, две большие разницы.
Поэтому идея автора заслуживает внимания и, по возможности, помощи и сотрудничества. Почему бы и нет, в своей среде создать классы, свойства, типы переменных и другие атрибуты чисто для индустрии игр. Реализация такой идеи может сравнится с операционными системами. Спрос на различные игры, интерес к этой тематике огромен.

[Пепел Феникса]

тогда уж лучше создать библиотеку к нужному ЯП. и использовать её там

[DaggerBall]

Да, вообще говоря можно создать и библиотеку, но их использование обычно все-же усложняет текст программы. Моя же основная идея заключается в том, чтобы упростить текст и работу с 2- и 3D-графикой и визуальными эффектами, звуком, анимацией, AI. Например нам надо включить в игру "Пехотинца". Мы создаем класс Marine, создаем в прилагающемся простеньком редакторе, или импортируем, все его трехмерные "части" и их текстуры, назначаем, если надо, первичное значение Visible, связываем их анимационным скелетом, добавляем динамические связывающие поверхности и, соответственно, их текстуры, если хочется покрасивее, создаем пару-тройку анимационных функций и модулей AI (опять таки во встроенных редакторах) и кидаем их в нашего Marine, создаем модификатор для Make от нашего класса - в общем много чего делаем, а в тоже время в главном коде у нас не изменилось ничего. И если теперь мы хотим поставить на карту разъяренного пехотинца, чтобы он стрелял направо и налево, то мы просто пишем в основном коде например Make(Marine,25,34,Player_Neutral,AI _Fury) и все... вот примерно так должна бы выглядеть реализация. И потом, очень хорошим, на мой взгляд, дополнением к final_release игры будет упрощенная (а насколько - по желанию разработчика) версия самой программы (или правда что правильнее писать "среда разработки"?), использующей вместо обычного ядра скомпилированный exe вашей игры - то есть "редактор игры", "редактор уровней", "construction set" - называй как хочешь. Такого не сделаешь просто написав библиотеку - библиотеки исполняют все-таки элементарные операции, а тут работа на макроуровне, и потом довольно абстрактная, тут нужна новая система разработки.
И главное - гораздо проще искать ошибки, обезопасить нужные данные. Не правда ли просто (может и неправда, но на всякий случай) случайно потерять какой-нибудь файл из проекта игры. крах системы, синий экран или другое бедствие сведут многие ваши усилия на нет. Но среда разработки может услужливо предоставить архив истории проекта, и возможность восстановить данные оттуда.
Есть еще, думаю, много преимуществ, но это правда не важно, пока нет людей готовых взяться за это, а я явно не в их числе - я пока буду разрабатывать теорию.
И вот что я попрошу вас: Пожалуйста,не выкладывайте больше постов типа "лучше пилить тем, что есть - затачивать некогда и желания нет". Лучше уж обходить стороной. Но еще лучше выкладывать задачи, которые, по-вашему, нужны в игре, и которые нельзя решить описанными методами или (что более вероятно) способ решения которых не сразу приходит в голову - это нужно для конденсации абстрактной идеи на твердую поверхность возможностей машины, конкретизации графических, звуковых типов, а в особенности AI и анимации: какие у них будут параметры, какие процедуры, функции, или еще что-нибудь (выкладывайте мысли и на эту тему, только слишком не увлекайтесь).
Например мне уже сейчас понятно, что AI-объекты должны представлять собой конкретный интерпретируемый код, написанный уже на другом языке, по которому у меня пока нет вообще никаких идей - я с AI еще не разбирался.

PS. "Множество", как я сегодня узнал, действительно является велосипедом - его можно запросто сконструировать уже по крайней мере в PascalABC.NET из типа List и оператора foreach. Сам PascalABC.NET (а .NET меня вообще сначала удивило) - довольно интересный фрукт - чего в нем только не намешано...

[JTG]

Если такая "делалка игр" дорастёт до состояния, когда на ней можно будет сделать что-то большее, чем простую аркаду или бессмысленную бомбилку с кучей эффектов, она превратится в Quest3D или UDK, освоить которые едва ли не сложнее, чем какой-то конкретный движок под конкретный язык.

[DaggerBall]

Извините конечно, но ни Quest3D ни UDK не подходят уже хотя бы потому, что с их помощью нельзя сделать, если я не ошибаюсь, никакую 2D игру - то есть универсальными их не назовешь. И нигде я не говорил о движке - это среда разработки, а в ядре у нее только работа с графикой и интерпретатор для AI. По сути дела на ней можно было бы сделать и текстовый квест и прикрутить AI туда... Короче мой девиз на красном флаге: "Все, что нужно для любой игры в одной программе и ничего лишнего".

[Levsha100]

Короче мой девиз на красном флаге: "Все, что нужно для любой игры в одной программе и ничего лишнего".

Ваш девиз не будет видно.