Ordinary Pig is the game that I am currently developing. This page serves to contain assorted information about it.
Ordinary Pig now has a newsletter, which you can join here. These will be rare, so have no fear of advertisement spam. This is currently the best way to stay up to date on what’s happening with the game.
FAQ
What is Ordinary Pig?
– Ordinary Pig is a game I’ve been privately developing since 2022. I haven’t posted much about it, mostly because writing an engine from the ground up requires a significant amount of time investment before anything resembling a game can be formed. I chose to do it this way because there was a lot I wanted to learn, and I wanted the onus of completion entirely on myself, rather than any existing game engines or foundations. I’ve found it much easier to add new or otherwise novel features to the engine having total familiarity with all of the other subsystems at once, which is where the true value of this approach comes from.
What is it about?
– This is hard to answer at this stage of development, but you can expect an ordinary pig to go on an adventure with 2D platforming characteristics, rich physics, and detail-oriented gameplay, allowing for creative solutions and unique interactions. I know that’s a bit of an obtuse explanation, but development is guided by some core principles I’ve found effective from years of prior development experience, and I’m not ready to subscribe to any labels until the game is complete. So as much as I’d like to, I can’t boil it down to “action/puzzle/etc. platformer” or “<thing>-like” or anything like that quite yet. It could be all or none of those things, depending on how things shake out.
Who is the Ordinary Pig?
– For all intents and purposes, Chunks was an ordinary pig, perhaps, save for one thing: he often seemed a little more curious than the other pigs. He was always sticking his nose somewhere, perhaps even sometimes places it shouldn’t belong. And yet for all the trouble it may have brought him, he was a happy pig, for his curiosity had made him a bit more clever, and he always found plenty to eat.
What will it come out on?
– PC first; hopefully with a native Linux port. Then I’ll see about consoles; maybe the Switch? Android could be possible as well but will require some testing to determine if it’s feasible, but I would like to make it available on as many platforms as I can in time. I’m using SDL3 as a hardware backend explicitly so that the porting process is easier, and so that the game can survive using the compatibility layers long after I’m gone.
When will it be done?
– This is a complicated question. I try to work on this every day, and on the days I don’t I’m still actively thinking about it. I’ve set no explicit targets for release yet, because the art comes first above all else. As a direct result I’ve kept the project largely under wraps and have been extremely hesitant to do any kind of crowd funding, since I’m not comfortable taking money for something I can’t presently deliver on a schedule. Plus, I encountered a lot of unexpected personal interference in 2024, so had I said “2025” I’d now be way off track. Engine development takes years, and will even continue once things shift into the the more game-centric development. With all that said I’m good at managing and finishing projects, so short of my untimely demise there will be an initial release within the next few years. I plan to support the game long after that with fixes and free expansions similar to what I’ve done before.
Why… pigs?
– The second half of my about page has roughly the best explanation I’ve come up with so far. What I do want to tell you is not to expect the obvious; this isn’t a joke game where everything is pig-themed for no reason. Those types of games are a dime a dozen, and I don’t personally jive with that style of writing where common pig tropes are all that’s used. So I wouldn’t expect Chunks to explode into bacon or a bunch of pig puns. Think of this as a game, that just happens to star a pig. It could’ve just as easily been about a possum or a beetle.
Update Posts
Below are a handful of posts that I’ve done on the development of the game, listed in chronological order.
…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.