Суббота, 16 Ноября 2024, 08:28

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 4 из 6
  • «
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • »
[2D] Taiga Survival [Survival / RPG]
WoKДата: Пятница, 12 Июня 2015, 14:37 | Сообщение # 61
Сейчас нет на сайте
Супер! Не знаю что даже сказать,просто отлично,удачи тебе с проектом !!!!

[2D/Android] Square feelings = Разработка
[2D]Green Jumper = Готова
Kos94okДата: Пятница, 12 Июня 2015, 15:52 | Сообщение # 62
почетный гость
Сейчас нет на сайте
WoK, Благодарю, в него вложено очень много сил и времени. Возможно, даже слишком много.
berilДата: Пятница, 12 Июня 2015, 16:04 | Сообщение # 63
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
Не было уже давно новостей (консоль не в счет biggrin )%)



Накодил? Убери за собой!
Инвентарь в Unity(UI)
Инвентарь в Unity(GUI)
Kos94okДата: Пятница, 12 Июня 2015, 16:19 | Сообщение # 64
почетный гость
Сейчас нет на сайте
beril, Ну так не о чем рассказывать особо ) Работаю в соло, пытаюсь все сделать как можно лучше, так что идет довольно медленно. Если бы я рассказывал обо всех технических аспектах, то, судя по консольке, это не очень интересно будет народу )
RemmintanДата: Суббота, 13 Июня 2015, 22:09 | Сообщение # 65
почетный гость
Сейчас нет на сайте
Цитата Kos94ok ()
beril, Ну так не о чем рассказывать особо ) Работаю в соло, пытаюсь все сделать как можно лучше, так что идет довольно медленно. Если бы я рассказывал обо всех технических аспектах, то, судя по консольке, это не очень интересно будет народу )


Мне было бы очень интересно послушать про технические аспекты движка. Сам пару лет занимаюсь программированием графики под OpenGL, пытаюсь потихоньку разрабатывать 2D движок, и в процессе разработки возникает множество вопросов, ответы на которые очень сложно найти в русском сегменте гугла (а я не владею английским на том уровне, чтобы читать техническую литературу про OpenGL и оптимизацию кода). Мне интересны даже не столько синтаксис и конструкции языка, с кучей кусков кода (сам на Java в связке с GLSL пишу), сколько сама архитектура игры: как производишь отрисовку текста (атлас или рендер в текстуру, например), как анимацию производишь, используешь ли потоки для разделения рендера от логики игры, а логики игры от Input'а (в C++ вообще есть потоки?), как оптимизируешь, борешься с утечками памяти (утечки памяти для С++ вообще жуткая тема, в плюсах нет сборщика мусора biggrin ), коллизии как обрабатываешь, AI на чем строишь. Эти и подобные технические мелочи для меня очень интересны, и чем подробней рассказ будет, тем больше лучей добра я отправлю в твою сторону.

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

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

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


Сообщение отредактировал Remmintan - Суббота, 13 Июня 2015, 22:30
TymonrДата: Суббота, 13 Июня 2015, 22:24 | Сообщение # 66
With OpenSource forever
Сейчас нет на сайте
Цитата Remmintan ()
в C++ вообще есть потоки?

Да, разумеется
Цитата Remmintan ()
утечки памяти для С++ вообще жуткая тема, в плюсах нет сборщика мусора

Вот не надо тут.

Kos94ok, а вообще какой резон писать свой движок? Кроме фана


Если вы решили обратиться к нам за помощью, не становитесь в позицию неудачника. И не ведите себя как неудачник. Лучший способ получить быстрый и чуткий ответ, - спрашивать как победитель — спрашивать как человек умный, уверенный в себе и знающий, которому просто понадобилась помощь при решении одной конкретной проблемы.
Как правильно задавать вопросы в технических форумах
RemmintanДата: Суббота, 13 Июня 2015, 22:35 | Сообщение # 67
почетный гость
Сейчас нет на сайте
Знаю, что не ко мне обращаешься, но все же.

