Войти
ПроектыФорумОцените

Всем Начинающим Разработчикам

#0
12:25, 18 авг. 2003

Итак обращаюсь в первую очередь к начинающим.

За две недели обитания на этом форуме в разделе "проекты" появилось 5 новых предложений по созданию игры. Но чё то народ не особо захотел поддерживать эти проекты.

Обясняю почему.
1. Голыми словами никого не заинтересуешь. Вот если бы были какие нибудь базовые наработки
тогда и народ бы пошёл. Увы такова человеческая натура. Начинать всегда очень и очень сложно.
2. Если за две недели только 5проектов то я так полагаю что за время существования данного ресурса их было окол сотни. Так что ничем обитателей форума не удивишь.

Но что же делать если идею реализовать очень хочется, а тебя поддерживать никто не хочет.

Предлагаю создать ОБЩИЙ ДВИЖОК. Или на худой конец Алгоритмическую базу, или Библиотеку классов.
Т.Е нет конкретной игры которую бы мы все вместе создавали. Предлагаю создавать просто программу заточенную под опредилённые цели, или на худой конец алгоритмическую базу.

Суть Идеи какая:
ПРОВЕДЁМ ДЕКОМПОЗИЦИЮ ПРОБЛЕМЫ(СОЗДАНИЯ ДВИЖКА) НА БОЛЕЕ МЕЛКИЕ ЗАДАЧИ И ПРОБЛЕМЫ.
КАЖДЫЙ ВОЗЬМЁТ ШЕВСТВО НАД ОДНОЙ ИЗ НИХ И КОГДА ОНИ БУДУТ РЕАЛИЗОВАНЫ СОЕДИНИТЬ ВСЁ ВМЕСТЕ. Результат будет использоваться каждым участником по своему усмотрению и для своей конкретной игры.

ТО есть когда будет движок, найти художников, сценаристов, дополнительных програмистов будет намного проще. У вас будет уже что то готовое.
Чтобы реализовать мечту надо на время объединиться.


Схема взаимодействия.

1. Определить требования к Движку(далее Д.)
2. Составить список проблем которые надо решить(только програмисстские проблемы)
3. Проектируем Д. (Можно даже на UML)
4. Составление Технических заданий
5. Разместить эти ТЗ и распределить между участниками.
6. Сборка отдельных частей, тестирование, до работка
7. Сборка всех частей в единое целое.

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

Я не думаю что кто то развалиться потратив свои драгоценные 10-15 часов на реализацию одного двух классов.

Я думаю результат будет того стоить.


#1
20:08, 18 авг. 2003

А у меня есть утопия:
"Объектно-Ориентированная Универсальная Операционная  Система Российского ГамеДева"

#2
21:05, 18 авг. 2003

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

#3
6:55, 19 авг. 2003

ogre.sf.net - есть и структура, UML диаграммы, примеры использования и открытый код под LGPL. Бери и делай игру, а не велосипед (движек)

#4
9:12, 19 авг. 2003

Проблема на данный момент стоит следующая...

Необходимо продумать концепт движка...(я лично за реализм).
1. Для каких нужд..
2. Nemo выносил предложение делать уинверсальный и для шутеров аркад и для RPG но сами понимаете процесс будет трудоемкий.
3. Опрелить перспективы движения.  и выбрать API... Я лично за OpenGL 2.0..С первоначальной ориентацией на FX5900Pro и Radeon 9800 Pro.
4. Создать постоянную тему в форуме и назвать движок хоть как нибудь на первое время..

Вот собственно первоначальные моменты...

#5
11:41, 19 авг. 2003

Я за Dx9 поскольку у меня есть небольшая программка которая грузит из ХМL Сцену. В ней есть простенький UI(Спрайты и кнопки) Свет. (есть отсечение по фруструму) Ну и упраление камерой(почти как в кваке), ну и текстуры накладывает, мип мапинг есть, туман.

Ride
Надо начинать хоть что то делать тогда народ я думаю подключится.

По поводу структуры движка есть идея такая
вести разработку по 3м иерархиям классов. Графика, Физика, ИИ. Потом единый объект унаследуем от трёх иерархий.

И общая реализация как  Виндовс. То есть на сообщениях. Произошло событие сгенирилось собщение. Ядро программы среагировала на сообщение.

#6
11:44, 19 авг. 2003

mudagen ок. нас уже трое. Надо подумать над структурой физических объектов

#7
11:44, 19 авг. 2003

md3ds1

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

#8
12:25, 19 авг. 2003

Основной каркас предлагаю спереть у Майкросфт. Который Генерится с помощью DXWizard. И преспособить под OpenGL.

Каждый объект обязательно должен иметь такие методы

1. Create() или Init()
2. Render();
3. FrameMove() если его параметры и поведение не статично
4. DeleteObject()
Объект должен создавться одним методом crеate

Каждый класс или иерархия классов лежат в одном H и Срр файле

Какие проблемы надо на данны момент решить
КАРКАС Приспособить Под GL (под DX он уже приспособлен)

Классы которые в первую очередь должны быть реализованы
СVertex
CBoundBOX
CCamera
CInput
CScena
CLight
CObject

Формат сцены предлагаю сделать XML
надо сделать Класс
CXMLUtils

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

#9
14:38, 19 авг. 2003

Вы тогда уж сразу делайте игровой конструктор (потому что какой смысл делать N+1 графический движок? Ими и так Интернет переполнен, в том числе и достаточно хорощими бесплатными , например, Nebula). А если вам удастся сделать хороший игровой конструктор, в котором будут воплощены последние достижения в 3Д графике, ИИ и прочем, то это было бы неплохо. То, что есть в настоящее время в этой области не выдерживает никакой критики (в смысле графики, да и, скорее всего и остального соедржтимого).

