Today, let’s talk a bit about what I actually want to make with this project, as well as some of my first steps into creating something in Unity.
So what’s all this then?
I’m about to deep dive into my motivations and thoughts behind the project, which may not be everyone’s cup of tea. So, I’ve put the concrete idea up at the top in plain language: I want to build a “life simulator/sandbox” with the primary purpose of producing emergent behavior. With that out of the way, feel free to skip ahead at your discretion.
Why would you do this?
As I mentioned in my last post, I’m taking a lot of inspiration from Dwarf Fortress. For the unfamiliar: it’s a deceptively complex 2D simulation game about an expedition of dwarves establishing a new settlement out in the wild. It’s best known for its steep learning curve, challenging UI, and the developer’s massive ambition in modeling realistic physical interactions in a 2D world. While the game simulates some high-level behaviours such as hunger and thirst, most of the specific details such as where to dig, what to build, and who takes on which jobs is left up to the player. After having played the game for a while, I had the thought: “What if the dwarves could order themselves?” Over the years I’ve abstracted from and built onto this thought, but ultimately this question is what formed the project I’m working on today.
From that question, I started thinking about how it could happen. How would they learn? Could they learn from each other? How would they know how to survive? How would they know what “survival” even is? This was before I had really heard of things like genetic algorithms, but I started dreaming up what was essentially an unsophisticated version of just that. I became enamored with the idea of creating a world with creatures that try to figure out the best way to make their way in it with as little direct input from me as possible.
I have something of a love for abstraction. One of the things that I enjoy most about my job is when I get to break down systems or procedures into their component parts so that they can be more easily reused. Sounds like so much fun, right? So, naturally, over time my ideas progressed roughly from “dwarves” to “humanoids” to “animals” to “living entities.” Gradually I realized that I cared very little about what the things in this world would be, and more about what they would do. And if I created a complex enough simulation, could they learn behaviors that I didn’t explicitly give them?
This train of thought doesn’t really have a terminus station; it just keeps driving on through the minutia of how I’d like to accomplish the above. I’ll probably get into it more in the future, as I’d like to write down more of these thoughts and perhaps be able to look back on this blog as something of a design document, but for now there’s just one more thing I want to touch on:
Where’d the “game” go?
Beyond my “shiny new idea” zeal, I realized that I’ve removed pretty much everything from my initial inspiration that could be considered a “game” or “playable” or “fun.” If the creatures in the world order themselves around, then what does the user do? Why would anyone care about any of this? Interactivity is something that I’ll have to flesh out over time, but I do have some preliminary ideas/principles to build on:
- Expose interesting data. I want to build an interesting world, so it makes sense to let the user learn about it. As I’ve decided to make a 2D game (I’ll touch on this a bit more below), I’ll be limited in what I can demonstrate visually, so this will require some creative solutions. I’m going to do my best to avoid ripping off Dwarf Fortress wholesale, but in terms of representing complex systems in a 2D world, I’m sure it will have its influences.
- Establish a sense of progression. This one is a bit harder to define, and probably even harder to pull off, given the game should be largely unscripted. But I do want the user to feel like time spent with the simulation is building to something. I’m currently tossing around thoughts on giving the user more tools and interactions as they reach certain milestones.
- Let the user poke it. One of the more interesting aspects of simulations is being able to alter its parameters to see what happens. Users have a knack for finding the most unexpected ways of using software, and in this case, that’s something I want to foster. The extent to which the user can poke things could be gamified, and/or tied to some progression mechanic.
Is any of this tangible?
Welcome, at long last, to the game development portion of my game development blog series. As I have mentioned previously I’m very novice to the language and tools that I’m going to be using, so for the moment my goal is more about learning and experimentation. Today’s adventure is in outputting displaying graphics to the screen! [star wipe]
2D, or not 2D?
One of the first decisions I had to make about this game is what kind of graphics I wanted it to have. I’ve known I wanted it to be 2D for quite a while, for a number of reasons. A big one is simply that I have little talent for graphic design, and I want to be able to represent the info being generated by the system in a simple way. This does put some constraints on how the world can physically behave, but that’s not a big setback in my overall plans.
Unity is a 3D engine, but it does have a 2D mode that works just as well. This mode effectively “erases” the game world’s z-axis by fixing the camera perpendicular to the x-y plane, and eliminating visual perspective. Unity also has some 2D-specific components for things like physics which are simpler than their 3D counterparts.
First things first, I need to be able to draw things to the screen. The 2D game tutorial I had already finished taught me how to output sprites (static 2D graphics) to a grid, so I had a bit of something to work with there. I decided to start with simple coloured squares. I’d use brown squares for ground, green squares for grass, and display them in a semi-random distribution. This was pretty simple to put together based on the tutorial code, but the visuals looked somewhat off. The squares weren’t all, well, square.
As it turns out, displaying a sprite in an exact number of pixels on a 2D representation of a 3D world isn’t as simple as it sounds. I don’t intend this to be a tutorial so I won’t get into the nitty gritty, but the short version is that – depending on a bunch of different factors (camera position, screen resolution, pixels displayed per game “world unit”) – sometimes a sprite’s calculated size includes fractions of pixels, which need to be rounded either up or down to be drawn to the screen, resulting in irregularly shaped squares. The even shorter version: math was trying to ruin my game.
So, I started tweaking settings. I laid out the ground and grass tiles in a checkerboard pattern to better see the changes, and got something like this:
I spent a few days trying to resolve this issue, and came close a few times to simply accepting the fact that I’d have funky shaped sprites forever. But with the help of some online tutorials and discussion threads and magic incantations, I found the configuration that I needed to get a “pixel perfect” 2D display. The final piece was setting a fixed resolution for the game display. Please don’t ask me to explain exactly why that’s necessary. But, it worked! And my checkerboard started looking like this:
After that, I modified the ground/grass placement script to make things a bit more natural looking, and adjusted the camera position so that the squares would appear as 4×4 pixels, et voila:
I also made some adjustments so that grass tiles would be placed on top of ground tiles (rather than being placed instead of ground), but that’s uninteresting and visually irrelevant.
Next I make it do things! My idea is to create something similar to Conway’s Game of Life. This will require me to figure out how to get entities in the world to determine things about their own state, as well as the state of the world around them. Stay tuned! There might be a GIF.
beep boop <3