Самоуничтожение обычно делают так:

Возможно сервер на C++ будет работать шустрее, чем на С#, но это зависит, конечно, от программиста. Реальные цифры: асинхронный сокетный сервер на C#, одновременное число подключений: 100к, максимальный размер передаваемой информации - 256 байт. Запущенный на нетбуке сервер поглощал около 85Мб оперативки и почти ни капли процессора.

О, раз уж я о цифрах, то вижу небольшое превосходство сокетных серверов над HTTP - объем передаваемой информации. Хотя возможно я несведущий, но когда мой первый сервер на php обменивался килобайтами информации, то сервер на C# - лаконично лишь несколькими байтами.

Сокеты есть и в php(насчет Ruby честно не знаю), но это дикое извращение.
Возможно что-то забыл...

Добавлено (07.01.2011, 19:33)
---------------------------------------------
Вспомнил, о чем никто не упоминал даже.
База данных. Кудаж без нее.
Я выскажусь за бесплатную MS SQL Express. Сравнений производительности с MySQL(самая популярная БД у вебдевелоперов) я к сожалению не делал и не видел.

А как по Вашему мнению, при таких характеристиках как еще можно задать пределы мин/макс атаки?

Добавлено (21.12.2010, 22:53)
---------------------------------------------
В данный момент пробую вот такую систему расчета урона(как в PerfectWorld)
На каждый уровень я рассчитал максимальное количество Защиты. Сопоставить его порезке 95% урона.
Нехитрая математика - 95/Макс.защита = число, сколько пунктов защиты составляют 1% порезки урона.
Например, 15 уровень. Если делать все возможное, то максимально мы добьемся 103 защиты. И для расчетов боя: 95/103 = 0,922330097087378.
Итак, бой начинается.
Атакующий бьет своим уроном.
Пусть у защищающегося 57 защиты. Считаем: 57/0,922330097087378 = 61,8 ~ 62% урона срежем.

Так как в игре запрещены "избиения младенцев", и максимальная разница в уровнях между сражающимися 3, то думаю, такая система не самая ужасная, какую можно придумать.
Как на Ваш взгляд это?
Есть идеи?

Да, надкласс контролирует все.

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

Если игра не клиент-серверная, то я думаю, будет уместно сказать о MVC. Тоже очень помогает разделить на полочки: тут модель, тут контроллер, а тут отображение.
Её можно и в мультиплеере использовать, в клиенте. Но все равно все сводится к куче switch-case операторов.
Мне более интересно разрабатывать производительный сервер, нежели красивую оболочку К сожалению, приходится делать и то и другое.

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

В голове есть еще критический момент для системы: если встретятся два персонажа таких:
Персонаж1: Сила 10, Защита 20, Ловкость 10.
Персонаж2: Сила 20, Защита 10, Ловкость 10.
Тогда их Сила врезается в Защиту, и как-то надо делать так, чтобы не по 0 был урон...

Если ты правда программируешь, а не используешь готовые конструкторы, то не важно в чем и что ты пишешь: будь то клиент на флеше, сервер на С или на РНР - все сводится к очень удобной вещи: ООП.
Если знаком с этим термином - здорово.
Если нет - советую почитать.

Разработка очень упрощается, когда ты описываешь все классами, и с ними работаешь. Ну и когда они в иерархию уложены.
Отвлеченный пример моего сервера:
На верхнем уровне класс самого сервера, занимается включением сокетов(обмен данных с клиентом), хранением подключенных людей.
Параллельно с ним на уровне лежит класс работы с сокетами(сервер их только включает, а дальше они сами по себе)
Чуть ниже лежат классы работы с персонажем: Персонаж, который включает в себя еще классы: Опыт, Показатели, Инвентарь, Экипировка, ПАРСЕР.
И еще ниже дергаемые по нужде классы типа Карта, Магазин, Монстр, Бой, ит.д.
Пример, как это функционирует:
Запускается сервер. Загружает в себя из БД все возможные характеристики вещей игры(оружия, брони, зелья). Инициализирует таблицу пользователей.
Потом включается класс передачи данных по сети. Он занимается тем, что ловит все входящие подключения, говорит серверу создать игрока, когда тот подключился, принимает и отдает команды от/к игрокам.
Когда приходит от игрока какая-нибудь команда(например, пройти вверх по карте), класс передачи данных поулчает эту команду и отдает её экземпляру класса игрока, который включает парсер, а тот уже расшифровывает, что за команда пришла и какие характеристики персонажа надо поменять - в данном случае координату У и возможно сообщить игроку, что мы наткнулись на монстра.

Как-то так, но очень кратко.
Суть в двух словах - используй ООП.

Тогда предположим, что есть 2 игрока, у каждого есть по яблоку.
Тогда в БД будет содержаться 2 строки:
id=>1 user_id=>0001 item_id=>"apple" item_count=>1
id=>2 user_id=>0002 item_id=>"apple" item_count=>1

А если у каждого по несколько разных фруктов:
id=>1 user_id=>0001 item_id=>"apple" item_count=>1
id=>2 user_id=>0001 item_id=>"grape" item_count=>1
id=>3 user_id=>0001 item_id=>"orange" item_count=>1
id=>4 user_id=>0002 item_id=>"strawberry" item_count=>1
id=>5 user_id=>0002 item_id=>"lime" item_count=>1
id=>6 user_id=>0002 item_id=>"cherry" item_count=>1

Вот меня пугает, как БД разрастется.
Строками бы хранилось
id=>1 user_id=>0001 BCKP=>"apple,grape,orange" Count=>"1,1,1"
id=>2 user_id=>0002 BCKP=>"strawberry,lime,cherry" Count=>"1,1,1"

Ориентировочное количество предметов в инвентаре у каждого персонажа порядка 10-30
Итого, на 1 пользователя 10-30 записей в БД.

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

А что по сути темы: я остановился на этой концепции инвентаря - написав её и парочку других сравнил производительность и объем хранимых данных. Эта самая оптимальная.