Re[4]: Rsdn.Game
От: loknalori Россия  
Дата: 25.01.06 05:42
Оценка:
L>>Да ни куда не пропали. Народ загорелся но в итоге не откликнулся — в результате...
А>и что в итоге...? Надо продолжать.

Мне кажется начать надо не с этого.
Итак:
ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!
Re[5]: Rsdn.Game
От: alxkolm  
Дата: 25.01.06 06:58
Оценка: :)
Здравствуйте, loknalori, Вы писали:
L>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!

я с вами. только ребята я не программист.
Re[6]: Rsdn.Game
От: loknalori Россия  
Дата: 25.01.06 08:50
Оценка:
Здравствуйте, alxkolm, Вы писали:

A>Здравствуйте, loknalori, Вы писали:

L>>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!

A>я с вами. только ребята я не программист.

А кто, если не секрет? А то, может, это будет и луше, даже.
Re[5]: Rsdn.Game
От: tripolox Россия  
Дата: 25.01.06 20:03
Оценка:
Здравствуйте, loknalori, Вы писали:

L>Мне кажется начать надо не с этого.

L>Итак:
L>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!

Я еще живой, некогда было.
Я C# программист.
Re[5]: Rsdn.Game
От: Macedonian Россия  
Дата: 26.01.06 01:03
Оценка:
Здравствуйте, loknalori, Вы писали:

L>>>Да ни куда не пропали. Народ загорелся но в итоге не откликнулся — в результате...

А>>и что в итоге...? Надо продолжать.

L>Мне кажется начать надо не с этого.

L>Итак:
L>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!

Вроде жив пока... Сессия в разгаре, поэтому я временно не активен
Re[6]: Rsdn.Game
От: loknalori Россия  
Дата: 26.01.06 09:24
Оценка:
Здравствуйте, Macedonian, Вы писали:

M>Вроде жив пока... Сессия в разгаре, поэтому я временно не активен

Так, не гундеть. Надо мной диссер не дописаный весит, я же не бухчу!

На самом деле у меня со временем тоже швах, но от этого час-полтора занятий фигней ни куда не девается

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

