101 Basic Computer Games

Недавно я натолкнулся в сети на книгу, о которой никогда не слышал.
Книга называется "101 Basic Computer Games". Она была выпущена DEC в 1975 году
и содержит тексты игр с аннотациями. Игры написаны на BASIC, на компьютере PDP-11.

Очень интересная коллекция для начинающих программистов, и не только.

Коллекция игр с описаниями и переводом на другие языки программирования находится по адресу:

https://github.com/coding-horr... uter-games

4

Сообщение от qbfan Она была выпущена DEC в 1975 году

На два года раньше — https://en.wikipedia.org/wiki/BASIC_Computer_Games

В прошлом году опубликовал биографическую статью об авторе — https://ru.wikipedia.org/wiki/... 0%B8%D0%B4

1

Для начинающих это точно не стал бы советовать.
Честно, никогда не понимал зачем что-то старое переводить с "того" бейсика на современные ЯП.
Там же самое зарождение ЯП, с соотв. стилем кода, близкому к 2GL, что изменилось лишь
к началу 90-х. Одно дело портировать что-то с относительно нестарого QuickBasic, под который
были и Vesa библиотеки и Sound Blaster библиотеки. И совсем другое ковырять безбожно
устаревшее по всем меркам и аппаратным и программным.
Максимум кому это было бы интересно - историкам IT, да и то не уверен.

0

Вот программа Train - мне понравилась как хороший пример школьной программы.
А не то, что сейчас на ЕГЭ - "Возведите Питоном какое-то число в 2024 степень,
и найдите, сколько раз в цифрах результата встречается цифра 6" - такие задания точно хорошему не учат.

0

Сообщение от qbfan А не то, что сейчас на ЕГЭ - "Возведите Питоном какое-то число в 2024 степень, и найдите, сколько раз в цифрах результата встречается цифра 6" - такие задания точно хорошему не учат.

Ни то ни другое ничему хорошему не учит.
В первом случае мы получаем условного "кодерхулигана", во-втором(ЕГЭ) вообще никого, т.е.
человека которому это всё не интересно.

Добавлено через 22 минуты
Твои же примеры qbfan, хотя бы имеют практическую составляющую,
тут: Преобразование нот в WAV файл.
или тут: https://www.cyberforum.ru/post17222009.html

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

0

qbfan, почему-то вы дали ссылку не на книгу с текстом игр на basic, а на какую-то коллекцию игр созданых на совершенно других языках. Но всё-таки спасибо за тему. Вот прямая ссылка на книгу с играми:
https://annarchive.com/files/B... df#page=17

Сообщение от Quiet Snow Для начинающих это точно не стал бы советовать.

Именно для начинающих - самое оно! Посмотрел на код: просто душа радуется как раньше было просто и понятно. Никакой структурщины, никакого ооп, короче никаких парадигм, и вот он настоящий код, каким он должен быть. Конечно язык примитивен, но всё же именно для начинающих такой примитив и необходим для развития навыков алгоритмизации.

1

Сообщение от CoderHuligan почему-то вы дали ссылку не на книгу

Потому что в PDF совершенно нечитаемые исходники в стиле матричных принтеров 70 годов,
а в коллекции игр - те же исходники, но уже набранные, и даже с некоторыми исправленными ошибками.
(Насколько я понял, авторы zip коллекции ориентировались на GW-Basic)
Я не хотел никого заставлять набирать столь древние программы вручную.

3

Сообщение от qbfan в коллекции игр - те же исходники, но уже набранные, и даже с некоторыми исправленными ошибками

Понятно. На мой взгляд там довольно странный подбор языков. Например, отсутствует тот же qbasic или C. В основном скриптовые ЯП. Причем, что довольно заметно: код на gwbasic менее объемен. Или мне так показалось.. После кода в книге, без отступов, смотришь на современный код и начинаешь осознавать странность современного подхода..

Добавлено через 2 минуты

Сообщение от qbfan Потому что в PDF совершенно нечитаемые исходники

Вот уже набранный код: http://www.vintage-basic.net/games.html

0

0

0

0

Опять 25, краем глаза смотрел эти исходники, простите, но это лютое и унылейшее говно, написанное
в стиле "бабушки-училки начальных классов", не умеющей абсолютно ничего. Я не понимаю почему,
коллеги, вы в упор этого не видите. Какие в жопу алгоритмы, где вы их там нашли?

Этим не то что никого завлечь не получится, максимум напугать, да так, чтобы человек от страху
обосрался и никогда в жизни больше не захотел приближаться ни к программированию, ни к бейсику.
И о языке у того, кто начнёт с этих исходников 70-х годов, зародится самое удручающее впечатление.
Тем более сейчас, когда он уже практически мёртв в силу стагнации комьюнити и отхода от дел
проф кодеров которые в 90-х\00-х ещё что-то писали. И даже если человек сильно пытлив и у
него что-то пойдёт по этой "литературе", то он переймёт худшие принципы программирования от
которых будет трудно избавиться(как у хулигана, который отписался тут). Это как раз и будет ловушка,
из-за которой огульно хаял язык придурковатый Дейкстра, потому что ему на глаза попадались
исключительно подобные "кадры".

