1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
\documentclass{projdoc}
\title{Software Design}
\begin{document}
\tablestables
\newpage
\section{Introduction}
This document outlines the design and development process of the cr\^epe game engine,
detailing the key decisions made during its creation. The primary goal of this engine
is to offer a streamlined, Unity-like experience tailored for developing 2D games
similar to Jetpack Joyride.
The cr\^epe engine is designed to ease the transition for developers familiar with
Unity, ensuring minimal friction when switching platforms. Our aim is to preserve
many of Unity’s core features while introducing a lightweight and open-source
alternative, licensed under the MIT License.
The engine is primarily aimed at indie developers who have prior experience with
Unity and are looking for a flexible, cost-effective solution with familiar
workflows.
\section{Overview}
\subsection{Core}
\subsubsection{Game Loop}
Problem Statement\
In the context of game development, a robust game loop is essential for maintaining consistent gameplay and ensuring that game logic, physics, and rendering are executed in a synchronized manner. Without a well-defined game loop, issues such as inconsistent frame rates, unresponsive input handling, and unpredictable behavior can arise, leading to a poor user experience. Therefore, the implementation of a game loop within a game engine is crucial for providing a stable foundation upon which game developers can build their projects.
Game Loop Design\
The game loop is integrated directly into the engine to streamline development and minimize timing issues for game developers. Two separate update functions are employed. A fixed-time update is used with a consistent time delay per update call for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. By performing physics calculations at regular intervals, game logic and physics are decoupled from frame rate, ensuring consistent behavior across different hardware.
Rendering and animations are handled separately on a per-frame basis.
A delay and delta time calculation are applied to create consitent visual behavior, even when frame rates vary.
This separation between game logic and rendering ensures that both simulation accuracy and visual fluidity are optimized.
\subsection{Patterns}
\section{Design}
\subsection{Rendering}
\subsection{Physics}
\subsection{Scripting}
\subsection{Audio}
\subsubsection{Library}
\subsubsection{Fa\c{c}ade}
\Cref{fig:class-audio-facade} shows a class diagram of the audio fa\c{c}ade. It
contains the following classes:
\begin{description}
\item[SoundContext] This is a wrapper around the \codeinline{SoLoud::soloud}
`engine' class, and is therefore implemented as a singleton. This ensures the
audio engine is initialized before \codeinline{Sound} is able to use it.
This class is friends with \codeinline{Sound}, so only \codeinline{Sound} is able
to get the \codeinline{SoundContext} instance.
\item[Sound] This is a wrapper around the \codeinline{SoLoud::Wav} class, and uses
cr\^epe's \codeinline{Asset} class to load an audio sample instead.
\end{description}
\begin{figure}
\centering
\includepumldiag{img/facade-audio.puml}
\caption{Audio fa\c{c}ade class diagram}
\label{fig:class-audio-facade}
\end{figure}
\subsection{Input}
\subsection{Physics}
\section{Tools}
\section{Conclusion}
\end{document}
|