mirror of
https://github.com/kuhyx/engineer-thesis-WUT.git
synced 2026-07-04 13:23:09 +02:00
feat: finished changing initialy generated text
This commit is contained in:
parent
216f28befe
commit
3757aabbb0
@ -6,6 +6,7 @@
|
||||
% Rozdzialy poziomu I od nowej strony -> domyslnie przez latexa
|
||||
% Wyliczenia -> tylko kropka lub myslnik -> tylko kropka domylsnie przez latexa
|
||||
|
||||
\usepackage{ulem}
|
||||
\usepackage{fontspec}
|
||||
\usepackage{anyfontsize}
|
||||
\usepackage{graphicx}
|
||||
@ -241,78 +242,6 @@ Architecture and libraries used form the skeleton, the Match Three mechanics are
|
||||
|
||||
While the first objective is the engine's development, a broader goal is to expand upon created engine. By addressing challenges and sharing solutions, this thesis hopes to offer an example for engine developers. Whether they wish to enhance this engine or create new game engines. This thesis tries to improve their understanding of the topic
|
||||
|
||||
\section{ Choice of graphic renderning API }
|
||||
There are 3 main APIs for graphical rendering
|
||||
\begin{itemize}
|
||||
\item DirectX
|
||||
\item OpenGL
|
||||
\item Vulkan
|
||||
\end{itemize}
|
||||
DirectX developed by Microsoft focues on Windows operating systems and
|
||||
Microsoft line of consoles Xbox, it is deemed as being harder with more
|
||||
low level programming and requiring better understanding of how underlying
|
||||
mechanisms work but in turn offers functionalities and better performance.
|
||||
It does not have free license. \\
|
||||
OpenGL is developed by Khronos Group and offers good compatibility,
|
||||
especially if using OpenGL ES subset which works on Windows, Linux,
|
||||
Mac OS, Android, iOS and all major consoles.
|
||||
It is widely recognized as easiest of APIs and most popular choice
|
||||
for writing first game engine. On the other hand it lacks some of
|
||||
more advanced features which have to be written manually.
|
||||
It uses open source license similar to BSD
|
||||
\\
|
||||
Vulkan is also developed by Khronos Group and as such is deemed as a
|
||||
spiritual successor of OpenGL with focus on using modern C++ features and
|
||||
fixing issues created by OpenGL 30 years old development time.
|
||||
Out of these three it is recognized as the hardest one as
|
||||
it is both complicated and newest. Similarly as OpenGL
|
||||
it uses open source license, namely Apache License 2.0.
|
||||
\\
|
||||
Considering all of those characteristics I decided to go with OpenGL API,
|
||||
specifically OpenGL ES subset with its focus on compatibility as
|
||||
making a multiplatform application is one of the focues of this thesis.
|
||||
I decided that since this will be my first attempt at game engine development
|
||||
I need something that is relatively easy and has a lot of resources online.
|
||||
I would most likely not use advanced features of Vulkan and DirectX and
|
||||
therefore finish my thesis before approaching problems where OpenGL
|
||||
does not deliver more complicated architecture.
|
||||
From my own private preferences I also prefer software with
|
||||
open source license.
|
||||
|
||||
\section{Choice of OpenGL Library}
|
||||
There are 4 basic OpenGL libraries that I considered:
|
||||
\begin{itemize}
|
||||
\item freeGLUT
|
||||
\item SDL
|
||||
\item SFML
|
||||
\item GLFW
|
||||
\end{itemize}
|
||||
freeGLUT was created as opensource alternative to GLUT,
|
||||
is considered to be the worst out of all 4,
|
||||
written in archaic way, using C or very old C++,
|
||||
which in turn results in unexpected "buggy" behaviour,
|
||||
it is also not really popular with lack of online guides \\
|
||||
SDL - Simple DirectMedia Layer has big userbase,
|
||||
it is not designed to by used as a standalone
|
||||
library and requires additional libraries to do networking
|
||||
or to create more complex applications. \\
|
||||
SFML is the library with most features out of all 4,
|
||||
it supports networking, audio and has system features by
|
||||
default. It uses modern object oriented C++.
|
||||
Main problem with SFML is that it is not very popular API,
|
||||
therefore troubleshooting problems with SFML is quite hard and
|
||||
it has only few use guides online \\
|
||||
GLFW is an library that is both the most popular and with fewest features by default.
|
||||
It forces users to use additional libraries for networking,
|
||||
sound, physic calculations and so on but in turn is also
|
||||
quite small and flexible. It has biggest community and a
|
||||
lot of guides, like one hosted at
|
||||
\href{learnopengl.com}{learnopengl.com} or one created by
|
||||
programming youtuber Cherno \\
|
||||
I decided to use GLFW library. I wanted something that is
|
||||
relatively easy to troubleshoot and has abundance of
|
||||
learning materials online.
|
||||
|
||||
\section{Match Three Games and Engines}
|
||||
The world of video games is vast and varied, Offering anything from massive multiplayer role playing games to small mobile puzzles. Match Three games offer players a blend of strategy, pattern recognition, and instant gratification. To better understand the significance of our task in creating a multiplatform Match Three game engine, it's important to trace how the genre evolved, understanding its roots, its development, and its appeal.
|
||||
|
||||
@ -900,76 +829,86 @@ To address these challenges, our engine adopts abstraction layers: by utilizing
|
||||
\section{Core Engine Implementation}
|
||||
For our Match Three game engine, we aimed to create a simple core, capable of ensuring basic gameplay and small codebase allowing developers to extend or modify the engine's capabilities as needed. This section describes the implementation of the Match Three game engine.
|
||||
|
||||
\subsection{Foundational Principles}++++++++++++Several principles guided the design and development of the core engine:
|
||||
\subsection{Foundational Principles}
|
||||
\begin{itemize}
|
||||
\item Platform Independence: Core engine functionalities independent of any specific platform, allowing for easy porting across Windows, MacOS, and GNU/Linux.
|
||||
|
||||
Platform Independence: Ensuring that core engine functionalities remain independent of any specific platform, allowing for easy porting across Windows, MacOS, and GNU/Linux.
|
||||
\item Simplicity: There are no more than 2500 lines of code in the entire engine
|
||||
|
||||
Modularity: Components of the engine are designed as discrete modules, facilitating ease of upgrades and maintenance.
|
||||
\item Good coding style: When writing code, popular coding styles of cpplint and clang-tidy were used
|
||||
|
||||
Performance-Centric: Every design decision and code optimization was taken keeping in mind the need for high-performance rendering and gameplay.
|
||||
\item Good coding principles: when writing code, clang-tidy was extensively used to highlight potential errors and eliminate bad practices
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Core Modules}
|
||||
|
||||
The engine's architecture is segmented into several pivotal modules:
|
||||
The engine's architecture is segmented into modules:
|
||||
|
||||
Renderer: Handles all tasks related to graphical rendering, from drawing sprites and animations to managing shaders and lighting.
|
||||
\begin{itemize}
|
||||
\item Game object: (game\_object.cpp) Defines base class for game objects used by the engine, this class is later used to define tiles
|
||||
|
||||
Physics Engine: Though a Match Three game is not typically physics-heavy, having a light physics engine can add subtle realistic touches, such as smooth tile drops or bounce effects.
|
||||
\item Main Game class: (game.cpp) This class combines all of the other modules and runs the game loop
|
||||
|
||||
Game Logic Controller: Manages the game state, tile matching logic, score calculations, and level progression.
|
||||
\item Game Level: (game\_level.cpp) Loads and saves game levels.
|
||||
|
||||
Audio Manager: Oversees background music, sound effects, and audio cues, adjusting based on game events.
|
||||
\item Particle Generator: (particle\_generator.cpp) Generates particle effects for tiles
|
||||
|
||||
Input Handler: Interprets and routes user input from various devices to corresponding game actionubsection{Dependency Management}
|
||||
\item Post Processor: (post\_processor.cpp) Combines particle and shader effects
|
||||
|
||||
With several libraries like OpenGL, GLFW, and stb\_image being integral to the engine's functioning:
|
||||
\item Resource Manager: (resource\_manager.cpp) Handles assets and shaders files
|
||||
|
||||
Library Wrappers: To maintain platform independence and ease of updates, custom wrappers were implemented for these libraries, ensuring that any library-specific calls are isolated.
|
||||
\item Shader: (shader.cpp) calculates shaders and applies their effects
|
||||
|
||||
Dynamic Linking: This approach was chosen for some libraries, ensuring that the latest library features or optimizations can be leveraged without major engine overhauls.
|
||||
\item Sprite Renderer: (sprite\_renderer.cpp) Renders sprites from images
|
||||
|
||||
\subsection{Extensibility and Customization}
|
||||
\item Text Renderer: (text\_renderer.cpp) Renders text
|
||||
|
||||
Recognizing that developers might have unique requirements:
|
||||
\item Texture Renderer: (texture.cpp) Renders textures
|
||||
\end{itemize}
|
||||
|
||||
Plugin Architecture: The engine supports a plugin system, allowing developers to add new features or modify existing ones without altering the core engine codebase.
|
||||
\subsection{Dependency Management}
|
||||
There are several libraries: OpenGL, GLFW, stb\_image and freetype being integrated into engine, they are simply included at the top of any files that need them.
|
||||
|
||||
Configuration Files: Game parameters, from graphics settings to gameplay variables, are stored in easily editable configuration files.
|
||||
\subsection{Constants file}
|
||||
Game parameters, from graphics settings to gameplay variables, are stored in constants.cpp file, which can be modified, to apply the changes the engine must be compiled again.
|
||||
|
||||
The core engine's implementation is a testament to meticulous planning, iterative development, and rigorous testing. It's the backbone upon which the entire game experience is built. As we delve deeper into specific functionalities in subsequent sections, the importance of a solid core becomes ever more apparent. The Match Three game engine, in its design and implementation, seeks to provide developers a tool that is both powerful and adaptable.
|
||||
\section{Match Three Logic and Mechanics}
|
||||
At its heart, a Match Three game relies on the elegant interplay of logic and mechanics to captivate players, challenging them to align identical items in rows or columns of three or more. While the premise sounds straightforward, achieving a fluid, responsive, and addictive gameplay experience requires a deep understanding of both game design and engineering principles. This section delves into the nuts and bolts of how the Match Three logic and mechanics were implemented within our game engine.
|
||||
Match Three game challenges players to align identical items in rows or columns of three or more. This section describes how the Match Three logic and mechanics were implemented within our game engine.
|
||||
|
||||
\subsection{The Fundamental Game Grid}
|
||||
|
||||
A Match Three game is underpinned by a grid, often rectangular, where each cell holds an item:
|
||||
A Match Three game takes place on a grid, where each cell holds an item (tile):
|
||||
|
||||
Dynamic Grid Generation: The engine supports grids of various dimensions, ensuring adaptability for different game designs or levels.
|
||||
\begin{itemize}
|
||||
\item Dynamic Grid Generation: The engine supports grids of various sizes, ensuring adaptability for different game designs or levels.
|
||||
|
||||
Item Diversity: While classic Match Three games primarily used jewels or candies, our engine supports a variety of items, from animated sprites to 3D models.
|
||||
\item Item Diversity: While classic Match Three games primarily used jewels or candies, our engine supports any kind of 2d image assets user wants to use, these assets can later be processed by user created shaders
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Matching Logic}
|
||||
|
||||
The crux of the gameplay:
|
||||
\begin{itemize}
|
||||
\item Pattern Recognition: The engine monitors the grid, identifies patterns where three or more items align vertically or horizontally.
|
||||
|
||||
Pattern Recognition: The engine continuously monitors the grid, identifying patterns where three or more items align vertically or horizontally.
|
||||
\item Combo Chains: Beyond the basic three-item match, the engine recognizes and rewards larger matches and cascading chain reactions.
|
||||
|
||||
Combo Chains: Beyond the basic three-item match, the engine recognizes and rewards larger matches and cascading chain reactions, enhancing gameplay depth.
|
||||
|
||||
Special Items: Some matches can generate special items with unique properties, such as the ability to clear an entire row or explode surrounding tiles.
|
||||
\item NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION! \sout{Special Items: Some matches can generate special items with unique properties, such as the ability to clear an entire row or explode surrounding tiles.}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Player Interactions and Moves}
|
||||
|
||||
Ensuring a smooth and intuitive player experience:
|
||||
\begin{itemize}
|
||||
\item Drag and Swap: The primary interaction method, where players drag items to swap positions and create matches.
|
||||
|
||||
Drag and Swap: The primary interaction method, where players drag items to swap positions and create matches.
|
||||
\item Move Validation: Not every swap leads to a match. The engine predicts potential matches before finalizing a move, ensuring players don't make invalid swaps.
|
||||
|
||||
Move Validation: Not every swap leads to a match. The engine predicts potential matches before finalizing a move, ensuring players don't make invalid swaps.
|
||||
\item NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION! \sout{Move Limitations: Some levels might introduce a maximum move count, adding a strategic layer to gameplay.}
|
||||
\end{itemize}
|
||||
|
||||
Move Limitations: Some levels might introduce a maximum move count, adding a strategic layer to gameplay.
|
||||
|
||||
\subsection{Game Progression and Levels}
|
||||
|
||||
NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION!
|
||||
\sout{
|
||||
Keeping players engaged:
|
||||
|
||||
Dynamic Difficulty: As players advance, the game introduces larger grids, more item types, or challenging obstacles, ensuring a progressively challenging experience.
|
||||
@ -977,9 +916,12 @@ Keeping players engaged:
|
||||
Level Objectives: Beyond mere matching, players might need to achieve specific objectives, such as reaching a certain score or clearing particular grid cells.
|
||||
|
||||
Reward System: Completing levels or achieving special combos can grant players rewards, from in-game currency to new levels or challenges.
|
||||
}
|
||||
|
||||
\subsection{Challenges and Obstacles}
|
||||
|
||||
NICE TO HAVE, TODO, REPLACE ME IN THE FINAL VERSION!
|
||||
\sout{
|
||||
Introducing variety:
|
||||
|
||||
Static Blocks: Some grid cells might be occupied by immovable blocks, adding a puzzle element to gameplay.
|
||||
@ -987,434 +929,213 @@ Introducing variety:
|
||||
Movable Obstacles: Items that shift position, grow, or change over time, forcing players to adapt their strategies.
|
||||
|
||||
Timed Challenges: Levels where players need to achieve objectives within a set time frame.
|
||||
}
|
||||
|
||||
The allure of Match Three games lies in their seemingly simple mechanics that hide layers of depth and strategy. Through the aforementioned logic and mechanics, our engine offers both the quintessential Match Three experience and the flexibility for developers to innovate, crafting unique gameplay moments. As we transition to discussing other facets of the engine, it becomes clear that the game's core logic serves as the pulse, dictating the rhythm and flow of the entire experience.
|
||||
Our engine offers basic match three experience with couple of additional features added on the top.
|
||||
\section{Integration of Libraries and Tools}
|
||||
The modern game development landscape often involves weaving together a tapestry of specialized libraries and tools, each honed for specific functionalities. For our Match Three game engine, a harmonious integration of several libraries was critical not only for realizing the intended game mechanics but also for ensuring compatibility across multiple platforms. This section delineates the process, challenges, and benefits of incorporating these tools into the engine's framework.
|
||||
In this section we will explain rationality for choosing libraries and tools for our engine and how they were implemented
|
||||
|
||||
\subsection{Rationalizing the Selection}
|
||||
\subsection{ Choice of graphic renderning API }
|
||||
There are 3 main APIs for graphical rendering
|
||||
\begin{itemize}
|
||||
\item DirectX
|
||||
\item OpenGL
|
||||
\item Vulkan
|
||||
\end{itemize}
|
||||
DirectX developed by Microsoft focues on Windows operating systems and
|
||||
Microsoft line of consoles Xbox, it is deemed as being harder with more
|
||||
low level programming and requiring better understanding of how underlying
|
||||
mechanisms work but in turn offers functionalities and better performance.
|
||||
It does not have free license. \\
|
||||
OpenGL is developed by Khronos Group and offers good compatibility,
|
||||
especially if using OpenGL ES subset which works on Windows, Linux,
|
||||
Mac OS, Android, iOS and all major consoles.
|
||||
It is widely recognized as easiest of APIs and most popular choice
|
||||
for writing first game engine. On the other hand it lacks some of
|
||||
more advanced features which have to be written manually.
|
||||
It uses open source license similar to BSD
|
||||
\\
|
||||
Vulkan is also developed by Khronos Group and as such is deemed as a
|
||||
spiritual successor of OpenGL with focus on using modern C++ features and
|
||||
fixing issues created by OpenGL 30 years old development time.
|
||||
Out of these three it is recognized as the hardest one as
|
||||
it is both complicated and newest. Similarly as OpenGL
|
||||
it uses open source license, namely Apache License 2.0.
|
||||
\\
|
||||
Considering all of those characteristics I decided to go with OpenGL API,
|
||||
specifically OpenGL ES subset with its focus on compatibility as
|
||||
making a multiplatform application is one of the focues of this thesis.
|
||||
I decided that since this will be my first attempt at game engine development
|
||||
I need something that is relatively easy and has a lot of resources online.
|
||||
I would most likely not use advanced features of Vulkan and DirectX and
|
||||
therefore finish my thesis before approaching problems where OpenGL
|
||||
does not deliver more complicated architecture.
|
||||
From my own private preferences I also prefer software with
|
||||
open source license.
|
||||
|
||||
Before diving into the specifics, it's crucial to understand the motivation:
|
||||
|
||||
Functionality vs. Overhead: Each library, while offering distinct functionalities, introduces a measure of complexity and overhead. The selected libraries — OpenGL, GLFW, GLAD, FreeType, stb\_image, and ft2build — represented the sweet spot between functionality and minimal baggage.
|
||||
|
||||
Multiplatform Support: A foundational requirement was compatibility across Windows, MacOS, and GNU/Linux. The chosen libraries generally have proven track records in multiplatform support.
|
||||
|
||||
\subsection{OpenGL and the Rendering Backbone}
|
||||
|
||||
As the primary graphics rendering library:
|
||||
|
||||
Version Management: With OpenGL's various versions, it was pivotal to settle on a version that balanced modern features with broad compatibility.
|
||||
|
||||
Shader Integration: OpenGL's shader mechanism was harnessed to produce the vibrant and dynamic visuals characteristic of Match Three games.
|
||||
|
||||
\subsection{GLFW and Window Management}
|
||||
|
||||
A seamless player experience starts with hassle-free game launches:
|
||||
|
||||
Custom Window Configurations: GLFW facilitated the creation of game windows with custom resolutions, full-screen modes, and specific OpenGL contexts.
|
||||
|
||||
Input Handling: Beyond windowing, GLFW was integral for detecting and managing player inputs, from mouse clicks to keyboard presses.
|
||||
\subsection{Choice of OpenGL Library}
|
||||
There are 4 basic OpenGL libraries that I considered:
|
||||
\begin{itemize}
|
||||
\item freeGLUT
|
||||
\item SDL
|
||||
\item SFML
|
||||
\item GLFW
|
||||
\end{itemize}
|
||||
freeGLUT was created as opensource alternative to GLUT,
|
||||
is considered to be the worst out of all 4,
|
||||
written in archaic way, using C or very old C++,
|
||||
which in turn results in unexpected "buggy" behaviour,
|
||||
it is also not really popular with lack of online guides \\
|
||||
SDL - Simple DirectMedia Layer has big userbase,
|
||||
it is not designed to by used as a standalone
|
||||
library and requires additional libraries to do networking
|
||||
or to create more complex applications. \\
|
||||
SFML is the library with most features out of all 4,
|
||||
it supports networking, audio and has system features by
|
||||
default. It uses modern object oriented C++.
|
||||
Main problem with SFML is that it is not very popular API,
|
||||
therefore troubleshooting problems with SFML is quite hard and
|
||||
it has only few use guides online \\
|
||||
GLFW is an library that is both the most popular and with fewest features by default.
|
||||
It forces users to use additional libraries for networking,
|
||||
sound, physic calculations and so on but in turn is also
|
||||
quite small and flexible. It has biggest community and a
|
||||
lot of guides, like one hosted at
|
||||
\href{learnopengl.com}{learnopengl.com} or one created by
|
||||
programming youtuber Cherno \\
|
||||
I decided to use GLFW library. I wanted something that is
|
||||
relatively easy to troubleshoot and has abundance of
|
||||
learning materials online.
|
||||
|
||||
\subsection{GLAD and OpenGL Extension Handling}
|
||||
|
||||
To maximize OpenGL's potential:
|
||||
|
||||
Dynamic Loading: GLAD enabled the dynamic loading of OpenGL functions, ensuring the engine can tap into the latest OpenGL features without being tied to a specific version.
|
||||
|
||||
Extension Management: As OpenGL's ecosystem evolves, GLAD makes it feasible to incorporate newer extensions, keeping the engine at the cutting edge of graphical innovations.
|
||||
GLAD enabled the dynamic loading of OpenGL functions, this way engine can use the latest OpenGL features.
|
||||
|
||||
\subsection{Text and Image Rendering with FreeType, stb\_image, and ft2build}
|
||||
|
||||
Games aren't just about shapes and colors; text and varied image formats play pivotal roles:
|
||||
FreeType and stb\_image were choosen for their simplicity and popularity
|
||||
|
||||
Font Rendering: With FreeType and ft2build, the engine can render sharp, scalable text, crucial for in-game messages, scores, and menus.
|
||||
\begin{itemize}
|
||||
\item Font Rendering: With FreeType and ft2build, the engine can render text, crucial for messages, scores, and menus.
|
||||
|
||||
Image Loading: stb\_image simplifies the task of loading and processing various image formats, from PNGs and JPGs to more complex formats, making asset integration a breeze.
|
||||
|
||||
\subsection{Challenges and Solutions}
|
||||
|
||||
No integration is without its hurdles:
|
||||
|
||||
Dependency Conflicts: There were instances where library dependencies overlapped or conflicted. Solutions involved careful version management and, occasionally, minor code adjustments.
|
||||
|
||||
Performance Bottlenecks: Some libraries, while feature-rich, introduced performance challenges. Profiling and optimization were crucial for maintaining the desired gameplay fluidity.
|
||||
|
||||
The Match Three game engine is a testament to the idea that the whole can be greater than the sum of its parts. By judiciously integrating specialized libraries and tools, the engine offers a robust and flexible platform for crafting delightful gaming experiences. As we delve into subsequent sections, the role of these integrations in shaping the engine's capabilities becomes even more pronounced.
|
||||
\item Image Loading: stb\_image simplifies the task of loading and processing various image formats, from PNGs and JPGs to more complex formats, making asset integration much easier.
|
||||
\end{itemize}
|
||||
|
||||
\chapter{Case Study: Development of a Prototype Match Three Game}
|
||||
\section{Game Concept and Design}
|
||||
While the technical underpinnings of our game engine are fundamental, they serve a higher purpose: to bring to life a captivating Match Three game that engages players and offers a memorable experience. This section delves into the conceptual phase of the project, exploring the ideation, design, and creative processes that shaped our game's identity.
|
||||
|
||||
\subsection{Initial Ideation}
|
||||
|
||||
The germination of the game idea:
|
||||
|
||||
Inspiration: Drawing from classics in the Match Three genre, we aimed to retain core mechanics while introducing unique twists to set our game apart.
|
||||
|
||||
Brainstorming: Multiple brainstorming sessions were held, exploring potential themes, power-ups, challenges, and progression systems.
|
||||
|
||||
Prototyping: Simple prototypes were developed to test mechanics and garner feedback, facilitating iterative refinement.
|
||||
In order to gauge the usability of our game engine, we decided to create a sample match three game using royalty free assets. First part of this process was game design
|
||||
|
||||
\subsection{Game Theme and Narrative}
|
||||
|
||||
The backbone of the player's journey:
|
||||
|
||||
Enchanted Forest: We settled on an enchanted forest theme, offering a rich palette of colors, magical creatures, and a sense of wonder.
|
||||
|
||||
Narrative Arc: Our game follows the journey of a young mage seeking to restore balance in the forest by solving Match Three puzzles, facing various challenges and adversaries along the way.
|
||||
We decided to create a classic gem filled match three game, comparable to old bejeweled games.
|
||||
|
||||
\subsection{Core Mechanics and Gameplay}
|
||||
|
||||
The heart of the game's engagement:
|
||||
|
||||
Basic Matching: Players align three or more identical game pieces either horizontally or vertically to clear them from the board.
|
||||
|
||||
Power-ups and Combos: Special combinations trigger power-ups—like bombs and cross-clears—adding depth and strategy to gameplay.
|
||||
|
||||
Progression and Levels: As players advance, they encounter harder puzzles, with obstacles, varied board shapes, and time constraints.
|
||||
|
||||
\subsection{Visual and Audio Design}
|
||||
|
||||
Crafting a multisensory experience:
|
||||
|
||||
Art Style: Leveraging the capabilities of our engine, we opted for a semi-realistic art style, blending enchanting visuals with a touch of whimsy.
|
||||
|
||||
Audio Landscape: The game's soundscape features soothing forest melodies, punctuated by magical chimes and creature sounds, enhancing immersion.
|
||||
Game utilizes full functionality of our engine, player needs to match three or more gems, chaining matches or achieving higher combos grants the player higher score
|
||||
|
||||
\subsection{User Interface and User Experience}
|
||||
|
||||
An intuitive and engaging interface:
|
||||
\begin{itemize}
|
||||
\item Game HUD: The Heads-Up Display is minimalistic, showcasing only essential elements like score and moves left.
|
||||
|
||||
Game HUD: The Heads-Up Display is minimalistic, showcasing only essential elements like score, moves left, and level progress.
|
||||
\item, Feedback Mechanics: Animations, particles and shaders provide feedback for successful matches and combos.
|
||||
|
||||
Feedback Mechanics: Animations, vibrations, and sound cues provide feedback for successful matches, combos, and level completion, enhancing player gratification.
|
||||
\end{itemize}
|
||||
|
||||
Accessibility: Ensuring that our game is accessible to all, features like color-blind mode and adjustable font sizes were incorporated.
|
||||
|
||||
Game design is an intricate dance of creativity and pragmatism. It demands a vision for what might captivate players while ensuring that the design is technically feasible and complements the engine's strengths. As the ensuing chapters delve deeper into the engine's implementation and performance, it's essential to remember that this design, with its aspirations and nuances, served as the compass guiding those technical endeavors.
|
||||
\section{Application of the Engine in Real-world Development}
|
||||
Building a game engine, while a significant achievement on its own, is only half the battle. The true test of an engine's worth lies in its application in real-world game development. This section elucidates how our multiplatform Match Three game engine was applied to bring our game concept to life, highlighting the challenges encountered, solutions devised, and the nuances of working with an in-house engine.
|
||||
After designing the game, we started creating it using our game engine.
|
||||
|
||||
\subsection{Seamless Integration with Game Design}
|
||||
|
||||
From concept to realization:
|
||||
|
||||
Design Compatibility: One of the foremost benefits was the engine's tailor-made nature, ensuring compatibility with our game's specific requirements.
|
||||
|
||||
Rapid Prototyping: The engine facilitated swift iterations, enabling developers and designers to test new ideas and mechanics quickly.
|
||||
|
||||
Feedback Loop: With a cohesive team of engine developers and game designers, feedback was prompt, leading to more refined gameplay experiences.
|
||||
Since the engine was created exactly with this type of game in mind, brining design decisions to life was very easy
|
||||
|
||||
\subsection{Challenges in Implementation}
|
||||
|
||||
Every tool has its learning curve:
|
||||
|
||||
Documentation Gaps: As a bespoke engine, documentation was initially sparse, necessitating a more hands-on learning approach for developers.
|
||||
|
||||
Toolset Limitations: Unlike commercial engines, our toolset was limited. Developers often had to build tools from scratch or adapt existing ones to suit our needs.
|
||||
|
||||
Optimization Overheads: Being a new engine, many optimization paths were uncharted, demanding more effort in ensuring smooth gameplay across platforms.
|
||||
Biggest challenge was our toolset, we had to either modify the existing engine solutions or create new one from scratch.
|
||||
|
||||
\subsection{Advantages of a Custom-built Engine}
|
||||
|
||||
Why reinvent the wheel?
|
||||
\begin{itemize}
|
||||
\item Optimized Performance: Tailored specifically for a Match Three game, the engine could be highly optimized for this genre, reducing unnecessary overheads. Using OpenGL and plain C++ also added to engine speed
|
||||
|
||||
Optimized Performance: Tailored specifically for a Match Three game, the engine could be highly optimized for this genre, reducing unnecessary overheads.
|
||||
\item Direct Control: Having complete control over engine we could introduce, modify, or remove features as needed.
|
||||
\end{itemize}
|
||||
|
||||
Direct Control: Complete control over the engine meant we could introduce, modify, or remove features as needed without waiting for third-party updates.
|
||||
We were able to create a game using our engine, which means that the goal of this entire thesis was reached.
|
||||
|
||||
Unique Features: We were able to implement specific features unique to our game's vision, setting it apart from competitors.
|
||||
|
||||
\subsection{Lessons for Future Projects}
|
||||
|
||||
Reflecting on the journey:
|
||||
|
||||
Iterative Development: The iterative approach, intertwined with constant testing, proved invaluable in refining both the engine and the game.
|
||||
|
||||
Collaboration is Key: Close collaboration between engine developers, game designers, and artists was essential to bridge the gap between technical feasibility and creative vision.
|
||||
|
||||
Future-proofing: It became evident that building the engine with future scalability in mind, both in terms of features and platforms, would be crucial for subsequent projects.
|
||||
|
||||
Applying our engine in real-world development offered a treasure trove of insights. While challenges were inevitable, they paved the way for innovation, adaptation, and growth. The resultant game, while a testament to the engine's capabilities, also stands as a beacon for future projects, illuminating the path of melding technical prowess with creative ambition. As we venture into the subsequent sections, this hands-on experience with our engine will provide a grounded perspective on its capabilities and potential.
|
||||
\section{Feedback and Iterative Improvement}
|
||||
Feedback is the lifeblood of any creative endeavor. In game development, particularly with a bespoke engine, gathering feedback and iterating upon it is crucial. This section underscores the feedback mechanisms we employed, the resulting insights, and how iterative improvements shaped both our game and the engine behind it.
|
||||
|
||||
\subsection{Feedback Collection Mechanisms}
|
||||
|
||||
Harnessing varied channels to garner insights:
|
||||
|
||||
Playtesting: Organized sessions with diverse players provided invaluable hands-on feedback, from game mechanics to engine performance.
|
||||
|
||||
Surveys and Questionnaires: After playtest sessions, participants were given surveys to provide structured feedback on gameplay, aesthetics, and overall experience.
|
||||
|
||||
Development Team Feedback: Our team's continuous interaction with the engine revealed areas of improvement from a technical standpoint.
|
||||
|
||||
Community Engagement: Online forums and beta releases provided a broader scope of feedback from the gaming community.
|
||||
|
||||
\subsection{Key Insights and Feedback Themes}
|
||||
|
||||
Identifying patterns and areas of focus:
|
||||
|
||||
Performance Inconsistencies: Players noted occasional framerate drops or stutters on specific platforms or hardware configurations.
|
||||
|
||||
Usability Concerns: Some game mechanics or controls were not intuitive to certain players, highlighting UI/UX improvement areas.
|
||||
|
||||
Feature Requests: Players often had ideas for additional power-ups, challenges, or game modes, enriching our feature pipeline.
|
||||
|
||||
Technical Challenges: Developers often pointed out areas where the engine could be more streamlined or offer better tools.
|
||||
|
||||
\subsection{Iterative Improvement Process}
|
||||
|
||||
Acting on the feedback:
|
||||
|
||||
Prioritization: Feedback was categorized by urgency and impact. Game-breaking issues were addressed immediately, while other feedback formed our iterative development roadmap.
|
||||
|
||||
Implementation: The development team would integrate changes, whether tweaking game mechanics, refining the engine, or introducing new features.
|
||||
|
||||
Testing: Every change underwent rigorous testing, ensuring stability and maintaining the game's overall vision.
|
||||
|
||||
Release and Re-evaluation: Post implementation, updates were released, and the feedback loop restarted.
|
||||
|
||||
\subsection{Lessons and Takeaways}
|
||||
|
||||
Reflections on the iterative journey:
|
||||
|
||||
Flexibility is Crucial: The ability to adapt to feedback, sometimes even revisiting foundational decisions, was essential.
|
||||
|
||||
Quantitative vs. Qualitative: While numbers and stats are valuable, qualitative feedback often held the key to enhancing player experience.
|
||||
|
||||
Continuous Engagement: Keeping channels of communication open, be it with playtesters or the broader community, ensured that the game and engine evolved in sync with player expectations.
|
||||
|
||||
Feedback-driven iterative improvement was not just a methodology; it was our guiding ethos. It led to a product that was refined through numerous lenses—players, developers, and the community. As we progressed, this approach affirmed one pivotal lesson: true success in game development lies at the intersection of technical innovation and responsiveness to player needs. The subsequent chapters will delve deeper into the tangible outcomes of this feedback-rich journey.
|
||||
\chapter{Future Work and Enhancements}
|
||||
\section{Potential Extensions to the Engine}
|
||||
While our multiplatform Match Three game engine has proven its worth in the real-world application, the world of game development is in constant evolution. Adapting to emerging trends, technologies, and player expectations requires continuous growth and expansion of the engine. This section will delve into the prospective extensions that can amplify the engine's capabilities and ensure its longevity and relevance in the ever-evolving gaming landscape.
|
||||
While we were able to produce a game using our engine, it still has a potential to grow more and introduce many new features.
|
||||
|
||||
\subsection{Enhanced Graphics and Physics}
|
||||
|
||||
Elevating the visual and interactive experience:
|
||||
Enhancing the visual and interactive experience:
|
||||
|
||||
Ray Tracing: Integrating ray tracing can provide more realistic lighting, shadows, and reflections, enhancing the visual depth of the games developed.
|
||||
\begin{itemize}
|
||||
\item Ray Tracing: Using ray tracing can provide more realistic lighting, shadows, and reflections, increasing visual depth with little cost to an engine user.
|
||||
|
||||
Advanced Particle Systems: Enhancing particle effects can create more immersive environments, from intricate weather effects to more dynamic game elements.
|
||||
\item Advanced Particle Systems: Enhancing particle effects can create more immersive environments, from weather effects to more dynamic game elements.
|
||||
|
||||
Physics Enhancements: Incorporating more advanced physics simulations can lend a more tactile feel to game interactions, from simple collisions to complex motion dynamics.
|
||||
\item Physics Enhancements: More advanced physics simulations can improve feel to game interactions, from simple collisions to complex motion dynamics.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Augmented and Virtual Reality Integration}
|
||||
\subsection{Adaptive Difficulty}
|
||||
Machine learning can analyze player performance and adjust game difficulty in real-time, ensuring a balanced challenge.
|
||||
|
||||
Expanding into immersive realities:
|
||||
\subsection{Real-time Multiplayer}
|
||||
Adding capabilities for online multiplayer modes can increase engagement, replayability and competetivnes.
|
||||
|
||||
AR Support: With AR technology becoming mainstream, adding AR capabilities can open doors for innovative game mechanics and real-world integrations.
|
||||
\subsection{More platforms}
|
||||
Engine could be adapted to work under mobile systems (Android and IOs) and consoles (Xbox, PlayStation and Switch)
|
||||
|
||||
VR Compatibility: Adapting the engine for VR can lead to immersive gaming experiences, capitalizing on the growing popularity of VR platforms.
|
||||
As can be seen there are still a lot of features that can be added to our engine to make it even more useful
|
||||
|
||||
\subsection{Advanced AI and Machine Learning Integration}
|
||||
|
||||
Creating smarter, adaptive gameplay:
|
||||
|
||||
Procedural Content Generation: Using AI to dynamically generate content—like levels or challenges—based on player behavior can keep the gameplay fresh and engaging.
|
||||
|
||||
Adaptive Difficulty: Machine learning can analyze player performance and adjust game difficulty in real-time, ensuring a balanced challenge.
|
||||
|
||||
\subsection{Multiplayer and Networking Capabilities}
|
||||
|
||||
Connecting players globally:
|
||||
|
||||
Real-time Multiplayer: Adding capabilities for online multiplayer modes can exponentially increase engagement and replayability.
|
||||
|
||||
Cloud Integration: Cloud-based features, such as cross-platform saves or cooperative play across devices, can enhance the multiplatform experience.
|
||||
|
||||
\subsection{Modular Plugin System}
|
||||
|
||||
Fostering a community of developers:
|
||||
|
||||
Custom Modules: Allowing developers to create and integrate custom modules can lead to a rich ecosystem of features and tools, expanding the engine's capabilities.
|
||||
|
||||
Marketplace Integration: Creating a platform where developers can share or sell their modules, assets, or tools can further foster community engagement and growth.
|
||||
|
||||
The potential extensions discussed here aim to ensure that our engine remains not just relevant but also at the forefront of game development. By anticipating and adapting to industry shifts, we can ensure a robust, dynamic, and future-ready platform that can cater to an array of gaming experiences, spanning genres and generations.
|
||||
\section{Integrating Newer Technologies and Libraries}
|
||||
The digital landscape is dynamic, with new technologies and libraries emerging at a rapid pace. Ensuring the longevity and adaptability of our multiplatform Match Three game engine requires proactive integration of these advances. This section will delve into the methodology and considerations behind incorporating contemporary technologies and libraries to keep our engine at the forefront of game development.
|
||||
|
||||
\subsection{Evaluation of Emerging Technologies}
|
||||
|
||||
The first step in the integration process:
|
||||
|
||||
Tech Scouting: Regularly monitoring industry news, forums, and events to identify promising technologies that could elevate the game engine.
|
||||
|
||||
Feasibility Analysis: Not all technologies are immediately relevant. Assessing their practicality, impact, and alignment with our engine's vision is essential.
|
||||
|
||||
Performance Metrics: Any potential technology must be rigorously tested for performance, stability, and compatibility with existing engine components.
|
||||
|
||||
\subsection{Library Integration Process}
|
||||
|
||||
Ensuring seamless integration without compromising stability:
|
||||
|
||||
Compatibility Checks: Before integration, new libraries undergo compatibility tests with existing components to ensure there aren't any conflicts or redundancies.
|
||||
|
||||
Modular Integration: Designing the engine's architecture in a modular fashion allows easier incorporation of new libraries without major overhauls.
|
||||
|
||||
Documentation and Training: Whenever a new library is added, comprehensive documentation is created, and training sessions are conducted for developers to ensure efficient utilization.
|
||||
|
||||
\subsection{Case Study: Recent Library Integration}
|
||||
|
||||
To demonstrate the process:
|
||||
|
||||
Library Overview: Detailing a recently integrated library, its features, and the reasons for its addition.
|
||||
|
||||
Integration Challenges: Documenting any obstacles encountered during the library's integration and the solutions implemented.
|
||||
|
||||
Resultant Enhancements: Exploring how the newly integrated library improved the engine's capabilities or performance.
|
||||
|
||||
\subsection{Future-Proofing the Integration Process}
|
||||
|
||||
Ensuring the engine remains adaptable:
|
||||
|
||||
Open Architecture: Designing the engine with an open architecture ensures easier integration of future technologies without necessitating extensive modifications.
|
||||
|
||||
Community Feedback: Engaging with the developer community to understand their needs can help prioritize which technologies and libraries to integrate.
|
||||
|
||||
Continuous Learning: Encouraging a culture of continuous learning among developers ensures that they remain updated with the latest technologies, facilitating smoother integrations.
|
||||
|
||||
Incorporating newer technologies and libraries is not merely about staying current but is intrinsic to the engine's evolution. By maintaining a proactive approach to integration, we ensure that our game engine remains cutting-edge, adaptable, and ready to leverage the best the industry has to offer, resulting in richer, more dynamic gaming experiences.
|
||||
\section{Broader Applicability to Other Game Genres}
|
||||
While the primary focus of our research and development was geared towards creating a robust multiplatform Match Three game engine, it's crucial to acknowledge the engine's potential beyond this genre. The fundamental components, tools, and features incorporated have a broader applicability that can catalyze the development of various other game genres. This section aims to explore the expansive horizons and potentials of our engine when applied to a diverse gaming landscape.
|
||||
|
||||
\subsection{The Modular Nature of the Engine}
|
||||
|
||||
Key to diversification:
|
||||
|
||||
Component-based Design: The engine's architecture, built on modular and interchangeable components, allows developers to swap, modify, or expand elements tailored to different genres.
|
||||
|
||||
Scalability: Whether it's a simple puzzle game or an expansive open-world adventure, the engine's scalable design ensures that it can handle varying degrees of complexity.
|
||||
|
||||
\subsection{Potential Genres and Applications}
|
||||
|
||||
Envisioning the possibilities:
|
||||
|
||||
Platformers: Utilizing the physics, graphics rendering, and character movement modules can facilitate the development of both 2D and 3D platform games.
|
||||
|
||||
Role-Playing Games (RPGs): The engine's asset management, state management, and event handling can be adapted for intricate storylines, character development, and expansive worlds characteristic of RPGs.
|
||||
|
||||
Strategy Games: With minor modifications to the game loop and AI components, developers can build real-time or turn-based strategy games.
|
||||
|
||||
Simulation Games: The precise physics and graphics rendering capabilities of the engine can serve as the foundation for various simulation genres, from life simulations to construction and management simulations.
|
||||
|
||||
\subsection{Customization and Genre-specific Extensions}
|
||||
|
||||
Tailoring for precision:
|
||||
|
||||
Custom Toolkits: While the core engine provides a general foundation, developing genre-specific toolkits and extensions can streamline the game development process for particular genres.
|
||||
|
||||
Library Expansions: Integrating genre-specific libraries can offer specialized functionalities, further enhancing the engine's versatility.
|
||||
|
||||
\subsection{Case Studies: Beyond Match Three}
|
||||
|
||||
Real-world applications:
|
||||
|
||||
Genre Transition: A detailed account of how a developer transitioned from using the engine for Match Three games to another genre, highlighting the changes, challenges, and outcomes.
|
||||
|
||||
Innovative Uses: Exploring instances where developers used the engine in unconventional ways or for genres it was not initially envisioned for.
|
||||
|
||||
The broader applicability of our multiplatform game engine underscores its versatility and robustness. By ensuring flexibility in its design and keeping an open framework, we have inadvertently paved the way for its use across a spectrum of game genres. This not only speaks to its technical prowess but also positions it as a valuable asset in the rapidly evolving world of game development.
|
||||
\chapter{Conclusion}
|
||||
\section{Summary of Achievements}
|
||||
As our exploration into the multiplatform Match Three game engine reaches its conclusion, it is vital to look back and encapsulate the milestones, successes, and breakthroughs achieved throughout this research journey. This section provides a condensed reflection on the significant achievements of this project, thereby offering a comprehensive view of our contributions to the game development industry.
|
||||
In this section we will look back at our project and describe our achievments.
|
||||
\subsection{Multiplatform Support}
|
||||
|
||||
\subsection{Groundbreaking Multiplatform Support}
|
||||
\begin{itemize}
|
||||
\item OS Versality: We successfully developed a game engine that operates across Windows, Mac, and GNU/Linux platforms, addressing the title of this thesis.
|
||||
|
||||
Versatility in OS: Successfully developed a game engine that operates seamlessly across Windows, Mac, and GNU/Linux platforms, addressing the critical demand for cross-platform game development.
|
||||
\item Addressed Platform-specific Challenges: Overcame technical challenges associated with different operating systems, ensuring a consistent user experience.
|
||||
\end{itemize}
|
||||
|
||||
Addressed Platform-specific Challenges: Overcame a myriad of technical barriers associated with different operating systems, ensuring a consistent user experience irrespective of the platform.
|
||||
\subsection{Library Integrations}
|
||||
We managed to itegrate libraries such as GLFW, glad, freetype, stb\_image, and ft2build, all within one game engine
|
||||
|
||||
\subsection{Advanced Library Integrations}
|
||||
|
||||
Cutting-edge Tools: Integrated state-of-the-art libraries such as GLFW, glad, freetype, stb\_image, and ft2build, providing a rich toolset for developers to craft visually stunning and performance-optimized games.
|
||||
|
||||
Holistic Graphics Rendering: Pioneered methods for advanced graphics rendering, leveraging FreeType, stb\_image, and ft2build, enabling detailed and vibrant game visuals.
|
||||
\begin{itemize}
|
||||
\item GLFW/glad: easying the process of using OpenGL
|
||||
\item freetype/ft2build: allowing for rendering text within game
|
||||
\item stb\_image: for ease of importing image assets into game engine
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Robust Game Mechanics}
|
||||
|
||||
Match Three Logic: Successfully implemented a dynamic and responsive Match Three logic that offers smooth gameplay mechanics, setting the foundation for captivating and immersive player experiences.
|
||||
\begin{itemize}
|
||||
\item Match Three Logic: Core match three logic was implemented, matching 3 or more tiles, chain reactions and limited moves
|
||||
|
||||
Asset and Event Management: Established a streamlined workflow for asset management and rendering, coupled with an efficient event-handling system, ensuring the game responds intuitively to user inputs.
|
||||
\item Event Management: The game responds successfuly to user interactions
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Broad Applicability}
|
||||
\subsection{Practical usage}
|
||||
We managed to create a fully functional match-three game, using only our game engine and royalty free assets.
|
||||
|
||||
Beyond Match Three: Demonstrated the engine's potential applicability to a range of other game genres, highlighting its versatility and wide-ranging utility.
|
||||
\subsection{Contributions to the Field of Game Development}
|
||||
Our engine allows aspiring game developers to create their own match three games, and engine developers to learn from it and expand it.
|
||||
|
||||
Innovative Utilizations: Presented real-world cases of developers leveraging the engine for unanticipated genres, affirming its adaptability and robustness.
|
||||
In conclusion, we managed to accomplish all of the goals we set for this thesis, our engine successfuly produces a game for all three operating systems we were aiming for.
|
||||
|
||||
\subsection{Performance Excellence}
|
||||
|
||||
Optimization Techniques: Employed state-of-the-art optimization techniques that ensure games built using the engine run smoothly, even on hardware with limited resources.
|
||||
|
||||
Benchmark Dominance: Our engine consistently performed at the top tier in cross-platform benchmarks, underlining its technical prowess and efficiency.
|
||||
|
||||
In conclusion, the journey to develop a multiplatform Match Three game engine, while replete with challenges, has been immensely rewarding. The achievements summarized above not only serve as a testament to the hard work and dedication invested in this project but also position our engine as a game-changer in the realm of cross-platform game development. These accomplishments not only pave the way for future enhancements and explorations but also offer a beacon of inspiration for aspiring game developers and researchers.
|
||||
\section{Contributions to the Field of Game Development}
|
||||
In the dynamic and rapidly-evolving world of game development, each innovative project can significantly impact methodologies, tools, and industry standards. Reflecting on our work with the multiplatform Match Three game engine, this section illuminates the distinctive contributions made to the broader domain of game development.
|
||||
|
||||
\subsection{Pioneering Cross-Platform Accessibility}
|
||||
|
||||
Democratizing Game Access: By delivering a seamless gaming experience across Windows, Mac, and GNU/Linux, we've diminished platform-exclusive barriers, thus broadening game accessibility for users.
|
||||
|
||||
Unified Development Approach: Our engine facilitates a unified approach to game development, where one core project can be deployed across multiple platforms. This methodology promotes efficiency and reduces redundancy.
|
||||
|
||||
\subsection{Pushing the Boundaries of Library Integration}
|
||||
|
||||
Harmonious Collaboration: Demonstrated the harmonious collaboration of multiple libraries (GLFW, glad, freetype, stb\_image, ft2build) in a singular engine, proving the feasibility of such integrations without compromising performance.
|
||||
|
||||
Blueprint for Future Developers: Our integrated approach serves as a blueprint for developers contemplating the incorporation of multiple third-party libraries into their engines or game projects.
|
||||
|
||||
\subsection{Advancing Game Mechanics and User Experience}
|
||||
|
||||
Dynamic Gameplay: The adaptable and dynamic Match Three logic developed can serve as a reference for those aiming to create engaging mechanics in similar genres.
|
||||
|
||||
User-Centric Development: Our emphasis on intuitive event handling and user input responsiveness pushes the industry towards a more user-centric game development approach.
|
||||
|
||||
\subsection{Versatility and Broader Applicability}
|
||||
|
||||
A Template for Diverse Genres: By showcasing the engine's applicability beyond Match Three games, we've contributed a versatile tool that can be the foundation for myriad game genres.
|
||||
|
||||
Adaptive Engine Architecture: The engine's modular design encourages developers to envision its applicability in various contexts, promoting innovative game concepts and mechanics.
|
||||
|
||||
\subsection{Championing Performance and Optimization}
|
||||
|
||||
Benchmarking Excellence: Through rigorous benchmarking and optimization, our engine stands as a testament to what's achievable in terms of performance, setting a high standard for future game engines.
|
||||
|
||||
Holistic Optimization: Our comprehensive approach to optimization, considering both hardware limitations and software efficiency, contributes a holistic model for performance enhancement in game development.
|
||||
|
||||
In essence, the contributions of our multiplatform Match Three game engine to the game development field are manifold. By setting new benchmarks, introducing innovative methodologies, and exemplifying the power of integration, we hope to inspire a new wave of developers. The ripple effect of our work promises to resonate throughout the industry, encouraging more inclusive, efficient, and innovative game development in the years to come.
|
||||
\section{Reflection on the Development Process}
|
||||
The path of innovation, particularly in a complex domain like game engine development, is seldom linear. It is punctuated by both enlightening successes and instructive challenges. Reflecting on our journey of constructing the multiplatform Match Three game engine, this section delves into the highs and lows, the insights gleaned, and the wisdom accrued during the development process.
|
||||
Creating this game engine was a long process, it took almost a year to bring it to the state it is now in, during this time several reflections came about.
|
||||
|
||||
\subsection{Embracing the Multiplatform Challenge}
|
||||
In order to overcome differences for different operating system, a lot of time was put into choosing correct graphical api and libraries that could work on Windows, GNU/Linux and MacOS. This proved crucial when later developing the engine as this issue did not came back and I could focus on creating the engine itself.
|
||||
|
||||
Initial Hurdles: Venturing into multiplatform development presented a steep learning curve. Early on, reconciling platform-specific idiosyncrasies and nuances required considerable research and adaptation. The process, while daunting at first, underscored the importance of thorough platform understanding.
|
||||
\subsection{Library Integrations}
|
||||
Using multiple different libraries and integrating them with our game engine was a challenge, thanks to existing solutions like learnopengl repository which already overcame those difficulties and KDevelop easy approach to external libraries it was possible to implement all of libraries within our game engine.
|
||||
|
||||
Triumph of Persistence: Despite the inherent challenges of multiplatform support, our commitment to providing a universal gaming experience reinforced our resolve. It was this unwavering dedication that steered us through the more trying phases of development.
|
||||
|
||||
\subsection{Navigating Library Integrations}
|
||||
|
||||
Integration Overhead: Integrating multiple libraries, each with its own set of conventions and requirements, initially seemed like threading a needle in the dark. Achieving a symbiotic relationship between them was one of our most time-intensive endeavors.
|
||||
|
||||
The Power of Collaboration: Consulting with online developer communities, attending workshops, and diving deep into documentation turned out to be invaluable. These interactions not only expedited our integration process but also fostered a sense of communal collaboration in game development.
|
||||
|
||||
\subsection{Evolving Game Mechanics}
|
||||
|
||||
Balancing Simplicity and Engagement: Designing the Match Three logic presented a dichotomy—ensuring simplicity for broad appeal, while also infusing enough depth for sustained engagement. Iterative prototyping and feedback loops were crucial in striking this balance.
|
||||
|
||||
User Feedback as a Beacon: Engaging with early testers and embracing their feedback was instrumental in refining our game mechanics. Their insights illuminated areas of improvement that might have otherwise been overlooked.
|
||||
|
||||
\subsection{Lessons in Optimization}
|
||||
|
||||
Performance Trade-offs: Throughout development, we grappled with trade-offs between visual fidelity and performance. Every added effect or intricate visual required careful consideration of its impact on game fluidity.
|
||||
|
||||
Benchmark-driven Development: Relying heavily on benchmarks, we continually assessed our engine's performance. This metric-driven approach ensured that we were always moving in the right direction, especially in terms of optimization.
|
||||
|
||||
Looking back, the development process of our game engine was as much about personal and team growth as it was about technical achievements. We learned the value of perseverance, the importance of community, and the irreplaceable role of user feedback. As we reflect, we are filled with gratitude for the experiences, both challenging and rewarding, that this journey has bestowed upon us. They have not only shaped our engine but also enriched our perspective as game developers and researchers.
|
||||
\subsection{Time management}
|
||||
Lastly, probably the biggest challenge was managing time for this thesis. Finishing it required a lot of determination, setting barriers and working every day to ensure that the thesis is finished on time. Thankfully past experiences helped in guiding through this task that could be compared to colos\textbf{sus}.
|
||||
\chapter{References}
|
||||
|
||||
\chapter{Appendices}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user