Tymonr, так в фане и есть вся суть, извращенные конечно интересы, но для меня программирование веселей любой игры. Ну еще как вариант: "Мужик должен все уметь!" ©
OrdanДата: Воскресенье, 14 Июня 2015, 02:15 | Сообщение # 68
Главный зомби
Сейчас нет на сайте
Цитата Tymonr ()
а вообще какой резон писать свой движок? Кроме фана

Ну мне лично проще написать игру на своем движке чем на конструкторе/движке. Так же это много крайне полезного опыта.


Цитата недели: Из-за леса, из-за гор, кишки, месиво, хардкор. (Берсерк ТВ-2)

Мои проекты ТЫК
Мои видяхи на ютубэ ТЫК

Если ты споришь с идиотом, вероятно тоже самое делает и он.
Kos94okДата: Воскресенье, 14 Июня 2015, 10:32 | Сообщение # 69
почетный гость
Сейчас нет на сайте
Tymonr, Объективно - практически никакого. Но меня это никогда не останавливало.
Remmintan, Ты удивишься, насколько просто реализованы многие вещи, но спасибо за интерес. В ближайшее время вывешу пост об основной архитектуре движка, а если есть конкретные вопросы помельче - задавай. Тот список, что ты там вывесил, считаю слишком длинным, чтобы подробно ответить на всё )
RemmintanДата: Воскресенье, 14 Июня 2015, 14:36 | Сообщение # 70
почетный гость
Сейчас нет на сайте
Kos94ok, да я список писал от балды, чтобы дать понять, что мне будет интересно послушать обо всем. Ладно уж, я подожду поста про общую архитектуру, потом уже задам про свои мелочи, больно уж мои вопросы мелкие и технически тонкие (аля, как объекты двигаешь, непосредственно x, y координаты или для каждого матрицу модели преобразуешь (это вроде как эффективнее может быть, но при этом теряется контроль над коллизиями) ? (чушь в общем-то но мне интересно)). Если есть о чем писать, то лучше пиши сам, так будет рассказ складней и понятней для большинства.

Ordan, Да и вообще, если движок написан своими руками, то ты знаешь его вдоль и поперек, это очень сильно упрощает поиск и исправление багов.
Kos94okДата: Воскресенье, 14 Июня 2015, 22:14 | Сообщение # 71
почетный гость
Сейчас нет на сайте
Цитата Remmintan ()
это очень сильно упрощает поиск и исправление багов.

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

Добавлено (14 июня 2015, 22:14)
---------------------------------------------
Настало время очередного технического поста! Как и обещал, немного информации о базовой структуре движка (которая только недавно окончательно устаканилась). Сегодня я буду приводить некоторое количество кода в качестве примера, но, я надеюсь, он будет понятен всем.

Говоря об основной структуре, мне кажется, что я должен упомянуть самое простое и основное - структуризацию файлов исходного кода. На данный момент я пользуюсь Visual Studio 2013 в качестве среды разработки, и список файлов проекта выглядит примерно так:

Файл main.h является основным заголовочным файлом, который включает в себя перечень всех классов и функций, использованных в коде.
Каждый файл исходного кода (*.cpp) начинается с директивы
Код
#include "main.h"

Это открывает доступ к любому участку кода без необходимости включать многочисленные заголовочные файлы. К слову, на момент написания в проект включено 30 заголовков и 60 файлов исходного кода (я тоже удивлен таким ровным числам).
Кроме прочего, main.h содержит объявление класса cCore, который используется для слежения за работой всех прочих потоков. Подробнее об этом - чуть позже.

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

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

Как только вся память выделена, и объекты готовы к работе, инициализация продолжается. Первым делом нам необходимо проверить, не переданы ли какие-то параметры запуска нашей игре. Делается это с одной целью - возможно, нужно переключиться в режим сервера. Отличается от обычного режима он отсутствием графического и звукового потоков.
Далее происходит загрузка баз данных:
Код
settings.setDefault();  // Настройки по-умолчанию
settings.load();  // Загрузка настроек из settings.ini
database.init();  // Основная внутренняя база данных
craft.loadRecipes();  // Рецепты крафта
visual.init();  // Шрифты и шейдеры
world.analyzeBlueprints();  // Компоненты генерации мира


