On Tuesday, 17 May 2022 at 16:59:31 UTC, Steven Schveighoffer
wrote:
I unfortunately can't try it, as it's not open source, and I
have a Mac. Are there any videos of gameplay?
Hi Steven. Apologies for the lack of a macOS build, I actually
don't own any Apple hardware so my capabilities for testing on
that platform are pretty limited at the moment. That said, all
the dependencies for the engine should work on macOS, so that's
probably something that I could remedy in the future. As for the
video, I'll see if I can something up later today that showcases
the gameplay.
Are there any plans to sell/release the engine?
No plans for selling/releasing the engine, though I would like to
be able to use it to make a game that I can actually sell at some
point.
Can you give a small overview of the engine design?
The engine takes a pretty standard OOP approach and relies
heavily on the concept of 'managers'. There is a base
'Application' class (which can be sub-classed if needed) that
handles a lot of the heavy lifting (window creation, main loop,
input polling), and contains instances of all of the facilities
that actually make it an engine (things like resource/sound/hook
managers, filesystem abstractions and database connections).
As one would would expect with most modern engines, there is a
'scene' management system (which are referred to as contexts in
the engine) that allows for easy implementation of game logic and
rendering. Simply sub-class the base 'Context' class, and you
have access to a set of methods that you can override as needed
(update, draw, keypress, keyrelease, etc...) to implement the
functionality of the scene. When you instance a context, it is
automatically added to the engine's internal context manager, and
can be activated/deactivated at any time. Here is an example of
what that looks like:
```d
class MyContext : Context
{
this(Application app)
{
name = "MyContext";
super(app);
}
override void activated()
{
// Load resources...
}
override void deactivated()
{
// Unload resources...
}
override void update(float delta)
{
// Update stuff...
}
override void draw(RenderWindow window)
{
// Draw stuff...
}
override void keyPressed(Event event)
{
// Key events...
}
}
```
And then instancing and actually using the engine looks like this
(from USG's main.d file):
```d
void main()
{
// create application
auto params = LaunchParameters();
params.windowName = "Untitled Shooter Game";
params.windowSize = Vector2i(1920, 1080);
params.statsEnabled = false;
params.uiAntiAliasing = 0;
params.uiDefaultSkin = "default:dark";
params.windowAntiAliasing = 0;
params.windowStyle = WindowStyle.Titlebar | WindowStyle.Close;
params.entryContext = "MainMenu";
// params.entryContext = "Game";
params.dataPath = "untitled-shooter-game";
auto app = new Game(params);
// create contexts
new MainMenuContext(app);
new GameContext(app);
// start application
app.start();
}
```
Beyond what I just described, the engine contains all kinds of
components geared toward game development. These include things
like timers, faders, oscillators, a SQLite-based registry system,
a basic Lua API, no-gc vectors (really just an abstraction of
std.container.array), and even a custom UI system (which has
become almost as complex as the engine itself unfortunately). It
also has a package of modules dedicated to creating and
simulating 2D top-down worlds, complete with tile-based geometry
and threaded pathing.
It's also very important to note that SFML makes most of the
audio/graphical functionality possible, as the engine relies
heavily on it's API (through CSFML).
Do you use the GC at all?
The engine takes a hybrid approach with it's memory management,
but yes I do use the GC for a lot of it's functionality. Almost
all of the modules that implement the 2D game world do their
allocations outside of the GC (with malloc and the relevant
emplacement functions), which allows for more granular control
over how the simulation's memory works and reduces the burden on
the GC heap. With this reduction of GC heap usage, it allows for
GC-based operations in other parts of the engine without having
to worry too much about triggering an allocation or collection
cycle.
I know GCs are a big source of contention, particularly so among
game developers, but I have to say I've never really experienced
one of the (theoretical) scenarios where a GC ruins a game's
performance or something like that, at least not with the D GC.
It seems to just be a matter of not doing crazy things (like
running heap-based operations every frame) and pre-allocating
everything that you can with pools or something similar.
