プログラミングで例えばゲームを作る際に、そのコードで何故その画面が表示されるようになってるんでしょう

プログラミングで例えばゲームを作る際に、そのコードで何故その画面が表示されるようになってるんでしょうか？もちろんそう組んでるんでしょうが、仕組みが分かれば丸暗記も減り、応用も効くと思ったので。
チャットgptでパイソンで迷路を作りたいと言った時のコードの一部です。何となく理屈は分かるのですが、じゃあ一から自分で思ったゲームを作りたいって時に画面の描写やキャラクターの動きの関数がどう定義されてるか分からないと難しいのではと思いました。まとまりのない文章ですがよろしくお願いしますm(_ _)m

import random

def generate_maze(width, height):
maze = [[0] * width for _ in range(height)]

def create_maze(x, y):
directions = [(0, 1), (0, -1), (1, 0), (-1, 0)]
random.shuffle(directions)

for dx, dy in directions:
nx, ny = x + dx, y + dy
if 0 <= nx < width and 0 <= ny <

No.5 回答者： もふもふ777 回答日時： 2024/02/29 14:09

ご質問は、要するに「コードの意味を知りたい」という要望と解釈しましたが、残念ながらソースコードが一部過ぎて何の機能を作っているのか？変数や配列が何に使われるのか？などの文脈が全く読み取ることが出来ないので、説明不可能です。

解説して欲しいなら、隠さずに全文載せるか、どうしても一部しか公開したくないのなら、繋がっているソースコードはキリの良い所まで載せて欲しいです。

あと、丸暗記などではなく、やはりご自身でコードの意味をを読めるようになるのが一番ですので、勉強の仕方を改めて質問した方が良いかもしれません。

一応読み取れる範囲だけでも意味を拾って、頑張って回答すると、恐らく、初めに幅と高さを指定して空の二次元配列を作り、その中身をシャッフルの機能を使って上下左右に移動して迷路を作る感じのソースコードなのかな？と思いました。たぶんですが。だって手がかりが少なすぎますから。

No.4 回答者： e.ttom 回答日時： 2024/02/26 11:15

import random

def generate_maze(width, height):
maze = [[0] * width for _ in range(height)]

def create_maze(x, y):
directions = [(0, 1), (0, -1), (1, 0), (-1, 0)]
random.shuffle(directions)

for dx, dy in directions:
nx, ny = x + dx, y + dy
# The following line is incomplete and missing the condition for ny
# if 0 <= nx < width and 0 <= ny <
# It should be:
if 0 <= nx < width and 0 <= ny < height and maze[ny][nx] == 0:
maze[y][x] |= 1 << directions.index((dx, dy))
maze[ny][nx] |= 1 << directions.index((-dx, -dy))
create_maze(nx, ny)

create_maze(0, 0)
return maze

# Example usage:
width, height = 10, 10
maze = generate_maze(width, height)
for row in maze:
print(" ".join(f"{cell:02X}" for cell in row))

これでどうでしょうか？

No.3 回答者： だいぬ 回答日時： 2024/02/25 01:44

こういうのは初代マリオで考えるとかなり直感的で分かりやすい気がするのですがどうでしょう？

例えば1-1の背景が横長の画像としたら、
右に移動するキーを押すとその画像の映す位置を右にずらします。
ディスプレイは1個1個がピクセル出できているので、例えば右のピクセルにマリオの体ごと動かすだとか、右を押した長さで速度を物理学的に計算して、スピードを変えるとか。

No.2 回答者： cametan_42 回答日時： 2024/02/24 18:31

> まとまりのない文章ですがよろしくお願いしますm(_ _)m

ホントにまとまってねぇや(笑)。

いやさ、例に挙げたプログラムの「部分」?
そもそもここに書かれてるのって

> そのコードで何故その画面が表示されるようになってるんでしょうか？

画面が表示されるのとは何も関係なくない?

> 何となく理屈は分かるのですが

多分だから「理屈が」分かってない(笑)。

いや、責めてるんじゃないんだよ。勘違いせんで。
そもそも・・・う〜ん、まず「画面」が何を意図してんだか分からんのよね。
端末上での表示?それともいわゆる「ゲーム画面」?
その辺が曖昧なんで何とも・・・・・・。
んで、

> 仕組みが分かれば丸暗記も減り、応用も効くと思ったので。

が曖昧になる。
いや、だから責めてるわけじゃなくって、単に「仕組み」って何を意図してるのか、って事なのよね。
何故なら、画像に関しては、ある程度「暗記」が絡む話に通常はなるだろうし、「理屈だと・・・」って言うのは限界があるんだよ。
貴方の志はいい。ただし、「どの辺を想定してるのか」がサッパリ分からんのだ。
いや、貴方だけじゃなくって、本質的に、現代のパーソナルコンピュータの「画像処理上の仕組み(つまりGPUが何をどうしてるか)」を理論とするのなら、我々が通常「プログラミングする」までのレイヤーの層が厚すぎて、通常は「手に負える範疇じゃない」って事なのよ。
結果、ラップにラップを重ねて、特定の「ライブラリの使い方」を習熟するか否か、って話になっちゃうのね。
これは僕もそうだし、世の中のプログラマのホンの一部、以外もそうなわけ。
別に貴方が「理論としてハッキリ分かりたい!」とか言う志(があるならば)を邪魔するつもりはない。やりたければ専門書を読んで・・・って話にはなるし、やりたければやれば?って事しか言えない。
ただし、そうじゃないのなら、単に「特定のライブラリの使い方に習熟するか否か」の話になって、別に「仕組みがどーの」って言う範疇の話じゃないんだよな。極論、そのライブラリの「デザイナー」の趣味(つまり設計方針)に、貴方のテイストが合うか合わないか、って話なだけだし、合わなければ「暗記してパターンを覚える」ってだけの話となる。
言い換えると「仕組みが分かる」って言う程の仕組みはそのレベルにはないし、貴方が書いてる「丸暗記」ってのは良い方法だよ。むしろ、「丸暗記」した方が応用が効くんじゃない?

