Сергей П

Вот сомневаюсь я что это орошая идея, хотя и не специалист по V-REP. ИМХО, очевидно, что в этом продукте симуляция слишком подробна для вашей задумки. Чтобы сохранить играбельность вам придется сильно упростить модель мира. В колобот было бы очень трудно и довольно скучно играть, если бы пришлось управлять серво-моторами на низком уровне, использовать законы управления и пид-регуляторы, использовать эмуляцию правдоподобных датчиков и техническое зрение вместо простой работы с моделью мира через лаконичный API.
Если речь не об игре, которую вы "джва года ждали", то надо всё-таки как-то формализовать основной геймплей и логику игрового мира.
Как ни заманчиво выглядит создание своеобразного единого игрового мира, где люди летают на самолетах как в симуляторе, стреляют из окопов как в шутере и играют в парке в шахматы между бомбёжками, такой мир очень трудно балансировать, оптимизировать и вычищать от абсурда, который вносится вынужденными условностями. Такие полноценные симуляторы, мне кажется, появятся только когда мы научимся работать на уровне кварков, а там это уже область философии и возникают неочевидные нюансы.
Давайте пообсуждаем ваши идеина какой-нибудь открытой площадке. Я тоже когда-то мечтал в таком ключе и с тех пор набил не мало шишек, которые в порыве энтузиазма и увлеченности просто не ожидаешь.

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

Посмотрите внимательно на эти две строки:

car = input ("Техническое обслуживанаие машины 'Ламборгини': ")
rent = (input("Съем раскошной квартиры В Манхэттене: "))

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

Правильнее так:

cur.execute('INSERT INTO Cars VALUES (?, ?, ?)',  (123, 'Belaz', 321))

cur.execute('INSERT INTO Cars VALUES (?, ?, ?)',  a)

Это, в отличие от формирования запроса в виде строки, убережет вас от SQL-инъекций.

В исходном коде много странных мест. Например, странным и опасным образом опущенны запятые в описании словаря, опасное применение переменной dobav в ветке else... Это всё ведёт к небезопасному коду в плане понимания и будущих модификаций. Очевидна нехватка опыта.

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

def print_mimic(mimic_dict, word):
    bred = []
    x = 0
    dobav = word
    while x < 200:
        if x == 0 or dobav in mimic_dict:
            dobav = random.choice(mimic_dict[dobav])
        else:
            dobav = random.choice(mimic_dict[" "])
        bred.append(dobav)
        x += 1
    print (bred)
    return bred

Я понятия не имею что это за код и для чего он. Предыдущий рефакторинг я сделал оставив код эквивалентным исходному (за исключением исправления очевидных ошибок). Можно предположить, что в коде есть ещё ряд логических ошибок. Возможно поведение по ветке "x == 0" не должно отличаться от поведения по ветке else условия "dobav in mimic_dict", а вместо константы " " следовало тоже поставить word. Тогда код становится гораздо более простым, понятным и элегантным.

def print_mimic(mimic_dict, word):
    bred = []
    dobav = word
    for x in range(200):
        dobav = random.choice(mimic_dict.get(dobav, mimic_dict[" "])) 
        bred.append(dobav)

    print (bred)
    return bred

IF'ы только всё запутают. Для вашей задачи есть специальная функция coalesce:

select coalesce(m2, m1)
from my_table
where m1 is not null

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

Теперь по существу. Чтобы сделать оценку стоимости проекта, вам нужно поговорить в диалоговом режиме с несколькими независимыми (друг от друга) разработчиками, имеющими опыт участия в подобных проектах. Эти разработчики, если будут заинтересованы в получении заказа, не спросят у вас ТЗ, а зададут множество вопросов, с каждым из которых они смогут всё более точно сузить вероятные ценовые рамки реализации проекта.
Лично я бы в первую очередь спросил:
- Кто получит авторские права на разработанный продукт?
// Если вас устраивает получение рабочего экземпляра продукта с поддержкой, а получать авторские права на него и тиражировать вы не собираетесь признав его собственностью разработчиков, то такая программа обойдётся вам гораздо дешевле. Всё будет упираться в степень специфичности продукта, но в целом от вас, возможно, потребуется лишь инвестировать какую-то сумму в разработку. В данном случае руководитель команды разработчиков задаст вам ещё кучу вопросов, оценит количество человеко-часов работы специалистов, которых нужно задействовать, и выдаст некую сумму, вклад в которую вы будете обсуждать с ним поторговавшись=).
- Какая функциональность требуется от клиентского приложения? (GPS, навигация, сканирование штрих-кодов, NFC,
- и т.д.
Короче поговорить надо с несколькими подрядчиками и всё прояснится.

Всё зависит от того, насколько сложная графика планируется в перспективе. Кроме этого игра-игре рознь. Если это какая-то простенькая убивалка времени, призванная занять пару минут, то длительный запуск с инициализацией Unity в пол минуты будет напрягать. Думаю скриншот сайта помог бы сообществу более обстоятельно и аргументированно ответить на ваш вопрос=).

На сколько я понял из обсуждения на хабре habrahabr.ru/company/raspisanie/blog/209986 речь идёт о БГТУ (Белгород). В нашем вузе сейчас разрабатывается подобная система. Если есть какие-то конкретные соображения по поводу модификации существующей системы, прошу связаться с лабораторией проблем качества образования =) внутренний номер телефона 1661 (Сергей).

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

Вообще-то описанную проблему можно проиллюстрировать проще:

>>> 0.5+2.7, 0.4+2.8
(3.2, 3.1999999999999997)

Это нормальная ситуация для чисел с плавающей точкой. Она связана с тем, что для любой системы счисления (двоичной, десятичной, троичной) есть числа, которые нельзя записать в виде конечной последовательности n-ричных разрядов. Например, в десятичной системе число 1/3 будет выглядеть как бесконечная последовательность троек после запятой. Если мы остановимся, то получим не 1/3 а что-то поменьше. Зато в троичной системе это число замечательно представляется как 0.1. Одна девятая в троичной системе равна 0.01.
Та же проблема, например, у десятичного числа 0.2 при переводе в двоичную систему:
2/10==1/5==1/8+1/16+1/128+1/256+1/2048+1/4096+(...)==0,00110011(0011)[в двоичной системе]
Как видим это периодическое число и двоичные разряды "0011" повторяются в нём после запятой бесконечно.
Компьютерное представление чисел с плавающей точкой подразумевает их хранение в конечном количестве двоичных разрядов. Это значит, что многие вполне нормально записываемые в десятичной форме дробные числа просто не могут абсолютно точно храниться в компьютере (если речь идёт о floatpoint).

Имеенно поэтому программистов учат на первом курсе института никогда не сравнивать числа с плавающей точкой на строгие равенство и неравенство. С учетом погрешности из-за округления двоичных разрядов это просто бессмысленно и некорректно.
Зато, вместо сравнения на равенство, можно сравнивать abs(a-b)<eps, где a и b -- числа в формате с плавающей точкой, а eps -- это некоторая пренебрежительно малая величина. Вообще-то, думаю, можно вычислить даже минимальное значение этой величины, чтобы она покрыла все неприятности с округлением двоичных разрядов.

Я бы посоветовл python. Порог вхождения не высок, а развить вашу идею можно до даже до локального веб приложения на джанго