…because this is a project that is going to take a significant amount of time to complete.
I am creating a game, engine and all, from the ground up. After several years working within an existing engine and learning as much as I could, I am ready to see what I can express on my own.
The engine is still very much in development, but after over a year of concentrated effort, it is beginning to take shape. As much as I’d like to reveal more details, the truth is I don’t have very much nailed down creatively yet – all of my focus has been on building a solid codebase. Even the hardware interface libraries I’m leaning on are still subject to change, since there’s a lot to consider at once when going down this path.
One thing is clear to me though – this is happening, no matter what it takes.
I am hoping to reach a point where I can open this endeavor up more to the general public, but it was critical to me that I made sure that it was actually going to happen first. Eventually I will make a formal announcement (both here, and on any socials you can find at the top of the site), and I am hoping to start doing some development streams and posting a lot more on one of these many platforms that I frequent. When that happens, I will update this page. Until then, if you want to know what I’m working on, all I can tell you is that “a pig game” is in active development.
(08-06-23)
The above preface was first written, with only minor revisions to follow. From here, I’ll be adding dates before any updates. While having actual blog posts would make more sense, those usually display in “most recent” order, and I think this page should be read top to bottom.
I’m going to try to keep these minimal, and only post them when I have several important things to say about the game at once, but this first one will also try to set up some foundational stuff for info about the game.
(11-13-23)
I should preface this with the following: a lot of other milestones and systems have already been set up. The foundation of the game’s logic and what that entails shifted immensely prior to this first post, so we’re already starting quite warm, with well over a year’s worth of concentrated development. But going back and chronicling all that could take…a while, so we’re going to just pick up from “recent events.” As things come up, I’ll try to offer relevant explanations.
Near the end of September, I hit an important engine milestone. In this case, what I had was what I’ll call, a “deployable binary.” I’m not always great with using the correct terminology, so I’ll try to explain what I mean. Since the beginning of development, I’ve been using Visual Studio to both compile and debug the game. It’s pretty easy to set up; and after some tutorials you click the funny green arrow and it runs your code.
This is fine for a while, but is obviously not what your end product is going to look like. What I wanted to have was the ability to run the game, completely outside of this environment. This sounds simple, but there’s a lot that goes into making this happen “correctly.”
First, there’s the hardware interface. For pig_game (working title), the first thing I figured out around this was that SDL2 was the best choice for me. I spent a month before I really started this project screwing around with just Vulkan and GLFW before discovering that SDL2 already had everything I needed to get started. The highlights here are that it offers you control of a window, a game controller interface, and some relatively basic rendering tools. It’s also explicitly cross-platform, so despite this example being PC relevant, by the time I’m done pig_game should be compatible with, well, everything it needs to be. This includes future hardware, since SDL is also written to have a compatibility layer, so future versions can run older implementations. Ultimately, for the end user, SDL is just a DLL file that either ships with the game, or with Steam. You may even have this on your computer already!
Next we have the executable itself. Technically this could be seen to come first, but I always tend to think of the first step being what’s going on at hardware level. In this case, since I’m writing C++ and using Visual Studio to compile for Windows, I’m using Microsoft Visual C++, or MSVC for short. I’ll admit, I’m a little fuzzy on what all this entails, but I think the short version is it is yet another DLL file(s) that comes with Windows. It has what’s needed to actually run the program, which includes the implementation of the C++ Standard Library. If I were compiling for Linux, or probably anything else, I’d need to do so through Clang, which has similar stuff going on. I intend to do this as it becomes more relevant.
For the sake of brevity, I won’t go over the details of the statically linked libraries; but my choices have been picky – they’re either written to be as platform agnostic as possible, and/or explicitly integrate with SDL.
Lastly, we have the game data. This is everything from graphics to sounds to scripts – anything that needs to be loaded from a file, that shouldn’t be part of the executable. A big package of all the fun stuff. Right now, this is being compiled by a Python script to a big whopping 27MB .zip file, and I’m accessing that using PhysicsFS, which is a library designed to provide abstract access to files. This was only set up recently, because most libraries that load anything from file can usually do so directly, without the need of an abstraction layer. However, this is a bit disorganized, and there are quite a handful of benefits to using a dedicated management system.
So – why explain all the steps? Well, aside from filling in some much needed details on this project page, with the game finally having a file management system correctly integrated into how the libraries access data, I was able to compile pig_game.exe in release mode, grab the SDL and PhysFS .dll files, and pig_data.zip, and throw it on a flash drive. I then took this flash drive to my old computer with a fresh install of Windows 10, and booted it up.
Instantly I saw a pig. This was a good sign.
You can develop something in a debug environment or a console window for a very long time without having it get in the way. But there was something magical about taking everything I’d done into another room, and just running it, and everything working correctly. It made it feel a lot less complicated, like it was a real game that anyone could just run and play; a “deployable binary.” This felt like a pretty big milestone crossed, even though I know I’ve got months and months of coding ahead of me before this game actually plays like a game, instead of a debug room you’d read about on The Cutting Room Floor.
Since then, I’ve felt a lot more comfortable thinking creatively about the game, compared to the more task-oriented thought process required for pure engine development. I’ve shifted gears a little bit in the last two months towards writing down more notes than code, and among all of that I think I’ve stumbled upon a pretty good title for the game! But, I need to do more research and make sure I can use it properly, so for now, we’re going to keep calling it pig_game.
It will take some time for “the creative process” to unfold. I’m hoping to get a lot more figured out before posting again, but something may come up before then that’s worth an update here.