What is "iteration"? It's the process of reworking/adjusting something over and over to eventually get something good.
You could argue that, if you have a solid idea for a game and that it's fairly simple to execute, you could just build your game straight up and not necessarily iterate on it. Build your game, fix some bugs and boom; you got yourself a game! I mean, "7 day game dev challenges" are a thing that people do (and I follow ~ but I don't participate ~ in the Roguelike category so google "7DRL Challenge" to see how that's like) so how essential can that process actually be?
The problem is that, with a few exceptions (like "Myst: the roguelike"), very few of these games are fun beyond the first few minutes of their discovery. Because what can you really do in 7 days besides making something that is playable and doesn't crash? You could have a decent game but a lot of it comes down to the level design... so even if you were to build a game in a really straight forward process (a platformer game that has a simple jump physic), you'd still need to re-iterate on your levels. That's where Q&A and play-testing comes into play.
Iteration is another part of game design that I like to talk about but I'm not going to talk about all there is to it in a single post. This is "part 1" where I don't talk about design but a step that goes BEFORE iterating on a design: how the tech and art can evolve during the process. By "tech", I don't mean how technology or game engines have evolved but more in the sense of how a developer (myself in this case) build systems to enable the game to function... like the Radiant AI for Bethesda Softwork games or their modding/dev toolkit, for example.
Way back in Jan 2014, I talk about four major milestones for my project. Each milestone has its own set of design and tech challenges (something to talk about at a later date) to overcome. I established the first milestone being "world building"; I can't have a game if I can't figure out how I'm going to build the world. For my game, the challenges for "world building" was figuring out how I was going to do procedural generated content and have it work in a multi-player environment. That sounds like a single challenge but it's really two separate ones. Today, I'm going to cover the procedural generation part:
When I started the project, I needed to figure out how the game was going to display the terrain that the player was going to walk on/through. Given the procedural (and random) nature of the game, we couldn't just sculpt the terrain, decorate it and call it a day... because you just can't tell exactly how it's going to be like. Like most Roguelikes, I decided to go with a tiling system (as shown above) but structure it in 3D instead of a 2D top-down perspective that is traditional with the genre.
It worked.
We planned out what we needed for the tiles, the designated 3D artist created the assets while I coded the logic that would place each tile correctly based on a dungeon-generator algorithm that I had created. In this blog post, I talk about how I've rewritten the entire program several times from scratch and improved on it on each subsequent iteration but that's not what I want to talk about. What if you could write complex code that isn't messy or convoluted on the first try? What if the algorithm was perfect (it isn't, but lets pretend)? Where would the iterative process take place?
In the same post, I mention that my team and I came to the conclusion that, while we've figured out a way to draw terrain, it wasn't up to snuff with our standards. Even IF the visuals were generally up to par, there was an issue with how the lighting would hit certain surfaces that made us looking for better alternatives...
We didn't want flat ground, we wanted smooth slopes.
So with the straight-forward approach not working; I turned to Voxels. Short for "[Vo]lumetric pi[xels]", it's a more complicated and mathematical method that tells the computer how to draw polygons (aka: terrain). "Minecraft" and "No Man's Sky", are good examples of games that use voxels at different levels of visual fidelity. Minecraft being the simpler method because it just renders a cube whenever the game recognizes mass/volume.
I'm not going to bore you with the specifics but the picture above is a screenshot of a room filled with voxels; rendering a sphere whenever a voxel would have mass. So, like Minecraft but with spheres instead of cubes. If you can imagine the white spheres as the ground and the red spheres as a rocky surface, you could see that there's an attempt at a varied elevation of terrain.
(In the image above) This is what a similar room would look like if we used that data to generate polygons. Piling up red spheres on top of each other would end up being stalagmites. This is an example of how the interior of a cave would look like, so we started working on exterior environments.
Months later, after a couple of iterations, the basic tech is in place. I worked on shaders for the terrain to draw dirt, roads and grass. The 3D artist started building some trees to decorate the environment and I started working on shaders for vegetation like the leaves on a tree.
Two months ago, I posted this image (above) which is the accumulation of tons and tons of re-iteration on the voxels tech, shaders and the 3D art. To get from the spheres to this is essentially a year's worth of work (excluding the fact that I was also working on other game systems).
You might be wondering what I'm doing with my time since I've not as active on Youtube as I once was. This is what two months of solid iteration looks like:
We haven't touched on the iterative process of game design yet which will be a subject for another day... But I wanted to point out that "being satisfied" and having something "that works" just means you still have plenty to go still...
... and the process never ends...
