Reflecting on my last post, where I shared the goal of my project, it’s time to get started. Today, we delve into the heart of the project: The Game Engine.
A Game Engine is the backbone of every digital game. Essentially, it’s a software framework that provides the necessary core functionalities to develop and run a game. Rendering, physics simulation, audio management, and more – these are typically the main components of a Game Engine.
Why Build a Custom Engine?
In previous projects, I’ve always preferred a DIY approach – a principle that is deeply embedded in my problem-solving mindset. A brilliant example of this? My experience with 3D printers.
After purchasing my first 3D printer, I took the step to assemble a second and a third printer myself and chose Voron-Design’s printers.The reason for this decision was simple: by assembling the printer by myself, I was able to understand each component in detail. That’s how I learned the ins and outs of 3D printing.
Serial Request Voron V2.4 and V0
This comprehensive approach has paid off. Now I can improve, repair and maintain my printer on my own. If something is wrong, I usually know which screw to tighten or which part to jiggle.
And that’s precisely what I’m aiming for with creating my own Game Engine:
Complete Control: Much like my 3D printer, I want full control over every aspect of the game. I want to know how each line of code and every element of the engine contributes to bringing my game to life.
Learning and Growing: This project is not about game development, at all – it’s a learning journey for me. I am trying to understand every aspect of game development as deeply as I understand the mechanical and electronic components of my 3D printer.
Independent Problem Solving: If something is not working properly, I want to be able to identify and fix the problem myself, rather than having to rely on outside help. However, that doesn’t mean I’m not willing to ask for help.
First Steps Toward the Game Engine
Since I’ve been working with C# for years and have some experience with WPF, this is a more than solid basis to start the project.
For development on macOS, I chose MAUI as the basis for the UI framework. MAUI, the Multi-Platform App UI, is a modern evolution of Xamarin.Forms. It enables the development of cross-platform native applications using .NET and C#. It provides the flexibility I need to design a smooth and engaging user interface and integrates seamlessly into my development environment.
Key Components
ResourceManager (RM): The core of managing all the game’s assets, including graphics, sounds, level data, scripts, etc. It ensures resources are loaded, used, and released efficiently and avoids duplicates.
RenderEngine (RE): The RE is tasked with drawing 2D Pixel Art objects on the screen. It must efficiently render images, animations, and effects while supporting various resolutions and screen sizes.
Physics Engine (PE: Responsible for simulating movements, collisions, and other physical interactions in the game.
Input Management (IM): This system manages user input from the keyboard, mouse, or gamepad and translates it into actions in the game.
Sound Engine (SE): Tasked with playing and managing sound effects and background music in the game.
Scene Management (SM): A system that manages the various “scenes” or “levels” of the game. It dictates what objects are displayed where and when in the game.
Networking (Planned for later): This module will be needed to support multiplayer features. It will handle communication between different instances of the game over the internet.
What’s Next?
In the next post, we will dive deeply into the ResourceManager – the very first and one of the most critical components I will tackle. We will discuss why it’s so crucial and how I plan to approach its design and implementation.
I’d love to hear from you. Have you ever considered building your own Game Engine? Or do you have experience with 3D printers? Share your stories in the comments below – I’m looking forward to hearing about your journeys as well.