#10
0:02, 20 авг. 2003

Мне лично M$ каркас не очень нравится. Слишком много наследования. Совершенно ненужный обькт CMyApplication и его наследники и всё такое... Проще и эффективнее ЭТО реализовать в обычных функциях. Про остальные классы- в основном согласен.
Идейка такая
Имеется класс CActor - любое действующее лицо. Он имеет ссылки на CGraphicObject и CPhysicObject.
Т.к. может быть 100 одинаковых монстров, то нет смысла хранить в памяти 100 одинаковых текстур и моделей - достаточно одной. То же и с физикой, только у каждого должен быть ещё СОБСТВЕННЫЙ физ.обьект, трансформированный под него, но это уже детали.

CCamera наследуем от CActor
CScene - octree с геометрией, физикой(чуть не сказал "и прочей химией"), графикой и актёрами.

XML занимает много места. Я за бинарный формат.

Сообщения оправданы только иногда. Например в AI. Часто они не нужны или создают лишнюю работу, когда можно просто вызвать метод.

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

Например, есть 200 ГОТОВЫХ способов рисовать quadtree и 100 текстурировать кубик. Всё это придётся выкладывать на даунлоад, скачивать и голосовать за лучший алгоритм, или делать что-то среднее.

В общем, отражение моего видения мира(!) и взгляда на структуру движка можно увидеть в моём движке:( (скромно улыбается)

Выкладывайте свои наработки, будем смотреть.

#11
1:17, 20 авг. 2003
//Это примерное описание иерархии классов и структуры движка
//Правила языка, как русского, так и C++, не соблюдаются:)
//Есть интерфейс рендеринга, позволяющий писать и под Д3Д и ОГЛ
//Обьект CActor - сущность в сцене.
//IMesh - полигональный обьект, зависит от типа рендера
//Много актёров могут иметь один и тот же меш. Рисует их всё равно рендер.
//Это очень в кратце
//не пытайтесь компилировать:)

void init();
void finalize();
void main();

void display()
{
	HandleMessages()//GetMessage(), etc.
	GetInput();
	ProcessPhysic();
	renderer.renderscene();
}

void GetInput()
{
	input.update();
}

class IRenderer
{
public:
	Init()
	Finalize();
	RenderScene();
	//Дальше технические методы. Они вызываются методом Render
private:
	RenderActor();
	RenderMesh();
	RenderParticles();
}

class COglRenderer:public IRenderer;
class CD3DRenderer:public IRenderer;


class IMesh
{
	prim_type;//TRIANGLE_LIST, STRIP, FAN, etc.
}

class COglMesh;
class CD3DMesh;

class ITexture
{
	Bind();
	Bind(tex_module);
	Upload(CBitmap* bmp);//Загружает текстуру из памяти в видео
}

class COglTexture;
class CD3DTexture;

class CActor
{
	vector pos;
	quaternion rot;
}

class CCamera:public CActor{
	float fov;//угол обзора
}

class CPlayingActor:public CActor{
	ITexture* texture;//
	IMesh* mesh;//Здесь ему всё равно, пусть хоть void* - актёр никакого доступа к нему не имеет
	CBoundBox bbox;

	//можно так: это всё равно.
	[void* texture
	void* mesh]		//Это указатель, чтобы Рендерер сам преобразовал его в нужное
				//и отрендерил его.
}


class CThinkingActor:public CPlayingActor
{
	Think();//думать
	bool See(CActor* a);//Видит ли данный актёр этого?
	CActor* NearestActor(void)//Возвращает ссылку на ближйшего актёра

	и т.д. как заготовка:) для AI
}
//class CPhysicEngine делать не стоит, т.к всё это можно реализовать как набор функций.
class CPhysicObject
{

}

class CTexturedMesh:public IMesh
{
	CTexture* texture[5];//
}

//Пока просто список актёров
class CScene{
	list<CTexturedMesh*> meshlist
	list<CActor*> actorlist;
}

//OCTREE
//Хотя я считаю, надо делать quadtree/octree
class OTNode{
	OTNode *child[4];
}

class OTLeaf{
	vector<IMesh> meshes;
}
#12
20:41, 20 авг. 2003

Вопрос. Какие вершины используем?
Сколько текстурных координат? Фиксированное количество, т.е. всегда одно и то же для всех примитивов, или где-то с одной текстурой, а где-то с 4-мя?

struct vectex
{
  float x,y,z;
  float n1,n2,n3;//Нужны ил нормали? Наверное
  float u,v;
  float u1,v1;//???
}

Это на зависит от АПИ, т.к. в обоих такая структура вершины возможна.

Ещё вопрос. Используем OcTree?

#13
21:03, 20 авг. 2003

Да, насчёт доки о структуре проекта. Не одобряю. Во-первых: Зачем нам писать  m_cPosition, когда можно сделать просто pos? или Position, если хотите с большой буквы.
Кроме того, я думаю, не стоит делать такую вот ошибку - врапперы для АПИ. SetTransform() - зачем это надо? Функция рендеринга вызовет сама(внутри) lpd3ddevice->SetTransform() или glLoadIdentity()-glRotate()-glTranslate, На худой конец, glLoadMatrix().
Не против, если я выложу свой вариант этой доки? Конечно, я постараюсь учесть и пожелания того, кто её написал(по всей видимости, Nemo?), но вещи, на которые не могу смотреть спокойно, я переделаю на свой вкус.
Потом равно выяснится, какой вариант лучше. Проголосуем.

ПроектыФорумОцените

Тема в архиве.