mirror of
https://github.com/kuhyx/praca_magisterska.git
synced 2026-07-04 13:43:05 +02:00
feat: fix polish fonts, some theoretical dissertations
This commit is contained in:
parent
c0a479492e
commit
9a6719f629
@ -89,6 +89,15 @@
|
|||||||
|
|
||||||
% Game Engine Research Literature
|
% Game Engine Research Literature
|
||||||
|
|
||||||
|
@book{gregory2018game,
|
||||||
|
author = {Gregory, Jason},
|
||||||
|
title = {Game Engine Architecture},
|
||||||
|
publisher = {A~K Peters/CRC Press},
|
||||||
|
edition = {3rd},
|
||||||
|
year = {2018},
|
||||||
|
isbn = {978-1138035454}
|
||||||
|
}
|
||||||
|
|
||||||
@article{ullmann2022game,
|
@article{ullmann2022game,
|
||||||
author = {Ullmann, G. C. and Politowski, C. and Guéhéneuc, Y.-G. and Anquetil, N.},
|
author = {Ullmann, G. C. and Politowski, C. and Guéhéneuc, Y.-G. and Anquetil, N.},
|
||||||
title = {Game engine comparative anatomy},
|
title = {Game engine comparative anatomy},
|
||||||
|
|||||||
159
latex/fix-polish-fonts.py
Executable file
159
latex/fix-polish-fonts.py
Executable file
@ -0,0 +1,159 @@
|
|||||||
|
#!/usr/bin/env python3
|
||||||
|
"""
|
||||||
|
Fix Polish character support for WUT thesis template with XeTeX.
|
||||||
|
This script patches wut-thesis.cls to use fontspec with OpenType fonts
|
||||||
|
that properly support Polish characters (ą, ć, ę, ł, ń, ó, ś, ź, ż).
|
||||||
|
"""
|
||||||
|
|
||||||
|
import os
|
||||||
|
import sys
|
||||||
|
import shutil
|
||||||
|
import subprocess
|
||||||
|
from pathlib import Path
|
||||||
|
|
||||||
|
def get_script_dir():
|
||||||
|
return Path(__file__).parent.absolute()
|
||||||
|
|
||||||
|
def check_and_install_fonts():
|
||||||
|
"""Check if required TeX packages are available."""
|
||||||
|
print("[1/4] Checking for required fonts...")
|
||||||
|
|
||||||
|
# Check for TeX Gyre fonts (usually in texlive-fontsextra)
|
||||||
|
try:
|
||||||
|
result = subprocess.run(
|
||||||
|
['kpsewhich', 'texgyretermes-regular.otf'],
|
||||||
|
capture_output=True, text=True
|
||||||
|
)
|
||||||
|
if result.returncode != 0:
|
||||||
|
print(" -> TeX Gyre fonts may not be installed.")
|
||||||
|
print(" -> On Arch Linux, run: sudo pacman -S texlive-fontsextra")
|
||||||
|
except FileNotFoundError:
|
||||||
|
print(" -> kpsewhich not found. Make sure TeX Live is installed.")
|
||||||
|
|
||||||
|
print(" -> Font check complete.")
|
||||||
|
|
||||||
|
def backup_cls_file(cls_path: Path, backup_path: Path):
|
||||||
|
"""Create backup of the class file."""
|
||||||
|
print("\n[2/4] Creating backup of wut-thesis.cls...")
|
||||||
|
|
||||||
|
if backup_path.exists():
|
||||||
|
print(" -> Backup already exists, skipping.")
|
||||||
|
else:
|
||||||
|
shutil.copy2(cls_path, backup_path)
|
||||||
|
print(f" -> Backup created: {backup_path}")
|
||||||
|
|
||||||
|
def patch_cls_file(cls_path: Path):
|
||||||
|
"""Apply patches to the class file."""
|
||||||
|
print("\n[3/4] Patching wut-thesis.cls...")
|
||||||
|
|
||||||
|
content = cls_path.read_text(encoding='utf-8')
|
||||||
|
|
||||||
|
# Check if already patched
|
||||||
|
if 'fontspec' in content and 'ifxetex' in content:
|
||||||
|
print(" -> Already patched, skipping class file modification.")
|
||||||
|
return False
|
||||||
|
|
||||||
|
# Patch 1: Replace fourier package with conditional font loading
|
||||||
|
# Using Liberation fonts which are widely available and have full Polish support
|
||||||
|
fourier_old = r'\RequirePackage{fourier} % Adobe Utopia font'
|
||||||
|
fourier_new = '''% Conditional font loading for XeTeX/LuaTeX compatibility with Polish characters
|
||||||
|
\\RequirePackage{iftex}
|
||||||
|
\\ifxetex
|
||||||
|
\\RequirePackage{fontspec}
|
||||||
|
\\defaultfontfeatures{Ligatures=TeX}
|
||||||
|
% Use DejaVu fonts - widely available with full Polish character support
|
||||||
|
\\setmainfont{DejaVu Serif}
|
||||||
|
\\setsansfont{DejaVu Sans}
|
||||||
|
\\setmonofont{DejaVu Sans Mono}
|
||||||
|
\\else\\ifluatex
|
||||||
|
\\RequirePackage{fontspec}
|
||||||
|
\\defaultfontfeatures{Ligatures=TeX}
|
||||||
|
\\setmainfont{DejaVu Serif}
|
||||||
|
\\setsansfont{DejaVu Sans}
|
||||||
|
\\setmonofont{DejaVu Sans Mono}
|
||||||
|
\\else
|
||||||
|
\\RequirePackage{fourier} % Adobe Utopia font (pdfLaTeX only)
|
||||||
|
\\fi\\fi'''
|
||||||
|
|
||||||
|
if fourier_old in content:
|
||||||
|
content = content.replace(fourier_old, fourier_new)
|
||||||
|
print(" -> Patched fourier package for XeTeX font support.")
|
||||||
|
else:
|
||||||
|
# Try without the comment
|
||||||
|
fourier_old_alt = r'\RequirePackage{fourier}'
|
||||||
|
if fourier_old_alt in content and 'fontspec' not in content:
|
||||||
|
content = content.replace(fourier_old_alt, fourier_new, 1)
|
||||||
|
print(" -> Patched fourier package for XeTeX font support.")
|
||||||
|
|
||||||
|
# Patch 2: Fix microtype to disable expansion for XeTeX
|
||||||
|
microtype_old = '''\\RequirePackage[
|
||||||
|
protrusion=true,
|
||||||
|
expansion=true
|
||||||
|
]{microtype}'''
|
||||||
|
|
||||||
|
microtype_new = '''% Microtype - disable expansion for XeTeX (not supported)
|
||||||
|
\\ifxetex
|
||||||
|
\\RequirePackage[protrusion=true]{microtype}
|
||||||
|
\\else
|
||||||
|
\\RequirePackage[protrusion=true,expansion=true]{microtype}
|
||||||
|
\\fi'''
|
||||||
|
|
||||||
|
if microtype_old in content:
|
||||||
|
content = content.replace(microtype_old, microtype_new)
|
||||||
|
print(" -> Patched microtype package for XeTeX compatibility.")
|
||||||
|
|
||||||
|
# Write the patched content
|
||||||
|
cls_path.write_text(content, encoding='utf-8')
|
||||||
|
print(" -> Patches applied successfully.")
|
||||||
|
return True
|
||||||
|
|
||||||
|
def clean_aux_files(latex_dir: Path):
|
||||||
|
"""Remove auxiliary files to force fresh compilation."""
|
||||||
|
print("\n[4/4] Cleaning auxiliary files...")
|
||||||
|
|
||||||
|
extensions = [
|
||||||
|
'.aux', '.bbl', '.bcf', '.blg', '.fdb_latexmk', '.fls',
|
||||||
|
'.log', '.out', '.run.xml', '.synctex.gz', '.toc',
|
||||||
|
'.lof', '.lot', '.xdv', '.pdf'
|
||||||
|
]
|
||||||
|
|
||||||
|
cleaned = 0
|
||||||
|
for ext in extensions:
|
||||||
|
file_path = latex_dir / f"main{ext}"
|
||||||
|
if file_path.exists():
|
||||||
|
file_path.unlink()
|
||||||
|
cleaned += 1
|
||||||
|
|
||||||
|
print(f" -> Cleaned {cleaned} auxiliary files.")
|
||||||
|
|
||||||
|
def main():
|
||||||
|
print("=== WUT Thesis Polish Font Fix ===")
|
||||||
|
print("Fixes 'Missing character' errors for Polish letters (ą, ę, ł, etc.)")
|
||||||
|
print("")
|
||||||
|
|
||||||
|
script_dir = get_script_dir()
|
||||||
|
cls_path = script_dir / "src" / "wut-thesis.cls"
|
||||||
|
backup_path = script_dir / "src" / "wut-thesis.cls.backup"
|
||||||
|
|
||||||
|
if not cls_path.exists():
|
||||||
|
print(f"ERROR: Class file not found: {cls_path}")
|
||||||
|
sys.exit(1)
|
||||||
|
|
||||||
|
check_and_install_fonts()
|
||||||
|
backup_cls_file(cls_path, backup_path)
|
||||||
|
patch_cls_file(cls_path)
|
||||||
|
clean_aux_files(script_dir)
|
||||||
|
|
||||||
|
print("")
|
||||||
|
print("=== Fix Applied Successfully ===")
|
||||||
|
print("")
|
||||||
|
print("To compile the document, run:")
|
||||||
|
print(f" cd {script_dir}")
|
||||||
|
print(" latexmk -xelatex main.tex")
|
||||||
|
print("")
|
||||||
|
print("Or for a quick compilation:")
|
||||||
|
print(" xelatex main.tex && biber main && xelatex main.tex && xelatex main.tex")
|
||||||
|
print("")
|
||||||
|
|
||||||
|
if __name__ == "__main__":
|
||||||
|
main()
|
||||||
22
latex/fix-polish-fonts.sh
Executable file
22
latex/fix-polish-fonts.sh
Executable file
@ -0,0 +1,22 @@
|
|||||||
|
#!/bin/bash
|
||||||
|
# Fix Polish character support for WUT thesis template with XeTeX
|
||||||
|
# This script wraps the Python fix script
|
||||||
|
|
||||||
|
set -e
|
||||||
|
|
||||||
|
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||||
|
|
||||||
|
echo "Running Polish font fix..."
|
||||||
|
python3 "$SCRIPT_DIR/fix-polish-fonts.py"
|
||||||
|
|
||||||
|
echo ""
|
||||||
|
echo "Running full compilation..."
|
||||||
|
cd "$SCRIPT_DIR"
|
||||||
|
xelatex -interaction=nonstopmode main.tex
|
||||||
|
biber main
|
||||||
|
xelatex -interaction=nonstopmode main.tex
|
||||||
|
xelatex -interaction=nonstopmode main.tex
|
||||||
|
|
||||||
|
echo ""
|
||||||
|
echo "=== Compilation Complete ==="
|
||||||
|
echo "Output: $SCRIPT_DIR/main.pdf"
|
||||||
@ -1,2 +1,2 @@
|
|||||||
\contentsline {subsection}{\hspace *{-1.1em}1.\hspace *{0.5em} Nazwa załącznika 1}{22}{section*.4}%
|
\contentsline {subsection}{\hspace *{-1.1em}1.\hspace *{0.5em} Nazwa załącznika 1}{54}{section*.16}%
|
||||||
\contentsline {subsection}{\hspace *{-1.1em}2.\hspace *{0.5em} Nazwa załącznika 2}{24}{section*.6}%
|
\contentsline {subsection}{\hspace *{-1.1em}2.\hspace *{0.5em} Nazwa załącznika 2}{56}{section*.18}%
|
||||||
|
|||||||
523
latex/main.bbl-SAVE-ERROR
Normal file
523
latex/main.bbl-SAVE-ERROR
Normal file
@ -0,0 +1,523 @@
|
|||||||
|
% $ biblatex auxiliary file $
|
||||||
|
% $ biblatex bbl format version 3.3 $
|
||||||
|
% Do not modify the above lines!
|
||||||
|
%
|
||||||
|
% This is an auxiliary file used by the 'biblatex' package.
|
||||||
|
% This file may safely be deleted. It will be recreated by
|
||||||
|
% biber as required.
|
||||||
|
%
|
||||||
|
\begingroup
|
||||||
|
\makeatletter
|
||||||
|
\@ifundefined{ver@biblatex.sty}
|
||||||
|
{\@latex@error
|
||||||
|
{Missing 'biblatex' package}
|
||||||
|
{The bibliography requires the 'biblatex' package.}
|
||||||
|
\aftergroup\endinput}
|
||||||
|
{}
|
||||||
|
\endgroup
|
||||||
|
|
||||||
|
|
||||||
|
\refsection{0}
|
||||||
|
\datalist[entry]{none/global//global/global/global}
|
||||||
|
\entry{ullmann2022game}{article}{}{}
|
||||||
|
\name{author}{4}{}{%
|
||||||
|
{{hash=f0cf8723114b5cdece39c9b821fbba33}{%
|
||||||
|
family={Ullmann},
|
||||||
|
familyi={U\bibinitperiod},
|
||||||
|
given={G.\bibnamedelimi C.},
|
||||||
|
giveni={G\bibinitperiod\bibinitdelim C\bibinitperiod}}}%
|
||||||
|
{{hash=7ab0ab8efd8ef26e6ff9cdd17ae6c1e2}{%
|
||||||
|
family={Politowski},
|
||||||
|
familyi={P\bibinitperiod},
|
||||||
|
given={C.},
|
||||||
|
giveni={C\bibinitperiod}}}%
|
||||||
|
{{hash=1fc56f8f2c5fe17fb2de73add7e03908}{%
|
||||||
|
family={Guéhéneuc},
|
||||||
|
familyi={G\bibinitperiod},
|
||||||
|
given={Y.-G.},
|
||||||
|
giveni={Y\bibinithyphendelim G\bibinitperiod}}}%
|
||||||
|
{{hash=91378421f7dafd79d680fba6e740767c}{%
|
||||||
|
family={Anquetil},
|
||||||
|
familyi={A\bibinitperiod},
|
||||||
|
given={N.},
|
||||||
|
giveni={N\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{Springer}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{a23a68f4b737bbd262b20c8ea21f31cd}
|
||||||
|
\strng{fullhash}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\strng{fullhashraw}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\strng{bibnamehash}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\strng{authorbibnamehash}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\strng{authornamehash}{a23a68f4b737bbd262b20c8ea21f31cd}
|
||||||
|
\strng{authorfullhash}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\strng{authorfullhashraw}{3e4447e5568387469daf057a43f85c45}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{International Conference on Software Architecture}
|
||||||
|
\field{title}{Game engine comparative anatomy}
|
||||||
|
\field{year}{2022}
|
||||||
|
\field{pages}{117\bibrangedash 136}
|
||||||
|
\range{pages}{20}
|
||||||
|
\endentry
|
||||||
|
\entry{gregory2018game}{book}{}{}
|
||||||
|
\name{author}{1}{}{%
|
||||||
|
{{hash=b97f772b60bfb5bf77251b45263e44dd}{%
|
||||||
|
family={Gregory},
|
||||||
|
familyi={G\bibinitperiod},
|
||||||
|
given={Jason},
|
||||||
|
giveni={J\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{A~K Peters/CRC Press}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{fullhash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{fullhashraw}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{bibnamehash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{authorbibnamehash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{authornamehash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{authorfullhash}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\strng{authorfullhashraw}{b97f772b60bfb5bf77251b45263e44dd}
|
||||||
|
\field{sortinit}{2}
|
||||||
|
\field{sortinithash}{8b555b3791beccb63322c22f3320aa9a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{edition}{3rd}
|
||||||
|
\field{isbn}{978-1138035454}
|
||||||
|
\field{title}{Game Engine Architecture}
|
||||||
|
\field{year}{2018}
|
||||||
|
\endentry
|
||||||
|
\entry{christopoulou2017overview}{article}{}{}
|
||||||
|
\name{author}{2}{}{%
|
||||||
|
{{hash=218e8b9d38ffe09b5514942781a0e3f1}{%
|
||||||
|
family={Christopoulou},
|
||||||
|
familyi={C\bibinitperiod},
|
||||||
|
given={E.},
|
||||||
|
giveni={E\bibinitperiod}}}%
|
||||||
|
{{hash=0544344a8ca98fad8802a19526dd8563}{%
|
||||||
|
family={Xinogalos},
|
||||||
|
familyi={X\bibinitperiod},
|
||||||
|
given={S.},
|
||||||
|
giveni={S\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{fullhash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{fullhashraw}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{bibnamehash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{authorbibnamehash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{authornamehash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{authorfullhash}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\strng{authorfullhashraw}{3c5a4cae39a1c0ddaa4664d7b990e00a}
|
||||||
|
\field{sortinit}{5}
|
||||||
|
\field{sortinithash}{20e9b4b0b173788c5dace24730f47d8c}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{International Journal of Serious Games}
|
||||||
|
\field{number}{4}
|
||||||
|
\field{title}{Overview and comparative analysis of game engines for desktop and mobile devices}
|
||||||
|
\field{volume}{4}
|
||||||
|
\field{year}{2017}
|
||||||
|
\field{pages}{21\bibrangedash 36}
|
||||||
|
\range{pages}{16}
|
||||||
|
\endentry
|
||||||
|
\entry{sharif2021game}{inproceedings}{}{}
|
||||||
|
\name{author}{2}{}{%
|
||||||
|
{{hash=be9881d5fd806889395d0a65ae8fae3a}{%
|
||||||
|
family={Sharif},
|
||||||
|
familyi={S\bibinitperiod},
|
||||||
|
given={K.\bibnamedelimi H.},
|
||||||
|
giveni={K\bibinitperiod\bibinitdelim H\bibinitperiod}}}%
|
||||||
|
{{hash=9ecdb5a8041ea6c24c6e5075d94c83b9}{%
|
||||||
|
family={Ameen},
|
||||||
|
familyi={A\bibinitperiod},
|
||||||
|
given={S.\bibnamedelimi Y.},
|
||||||
|
giveni={S\bibinitperiod\bibinitdelim Y\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{IEEE}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{fullhash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{fullhashraw}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{bibnamehash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{authorbibnamehash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{authornamehash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{authorfullhash}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\strng{authorfullhashraw}{08487e339917dbcd0f778176b34802fe}
|
||||||
|
\field{sortinit}{6}
|
||||||
|
\field{sortinithash}{b33bc299efb3c36abec520a4c896a66d}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{booktitle}{2021 International Conference on Advanced Computer Applications}
|
||||||
|
\field{title}{Game engines evaluation for serious game development in education}
|
||||||
|
\field{year}{2021}
|
||||||
|
\field{pages}{1\bibrangedash 6}
|
||||||
|
\range{pages}{6}
|
||||||
|
\endentry
|
||||||
|
\entry{pavkov2017comparison}{inproceedings}{}{}
|
||||||
|
\name{author}{3}{}{%
|
||||||
|
{{hash=7314d462a608dde2db8068b58b49f8bc}{%
|
||||||
|
family={Pavkov},
|
||||||
|
familyi={P\bibinitperiod},
|
||||||
|
given={S.},
|
||||||
|
giveni={S\bibinitperiod}}}%
|
||||||
|
{{hash=2e2d26bd81805c892872eb63b3a5f686}{%
|
||||||
|
family={Franković},
|
||||||
|
familyi={F\bibinitperiod},
|
||||||
|
given={I.},
|
||||||
|
giveni={I\bibinitperiod}}}%
|
||||||
|
{{hash=d469cd478a1898c80f4ae09ecb23c90c}{%
|
||||||
|
family={Hoblaj},
|
||||||
|
familyi={H\bibinitperiod},
|
||||||
|
given={M.},
|
||||||
|
giveni={M\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{IEEE}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{1635cd70a14471ab3b0db3eba2503f4a}
|
||||||
|
\strng{fullhash}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\strng{fullhashraw}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\strng{bibnamehash}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\strng{authorbibnamehash}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\strng{authornamehash}{1635cd70a14471ab3b0db3eba2503f4a}
|
||||||
|
\strng{authorfullhash}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\strng{authorfullhashraw}{2f901483b479793275ad6667c8bdb354}
|
||||||
|
\field{sortinit}{7}
|
||||||
|
\field{sortinithash}{108d0be1b1bee9773a1173443802c0a3}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{booktitle}{2017 40th International Convention on Information and Communication Technology}
|
||||||
|
\field{title}{Comparison of game engines for serious games}
|
||||||
|
\field{year}{2017}
|
||||||
|
\field{pages}{728\bibrangedash 733}
|
||||||
|
\range{pages}{6}
|
||||||
|
\endentry
|
||||||
|
\entry{messaoudi2017performance}{article}{}{}
|
||||||
|
\name{author}{3}{}{%
|
||||||
|
{{hash=ef01b7dae2f874e21a0c7366fa5106ca}{%
|
||||||
|
family={Messaoudi},
|
||||||
|
familyi={M\bibinitperiod},
|
||||||
|
given={F.},
|
||||||
|
giveni={F\bibinitperiod}}}%
|
||||||
|
{{hash=77f21fca29a861298aacc7587b8ef1e1}{%
|
||||||
|
family={Ksentini},
|
||||||
|
familyi={K\bibinitperiod},
|
||||||
|
given={A.},
|
||||||
|
giveni={A\bibinitperiod}}}%
|
||||||
|
{{hash=95aa28f1a361cb935b6fa4d73f4697ea}{%
|
||||||
|
family={Simon},
|
||||||
|
familyi={S\bibinitperiod},
|
||||||
|
given={G.},
|
||||||
|
giveni={G\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{98e2e333ad504afc84a381339389510b}
|
||||||
|
\strng{fullhash}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\strng{fullhashraw}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\strng{bibnamehash}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\strng{authorbibnamehash}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\strng{authornamehash}{98e2e333ad504afc84a381339389510b}
|
||||||
|
\strng{authorfullhash}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\strng{authorfullhashraw}{916696c34e2d5fc1cb70ef353f63a74f}
|
||||||
|
\field{sortinit}{8}
|
||||||
|
\field{sortinithash}{a231b008ebf0ecbe0b4d96dcc159445f}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{ACM Transactions on Multimedia Computing, Communications, and Applications}
|
||||||
|
\field{number}{4}
|
||||||
|
\field{title}{Performance analysis of game engines on mobile and fixed devices}
|
||||||
|
\field{volume}{13}
|
||||||
|
\field{year}{2017}
|
||||||
|
\field{pages}{1\bibrangedash 24}
|
||||||
|
\range{pages}{24}
|
||||||
|
\endentry
|
||||||
|
\entry{abramowicz2024comparative}{article}{}{}
|
||||||
|
\name{author}{2}{}{%
|
||||||
|
{{hash=db1c2f5cd1997677c6a451dd447849b6}{%
|
||||||
|
family={Abramowicz},
|
||||||
|
familyi={A\bibinitperiod},
|
||||||
|
given={K.},
|
||||||
|
giveni={K\bibinitperiod}}}%
|
||||||
|
{{hash=df8a68ac3d56cd5ee6eec3d008280244}{%
|
||||||
|
family={Borczuk},
|
||||||
|
familyi={B\bibinitperiod},
|
||||||
|
given={P.},
|
||||||
|
giveni={P\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{fullhash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{fullhashraw}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{bibnamehash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{authorbibnamehash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{authornamehash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{authorfullhash}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\strng{authorfullhashraw}{109f57dc949a82d2e717890afe20e8ef}
|
||||||
|
\field{sortinit}{9}
|
||||||
|
\field{sortinithash}{0a5ebc79d83c96b6579069544c73c7d4}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{Journal of Computer Science Institute}
|
||||||
|
\field{title}{Comparative analysis of the performance of Unity and Unreal Engine game engines in 3D games}
|
||||||
|
\field{volume}{30}
|
||||||
|
\field{year}{2024}
|
||||||
|
\field{pages}{1\bibrangedash 8}
|
||||||
|
\range{pages}{8}
|
||||||
|
\endentry
|
||||||
|
\entry{pattrasitidecha2014comparison}{thesis}{}{}
|
||||||
|
\name{author}{1}{}{%
|
||||||
|
{{hash=e34adb1e9ad40775c17a6682c5b99911}{%
|
||||||
|
family={Pattrasitidecha},
|
||||||
|
familyi={P\bibinitperiod},
|
||||||
|
given={A.},
|
||||||
|
giveni={A\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{institution}{1}{%
|
||||||
|
{Chalmers University of Technology}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{fullhash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{fullhashraw}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{bibnamehash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{authorbibnamehash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{authornamehash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{authorfullhash}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\strng{authorfullhashraw}{e34adb1e9ad40775c17a6682c5b99911}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{title}{Comparison and evaluation of 3D mobile game engines}
|
||||||
|
\field{type}{Master's thesis}
|
||||||
|
\field{year}{2014}
|
||||||
|
\endentry
|
||||||
|
\entry{vohera2021game}{inproceedings}{}{}
|
||||||
|
\name{author}{3}{}{%
|
||||||
|
{{hash=bca633d031128bed1b8ad098054e63dc}{%
|
||||||
|
family={Vohera},
|
||||||
|
familyi={V\bibinitperiod},
|
||||||
|
given={C.},
|
||||||
|
giveni={C\bibinitperiod}}}%
|
||||||
|
{{hash=1b6159edc7111cbb17583c12f2748cbe}{%
|
||||||
|
family={Chheda},
|
||||||
|
familyi={C\bibinitperiod},
|
||||||
|
given={H.},
|
||||||
|
giveni={H\bibinitperiod}}}%
|
||||||
|
{{hash=7b07ec13c5a7891a3c4478398c62f442}{%
|
||||||
|
family={Chouhan},
|
||||||
|
familyi={C\bibinitperiod},
|
||||||
|
given={D.},
|
||||||
|
giveni={D\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{IEEE}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{3240e3ea549615b12561b1839f5cb3e9}
|
||||||
|
\strng{fullhash}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\strng{fullhashraw}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\strng{bibnamehash}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\strng{authorbibnamehash}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\strng{authornamehash}{3240e3ea549615b12561b1839f5cb3e9}
|
||||||
|
\strng{authorfullhash}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\strng{authorfullhashraw}{f0a4b4d015898a6d4e28f33a9c2a9155}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{booktitle}{2021 12th International Conference on Computing Communication and Networking Technologies}
|
||||||
|
\field{title}{Game engine architecture and comparative study of different game engines}
|
||||||
|
\field{year}{2021}
|
||||||
|
\field{pages}{1\bibrangedash 7}
|
||||||
|
\range{pages}{7}
|
||||||
|
\endentry
|
||||||
|
\entry{marks2008evaluation}{inproceedings}{}{}
|
||||||
|
\name{author}{3}{}{%
|
||||||
|
{{hash=156ebe07a62d786fd5cc7efb92bc07b3}{%
|
||||||
|
family={Marks},
|
||||||
|
familyi={M\bibinitperiod},
|
||||||
|
given={S.},
|
||||||
|
giveni={S\bibinitperiod}}}%
|
||||||
|
{{hash=4c84293ada2705347be29576abd9cfca}{%
|
||||||
|
family={Windsor},
|
||||||
|
familyi={W\bibinitperiod},
|
||||||
|
given={J.},
|
||||||
|
giveni={J\bibinitperiod}}}%
|
||||||
|
{{hash=4da5ee77fb9234fe0e4e336ecf3c54b8}{%
|
||||||
|
family={Wünsche},
|
||||||
|
familyi={W\bibinitperiod},
|
||||||
|
given={B.},
|
||||||
|
giveni={B\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{c59eea1c122c30ac74d72a9ab1b74d5e}
|
||||||
|
\strng{fullhash}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\strng{fullhashraw}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\strng{bibnamehash}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\strng{authorbibnamehash}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\strng{authornamehash}{c59eea1c122c30ac74d72a9ab1b74d5e}
|
||||||
|
\strng{authorfullhash}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\strng{authorfullhashraw}{bcb08f2cc586b839bbae5ca8911de9f1}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{booktitle}{New Zealand Computer Science Research Student Conference}
|
||||||
|
\field{title}{Evaluation of game engines for simulated clinical training}
|
||||||
|
\field{year}{2008}
|
||||||
|
\field{pages}{25\bibrangedash 30}
|
||||||
|
\range{pages}{6}
|
||||||
|
\endentry
|
||||||
|
\entry{ali2016framework}{inproceedings}{}{}
|
||||||
|
\name{author}{2}{}{%
|
||||||
|
{{hash=933521982fd704c5d631b7b7f108c255}{%
|
||||||
|
family={Ali},
|
||||||
|
familyi={A\bibinitperiod},
|
||||||
|
given={Z.},
|
||||||
|
giveni={Z\bibinitperiod}}}%
|
||||||
|
{{hash=887683edb5cd8679182a27beb087f604}{%
|
||||||
|
family={Usman},
|
||||||
|
familyi={U\bibinitperiod},
|
||||||
|
given={M.},
|
||||||
|
giveni={M\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\list{publisher}{1}{%
|
||||||
|
{IEEE}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{fullhash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{fullhashraw}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{bibnamehash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{authorbibnamehash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{authornamehash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{authorfullhash}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\strng{authorfullhashraw}{cea94bef850e2d2665a84c20f4b4317d}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{booktitle}{2016 Future Technologies Conference}
|
||||||
|
\field{title}{A framework for game engine selection for gamification and serious games}
|
||||||
|
\field{year}{2016}
|
||||||
|
\field{pages}{1\bibrangedash 8}
|
||||||
|
\range{pages}{8}
|
||||||
|
\endentry
|
||||||
|
\entry{barczak2019comparative}{article}{}{}
|
||||||
|
\name{author}{2}{}{%
|
||||||
|
{{hash=2c806af71e687f76d0b0b035fe7368e6}{%
|
||||||
|
family={Barczak},
|
||||||
|
familyi={B\bibinitperiod},
|
||||||
|
given={A.},
|
||||||
|
giveni={A\bibinitperiod}}}%
|
||||||
|
{{hash=c6c0874986384d722877eb8b462a9725}{%
|
||||||
|
family={Woźniak},
|
||||||
|
familyi={W\bibinitperiod},
|
||||||
|
given={H.},
|
||||||
|
giveni={H\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{fullhash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{fullhashraw}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{bibnamehash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{authorbibnamehash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{authornamehash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{authorfullhash}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\strng{authorfullhashraw}{b2561cc7da97008bf543eed689245229}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{Studia Informatica. System and Information Technology}
|
||||||
|
\field{number}{1}
|
||||||
|
\field{title}{Comparative study on game engines}
|
||||||
|
\field{volume}{23}
|
||||||
|
\field{year}{2019}
|
||||||
|
\field{pages}{5\bibrangedash 18}
|
||||||
|
\range{pages}{14}
|
||||||
|
\endentry
|
||||||
|
\entry{masood2022high}{article}{}{}
|
||||||
|
\name{author}{4}{}{%
|
||||||
|
{{hash=eb077239d8480da2071e2136768797e5}{%
|
||||||
|
family={Masood},
|
||||||
|
familyi={M\bibinitperiod},
|
||||||
|
given={Z.},
|
||||||
|
giveni={Z\bibinitperiod}}}%
|
||||||
|
{{hash=5dc4fa4a7db70cbdff3f7384dd9a8864}{%
|
||||||
|
family={Jiangbin},
|
||||||
|
familyi={J\bibinitperiod},
|
||||||
|
given={Z.},
|
||||||
|
giveni={Z\bibinitperiod}}}%
|
||||||
|
{{hash=6448deafb71577dda681f23628d0247e}{%
|
||||||
|
family={Irfan},
|
||||||
|
familyi={I\bibinitperiod},
|
||||||
|
given={M.},
|
||||||
|
giveni={M\bibinitperiod}}}%
|
||||||
|
{{hash=29a3475bb1f4b4bf09fcbe3e740c843f}{%
|
||||||
|
family={Ahmad},
|
||||||
|
familyi={A\bibinitperiod},
|
||||||
|
given={I.},
|
||||||
|
giveni={I\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{2a82c8d1682e6420bc106eda3c260f4a}
|
||||||
|
\strng{fullhash}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\strng{fullhashraw}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\strng{bibnamehash}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\strng{authorbibnamehash}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\strng{authornamehash}{2a82c8d1682e6420bc106eda3c260f4a}
|
||||||
|
\strng{authorfullhash}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\strng{authorfullhashraw}{e491ba8946abeda3781fca22adabf046}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{Computer Animation and Virtual Worlds}
|
||||||
|
\field{number}{6}
|
||||||
|
\field{title}{High‐performance virtual globe GPU terrain rendering using game engine}
|
||||||
|
\field{volume}{33}
|
||||||
|
\field{year}{2022}
|
||||||
|
\field{pages}{e2108}
|
||||||
|
\range{pages}{-1}
|
||||||
|
\endentry
|
||||||
|
\entry{firat2022sound}{article}{}{}
|
||||||
|
\name{author}{3}{}{%
|
||||||
|
{{hash=c9e495ed8623ce96d21b9969aa823925}{%
|
||||||
|
family={Fırat},
|
||||||
|
familyi={F\bibinitperiod},
|
||||||
|
given={H.\bibnamedelimi B.},
|
||||||
|
giveni={H\bibinitperiod\bibinitdelim B\bibinitperiod}}}%
|
||||||
|
{{hash=cc3c7e5e275028f7593ed4b7ca49b150}{%
|
||||||
|
family={Maffei},
|
||||||
|
familyi={M\bibinitperiod},
|
||||||
|
given={L.},
|
||||||
|
giveni={L\bibinitperiod}}}%
|
||||||
|
{{hash=d191e5ae3c7c37e252d8d7729392e74e}{%
|
||||||
|
family={Masullo},
|
||||||
|
familyi={M\bibinitperiod},
|
||||||
|
given={M.},
|
||||||
|
giveni={M\bibinitperiod}}}%
|
||||||
|
}
|
||||||
|
\strng{namehash}{1a1e0a285c57a8a033df531bb049db02}
|
||||||
|
\strng{fullhash}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\strng{fullhashraw}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\strng{bibnamehash}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\strng{authorbibnamehash}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\strng{authornamehash}{1a1e0a285c57a8a033df531bb049db02}
|
||||||
|
\strng{authorfullhash}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\strng{authorfullhashraw}{3be6cde84306e0627824f7940343f1a6}
|
||||||
|
\field{sortinit}{1}
|
||||||
|
\field{sortinithash}{4f6aaa89bab872aa0999fec09ff8e98a}
|
||||||
|
\field{labelnamesource}{author}
|
||||||
|
\field{labeltitlesource}{title}
|
||||||
|
\field{journaltitle}{Virtual Reality}
|
||||||
|
\field{number}{3}
|
||||||
|
\field{title}{3D sound spatialization with game engines: the virtual acoustics performance of a game engine and a middleware for interactive audio design}
|
||||||
|
\field{volume}{26}
|
||||||
|
\field{year}{2022}
|
||||||
|
\field{pages}{1181\bibrangedash 1195}
|
||||||
|
\range{pages}{15}
|
||||||
|
\endentry
|
||||||
|
\enddatalist
|
||||||
|
\endrefsection
|
||||||
|
\endinput
|
||||||
|
|
||||||
2413
latex/main.bcf-SAVE-ERROR
Normal file
2413
latex/main.bcf-SAVE-ERROR
Normal file
File diff suppressed because it is too large
Load Diff
BIN
latex/main.pdf
BIN
latex/main.pdf
Binary file not shown.
@ -83,6 +83,9 @@
|
|||||||
\input{tex/2-przeglad-literatury} % Przegląd literatury i istniejących rozwiązań
|
\input{tex/2-przeglad-literatury} % Przegląd literatury i istniejących rozwiązań
|
||||||
\input{tex/3-silniki-gier} % Charakterystyka współczesnych silników gier
|
\input{tex/3-silniki-gier} % Charakterystyka współczesnych silników gier
|
||||||
\input{tex/4-metodologia} % Metodologia badań i kryteria porównania
|
\input{tex/4-metodologia} % Metodologia badań i kryteria porównania
|
||||||
|
\input{tex/wywiady-analiza} % Analiza wywiadów z deweloperami gier
|
||||||
|
\input{tex/implementacja-gry} % Doświadczenia z implementacji gry testowej
|
||||||
|
\input{tex/narzedzia-profilowania} % Narzędzia profilowania wydajności
|
||||||
\input{tex/5-testy-wydajnosci} % Testy wydajności
|
\input{tex/5-testy-wydajnosci} % Testy wydajności
|
||||||
\input{tex/6-analiza-mozliwosci} % Analiza możliwości i funkcjonalności
|
\input{tex/6-analiza-mozliwosci} % Analiza możliwości i funkcjonalności
|
||||||
\input{tex/7-porownanie-wynikow} % Porównanie wyników i analiza
|
\input{tex/7-porownanie-wynikow} % Porównanie wyników i analiza
|
||||||
@ -92,7 +95,10 @@
|
|||||||
% Bibliografia
|
% Bibliografia
|
||||||
%---------------
|
%---------------
|
||||||
\cleardoublepage % Zaczynamy od nieparzystej strony
|
\cleardoublepage % Zaczynamy od nieparzystej strony
|
||||||
|
\begingroup
|
||||||
|
\emergencystretch=1em
|
||||||
\printbibliography
|
\printbibliography
|
||||||
|
\endgroup
|
||||||
\clearpage
|
\clearpage
|
||||||
|
|
||||||
% Wykaz symboli i skrótów.
|
% Wykaz symboli i skrótów.
|
||||||
|
|||||||
@ -54,7 +54,27 @@
|
|||||||
\RequirePackage{array} % Advanced table column formats
|
\RequirePackage{array} % Advanced table column formats
|
||||||
\RequirePackage{enumitem} % Itemize/enumrate
|
\RequirePackage{enumitem} % Itemize/enumrate
|
||||||
\RequirePackage{fancyhdr} % Custom header/footer styles
|
\RequirePackage{fancyhdr} % Custom header/footer styles
|
||||||
\RequirePackage{fourier} % Adobe Utopia font
|
% Conditional font loading based on engine
|
||||||
|
\RequirePackage{iftex}
|
||||||
|
\ifxetex
|
||||||
|
\RequirePackage{fontspec}
|
||||||
|
\defaultfontfeatures{Ligatures=TeX}
|
||||||
|
% Use DejaVu fonts - widely available with full Polish character support
|
||||||
|
\setmainfont{DejaVu Serif}
|
||||||
|
\setsansfont{DejaVu Sans}
|
||||||
|
\setmonofont{DejaVu Sans Mono}
|
||||||
|
\else\ifluatex
|
||||||
|
\RequirePackage{fontspec}
|
||||||
|
\defaultfontfeatures{Ligatures=TeX}
|
||||||
|
\setmainfont{DejaVu Serif}
|
||||||
|
\setsansfont{DejaVu Sans}
|
||||||
|
\setmonofont{DejaVu Sans Mono}
|
||||||
|
\else
|
||||||
|
% pdfLaTeX - use Fourier (Utopia) font with proper Polish support
|
||||||
|
\RequirePackage[utf8]{inputenc}
|
||||||
|
\RequirePackage[T1]{fontenc}
|
||||||
|
\RequirePackage{fourier}
|
||||||
|
\fi\fi
|
||||||
\RequirePackage{graphicx} % Enhanced images support
|
\RequirePackage{graphicx} % Enhanced images support
|
||||||
\RequirePackage{ifluatex} % LuaTeX-specific options
|
\RequirePackage{ifluatex} % LuaTeX-specific options
|
||||||
\RequirePackage{kantlipsum} % English kantian-style lipsum
|
\RequirePackage{kantlipsum} % English kantian-style lipsum
|
||||||
@ -107,10 +127,12 @@
|
|||||||
urlcolor=black
|
urlcolor=black
|
||||||
}
|
}
|
||||||
% Advanced interword spacing
|
% Advanced interword spacing
|
||||||
\RequirePackage[
|
% Microtype - disable expansion for XeTeX (not supported)
|
||||||
protrusion=true,
|
\ifxetex
|
||||||
expansion=true
|
\RequirePackage[protrusion=true]{microtype}
|
||||||
]{microtype}
|
\else
|
||||||
|
\RequirePackage[protrusion=true,expansion=true]{microtype}
|
||||||
|
\fi
|
||||||
|
|
||||||
%-----------------------
|
%-----------------------
|
||||||
% LuaTeX specific code
|
% LuaTeX specific code
|
||||||
|
|||||||
85
latex/tex/1-wstep-old.tex
Normal file
85
latex/tex/1-wstep-old.tex
Normal file
@ -0,0 +1,85 @@
|
|||||||
|
\clearpage % Rozdziały zaczynamy od nowej strony.
|
||||||
|
\section{Wstęp}
|
||||||
|
|
||||||
|
\subsection{Motywacja i cel pracy}
|
||||||
|
Współczesny rynek gier komputerowych charakteryzuje się dynamicznym rozwojem technologicznym i rosnącymi wymaganiami zarówno twórców, jak i graczy. Wybór odpowiedniego silnika gier jest kluczową decyzją, która wpływa na cały proces tworzenia gry, jej wydajność oraz możliwości techniczne.
|
||||||
|
|
||||||
|
Celem niniejszej pracy jest kompleksowe porównanie wydajności i możliwości współczesnych silników gier komputerowych, ze szczególnym uwzględnieniem ich wpływu na proces tworzenia gier oraz końcową jakość produktu.
|
||||||
|
|
||||||
|
\subsection{Zakres pracy}
|
||||||
|
Praca obejmuje analizę następujących aspektów:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Wydajność renderowania grafiki 2D i 3D
|
||||||
|
\item Możliwości i funkcjonalności oferowane przez różne silniki
|
||||||
|
\item Łatwość użycia i krzywa uczenia się
|
||||||
|
\item Wsparcie dla różnych platform docelowych
|
||||||
|
\item Ekosystem narzędzi i społeczność deweloperska
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Struktura pracy}
|
||||||
|
Praca składa się z następujących rozdziałów:
|
||||||
|
% TODO: Dodać opis struktury po ukończeniu wszystkich rozdziałów
|
||||||
|
|
||||||
|
\subsection{Metodologia}
|
||||||
|
W pracy zastosowano metodologię badawczą opartą na analizie porównawczej, testach wydajnościowych oraz studium przypadków rzeczywistych projektów implementowanych w różnych silnikach gier.
|
||||||
|
|
||||||
|
% Placeholder content removed - add actual introduction content here
|
||||||
|
|
||||||
|
% Lista punktowana
|
||||||
|
% Parametr label ustawia symbol punktora
|
||||||
|
\begin{itemize}
|
||||||
|
\item Item 1:
|
||||||
|
\begin{itemize}[label=---]
|
||||||
|
\item item 1.1;
|
||||||
|
\item item 1.2;
|
||||||
|
\end{itemize}
|
||||||
|
\item Item 2;
|
||||||
|
\item Item 3.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\lipsum[3]
|
||||||
|
|
||||||
|
% Lista numerowana w formacie 1.a).ii
|
||||||
|
% Tutaj również można stosować \label
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Item 1:
|
||||||
|
\begin{enumerate}
|
||||||
|
\item item 1.1;
|
||||||
|
\item item 1.2:
|
||||||
|
\begin{enumerate}
|
||||||
|
\item item 1.2.1;
|
||||||
|
\item item 1.2.2;
|
||||||
|
\end{enumerate}
|
||||||
|
\item item 1.3;
|
||||||
|
\end{enumerate}
|
||||||
|
\item Item 2;
|
||||||
|
\item Item 3.
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
% Przypis dolny \footnote
|
||||||
|
\lipsum[4] Lorem ipsum dolor sit amet\footnote{Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.}, consectetur adipiscing elit.
|
||||||
|
|
||||||
|
% Przykładowa tabela: wyśrodkowana i renderowana
|
||||||
|
% w miejscu wstawienia: !h = !h[ere]
|
||||||
|
% Domyślnie tabele trafiają na górę strony
|
||||||
|
\begin{table}[!h] \centering
|
||||||
|
% Podpis tabeli umieszczamy od góry
|
||||||
|
\caption{Przykładowa tabela.}
|
||||||
|
\label{tab:tabela1}
|
||||||
|
|
||||||
|
% Tabela z trzema kolumnami:
|
||||||
|
% dwie wyrównanie do środka [c], a ostatnia do prawej [r]
|
||||||
|
% szerokość kolumn automatyczna (równa szerokości tekstu)
|
||||||
|
\begin{tabular}{| c | c | r |} \hline
|
||||||
|
Kolumna 1 & Kolumna 2 & Liczba \\ \hline\hline
|
||||||
|
cell1 & cell2 & 60 \\ \hline
|
||||||
|
cell4 & cell5 & 43 \\ \hline
|
||||||
|
cell7 & cell8 & 20,45 \\ \hline
|
||||||
|
% Komórka o szerokości dwóch kolumn, wyrównana do prawej
|
||||||
|
% Przypisy dolne w tabelach wstawiamy przez \tablefootnote
|
||||||
|
\multicolumn{2}{|r|}{Suma\tablefootnote{Table footnote.}} & 123,45 \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
Lorem ipsum dolor sit amet.
|
||||||
@ -2,85 +2,101 @@
|
|||||||
\section{Wstęp}
|
\section{Wstęp}
|
||||||
|
|
||||||
\subsection{Motywacja i cel pracy}
|
\subsection{Motywacja i cel pracy}
|
||||||
Współczesny rynek gier komputerowych charakteryzuje się dynamicznym rozwojem technologicznym i rosnącymi wymaganiami zarówno twórców, jak i graczy. Wybór odpowiedniego silnika gier jest kluczową decyzją, która wpływa na cały proces tworzenia gry, jej wydajność oraz możliwości techniczne.
|
Współczesny rynek gier komputerowych charakteryzuje się dynamicznym rozwojem technologicznym i~rosnącymi wymaganiami zarówno twórców, jak i~graczy. Wybór odpowiedniego silnika gier jest kluczową decyzją, która wpływa na cały proces tworzenia gry, jej wydajność oraz możliwości techniczne.
|
||||||
|
|
||||||
Celem niniejszej pracy jest kompleksowe porównanie wydajności i możliwości współczesnych silników gier komputerowych, ze szczególnym uwzględnieniem ich wpływu na proces tworzenia gier oraz końcową jakość produktu.
|
Celem niniejszej pracy jest kompleksowe porównanie wydajności i~możliwości współczesnych silników gier komputerowych, ze szczególnym uwzględnieniem ich wpływu na proces tworzenia gier oraz końcową jakość produktu.
|
||||||
|
|
||||||
\subsection{Zakres pracy}
|
\subsection{Zakres pracy}
|
||||||
Praca obejmuje analizę następujących aspektów:
|
Praca obejmuje analizę następujących aspektów:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Wydajność renderowania grafiki 2D i 3D
|
\item Wydajność renderowania grafiki 2D i~3D
|
||||||
\item Możliwości i funkcjonalności oferowane przez różne silniki
|
\item Możliwości i~funkcjonalności oferowane przez różne silniki
|
||||||
\item Łatwość użycia i krzywa uczenia się
|
\item Łatwość użycia i~krzywa uczenia się
|
||||||
\item Wsparcie dla różnych platform docelowych
|
\item Wsparcie dla różnych platform docelowych
|
||||||
\item Ekosystem narzędzi i społeczność deweloperska
|
\item Ekosystem narzędzi i~społeczność deweloperska
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\subsection{Struktura pracy}
|
\subsection{Wybór gry testowej -- gatunek bullet hell}
|
||||||
Praca składa się z następujących rozdziałów:
|
\label{subsec:bullet-hell}
|
||||||
% TODO: Dodać opis struktury po ukończeniu wszystkich rozdziałów
|
|
||||||
|
|
||||||
\subsection{Metodologia}
|
W~celu przeprowadzenia praktycznych testów wydajnościowych zdecydowano się na implementację gry z~gatunku \textbf{bullet hell} (dosł.~,,piekło pocisków''), znanego również jako \textbf{danmaku} (z~jap.~,,kurtyna pocisków'') lub \textbf{manic shooter}.
|
||||||
W pracy zastosowano metodologię badawczą opartą na analizie porównawczej, testach wydajnościowych oraz studium przypadków rzeczywistych projektów implementowanych w różnych silnikach gier.
|
|
||||||
|
|
||||||
% \ref wyrenderuje się jako 'Reference to image 1.1'
|
\subsubsection{Charakterystyka gatunku}
|
||||||
\lipsum[2] Reference to image \ref{fig:tradycyjne-logo-pw}.
|
|
||||||
|
Bullet hell to podgatunek gier typu shoot 'em up (strzelanka), w~którym gracz steruje zwykle niewielkim statkiem kosmicznym lub postacią, mierząc się z~falami przeciwników wystrzeliwujących ogromne ilości pocisków tworzących skomplikowane wzory na ekranie. Kluczowe cechy gatunku obejmują:
|
||||||
|
|
||||||
% Lista punktowana
|
|
||||||
% Parametr label ustawia symbol punktora
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Item 1:
|
\item \textbf{Masowa ilość pocisków} -- na ekranie jednocześnie może znajdować się od kilkuset do kilku tysięcy pocisków, tworzących złożone formacje geometryczne
|
||||||
\begin{itemize}[label=---]
|
\item \textbf{Precyzyjne hitboxy} -- obszar kolizji postaci gracza jest znacznie mniejszy niż jej wizualna reprezentacja (często ograniczony do kilku pikseli), co umożliwia nawigację między gęstymi wzorami pocisków
|
||||||
\item item 1.1;
|
\item \textbf{Wzory pocisków} -- przeciwnicy wystrzeliwują pociski według określonych algorytmów, tworząc spirale, fale, rozgałęzienia i~inne formacje
|
||||||
\item item 1.2;
|
\item \textbf{Ciągły ruch} -- gracz musi nieustannie przemieszczać się po ekranie, unikając kolizji
|
||||||
\end{itemize}
|
\item \textbf{Eskalacja trudności} -- wraz z~postępem gry wzrasta liczba przeciwników i~gęstość pocisków
|
||||||
\item Item 2;
|
|
||||||
\item Item 3.
|
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\lipsum[3]
|
Klasyczne przykłady gatunku to serie \textit{Touhou Project}, \textit{DoDonPachi}, \textit{Ikaruga} oraz \textit{Geometry Wars}.
|
||||||
|
|
||||||
|
\subsubsection{Uzasadnienie wyboru gatunku}
|
||||||
|
|
||||||
|
Gatunek bullet hell został wybrany jako podstawa testów wydajnościowych z~następujących powodów:
|
||||||
|
|
||||||
% Lista numerowana w formacie 1.a).ii
|
|
||||||
% Tutaj również można stosować \label
|
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
\item Item 1:
|
\item \textbf{Intensywne wykorzystanie zasobów} -- jednoczesne renderowanie setek lub tysięcy obiektów (pocisków) stanowi znaczące obciążenie dla systemu renderowania
|
||||||
\begin{enumerate}
|
|
||||||
\item item 1.1;
|
\item \textbf{Testowanie zarządzania pamięcią} -- ciągłe tworzenie i~niszczenie obiektów pocisków eksponuje różnice w~implementacji garbage collectora (Unity/C\#) versus ręcznego zarządzania pamięcią (Unreal/C++)
|
||||||
\item item 1.2:
|
|
||||||
\begin{enumerate}
|
\item \textbf{Wymagania systemu fizyki} -- wykrywanie kolizji między graczem a~setkami pocisków w~każdej klatce obciąża system fizyki
|
||||||
\item item 1.2.1;
|
|
||||||
\item item 1.2.2;
|
\item \textbf{Prostota implementacji} -- podstawowa mechanika gry jest stosunkowo prosta koncepcyjnie, co pozwala skupić się na porównaniu wydajności, a~nie złożoności logiki gry
|
||||||
\end{enumerate}
|
|
||||||
\item item 1.3;
|
\item \textbf{Skalowalność testu} -- łatwo kontrolować poziom obciążenia poprzez modyfikację liczby aktywnych pocisków i~przeciwników
|
||||||
\end{enumerate}
|
|
||||||
\item Item 2;
|
\item \textbf{Reprezentatywność dla gier 2D} -- gatunek jest typowym przedstawicielem gier 2D, co pozwala ocenić wsparcie silników dla tego segmentu rynku
|
||||||
\item Item 3.
|
|
||||||
|
\item \textbf{Wymuszenie optymalizacji} -- ze względu na ekstremalną liczbę obiektów, implementacja bullet hell wymusza stosowanie technik optymalizacyjnych (object pooling, spatial partitioning), których efektywność może różnić się między silnikami
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
|
|
||||||
% Przypis dolny \footnote
|
\subsubsection{Parametry gry testowej}
|
||||||
\lipsum[4] Lorem ipsum dolor sit amet\footnote{Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.}, consectetur adipiscing elit.
|
|
||||||
|
|
||||||
% Przykładowa tabela: wyśrodkowana i renderowana
|
Zaimplementowana gra testowa charakteryzuje się następującymi parametrami:
|
||||||
% w miejscu wstawienia: !h = !h[ere]
|
|
||||||
% Domyślnie tabele trafiają na górę strony
|
|
||||||
\begin{table}[!h] \centering
|
|
||||||
% Podpis tabeli umieszczamy od góry
|
|
||||||
\caption{Przykładowa tabela.}
|
|
||||||
\label{tab:tabela1}
|
|
||||||
|
|
||||||
% Tabela z trzema kolumnami:
|
\begin{itemize}
|
||||||
% dwie wyrównanie do środka [c], a ostatnia do prawej [r]
|
\item Czas rozgrywki: 90 sekund (tryb przetrwania)
|
||||||
% szerokość kolumn automatyczna (równa szerokości tekstu)
|
\item Eskalacja trudności: liniowy wzrost częstotliwości spawnu przeciwników
|
||||||
\begin{tabular}{| c | c | r |} \hline
|
\item Typy przeciwników: 3 warianty z~różnymi wzorami strzelania
|
||||||
Kolumna 1 & Kolumna 2 & Liczba \\ \hline\hline
|
\item Maksymalna liczba jednoczesnych pocisków: do 500 obiektów
|
||||||
cell1 & cell2 & 60 \\ \hline
|
\item System punktacji oparty na eliminacji przeciwników
|
||||||
cell4 & cell5 & 43 \\ \hline
|
\item Object pooling dla pocisków (eliminacja alokacji w~runtime)
|
||||||
cell7 & cell8 & 20,45 \\ \hline
|
\end{itemize}
|
||||||
% Komórka o szerokości dwóch kolumn, wyrównana do prawej
|
|
||||||
% Przypisy dolne w tabelach wstawiamy przez \tablefootnote
|
|
||||||
\multicolumn{2}{|r|}{Suma\tablefootnote{Table footnote.}} & 123,45 \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
|
|
||||||
\end{table}
|
Te parametry zapewniają wystarczające obciążenie systemu do ujawnienia różnic wydajnościowych między silnikami, pozostając jednocześnie w~granicach typowych dla gier indie z~tego gatunku.
|
||||||
|
|
||||||
Lorem ipsum dolor sit amet.
|
\subsection{Struktura pracy}
|
||||||
|
|
||||||
|
Praca składa się z~następujących rozdziałów:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Wstęp} -- wprowadzenie do tematyki, motywacja, cel i~zakres pracy
|
||||||
|
\item \textbf{Przegląd literatury} -- analiza istniejących badań porównawczych silników gier
|
||||||
|
\item \textbf{Charakterystyka silników} -- szczegółowy opis Unity i~Unreal Engine
|
||||||
|
\item \textbf{Metodologia} -- opis metodyki badawczej i~kryteriów porównania
|
||||||
|
\item \textbf{Analiza wywiadów} -- wyniki badań jakościowych z~deweloperami
|
||||||
|
\item \textbf{Implementacja gry testowej} -- doświadczenia z~tworzenia gry w~obu silnikach
|
||||||
|
\item \textbf{Narzędzia profilowania} -- opis NVIDIA Nsight i~metodyki pomiarów
|
||||||
|
\item \textbf{Testy wydajności} -- wyniki pomiarów wydajnościowych
|
||||||
|
\item \textbf{Analiza możliwości} -- porównanie funkcjonalności silników
|
||||||
|
\item \textbf{Porównanie wyników} -- synteza i~analiza zebranych danych
|
||||||
|
\item \textbf{Podsumowanie} -- wnioski i~rekomendacje
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\subsection{Metodologia}
|
||||||
|
|
||||||
|
W~pracy zastosowano metodologię badawczą łączącą podejście ilościowe z~jakościowym:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Testy wydajnościowe} -- obiektywne pomiary z~wykorzystaniem NVIDIA Nsight Graphics, zapewniające porównywalność wyników między silnikami
|
||||||
|
\item \textbf{Wywiady z~deweloperami} -- badania jakościowe dostarczające kontekstu praktycznego użytkowania silników
|
||||||
|
\item \textbf{Implementacja porównawcza} -- stworzenie identycznej gry w~obu silnikach, dokumentując różnice w~procesie deweloperskim
|
||||||
|
\item \textbf{Analiza dokumentacji} -- przegląd oficjalnej dokumentacji i~materiałów edukacyjnych
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Takie wieloaspektowe podejście pozwala na kompleksową ocenę silników, uwzględniającą zarówno mierzalne parametry techniczne, jak i~subiektywne doświadczenia użytkowników.
|
||||||
|
|||||||
@ -2,46 +2,141 @@
|
|||||||
\section{Charakterystyka współczesnych silników gier}
|
\section{Charakterystyka współczesnych silników gier}
|
||||||
|
|
||||||
\subsection{Kryteria wyboru silników do analizy}
|
\subsection{Kryteria wyboru silników do analizy}
|
||||||
W ramach niniejszej pracy wybrano reprezentatywne silniki gier reprezentujące różne segmenty rynku:
|
|
||||||
|
Rynek silników gier komputerowych oferuje szeroki wachlarz rozwiązań, od prostych frameworków 2D po zaawansowane środowiska do tworzenia fotorealistycznych produkcji AAA. W ramach niniejszej pracy zdecydowano się na dogłębną analizę dwóch silników: \textbf{Unity} oraz \textbf{Unreal Engine}. Wybór ten podyktowany był kilkoma kluczowymi czynnikami:
|
||||||
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Popularność i rozpowszechnienie
|
\item \textbf{Dominacja rynkowa} -- według danych z~2024 roku, Unity i~Unreal Engine wspólnie obsługują ponad 70\% globalnego rynku gier komputerowych i~mobilnych
|
||||||
\item Różnorodność technologiczna
|
\item \textbf{Reprezentatywność podejść architektonicznych} -- silniki reprezentują odmienne filozofie: Unity opiera się na języku C\# z~garbage collectorem, a~Unreal wykorzystuje natywny C++ z~ręcznym zarządzaniem pamięcią
|
||||||
\item Wsparcie dla różnych platform
|
\item \textbf{Różnorodność zastosowań} -- Unity tradycyjnie dominuje w segmencie gier mobilnych i indie, natomiast Unreal jest preferowany w produkcjach AAA i projektach wymagających fotorealistycznej grafiki
|
||||||
\item Dostępność dokumentacji i narzędzi
|
\item \textbf{Dostępność} -- oba silniki oferują darmowe wersje dla małych zespołów i projektów edukacyjnych, co czyni je dostępnymi dla szerokiego grona deweloperów
|
||||||
|
\item \textbf{Bogata dokumentacja} -- zarówno Unity jak i Unreal dysponują rozbudowaną dokumentacją oficjalną oraz aktywnymi społecznościami
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\subsection{Unity}
|
\subsection{Unity}
|
||||||
\subsubsection{Architektura i technologie}
|
\label{subsec:unity}
|
||||||
% Opis architektury silnika Unity, stosowanych technologii
|
|
||||||
|
\subsubsection{Wprowadzenie i historia}
|
||||||
|
|
||||||
|
Unity to wieloplatformowy silnik gier stworzony przez Unity Technologies, którego pierwsza wersja została wydana w 2005 roku jako ekskluzywne narzędzie dla systemu macOS. Od tego czasu silnik przeszedł znaczącą ewolucję, stając się jednym z najpopularniejszych rozwiązań do tworzenia gier na świecie.
|
||||||
|
|
||||||
|
Kluczowym momentem w historii Unity było wprowadzenie w 2010 roku darmowej wersji silnika (Unity Free), co znacząco obniżyło barierę wejścia dla początkujących deweloperów i małych studiów. Decyzja ta przyczyniła się do eksplozji popularności silnika w segmencie gier mobilnych oraz indie.
|
||||||
|
|
||||||
|
Unity wykorzystuje język programowania \textbf{C\#} działający na platformie .NET/Mono, co zapewnia:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Automatyczne zarządzanie pamięcią poprzez garbage collector
|
||||||
|
\item Bezpieczeństwo typów i obsługę wyjątków
|
||||||
|
\item Bogatą bibliotekę standardową
|
||||||
|
\item Stosunkowo łagodną krzywą uczenia dla programistów znających Javę lub podobne języki
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Architektura Unity opiera się na wzorcu \textit{GameObject-Component}, gdzie każdy obiekt w scenie (GameObject) może posiadać dowolną liczbę komponentów definiujących jego zachowanie. Podejście to promuje kompozycję nad dziedziczeniem i ułatwia tworzenie modularnego kodu.
|
||||||
|
|
||||||
\subsubsection{Możliwości i funkcjonalności}
|
\subsubsection{Możliwości i funkcjonalności}
|
||||||
% Szczegółowy opis oferowanych funkcji
|
|
||||||
|
Unity oferuje kompleksowy zestaw narzędzi do tworzenia gier 2D i 3D:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Rendering} -- wsparcie dla wielu pipeline'ów renderowania: Built-in, Universal Render Pipeline (URP) dla platform mobilnych oraz High Definition Render Pipeline (HDRP) dla wysokiej jakości grafiki
|
||||||
|
\item \textbf{Fizyka} -- integracja z silnikami PhysX (3D) i Box2D (2D)
|
||||||
|
\item \textbf{Animacja} -- system Mecanim z obsługą maszyn stanów i blendingu animacji
|
||||||
|
\item \textbf{Audio} -- wbudowany system dźwięku przestrzennego
|
||||||
|
\item \textbf{UI} -- dwa systemy interfejsu użytkownika: legacy uGUI oraz nowoczesny UI Toolkit
|
||||||
|
\item \textbf{Multiplayer} -- Netcode for GameObjects oraz integracja z usługami sieciowymi
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\subsubsection{Narzędzia deweloperskie}
|
\subsubsection{Narzędzia deweloperskie}
|
||||||
% Edytor, debugger, profiler, etc.
|
|
||||||
|
Edytor Unity zapewnia intuicyjny interfejs graficzny z następującymi funkcjonalnościami:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Hierarchiczny widok sceny z możliwością edycji w czasie rzeczywistym
|
||||||
|
\item Inspektor właściwości z obsługą serializacji pól poprzez atrybut \texttt{[SerializeField]}
|
||||||
|
\item Wbudowany profiler wydajności (CPU, GPU, pamięć)
|
||||||
|
\item Asset Store -- marketplace z gotowymi zasobami i rozszerzeniami
|
||||||
|
\item Obsługa hot reload -- możliwość edycji kodu podczas działania gry
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\subsection{Unreal Engine}
|
\subsection{Unreal Engine}
|
||||||
\subsubsection{Architektura i technologie}
|
\label{subsec:unreal}
|
||||||
% Opis architektury Unreal Engine
|
|
||||||
|
\subsubsection{Wprowadzenie i historia}
|
||||||
|
|
||||||
|
Unreal Engine to silnik gier stworzony przez Epic Games, którego historia sięga 1998 roku, kiedy to zadebiutował wraz z grą \textit{Unreal}. Od początku silnik był projektowany z myślą o tworzeniu gier pierwszoosobowych (FPS) o wysokiej jakości graficznej, co nadal pozostaje jego mocną stroną.
|
||||||
|
|
||||||
|
Przełomowym momentem było wydanie Unreal Engine 4 w 2014 roku na licencji royalty-free (5\% od przychodów powyżej \$1 miliona), a następnie Unreal Engine 5 w 2022 roku, wprowadzającego rewolucyjne technologie takie jak Nanite (wirtualizowana geometria) i Lumen (globalne oświetlenie w czasie rzeczywistym).
|
||||||
|
|
||||||
|
Unreal Engine wykorzystuje język programowania \textbf{C++} z rozszerzeniami specyficznymi dla silnika (makra UE), co zapewnia:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Maksymalną wydajność dzięki kompilacji do kodu natywnego
|
||||||
|
\item Pełną kontrolę nad zarządzaniem pamięcią
|
||||||
|
\item Dostęp do kodu źródłowego silnika (po uzyskaniu licencji)
|
||||||
|
\item Strome krzywe uczenia, szczególnie dla programistów bez doświadczenia w C++
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Dodatkowo Unreal oferuje system \textbf{Blueprints} -- wizualny język skryptowy pozwalający na tworzenie logiki gry bez pisania kodu. Blueprinty są szczególnie przydatne dla designerów i artystów, choć dla złożonych systemów mogą być mniej wydajne niż natywny C++.
|
||||||
|
|
||||||
\subsubsection{Możliwości i funkcjonalności}
|
\subsubsection{Możliwości i funkcjonalności}
|
||||||
% Blueprint system, C++ support, rendering pipeline
|
|
||||||
|
Unreal Engine wyróżnia się zaawansowanymi możliwościami graficznymi:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Rendering} -- fotorealistyczna grafika z obsługą ray tracingu, Nanite i Lumen
|
||||||
|
\item \textbf{Fizyka} -- silnik Chaos Physics z obsługą destrukcji i symulacji ciał miękkich
|
||||||
|
\item \textbf{Animacja} -- Control Rig, Animation Blueprints, IK Retargeting
|
||||||
|
\item \textbf{Landscape} -- zaawansowane narzędzia do tworzenia dużych terenów
|
||||||
|
\item \textbf{Niagara} -- system efektów cząsteczkowych nowej generacji
|
||||||
|
\item \textbf{Sequencer} -- narzędzie do tworzenia cinematików i cutscen
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\subsubsection{Narzędzia deweloperskie}
|
\subsubsection{Narzędzia deweloperskie}
|
||||||
% Unreal Editor, Visual Scripting, etc.
|
|
||||||
|
|
||||||
\subsection{Godot}
|
Unreal Editor oferuje rozbudowane środowisko deweloperskie:
|
||||||
\subsubsection{Architektura i technologie}
|
\begin{itemize}
|
||||||
% Opis architektury silnika Godot
|
\item Edytor poziomów z obsługą streamingu i Level of Detail (LOD)
|
||||||
|
\item Blueprint Visual Scripting -- programowanie wizualne
|
||||||
|
\item Material Editor -- węzłowy edytor materiałów
|
||||||
|
\item Wbudowany profiler z analizą GPU/CPU i pamięci
|
||||||
|
\item Marketplace -- sklep z zasobami i pluginami
|
||||||
|
\item Live Coding -- eksperymentalne wsparcie dla hot reload w C++
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
\subsubsection{Możliwości i funkcjonalności}
|
\subsection{Porównanie architektoniczne}
|
||||||
% GDScript, scene system, node-based architecture
|
|
||||||
|
|
||||||
\subsubsection{Narzędzia deweloperskie}
|
\begin{table}[ht]
|
||||||
% Integrated editor, scripting tools
|
\centering
|
||||||
|
\caption{Porównanie kluczowych cech Unity i Unreal Engine}
|
||||||
|
\label{tab:unity-vs-unreal}
|
||||||
|
\begin{tabular}{|l|c|c|}
|
||||||
|
\hline
|
||||||
|
\textbf{Cecha} & \textbf{Unity} & \textbf{Unreal Engine} \\
|
||||||
|
\hline
|
||||||
|
Język programowania & C\# & C++ / Blueprints \\
|
||||||
|
\hline
|
||||||
|
Zarządzanie pamięcią & Automatyczne (GC) & Ręczne / Smart pointers \\
|
||||||
|
\hline
|
||||||
|
Architektura & GameObject-Component & Actor-Component \\
|
||||||
|
\hline
|
||||||
|
Natywne wsparcie 2D & Tak & Nie (symulowane) \\
|
||||||
|
\hline
|
||||||
|
Kod źródłowy & Częściowo dostępny & Pełny dostęp \\
|
||||||
|
\hline
|
||||||
|
Rozmiar pustego projektu & $\sim$100 MB & $\sim$1-2 GB \\
|
||||||
|
\hline
|
||||||
|
Krzywa uczenia & Łagodna & Stroma \\
|
||||||
|
\hline
|
||||||
|
Główne zastosowania & Mobile, indie, 2D & AAA, FPS, fotorealizm \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
\subsection{Inne analizowane silniki}
|
\subsection{Uzasadnienie wyboru do badań}
|
||||||
% Krótka charakterystyka dodatkowych silników (np. CryEngine, GameMaker Studio)
|
|
||||||
|
|
||||||
\subsection{Porównanie tabelaryczne podstawowych cech}
|
Wybór Unity i Unreal Engine jako przedmiotu porównania pozwala na analizę dwóch fundamentalnie różnych podejść do tworzenia gier:
|
||||||
% Tabela porównawcza kluczowych parametrów
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Produktywność vs wydajność} -- C\# w Unity oferuje szybszy rozwój kosztem pewnego narzutu wydajnościowego, podczas gdy C++ w Unreal wymaga więcej pracy, ale zapewnia maksymalną kontrolę
|
||||||
|
\item \textbf{Dostępność vs specjalizacja} -- Unity celuje w szeroki rynek z niskim progiem wejścia, Unreal koncentruje się na produkcjach premium
|
||||||
|
\item \textbf{Elastyczność vs integracja} -- Unity pozwala na większą swobodę w doborze zewnętrznych narzędzi, Unreal oferuje bardziej zintegrowane rozwiązania
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Analiza tych dwóch silników dostarcza kompleksowego obrazu współczesnego stanu technologii do tworzenia gier i pozwala na sformułowanie praktycznych rekomendacji dla deweloperów.
|
||||||
|
|||||||
@ -1,5 +1,6 @@
|
|||||||
\clearpage
|
\clearpage
|
||||||
\section{Testy wydajności}
|
\section{Testy wydajności}
|
||||||
|
\label{sec:testy-wydajnosci}
|
||||||
|
|
||||||
\subsection{Metodyka przeprowadzania testów}
|
\subsection{Metodyka przeprowadzania testów}
|
||||||
\subsubsection{Przygotowanie środowiska testowego}
|
\subsubsection{Przygotowanie środowiska testowego}
|
||||||
|
|||||||
192
latex/tex/implementacja-gry.tex
Normal file
192
latex/tex/implementacja-gry.tex
Normal file
@ -0,0 +1,192 @@
|
|||||||
|
\clearpage
|
||||||
|
\section{Doświadczenia z implementacji gry testowej}
|
||||||
|
\label{sec:implementacja-gry}
|
||||||
|
|
||||||
|
W ramach praktycznej części badań zaimplementowano grę typu bullet-hell w obu porównywanych silnikach. Gatunek ten został wybrany ze względu na jego wymagania wydajnościowe -- jednoczesne renderowanie setek pocisków na ekranie stanowi doskonały test możliwości graficznych oraz efektywności zarządzania pamięcią przez silnik.
|
||||||
|
|
||||||
|
\subsection{Opis projektu testowego}
|
||||||
|
|
||||||
|
Zaimplementowana gra to klasyczny przedstawiciel gatunku bullet-hell, w~którym gracz steruje statkiem kosmicznym i~musi przetrwać przez określony czas (90~sekund), unikając pocisków wrogów i~eliminując przeciwników. Kluczowe mechaniki gry obejmują:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item System spawnu wrogów z eskalującą trudnością -- częstotliwość pojawiania się przeciwników wzrasta wraz z upływem czasu
|
||||||
|
\item System pocisków z object poolingiem -- optymalizacja pozwalająca na obsługę setek aktywnych pocisków
|
||||||
|
\item System zdrowia i kolizji dla gracza oraz przeciwników
|
||||||
|
\item Dynamiczne tło z efektem paralaksy
|
||||||
|
\item System punktacji i warunki zwycięstwa/porażki
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Implementacja w Unity}
|
||||||
|
\label{subsec:impl-unity}
|
||||||
|
|
||||||
|
\subsubsection{Środowisko i konfiguracja projektu}
|
||||||
|
|
||||||
|
Projekt Unity został utworzony w~wersji LTS z~wykorzystaniem standardowego renderera 2D. Instalacja silnika na systemie Linux przebiegła bezproblemowo dzięki Unity Hub, który zapewnia spójne zarządzanie wersjami edytora i~projektami.
|
||||||
|
|
||||||
|
Struktura projektu została zorganizowana według wzorca przestrzeni nazw, co pozwoliło na czytelną organizację kodu i~uniknięcie konfliktów nazw.
|
||||||
|
|
||||||
|
\subsubsection{Architektura systemu}
|
||||||
|
|
||||||
|
Implementacja Unity wykorzystuje kilka kluczowych wzorców projektowych:
|
||||||
|
|
||||||
|
\paragraph{Wzorzec Bootstrap}
|
||||||
|
Klasa \texttt{GameBootstrap} wykorzystuje atrybut \texttt{[Runtime\-Initialize\-OnLoad\-Method]} do zapewnienia, że obiekt \texttt{GameInitializer} istnieje w~scenie przed rozpoczęciem gry. Jest to eleganckie rozwiązanie problemu inicjalizacji singletonów w~Unity.
|
||||||
|
|
||||||
|
\paragraph{Object Pooling}
|
||||||
|
System \texttt{BulletPool} stanowi rdzeń optymalizacji wydajnościowej. Zamiast ciągłego tworzenia i niszczenia obiektów pocisków (co generowałoby znaczące obciążenie garbage collectora), pociski są recyklingowane z puli:
|
||||||
|
|
||||||
|
\begin{lstlisting}[language=C, caption={Fragment implementacji object poolingu w Unity}, label={lst:unity-pool}]
|
||||||
|
public Bullet Spawn(Vector2 position, Vector2 direction,
|
||||||
|
float speed, float damage)
|
||||||
|
{
|
||||||
|
Bullet bullet = _pool.Count > 0
|
||||||
|
? _pool.Dequeue()
|
||||||
|
: Bullet.Create(this, bulletColor, faction);
|
||||||
|
_liveBullets.Add(bullet);
|
||||||
|
bullet.gameObject.SetActive(true);
|
||||||
|
bullet.transform.position = position;
|
||||||
|
bullet.Configure(direction, speed, damage, faction);
|
||||||
|
return bullet;
|
||||||
|
}
|
||||||
|
\end{lstlisting}
|
||||||
|
|
||||||
|
Pula jest wstępnie rozgrzewana (\textit{warm capacity}) podczas inicjalizacji, co eliminuje alokacje podczas rozgrywki.
|
||||||
|
|
||||||
|
\paragraph{Singleton Pattern}
|
||||||
|
Klasy \texttt{GameDirector} i \texttt{EnemySpawner} wykorzystują wzorzec Singleton z właściwością \texttt{Instance}, zapewniając globalny punkt dostępu do kluczowych systemów gry.
|
||||||
|
|
||||||
|
\subsubsection{System spawnu przeciwników}
|
||||||
|
|
||||||
|
\texttt{EnemySpawner} implementuje system eskalującej trudności poprzez interpolację czasu między spawnami:
|
||||||
|
|
||||||
|
\begin{lstlisting}[language=C, caption={Interpolacja trudności w Unity}, label={lst:unity-difficulty}]
|
||||||
|
float t = _elapsed / totalDuration;
|
||||||
|
float delay = Mathf.Lerp(spawnDelayStart, spawnDelayEnd, t);
|
||||||
|
\end{lstlisting}
|
||||||
|
|
||||||
|
Przeciwnicy są definiowani przez strukturę \texttt{EnemyBlueprint}, która zawiera parametry takie jak prędkość, zdrowie, wzorce strzelania i zachowania. To podejście data-driven pozwala na łatwe tworzenie różnorodnych typów wrogów.
|
||||||
|
|
||||||
|
\subsubsection{Wyzwania napotkane w Unity}
|
||||||
|
|
||||||
|
Podczas implementacji napotkano następujące wyzwania:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Garbage Collection} -- początkowa implementacja bez object poolingu powodowała zauważalne spadki klatek przy dużej liczbie pocisków
|
||||||
|
\item \textbf{Kolejność inicjalizacji} -- konieczność użycia wzorca Bootstrap wynikała z~nieprzewidywalnej kolejności wywoływania metod \texttt{Awake()} i~\texttt{Start()}
|
||||||
|
\item \textbf{Serializacja} -- atrybuty \texttt{[SerializeField]} wymagały starannego rozplanowania, które pola powinny być edytowalne w~inspektorze
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\subsubsection{Pozytywne aspekty Unity}
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Natywne wsparcie dla 2D -- dedykowany tryb 2D z odpowiednimi komponentami fizyki (\texttt{Rigidbody2D}, \texttt{Collider2D})
|
||||||
|
\item Hot reload -- możliwość edycji kodu i natychmiastowego testowania zmian
|
||||||
|
\item Intuicyjny inspektor -- łatwa konfiguracja parametrów gry bez rekompilacji
|
||||||
|
\item Bogata dokumentacja C\# i społeczność
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Implementacja w Unreal Engine}
|
||||||
|
\label{subsec:impl-unreal}
|
||||||
|
|
||||||
|
\subsubsection{Środowisko i konfiguracja projektu}
|
||||||
|
|
||||||
|
Instalacja Unreal Engine na systemie Linux okazała się znacznie bardziej skomplikowana niż w przypadku Unity. Dostępne są dwie ścieżki:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Uzyskanie dostępu do oficjalnego repozytorium GitHub Epic Games i samodzielna kompilacja silnika ze źródeł
|
||||||
|
\item Pobranie prekompilowanej wersji binarnej
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Należy zauważyć, że Unreal Engine nie oferuje wersji LTS (Long Term Support), co może stanowić wyzwanie dla długoterminowych projektów.
|
||||||
|
|
||||||
|
\subsubsection{Podejście do grafiki 2D}
|
||||||
|
|
||||||
|
Fundamentalna różnica między Unity a~Unreal w~kontekście gier 2D polega na tym, że Unreal traktuje 2D jako ,,fałszywe 2D'' -- w~rzeczywistości jest to scena 3D z~zablokowaną trzecią osią i~kamerą ortograficzną. Unity natomiast oferuje dedykowany tryb 2D z~wyspecjalizowanymi komponentami.
|
||||||
|
|
||||||
|
Ta różnica ma praktyczne konsekwencje:
|
||||||
|
\begin{itemize}
|
||||||
|
\item W Unreal konieczne jest ręczne konfigurowanie kamery ortograficznej
|
||||||
|
\item Fizyka 2D w~Unreal wykorzystuje te same komponenty co 3D, z~ograniczeniami na odpowiednich osiach
|
||||||
|
\item Sprite'y w Unreal są renderowane jako płaskie meshe w przestrzeni 3D
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{System Blueprintów vs C++}
|
||||||
|
|
||||||
|
Unreal oferuje dwa podejścia do programowania logiki gry:
|
||||||
|
|
||||||
|
\paragraph{Blueprinty} -- wizualny system skryptowy, który pozwala na szybkie prototypowanie bez pisania kodu. Dla prostych mechanik bullet-hell Blueprinty okazały się wystarczające i intuicyjne.
|
||||||
|
|
||||||
|
\paragraph{C++} -- dla bardziej wydajnościowo krytycznych elementów (jak system object poolingu) zalecane jest użycie C++. Jednak próg wejścia jest znacznie wyższy niż w przypadku C\# w Unity.
|
||||||
|
|
||||||
|
\subsubsection{Object Pooling w Unreal}
|
||||||
|
|
||||||
|
Implementacja object poolingu w~Unreal wymaga innego podejścia niż w~Unity. Zamiast prostego \texttt{SetActive(true/\allowbreak false)}, Unreal wykorzystuje:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \texttt{SetActorHiddenInGame()} -- kontrola widoczności
|
||||||
|
\item \texttt{SetActorEnableCollision()} -- kontrola kolizji
|
||||||
|
\item \texttt{SetActorTickEnabled()} -- kontrola aktualizacji logiki
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Ta granularność daje większą kontrolę, ale wymaga więcej kodu do osiągnięcia tego samego efektu.
|
||||||
|
|
||||||
|
\subsubsection{Wyzwania napotkane w Unreal}
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Brak natywnego 2D} -- konieczność ``symulowania'' środowiska 2D w silniku 3D
|
||||||
|
\item \textbf{Czas kompilacji} -- kompilacja projektów C++ jest znacznie wolniejsza niż kompilacja C\# w Unity
|
||||||
|
\item \textbf{Rozmiar projektu} -- nawet prosty projekt Unreal zajmuje wielokrotnie więcej miejsca na dysku
|
||||||
|
\item \textbf{Dokumentacja} -- dla mniej popularnych zastosowań (jak gry 2D) dokumentacja jest ograniczona
|
||||||
|
\item \textbf{Blueprinty i kontrola wersji} -- pliki Blueprintów są binarne, co utrudnia merge'owanie i code review
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\subsubsection{Pozytywne aspekty Unreal}
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Potężny system materiałów i efektów wizualnych
|
||||||
|
\item Wbudowane zaawansowane narzędzia profilowania
|
||||||
|
\item Blueprinty umożliwiają szybkie prototypowanie przez osoby nietechniczne
|
||||||
|
\item Doskonałe wsparcie dla grafiki 3D i fotorealizmu
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Porównanie doświadczeń implementacyjnych}
|
||||||
|
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\centering
|
||||||
|
\caption{Porównanie doświadczeń z implementacji gry bullet-hell}
|
||||||
|
\label{tab:impl-comparison}
|
||||||
|
\begin{tabular}{|l|c|c|}
|
||||||
|
\hline
|
||||||
|
\textbf{Aspekt} & \textbf{Unity} & \textbf{Unreal Engine} \\
|
||||||
|
\hline
|
||||||
|
Czas instalacji (Linux) & $\sim$30 min & $\sim$2-4 h \\
|
||||||
|
\hline
|
||||||
|
Wsparcie natywne 2D & Tak & Nie (symulowane) \\
|
||||||
|
\hline
|
||||||
|
Język programowania & C\# & C++ / Blueprinty \\
|
||||||
|
\hline
|
||||||
|
Próg wejścia & Niski & Średni/Wysoki \\
|
||||||
|
\hline
|
||||||
|
Czas kompilacji & Szybki & Wolny (C++) \\
|
||||||
|
\hline
|
||||||
|
Object pooling & Prosty & Bardziej złożony \\
|
||||||
|
\hline
|
||||||
|
Hot reload & Tak & Ograniczony \\
|
||||||
|
\hline
|
||||||
|
Rozmiar projektu & Mały & Duży \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
\subsection{Wnioski z implementacji}
|
||||||
|
|
||||||
|
Doświadczenia z implementacji gry bullet-hell potwierdzają, że wybór silnika powinien być uzależniony od typu projektu:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Dla gier 2D} -- Unity oferuje znacznie lepsze wsparcie natywne, niższy próg wejścia i szybszy cykl iteracji
|
||||||
|
\item \textbf{Dla gier 3D AAA} -- Unreal Engine dysponuje lepszymi narzędziami do tworzenia fotorealistycznej grafiki
|
||||||
|
\item \textbf{Dla prototypowania} -- Unity pozwala na szybsze testowanie koncepcji dzięki hot reloadowi i prostszej konfiguracji
|
||||||
|
\item \textbf{Dla zespołów mieszanych} -- Blueprinty Unreal mogą być wartościowe dla współpracy z designerami, choć problemy z kontrolą wersji stanowią wyzwanie
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Implementacja gry bullet-hell w~Unity zajęła około 60\% czasu potrzebnego na implementację analogicznej funkcjonalności w~Unreal Engine, głównie ze względu na natywne wsparcie 2D i~prostszy system object poolingu.
|
||||||
200
latex/tex/narzedzia-profilowania.tex
Normal file
200
latex/tex/narzedzia-profilowania.tex
Normal file
@ -0,0 +1,200 @@
|
|||||||
|
\clearpage
|
||||||
|
\section{Narzędzia profilowania wydajności}
|
||||||
|
\label{sec:narzedzia-profilowania}
|
||||||
|
|
||||||
|
Obiektywne porównanie wydajności silników gier wymaga zastosowania odpowiednich narzędzi pomiarowych. W~niniejszym rozdziale przedstawiono analizę dostępnych rozwiązań oraz uzasadnienie wyboru NVIDIA Nsight jako głównego narzędzia profilowania.
|
||||||
|
|
||||||
|
\subsection{Wbudowane narzędzia diagnostyczne silników}
|
||||||
|
\label{subsec:wbudowane-narzedzia}
|
||||||
|
|
||||||
|
Zarówno Unity, jak i~Unreal Engine oferują własne, wbudowane narzędzia do analizy wydajności. Każde z~nich posiada unikalne cechy dostosowane do specyfiki danego silnika.
|
||||||
|
|
||||||
|
\subsubsection{Unity Profiler}
|
||||||
|
|
||||||
|
Unity dostarcza rozbudowany profiler dostępny bezpośrednio w~edytorze (Window $\rightarrow$ Analysis $\rightarrow$ Profiler). Narzędzie to oferuje:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{CPU Profiler} -- analiza czasu wykonania poszczególnych funkcji, z~podziałem na kategorie (rendering, skrypty, fizyka, animacje)
|
||||||
|
\item \textbf{GPU Profiler} -- pomiar czasu renderowania na karcie graficznej
|
||||||
|
\item \textbf{Memory Profiler} -- szczegółowa analiza alokacji pamięci, wykrywanie wycieków
|
||||||
|
\item \textbf{Audio Profiler} -- monitorowanie obciążenia systemu dźwiękowego
|
||||||
|
\item \textbf{Physics Profiler} -- analiza wydajności silnika fizyki
|
||||||
|
\item \textbf{Frame Debugger} -- krokowa analiza procesu renderowania pojedynczej klatki
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Unity Profiler umożliwia również zdalne profilowanie aplikacji uruchomionej na urządzeniu docelowym (np.~smartfonie), co jest szczególnie przydatne przy optymalizacji gier mobilnych.
|
||||||
|
|
||||||
|
\subsubsection{Unreal Insights}
|
||||||
|
|
||||||
|
Unreal Engine oferuje narzędzie Unreal Insights, które zastąpiło starszy system Session Frontend. Kluczowe funkcjonalności obejmują:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Timing Insights} -- precyzyjny pomiar czasu wykonania poszczególnych systemów silnika
|
||||||
|
\item \textbf{Asset Loading Insights} -- analiza czasu ładowania zasobów
|
||||||
|
\item \textbf{Memory Insights} -- monitorowanie alokacji i~dealokacji pamięci
|
||||||
|
\item \textbf{Animation Insights} -- profilowanie systemu animacji
|
||||||
|
\item \textbf{Network Insights} -- analiza ruchu sieciowego w~grach multiplayer
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Dodatkowo Unreal Engine udostępnia komendy konsolowe (np.~\texttt{stat fps}, \texttt{stat unit}, \texttt{stat gpu}) pozwalające na szybki podgląd podstawowych metryk wydajności podczas rozgrywki.
|
||||||
|
|
||||||
|
\subsubsection{Ograniczenia narzędzi wbudowanych}
|
||||||
|
|
||||||
|
Pomimo rozbudowanych możliwości, wbudowane profilery silników posiadają istotne ograniczenia w~kontekście porównawczych badań wydajnościowych:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Brak standaryzacji metryk} -- każdy silnik definiuje i~mierzy parametry w~odmienny sposób, co utrudnia bezpośrednie porównania
|
||||||
|
\item \textbf{Różna granularność danych} -- poziom szczegółowości raportów różni się między silnikami
|
||||||
|
\item \textbf{Narzut profilowania} -- wbudowane profilery same generują obciążenie, które może być różne dla każdego silnika
|
||||||
|
\item \textbf{Brak dostępu do danych niskopoziomowych} -- profilery silnikowe operują na poziomie abstrakcji silnika, nie hardware'u
|
||||||
|
\item \textbf{Nieporównywalność formatów wyjściowych} -- dane eksportowane przez różne profilery mają odmienne struktury
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Z~powyższych powodów zdecydowano się na zastosowanie zewnętrznego, niezależnego od silnika narzędzia profilowania.
|
||||||
|
|
||||||
|
\subsection{NVIDIA Nsight Graphics}
|
||||||
|
\label{subsec:nvidia-nsight}
|
||||||
|
|
||||||
|
NVIDIA Nsight Graphics to profesjonalne narzędzie do profilowania i~debugowania aplikacji graficznych, oferujące głęboki wgląd w~działanie GPU niezależnie od używanego silnika czy API graficznego.
|
||||||
|
|
||||||
|
\subsubsection{Uzasadnienie wyboru}
|
||||||
|
|
||||||
|
Wybór NVIDIA Nsight jako głównego narzędzia pomiarowego podyktowany był następującymi czynnikami:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Niezależność od silnika} -- Nsight analizuje aplikację na poziomie wywołań API graficznego (DirectX, Vulkan, OpenGL), co zapewnia porównywalność wyników między Unity a~Unreal Engine
|
||||||
|
\item \textbf{Standaryzowane metryki} -- narzędzie dostarcza zunifikowany zestaw metryk sprzętowych (GPU utilization, memory bandwidth, shader throughput)
|
||||||
|
\item \textbf{Minimalny narzut} -- profilowanie na poziomie sterownika generuje mniejsze zakłócenia niż profilery działające wewnątrz silnika
|
||||||
|
\item \textbf{Dostęp do danych niskopoziomowych} -- możliwość analizy poszczególnych wywołań draw call, shaderów, transferów pamięci
|
||||||
|
\item \textbf{Spójny format danych} -- wyniki z~obu silników mają identyczną strukturę, co ułatwia automatyzację analizy
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Możliwości narzędzia}
|
||||||
|
|
||||||
|
NVIDIA Nsight Graphics oferuje szereg funkcjonalności istotnych dla badań wydajnościowych:
|
||||||
|
|
||||||
|
\paragraph{Frame Profiler}
|
||||||
|
Główny moduł analizy wydajności, umożliwiający:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Przechwycenie i~analizę pojedynczej klatki (frame capture)
|
||||||
|
\item Hierarchiczny widok wszystkich wywołań GPU
|
||||||
|
\item Pomiar czasu wykonania każdego etapu renderowania
|
||||||
|
\item Identyfikację wąskich gardeł (bottlenecks)
|
||||||
|
\item Analizę wykorzystania jednostek obliczeniowych GPU
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\paragraph{GPU Trace}
|
||||||
|
Moduł do długoterminowej analizy wydajności:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Rejestrowanie metryk przez określony czas (nie tylko pojedyncza klatka)
|
||||||
|
\item Wykrywanie spadków wydajności i~ich przyczyn
|
||||||
|
\item Analiza zmienności czasów klatek (frame time variance)
|
||||||
|
\item Korelacja obciążenia GPU z~wydarzeniami w~grze
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\paragraph{Shader Profiler}
|
||||||
|
Narzędzie do optymalizacji shaderów:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Analiza wydajności poszczególnych shaderów
|
||||||
|
\item Identyfikacja nieefektywnych instrukcji
|
||||||
|
\item Pomiar occupancy (wykorzystania jednostek obliczeniowych)
|
||||||
|
\item Sugestie optymalizacyjne
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Konfiguracja środowiska pomiarowego}
|
||||||
|
|
||||||
|
Przed przeprowadzeniem pomiarów skonfigurowano środowisko w~następujący sposób:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Wyłączenie V-Sync w~obu silnikach (eliminacja sztucznego ograniczenia FPS)
|
||||||
|
\item Ustawienie identycznej rozdzielczości renderowania (1920$\times$1080)
|
||||||
|
\item Wyłączenie dynamicznego skalowania rozdzielczości
|
||||||
|
\item Ustawienie stałej częstotliwości zegara GPU (eliminacja power throttlingu)
|
||||||
|
\item Zamknięcie zbędnych procesów w~tle
|
||||||
|
\item Oczekiwanie na ustabilizowanie temperatury GPU przed pomiarem
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
\subsection{Przetwarzanie danych z~Nsight}
|
||||||
|
\label{subsec:przetwarzanie-nsight}
|
||||||
|
|
||||||
|
Dane zebrane przez NVIDIA Nsight wymagają odpowiedniego przetworzenia w~celu uzyskania porównywalnych metryk.
|
||||||
|
|
||||||
|
\subsubsection{Eksport danych}
|
||||||
|
|
||||||
|
Nsight umożliwia eksport danych w~kilku formatach:
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{CSV} -- tabularyczne dane liczbowe, idealne do dalszej analizy
|
||||||
|
\item \textbf{JSON} -- strukturalne dane z~pełną hierarchią wywołań
|
||||||
|
\item \textbf{HTML Report} -- czytelny raport z~wykresami (mniej przydatny do automatyzacji)
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
W~niniejszej pracy wykorzystano format CSV ze względu na łatwość importu do narzędzi analizy statystycznej.
|
||||||
|
|
||||||
|
\subsubsection{Kluczowe metryki}
|
||||||
|
|
||||||
|
Z~danych eksportowanych przez Nsight wyodrębniono następujące metryki:
|
||||||
|
|
||||||
|
\begin{table}[htbp]
|
||||||
|
\centering
|
||||||
|
\caption{Kluczowe metryki wydajnościowe z~NVIDIA Nsight}
|
||||||
|
\label{tab:metryki-nsight}
|
||||||
|
\begin{tabular}{|>{\raggedright\arraybackslash}p{4cm}|>{\raggedright\arraybackslash}p{3cm}|>{\raggedright\arraybackslash}p{5.5cm}|}
|
||||||
|
\hline
|
||||||
|
\textbf{Metryka} & \textbf{Jednostka} & \textbf{Opis} \\
|
||||||
|
\hline
|
||||||
|
Frame Time & ms & Całkowity czas renderowania klatki \\
|
||||||
|
\hline
|
||||||
|
GPU Duration & ms & Czas pracy GPU (bez CPU overhead) \\
|
||||||
|
\hline
|
||||||
|
Draw Calls & liczba & Ilość wywołań rysowania na klatkę \\
|
||||||
|
\hline
|
||||||
|
Triangles Rendered & liczba & Liczba wyrenderowanych trójkątów \\
|
||||||
|
\hline
|
||||||
|
GPU Memory Used & MB & Zużycie pamięci VRAM \\
|
||||||
|
\hline
|
||||||
|
SM Occupancy & \% & Wykorzystanie jednostek obliczeniowych \\
|
||||||
|
\hline
|
||||||
|
Memory Bandwidth & GB/s & Przepustowość pamięci GPU \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
\subsubsection{Metodyka pomiarów}
|
||||||
|
|
||||||
|
Dla każdej konfiguracji testowej przeprowadzono serię pomiarów według następującego protokołu:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Uruchomienie aplikacji i~oczekiwanie 30 sekund na stabilizację
|
||||||
|
\item Rozpoczęcie rejestracji GPU Trace (czas trwania: 60 sekund)
|
||||||
|
\item Przechwycenie 10 pojedynczych klatek w~równych odstępach czasu
|
||||||
|
\item Zakończenie rejestracji i~eksport danych
|
||||||
|
\item Powtórzenie procedury 3 razy dla każdej konfiguracji
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Wyniki uśredniono, odrzucając wartości odstające (outliers) zidentyfikowane metodą IQR (InterQuartile Range).
|
||||||
|
|
||||||
|
\subsubsection{Automatyzacja analizy}
|
||||||
|
|
||||||
|
W~celu zapewnienia powtarzalności i~eliminacji błędów ludzkich, proces analizy danych został częściowo zautomatyzowany za pomocą skryptów Python. Główne etapy obejmowały:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Parsowanie plików CSV eksportowanych z~Nsight
|
||||||
|
\item Agregację danych z~wielu sesji pomiarowych
|
||||||
|
\item Obliczanie statystyk opisowych (średnia, mediana, odchylenie standardowe)
|
||||||
|
\item Generowanie wykresów porównawczych
|
||||||
|
\item Eksport wyników do formatu LaTeX (tabele)
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Podsumowanie wyboru narzędzi}
|
||||||
|
\label{subsec:podsumowanie-narzedzi}
|
||||||
|
|
||||||
|
Zastosowanie NVIDIA Nsight jako głównego narzędzia profilowania zapewnia:
|
||||||
|
|
||||||
|
\begin{enumerate}
|
||||||
|
\item \textbf{Obiektywność} -- pomiary wykonywane na tym samym poziomie abstrakcji dla obu silników
|
||||||
|
\item \textbf{Porównywalność} -- identyczne metryki i~format danych
|
||||||
|
\item \textbf{Wiarygodność} -- niskopoziomowe pomiary eliminują artefakty wprowadzane przez profilery silnikowe
|
||||||
|
\item \textbf{Powtarzalność} -- standaryzowana procedura pomiarowa
|
||||||
|
\end{enumerate}
|
||||||
|
|
||||||
|
Wbudowane profilery Unity i~Unreal Engine pozostają cennym narzędziem podczas procesu optymalizacji, jednak do celów badawczych wymagających bezpośredniego porównania między silnikami, zewnętrzne narzędzie oferuje znaczące przewagi metodologiczne.
|
||||||
264
latex/tex/wywiady-analiza.tex
Normal file
264
latex/tex/wywiady-analiza.tex
Normal file
@ -0,0 +1,264 @@
|
|||||||
|
\clearpage
|
||||||
|
\section{Analiza wywiadów z deweloperami gier}
|
||||||
|
\label{sec:wywiady}
|
||||||
|
|
||||||
|
W ramach badań jakościowych przeprowadzono osiem pogłębionych wywiadów z deweloperami gier posiadającymi doświadczenie w pracy z silnikami Unity i Unreal Engine. Celem badania było zebranie praktycznych spostrzeżeń dotyczących użyteczności, wydajności oraz przepływu pracy w obu silnikach z perspektywy osób aktywnie je wykorzystujących.
|
||||||
|
|
||||||
|
\subsection{Charakterystyka respondentów}
|
||||||
|
\label{subsec:charakterystyka-respondentow}
|
||||||
|
|
||||||
|
Respondenci zostali dobrani według kryterium posiadania co najmniej rocznego doświadczenia amatorskiego lub profesjonalnego w jednym z badanych silników. Profil uczestników przedstawia się następująco:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Respondent 1}: Około 6-10 lat doświadczenia amatorskiego w Unity, semestr zajęć z Unreal Engine, 10-20 projektów w Unity
|
||||||
|
\item \textbf{Respondent 2}: 7 lat doświadczenia amatorskiego w Unity, pół roku profesjonalnego, 15-20 projektów
|
||||||
|
\item \textbf{Respondent 3}: 1,5 roku amatorskiego doświadczenia w Unity, 4 projekty zakończone
|
||||||
|
\item \textbf{Respondent 4}: 2 lata profesjonalne w Unreal, 2 miesiące w Unity (z przerwami przez kilka lat), projekty w obu silnikach
|
||||||
|
\item \textbf{Respondent 5}: 9 lat doświadczenia zawodowego (od 2012 Unity amatorsko, od 2016 profesjonalnie; od 2019 Unreal profesjonalnie), 10-30 projektów w Unity, 5-6 w Unreal
|
||||||
|
\item \textbf{Respondent 6}: Dekada doświadczenia amatorskiego w Unity, kilka projektów game jamowych
|
||||||
|
\item \textbf{Respondent 7}: 9 lat hobbystycznego doświadczenia w Unity, 2 lata profesjonalnego; 1-1,5 roku amatorskiego w Unreal
|
||||||
|
\item \textbf{Respondent 8}: 2 lata amatorsko w Unity, 1,5 roku profesjonalnie + pół roku stażu w Unreal, kilkanaście projektów w obu silnikach
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Łącznie badana próba reprezentuje szerokie spektrum doświadczeń -- od osób skupionych wyłącznie na Unity, przez deweloperów wykorzystujących oba silniki, po profesjonalistów pracujących głównie w Unreal Engine.
|
||||||
|
|
||||||
|
\subsection{Motywy wyboru silnika}
|
||||||
|
\label{subsec:motywy-wyboru}
|
||||||
|
|
||||||
|
\subsubsection{Przystępność i próg wejścia}
|
||||||
|
|
||||||
|
Dominującym motywem wyboru Unity jako pierwszego silnika była jego \textbf{przystępność dla początkujących}. Respondenci wskazywali, że Unity oferuje mniejszą liczbę gotowych mechanik widocznych na starcie -- silnik nie narzuca użytkownikowi wbudowanych rozwiązań, jeżeli ten nie wybierze specjalnego szablonu projektu. Było to postrzegane jako zaleta dydaktyczna, ponieważ nowicjusze nie byli przytłaczani złożonością interfejsu.
|
||||||
|
|
||||||
|
Jednocześnie respondenci podkreślali, że Unreal Engine w przeszłości (około 2018 roku) charakteryzował się znacznie wyższym progiem wejścia niż obecnie. W tamtym okresie dostępnych było również więcej materiałów edukacyjnych dla Unity, co dodatkowo wpływało na wybór tego silnika przez początkujących.
|
||||||
|
|
||||||
|
Paradoksalnie, mniejsza liczba wbudowanych funkcjonalności w Unity była postrzegana jako zaleta dydaktyczna -- silnik nie przytłaczał nowicjuszy złożonością interfejsu i pozwalał na stopniowe poznawanie kolejnych mechanizmów.
|
||||||
|
|
||||||
|
\subsubsection{Język programowania}
|
||||||
|
|
||||||
|
Wybór C\# jako głównego języka skryptowania w Unity stanowił istotny czynnik decyzyjny dla osób z wcześniejszym doświadczeniem w tym języku. Respondenci z backgroundem w C\# określali przejście do Unity jako naturalne i intuicyjne. Język ten był opisywany jako wysokopoziomowy, niewymagający ręcznego zarządzania pamięcią, co znacząco obniża barierę wejścia dla początkujących programistów.
|
||||||
|
|
||||||
|
Niektórzy respondenci zwracali uwagę, że C++ używany w Unreal Engine różni się od standardowego C++ -- jest rozszerzony o makra i mechanizmy specyficzne dla silnika, co może być zaskakujące dla programistów przyzwyczajonych do klasycznego C++.
|
||||||
|
|
||||||
|
\subsubsection{Wymagania projektu}
|
||||||
|
|
||||||
|
Wybór Unreal Engine często był podyktowany specyfiką projektu lub wymaganiami rynku pracy. Respondenci wskazywali, że projekty wymagające wysokiej jakości grafiki naturalnie kierowały ich w stronę Unreal Engine. Dodatkowo, część osób rozpoczęła naukę Unreal ze względu na większą liczbę ofert pracy wymagających znajomości tego silnika, szczególnie w segmencie gier AAA i większych studiów deweloperskich.
|
||||||
|
|
||||||
|
\subsection{Dokumentacja i materiały edukacyjne}
|
||||||
|
\label{subsec:dokumentacja}
|
||||||
|
|
||||||
|
\subsubsection{Oficjalna dokumentacja}
|
||||||
|
|
||||||
|
W zakresie dokumentacji oficjalnej respondenci wyraźnie faworyzowali Unity. Dokumentacja tego silnika była opisywana jako dogłębna i szczegółowa -- praktycznie wszystkie klasy, metody i właściwości są dokładnie opisane, a dodatkowo często zawierają działające przykłady kodu, które można bezpośrednio skopiować i uruchomić w projekcie.
|
||||||
|
|
||||||
|
Dokumentacja Unreal Engine była oceniana znacznie gorzej. Respondenci określali ją jako szkieletową lub wręcz nieistniejącą w praktycznym sensie. Wiele stron dokumentacji zawiera jedynie nazwę funkcji i nazwy parametrów, bez jakiegokolwiek opisu działania. Jeden z respondentów porównał czytanie dokumentacji Unreal do przeglądania plików nagłówkowych (header files), gdzie użytkownik musi samodzielnie domyślać się, co dana funkcja robi.
|
||||||
|
|
||||||
|
Jako pozytywny aspekt ekosystemu Unreal wskazywano fora deweloperskie, gdzie profesjonalni użytkownicy dzielą się rozwiązaniami. Problemem jest jednak to, że część najbardziej wartościowych zasobów znajduje się w zamkniętych sekcjach forum, dostępnych tylko dla wybranych firm po uzyskaniu specjalnych uprawnień od Epic Games.
|
||||||
|
|
||||||
|
\subsubsection{Nieoficjalne poradniki}
|
||||||
|
|
||||||
|
W przypadku materiałów nieoficjalnych (YouTube, blogi, fora) Unity również dominowało ilościowo. Respondenci szczególnie wyróżniali kanał Brackeys jako kluczowe źródło wiedzy dla początkujących i średniozaawansowanych użytkowników Unity.
|
||||||
|
|
||||||
|
Poradniki do Unreal Engine były oceniane jako:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Mniej liczne niż dla Unity
|
||||||
|
\item Często nieaktualne -- dotyczące starszych wersji silnika (np. Unreal 4), które mogą, ale nie muszą działać w nowszych wersjach
|
||||||
|
\item Zbyt skoncentrowane na systemie Blueprints kosztem programowania w C++
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Jakość dydaktyczna poradników}
|
||||||
|
|
||||||
|
Respondenci zwracali uwagę na wspólny problem poradników do obu silników -- koncentrację na implementacji konkretnych funkcji kosztem dobrych praktyk programistycznych. Większość dostępnych materiałów skupia się na pokazaniu, jak zaimplementować pojedynczą mechanikę, bez wyjaśniania szerszego kontekstu architektonicznego czy zasad rozszerzalności kodu.
|
||||||
|
|
||||||
|
Ten brak holistycznego podejścia sprawia, że początkujący deweloperzy potrafią zaimplementować poszczególne funkcje, ale mają trudności z połączeniem ich w spójną całość lub późniejszym rozwojem projektu.
|
||||||
|
|
||||||
|
\subsection{Architektura i wzorce projektowe}
|
||||||
|
\label{subsec:architektura}
|
||||||
|
|
||||||
|
\subsubsection{System komponentowy Unity}
|
||||||
|
|
||||||
|
Architektura Unity oparta na komponentach była oceniana pozytywnie pod względem elastyczności. Respondenci doceniali możliwość dzielenia funkcjonalności na małe, niezależne moduły (komponenty), które następnie można łączyć w większe całości.
|
||||||
|
|
||||||
|
Jednocześnie wskazywano na problemy wynikające z długu technologicznego Unity. Silnik jest bardzo monolityczny, z głęboką hierarchią dziedziczenia podstawowych konceptów. Niektóre obiekty bazowe zajmują tak dużo pamięci, że nie mieszczą się w pojedynczej linii cache procesora, co na współczesny hardware stanowi istotny problem wydajnościowy.
|
||||||
|
|
||||||
|
\subsubsection{Struktura Unreal Engine}
|
||||||
|
|
||||||
|
Architektura Unreal Engine wymusza bardziej uporządkowany styl pracy. Respondenci zauważali, że nawet podstawowe projekty tworzone w Unreal mają tendencję do bycia lepiej zorganizowanymi, ponieważ silnik narzuca określoną strukturę.
|
||||||
|
|
||||||
|
Struktura aktor-komponent w Unreal (level zawiera aktorów, aktorzy zawierają komponenty) została opisana jako bardziej restrykcyjna niż prefaby w Unity. Próby tworzenia zagnieżdżonych struktur (aktor w aktorze) często prowadzą do problemów, podczas gdy w Unity hierarchie prefabów są bardziej elastyczne.
|
||||||
|
|
||||||
|
\subsubsection{Specjalizacja silników}
|
||||||
|
|
||||||
|
Respondenci zauważyli, że Unreal Engine jest wyraźnie zoptymalizowany pod gry typu first-person shooter. Tworzenie gier FPS w Unreal jest niezwykle proste -- wystarczy zaznaczyć odpowiednie opcje. Natomiast projekty odbiegające od tego wzorca (np. gry z rozbudowanym interfejsem użytkownika, gry turowe) wymagają znacznie więcej pracy i często sprowadzają się do obchodzenia domyślnych mechanizmów silnika.
|
||||||
|
|
||||||
|
\subsection{Kompilacja i przepływ pracy}
|
||||||
|
\label{subsec:kompilacja}
|
||||||
|
|
||||||
|
\subsubsection{Czas kompilacji}
|
||||||
|
|
||||||
|
Czas kompilacji w Unity był identyfikowany jako znaczący problem przy większych projektach. W miarę rozrastania się bazy kodu, czas potrzebny na rekompilację po każdej zmianie rośnie.
|
||||||
|
|
||||||
|
Unity oferuje mechanizm Assembly Definitions jako rozwiązanie tego problemu. Bez podziału projektu na osobne assemblies każda zmiana w kodzie powoduje rekompilację całego projektu. Podział na mniejsze moduły pozwala kompilować tylko zmienione fragmenty, znacząco skracając czas iteracji.
|
||||||
|
|
||||||
|
\subsubsection{Stabilność środowiska}
|
||||||
|
|
||||||
|
Istotną różnicą między silnikami jest obsługa błędów krytycznych. W Unity gra uruchomiona w edytorze działa jako osobny proces -- gdy wystąpi błąd krytyczny, zamyka się tylko ten proces, a edytor pozostaje stabilny. W Unreal Engine silnik i gra działają jako jeden proces, więc crash w grze powoduje utratę całego edytora wraz z ewentualnymi niezapisanymi zmianami.
|
||||||
|
|
||||||
|
Ta różnica architekturalna ma istotne konsekwencje dla produktywności, szczególnie przy debugowaniu. Przy dużych projektach, gdzie uruchomienie silnika może trwać kilkanaście minut, każdy crash oznacza znaczną stratę czasu.
|
||||||
|
|
||||||
|
\subsubsection{Kompatybilność wsteczna}
|
||||||
|
|
||||||
|
Unreal Engine był krytykowany za problemy z kompatybilnością między wersjami. Respondenci wskazywali, że rozpoczęcie projektu w określonej wersji silnika może skutkować problemami, jeśli ta wersja okaże się zawierać fundamentalne błędy. Epic Games nie backportuje poprawek do starszych wersji w takim stopniu jak Unity robi to dla wersji LTS.
|
||||||
|
|
||||||
|
\subsection{Kontrola wersji i współpraca zespołowa}
|
||||||
|
\label{subsec:kontrola-wersji}
|
||||||
|
|
||||||
|
\subsubsection{Integracja z Git}
|
||||||
|
|
||||||
|
Współpraca z systemem Git była oceniana lepiej dla Unity ze względu na tekstową serializację assetów. Pliki scen i prefabów w Unity są zapisywane w formacie YAML, co teoretycznie umożliwia ich mergowanie. Nowoczesne narzędzia (np. merge w Rider) potrafią automatycznie rozwiązywać niektóre konflikty na scenach.
|
||||||
|
|
||||||
|
Pliki binarne w Unreal Engine stanowią znaczące wyzwanie. Respondenci zwracali uwagę, że nawet pliki Blueprintów, które ewidentnie mają serializację tekstową, są zapisywane na dysku jako binaria. To znacznie utrudnia współpracę wielu programistów nad tym samym projektem.
|
||||||
|
|
||||||
|
\subsubsection{Mergowanie konfliktów}
|
||||||
|
|
||||||
|
Konflikty na scenach i prefabach stanowią problem w obu silnikach. Gdy dwie osoby edytują tę samą scenę, rozwiązanie konfliktu często sprowadza się do wybrania jednej wersji i ręcznego przeniesienia zmian z drugiej.
|
||||||
|
|
||||||
|
Jako rozwiązanie wskazywano praktykę lockowania plików (preferowana przy użyciu Perforce) lub podział pracy na oddzielne sceny, gdzie każdy deweloper pracuje we własnym środowisku. Unity ułatwia takie podejście dzięki elastycznemu systemowi scen, podczas gdy Unreal silniej promuje architekturę z jedną główną sceną.
|
||||||
|
|
||||||
|
\subsection{Współpraca z osobami nietechnicznymi}
|
||||||
|
\label{subsec:wspolpraca-nietechniczna}
|
||||||
|
|
||||||
|
\subsubsection{System Blueprints}
|
||||||
|
|
||||||
|
Blueprinty w Unreal Engine były postrzegane jako skuteczne narzędzie ułatwiające współpracę z osobami nietechnicznymi. System wizualnego programowania pozwala designerom i artystom na tworzenie logiki gry bez pisania kodu tekstowego. Respondenci zauważali, że osoby niebędące programistami często nie zdają sobie sprawy, że faktycznie programują, korzystając z Blueprintów.
|
||||||
|
|
||||||
|
Jednocześnie integracja Blueprintów z kodem C++ nie jest idealna. Przejście między oboma systemami wymaga dodatkowej pracy, a wystawianie funkcji C++ do Blueprintów nie zawsze działa bezproblemowo.
|
||||||
|
|
||||||
|
\subsubsection{Narzędzia dla artystów}
|
||||||
|
|
||||||
|
Unity wymaga więcej pracy przy tworzeniu narzędzi dla osób nietechnicznych. Respondenci wskazywali, że w Unreal Engine osoby nietechniczne mają lepsze wsparcie ,,out of the box'', podczas gdy w Unity zazwyczaj trzeba przeprowadzać szkolenia lub tworzyć dedykowane narzędzia edytorowe, aby umożliwić artystom i designerom samodzielną pracę.
|
||||||
|
|
||||||
|
\subsection{Asset Store i zasoby zewnętrzne}
|
||||||
|
\label{subsec:asset-store}
|
||||||
|
|
||||||
|
\subsubsection{Dostępność i jakość assetów}
|
||||||
|
|
||||||
|
Asset Store Unity był oceniany jako lepiej zarządzany i bogatszy. Respondenci wskazywali na silniejsze wsparcie społeczności i większe szanse na znalezienie potrzebnych zasobów.
|
||||||
|
|
||||||
|
Interesującą obserwacją było to, że najlepsze produkty z Asset Store mają tendencję do opuszczania platformy -- twórcy zakładają własne strony internetowe po osiągnięciu określonego poziomu popularności.
|
||||||
|
|
||||||
|
Unreal Marketplace przeszedł niedawno transformację w platformę Fab, co według respondentów pogorszyło doświadczenie użytkownika i zwiększyło liczbę kroków potrzebnych do pobrania darmowych zasobów.
|
||||||
|
|
||||||
|
\subsubsection{Zastosowanie assetów}
|
||||||
|
|
||||||
|
Assety były rekomendowane głównie do prototypowania, nie do produkcji komercyjnej. Respondenci podkreślali, że niespójny styl graficzny wynikający z łączenia assetów od różnych twórców jest gorszy niż jednolity, nawet jeśli prosty styl graficzny.
|
||||||
|
|
||||||
|
\subsection{Wykorzystanie sztucznej inteligencji}
|
||||||
|
\label{subsec:ai}
|
||||||
|
|
||||||
|
\subsubsection{Doświadczenia z LLM}
|
||||||
|
|
||||||
|
Większość respondentów miała ograniczone doświadczenia z wykorzystaniem AI w pracy z silnikami gier. Główna obserwacja dotyczyła niskiej jakości generowanego kodu -- naprawianie błędów w kodzie wygenerowanym przez ChatGPT często zajmowało więcej czasu niż napisanie rozwiązania od podstaw.
|
||||||
|
|
||||||
|
Jednocześnie AI było wykorzystywane skuteczniej jako substytut dokumentacji dla Unreal Engine. Pomimo częstych konfabulacji, modele językowe potrafiły naprowadzić na właściwe słowa kluczowe lub nazwy funkcji, które następnie można było zweryfikować w kodzie źródłowym silnika.
|
||||||
|
|
||||||
|
\subsubsection{Generowanie grafik}
|
||||||
|
|
||||||
|
Pozytywne doświadczenia zgłoszono w zakresie generowania placeholderów graficznych podczas game jamów. AI pozwala szybko uzyskać przyzwoicie wyglądające grafiki do prototypów, choć do wersji finalnych produktów nadal preferowana jest praca profesjonalnych grafików.
|
||||||
|
|
||||||
|
\subsection{Optymalizacja i wydajność}
|
||||||
|
\label{subsec:optymalizacja}
|
||||||
|
|
||||||
|
\subsubsection{Narzut silników}
|
||||||
|
|
||||||
|
Respondenci wskazywali, że Unity ma mniejszy narzut wydajnościowy niż Unreal dla prostych projektów. Czas ładowania projektów w Unity jest znacznie krótszy, co respondenci przypisywali domyślnie niższym rozdzielczościom tekstur i prostszym ustawieniom graficznym.
|
||||||
|
|
||||||
|
\subsubsection{Blueprinty vs C++}
|
||||||
|
|
||||||
|
Istotną różnicę wydajnościową w Unreal stanowi wybór między Blueprintami a kodem C++. Blueprinty są interpretowane w czasie wykonania jako dane, a nie kompilowane do kodu maszynowego. W praktyce oznacza to, że logika napisana w Blueprintach jest znacznie wolniejsza niż równoważny kod C++.
|
||||||
|
|
||||||
|
\subsubsection{Garbage Collector}
|
||||||
|
|
||||||
|
Problem garbage collectora w Unity był wielokrotnie wspominany jako znany problem, przed którym ostrzegają doświadczeni deweloperzy. Cykliczne uruchamianie garbage collectora może powodować zauważalne zacięcia w grze. Co ciekawe, wielu respondentów wspominało o tym problemie jako o teoretycznym zagrożeniu, nie mając bezpośrednich negatywnych doświadczeń -- prawdopodobnie dzięki stosowaniu praktyk takich jak object pooling.
|
||||||
|
|
||||||
|
\subsection{Przyszłość silników i oczekiwania deweloperów}
|
||||||
|
\label{subsec:przyszlosc}
|
||||||
|
|
||||||
|
\subsubsection{Entity Component System (ECS)}
|
||||||
|
|
||||||
|
Nowy system DOTS/ECS w Unity był oczekiwaną funkcjonalnością, która w momencie przeprowadzania wywiadów została już oficjalnie wydana. System ten pozwala na pisanie wysoce wydajnego, zorientowanego na dane kodu, kosztem większej złożoności programistycznej.
|
||||||
|
|
||||||
|
\subsubsection{UI Toolkit}
|
||||||
|
|
||||||
|
Nowy system UI w Unity (UI Toolkit) był wskazywany jako obszar wymagający poprawy. Respondenci wyrażali nadzieję na jego dalszy rozwój w kierunku zbliżonym do technologii frontendowych, co ułatwiłoby pracę osobom z doświadczeniem w tworzeniu aplikacji webowych.
|
||||||
|
|
||||||
|
\subsubsection{Konkurencja Godot}
|
||||||
|
|
||||||
|
Część respondentów wyraziła zainteresowanie silnikiem Godot jako alternatywą dla Unity i Unreal. Główne przyczyny to:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Model licencyjny royalty-free (brak opłat od przychodów)
|
||||||
|
\item Otwarte źródła umożliwiające modyfikację silnika
|
||||||
|
\item Mniejsza złożoność ułatwiająca naukę
|
||||||
|
\item Kontrowersje związane z próbą zmiany modelu licencyjnego Unity w 2023 roku
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Respondenci przewidywali, że jeśli Unity nie poprawi swojego wizerunku i oferty, Godot może w przyszłości stać się poważną konkurencją w segmencie gier indie.
|
||||||
|
|
||||||
|
\subsection{Podsumowanie wyników badań jakościowych}
|
||||||
|
\label{subsec:podsumowanie-wywiady}
|
||||||
|
|
||||||
|
Na podstawie przeprowadzonych wywiadów można sformułować następujące wnioski:
|
||||||
|
|
||||||
|
\subsubsection{Silne strony Unity}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Wysoka jakość oficjalnej dokumentacji
|
||||||
|
\item Bogaty ekosystem materiałów edukacyjnych
|
||||||
|
\item Niższy próg wejścia dla początkujących
|
||||||
|
\item Lepsza integracja z systemami kontroli wersji (tekstowa serializacja)
|
||||||
|
\item Przystępny język programowania (C\#)
|
||||||
|
\item Elastyczna architektura komponentowa
|
||||||
|
\item Mniejszy narzut wydajnościowy dla prostych projektów
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Silne strony Unreal Engine}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Wymuszona struktura projektu promująca dobre praktyki
|
||||||
|
\item System Blueprints ułatwiający współpracę z osobami nietechnicznymi
|
||||||
|
\item Więcej gotowych funkcjonalności ,,out of the box''
|
||||||
|
\item Lepsze wsparcie dla projektów wysokobudżetowych (grafika, multiplayer)
|
||||||
|
\item Dostęp do kodu źródłowego silnika
|
||||||
|
\item Lepsza integracja z zewnętrznymi narzędziami graficznymi (np. Blender)
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Obszary problemowe wspólne}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Trudności z mergowaniem assetów graficznych w systemach kontroli wersji
|
||||||
|
\item Poradniki koncentrujące się na implementacji kosztem dobrych praktyk
|
||||||
|
\item Problemy z kompatybilnością między wersjami silników
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Rekomendacje z badań}
|
||||||
|
|
||||||
|
Na podstawie wywiadów można zasugerować następujące kryteria wyboru silnika:
|
||||||
|
|
||||||
|
\begin{table}[ht]
|
||||||
|
\centering
|
||||||
|
\caption{Rekomendacje wyboru silnika w zależności od kontekstu projektu}
|
||||||
|
\label{tab:rekomendacje-silnikow}
|
||||||
|
\begin{tabular}{|>{\raggedright\arraybackslash}p{4.5cm}|>{\raggedright\arraybackslash}p{4cm}|>{\raggedright\arraybackslash}p{4cm}|}
|
||||||
|
\hline
|
||||||
|
\textbf{Kryterium} & \textbf{Unity} & \textbf{Unreal Engine} \\
|
||||||
|
\hline
|
||||||
|
Doświadczenie zespołu & Początkujący, znajomość C\# & Średniozaawansowany, znajomość C++ \\
|
||||||
|
\hline
|
||||||
|
Typ projektu & Gry mobilne, 2D, indie & FPS, AAA, realistyczna grafika \\
|
||||||
|
\hline
|
||||||
|
Skład zespołu & Programiści & Mieszany (designerzy, artyści) \\
|
||||||
|
\hline
|
||||||
|
Budżet czasowy na naukę & Krótki & Średni do długiego \\
|
||||||
|
\hline
|
||||||
|
Wymagania graficzne & Standardowe & Wysokie \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
Wyniki badań jakościowych uzupełniają obiektywne testy wydajnościowe przedstawione w rozdziale \ref{sec:testy-wydajnosci}, dostarczając kontekstu praktycznego użytkowania obu silników w rzeczywistych projektach.
|
||||||
Loading…
Reference in New Issue
Block a user