Myon: Collect the Cubes!

A very simple game, and the first game made in a small home-made engine I've called "Myon" using SDL2 and D3D11. The game itself isn't all that interesting, but at the same time it's really cool because it's actually a complete game with a start, gameplay, loops, and an actual ending!

This is like the 30th enginedev thing I've attempted, and while some of them have actually gone surprisingly far (only one has been more technically advanced), none ever amounted to anything because they never made a game. Well, now that's changed!

Gameplay

Use WASD or the Arrow Keys to control the little spinning multi-colored cube to collect the larger cubes within the time limit.

There are 6 levels with increasing difficulty.

Will it Run?

I have no idea! It works on my machine, but one of the scariest things about enginedev to me is that there's little guarantee that something will work on anybody's computer. Something like Unity has been battle tested across an insane degree of hardware but I can only test on mine.

Hopefully it works!

YAGNI

I've been pretty strictly following YAGNI (You Aren't Gonna Need It), so the "engine" is extremely barebones. I've been adding features only as I need them as I've been developing this simple game.

There isn't even a depth buffer yet!

I really, really want to see something come of this, even if it means only very basic games, and for that to happen I need to primarily be making a game, and not an engine! I've fallen for that trap more times than I can count.

"Engine" Features

It doesn't do much!

• 3D rendering with 3D cameras
• 2D rendering using a special 2D camera
• Meme resolution divisor for chunky pixels (it's set to 1/2 in this game)
• Can programmatically create simple meshes (quads, cube, triangle, grid)
• Textures can be loaded into materials and materials applied to meshes
• Basic input handling provided by SDL2
• Basic audio handling provided by SDL_Mixer
• Text rendering assisted by BMFont! (This is such a big deal, you have no idea. IMO it's the Great Filter of enginedev.)
• Buttery smooth performance through separation of game and rendering framerates. Gameplay runs at 30 FPS, but you can't tell.

Fix Your Timestep!

That last bullet point is probably the most interesting feature that "engine" natively supports. Because of something kinda idiotic, but provocative, an anonymous person on the internet once said to me about timesteps, I've been obsessed with the smoothness of a video game. To that end, Gaffer on Games' excellent "Fix Your Timestep" article lives rent free in my head. This article is up there with Tom Forsyth's "A Matter of Precision" in terms of how much it's ruined my life.

Getting the "definitive" solution as the end of the article has proven to be a bit tricky. It's a very subtle thing when done right. I don't think most people consciously notice this being poorly, but it does add to the perception of how polished and how well a game runs. For example DOOM 2016 has unbelievably consistent frame pacing and I think that added a lot to how great that game felt.

My big problem right now is I'm not sure how to handle that interpolation between states. From where I'm standing right now, I feel like there's two approaches to this:

1. Keep a singular monolithic "render state" object that keeps track of any information required for rendering, and swap this appropriately between frames.
2. Each object itself keeps track of its own "render state" and is responsible for swapping states between frames by itself.

For this game, I've done the former. It's an extremely simple game so it felt like the easiest thing to do. The only things in it are the position of the player and the positions of the targets plus some small metadata needed for the shrink effect on targets.

Intuitively, I feel like a "single source of truth" is the better approach, but it is a bit awkward when the states require special handling by individual objects (e.g. snapping to a new position). It also feels like halfway to a save system to be able to save/load the game's state at any point.

However, it does seem like it might not scale well with more complex games. I am skeptical of the distributed and disconnected second approach, mostly from a perspective of debugging and keeping things consistent, but it's hard to really say until I try it. Neither option seems "correct" and I haven't found an approach to this problem yet that I think feels ergonomic and "safe" from a developer point of view.