One of the most exciting developments in programming is the introduction of stronger metaprogramming capabilities to C-like multiparadigm languages. Very soon, users of these languages will be able to write meta-code, intertwined with and semantically similar to standard-issue source code, which executes at build time and generates symbols usable by the code which executes at runtime. Metaprogramming will be seen in a conservative form in future versions of C++. It will be seen in a more liberated form as a headliner feature of Jai. Both of these cases represent a clear upgrade in usability, versatility, and comprehensibility from macros and templates.

However, I argue that these strong metaprogramming features must be accompanied by strong "user experience" features. These UX features must provide transparency and convenience to a convention-break

Recently, I decided that Swedish Cubes for Unity would need to have a robust system for serialization and data versioning. This would allow me to avoid getting a bad rap by releasing updates that break people's save data, enable the level designer hired for my own game to start making levels before the tools are fully finished, and finally, to have a leg up on competing products which have some problems in this regard.

This is one thing that has not been covered in great detail by HMH, but thankfully I had another valuable resource. For a while now, I've been exchanging messages on many topics with Alex Evans of Media Molecule, who I got in touch with thanks to Stephanie Hurlburt's software engineer mentor list. Media Molecule's LittleBigPlanet series features somes of the strongest, most easy-to-use, and

EDIT: Unity has announced that future versions of its engine will feature a non-verbose math library with integer-based vectors. Therefore, this repository will no longer be updated, and I encourage you not to use it.

I've updated OHUnityVector a few times and am now quite confident in its correctness and utility :) https://github.com/OswaldHurlem/OHUnityVector

Also please vote on the subject of my next blog post! You have 3 days. https://twitter.com/OswaldHurlem/status/923740365575745536

One of the challenges in writing a Cube-Based Game* system is meshing. In order to quickly draw a large number of cubes, it helps to have large numbers of cubes be grouped together into a single mesh, which gets cached on the GPU. In every cube-based game system I've seen, each mesh corresponds to a fairly large neighborhood called a "chunk." This makes it fast and easy to cull meshes out from getting drawn.

It's common for game engines to represent the position of mesh vertices in GPU memory by assigning, absent any other per-vertex information, 3 floating point numbers to each vertex. Unfortunately, due to the complexity of cube meshes, using this approach results in meshes which are just too large. In an absolute worst case scenario, a 256x256x256 cubit** region could require a set of meshes with 300 million vertices between them. If every one of these vertices stored 3 floating point numbers, that's 3 gigabytes that needs to get stored in memory.

Now, getting my meshes to tak

Ordnance inbound. https://github.com/OswaldHurlem/OHUnityVector

This is the math code I've been using to develop Swedish Cubes for a while now. It provides more vector types/functions for Unity and the C++ code it is wont to interop with. I removed a bunch of the dependencies in the code generator and put it up.

I'm planning to put up a few interesting tech posts soon (within a week), but before that, I want to give some context for them, in the process telling you where I've been for the past few months. With YAVE, I've always entertained the possibility that I'd integrate the features I've written into a larger game engine. A voxel engine is only distinguished from a more typical game engine in a few ways, such as world streaming, rendering, lighting, AI, and physics. Well, that's more than a few ways, but, game development also involves a lot of grunt work, which I'd like to sidestep if possible. Tasks like importing assets, having cross-platform compatibility, running animations, and mixing sounds are all fairly perpendicular to what makes a voxel engine special.

The allure of releasing YAVE as an addtion to a larger engine was reinforced during the experience of making a gameplay prototype in Unity. I felt that the plugins available for voxel game development did not accomplish nearly

Hey all, I'm hoping to get a blog post or two out sometime soon. It won't be news about YAVE, but it'll be an interesting read in their own right. There's quite a few pieces of writing I have on the backburner, including:

• Reflections on using Unity for game prototyping
• Making IMGUI wrappers around a non-IMGUI library like Windows Forms
• A color picker application I'm working on
• Restrictive textures that are not pixel art
• A feature that I would like in every metaprogramming tool

Hopefully once one of these is done, it'll give me momentum to do some of the others. Anyway, haven't forgotten about you. Disappearing now! Bye!