> 迷路を作りたい

でも迷路を作る、例えばアルゴリズムを使って?と言うのと画像は関係ないよね・・・随分前に、教えて!gooの質問で迷路作成アルゴリズム書いた事あったな・・・どれだっけ。
あ、これか。
Pythonで書くとこんな風になるのか?

https://www.ideone.com/iZ2gVV

まぁ、過去書いたロジックをザーッと書き換えただけだけど(バグってるかもしんない・笑)。
いずれにせよ、「迷路を作るアルゴリズム」と「どう表示するのか」って関係ないよね。
それと、キャラの移動だっけ?
例えばさ、端末上に迷路の自キャラを@として置いてカーソルキーを叩けば上下左右に移動するとか。ローグってゲームが有名だけど。

Leaf Rogue:
http://games.roguelife.org/leaf/

単純には自キャラの座標(x, y)に対してカーソルによってx座標あるいはy座標を±1していけばいい。
していけばいいんだけど、端末(Windowsで言うとDOS窓?)で、そういうカーソルキーを「叩く」って動作に対して「即座に反応してくれるかどうか」ってのは別問題なんだ。
なんつっても「標準入力の縛り」ってのがプログラミング言語に対しては大きいから、さ。
結果、こういうのも「貴方のプログラミング上のロジックがどーの」じゃなくって、「端末にどういうライブラリが用意されてるか」次第なのね、実際のトコ。
UNIX系OSだったらncursesってライブラリがその辺を引き受ける。Windowsだとそのテのツールが「無い」と。だから驚くけど、割に自分で「ゲーム用端末」を「GUIとして作っちゃう」って例がWindowsだと結果多いんじゃないかしらん。

余談だけど、黎明期のパソコン、ってのはモニターにテレビを使うってのが良くあったの。当時のテレビ、ってのはブラウン管のブツだな。走査線って言われるもので一画面256本しか線を引けなくて、結果、今で言うピクセル数ってのは256 x 224前後だったのね。
今の4Kテレビ、3,840x2,160とは大違いの貧弱さ、だった。
それだけじゃない。CPUの演算速度だって、今で言うとおもちゃ程度の性能しかなかったんで、256 x 224前後のピクセルを「全部操作する」ってのが不可能だったんだ。
で、最初に出たApple IIとか、結果、256 x 224のピクセル数をリアルタイムで全部制御するのは不可能だったんで、色数が多い(それでもたった15色・笑)場合、テレビの何ピクセルかを一個にまとめて、40×48くらいで絵を描く、って事しか出来なかった。
今見ると当然「しょぼ!」とか思うんだけど(笑)、反面、プログラムする側には優しかったんだよ。なんせピクセル総数が2,000に満たない。この程度なら「直接プログラマが制御コードを書けた」って意味なんだ。
当時のBASIC言語にはPOKE命令、と言われる命令があって、1ピクセル1ピクセル毎をBASICから操作出来たのね。なんも「下部レイヤー」とか存在しない。
だから今と違って、「どうすればいいのか」ってのが、皮肉な事に、「しょぼい見た目のゲームしか作れなかった」割には、「理屈としては」分かりやすかったんだ。
僕らはその時代から「凄く遠いトコへ」来ちゃった、ってお話。

写真: 初期Apple IIに付属していたゲーム「Breakout」。いわゆる「ブロック崩し」。
これはゲーセンでのブロック崩し(オリジナル)の開発に関わっていた、Appleの創業者の一人、スティーヴ・ウォズニアックの手に依るモノだと思われる。
ウォズニアックは、一種の「Apple IIで何が出来るのか」デモンストレーションの意を込めて、わずか数行のBASICによるプログラミングで、この「付属品」を作った。
しかし、「見た目はショボい」けど、「簡単にプログラム出来た」のはBASICのPOKE命令、そしてなんと言っても「扱える画素数が今の基準で言うと極端に少なかったから」だ。
結果、簡単な記述で、Apple IIではプログラマが画面の制御を思い通りに出来たわけだ。

No.1 回答者： rera1016 回答日時： 2024/02/24 07:04

このソースでは画面表示のためのコーディングがされていないので、何も表示されないのが正解です。

実際に画面描写する時は、グラフィックライブラリーを使って描写する命令を加えないといけません。
WindowsであればGDIやDirectXを利用します。

Webアプリケーションだと、HTML要素としてcanvasというものがあり、それをJavaScriptなどで描画する命令をコーディングすることで任意の図形を描写することができます。
https://www.sejuku.net/blog/101680