Архитектура игры. Разные вопросы.

[intmain]

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

Игру как я думаю можно, начать писать - с низу vs с верху.

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

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

Короче как мне кажется, я всегда пользовался первым способом (с низу).
Хочу понять: Как же мне переучить себя на второй способ ? Нужен ли он и какой вообще лучше ? Может есть еще что-то ?

[s-andriano]

Эти два способа применимы не только к играм - а вообще к любым программам.

IMHO планомерно переучивать себя на 2-й способ имеет смысл только для работы в команде. Просто потому, что иначе в команде работать нельзя.

При работе в одиночку мне представляется наиболее продуктивным сочетание этих способов:
- проектирование сверху,
- написание кода снизу*.

* перемежается как бы "из середины" - когда сверху пишется не проект в целом, а некоторый достаточно крупный его блок.

[intmain]

- проектирование сверху,
- написание кода снизу*.

вот об этом я и думал.

Проектирование в данном и упрощенном виде это что?
Набросал кучу абстрактных классов, связал их как-то и все ?

[s-andriano]

Зачем же в упрощенном виде?

А классы - это уже вопрос реализации, а не проектирования.

[intmain]

Зачем же в упрощенном виде?

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

А классы - это уже вопрос реализации, а не проектирования.

Согласен. Можно ж и процедурно. Но в проектировании это как-то отражается наверное ?

[s-andriano]

Сообщение от intmain

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

Просто и надежно - это, нередко, взаимоисключающие требования.

Согласен. Можно ж и процедурно. Но в проектировании это как-то отражается наверное ?

Строго говоря, реализацию, конечно, тоже нужно проектировать, но это самый нижний уровень проектирования.
Примерно так:
1. Цели.
2. Задачи.
3. Функции (не подпрограммы, а "фичи").
4. Пользовательский интерфейс.
5. Реализация (классы - тут).

[intmain]

Просто и надежно - это, нередко, взаимоисключающие требования.

Разве? Мне кажется это зависит от того, при каких условиях и для чего.
В условиях диких рыночных отношений, нередко, выгоднее делать сложно и не надежно. Хотябы последнее.
Чтобы получать прибыля на продаже и на обслуживании.
Субъекты это понимают и уменьшают общий уровень качества обоих.
И конкуренция на помойке как бы получается.

В условиях марсианской экономической модели. Все отлично.
Субъектов экономических отношений попросту нет.

Примерно так:
1. Цели.
2. Задачи.
3. Функции (не подпрограммы, а "фичи").
4. Пользовательский интерфейс.
5. Реализация (классы - тут).

В ближайшее время попробую в таком виде оформить наброски для двига двигаясь курсом проектирования с верху.
Диаграммы, связи, наверное, придется рисовать в pant.

обнов.
В ворде что-то набросал. Это какой из пяти пунктов 5 ?
Doc1.doc

[s-andriano]

Сообщение от intmain

Разве? Мне кажется это зависит от того, при каких условиях и для чего.
В условиях диких рыночных отношений, нередко, выгоднее делать сложно и не надежно. Хотябы последнее.
Чтобы получать прибыля на продаже и на обслуживании.

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

В ворде что-то набросал. Это какой из пяти пунктов 5 ?
Вложение 59950

Понятия не имею.
Я не открываю вложения. Особенно в проприетарных форматах.

[intmain]

Если Ваша игра будет падать при любом удобном случае

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

Я не открываю вложения. Особенно в проприетарных форматах.

они как бы не кусаются. там диаграмма и всего-то.

[intmain]

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

class Entity 
{
// туду: бла бла
};

Вопрос для чего?
И можете ли вы привести пример такой простейшей иерархии чтобы даже я разобрался.