Я — С++ (чуть-чуть C#, но слабо). В основном — MFC программист, проектировани БД и немного их реализация. В паралели некоторый опыт работы (правда высокоуровневой) с железками (контроллеры, фотоаппараты и тп). Профессионально программированием занимаюсь 2-3 года (смотря как считать).
Re[5]: Rsdn.Game
От: XilenteZ Россия  
Дата: 27.01.06 07:45
Оценка:
Здравствуйте, loknalori, Вы писали:

L>>>Да ни куда не пропали. Народ загорелся но в итоге не откликнулся — в результате...

А>>и что в итоге...? Надо продолжать.

L>Мне кажется начать надо не с этого.

L>Итак:
L>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!
Мне данная тема очень интересная, только я совсем начинающий программист . Кстати посмотри здесь
... << RSDN@Home 1.1.4 @wamp>>
It’s never too late to take a fucked up life to a beautiful state.
(c) Crazy Town
Re[5]: Rsdn.Game
От: KeyMaster Россия  
Дата: 27.01.06 11:10
Оценка: +1
loknalori,

Уже есть окончательная версия игрового мира? если есть, выложите или киньте ссылку плиз.
Re[5]: Rsdn.Game
От: Аноним  
Дата: 21.02.06 06:56
Оценка:
Начали за здравие (тип игрухи Real4X), закончили — за упокой (какие-то моря, роботы и т.п.)

Есть опыт реализации сервера и клиента реал-тайм стратегии типа Stars! и Real4X, 2D с использованием OpenGL, НО на Delphi.
1. Вселенная не ограничена (генерируется по мере необходимости)
2. Трафик минимальный (т.к. кусок серверной части реализован в клиенте и пересылаются только то что изменилось из того что видит клиент — радары рулят).
В песпективе реализовать в виде CGI (dll) и, соотетственно, прицепить web-интерфейс.


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re[6]: Rsdn.Game
От: loknalori Россия  
Дата: 22.02.06 08:39
Оценка:
Здравствуйте, ManGo, Вы писали:

MG>Начали за здравие (тип игрухи Real4X), закончили — за упокой (какие-то моря, роботы и т.п.)

А какая разница море или нет — космос превратится в море, планеты в острова
MG>Есть опыт реализации сервера и клиента реал-тайм стратегии типа Stars! и Real4X, 2D с использованием OpenGL, НО на Delphi.
MG>1. Вселенная не ограничена (генерируется по мере необходимости)
MG>2. Трафик минимальный (т.к. кусок серверной части реализован в клиенте и пересылаются только то что изменилось из того что видит клиент — радары рулят).
MG>В песпективе реализовать в виде CGI (dll) и, соотетственно, прицепить web-интерфейс.

Ну какая разница, Дельфи-не дельфи. Мы мальчики взрослые, как нибудь склеим. Нам ведь дикая производительность не нужна...
Re[6]: Rsdn.Game
От: Аноним  
Дата: 22.02.06 20:16
Оценка:
Готов подключиться к работе. Нужно разработать спецификацию...


данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение
Re[6]: Rsdn.Game
От: WoldemaR Россия  
Дата: 14.03.06 10:04
Оценка: 2 (1)
Здравствуйте, Macedonian, Вы писали:

M>Если реализовывать без пошаговости, то получим проблему, которую необходимо избежать: значительно больший шанс на победу у игрока, затрачивающего на игру больше времени. Игровая ситуация постоянно меняется, что требует принятия своевременных решений. Например, идет партия, борьба равная, но на третий день наступила важная битва, а один из игроков, по какой-либо причине, не может играть (работа, учеба, ночь на дворе и т.д.). В итоге победа достается второму игроку. Несправедливо. После пары таких поражений опускаются руки. В случае пошаговости подобные случайности отсутствуют. До каждого принятия решения обе стороны видят одинаковую картину, после чего происходят события, являющиеся результатом совместного принятия очередного решения и вмешаться в эти события до определенного момента (следующего хода) уже нельзя.


Простите что вмешиваюсь. Позвольте сформулировать цель следующим образом: Главное, чтобы игроки, имеющие разную игровую активность, в том числе и по причине занятости, получали достаточное удовольствие от участия в игре. Если вас такая формулировка устраивает, по позвольте предложить вам один рецепт.
В стратегической игре участник может использовать ресурс на добычу и накопление ресурса. Таким образом он из категории военных переходит в категорию промышленников и банкиров. Что это даёт?
Во первых, приумноженный ресурс можно перенести в другую партию. Это нарушит баланс сил, но в этом и цель игрока — получить преимущество. Зато это можно скомпенсировать возможностью ограбления мамона. А теперь внимание!:
По окончании партии у грабителя и пострадавшего появляется общий заблокированный счёт. Для снятия денег(ресурса) со счёта (равного сумме на момент грабежа) надо каждому ответить на вопрос: "кому отдать средства?" — другому или себе. И тут вступает в игру известная психологическая дилема, потому что:
1) если оба ответят — "отдать другому", то каждый получит половину.
2) если оба укажут на одного, то он получит всё.
3) если оба захотят взять себе, то никто ничего не получит.

Вот такая фича. Если она вам понравилась, то я чуть позже постараюсь написать ещё что нибудь интересное.
Re: Rsdn.Game
От: JazzzMaster Россия  
Дата: 25.03.06 02:05
Оценка:
Здравствуйте, loknalori, Вы писали:

L>

L>Ну вот как-то так. Надеюсь что встречу единомышленников-единоверцев. И, в любом случае, хотелось-бы почитать коментарии.

