какие программы использовать для создания своих игр?

[r57shell]

Я про суть. По такому алгоритму пишутся движки, или как то подругому? 

Движки пишутся по алгоритму:

Код: [Выделить]

Движок=Архитектор.ПридуматьДвижок();
while((НеРеализованное=Движок.СледуйщееНеРеализованое())!=НЕРЕАЛИЗОВАННОГО_НЕТУ)
{
   ПолучилосьЛи=ПопробоватьРеализовать(НеРеализованное);
   if(ПолучилосьЛи==Невозможно) //мури (яп. невозможно)
      Архитектор.ПоправитьАрхитектуру(Движок);
   else
      while((Баг=НайтиБаг(Движок))!=БАГОВ_НЕТ)
          Пофиксить(Баг);
}
ЭЭэ и даже этот бред - не правда. Алгоритм ещё более запутаннее и сложнеее. И об этом можно тоже почитать.
А архитектур, ещё раз повторюсь, можно придумать 100500.

Добавлено позже:
CrazyMax, ты написал как использовать движок, а вопрос Mr2, я так и не могу понять. Он спрашивает как пишутся движки, а в тоже время, похоже хочет чего-то другого. Прямо надо! А про устройство движков - надо смотреть конкретный, ещё раз повторюсь.

[Mr2]

r57shell, ты о чем? Все что ты написал о "движке", ты написал о API.
Движок это совсем другое, ты можешь в своем движке использовать это API.
А движок - это спрайтовая систем (не просто вывод на экран, а например в объекте спрайта хранить его характеристики - id, анимацию, аффект вывода и т.д.), звук, физика, скрипты, файловая система...
И ты его можешь использовать для написания не конкретной игры.

Mr2, то что тебе написал HoRRoR - это главный цикл твоей игры и он пишется в "игре", а не в движке.
Маленький пример:
Незнаю, может не очень доходчиво, но где-то так

Помоему ты написал то же что и я но, только выделил отдельный класс движок (Движок->gpu->draw() ?

[r57shell]

r57shell, ты о чем? Все что ты написал о "движке", ты написал о API.

Движок не API?

[CrazyMax]

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

Кстати, если ты собрался Battle City портировать, то тебе там движок не нужен, игра слишком простая.

Добавлено позже:

Движок не API?

НЕТ!!!
API это тот же devkit, чтобы разработчик не заморачивался работой напрямую с железом/драйверами.

Я написал раньше, чем отличается движок от API/devkit

[r57shell]

НЕТ!!!
API это тот же devkit, чтобы разработчик не заморачивался работой напрямую с железом/драйверами

API определяет функциональность, которую предоставляет программа (модуль, библиотека)

оригинал
Движок - библиотека, модуль.

[CrazyMax]

оригинал
Движок - библиотека, модуль.

И?

WinAPI - это тоже движок (он выводит/обрабатывает интерфейс), но тоже использует тот-же DirectX для рисования линий, точек. Анимирует кнопки, иконки и т.д.
Также и игровой. Ты эму указываешь атрибуты спрайта, а он их использует - анимирует, поварачивает, проверяет коллизии и т.д.
OpenGL, DirectX или любой devkit делает это? НЕТ!!!

P.S. devkit железа, а сейчас начнется

[r57shell]

Вывод: Движок API. DirectX, OpenGL, OpenAL - это всё API.

[AjaxVS]

r57shell, классный алгоритм!  

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

ах, да:

какие программы использовать для создания своих игр?

с++, visual basic, delphi, c#.
тогда создашь _игры_. ежели выберешь гейммейкер/муген/еще_что_то_подобное, то в 99.99% случаев получится _игрулька_, похожая на тясячи остальных под авторством таких же скрипткиддис.. из нее ты не сможешь вырасти дальше как создатель игр, в лучшем случае ты будешь штамповать на своем конструкторе очередные убожества, на которые никто всерьез внимания не обратит. зато ты избавишь себя от многих часов создания собственных классов на базе DirectX, и гордо будешь говорить "я создал свою игру!!!111" (не забудь ее назвать как-нибудь поэпичнее. например, "Shining Force 6", и все равно, если там от шайнинг форса ничего нет, так многие юзеры конструкторов делают ^^).
выбор всегда есть  

[Mr2]

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

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

Да и вот ещё экспереминтировать начал c 2D, и решил так сказать углУбить, и расшИрить...

[r57shell]

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

Согласен что нет строгого определения, но есть хоть смысл общепринятый). Движок чаще всего как Framework+API.

