tl; dr: Nauka tworzenia silnika jest często tak samo przydatna w tworzeniu gier, jak nauka tworzenia od podstaw własnego komputera i systemu operacyjnego. Jeśli nie jesteś ekspertem w tej dziedzinie, prawdopodobnie nie chcesz robić silnika. Zamiast tego stwórz grę, część silnika już istnieje. Później, jeśli żaden z silników, do których masz dostęp, nie spełnia kryteriów projektowania Twojej gry, możesz skupić się na budowaniu tego konkretnego aspektu, a do diabła może być on przydatny także dla innych, ponieważ tworzysz coś nowego i nie przerabiasz mniej niezawodnej wersji czegoś, w co ludzie zainwestowali już tysiące godzin.
Długa wersja: jeśli naprawdę chcesz nauczyć się pisać silnik, nie patrz jeszcze na istniejący silnik. Naucz się zamiast części (algorytmów), które tworzą silnik, czy to renderowania, fizyki czy wyszukiwania ścieżek itp. Kiedy już zrozumiesz konkretny aspekt, możesz chcieć sprawdzić źródło.
Zwykle nie chcesz uczyć się bezpośrednio ze źródła, chyba że nie ma lepszej alternatywy. Nawet doświadczeni programiści zwykle nie patrzą na źródło całego silnika, aby się z niego uczyć (jeśli mogą mu pomóc), najprawdopodobniej sprawdzą określoną jego część lub poprawią jej część. Próba spojrzenia na źródło wyłącznie w celu uczenia się nie ujawniłaby procedury i procesu myślowego stojącego za kodem silnika; To by było jak rozrywanie kawałków budynku, aby zobaczyć jego wnętrze, aby nauczyć się je budować. Chociaż zgadzam się z odpowiedzią Josha, pójdę o krok dalej, ty nawet nie uczysz się „Jak” pod wieloma względami (chyba że znasz się na tej dziedzinie); na przykład, jaką metodologię zastosował zespół programistów? Na jakich zasadach polegali przy wdrażaniu działającego kodu? Jakich narzędzi i technik użyli do debugowania? Wszystkie te pytania są czasem ważniejsze niż sam kod (do celów uczenia się).
Jeśli chcesz uczyć się od źródła, poszukaj źródła, które jest dobrze udokumentowane i ma silną społeczność wokół niego. Czytanie kodu (silnika), nawet jeśli sam go napisałeś, jest często mylące.