Ну что, проект умер медленной тихой смертью? Или все в силе?
В общем, хочу поделиться своими мыслями. По-моему все сводится к тому, чтобы действительно сделать "игру для программистов". Подумав, над этим делом решил написать свои мысли по этому поводу.
1) Надо создать что-то концептуально новое, непохожее на обычные Strategy и RPG, только так можно вызвать интерес и привлечь достаточное число энтузиастов в разработку. Еще один клон Starcraft с оооочень медленным реалтаймом никому не нужен.
2) Игрок перед началом игры программирует поведение всех юнитов. Игра происходит в realtime без участия игрока. Запрограммировавший наиболее оптимальный алгоритм развития игрок побеждает. Т.е. своего рода война алгоритмов развития. Это избавляет игрока от участия в процессе самом игры (битвы) и сообветственно отпадает проблема разницы часовых поясов и свободного времени у играющего.
3) Исходные данные у игроков равны. Игрок дожен сконцентрироваться на алгоритме развития. 1 раса, 1 абстрактный вид ресурсов (можно обозначить как $), 1 база с которой начинать развитие. В игровом мире имеется некоторый набор свойств(скиллов, возможностей, видов оружия и т.п.) из которых можно создавать свой собственный юнит. Скиллы, к примеру — Healph Pack, Speed, Ammo Pack. Возможности — возможность сбора ресурсов, постройка зданий, возможность ремонта других юнитов. Оружия — пушки, пулеметы, гранатометы и все остальное. Все это можно нацепить в некоторых количествах на один юнит либо на здание. Каждое свойство юнита будет стоить некоторое число money и может влиять на другие свойства (например, число ammo pack и количество навешенного оружия влияет на speed).
4) Согласен с Macedonian по поводу

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

5) Сделать одну точку сбора ресурсов, чтобы юниты не разбредались по всему игровому полю. Т.е. сделать своеобразное место встречи, которое будет стремиться захватить каждый игрок. Захватил точку с ресурсами — считай победа у тебя (хотя не факт). Другим игрокам надо либо отбивать его у тебя либо сдаваться. Собственно, основная цель этого введения — не затягивать игру.
6) Игрок проиграл, если уничтожены все его здания.

Привожу пример игрового мира. Космос. Ресурс — космическая пыль (как в Homeworld). 4 игрока. У каждого в начале игры база, 500 $ на начало развития, 1 юнит с 100 hp и 5 speed. Начинаем строить юниты со скиллом сборщика ресурсов. Параллельно можно к ним пожцеплять навыки — speed, attack, extendeв ammo, extended health, но на каждый навык уходит определнное количество ресурсов $. К примеру, можно построить 1 сборщик с высоким навыком атаки и защиты и низкой скоростью, либо 3 сборщика и низкими навыками атаки и защиты и низкой скоростью, либо 10 сборщиков без навыков атаки и защиты, но с оч. высокой скоростью. Все начинают собирать ресурсы, параллельно пытаясь выбить игроков с точки сбора ресурсов. Естественно, алгоритмы сбора и поведения юнитов в битве программируются заранее (перед началом игры) игроком.
В общем суть моих мыслей ясна, я думаю. Теперь ваши мысли вслух.

P.S. to Macedonian: я тоже из Комсомольска
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[2]: Rsdn.Game
От: Macedonian Россия  
Дата: 25.03.06 03:49
Оценка:
Здравствуйте, JazzzMaster, Вы писали:

JM>Ну что, проект умер медленной тихой смертью? Или все в силе?

Вопрос, конечно, интересный
JM>В общем, хочу поделиться своими мыслями. По-моему все сводится к тому, чтобы действительно сделать "игру для программистов". Надо создать что-то концептуально новое, непохожее на обычные Strategy и RPG, только так можно вызвать интерес и привлечь достаточное число энтузиастов в разработку. Еще один клон Starcraft с оооочень медленным реалтаймом никому не нужен.
Согласен.
JM>2) Игрок перед началом игры программирует поведение всех юнитов. Игра происходит в realtime без участия игрока. Запрограммировавший наиболее оптимальный алгоритм развития игрок побеждает. Т.е. своего рода война алгоритмов развития. Это избавляет игрока от участия в процессе самом игры (битвы) и сообветственно отпадает проблема разницы часовых поясов и свободного времени у играющего. Исходные данные у игроков равны. Игрок дожен сконцентрироваться на алгоритме развития. 1 раса, 1 абстрактный вид ресурсов (можно обозначить как $), 1 база с которой начинать развитие. В игровом мире имеется некоторый набор свойств(скиллов, возможностей, видов оружия и т.п.) из которых можно создавать свой собственный юнит. Скиллы, к примеру — Healph Pack, Speed, Ammo Pack. Возможности — возможность сбора ресурсов, постройка зданий, возможность ремонта других юнитов. Оружия — пушки, пулеметы, гранатометы и все остальное. Все это можно нацепить в некоторых количествах на один юнит либо на здание. Каждое свойство юнита будет стоить некоторое число money и может влиять на другие свойства (например, число ammo pack и количество навешенного оружия влияет на speed).
JM>4) Согласен с Macedonian по поводу
JM>

JM>Обобщая эту идею, можно задать разумные алгоритмы по умолчанию для самых распространенных действий. Игрок может задать свои алгоритмы для класса юнитов, группы юнитов, либо для отдельных юнитов. Поведение юнита получаем по следующей цепочке: алгоритм для конкретного юнита, для группы юнитов, для класса юнитов, по умолчанию. Т.е. наибольший приоритет у алгоритма для конкретного юнита, наименьший — у алгоритма по умолчанию.

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

  1. Сложность написания алгоритма на все случаи жизни, иначе получим ситуацию "камень-ножницы-бумага". Например, стратегия направленная на постоянную атаку проигрывает стратегии "от защиты", но выигрывает алгоритм, направленный на повышенную добычу ресурсов.
  2. Уменьшение доли творчества. В случае пошаговости игры, можно менять поведение юнитов (алгоритмы), исходя из сложившейся уникальной ситуации (неудача/удача при атаке/защите, изменение соотношения сил на каком-либо участке карты и т.д.). Таким образом, увеличивается зрелищность и простор для творчества. Если добавлять новые алгоритмы, отвечающие за какие-либо конкретные ситуации, только после просмотра завершившейся игры, то нет никаких гарантий, что одна и та же ситуация повторится в будущем.

JM>5) Сделать одну точку сбора ресурсов, чтобы юниты не разбредались по всему игровому полю. Т.е. сделать своеобразное место встречи, которое будет стремиться захватить каждый игрок. Захватил точку с ресурсами — считай победа у тебя (хотя не факт). Другим игрокам надо либо отбивать его у тебя либо сдаваться. Собственно, основная цель этого введения — не затягивать игру.

JM>6) Игрок проиграл, если уничтожены все его здания.
Насчет пунктов 5) и 6) есть небольшая идея. Можно ввести плату в сколько-нибудь ден. ед. за относительную ценность юнита (напр., сумму значений всех его характеристик) на поддержание его работы. Если нет денег, то юнит умирает. Путем введения критерия проигрыша как отсутствие денег и юнитов, избавляемся от бесконечных партий (количество потенциальных ресурсов на карте ограничено).

JM>Привожу пример игрового мира. Космос. Ресурс — космическая пыль (как в Homeworld). 4 игрока. У каждого в начале игры база, 500 $ на начало развития, 1 юнит с 100 hp и 5 speed. Начинаем строить юниты со скиллом сборщика ресурсов. Параллельно можно к ним пожцеплять навыки — speed, attack, extendeв ammo, extended health, но на каждый навык уходит определнное количество ресурсов $. К примеру, можно построить 1 сборщик с высоким навыком атаки и защиты и низкой скоростью, либо 3 сборщика и низкими навыками атаки и защиты и низкой скоростью, либо 10 сборщиков без навыков атаки и защиты, но с оч. высокой скоростью. Все начинают собирать ресурсы, параллельно пытаясь выбить игроков с точки сбора ресурсов. Естественно, алгоритмы сбора и поведения юнитов в битве программируются заранее (перед началом игры) игроком.

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

JM>P.S. to Macedonian: я тоже из Комсомольска