Чего не прокоментировал - с тем согласен, как обычно).

[Mr2]

Научил зайца ходить.

[r57shell]

Допустим надо добавить кого-нибудь ещё, то ты его заного будешь учить ходить?)
Вот в этом и суть движков. Учишь одного - научиваются все ). образно.
Поэтому надо например для всех персонажей, какой-то интерфейс придумывать, чтобы не надо было каждого учить одинаковому, а чтобы их отличия состояли только из их свойств. И затем можно будет сделать сразу(образно) много персонажей)). Кроме того, если вдруг найдётся то, чего неустраивает, не прийдётся исправлять всех по отдельности, достаточно будет изменить этот "интерфейс". Это один из принципов OOP (Object Oriented Programming - Объектно Ориентированное Программирование).
Вообще ненавижу фанатов OOP. Они начинают умно говорить о всяких абстракциях, интерфейсах, делегировании, обобщённых классах и прочей фигне, которая на самом деле, ничего иного как метод реализаци OOP. Фанатеть можно сколько угодно, а для меня OOP важно только парочкой принципов: объекты можно сказать "сами за себя отвечают"(не важно какая у них внутри реализация, если сказал ему идти то он идёт), скрывать от другого программиста "критические" переменные (при изменении которых может произойти сбой). Ито, и эти принципы не обязательны.

[Mr2]

Допустим надо добавить кого-нибудь ещё, то ты его заного будешь учить ходить?)

Вместе с зайцем я сам первый раз шагнул. Зайца вполне достаточно для пробы, а так конечно ооп для какого нибудь крупномасштабного проэкта . В данном эксперименте(1массив и 4 цикла(при желании и до двух можно довести)) ооп избыточно.
Как я понял Joypad можно опрашивать только через Derect X?

Они начинают умно говорить о всяких абстракциях, интерфейсах, делегировании, обобщённых классах и прочей фигне,

Да это просто Ж, столько терминов понавыдумывали, да к тому же и не могут понятно объяснить их значение.....

[HoRRoR]

Вообще ненавижу фанатов OOP. Они начинают умно говорить о всяких абстракциях, интерфейсах, делегировании, обобщённых классах и прочей фигне, которая на самом деле, ничего иного как метод реализаци OOP. Фанатеть можно сколько угодно, а для меня OOP важно только парочкой принципов: объекты можно сказать "сами за себя отвечают"(не важно какая у них внутри реализация, если сказал ему идти то он идёт), скрывать от другого программиста "критические" переменные (при изменении которых может произойти сбой). Ито, и эти принципы не обязательны.

(извиняюсь, не сдержался)

[r57shell]

(извиняюсь, не сдержался)

Я также смеялся над преподом ООП когда он шнягу всякую задвигал по ООП, и не только над преподом, над многими.
простой пример: язык C. На нём вить можно на ООП фигачить, а в их смысле (в фанатском) - нет. Т.к. там нет абстракций и интерфейсов. и прочей шняги. Ах, да, даже классов нет.

[HoRRoR]

На нём вить можно на ООП фигачить

Эм... Приведи хоть один пример.
--
Хотя да, помещать в структуры указатели на "методы"

Т.к. там нет абстракций и интерфейсов. и прочей шняги.

Ну да, если с чем-то не знаком - надо обязательно считать это шнягой...

[r57shell]

