The Elder Scrolls and The Legend of Zelda

I could most likely write an entire essay on "open worlds" and "sandboxes" individually and what they mean for games.  Heck, I could probably write an entire blog about the distinctions between the two.

For the sake of this post, I'll give you a quick run-down for those who are wondering:

• "open world" basically means that a particular game world is explorable by the player's initiative.  This is typically done without any story-related or character-progression barriers.
• "sandbox" essentially means that the player is given tools to play however he or she wishes.

It's very common for sandbox games to be open world but the two aren't necessarily inclusive.  "Scribblenauts" being a prime example.  The Legend of Zelda, on the other hand, is one of those series that is traditionally open world without being a sandbox.  Sure, one can decide to muck around and terrorize chickens but most of the player tools (if not all) revolves around combat and solving puzzles in dungeons... and those are traditionally linear.  You can't do anything else.

Open world sandbox games used to be more or less exclusive to the PC gaming category due to the hardware limitations that most consoles had and still (technically to some extent) have to this day.  Putting memory and processing power aside, before the industry learned of the concept of "contextual controls" where a single button could do various actions, consoles couldn't handle what the PC had roughly 84 buttons for.

With that out of the way:

The Elder Scrolls series has been one of the best video game series of that type.  I fell in love with the series starting with Oblivion and that, in turn, introduced me to other similar games like Morrowind, Two Worlds, the Witcher and Skyrim.  Here's the thing, though:  I got my Nintendo Switch (my first "home console" aside from the GameGear and the 3DS; that could be another topic on its own, really) earlier this month and I've been playing The Legend of Zelda: Breath of the Wild on it... I mean, what else could I possibly be playing on it right now?

Anyways, I've played other Zelda games before (The original, Link's Awakening, Link to the Past and Link Between Worlds) but it's not until Breath of the Wild that I've started to compare the series to the Elder Scrolls'... or maybe it's just THAT one game.  I always associated the Zelda series as an action-oriented variant on the adventure "King's Quest"-type of games.  You find items, use them to solve puzzles, give other items to NPCs, progress, etc... and it's on a top-down perspective rather than a side view.

I wouldn't go as far to say that Breath of the Wild is a better open world sandbox games than the Elder Scrolls series ever was; they're more or less trying to achieve different things... but it's definitely better than Skyrim.  Physics and chemistry mechanics aside (which is more or less a product of improved technologies), everything you do in Breath of the Wild feels intuitive.  From the way the game teaches you how to play, to the way you gather and cook food, to how you solve puzzles.  A very stupid (yet appropriate, I find) way of describing it is: it's like playing Oblivion which has fluid game-play, interesting stories and characters, intuitive design but without the game explicitly telling you where you should go.

That's the conclusion I came to earlier today: Zelda Breath of the Wild is to Skyrim what Oblivion is to Skyrim... just without the quest markers.

Zelda has the added benefit of being development by a dev team that understands what "polish" means.  C'mon Bethesda, step it up a notch!  Blizzard Entertainment is too bloated and drunk to understand this, don't you fail me too!

If the next Zelda game turns out to be in first-person view and features a crime mechanic; the Elder Scrolls series is going to have a monster of a competitor to shake off.

Game Update : Iteration part 1

I think anyone who's remotely interested in games and the process of making games knows that iteration is a pretty big part of game development.  What I believe people fail to understand is that iteration is ESSENTIAL to making good games.  When building your game, the first idea is hardly ever good or useable.  You need to salvage your ideas or simply do better.

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...

Game Update : the Accomplishments of 2016

I did it!  After 3 years of hard work (during my spare time, of course), I managed to build within the Unity engine a game system that supports:
- Procedurally generated environments featuring custom made occlusion culling and LOD.
- Day/Night cycle that can trigger specific lighting schemes based on event/location.
- Pseudo-physic projectiles (such as arrows, thrown rocks) that can be picked up.
- Loot table logic.
- A (crude) dialogue interface.

The biggest achievement yet is to get all of that working with four players in LAN (haven't tried over the internet yet); squashing all of the bugs that were found.

Whew!

1) The part where we procedurally generate the environment took a lot of time to develop; mainly because pre-packaged game engines don't really support that kind of thing.  There was a logic issue, there was a memory issue and there was a graphic issue.  All of which are pretty much resolved so my friends know how to build the art and we can implement new stuff without adding too much code.

There's still a lot of work to do, particularly when the game builds cities.  The game doesn't really know how to build houses yet, so a small portion of my time throughout 2017 will be spent on fleshing that out.
My only real concern with cities is hitting a limit on collision objects.  So it'll be a balance between [how many objects can I use to decorate the cities], [how many of those objects can I get away without having collision on] and [how large can I make each city with those decorations].

It shouldn't be that bad, but better safe than sorry.

2) There's still a few tweaks I need to do to make sure the clock remains in-sync between game clients but, overall, the system is practically complete.  I can start looking into creating new environment types to add more variety in the mood; gotta make good use of those old colour-theory classes.

This is the kind of thing you do when you only have a short amount of time available in a given day but you still want to spend that time to work on the project.  You know, mess around with colours after a hard day at the office.

3) Projectiles were fun to work on.  It's not like I'm putting combat mechanics earlier than planned, but I had to figure the server-to-client stuff out... which is why I only mention projectiles as opposed to sword play and what-not.  So I came up with 3 types of possible projectiles that a given player would be firing (arrows, thrown objects and fireballs) and made them work.  Latency issues with projectiles is inevitable but I'm keeping an eye out for any issues.  I haven't any problems yet but, then again, we're testing in a LAN.

Fireballs don't really have any physics to them but they do generate light so I wanted to make sure that casting spells wouldn't break the game's performance.  A neat little thing I added (one of the beauties of the iterative process) is that charging up a fireball (like one would to draw an arrow, by holding down the button) currently increases the size of the fireball... Dragon Ball Z style :P

... and it gives us something to do while we play-test.  I’m not sure we’ll end up keeping the fireball-gets-bigger-as-you-charge thing but we might as well play with it and see if it sticks.

I also took the time to work on stationary objects such as doors, chests and anything other item that one could pick up.

4) Chest objects introduced the concept of loot tables, which allows the game to generate new items to reward the player.  It was an interesting challenge considering, typically in roleplaying games, the results of loot tables are based on the player’s level.  You know, “if player is at level 5, then spawn more magical items”; that kind of thing.  But the game I’m working on has no “level” to speak of so I had to come up with an way to reward players with loot without relying on a linear table.

It functions and what I came up with seems interesting enough on paper; only time will tell if it’ll actually be fun to loot things.

This is what happens when you forget to put a limit

on how many items may spawn on a single chest.

5) The dialogue system was one of the most challenging things I had to come up with; primarily the UI.  How do you build a system that's intuitive, doesn't pause the game during a conversation and allows the player to say pretty much anything he might want to say?  … and possibly allow multiple players to participate in the conversation?

I practically had to delay work on it for a full year (I was supposed to dedicate 2016 to the system) because I wasn't sure how the player would interact with the NPCs.  It's one thing to generate dialogue for the NPCs (not an easy task on its own, but I think I got it figured out) but I wanted to figure out how the player would communicate to the NPCs first.

Not that I'm complaining too much because it did allow me to fix a lot of other stuff in the meantime, but it does sadden me a bit that I've taken yet another delay.  On the bright side, everything's ready to go for 2017 and work on that dialogue.

It's like I can finally build the game, now.