Эта литература вредна для BASIC комьюнити. С одной стороны она призвана пересадить человека на
другой ЯП, с другой навязать уродливую идеологию с помощью которой люди не смогут писать
современное ПО. Это примерно как нам в стране навязывают что надо учить английский и сваливать
подальше(в переводе на "прогерский" - переходить на другие ЯП), причём даже сейчас.
По аналогии с гос-вом, BASIC находится в сходном "трудном положении".

А если по тезисам темы, то объясню в чём смысл:
1) Текстовый режим окончательно устарел ровно в то время, когда BIOS-ы массово были переведены
на графический интерфейс. Это было его последним актуальным назначением. Но исходники темы
и не учат пользоваться текстовым режимом(оформление UI, работа со страницами видео памяти,
программирование знакогенератора, стандарт ASCII, работа через память). Часть этих навыков
может потребоваться при программировании консольных утилит или для создания собственных
графических консолей.
2) Отступы нужны для увеличения скорости считывания кода глазами. И работают сугубо в тандеме
с другими принципами увеличения читаемости кода. Код без отступов читать можно, если соблюдены
другие принципы(комментарии, пропуски строк, грамотное именование переменных и т.п.).
Однако код с отступами "всегда" схватится и осознается мозгом быстрее. Во-времена 70-х годов делать
кучу пробелов для отступов - было непростительно из-за отсутствия памяти, именно поэтому любые
"декоративные" элементы опускались, но эта проблема давно позади. И сейчас код без отступов
выдаёт обычно слащавого юнца, первый раз взявшего в руки компилятор.
3) По поводу макаронинга диалоги уже были. GOTO не для кодинга им, а для редких моментов, когда
без него будет херово всему проекту, например чтобы избежать массированной реструктуризации кода
или для избавления от кусков кода, которые в структурном виде заняли бы 2-3 стандартных экрана в ширину.
Ещё имеет место редкое применение для оптимизации(описания всех состояний кода и множественного
разветвления конкретного блока на состояния), на ВУ применяется крайне редко, в основном на ассемблере.
А GOSUB безвозвратно устарел как только появились нормальные процедуры.
4) По поводу каких-то интересных якобы задач, а почему просто не посоветовать людям подтянуть матан
и не поиграть в шахматы? Эти вещи дадут очевидный результат в плане развития логико-математического
мышления. При чём тут вообще ЯП?

0

Сообщение от Quiet Snow Этим не то что никого завлечь не получится, максимум напугать,

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

Сообщение от Quiet Snow Отступы нужны для увеличения скорости считывания кода глазами.

При структурном подходе - да. Но я всегда считал отступы неестественными. Они отнимают много места, и при этом в экран въезжает гораздо меньше кода. Если что и охватывать глазами, то код целиком, а не постоянно дергать за ползунок. Да, я их сам постоянно использую, ведь все привыкли так. Грамотная подстветка кода решает вопрос.

Сообщение от Quiet Snow А GOSUB безвозвратно устарел как только появились нормальные процедуры.

Что значит "нормальные"? Это те, что что посредством стека работают? Это функции, в моем представлении. И в бейсике тоже были функции, которые отличны от процедур Нормальная процедура не должна принимать параметры через стек. Не должна позволять работать рекурсивно. Это обеспечивает в разы большую безопасность кода. Ну и ускоряет работу самих процедур. Нынешние языки вообще размыли поняти процедур и функций.
Да, в старых версиях basic, процедура не имела своих параметров, надо было работать через глобальные переменные. Это недостаток. Но он поправим если каждая процедура будет иметь свой собственнй пул переменных, и поле для возврата. Простой пример.
Допустим нам надо три раза вызвать одну и ту же процедуру с тремя параметрами, один из параметров которой должен быть все время разным, а два других не меняются. В обычном подходе приходится передавать все три параметра. В нормальном, надо передать в первый раз три параметра, а в двух остальных всего один, так как два параметра остаются неизменными. Разве это не ускоряет код? Ускоряет. А нам все универсализировали. Я не согласен.

0

Сообщение от CoderHuligan начинать надо с малого, с азов.

Не нужно учится старому стилю программирования, который сейчас не применяется. Я про номера строк, повсеместные goto, подпрограммы вместо функций и т. д.

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

Не нужно стараться писать строки кода как можно более длинными. Это снижает читаемость.
Размер процедуры/функции должен быть таким чтобы помещался на экране без прокрутки.
В IDE должна быть удобная навигация по функциям.
Большой код нужно делить на несколько файлов.