Эм... Приведи хоть один пример.

Простой пример WinAPI - почти весь основан на объектах. Таких как HRGN, HWND, HANDLE, и прочих, однако они все типа void *. А методы к ним это функции SetWindowRgn(hwnd,rgn) и прочее. Также на C пишется на принципах ооп. Если надо допустим делегирование, то просто добавляется свойство, с указателем на другой "объект" - который уже будет делегантом или как там я уже забыл.

Ну да, если с чем-то не знаком - надо обязательно считать это шнягой...

Заблуждаешься что незнаком. Знаком с большинством инструментов Java и C++ для ООP такие как шаблонные классы, функции - (C++), обобщённые типы (Java), интерфейсами, делегированием, абстракциями, и прочей фигнёй. Может чего ещё нового придумали, с чем не знаком.

Добавлено позже:
Добавление: обычно функция(объект, параметры) вот так методы вызываются. Даже в ASM логично используют. Бывает за счёт макросов. И с asm x86 я тоже знаком.

Добавлено позже:
Принцип ООП сокрытия достигается соглашением работать только через Get, Set.

Добавлено позже:
О! я даже вспомнил термин. Это называется "инкапсуляция". Умными названиями только и кишит ).

[HoRRoR]

Простой пример WinAPI - почти весь основан на объектах. Таких как HRGN, HWND, HANDLE, и прочих, однако они все типа void *. А методы к ним это функции SetWindowRgn(hwnd,rgn) и прочее. Также на C пишется на принципах ооп. Если надо допустим делегирование, то просто добавляется свойство, с указателем на другой "объект" - который уже будет делегантом или как там я уже забыл.

Ой не могу Ты даже понятие ООП неправильно понимаешь, чего уж об остальном говорить

Заблуждаешься что незнаком.

По твоему отношение ко всей этой "шняге" можно сделать только такой вывод.

И хватит параллельно написанию поста гуглить и сёрфить по статьям

[r57shell]

И хватит параллельно написанию поста гуглить и сёрфить по статьям

Делать мне нечего...
Маладец съешь солёный огурец.
И желаю тебе, удачи).

[AjaxVS]

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

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

помню, мне все время говорили "да, ты можешь обойтись без ООП, пока делаешь небольшие программы". но я делал на VB все что хотел, измерял количество кода в тысячах строк, и все ждал, когда же уже мне понадобится этот ООП
сейчас я перешел на C++, делаю такие штуки как прототипы гравитации, но ООП все так же использую разве что для галочки, чтобы код не стыдно показывать было  

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

[r57shell]

Ято забиваю, просто хотел открыть другим глаза на то, что на ООП зацикливаться нестоит и фанатеть, т.к. это бред. Без ООП сложно просто разделить работу между людьми.

[aptyp]

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

[r57shell]

Но всёравно если этот полиморфизм не использовать то уже нет никакого ООП ))). А использование как я в С пример привёл это и есть уже юзать полиморфизм. Даже на мего ООП языках можно писать без ООП ).

[BmpCorp]

Но всёравно если этот полиморфизм не использовать то уже нет никакого ООП )))

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

[r57shell]

BmpCorp, эмм вы о чём простите? Цитата которую вы вставили просто утверждение, и там нет ни каких - "не используй/обязательно используй".
А вот эти слова:

А почему бы его не использовать?

Меня наводят на мысль, что я говорил "не использовать" где-то. И ещё раз для закрепления, я сказал не стоит фанатеть. Не знаю как вы, а я слово "фанатеть" воспринимаю расхваливание постоянное, и толкание куда только угодно, лижбы было. Видал я один проэкт. Около 20 файлов, в каждом по 10 строк от силы - вот что значит, фанатизм OOP.
А в остальном согласен.
А на закуску: мы с друзьями раздували на тему, создать в Java класс. Пока умолчу его имя ). Есть такие классы как Clonable, Closeable, и так далее - как маркеры. Вот мы и прикололись:

Код: [Выделить]

class IntegerCloseable : implements Closeable
{
 void close()
 {
 //do nothing
 }
...
}

...
IntegerCloseable a= new IntegerCloseable(5);
...
a.close();
a.close();
a.close();
a.close();
//amin'!

сlass NothingDoAble
{
public void doNothing()
{
//let's do this!
}
};
И ещё одна закуска, называется падла в проекте по полной программе:

Код: [Выделить]

#define true (Math.random()>0.5)а для тех кто сомневается - компилится, ещё как!)

[BmpCorp]

Меня наводят на мысль, что я говорил "не использовать" где-то.

Я не об этом, а конкретно про полиморфизм и наследование. Так как

для меня OOP важно только парочкой принципов: объекты можно сказать "сами за себя отвечают"(не важно какая у них внутри реализация, если сказал ему идти то он идёт), скрывать от другого программиста "критические" переменные (при изменении которых может произойти сбой).

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

А про фанатизм, да ещё и в программировании, это точно не ко мне

[HoRRoR]

Господи, человек боится ООП, с негативом называет тех, кто его использует, "фанатами" или как там ещё, постоянно выдаёт за прописные истины какую-то хрень, а сам никакой компетентности не внушает нисколько. И как вообще воспринимать его слова?

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

Вот мы и прикололись

И в чём прикол?

[r57shell]

Господи, человек боится ООП, с негативом называет тех, кто его использует, "фанатами" или как там ещё, постоянно выдаёт за прописные истины какую-то хрень, а сам никакой компетентности не внушает нисколько. И как вообще воспринимать его слова?

Продчёркнутое - это я подчеркнул, чтобы было понятно, дак вот. Я этого не говорил. Вспоминается цитата, может кто до меня так говорил, но как-то раз я сказанул "как может читать между строк тот, кто даже сами строки не может прочесть". Дак вот, я говорил подчёркнутое? Находишь различие между фанатизмом и использованием? Ещё (не знаю какой раз повторюсь), я сказал не стоит фанатеть, про использование, я соглашался, смотри выше, много примеров. Я не говорил что те кто используют - "фанаты". Прошу цитату встудию.

А на счёт компетентности, на себя посмотри, сначала не правильно поймёт, а потом наежяет - тоже не тру. А мне лично честно пофиг как я выглежу со стороны, т.к. я такой как есть, и от того что обо мне думают, ничего не изменится. И я сам в праве выбирать, с кем общаться а с кем нет. Непомню чья цитата: "Уж лучше голодать, чем что попало есть; Быть лучше одному, чем с кем попало."

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

Нестоит сразу всё под одну рамку загонять, т.к. кто знает какие могут быть исключения.

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

Согласен, но это не означает что нужно его толкать куда угодно.

И в чём прикол?

Видимо фанатам OOP не понять. Это собственно пародия на фанатство в OOP. Так оно со стороны выгледит.

[HoRRoR]

Что в твоём понимании значит "фанатеть"? Это какой-то новый термин в программировании или что? Или фанатеть - говорить, как ты говоришь, всякие умные слова использовать ООП? Объясни, ибо в таком случае я вообще не понимаю, кого ты подразумеваешь под фанатеющими от ООП.

Нестоит сразу всё под одну рамку загонять, т.к. кто знает какие могут быть исключения.

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

Согласен, но это не означает что нужно его толкать куда угодно.

Что значит куда угодно? Где ты, например, не видишь места ООП?

Видимо фанатам OOP не понять. Это собственно пародия на фанатство в OOP. Так оно со стороны выгледит.

facepalm.jpg

[r57shell]

Что в твоём понимании значит "фанатеть"?

Что принято обществом понимать, а именно :
Фанатеть(1-й смысл)
Википедия: Фанатизм(я знаю ей не все верят) 1-й абзац.
Собственно теперь, процитируем себя же.

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

Замечу, что это из этой темы, и было написано до твоего ответа.