********
Вид для печати
********
sevol, я начинал писать первую свою игру на бейсике... но поняв, что это ложный путь стал осваивать ассемблер... так до сих пор и не написал ни одной игры ни на одном языке (демоверсии не всчет:)).
проще освоить игровой редактор - например Arcade Game Designer
http://www.worldofspectrum.org/infos...cgi?id=0020176
посмотри по ссылке игры сделанные на нём - вполне достойно
goodboy, впечатляет :v2_dizzy_cowboy:
А вообще лучше их и не писать.
Потому-что - тяжёлый и неблагодарный труд.
Ну если только очень хочется - ну почитай книги издательства "Питер" (говнари
ещё те, но общее представление поимеешь).
http://vtrdos.ru/book/WGASM.ZIP
Только ради 2++ - не воспринимай их выкладки как догмы, иначе - ... (сам поймёш)
(они там на gens напирают)
Есть уже более вменяемые асмы, sjasm к примеру...
Про сижджейасм много и на форуме найдёш
P.S. А после того как переваришь всё что там - можно лезть на zxpress.ru и там журналы смотреть (есть статьи типа "Как написать игру")
P.S.S. ZX-РЕВЮ тоже свои советы давали
Статьями от гуру
Много там писано - суть одна: Мы научим вас писать игры уровня 86 года! Спешите!
//sevol
Начинать можно и на Бейсике.
Будет тормозить, но если ты осилишь проект, то его тормозящие части, либо весь его потом можно будет в Ассемблер перевести (речь ведь о ZX Spectrum игре?).
Ассемблер Z80, кстати, прост до невозможности, и по нему хватает документации в свободном доступе.
Но лучше всего начать с алгоритма и идеи игры - расписать всё на бумаге. Поверь, это сэкономит дни и даже недели
Удачи :v2_thumb:
to sevol, перво-наперво следует определиться с направлением (жанром) игры. Для написания логических, настольных, традиционных - может хватить быстродействия spectrum-basic, ну, возможно еще компилятор (tobos FP\MCoder). Кстати написание программ под компилятор весьма способствует переходу на ассемблер - в силу разложения "сложных" конструкций на более простые, понимаемые компялятором.
А вот для написания динамичных игр нужно переходить на "чистый" ассембер (или писать на нем, наиболее ресурсоемкий код, либо недоступные из бейсика операции, типа работы с BDI). Правда здесь нужно освоить мнемоники z80 и особенности архитектуры spectrum.
Выкладки на бумаге не помешают, т.к. при откладывании в долгий ящик, впоследствии трудно сразу вспомнить как работает набранная тобой программа.. ну и в процессе можно спокойно "заплутать".
В-принципе, каждый для себя решает сам, каким образом ему удобней писать игры! ;)
sevol,
Попробуй выкурить книжку, о результатах обкурки скажешь:) сам я её не выкуривал, заодно и проверю работает или нет )))
Это одна из книжек с которой я начинал знакомство с "писанием" игр.. несмотря на некоторые ошибки в листингах программ и "специфичный" принцип изложения информации.
Начинать писать спектрумовские игры можно и на бейсике, хотя его возможности ограничены, и при серьезном занятии игростроительством, со временем придется осваивать ассемблер. Любой инструмент годится, когда за дело берется талантливый человек, имеющий большое желание сотворить что-то хорошее!
На бейсике создана масса увлекательнейших игр. Это и текстовые стратегии, такие как "Диктатор", "Президент", "Хлебное королевство".
Из аркадных игр на бейсике, на Спектруме существует такая прекрасная игра, как "Ground force zero", также известная под названием "Титан". В свое время я эту игру сделал на бейсике для компьютеров "Агат" и "Специалист", не глядя в оригинал (хотя графика в моих версиях была хуже). Далее, на бейсике можно сделать прекрасный "Питон", а может быть даже тетрис и ксоникс - не пробовал. Еще я конвертировал игру на бейсике "Взбесившиеся роботы" - тоже очень увлекательная.
Также на бейсике можно сделать какую-нибудь викторину, "Поле чудес", "Миллионер", "Монополию" и так далее. Скорость компьютера вторична - в первую очередь важна идея, и чтобы игра захватывала игрока, то есть была в меру простой, в меру сложной, позволяла игроку учиться и добиваться все больших успехов, а также таила в себе загадку ("что будет дальше?").
С тем же успехом, как на бейсике, можно писать игры на любых других языках высокого уровня, однако мне неизвестны такие их реализации на Спектруме, которые обладали бы сопоставимым с бейсиком удобством редактирования программ, стойкостью к сбоям и универсальностью. Есть, впрочем, заслуживающие внимание расширения бейсика, такие как Laser Basic - по сравнению с просто бейсиком это большой шаг вперед при написании игр.
Как ни смешно, но на ассемблере писать игры не сложнее чем на бейсике. Просматривая многие из спектрумовских игр изнутри, изумляешься во первых простоте, во вторых лаконичности. Когда мне было 15 лет и я только только начинал изучать бейсик, то искренне недоумевал, как же были написаны такие игры как Batty, Krakout, Monty on the Run, Rick Dangerous и другие.
Примеры на бейсике удручали. Игры на basic были очень плохи. Я думал тогда, что язык "машины" очень сложен и не достижим, что бы делать такие же игры как я привел выше. Как оказалось это не совсем так, программирование на асме мало отличается от того же басика. Главное научится на нем программировать. Сколько я интересных приемов кодирования и программирования увидел в программах.... Бейсик лишь начало, что бы подготовить человека к программированию, но чем лучше он поймет систему программирования в общем, тем лучше в дальнейшем для него.
Иногда когда что то не получаеться игры пишуться на народном матерном языке
Это уже не игры. ААА ты понимаешь.
Лазер бейсик, как и компиляторы - палка о двух концах. Даёт удобство и скорость при работе со спрайтами и окнами, но при этом "сжирает" память своим присутствием для нормальной работы и делает невозможным использование полученных программ в 128К режиме (без перехода на "стандартный" 48К редактор).
Можно так начать - сначала освоить бейсик, написать простую игру на нём, а потом перевести её на асм.
А ещё можно бейсик-программу откомпилировать - будет работать в несколько раз быстрее.
вот неплохой пример http://www.worldofspectrum.org/infos...cgi?id=0018540
компилирован с помощью HiSoft BASIC
2 goodboy, клавиатура в эмуляторе unreal, опять же неработает, из-за состояния бита магнитофонного порта.
---------- Post added at 21:06 ---------- Previous post was at 20:26 ----------
Подобное поведение некоторых программ, замечено мною давно..
Бейсик вреден. Начинать нужно с кросс-ассемблера или кросс-компилера на пц.
На ассемблере все-таки писать сложнее по следующим причинам:
1) Ошибки в программах имеют тяжелые последствия, вплоть до сброса компьютера. Раньше, когда программы сохранялись на кассетах, это серьезно задерживало процесс, пока перемотаешь кассету и загрузишь заново ассемблер и свою программу, а потом еще надо было внести в нее все те последние изменения, которые были уничтожены в результате сброса. Сейчас все грузится быстрее, но все равно, если забыл сохранить текст программы перед запуском - придется сочинять его заново. То же касается компиляторов: ошибки в компилированных программах часто приводят к сбросу компьютера.
2) Невозможно остановить в любой момент ассемблерную программу и посмотреть ее состояние с той же легкостью, как это можно сделать с бейсик-программой.
3) Некоторые ошибки в программах на ассемблере поздно себя проявляют, делая трудным их обнаружение.
4) Отсутствие разборщика выражений, из-за этого - трудности с вычислениями. Арифметика с плавающей точкой доступна начинающим только после изучения пи-кода бейсиковского "калькулятора", что сопоставимо по сложности с изучением самого ассемблера.
5) Отсутствие процедур ввода и вывода. Использование бейсиковских процедур требует изучения и понимания куда более сложных вещей, чем то, как пользоваться операторами PRINT и INPUT.
И вообще, одна из главных сложностей с ассемблером - это то, что программирование даже таких простых вещей, как умножение и деление, требует нехилого знания теории и знакомства с трюками, с помощью которых реализуются такие вещи; либо изучения библиотек процедур. Но даже изучение библиотек само по себе сложнее, чем изучение бейсика.
---------- Post added at 21:10 ---------- Previous post was at 21:07 ----------
Чем вреден бейсик?
Я, профессиональный программист, начинал с бейсика, и не вижу в этом никакого вреда.
недавно наткнулся на ещё один - называется White Lightning.
http://www.worldofspectrum.org/infos...cgi?id=0008967
Бейсик для начинающих имхо лучший вариант чтобы почувствовать, что такое программирование вообще. А вреден недостаточными средствами структурирования программ и данных, что провоцирует спагетти-стиль программирования.
Удобно на смеси асма и ц. Жаль кроме hi-soft'овского 198.. г никто так и не прикололся на норм, редактор/компилер C под спек, а ведь была бы классная софтина. Если религия позволяет, можно заюзать pc-кросскомпилеры z88dk/sdcc.
если ты забыл "сохранить текст программы перед запуском"
то не сможешь даже загрузить снапшот в эмулятор для трассировки :D
Лолшто? С эмулятором отлаживать машинный код ПРОЩЕ бейсика!
На бейсике та же хрень, быстро ловятся только синтаксические ошибки и опечатки
Чушь - все давно придумано до нас, просто бери готовенькое
Даже лучше где-нибудь стырить процедуры, бо калькулятор глючный
Только нафиг начинающему игроделу вещественная арифметика?
Сразу прям Элиту чтоль переплюнуть?
Что такого запредельно сложного в каком-то rst10? :rolleyes:
А не нравится - опять же, возьми готовое (или даже лучше начать с написания своих)
Да машинный код даже без делений уделает тормознутый бейсик
Не говоря уж о том, что в простых игрушках оно не нада
Вот именно тем и вреден, что потом приходится отучать от "простых вещей" :p
Интересно, найдётся кто-нибудь, кто начинал программировать сразу на асме :)
Или хотя бы не на бейсике (калькулятор не в счёт).
SJASM: редактируем на PC, делаем простенькую автосборку - по запуску bat-файла всё само компилируется и запускается в эмуляторе. При сбросе ничего не теряется.
Опять-таки поможет эмулятор. В Unreal более чем достаточный debugger - нажал escape и ковыряйся в программе в своё удовольствие :)
Не соглашусь! Это касается любой сложной программы - чем сложнее структура, тем больше таких ошибок. Просто ассемблер позволяет писать более сложные программы, поэтому в них более сложные баги.
Со всем остальным соглашусь.
Советую определить цель:
1. Если цель - научиться программировать, то лучше начать с бейсика.
2. Если цель - написать игру, то лучше на бейсик время не тратить, т.к всё равно в итоге придется осваивать весь асм со всеми сложностями - так зачем делать двойную работу?
Это, естественно, имхо.
---------- Post added at 00:29 ---------- Previous post was at 00:23 ----------
Я точно помню, что начал асм изучать до того, как освоил смысл бейсиковских команд for, if и прочей базы. Максимум, что умел - цвет экрана поменять и файлы с диска подгрузить.
Учился по книге "Как написать игру" с робокопом - там хреново всё объяснялось, но мне хватило, чтобы хоть что-то зашевелилось на экране.
Не припомню, чтобы это что-то изменило - высокоуровневые управляющие структуры всё равно пришлось учить, но это уже были C, паскаль итд. На бейсике до сих пор их синтаксиса не знаю. Короче, мысль такая, что без бейсика не легче и не сложнее, если цель - освоить основы assembler'а.
---------- Post added at 00:33 ---------- Previous post was at 00:29 ----------
В общем, что я опять остро почувствовал - новичкам требуется Wiki по программированию - от статей по сборке и отладке до готовых примеров и мини-библиотек.
Мне, причем, самому - в первую очередь :D
Из частично бейсиковских можно вспомнись игрушки-стратегии от CCS: Blitzkrieg, Overlord.
Ассемблер ничем не лучше бейсика с этой точки зрения. А даже и хуже. В бейсике есть хотя бы именованные переменные, массивы, строки, циклы наконец. Они придают программе и данным хоть какую-то структуру.
Я не против ассемблера, просто возражаю против того, что на нем легче программировать, чем на бейсике.
---------- Post added at 03:14 ---------- Previous post was at 02:42 ----------
Я вообще-то имел в виду не кросс-компиляцию, а работу с ассемблером в эмулируемой системе (или на реале). Но даже если писать программу с прицелом на эмулятор: видишь, ты сам описал, сколько всего нужно. Какие-то bat-файлы создавать, стыковать ассемблер с эмулятором. С бейсиком проще. Там всё сразу есть. Не надо изучать доки к куче других программ. И программа на бейсике (если только она не делает какие-нибудь POKE или USR) не может привести к сбою компьютера.
И опять-таки: допустим, произошел сбой при пробном выполнении программы на ассемблере. Как в этом случае можно проследить его причину, если память перепахана? Бейсик же обычно останавливается с ошибкой, потому что там проверки постоянные на выход за пределы диапазона, NEXT без FOR и так далее.
Это все ничто по сравнению с преимуществами, которые предоставляют интерпретируемые языки типа бейсика. При останове программы в них можно распечатать любые данные, можно выполнять сложные команды этого языка или куски отлаживаемой программы, вычислять выражения. Изменить текст программы и продолжить ее работу. Всего этого в отладчиках компилируемых языков нет, даже отладчик Visual C++ сильно ограничен в своих возможностях к копанию в программе, что уж говорить об отладчике Unreal.
Видишь ли, я имел в виду такие ошибки, которые не сами по себе приводят к сбою, а портят где-нибудь содержимое памяти, так что программа сбивается спустя долгое время в другом месте. При программировании на бейсике вероятность подобных ошибок уменьшается, так как во-первых, имеются именованные переменные, и при присвоении переменной A нельзя испортить переменную B. Во-вторых в бейсике постоянно происходят проверки на предмет выхода за пределы диапазона и другие ошибки времени выполнения. Просто посчитай, сколько всего разных ошибок диагностируется бейсиком (сообщения 1-9, A-R). По сравнению с этим, сколько ошибок диагностируется ассемблером? Только две! Программа либо правильно работает, либо слегка глючит, либо компьютер полностью сбивается. А на бейсике больше вероятность останова программы с диагностикой на ранних стадиях ее выхода из-под контроля.
Это смотря какую игру. Начинающий программист, думаю, не потянет работу класса Sea Dragon, например. Такой программист должен понимать ограниченность своих возможностей и начать с чего-нибудь попроще, вроде тех примеров, что ранее приводились в этой ветке. Простую же игру не только можно, но и нужно писать на бейсике. Это быстрее приводит к успеху.
Маленькие успехи способствуют поддержке энтузиазма и стремлению к большим успехам. Рано или поздно человек сам осознает ограниченность бейсика и потянется к чему-нибудь более серьезному. Ведь почти все из нас этот путь прошли, так зачем от него отваживать новичков?
вообще, ассемблер - это другое мышление. многие здесь не видят ничего сложного, а обычные люди, программя на си/паскале по несколько лет, реально не могут сесть за ассемблер. вот это факт. и потому ассемблер сложнее.
а научиться можно на ... демках! и себе польза, и ААА радость! попробуешь чего-нить такого по экрану погонять, сразу поймешь кучу фишек и осознаешь что можно потянуть, а что не очень.
Новичку точно не легче. Да и вообще программирование на ассемблере более трудоёмко. Исключение - случаи, когда задача хорошо укладывается в имеющиеся ассемблерные наработки в виде готовых процедур и макросов.
Ассемблер дисциплинирует мышление в плане структурирования программ лучше, чем бейсик, потому что без процедурного структурирования даже небольшую игру на ассемблере просто не напишешь. На бейсике - вполне. Мало того, в плане визуального структурирования ассемблер лучше бейсика - отступы, пустые строки, комментарии-шапки процедур и циклов. На zx-бейсике длинные строки, без которых чаще всего не обойтись, визуально рвут текст программы, делая отступы бесполезными (к тому же пробелы и комментарии в тексте тормозят выполнение). Так что в целом бейсик всё-таки больше, чем ассемблер, поощряет неупорядоченный стиль программирования. По крайней мере zx-бейсик, очень близкий к чистому бейсику. Я сужу по себе - какие хитрозаплетённые и трудночитаемые программы я когда-то писал на бейсике, и как естественно приходилось структурировать программу на ассемблере.
Но для того, чтобы начать мыслить программистскими категориями, начать учиться программированию - имхо, бейсик вне конкуренции. Процесс более последовательный и результативный.
просто ты не писал хитрозаплетенных программ на ассемблере, вот и вся разница. если говорить о структурном программировании, то ассемблер - это зло злейшее! он разрешает делать вообще ВСЁ, что только можно, и неокрепший ум и будет делать ВСЁ. никогда у него не будет хорошо структурированной программы, ибо поймет он прелести экономии кода, прыгая в кусок другой процедуры, мухлеж со стеком, патч кодом самого себя (как минимум хранение переменной в самой команде) и т.д.
он научится писать сверхкороткий или сверхбыстрый код на данном ассемблере, но это никак не будет связано со структурированием. да, вызов подпрограмм в асме - это его плюс (в сравнении с бейсиком), но это имеет очень мало общего с структурированием...
вы не пробовали взять какой-нить код 80х-начала 90х годов на асме и заценить его сегодня? какая там проглядывает структура и прочее:) это сейчас все стали умные, образованные, а тогда даже коммерческий софт был написан вот в таком характерном хакерском стиле. и все начинающие проходят через этот стиль, всем непременно хочется схитрить, а в результате - спагетти:)
А зачем? Вот сегодня, начинающему - зачем?
Ну не создавай, не стыкуй. Ручками грузить снапшот все умеют.
Даааа, все сразу? Как насчет локальных переменных? Структур? Указателей? :v2_conf2:
Еще как может, например из-за неаккуратного обращения с каналами
Но чем, собс-но, так страшен сбой виртуального компа в эмуляторе? :D
...проследить первоначальную причину которой ничуть не проще
Самые поганые логические ошибки приходится ловить трассировкой
А на бейсике? Стопы с ремами ручонками забивать? :v2_dizzy_tired2:
При отладке в эмуляторе это попросту НЕ НУЖНО (хотя можно) - И ТАК ВСЕ ВИДНО
Так на бейсике ровно то же самое с переменными
Ты не поверишь, в ассемблерах они тоже есть :v2_dizzy_biggrin2:
А еще там есть именованные процедуры, структуры, макросы...
Ну забей в макруху явную проверку диапазона
Или точку поставь контрольную
Ну ты хватил, начинающий даже маникмайнера ниасилит, пусть питона пишет :)
Ерунда. Выкрутасы в структурирующей части просто бессмысленны, в мелких процедурках - безвредны.
Главное, что в асмах ЕСТЬ достаточные средства структурирования, а в синклер-бейсике НЕТУ
"Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации" (c) Э.Дейкстра ;)
Если уж приспичило учиться программированию с нуля непременно на Спектруме - начинайте хотя бы с бета-мега-бейсиков, а еще лучше - с Лого (тем более, что Инфорком, помнится, печатал в ZX-ревю перевод учебника), он куда удобней и дружелюбней. Да, они жрут память - но обычному-то бейсику все равно от свободной памяти проку мало, для больших проектов он практически непригоден.
ничего такого в ассемблере НЕТ :)
а я и в спектрумовском бейсике могу сделать РЕКУРСИЮ, это не значит что он поддерживает рекурсии.
приведите-ка пример без poke и usr, убивающий все безвозвратно? ;)))))
нет не то же самое. присваивая что-то переменной А, В никогда не попортишь. а в ассемблере не тока В испортишь легко, а еще и сам код! а на реалах было и диск убивался от случайного перехода не туда...
слишком сложно... мощно, но сложно;)
если писать все такими макросами, чем это будет отличаться от бейсика??? кому вообще такое надо?
Курим доки (вот хотя бы на SJasm) :v2_dizzy_facepalm:
Он локальных переменных-то не поддерживает :v2_laugh:
LET a=5:CLOSE #a :v2_tong2:
Ну давай, попорть что-нибудь, обращаясь к A или B по имени :v2_devil:
...и потом, там речь совсем не об этом (а о том, что ошибочный результат вычислений точно так же может проявиться не сразу)Код:A: dw $0
B: dw $0
Уровнем абстракции и все так же скоростью, там запас огромный
Начинающим - им пока не нужно выжимать из уродца :speccy: максимум :v2_dizzy_roll:
Или при отладке - кому угодно
Что-то уже холиваром попахивает.
Самое нужное качество программиста- умение выбирать инструмент. Ибо универсальных языков программирования, годящихся под все цели, не существует. И при решении какой-либо задачи надо оценивать что выгоднее- изучить новый язык/технологию или продираться сквозь трудности, используя знакомые инструменты.
правильно, точно так же как и в асме нет ни структур, ни чего-то еще. это НАДСТРОЙКА, как макрос. а надстройку я сделаю в бейсике и у меня будет работать рекурсия. через жопу, но будет! рекурсия! самая настоящая! от этого бейсик не станет поддерживать рекурсии:)
шайтанама!
хорошо, можно к тому условию добавить неиспользование потоков:) где оно такое реально надо? у нас это не используется, а если используется, то это уже выходит за рамки обычного бейсика.
лучше так:
A: db $0
B: db $0
байты же у нас не запрещены? и опа: ld (A),hl...
и даже с тем примером, загрузив адрес А в hl, потом случайно изменив hl, попортишь память.
это ты додумал сам, про результат вычислений:) а вот когда реально портачатся и данные и код от недосмотра - это всегда пожалуйста, не редкость вообще.
т.е. ты пишешь уже как бы не на языке нормального обычного ассемблера, а на каком-то новом, известном только тебе, диалекте птичьего языка:) так тогда не парь моск, пиши на си!
думаю начинающим важно быстрее понять и научиться добиваться результата. ты же предлагаешь вместо простого понятного почти человеческого языка (basic) выучить ассемблер, как работает проц, какие точки входа есть в пзу, выучить макроязык... не слишком ли? синдром линуксоида налицо :)))
Я имел ввиду не строгое следование канонам структурного программирования, а естественную неоходимость разбиения программы на асме на более-менее автономно написываемые и отлаживаемые блоки. Человеческий разум имеет ограничение на объём одновременно отслеживаемых объектов, именно это естественно заставляет структурировать программы на асме. Конечно, хакерские трюки ассемблер позволяет как никакой другой язык, но на одних трюках более-менее сложную программу не напишешь. Злоупотребление переходами и трюками на асме моментально выливается в очень тяжело отлаживаемые участки кода, что также приводит к осознанию необходимости писать проще.
Но в целом - и бейсик, и ассемблер имеют слабые встроенные средства структурирования, просто ассемблер быстрее заставляет задумываться о нём. На бейсике можно писать программу прямо за компом, без предварительного обдумывания. На ассемблере так можно написать максимум небольшую шаблонную процедуру.
Я примерно то же самое хотел сказать. В ассемблере постоянно возникает необходимость пользоваться косвенной адресацией, то есть указателями. А где указатели - там и их неправильные значения, выход за пределы диапазона, перепахивание памяти. Ставить везде макросы и проверки надо вручную. Для этого новичок в ассемблере должен как минимум озаботиться проблемой постоянных проверок времени выполнения. В бейсике все проверки происходят автоматически, и начинающему программисту не надо об этом беспокоиться.
Ассемблер сам по себе ничего не может, даже такой простой вещи, как вывести сообщение на экран. Все это надо делать через вызов подпрограмм из библиотек. То есть с самого начала надо понять, что такое подпрограммы и с чем их едят. При изучении же бейсика подпрограммы проходятся далеко не на начальном этапе. Первые программы новичков обычно настолько просты, что не содержат операторов GOSUB и RETURN. Встроенные средства бейсика позволяют и без подпрограмм добиться интересных результатов (текст, графика, ввод-вывод). Всего этого достаточно даже чтобы написать простую игру.
То же касается, между прочим, изучения паскаля и других языков высокого уровня при первоначальном знакомстве с программированием. Вызов процедур/функций проходится далеко не на начальном этапе.
Угу, это точно. Тут можно еще добавить изучение библиотек (арифметика, графика, ввод/вывод). То, что библиотеки существуют, еще не значит, что их не надо изучать.
---------- Post added at 16:01 ---------- Previous post was at 15:49 ----------
Это ты и я понимаем, что когда разум уже не справляется с указанным отслеживанием - то нужно структурировать программу. То есть мы знаем прием борьбы с этими сложностями. Но новичок-то еще не знает, с чем он столкнулся и как это побороть. Пока он сам дойдет до необходимости структурирования программ, пока выработает свой стиль их структурирования - много воды утечет. На бейсике к тому времени будут достигнуты какие-то результаты, подкрепляющие энтузиазм. А с ассемблером результатов будет меньше, а фрустрации - больше.
Ну, скажем, опытные зубры среди присутствующих здесь могут и довольно сложные программы на асме с ходу писать :) Но в целом тенденция верная.
Я вот еще на что хочу обратить внимание. Всякие редакторы к играм, которыми пользуются разработчики. Это программы, которые предназначены для того, чтобы единожды их использовать и забыть. Скорость в них не важна, важен только результат (уровни). Взять хотя бы Монти-редактор или редактор уровней Sea Dragon. Разработчик, опытный программист на ассемблере, предпочел написать эти редакторы на бейсике. Догадайтесь, почему :)
---------- Post added at 16:15 ---------- Previous post was at 16:01 ----------
Эта цитата относится к обучению структурному программированию, концепции которого разработал и проповедовал Дейкстра. Именно такое программирование в данном контексте называется "хорошим". Одним из условий этой "хорошести" является отказ от инструкции GOTO. С этой точки зрения ассемблер даже хуже бейсика, потому что там постоянно приходится пользоваться аналогами GOTO, да и остальные средства структурирования программ, такие как локальные переменные, циклы и четко выделенные подпрограммы, отсутствуют.
Если уж следовать заветам великого Дейкстры, то можно начать с обучения программированию на Turbo Pascal под CP/M. Но тогда не будет графики. В бейсике есть графика, и она одна из фактороы, которые очень подогревают энтузиазм начинающих. Ну и средств отладки, изучения состояния программы при останове тоже нет, ведь турбо паскаль - это компилятор.