В этот момент начинается интересная часть. Основная идея, которая отличает данный движок от моей предыдущей попытки - многопоточность.
На момент написания, нагрузка движка разнесена в десять потоков, включая основной:
Код
thread threadWindow(windowMain);   Sleep(10);  // Ввод и рендер
thread threadServerWorld(serverWorldMain);  Sleep(10);  // Основная игровая логика
thread threadServerConnect(serverConnectMain);    Sleep(10);  // Входящие соединения на сервер
thread threadServerReceive(serverReceiveMain);    Sleep(10);  // Входящие сообщения на сервер
thread threadServerSend(serverSendMain);  Sleep(10);  // Исходящие сообщения
thread threadClientReceive(clientReceiveMain);  Sleep(10);  // Входящие сообщения на клиент
thread threadClientSend(clientSendMain);  Sleep(10);  // Исходящие сообщения
thread threadWorldLoader(worldLoaderMain);  Sleep(10);  // Загрузка мира с диска или запрос данных с сервера по необходимости
thread threadAICore(AICoreMain);    Sleep(10);  // Искусственный интеллект
thread threadAudio(audioMain);    Sleep(10);  // Звук

Задержка в десять миллисекунд после старта каждого из потоков не необходима, но позволяет избежать смешения вывода в консоли. По сути - просто для красоты.
Каждый из данных потоков обладает собственным вечным циклом, который обрывается по команде основного потока. При каждой итерации поток обязан проверить состояние переменной core.thread_shutdown[threadId], где threadId - идентификатор потока, а так же обнулить переменную core.thread_antifreeze[threadId]. Но, опять же, об этом чуть позже.

Как только все потоки запущены, движок готов к работе. Основной поток переходит в своеобразный режим ожидания, наблюдая за работой всех остальных. Он подсчитывает частоту кадров, количество тиков потока логики, а так же следит за тем, чтобы никто не отлынивал от работы, ибо как только переменная core.thread_antifreeze одного из потоков перевалит за тысячу тиков, то консоль сообщит об этом.
Код
while (!core.shutdown)
{
    // Counting ticks
    if (timeGetTime() - globalTime >= 1000)
    {
     globalTime = timeGetTime();
     core.thread_windowTicksPerSec = core.thread_windowTicks;
     core.thread_serverWorldTicksPerSec = core.thread_serverWorldTicks;
     core.thread_windowTicks = 0;
     core.thread_serverWorldTicks = 0;
    }
    // Adding some antifreeze
    for (int i = 0; i < 10; i++) {
     if (core.thread_antifreeze[i] > 1000) {
      core.thread_antifreeze[i] = 0;
      console.error << "[MAIN] Thread " << i << " appears to be frozen..." << endl;
     }
    }
    Sleep(1);
}


Но в какой-то момент спокойной жизни приходит конец и появляется сообщение core.shutdown. В таком случае, приходится сворачивать удочки.
По сути, основному потоку остается только по порядку отключить все прочие потоки. Но сначала нужно дождаться завершения скриптовых потоков, которые создаются динамически по необходимости, выполняя разнообразную грязную работу.
Финальная часть кода выглядит очень даже опрятно.
Код
core.thread_shutdown[9] = true;  threadAudio.join();
core.thread_shutdown[8] = true;  threadAICore.join();
core.thread_shutdown[7] = true;  threadWorldLoader.join();
core.thread_shutdown[6] = true;  threadClientSend.join();
core.thread_shutdown[5] = true;  threadClientReceive.join();
core.thread_shutdown[4] = true;  threadServerSend.join();
core.thread_shutdown[3] = true;  threadServerReceive.join();
core.thread_shutdown[2] = true;  threadServerConnect.join();
core.thread_shutdown[1] = true;  threadServerWorld.join();
core.thread_shutdown[0] = true;  threadWindow.join();

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

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

