qwertyMAN

"- система жизнеобеспечения. Наличие этой системы на космическом корабле предполагает наличие экипажа и позволяет игроку управлять кораблем вручную." 

Какой экипаж? Какое ручное управление? По истории ты остался один с 10 работающими роботами и кучей сломанных, ты должен сидеть на базе, кодить роботов и посылать их на корабле собирать ресурсы. А на эти ресурсы можно починить\улучшить роботов, улучшить\построить базу, построить\улучшить корабль.

Я думал геймплей будет ориентирован на факторио или колобот. По типу, ты можешь всё делать сделать вручную, более долго и сложно. Но намного проще автоматизировать все процессы.

P.S. Пожалуй пока продумываю геймплей, можно и рисованием спрайтов заняться. Вдруг что то годное получиться. Не хочется с интернета скачивать кашу из спрайтов нарисованных в разном стиле и никак не связанных друг с другом.

Честно говоря, не нравится мне идея программирования в "команде". Есть значительные минусы при этом, хотя свои плюсы тоже есть.

Скорее всего, я просто возьму и доработаю свой текущий проект, чем буду смотреть в код и разбираться, что же без меня добавили в игру и как это работает.

Скорее всего я просто не умею работать в команде и не хочу учиться.

Ещё у каждой планеты можно ввести такие параметры как плотность (давление), температура, состав атмосферы (причём на каждой высоте он свой), состав водоёмов и так далее.

При том, что выкачивание воздуха будет вызывать понижение плотности планеты (истощение атмосферы планеты), также выкачивание жидкостей из водоёмов будет так же истощать их источник.

Например у нас есть смесь газов номер 1, мы её выпускаем на луне. У луны появляется атмосфера и её плотность повышается. Далее чем выше плотность, тем быстрее будут метеориты сгорать в атмосфере. А это значит, что шансов что наземную технику завалит метеоритами уже уменьшается. Выпустив же смесь газов номер 2 в атмосферу, эта смесь по плотности определит, будет ли создан слой атмосферы выше или ниже уже имеющегося.

В общем, предлагаю такую некую реалистичную игрушку, в которой нужно летать от планеты к планете, выкачивать жидкости, газы и собирать руды (из упавших метеоритов или в шахтах) Кроме этого селиться и обустраивать свою родную планету (ту которая вам больше нравится)

Всё это будет сопровождаться тем, что на каждую технику нужно самому писать ПО, будь то турель, шахтёрский робот, дрон для выкачки атмосферы или космический корабль.

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

Придётся автоматизировать всё. Чтобы дроны подымались на нужную высоту и высасывали нужную смесь газов. Далее чтобы отвозили его в цистерны, чтобы от туда шла переработка и готовые газы загружались в космические корабли. Которые опять же надо запрограммировать на полёт на другую планету, где они спокойно должны приземлиться и выгрузится. При том что физика реалистичная, как в моём ролике, если кто уже видел. То есть учитывается при этом и масса ракеты со всем содержимым топливом и грузом и сопротивление воздуха с учётом высоты и гравитация и ветер и всё в этом духе.

Кстати, чтобы определять воздействие ветра и прочих воздействий, придётся ввести ещё один сенсор ускорения.

В принципе я бы мог попробовать сделать такую игру (не факт, что опыта хватит), но у меня есть 2 проблемы.

1. Я не знаю как в love2d осуществляется связь с серверами, как там всё работает, синхронизируется и всё такое.

2. Я не разбирался пока с физической библиотекой движка, а именно как осуществить реалистичное поведение объектов при столкновении. (кажется там что то с ООП связано, а это опять же надо вникать в то что такое ООП, хотя мне этого не хочется)

А ведь это идея. Что если запилить игрушку с каким нибудь муторным геймплеем, но всунуть возможность каждому игроку писать клиентские моды. Хочешь играть весело - пиши мод во встроенном редакторе.

Есть клон игры инферомайнер с подобной механикой, там на луа можно моды писать.