Shortly after reaching a benchmark with my light propagation system, I realized two things. The first was that the development of YAVE has been productive and enjoyable enough that I want to turn it into a finished game. The second was that people -- including fellow game devs in Seattle, other HMN members, and potential investors -- have a difficult time conceptualizing a game which uses a voxel engine but is very different than Minecraft. So I've decided to take some time off from engine development in order to prototype some gameplay in Unity. For the next month or so I'm not going to be very Handmade, but wish me luck anyway. You can follow my twitter for bite-sized updates. For example, two nights ago I managed to jury rig a "level editor" out of an existing level design tool for Unity. Why is "level editor" in quotes? That's for you to find

OR, How I Did Light Propagation Volumes With No Floating Points

I am finishing up the next pass of YAVE's light propagation system and one thing I needed to do was reduce that number of expensive computations that go into spreading light from one block into another. Like Minecraft, the lighting in my game takes the form of a fixed, low-digit number which corresponds to a point on a non-linear curve, but there are key differences. In Minecraft, the light values range from 0 to 16 and correspond to a range from 5% to 98% screen space brightness*. In YAVE, the light values range from 0 to 255, and because YAVE does HDR rendering, these values correspond to a range from 2^-8 to 2^8, chosen because it matches up with a good range of real-world luminance values. Additionally, YAVE does a simplified version of Light Propagation Volumes aka

Quade Zaban has been added as a temporary member of YAVE's development team, and in order to familiarize him with my project, I've had a few recorded skype calls with him that I am now sharing with you! This is the third and last of these, an extra long screencast in which we go over the game code. Special attention is paid to the most complicated and unique challenge presented by a voxel game (so far), which is loading and unloading user-editable resources.

Thanks again to Quade for volunteering to be part of this, and thanks to HMN for providing a place for me to share my work with a greater community.

So last month, our sister in low-level-programming arms, Stephanie Hurlburt, collected a list of experienced software engineers willing to mentor less experienced ones. The very first person on the list caught my eye. It was Alex Evans of Media Molecule, a studio that has used voxel techniques for global illumination for previous games and which was currently working on "Dreams," an insanely cool creative artistic sandbox game for the PS4. If anybody knew how to take the graphical presentation of a Minecraft clone to the next level, it would be him.

So I asked him and he accepted! Note that at the time I believed that "physical lighting" specifically referred to volumetric lighting. In reality, what I want to accomplish with my game and what "physical lighting" means are two circle

Quade Zaban has been added as a temporary members of YAVE's development team, and in order to familiarize him with my project, I've had a few recorded skype calls with him that I am now sharing with you! In this screencast video we go over my build system and the platform layer. I messed up on recording part of it so I recorded a solo screencast (chat #1.5) in which I tell you what I told Quade.

So what do you think? Should I switch to a command list for my rendering API? Should I be ashamed of the extra seconds being added to my build times? Have you opened up your third eye? Sound off in the comments.

I'll begin with an announcement: Quade Zaban has been added as a temporary members of YAVE's development team. Quade has a fair deal of game development experience and shares a lot of game design philosphy with me. He's interested in contributing to this 3D game project in order to provide him with some mental breathing room as he prepares his action-puzzler for publication on Nintendo consoles. In order to get Quade familiar with my project and my codebase, I needed to have a few Skype calls with him. And since I also needed to inform my HMN brethren on what I've been up to, we elected to record our conversations, thereby killing two birds with one stone. So this will be a series screencasts of us discussing the project. The first video will be a grand overview of the game and then a discussion of short term goals. The second will go over the game's platform layer. The third will dive into the game code and its reso

So, one of the things I have to do with my game is change some of the types so that global positions in the game are expressed as double rather than single floating points. If I express positions only using floating points, I can maintain millimeter precision only out to 5 miles from (0,0,0). And that ain't something I'm okay with.

I didn't want to rewrite a bunch of code, I wanted to keep nice naming conventions, and I didn't want to resort to using C++ templates (I've always thought they were goofy). Casey has mentioned the advantages of metaprogramming so I decided to give it a shot.

I used C# since it's a language that comes much more naturally to me than C. C# and .NET have lots of nice string manipulation features so this was a breeze. This was my first time doing metaprogramming, and I followed Snuffleupagus-oriented programming to an extreme. The result is code that does what I need it to do. I am not sure how useful it will be to the the rest of Handmade Ne

100 Todo items later, I have my code up to a place where I'm not embarassed by it. I'm going to be holding a livestream on Wednesday from noon until 2pm PDT. I'm going to show you guys my personal development environment, and then we'll walk through one iteration of the game loop. I might not finish in time, in which case I'll either keep going (if I'm feeling good) or continue on another date. This one will go on YouTube.

https://www.twitch.tv/oswald_hurlem/

Be there!

TBD