Бонус: Пример вывода консоли при запуске игры и моментальном закрытии.
Код
[MAIN] Main thread started
[MAIN] Parsed [1] arguments
[MAIN] Initializing
[MAIN] Detected Nvidia video card
[MAIN] Loading databases
[DATABASE] Loading Items
[DATABASE] Loading Units
[DATABASE] Loading UI
[DATABASE] Loading Textures
[DATABASE] Loading External
[DATABASE] Main database ready
[MAIN] Blueprints analyzed: 28. Correct: 28, Wrong: 0
[MAIN] Starting the threads
[WND] Window thread started
[WND] Creating 1600x900 window rendering at 1600x900
[SRV_WORLD] Starting the server world thread
[SRV_CONNECT] Starting the server connect thread
[SRV_CONNECT] Listening at port 21045.
[SRV_RECEIVE] Starting the server receive thread
[SRV_SEND] Starting the server send thread
[CLIENT_RECEIVE] Starting the client receive thread
[CLIENT_SEND] Starting the client send thread
[WORLD_LOADER] Starting the world loader thread
[AI_CORE] Starting the AI core thread
[WND] Starting the main loop
[AUDIO] Starting the audio thread
[MAIN] Making some menu
[MAIN] Overlooking the threads...
[MAIN] Waiting for script threads to finish...
[MAIN] Waiting for core threads to finish...
[AUDIO] Cleaning up
[AI_CORE] Cleaning up
[WORLD_LOADER] Cleaning up
[CLIENT_SEND] Cleaning up
[CLIENT_RECEIVE] Cleaning up
[SRV_SEND] Cleaning up
[SRV_RECEIVE] Cleaning up
[SRV_CONNECT] Cleaning up
[SRV_WORLD] Cleaning up
[WND] Cleaning up
[MAIN] Cleaning up


Сообщение отредактировал Kos94ok - Воскресенье, 14 Июня 2015, 22:16
ЭргалонДата: Воскресенье, 14 Июня 2015, 22:22 | Сообщение # 72
Вездесущий
Сейчас нет на сайте
По некоторым моментами схожей структуры у моей игры, возник вопрос. Вся графическая часть интерфейса хранится в отдельном классе или она создается в том классе, который хранит логику определенного модуля? Например есть класс инвентаря, то там соотв. и логика и графический облик самого инвентаря.

Кубариум
Rise of the dark lords


Сообщение отредактировал Эргалон - Воскресенье, 14 Июня 2015, 22:23
Kos94okДата: Воскресенье, 14 Июня 2015, 22:38 | Сообщение # 73
почетный гость
Сейчас нет на сайте
Эргалон, собственно, класс cUI. Большая часть данных интерфейса хранится именно там. Часть данных, которые часто используются, лежит в базе данных. Отдельного класса на инвентарь, как элемент интерфейса, нет. Логика инвентаря - это три класса cItemContainer (один хранится в объекте персонажа, два других - в cCraft), манипуляции с контейнерами производятся через callback'и кнопок, принадлежащих основному классу.

Сообщение отредактировал Kos94ok - Воскресенье, 14 Июня 2015, 22:39
ЭргалонДата: Воскресенье, 14 Июня 2015, 22:42 | Сообщение # 74
Вездесущий
Сейчас нет на сайте
Kos94ok, Понял, спасибо. В прочем мне гораздо удобнее обращаться к объектами интерфейса(который является своего рода статичным) через один класс. Ну в целом понятно, у меня инвентарь также разбивается на один главный класс и несколько его подклассов

Кубариум
Rise of the dark lords
RemmintanДата: Воскресенье, 14 Июня 2015, 22:59 | Сообщение # 75
почетный гость
Сейчас нет на сайте
Kos94ok, все классно написано, продолжай в том же духе.

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

Про потоки: я тоже пришел к потокам не сразу, мне для этого пришлось два раза переписать движок biggrin .
И опять же такая архитектура затрудняет работу с потоками (хотя возможно в С++ с этим все нормально) просто в Java, например, для корректного использования одних и тех же кусков кода в двух разных потоках рекомендуется использовать синхронизованые методы или блоки кода (иначе могут возникать труодноотлваливаемые баги, которые проявляют себя не при каждом запуске программы).

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

p.s. Я ни в коем случае не критикую. То, что сделал ты, это просто чума, мне до такого расти и расти, и ты однозначно по своим результатам лучший программист чем я (у тебя есть геймплей, у меня лишь куча тестов не производительность собственного кода). Я просто оборачиваюсь на свой опыт (программирую с раннего возраста вместо игры в компьютер, 4 года уж на Java пишу, развиваюсь медленно, ибо учеба) и делюсь своими мыслями по поводу выбранной архитектуры. Такая архитектура имеет полное право на существование. Работает? Значит все супер


