Тут лежит описание игры (только идея)
Помогите плиз
Кстати:
программисты .NET, объединяйтесь! Писать-то можно на любом языке (хоть что-то MS'овцы правильно сделали )

Чего, ни у кого нет идей

Я раньше хотел сделать РПГ в стиле Фоллаута

Есть одна идея: не использовать Windows.Forms как основу (вроде как автор собирается делать игру на основе датагрида ).

Цитата(mr @ 30.3.2005, 03:01)

вроде как автор собирается делать игру на основе датагрида smile

Run-time error, используй DirectDraw или OpenGL, но только не Windows Forms...!!!

Это сообщение отредактировал(а) chipset - 30.3.2005, 14:07

Run-time error
3D движок на C# - посмотри для начала сюда. Может, тебе это поможет...

Насколько я знаю, лучший движок существующий под шарп сейчас, это - Irrlicht.
Здесь тоже пополняется коллекция двиглов
Хотя я не уверен что тебе не хватит обычного managed DirectX

Цитата(chipset @ 30.3.2005, 20:27)

Насколько я знаю, лучший движок существующий под шарп сейчас, это - Irrlicht.

Ты уверен?

Цитата(arilou @ 31.3.2005, 00:07)

Ты уверен?

Нет.

Я же говорю:

Цитата

Только 2D, с DirectX пока не умею работать

С OpenGL тоже
Я лично хочу заниматься составлением классов и прочей хрени, а уж с реализацией посмотрим

Цитата(Run @ 31.3.2005, 11:36)

Я лично хочу заниматься составлением классов и прочей хрени, а уж с реализацией посмотрим

То есть, ты будешь заниматься созданием модели, а её отображение "прикрутишь" после? Тогда пока что можно и в грид или даже в консоль всё выводить, согласен. Главное сейчас - это грамотно продумать архитектуру игровой модели: чтобы она была как можно более гармоничной, расширяемой и простой. Позже к классу "GameModel" можно будет прикрутить классы "InputSystem", "Engine", и т.п.

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

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

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

Цитата(mr @ 3.4.2005, 04:03)

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

Я обычно сначала начинаю с требований, и только потом медленно опускаясь по лестнице абстракции разделяю все на модули, неймспейсы, классы, функции, строчки кода...
Т.е. к примеру так, есть приложение Аркада, вопрос: что она будет делать?
1) Отражать шарик от двух бит руководствуясь текущим положением биты.
2) Шарик будет отражаться от нижней и верхней стен.
3) Если шарик проникнет в правую/левую стену, левый/правый игрок выиграл.
4) Игра будет иметь два контрола: Начать новую игру и Выйти.
Теперь пройдемся по четырем требованиям:
Ясно что будет обьект "Шар". Ясно что будет обьект "Бита".
Как шарик может держать своё направление? Правильно, с помощью вектора: класс "Вектор". Как шарик будет отражаться от стен и бит? Вероятно с функции отражения, которая будет модифицировать вектор при столкновении. Ок, но как мы отловим столкновение? Вариант: Менеджер столкновений.
Мы забыли про 5-ый пункт - управление, добавляем:
5) Биты должны управляться следующими кнопками: левая: "X","S", правая: "ВНИЗ", "ВВЕРХ".
Введём класс Game, который будет апдейтить игру, отлавливая ввод, двигать биты,
проверять коллизии, двигать шарик и проверять пункт #3.
#4 потребует класс UI, которое будет включать в себя само окно вывода, и две кнопки.
Можно спрятать код рисования биты/шарика в соответствующие классы, а можно создать другой класс отвечающий за прорисовку всей этой фигни.
..
Можно конечно заюзать UML тулзы, но карандаш+бумага тоже рулез форева

Цитата(chipset @ 3.4.2005, 22:35)

Т.е. к примеру так, есть приложение Аркада, вопрос: что она будет делать?

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

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

Цитата(arilou @ 4.4.2005, 00:53)

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

Да. Но требования, находятся на чуть более высоком уровне абстракции .
Добавлено @ 15:01

Цитата(Run @ 4.4.2005, 04:54)

Как вы думаете, идея имет право на жизнь?

Да. Таким образом, у тебя графический движок: FlexGrid, OpenGL, DirectX, et al, будет отделен от мини-игрового движка, который и будет реализовывать логику игру, а уже как оно там выводится, ему deep purple

Это сообщение отредактировал(а) chipset - 4.4.2005, 15:01