Menu
▾
▴
openpref-devel — Development of OpenPref
You can subscribe to this list here.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(27) |
Sep
(73) |
Oct
(2) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Konstantin T. <an...@ya...> - 2010-09-22 07:50:10
|
> Если код уже написан, отличные диаграммы взаимодействия рисуются Doxygen'ом > безо всякого UML Поясню: достаточно написать заголовки с документацией, работающий код не обязателен -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-22 07:47:02
|
22.09.2010, 11:37, "dodikk.reg" <dod...@gm...>: >> Это же не код. Выложу на сайте в "Разработке" > > А в чём проблема завести отдельную директорию типа "doc/API_drafts"? > На мой взгляд, документация должна храниться вместе с самим проектом. > Пусть народ будет исправлять и присылать наравне с кодом. При желании > можно будет и changelog просматривать в последствии. ок, сделаю > > То, что они бинарные, можно, в принципе, решить с помощью сего > замечательного языка для описания UML (будет сильно нужно - переведу). Диа вроде умеет экспортировать в UML Лично я с UML раньше не работал (хотя в общих чертах представляю себе) Если код уже написан, отличные диаграммы взаимодействия рисуются Doxygen'ом безо всякого UML -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-22 07:38:59
|
> Это же не код. Выложу на сайте в "Разработке" А в чём проблема завести отдельную директорию типа "doc/API_drafts"? На мой взгляд, документация должна храниться вместе с самим проектом. Пусть народ будет исправлять и присылать наравне с кодом. При желании можно будет и changelog просматривать в последствии. То, что они бинарные, можно, в принципе, решить с помощью сего замечательного языка для описания UML (будет сильно нужно - переведу). http://yuml.me/diagram/scruffy/class/samples |
|
From: dodikk.reg <dod...@gm...> - 2010-09-22 07:16:49
|
> Насколько я понимаю, ты предлагаешь лишить игровые стратегии доступа к
> информации о типе игры? Не уверен, что это было бы правильно (хотя конечно
> знание о том, сколько взяток не добираешь, вряд ли поможет взять больше
Да. И "подсовывать" классу, следящему за ходом игры и соблюдением правил
(назовём его GameController) нужную стратегию в зависимости от
заказанной игры. От стратегии же не будет требоваться ничего кроме как
выдавать следующий заказ на торге или карту в игре.
Если ухитримся подсунуть на мизере стратегию для виста или обычной игры
(набора взяток), то соответственно и получим полное фиаско.
> Я все-таки не согласен с таким детальным разделением типов игровых стратегий
> Например, для альфабеты сейчас нет разницы между игрой и вистом, между
> распасами и мизером (в первом случае число возможных взяток максимизируется,
> во втором - минимизируется)
Используй те же 2 стратегии как раньше. Только теперь не будет
конструкций типа
>> if (gameType == GAME_MISERE)
>> {
>> .......
Помнится, при беглом осмотре видел такое. Файл сейчас точно не скажу ибо
немного недосуг.
Короче, тип игры определяется сразу как игра заказана. В соответствии с
этим типом фабрика (или "игрок" как ты это называешь) отдаёт в
GameController нужную стратегию.
И дальше GameController уже крутит ходы и опрашивает нужную стратегию. А
как взять больше будет решать уже сама стратегия исходя из поданной ей
на вход ситуации. Из тех же данных что получаем мы с тобой когда играем
в эту прекрасную игру.
Схему с GameController я потом отдельно нарисую.
Посмотри еще классы "xxxEnvironment". Не забыл ли я туда включить
чего-нибудь важного.
|
|
From: Konstantin T. <an...@ya...> - 2010-09-22 06:57:17
|
21.09.2010, 23:01, "dodikk.reg" <dod...@gm...>: > Нарисовал то, что мы обсуждали с Константином в jabber. > Смотрим, обсуждаем далее. Я все-таки не согласен с таким детальным разделением типов игровых стратегий Например, для альфабеты сейчас нет разницы между игрой и вистом, между распасами и мизером (в первом случае число возможных взяток максимизируется, во втором - минимизируется) Насколько я понимаю, ты предлагаешь лишить игровые стратегии доступа к информации о типе игры? Не уверен, что это было бы правильно (хотя конечно знание о том, сколько взяток не добираешь, вряд ли поможет взять больше :) > > P.S. Я пока не разобрался со своим GIT. Константин, положи сие > куда-нибудь в свой репозиторий. Это же не код. Выложу на сайте в "Разработке" -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-21 19:01:34
|
Нарисовал то, что мы обсуждали с Константином в jabber. Смотрим, обсуждаем далее. P.S. Я пока не разобрался со своим GIT. Константин, положи сие куда-нибудь в свой репозиторий. |
|
From: Konstantin T. <an...@ya...> - 2010-09-20 16:08:57
|
1. Добавлена возможность возврата ошибочно снесенных карт 2. Диалог торгов был переведен на использование лэйаутов - вы больше не увидите текста, не умещающегося на кнопке "Полвиста" :) В мобильном режиме (нужно задефайнить MOBILE) включена автоматическая максимизация диалога В будущем диалог торгов скорее всего будет разделен на два - один для собственно торгов и назначения игры, другой для выбора вист/полвиста/пас. Тестируем, делимся предложениями :) -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 20:34:18
|
Обсудили с Константином архитектуру сего дела.
Высылаю результаты нашей беседы.
=================================================================
(23:04:38) Konstantin Tokarev: привет!
(23:04:43) dodikk.reg: привет
(23:04:50) dodikk.reg: пишу письмо тебе :)
(23:04:55) Konstantin Tokarev: ок
(23:05:07) dodikk.reg: щас сюда кину
(23:05:16) dodikk.reg: Я предлагаю чтобы модель взаимодействовала со
стратегиями. Точнее, стратегия получает текущее состояние (возможно, лог
предыдущих состояний игры) и на их основании выдаёт решение.
(23:06:20) dodikk.reg: а клиентскому коду, на мой взгляд, будет глубоко
всё равно, укого требовать следующей карты или заказа игры
(23:06:27) Konstantin Tokarev: сейчас Player может получить любую нужную
информацию из модели
(23:06:31) dodikk.reg: у стратегии или у класса "Player"
(23:06:36) Konstantin Tokarev: в принципе да
(23:06:48) Konstantin Tokarev: но ботов будет труднее писать
(23:07:11) dodikk.reg: не совсем понимаю почему.
(23:08:02) dodikk.reg: наоборот, у тебя будет вместо одного бота целая
команда.
один торгуется, другой играет игру, третий играет мизер, четвёртый -
вист, пятый - распасы
(23:08:03) dodikk.reg: итд
(23:08:23) Konstantin Tokarev: а как они буду связаны между собой?
(23:08:39) dodikk.reg: смотри. игра разделена на фазы.
так?
(23:08:48) Konstantin Tokarev: ага
(23:08:58) dodikk.reg: фазы в принципе независимы
(23:09:26) dodikk.reg: то есть к примеру, бот, выдающий следующую карту
не должен ничего знать о том боте, который заказывал игру.
(23:10:01) dodikk.reg: зачем им взаимодействовать?
(23:10:12) Konstantin Tokarev: но выбирать то хочется конкретного противника
(23:10:34) Konstantin Tokarev: а зачем знать - легко объяснить
(23:10:45) Konstantin Tokarev: это они в существующих ботах не связаны
(23:10:57) Konstantin Tokarev: когда играет человек, связано все
(23:10:59) dodikk.reg: ну так сделаем фабрику, которая будет создавать
нам такие команды ботов.
1 фабрика - 1 конкретный противник
(23:12:00) dodikk.reg: вообще-то чем меньше параметров у моделируемого
процесса, тем систему легче обучить
(23:12:06) Konstantin Tokarev: мб. все ранво не понимаю, чем Player мешает
(23:12:40) dodikk.reg: да особо ничем. просто лишние перенаправления
вызовов писать прийдётся
(23:13:38) dodikk.reg: CardPtr Player::GetNextCard()
{
activeCardStrategy_->GetNextCard();
}
(23:13:43) dodikk.reg: наподобие этого
(23:13:48) Konstantin Tokarev: замечательно же)
(23:14:23) Konstantin Tokarev: и все это живет внутри плагина или
скриптового модуля
(23:15:48) dodikk.reg: почему бы этому всему не жить внутри каждой
стратегии?
(23:16:42) Konstantin Tokarev: ну мб
(23:16:59) dodikk.reg: ладно. а вдруг новичёк вроде меня вздумает
вызвать GetNextCard() во время заказа игры?
(23:17:25) dodikk.reg: в случае стратегий этого нельзя сделать будет в
принципе.
в случае Player - запросто
(23:17:41) dodikk.reg: короче, я о том что инкапсуляция рулит :)
(23:18:19) Konstantin Tokarev: согласен
(23:18:23) dodikk.reg: тем более, ботов можно будет писать по частям
(23:19:04) dodikk.reg: берёшь готового бота.
пишешь свой гениальнейший модуль, допустим, торговли за прикуп.
а остальные пока не придумал, пользуешь чужие
(23:19:14) Konstantin Tokarev: ок, убедил. думай над API, в 0.2 включим
(23:21:06) dodikk.reg: по сути, то, что ты называешь Player, я называю
Factory
(23:21:46) dodikk.reg: но Factory будет без методов вроде GetNextCard().
(23:21:53) Konstantin Tokarev: а где будут данные игрока храниться? в
модели?
(23:22:00) dodikk.reg: Он просто будет выдавать нужную стратегию по
требованию
(23:22:31) dodikk.reg: что есть данные игрока, по-твоему?
Кроме набора сданых карт?
(23:24:51) Konstantin Tokarev: имя, тип, очки
(23:25:18) dodikk.reg: должно быть состояние игры - карты на столе,
карты в отбое, текущие очки в пуле итд.
(23:25:31) dodikk.reg: то, что знают остальные игроки, должно храниться
в этом состоянии
(23:25:41) dodikk.reg: в том числе имя и очки.
(23:26:20) Konstantin Tokarev: для очков я думал сделать общий
ScoreBoard. Сейчас ScoreBoard у каждого игрока свой)
(23:27:10) dodikk.reg: по хорошему, согласен, он должен быть общий.
(23:28:30) dodikk.reg: по идее, любая стратегия описывается так
typedef <class Decision>
class IStrategy
{
public:
virtual Decision Decide(const GameState& gState) const;
};
(23:28:37) Konstantin Tokarev: тогда надо сначала модель отрефакторить,
затем игроков
(23:29:36) dodikk.reg: ага.
только у меня ещё не дошли руки по-серьёзному в исходниках разобраться.
проектик небольшой, но разбираться всё равно нужно.
(23:29:41) dodikk.reg: короче, дело поправимое
(23:29:57) dodikk.reg: скоро дожди, слякоть, а там и зима.
(23:30:29) dodikk.reg: ** должно будет когда-нибудь найтись это самое время
(23:30:34) dodikk.reg: однако я отвлёкся.
(23:31:12) dodikk.reg: Ладно. давай на сегодня завершать.
На досуге ещё диаграмки порисую :)
(23:31:33) dodikk.reg: Разговор этот сейчас перешлю на общую рассылку, с
твоего позволения
=================================================================
------------------------------------------------------------
Best regards,
Alexander Dodatko.
|
|
From: Konstantin T. <an...@ya...> - 2010-09-17 18:26:01
|
> В этом-то и идея. Что игрок будет содержать просто набор стратегий и в > нужный момент подсовывать GameEngine нужную. > Я бы лучше рассмотрел архитектуру, основанную на API стратегий, а не API > игрока. > > Ведь, по сути, в каждой из фаз игры нужны не все методы, перечисленные > тобой, а только один. > Под фазами игры я понимаю : > * торговля за прикуп (сюда же наверно заказ игры, сброс карт) > * торговля за вист (не помню как правильно завётся. надеюсь поймёшь) > * собственно, игра (какую карту бросить следующей) Но логика этих действий в общем случае связана между собой, поэтому обрамляющий класс Player, с котороым взаимодействует модель, все равно нужен -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 17:52:10
|
> Насчет остального мне трудно что-либо сказать, так как качество схем > неважное и не хватает > пояснений что есть что. Думаю, drawanywhere легко решит эту проблему Можете писать\звонить в jabber : dod...@gm... |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 17:49:38
|
> ..присылайте свои логины > > -- > Regards, > Konstantin Sourceforge Login : dodikk ------------------------- Best regards, Alexander Dodatko. |
|
From: dodikk.reg <dod...@gm...> - 2010-09-17 17:46:45
|
Hello, Konstantin.
Перерисовал схемы в dia (экспортнул в png). Присылаю их с сим
письмом. Перерисовывать ещё в чём-либо желания нет. Однако на будущее
буду иметь в виду предложенный тобой сервис.
> Однако, модель на мой взгляд не
> должна знать внутреннего устройства игрока, так как все, то от него
> требуется - это
> сообщать решения по поводу хода или заказанной игры
А я не вижу нарушения данного требования в своих диаграммах. Параметры,
передающиеся интерфейсу в реальной игре и так известны всем игрокам.
Это :
* текущее состояние пули (и история изменений)
* история торга игры.
* торг "пас/вист/полвиста".
* карты, лежащие на столе.
* карты из отбоя.
> makeMove, makeBid, makeFinalBid, drop... (эти два должны быть
> объединены),
> chooseClosedWhist, которые внутри конкретного бота могут
> реализовываться, например,
> как обращение к экзепляру какой-то стратегии.
В этом-то и идея. Что игрок будет содержать просто набор стратегий и в
нужный момент подсовывать GameEngine нужную.
Я бы лучше рассмотрел архитектуру, основанную на API стратегий, а не API
игрока.
Ведь, по сути, в каждой из фаз игры нужны не все методы, перечисленные
тобой, а только один.
Под фазами игры я понимаю :
* торговля за прикуп (сюда же наверно заказ игры, сброс карт)
* торговля за вист (не помню как правильно завётся. надеюсь поймёшь)
* собственно, игра (какую карту бросить следующей)
-------------------------------------
Best regards,
Dodatko Alexander.
|
|
From: Konstantin T. <an...@ya...> - 2010-09-17 17:34:00
|
..присылайте свои логины -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-17 16:48:24
|
> Я это вижу себе примерно так (см. диаграммы в приложении к сему > письму - потом перерисую в любимом векторном редакторе). Изучаю диаграммы. Фотографии да еще и с рукописного текста воспринимаются ужасно :) Рекомендую вот этот сервис: http://www.drawanywhere.com/ Я там даже начинал строить диаграмму игрового процесса http://www.drawanywhere.com/live/2dd649721cbe3.aspx По поводу разделения логики на стратегии: возможно, этот подход будет эффективен, если мы захотим строить "комбинированных" ботов. Однако, модель на мой взгляд не должна знать внутреннего устройства игрока, так как все, то от него требуется - это сообщать решения по поводу хода или заказанной игры, для чего вполне достаочен набор методов makeMove, makeBid, makeFinalBid, drop... (эти два должны быть объединены), chooseClosedWhist, которые внутри конкретного бота могут реализовываться, например, как обращение к экзепляру какой-то стратегии. Насчет остального мне трудно что-либо сказать, так как качество схем неважное и не хватает пояснений что есть что. Думаю, drawanywhere легко решит эту проблему -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-17 12:15:54
|
<BLOCKQUOTE style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" ><BLOCKQUOTE type="cite" ><PRE wrap="" ><br />Card<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN>CardList<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >::</SPAN>exists<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >int</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aFace<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >,</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >int</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aSuit<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >)</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >const</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >{</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>Card<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN>c<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >=</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>newCard<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN>aFace<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >,</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>aSuit<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >);</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>Card<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >*</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>ret<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >=</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>exists<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >(</SPAN>c<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >);</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >//</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >delete</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >c;</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >//</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >TODO</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >:</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >memory</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(0, 128, 0);" mce_style="color: #008000;" >leak.</SPAN>
<SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN><SPAN style="color: rgb(128, 128, 0);" mce_style="color: #808000;" >return</SPAN><SPAN style="color: rgb(192, 192, 192);" mce_style="color: #c0c0c0;" > </SPAN>ret<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >;</SPAN>
<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" >}</SPAN></PRE>
</BLOCKQUOTE>
<PRE wrap="" >Напоминает memory leak. Поглядел потом внутрь exists и понял что ошибся. Однако не стоит ли перейти на QSharedPointer<SPAN style="color: rgb(0, 0, 0);" mce_style="color: #000000;" > или хранить структуры просто как ValueType (без указателя)? Или снова боязнь замедления всего сущего?
</SPAN>=======================================================
</PRE></BLOCKQUOTE><br /><br />Все карты создаются один раз и используются до завершения работы программы (если где-то это не так - значит утечка). Перед каждой сдачей колода на самом деле тасуется (а не заново создает случайные карты). Поэтому сомневаюсь, что здесь нужен shared pointer<br /><br />Еще одно обстоятельство: если где-то в программе объявлена "стремная" функция, это еще не означает, что она где-то используется (или ее нельзя заменить на вызов другой функции)<br /><br /><br /><BLOCKQUOTE mce_style="border-left:1px solid #CCCCCC;margin:0pt 0pt 0pt 0.8ex;padding-left:1em;" style="" id="" ><PRE wrap="" style="" ><br />
Кроме того, вместо CardUtils, по-моему, имеет смысл сразу при сдаче делить карты на 4 масти и работать уже с этими мастями. А не делать по линейному массиву карт постоянные выборки типа minInSuit(1..4).
Вот это как раз и будет замедлять программу, а не ООП.
=======================================================
</PRE></BLOCKQUOTE><br />Можно изменить устройство CardList - сделать четыре независимых списка, а когда требуется получить QList со всеми картами, объединять эти списки<br /><br /><br />Если у кого-то есть желание порефакторить Card, CardList, ScoreBoard с сохранением их публичного API - вперед! Я сейчас с ними не работаю и они мало изменились с 0.1.3, так что у нас вряд ли возникнут конфликтующие правки.<br /><br />-- <br />Regards,<br />Konstantin<br /> |
|
From: Konstantin T. <an...@ya...> - 2010-09-16 20:26:11
|
> смена тайтла окна для доп. информативности в стиле "Player XXX plays 6♦" Я реализовал смену заголовка (немного по-другому, но суть та же самая). Результат можно посмотреть в гите -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 20:07:28
|
>Где смотреть? На Гитоуриусе, на странице с коммитом -- Regards, Konstantin |
|
From: Antony D. <to...@da...> - 2010-09-15 19:09:05
|
On 09/15/2010 07:59 PM, Konstantin Tokarev wrote: > Патч со Сталинградом принят, с заголовком - нет (см. комментарий) Где смотреть? -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 16:00:06
|
Патч со Сталинградом принят, с заголовком - нет (см. комментарий), требуется доработка -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 09:59:01
|
Насколько мне показалось, KScore2 - штука достаточно мощная (хотя с либами из КДЕ я пока ничего не разрабатывал) http://majewsky.wordpress.com/2010/08/09/kscore2-yet-another-new-framework/ -- Regards, Konstantin |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 09:55:58
|
15.09.10, 13:48, "dodikk.reg" <dod...@gm...>: > Для этого можно libkdegames прикрутить (в качестве опциональной зависимости)А как же портабельность? Особенно меня как пользователя offtopic радует такая зависимость. KDE же собирают для Windows, можно оттуда ddl'ку стрельнуть. На мобилки не покатит, но там оно и не надо -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 09:49:33
|
> Для этого можно libkdegames прикрутить (в качестве опциональной зависимости) А как же портабельность? Особенно меня как пользователя offtopic радует такая зависимость. |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 09:40:13
|
15.09.10, 13:35, "dodikk.reg" <dod...@gm...>: > Ну, ещё можно будет считать всякие там рейтинги игроков. Количество побед, сыгранных игр, мизеров итд.Минорная, но весьма приятная feature. Для этого можно libkdegames прикрутить (в качестве опциональной зависимости) -- Regards, Konstantin |
|
From: dodikk.reg <dod...@gm...> - 2010-09-15 09:37:20
|
Ну, ещё можно будет считать всякие там рейтинги игроков. Количество побед, сыгранных игр, мизеров итд. Минорная, но весьма приятная feature. |
|
From: Konstantin T. <an...@ya...> - 2010-09-15 09:26:51
|
15.09.10, 13:21, "dodikk.reg" <dod...@gm...>: > Тогда сказать делегату (или вьюшке) что рендерить карты этих игроков вообще не надоЭто даже мне понятно :). Как реализовать, в смысле.Просто идея как дополнение к твоему ASCII art.Ещё одна идея для feature. Складывать игры в БД (sqlite или firebird embedded какой-нибудь). А потом давать user-у просматривать replay. (по крайней мере, мне было бы интересно). Я тоже об этом думал, правда скорее для удобства отладки. Пока реализовано только запоминание раскладов в каждой сдаче и количество взяток, взятых игроками. -- Regards, Konstantin |