Сообщение отредактировал Remmintan - Воскресенье, 14 Июня 2015, 22:59
Kos94okДата: Воскресенье, 14 Июня 2015, 22:59 | Сообщение # 76
почетный гость
Сейчас нет на сайте
Эргалон, Не за что. На самом деле, я не очень доволен своей реализацией интерфейса, потому что как-то она выглядит слишком массивной, хоть и работает как надо. Возможно, позже переработаю во что-то более удобное.
Remmintan, Критичные куски кода закрываются семафорами, так что многопоточность - не проблема в этом плане. И да, я понимаю все минусы отсутствия инкапсуляции, но я понимаю и все плюсы. Конечно, мне иногда приходится залипать по паре часов в код, пытаясь отловить очередной хитро окопавшийся баг, но если какой-то код полез туда, куда не надо, он бы все равно влез туда, только для этого ты бы написал отдельный метод.
Первая версия движка вообще была гораздо более функционально-ориентированной. Там не было классов подобного рода, только объекты предметов, декораций и юнитов.
По части рендера, я не так много могу рассказать. В этот раз я все-таки полагаюсь на библиотеку, которая делает большую часть грязной работы. То есть основная часть работы со шрифтами выполняется через SFML. Реализовав шрифты однажды, я больше не хочу этим заниматься )
Вся эта архитектура - это исключительно пробы и ошибки, а также мой личный опыт. Мне кажется, что по части теории ты знаешь даже больше, чем я )


Сообщение отредактировал Kos94ok - Воскресенье, 14 Июня 2015, 23:07
RemmintanДата: Воскресенье, 14 Июня 2015, 23:05 | Сообщение # 77
почетный гость
Сейчас нет на сайте
И да. Забыл еще про доступ всех классов ко всем. Это гигантская дыра в безопасности с точки зрения читера (а игра вроде как будет онлайн равно или поздно). Ведь сделав хук памяти в одном классе из-за мелкого бага этого класса, у хакера будет возможность получить доступ абсолютно ко всем другим функциям игры (вплоть до полной замены пакетов клиента своими). Я понимаю, что безопасность не суть для маленькой инди игры, разработчик который не претендует на миллион продаж, но нужно же учится писать код правильно с самого начала, еще раз удачи в разработке.
Kos94okДата: Воскресенье, 14 Июня 2015, 23:09 | Сообщение # 78
почетный гость
Сейчас нет на сайте
Remmintan, Мультиплеер встроен едва ли не в самое ядро игры, так что она уже онлайн )
Приличная часть вычислений выполняется на стороне сервера, так что клиент не имеет столь больших привилегий. И даже если кто-то найдет эксплойт, я не планирую, что кто-то будет держать большие публичные сервера игры в принципе. Это маленькая кооперативная игрушка, которую нужно играть с друзьями. А там если вы все решите массово читерить, то и флаг вам в руки )
RemmintanДата: Воскресенье, 14 Июня 2015, 23:46 | Сообщение # 79
почетный гость
Сейчас нет на сайте
Цитата Kos94ok ()
Реализовав шрифты однажды, я больше не хочу этим заниматься )

Ох как я тебя понимаю. Для меня интерфейс самая гемморойная часть разработки.
Kos94okДата: Пятница, 19 Июня 2015, 22:03 | Сообщение # 80
почетный гость
Сейчас нет на сайте
Вот интересно, я один сталкиваюсь с совершенно необъяснимыми проблемами, когда работаю с сетевым кодом? Причем проявляются они только в реальной ситуации. Локальный сервер - никаких проблем. Сервер + клиент на одном ПК - проблемы есть, но все вполне себе работает. Сервер на одной машине, клиент на другой (обе передо мной, соединение через внешний адрес) - работает. Но как только я пытаюсь протестировать систему с кем-то, так все резко перестает работать, и соединение проходит правильно только когда звезды на небе верно расположатся...

Сообщение отредактировал Kos94ok - Пятница, 19 Июня 2015, 22:04
  • Страница 4 из 6
  • «
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг