LINUX.ORG.RU

Star E пишу.

 , , , написание игр


0

2

Снимок экрана http://1.bp.blogspot.com/-bS3NAXY0EVY/UvIEXCxfKEI/AAAAAAAAAFg/CDfTZZQml7Q/s16...

Если кому то не жалко своего времени, то прошу протестировать редактор. И ещё попробуйте создать новые конечности для редактора, а то у меня их всего 3 (голова, лапа, хвост) , а рисовать я умею плохо. Файлы образцов с комментариями лежат в editor-2d-1 .

Репозиторий исходного кода https://github.com/killofwin/star-e

Блог разработки http://star-engineers.blogspot.ru/

Добавил иное отображение чётных конечностей. Исправил некоторые ошибки. Немного обновил стандарт и файлы образцов.

Установить Gambas-runtime https://dl.dropboxusercontent.com/u/86123252/projects/StarE/star-e-meta.deb (что бы не устанавливать всю среду разработки)

Архив с запускаемым файлом https://dl.dropboxusercontent.com/u/86123252/projects/StarE.tar

Ответ на: комментарий от hobbit

А если бы у тебя был xml, то сервер точно так же передал бы в класс-обработчик ссылку на DOM-объект, соответствующий тегу <unit>, вместе со всеми дочерними объектами - не вникая в их суть, как ты и хотел. При этом разбор файла вместе с синтаксическим контролем выполняется одной строкой программы. Википедия подсказывает, что XML-парсер в Гамбасе есть (я правда, не знаю, что он поддерживает - DOM, SAX или обе модели).

Тогда бы мне пришлось бы под каждый тип объекта городить собственный класс.

Судя по первой фразе - как раз не массив, а структура (запись). Применительно к XML - набор разноимённых (что принципиально) атрибутов внутри тега <armor>. Применительно к INI - набор разноимённых переменных внутри секции. А у тебя да, получается массив никак не контролируемого формата.

Может для загрузки так и оптимально, но для выполнения каждый раз при обращении к объекту разбирать XML это как то не оптимально. А насчёт неконтролируемости формата, его контроль осуществляет обработчик нужного ID.

Количество ты так проконтролируешь, состав - нет.

Для состава керамический коэффициент.

если один параметр добавился, а другой (устаревший) выкинут? Нет, ну можно старые оставлять для совместимости? Далее, при твоём подходе новые элементы можно добавлять только в конец, даже если их группировка подсказывает обратное.

А какая разница как они сгруппированы? Если обращение к ним всё равно происходит с использованием констант из класса-обработчика.

И наверно уже повторюсь, использование GameObjectDataClass нужно только если для описания свойства не подходит строковая или численная переменная.

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

https://gist.github.com/killofwin/8878734

https://github.com/killofwin/star-e/blob/master/.src/unit-class/GroupUniversa...

Public NameValue As New String[] ' имя параметра
Public IDValue As New Integer[] ' числовое значение совпадающее с именем параметра
' каждый параметр должен должен обладать своим ID, а так же NameValue и IDValue должны быть синхронизированны
Public Values As New Variant[] ' Всё таки я решил хранить значения в типе Variant
  
 '4 + 4 + 8 = 16 байт на одно свойство
Public Count As Integer ' колличество свойств  
If TypeOf(Values[a]) = gb.Integer Then
    'значение integer
     Srm.Add("value-integer=" & Str(Values[a]))
   Endif
   If TypeOf(Values[a]) = gb.Single Then
    'значение Single
     Srm.Add("value-single=" & Str(Values[a]))
   Endif
   If TypeOf(Values[a]) = gb.Float Then
    'значение float
     Srm.Add("value-float=" & Str(Values[a]))
   Endif
   If TypeOf(Values[a]) = gb.String Then
    'значение строка
     Srm.Add("value-string=" & Values[a])
   Endif
   If TypeOf(Values[a]) = TypeGameObjectDataClass Then
    'комплексное значение GameObjectDataClass
    'здесь надо будет сохранено куча строк 
    Srm.Add("value-godc=") ' GameObjectDataClass
    godcStrings.Clear ' очистка массива
    godcLink = Null ' обнудение переменной ссылки
    godcLink = Values[a] ' присвоение ссылки, в дальнейшем использовать для операций эту ссылку
    godcStrings = godcLink.SaveClass() ' сохранение класса в массив
    ' а теперь надо перебрать массив и сохранить его строки в массиве Srm этого класса
    godcM = godcStrings.Max ' узнать индекс последнего элемента в массиве 
    For godcA = 0 To godcM
      'собственно перебор
      Srm.Add(godcStrings[godcA]) ' добавить в Srm массив значение из возвращённого массива
    Next
    
   Endif
rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

Может для загрузки так и оптимально, но для выполнения каждый раз при обращении к объекту разбирать XML это как то не оптимально.

Нет, ты не в курсе. Разбор выполняется один раз на абстрактном уровне. В классы-обработчики передаётся (для модели DOM) поддерево объектов в памяти. И даже если нужно всё это распихать по более удобным (по какой-то причине) структурам, это можно сделать один сразу после parse.

А насчёт неконтролируемости формата, его контроль осуществляет обработчик нужного ID.

Очень ограниченный контроль, как я и пытался показать выше.

И наверно уже повторюсь, использование GameObjectDataClass нужно только если для описания свойства не подходит строковая или численная переменная.

То есть для любого составного типа. А таких у тебя будет много, если доведёшь проект до рабочего состояния.

Чувствую, я тебя не убедил. Что ж, делай как знаешь, но всё же рекомендую подучить XML-технологии, DOM, XSD. Я считаю, что там всё нужное есть. Даже если сейчас ты не будешь ими пользоваться - пригодится в следующем.

И ещё: избегай в программе комментариев в стиле Капитана Очевидность: «очистка массива», «обнуление переменной ссылки» и др. В приведённом примере таких комментариев, увы, больше половины. Комментарии пишутся не для неуча, который не знает язык программирования, а для программиста, которому нужно вспомнить, ДЛЯ ЧЕГО написан тот или иной оператор. К примеру, при обнулении можно напомнить, массив ЧЕГО ты обнуляешь.

Вообще, если код написан хорошо, комментировать каждую строку не нужно. Достаточно сделать шапку для модуля, комментарий для класса, комментарий в начале каждой функции/метода и комментарии для НЕОЧЕВИДНЫХ фрагментов кода. Если функция большая (чего, как правило, следует избегать) - комментарии к разным частям алгоритма. Когда комментариев больше кода, код теряется.

В сам код, прости, я сильно не вникал: там ещё много чего, вероятно, можно было бы написать, но этим пусть занимаются гуру бейсика, коих на ЛОРе, боюсь, не очень много. И русский язык всё же подучи: формулировки типа «здесь надо будет сохранено куча строк» глаз режут.

Удачи.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

поддерево объектов в памяти. И даже если нужно всё это распихать по более удобным (по какой-то причине) структурам, это можно сделать один сразу после parse.

Такое поддерево потребует именованных наборов и использования строк в качестве идентификаторов полей. Кроме того это потребует сохранять там объекты не определённого заранее типа и как следствие выполнять позднее связывание. Или может я не понимаю что такое DOM ?

Очень ограниченный контроль, как я и пытался показать выше.

А почему он должен быть более жёстким?

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12
#!/bin/bash

wget http://www.linux.org.ru/forum/development/10141905 -O- |
awk 'BEGIN{lock=0}
/<\/code>/{ sub(/<\/code>.*/,""); lock=2}
/<code>/{ sub(/.*<code>/,""); lock=1}
lock!=0
lock==2 {exit}
' |
awk 'BEGIN{level=0; k=0}
function p(level,value) {
  a=sprintf("%%%is%%s\n",2*level)
  printf(a,"",value)
  next
}
function dumpKV(postfix) {
  sub("="," "); name=$1
  sub(name" ","")
  p(level, "<"name""postfix" value=\""$0"\"/>")
}
/^$/ {next}
'"/'= /"'{
  sub('"/'= /"',"")
  p(level,"<!--"$0"-->")
}
/^begin *game-object-data$/ {k++}
/^end *game-object-data$/   {k--}
/^begin / { p(level++,"<"$2">")  }
/^end /   { p(--level,"</"$2">") }
/^add-string=.*/ { dumpKV(" id=\""(++S[k])"\"")  }
/^add-integer=.*/{ dumpKV(" id=\""(++I[k])"\"")  }
/^add-single=.*/ { dumpKV(" id=\""(++Si[k])"\"") }
/^[a-zA-Z-]*=.*/ { dumpKV("") }
{p(level,"<error text=\""$0"\"/>")}
' >input.xml
anonymous
()
Ответ на: комментарий от rezedent12

Попробуй. Только под рутом не запускай :)

// Код не мой.

hobbit ★★★★★
()
Ответ на: комментарий от rezedent12

это потребует сохранять там объекты не определённого заранее типа

Тип можно проконтролировать, сделав XSD. Причём ввиду отработанности механизма это будет более надёжно, чем если вручную проверять каждый add-*

и как следствие выполнять позднее связывание

Так у тебя сейчас и так Variant во все поля, судя по коду.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

чем если вручную проверять каждый add-*

В смысле вручную проверять? Зачем и как это?

Так у тебя сейчас и так Variant во все поля, судя по коду.

Ну как напишу API для модов, то определю в качестве стандарта выполнять конвертацию сразу после передачи. Да, это позднее связывание, но я уже проводил тесты и выяснил что оно достаточно быстрое. И оптимизировать это не получается созданием своего механизма. Я кажется понял суть твоей идеи, сохранять объекты разных классов раз уже переменная всё равно Variant. Заманчиво конечно, но чутьё подсказывает что в этом случае есть вероятность легко всё поломать и упереться в двоичную совместимость. Да и множить классы без необходимости не охото.

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

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

Я кажется понял суть твоей идеи, сохранять объекты разных классов раз уже переменная всё равно Variant. Заманчиво конечно, но чутьё подсказывает что в этом случае есть вероятность легко всё поломать и упереться в двоичную совместимость.

Я из этого объяснения не понял, что ты понял. По крайней мере, сохранять в двоичный файл я точно не предлагаю.

И ещё раз, я говорил не столько про функции и объекты, сколько про формат файла. Объекты могут 100 раз переписаться, а вот с файлами, если ими реально пользуются, а формат оказался неудачным - намучаешься.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

Бросай уже это дело. Я за его проектом слежу (по постам на ЛОРе). Пытался образумить. Бесполезно. Походу он из тех, кого жизнь учит.

ziemin ★★
()
Ответ на: комментарий от hobbit

Ничего хорошего. Пару раз перелопатит свой код. Заодно и слово «рефакторинг» будет понимать.

upd: понимать в смысле «нутром понимать», что некоторые вещи лучше закладывать с самого начала грамотно, с оглядкой на хорошие практики.

ziemin ★★
()
Последнее исправление: ziemin (всего исправлений: 1)
Ответ на: комментарий от hobbit

сколько про формат файла

Ну формат файла он меня просто пока не волнует. Хотя рассматриваю в планах переход на XML или сделать специальный редактор для этого формата. А за советы спасибо.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

к теме для огороженных регистрантов (тот тред про экономику доставляет, ага):

смотреть мысли

много думать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.