Сообщение от CoderHuligan Нормальная процедура не должна принимать параметры через стек. Не должна позволять работать рекурсивно. Это обеспечивает в разы большую безопасность кода.

В чем безопасность?
Если не через стек, то как? Через глобальные переменные? Про многопоточность не думали? А про 1500 глобальных переменных? С локальными что делать? Тоже хранить в глобальных? Вот будет "весело" править отлаженный код при его повторном использовании из-за конфликта имен глобальных переменных.

Сообщение от CoderHuligan Да, в старых версиях basic, процедура не имела своих параметров, надо было работать через глобальные переменные.

Это не процедуры, а подпрограммы.

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

То есть стек.

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

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

0

Сообщение от locm Передавайте указатель на экземпляр структуры

А если они логически не связаны? Плодить еще один тип?

Сообщение от locm Если не через стек, то как? Через глобальные переменные?

В forth есть такое понятие как словарь. Допустим, что у нас вместо стека есть список структур, которые описывают каждую отдельную процедуру. Описатель процедуры. В полях параметров описаны параметры-переменные. Их видит только процедура. Они не глобальны. Также есть поле с адресом возврата. Это поле заполняет вызывающая процедура. Вызов обычен.

Сообщение от locm В чем безопасность?

В полном отсутствии стека. Нельзя коррумпировать стек во время исполнения.

0

По поводу стека. В достаточно старых версиях Бейсика стек не просто используется, а их
несколько - отдельно стек для вызовов for, отдельно стек для вызовов gosub.
(и далее видимо - while ... wend)
Интерпретатор контролирует эти стеки и выдаёт при проблемах сообщения об ошибке
(типа next without for, return without gosub).
Проблемы со стеком и вызовом gosub вероятно привели к тому, что в FreeBasic использование
gosub по умолчанию запрещено.

0

Сообщение от CoderHuligan А если они логически не связаны? Плодить еще один тип?

Лучше плодить 1500 глобальных переменных?

Сообщение от CoderHuligan Допустим, что у нас вместо стека есть список структур, которые описывают каждую отдельную процедуру

То есть по структуре на процедуру? Слишком много придется писать и результат того не стоит.

Сообщение от CoderHuligan Их видит только процедура. Они не глобальны.

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

Сообщение от CoderHuligan В полном отсутствии стека. Нельзя коррумпировать стек во время исполнения.

Зато можно коррумпировать ваш словарь со структурами!

0

Сообщение от qbfan Интерпретатор контролирует эти стеки и выдаёт при проблемах сообщения об ошибке (типа next without for, return without gosub).

Это не стек, а элментарная проверка синтаксиса. Современные так же могут.

Миниатюры

 

0

Сообщение от locm Это не стек, а элментарная проверка синтаксиса.

Это именно стек, с помощью которого реализовывались вложенные for..next и вложенные gosub.
Например при gosub в стеке запоминался не адрес возврата (как в ассемблере),
а что-то вроде номера строки и положения директивы gosub в строке. Более того -
при неумелом использовании for..next и gosub .. return в сочетании с goto эти стеки переполнялись
или опустошались.

0

Сообщение от CoderHuligan Это функции, в моем представлении.

Кодер, ты функции не отличаешь от процедур?
Функция возвращает значение, процедура - не возвращает. Это всё что надо об этом знать.
А GOSUB это аморфная субстанция, которая однозначно тебе не скажет какие у неё параметры,
что она возвращает и куда. Т.е. на каждый GOSUB тебе надо лезть в код чтобы это узнать.
По поводу рекурсии уже высказывался, кто хочет себе геморрой - всегда его сыщет.

Сообщение от CoderHuligan Что значит "нормальные"?

Нормальные - значит, обособленные, разграниченные ключевым словом. В которых сразу видно какие
параметры куда приходят и куда уходят, какой их тип.
Твой пример с передачей сначала трёх параметров, а потом одного. Решается просто - через глобалки двух
параметров. Либо передачей в процедуру одного указателя на все три параметра, меняется из которых
любое количество. При адекватном компиляторе скорость будет равноценная.

Сообщение от locm Не нужно стараться писать строки кода как можно более длинными. Это снижает читаемость. Размер процедуры/функции должен быть таким чтобы помещался на экране без прокрутки. В IDE должна быть удобная навигация по функциям. Большой код нужно делить на несколько файлов.

Кстати тоже иногда жертвую парой тактов в чисто логическом коде разбивая одну формулу на две\три и т.п.
чтобы не вылезало за экран. Хотя во времена FullHD мониторов чтобы просто писать код - это не проблема.
Впрочем для читателя это тоже не проблема, если за большой объём кода пару раз вылезет.

Сообщение от locm Не нужно учится старому стилю программирования, который сейчас не применяется.

Именно.

0