Разработка игры [Название не имеется]

Хммм, один человек работает на тем, что он и так сделал, а группе ещё разбираться в коде других надо)

 

Значит это плохая группа.

 

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

 

У меня есть пара идей для игр, но я буду писать своё ядро так-как это интереснее)

 

Я мог бы и продолжить дальше, но не увидел смысла делать что-то дальше, ибо в моделировании полный ноль, квесты тоже не мой конек, да и в одиночку действительно не очень хорошо все делать

 

Я в квестах профи

 

Ага, на шарпе.

И лет через 500 бы...

 

А почему бы и нет?) .XNA есть же) С её помощью мб что-то, да получится)

 

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

 

Все творения человека начались с: "А почему бы и нет?"

 

Аспекты движка нужно очень тщательно прорабатывать, а то может получиться очень глючный движок, пример Sonic the Hedgehog 2006.
Для быстроты движка рекомендую чтобы игра определяла игровые карты в 2D, а движок преобразовывал в 3D для игрока.
Физическую составляющую движка лучше делать подобно физике марионеток.
Для физики будет нужен интерпретатор.
Все мои советы касательно движка.

 

[QUOE="HyperCOGENT, post: 1057490, member: 62979"]Движок лучше писать на Си, потому что Си более гибкий язык программирования.
Аспекты движка нужно очень тщательно прорабатывать, а то может получиться очень глючный движок, пример Sonic the Hedgehog 2006.
Для быстроты движка рекомендую чтобы игра определяла игровые карты в 2D, а движок преобразовывал в 3D для игрока.
Физическую составляющую движка лучше делать подобно физике марионеток.
Для физики будет нужен интерпретатор.
Все мои советы касательно движка[/QUOTE]

1. Писать на C будет гораздо сложнее => если движок делается одним человеком, то ему быстро надоест. Лучше использовать тот же C# с вызовами нативного кода в критичных местах.
2. Как вы себе представляете конвертацию 2D в 3D? Да ещё такую, чтобы производительность возрастала...
3. Зачем для физики интерпретатор? Что он будет интерпретировать, падающие бочки?

 

1. Писать на C будет гораздо сложнее => если движок делается одним человеком, то ему быстро надоест. Лучше использовать тот же C# с вызовами нативного кода в критичных местах.
2. Как вы себе представляете конвертацию 2D в 3D? Да ещё такую, чтобы производительность возрастала...
3. Зачем для физики интерпретатор? Что он будет интерпретировать, падающие бочки?

[/QUOTE]
1.Нужна кроссплатформенность и гибкость.
2.Игра будет определять 2D, а движок просто будет накладывать спрайты и полигоны.
3.Интерпретатор нужен для объектов.

 

1. Благодаря Mono проблем с кроссплатформенностью не будет, тем более сейчас открыли исходники ядра .NET. И я не говорил: "нужно использовать только C#", это был лишь пример. Сойдёт тот же D (простота кода, производительность и кроссплатформенность).
2. Если нужно нормальное 3D, то от таких извращений лучше отказаться.
3. Повторяю вопрос: что он будет интерпретировать? Для физики просто нужен любой физический движок.

P.S. Здесь никто не собирается писать большой сложный проект, люди просто хотят сделать свою игру (некоторые и небольшой движок), которая будет работать. Для этого не нужно городить костыли.

 

1. Действительно.
2. А вот тут лучше делать в 3D не всё сразу.
3. А интерпретировать он будет физику предметов.

 

А ничего, что C как бы не поддерживает ООП?
Тогда уж лучше на плюсах, что будет вполне логично.

 

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

Физику нужно не интерпретировать (там интерпретировать нечего), а симулировать.

 

Не делает. Пиксельная змейка устроит?

 

Почему сразу "пиксельная змейка"? Движок игры Doom был написан на C и ASM.

 

Unreal Engine возьми) достаточно популярен и удобен