Я со Дзёмог
Re[3]: Rsdn.Game
От: JazzzMaster Россия  
Дата: 25.03.06 14:44
Оценка:
Здравствуйте, Macedonian, Вы писали:

M>В итоге получаем идеальный баланс, почти как в шахматах . Вот только сомневаюсь в том, что вся партия должна вестить от начала до конца по одним и тем же алгоритмам. Вижу как минимум два недостатка:


M>

    M>
  1. Сложность написания алгоритма на все случаи жизни, иначе получим ситуацию "камень-ножницы-бумага". Например, стратегия направленная на постоянную атаку проигрывает стратегии "от защиты", но выигрывает алгоритм, направленный на повышенную добычу ресурсов.
    M>
  2. Уменьшение доли творчества. В случае пошаговости игры, можно менять поведение юнитов (алгоритмы), исходя из сложившейся уникальной ситуации (неудача/удача при атаке/защите, изменение соотношения сил на каком-либо участке карты и т.д.). Таким образом, увеличивается зрелищность и простор для творчества. Если добавлять новые алгоритмы, отвечающие за какие-либо конкретные ситуации, только после просмотра завершившейся игры, то нет никаких гарантий, что одна и та же ситуация повторится в будущем.
    M>
Вот тут по-моему ключевой момент. Вообще, я против затягивания процесса игры. Пошаговость предполагает игру очень продолжительное время. Это все равно, что играть в шахматы по почте. Попробуй, как-нибудь на досуге. По-моему у игрока в конце концов пропадет интерес играть одну партию несколько недель или месяцев, особенно если выяснится, что он изначально выбрал неправильный путь развития, который не приводит к выигрышу. Короче, надо домыслить в этом направлении, аргументы в ту или иную пользу принимаются.

M>Насчет пунктов 5) и 6) есть небольшая идея. Можно ввести плату в сколько-нибудь ден. ед. за относительную ценность юнита (напр., сумму значений всех его характеристик) на поддержание его работы. Если нет денег, то юнит умирает. Путем введения критерия проигрыша как отсутствие денег и юнитов, избавляемся от бесконечных партий (количество потенциальных ресурсов на карте ограничено).

Это вопрос не критичный, поэтому к нему можно будет вернуться позже.

M>Количество игроков больше 2-х отрицательно сказывается на балансе, т.к. игрок с хорошей стратегией может проиграть алгоритмам по умолчанию, если те, вдруг, решат одновременно на него напасть. Предлагаю сделать основой игру 1х1, а остальное (2х2, 1х1х1х1 и т.д.) по желанию.

Для начала вполне возможно и так. Это тоже вопрос не принципиальный.

M>Я со Дзёмог

Гайтер-1, в/ч 20117, Космические войска

P.S. Хотелось бы услышать мнение организатора сего мероприятия. loknalori, отзовись!
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[4]: Rsdn.Game
От: Macedonian Россия  
Дата: 26.03.06 01:31
Оценка:
Здравствуйте, JazzzMaster, Вы писали:

JM>Здравствуйте, Macedonian, Вы писали:


M>>В итоге получаем идеальный баланс, почти как в шахматах . Вот только сомневаюсь в том, что вся партия должна вестить от начала до конца по одним и тем же алгоритмам. Вижу как минимум два недостатка:


M>>

    M>>
  1. Сложность написания алгоритма на все случаи жизни, иначе получим ситуацию "камень-ножницы-бумага". Например, стратегия направленная на постоянную атаку проигрывает стратегии "от защиты", но выигрывает алгоритм, направленный на повышенную добычу ресурсов.
    M>>
  2. Уменьшение доли творчества. В случае пошаговости игры, можно менять поведение юнитов (алгоритмы), исходя из сложившейся уникальной ситуации (неудача/удача при атаке/защите, изменение соотношения сил на каком-либо участке карты и т.д.). Таким образом, увеличивается зрелищность и простор для творчества. Если добавлять новые алгоритмы, отвечающие за какие-либо конкретные ситуации, только после просмотра завершившейся игры, то нет никаких гарантий, что одна и та же ситуация повторится в будущем.
    M>>
