Blog:Hexagons are the bestagons


 * This article is at least partially a continuation of the article Blog:Musings_about_a_potential_Ways_of_Darkness_video_game,_that_will_(probably)_never_be. Read that one first.

Hexagons
You know.... hexagons, are the bestagons.

https://youtu.be/thOifuHs6eY

Sure, the video is a bit silly at times, but it does mention games by the end. What's wrong with square grids? Everything.

Square grids may be easy to program, but they distort space and time: if a certain unit can only move one tile per turn. In real-life, the amount of distance you can cover per any unit of time is completely independent of your angle - effectively, the amount of distance you can cover per unit of time is a radius, and your potential next positions compose a circle. Let me demonstrate.

Meet Dave, our resident stickman:



Let's change our perspective, and move above Mr. Dave, so that our camera is pointing at him from above:



Dave's speed or velocity - the amount of distance he can cover within a specified time frame - is effectively a radius. If we ignore the time it takes for him to change his rotation or angle, then effectively, within a specified unit of time, he can change his position to any place within that yellow circle, but not outside of it. Or he can just not change his position at all - Dave's an adult, he can do whatever he wants.

But what if Dave is a protagonist of a turn-based video game? This is where things get tricky... Let's try dividing the world around Dave into a square grid, shall we?



The green squares represent the tiles he can move onto - if he can only move one tile per turn - and the red squares represent the tiles he can NOT move onto within a single turn. Effectively, moving diagonally would require him to move to turns. A square only has four true neighbours, only four other squares that are of one unit of distance from it. While moving orthogonally costs one unit of time, moving diagonally would involve covering a distance of $$\sqrt{2} \approx 1.4142135623731$$, which then gets rounded up to 2, ergo, it takes twice as much units of time to cover what should be the same distance diagonally. This is highly unrealistic - square grids grossly distort space and time. It effectively costs two units of time to cover the exact same distance depending on whether the movement is orthogonal or diagonal. That's not how it works in real-life.

But what if we used a hexagonal grid instead?



Muuuuuch better. Sure, it isn't perfect, but that's just something we have to live with, if we divide up the world into any kind of grid. It is still far closer approximation of the original circle that represents the amount of distance Dave can cover within a single unit of time. Because a hexagon has 6 true neighbours instead of 4, it won't distort space and time to the extent that a square grid will: moving diagonally

Where was I going again?

Hexagonal Strategy
Now that we've established that hexagons are in fact the bestagons, let's speculate more. Let's say, that hypothetically, I want to make a game. While I do in fact possess the programming skills, I don't have the time and discipline for that kind of dedication and commitment right now - none the less I'm still going to write my thoughts and ideas into an article: this article.

One idea of mine, was to have a kind of strategy game - either purely turn-based, or a hybrid (turn-based overworld, real-time battles). The first idea would be guaranteed to be a blatant ripoff of Heroes of Might and Magic or Age of Wonders (which is basically Heroes of Might and Magic meets Sid Meier's Civilization). The second idea would be more or less the first idea meets Total War. Basically, taking Total War, but putting all the armies, cities, and everything the overworld has, onto a hexagonal map, instead of dividing the world into provinces (or God forbid, risk-style map). In either case, a single hexagonal tile would have a terrain type, it might contain various other attributes too, such as pops if we want to borrow from Paradox Games (though, that might be an overkill, depending on the size of the map). But I digress.

I think I wanted to say more about a potential hexagonal strategy game, but maybe I more or less covered it all in the previous article? Oh well, I have more...

Hexagonal Chunks in First Person?
First, let's talk about chunks. If a video game is relatively small in size, then you don't need chunks. If your first-person shooter or car racing game or whatever takes place on a single, relatively small level, then you can just load in the level geometry and every other asset associated with the level, and call it a day. This is a luxury we cannot afford, if we want to make some sort of open-world sandboxing game (which is what the majority of RPGs are, as well as games like Grand Theft Auto) - we effectively have to divide up the world into chunks or sectors, only load in the ones that are relevant to us at the moment (and do the loading in the background, avoiding loading screens), and quietly dispose of the ones we don't need at the moment to save memory.

Games do this through a variety of ways. Legacy of Kain: Soul Reaver achieved this through cutting the world up into sectors, and only having three sectors loaded into the memory at a time: the one the player was currently located in, the one behind it, and the one after it, completely avoiding loading screens. In Crash Bandicoot, level-dependent game data (level geometry, textures, audio data, even animations) was divided up into 64 kilobyte "virtual pages", with no more than 32 so-called "virtual pages" being loaded into the 2 mebibytes memory of the PlayStation 1 at a time (or less, since you obviously needed space for game executable code too) - this division effectively allowed the game to use up all the space on the disk, instead of padding it with music or FMVs. Last but not least, Minecraft divides up the world into so-called "chunks", each of which consists of 98304 blocks (a chunk is 16 blocks wide, 16 blocks long and 384 blocks tall) - these chunks are streamed into the memory dynamically as the player walks around the world, with chunks that have grown too distance from the player's position simply being unloaded from memory, while new chunks are loaded into the memory as the player gets to new positions.

Now, as I said, I'm not developing a video game, and likely won't be any time soon, but if I was developing a video game, it definitely wouldn't be a voxel game, so we can cross Minecraft out. Instead of a set number of blocks, our "chunks" would consist of... well....

Before I first thought about writing an article about how awesome hexagons are into this Wiki, one of the programming YouTubers I follow posted a video:

https://youtu.be/fSjc8vLMg8c

And this video inspired me, conceptually. Even before that, I already had the idea of making a 3D engine, that's actually more like a 2.5D-3D hybrid in a way, rendering level geometry the way the Doom engine or Build engine do - at least in software mode (I'm still flirting with the idea of implementing both a software renderer, and a hardware-accelerated renderer relying on OpenGL, within my engine) - and rendering everything else like a regular 3D engine would, with monsters, items and other entities being made up of 3D polygons.

Since I mentioned that I wouldn't want to make a voxel game, this is the point where I get back to chunks: the chunks would consist of vectors and portals, basically. Essentially, a single chunk would be the size of a Doom level or Duke Nukem 3D level, but with seamless transition between the levels, with maybe 7 or more chunks being loaded at a time (the chunk the player is located in, plus its six neighbours, plus maybe more). Under the assumption that level geometry will be rather simple - as in, as simple as it was during mid-late 90s video games - it won't be too much of a strain on modern systems that possess RAM orders of magnitude greater.

Since I already hinted at a single chunk having six neighbours, it's pretty obvious, that these chunks would be hexagonal. In fact, a first-person roleplaying game could still have a hexagonal overworld map, where each tile in the hexagonal grid could be given a set of hidden attributes that would manifest themselves during the procedural generation of the levels. Naturally, some maps would be hand-made, but a little bit of procedural generation can't hurt, right? Hell, the hexagonal overworld map could even be made visible to the player, allowing for fast-travel, like in the Elder Scrolls games.

So yeah.... hexagonal chunks in an open-world game, because why not?