http://www.minetest.net

И зачем изобретать велосипед?

В общем вот, если кому интересно наработки из OpenSpace:

Как бы, кислород растения вырабатывают

Ты скажи это инопланетной флоре, что метилен в ацетилен перерабатывает. Там кислородом даже и не пахло, не говоря уже о том, что инопланетяне ацетиленом дышат.

О игре

Собственно о наработках, могу выложить свою новую версию OpenSpace, где осуществлена планета, на которой есть гравитация и где сопротивление среды уменьшается с высотой. Там то физика полёта что надо (но нет физики ударов и прочего)

P.S. Неужели тут кто то кроме меня увлекается пони?

Эм... ты не один такой

Сделал прочность кирпичей. Цвет изменяется очень странно, доработаю позже. 

Сейчас массив с данными выглядит так {{x, y, w, h, color, prochka, bonus(empty)}, ...{x, y, w, h, color, prochka, bonus(empty)}, {l(platforma)}}

В принципе w и h можно не записывать в массив, так как они везде (скорее всего) будут одинаковые. Просто вывести их в отдельные переменные.

Color записывать тоже не вижу смысла. Вместо этого можно использовать переменную level, которая будет содержать уровень кирпича (от 1 и выше) и по отдельной таблице подбирать по уровню нужный цвет.

Тогда и переменная prochka не нужна будет.

В итоге получим следующую таблицу:

local w, h = 4, 1 --например так
local block = {}

for x=1, 10 do
  for y=1, 5 do
    table.insert(block, {x=x, y=y, level=math.random(1,5)}) --генерируем поле 10 на 5 с блоками случайного уровня
  end
end

color = { --создаём таблицу с цветами для каждого из пяти уровней блоков
  0xffffff,
  0xff0000,
  0x00ff00,
  0x0000ff,
  0xffff00
}

-- ...

-- где то в коде, когда назначаем цвет блока
require("component").gpu.setBackground(color[block[i].level]) --где i - индекс блока

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

Покупаешь файл в магазине и засовываешь в него нужные бумаги. Так же ты можешь вытащить бумаги из файла.

Файл предназначен для сохранения бумаг от агрессивной внешней среды. Дабы сохранить ценные бумаги в сохранности как можно дольше.

Вот и всё, что тебе нужно знать о файлах.

Пример:

Тебе сказали рассортировать папки так, чтобы в каждой папке было по 10 файлов. Вытаскиваешь все файлы из всех папок и засовываешь в каждую папку по 10 файлов. Готово!

за отсутствие пробела после запятой

За убийство комара, за то что воздухом дышал не правильно, за то что не правильно какал   

А не проще было проверить, что он там выводит вот так?

exit = false

local function e1(...)
  local tb = {...}
  for i=1, #tb do
    print(i .. "   " .. tb[i])
  end
  exit = true
end

event.listen("touch",e1)
while not exit do
  os.sleep(0)
end
event.ignore("touch",e1)

Элементарно же 

Я подумал... Можно. Использовать передний цвет и не писать символы. При этом цвет сохранится и можно будет найти кирпич. 

Если затеешь перейти на полноценный движок и нарисуешь спрайты для кирпичей, они не смогут взаимодействовать как ты задумал по цвету. Ты сейчас загоняешь себя в рамки, выбирая не традиционные способы решения проблем. Может оно и проще кажется сейчас, но в будущем будет сложнее.

Изучил бы работу с координатами - стало бы проще другие программы писать. А избегая эту тему, её не изучишь.

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

event.lister ?Для опечатки слишком много повторений.

Ты разгадал мой секрет, я не знаю английский.

Да event.lister работает аналогично. Не надо ничего придумывать и усложнять 

Стоп. А как мне получить информацию?

Я мысли читать не могу. для примера написал print, а там в аргументы что хочешь подставляй. Я то не знаю что ты хотел выводить на экран. 

руки оторвать за такой стиль, надо так:

О боже, что я вижу, за такое руки ломать надо.

Надо так:

-- Автор qwertyMAN
-- Не крадите прогу пожалуйста. Грешно.

local function e1()
  -- <код>
  -- ...
  -- </код>
end
 
event.lister("key_down", e1) -- устанавливаем обработчик
 
while 1 do
  -- <код>
  -- ...
  -- </код>
  os.sleep(0) -- 0.25 секунд слишком долго
end
 
event.ignore("key_down", e1) -- убираем обработчик

Лично отломаю.

Ну вот пример. Мне нужно выводить какое-то значение на экран, которое постоянно изменяется. И параллельно принимать сигнал от event.pull(), чтобы можно было взаимодействовать. Ибо во время вызова этой функции приостанавливается программа.

Используй event.lister() Он обрабатывает сигналы в режиме ожидания os.sleep(). Таким образом можешь что угодно выводить, но поставить хотя бы os.sleep(0) которого будет достаточно, чтобы обработать эвенты.

Например так:

function func()
<код>
end

event.lister("key_down",func) --регистрируем эвент и привязываем события "нажатие клавиши" функцию func()

while true do
print(42) --выводим на экран что хотим
os.sleep(1) --обрабатываем эвенты
end

event.ignore("key_down",func) --убираем эвент

А в чем проблема на других движках? Нельзя получить цвет пикселя? Тут же все просто, без особенностей.

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

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

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

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

Дело твоё конечно, но твой метод определения столкновения не универсален.

И разве определение цвета это не является опредением объекта?

Странное решение, определять по цвету. На других движках, возможно ты бы и не смог подобным способом решить проблему.

Можно по координатам определять, когда происходит прикосновение. 

Ага, а ещё обучить робота работе с памовскими машинками и сбору урожая с грядок

Сбор урожая пкм, очень просто. К тому же для грядок можно использовать второго робота, что складывает всё в сундуки.

А с памовскими машинами можно попробовать через воронки взаимодействовать. Если получится, то будет очень просто. Хотя я только одну памовскую машину использую - пресс, чтобы производить продукты из сои. Остальные как то и не нужны. Соль из воды получить можно, роботы тут как нельзя лучше подходят. Потому что вручную соль замучаешься добывать.

С фруктовых деревьев урожай собирать не надо будет, так как в основном топовая еда без них крафтится.

При желании можно всё осуществить и даже сделать прогу, что при каждом запросе определённому игроку выдаёт нужную еду раздатчиком. Чтобы вручную не искать, что там уже можно съесть.

Несколько роботов и это всё будет автоматизировано.

Я уже не говорю, допустим про робо-повара (собирать рецепты из памса,например) - там уууйма крафтов

Там всего то надо забить 12 видов топовой еды чтобы голода не было и всё. Все остальные рецепты не нужны будут.

create serafim

Столько раз видал как люди подписывают свои работы через by, что create меня просто убил

оптимизация вещь тонкая

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

Он дает +1 к ЧСВ. У меня, к примеру, благодаря байтикам, ЧСВ близко к переполнению.

Ага, разрешено иметь не более 3-х байтиков. (особо себя не разбалуешь  )

И то, смысла от них не вижу. Чтобы повысить ЧСВ, нужно написать полезные проги, которые все будут использовать. А так как кроме робокопалки ничего полезного не написать, грош цена всем остальным прогам. Там хоть медальки выдавай, как были проги никому ненужные, так и останутся. Факт того, что проги никому не нужны, должен снижать ЧСВ.

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

Байтик старание за труд, спосибо

А я всегда думал, что лучшая награда - опыт и полученные знания, а не картинка у профиля на форуме, которая не цениться никак. (скажу по секрету, что пользователи у которых нет этих медалек, тем не менее имеют вес на этом форуме)

Посмотри на томата например, у него не одного байта нет, но он мне помог с оптимизацией кода и часто советы давал на эту тему. Не в байтиках и медальках человек ценится.