JM>Вот тут по-моему ключевой момент. Вообще, я против затягивания процесса игры. Пошаговость предполагает игру очень продолжительное время. Это все равно, что играть в шахматы по почте. Попробуй, как-нибудь на досуге. По-моему у игрока в конце концов пропадет интерес играть одну партию несколько недель или месяцев, особенно если выяснится, что он изначально выбрал неправильный путь развития, который не приводит к выигрышу. Короче, надо домыслить в этом направлении, аргументы в ту или иную пользу принимаются.

Не так давно я занимался шахматами серьезно, и по переписке тоже играл. Здесь смысл в том, что ничто не мешает вести несколько партий в одно и то же время. В любом случае, можно ввести разные контроли времени на партию при пошаговом режиме (х дней на партию). Кстати, при участии в одноходовых партиях можно оставить свою программу на сервере и забыть про это дело на недельку (возможно, выставив максимальное количество игр в день), а затем просмотреть записи игр (это не плюс и не минус, просто идея ).
Re[5]: Rsdn.Game
От: loknalori Россия  
Дата: 27.03.06 04:35
Оценка:
Loknalori тут. Проект жив, т.к. пока умирать нечему.

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

На неделе посмотрю всякие системы для коллективного составления хелпов. Начну с той которой хелпы к фаерберду делают. Рекомендую и прошу всех остальных сделать тоже самое.

Как-то так...
Re[5]: Rsdn.Game
От: gran  
Дата: 25.04.06 11:48
Оценка:
Здравствуйте, loknalori, Вы писали:

L>>>Да ни куда не пропали. Народ загорелся но в итоге не откликнулся — в результате...

А>>и что в итоге...? Надо продолжать.

L>Мне кажется начать надо не с этого.

L>Итак:
L>ЛЮЮЮЮЮЮДИ! КТО ЕЩЕ ЖИВОЙ! КТО ЕЩЕ С НАМИ! СКОЛЬКО НАС???? А? ОТЗОВИТЕСЬ!!!

Запишите и меня.
Если что могу занятся внутренним языком. Имею опыт написания трансляторов.
Re[6]: Rsdn.Game
От: Аноним  
Дата: 18.05.06 21:37
Оценка:
Здравствуйте, gran, Вы писали:

G>Запишите и меня.

G>Если что могу занятся внутренним языком. Имею опыт написания трансляторов.

Жалко, что проект загнулся так и начавшись. Хотя перспективность идеи очевидна, в том числе, если бы кто-нибудь захотел заняться, и коммерческая. Нет паровоза, который взял бы на себя организаторскую составляющую проекта.
На мой взгляд, с точки зрения организации совместной работы, необходимо разработать ядро — этакий супервизор (хорошая ассоциация с созданием Linux). Все остальное реализовывать участниками в виде подключаемых модулей (форма может быть любая — dll как плугины, интерфейсы и т.п.). Здесь бы и пригодися опыт написания внутреннего языка, например, для написания скриптов поведения как на уровне ядра — описание поведения системных объектов (космическая пыль, астероиды, и т.п.), так и на пользовательском уровне — для управления объектами (например, во время отсутсвия игрока).
Нужен отдельный отдельный сайт для накопления информации, документации, репозитарий кода.
Кто возьмется?
Re: Rsdn.Game
От: Torinous Россия  
Дата: 19.05.06 10:25
Оценка:
Здравствуйте, loknalori, Вы писали:

Вот думал, думал и скрепя сердце таки нажал.

Хочу присоедениться к вашей дружной компании, правда профессиональный уровень у меня невысок.
Программирую на C++, сейчас с C#`ом разбираюсь, студент на дипломе.

Сразу хочу сказать вам похоже надо просить отдельный форум на RSDN, но это может быть потом.
А сейчас нужно продумать алгоритм общения, форум подходит проекту больше на конечном этапе, когда люди уже разделились на подгруппы обсуждают свои части, но выработать единый дизайн-проект(или как это правильно называется) по-моему будет тяжеловато.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.