next »

[Permafrost11]

Hello.

Back in June 2018 I began a project known as "The Ascender", a tower-defense survival sandbox fusion type of thing. It ran for a few weeks, before I abandoned it and started over, marking the "August 2018 revival", which lasted even shorter than the previous iteration.

It's been a year since then.

My interests for the project have changed, and rather than continue to pursue the initial idea I once had, I decided to aim for something different. I'm still creating a voxel-based 3D sandbox, but this time I believe I've come across an idea that feels more original.

Here's a quick screenshot to show off what the game currently looks like:



Since this is the introductory post, I won't go too much into detail about the game's features and development, but I'll update this devlog with ideas, progress, and of course, rants about particular features and concepts.

[Ordnas]

Intersting, the tower defense genre in a sandbox environment also wasn't a bad idea. What engine are you using? Keep us updated 

[Permafrost11]

Intersting, the tower defense genre in a sandbox environment also wasn't a bad idea. What engine are you using? Keep us updated  

Thanks for the interest, I'm using a custom engine that I'm building alongside this project in C++ and OpenGL. I'll still have some defense elements in the game, but in a much different way.

Anyway, onto some catchup posts:

June 10, 2019

The day I started developing this game.

I used a library called GLFW to handle window creation as well as user inputs. You can read up on it here: https://www.glfw.org/. I also use another library called GLM (GL Mathematics) to include the math-related classes so that I don't have to code them myself . I also use GLEW to provide the declarations for OpenGL since most compilers only include the declarations for OpenGL 1.1 (oldest usable version of the API that has very little functionality). Finally, OpenAL to help with audio-related programming and stb_image.h to assist with texture loading.

So with all that out of the way, let's get into the pipeline of how drawing graphics works in OpenGL:  



If you were trying to draw a textured cube, you would need 2 VBOs, one representing the positions of each vertex of the cube, and the other representing the texture coordinates corresponding to each vertex of the cube. Once that's done, while VAOs aren't completely necessary, they definitely help with organizing and defining each mesh, and they also have other benefits in the long run.

When you tell OpenGL to "draw" a mesh, what it's really doing is sending the VAO (which is just an array of VBOs) to the GPU where user-created shaders that use the GLSL language (similar to C) handle various steps of drawing the mesh as described in my extremely clean and professional looking diagram. I mean, what can I say, graphic design is my passion after all.  

The code structure that I use appears like this:



Most of this code was just siphoned from earlier projects of mine, hence why I was able to get it all done in a relatively short amount of time. The reason textures are directly related to the main class is because that's where texture binding is handled, since texture binding is a pretty expensive process in memory.

To summarize:

The mesh object contains the VAO and VBOs for a mesh, and all of it's standalone attributes.
The shader object contains the shader program, which involves the vertex, fragment, and sometimes geometry shader. You can have more than one of these.
The entity object contains the mesh and it's transformations, and as a result handles translation, rotation, scaling, and drawing.
The texture object loads in and contains an OpenGL texture buffer.
The renderer object has all of the main drawing methods that I'm currently using.

At any rate, this was the base I started out with, and used to slowly develop the game over time. I didn't have much time near the end of June thanks to exams and finals, but I did manage to make a couple breakthroughs that led me to this point that I'm quite eager to talk about in my next few posts. I plan on updating this devlog at least twice a week.

EDIT: Siphoned not syphoned. 

[Permafrost11]

Voxels and The Sector System

Voxels in my engine are simply number values (unsigned ints) used by the mesh builder and stored in sectors.

Each sector contains a 32x32x32 array of unsigned ints (positive integers) that can be modified by accessing the array within the sector. Each sector also contains a mesh and entity object, which the MeshBuilder class builds. Basically, the loader I have checks the visibility of each voxel face. For example, if voxel at location 15, 4, 23 is solid and the voxel to it's left (14, 4, 23) is air or some see-through voxel, then that left face of that particular voxel is added to the mesh. Repeat this for all of the voxels, and that's basically the mesh-building process.

However, visibility checks can get a little complicated when it comes to multiple sectors. Fortunately, I have the World Class to sort that out.

Here's a basic diagram of how this process of infinite generation happens:



I won't go too much into detail, especially since I think most of the steps presented here are pretty self-explanatory. But I will say the way of determining which sector you want to use (since all of the sectors are stored within a 1D dynamic array) is handled by doing a quick loop-and-check and returning the index of the sector at the position you want.

That's about all for now. I'm currently experimenting with the game's look, so no new screenshots yet.

[Permafrost11]

Mesh Smoothing

During the first week of July, I began experimenting with different ways to smooth voxel meshes, to reduce the risk of this game being labeled as yet another Minecraft clone .

The first and most obvious choice was to use the famous Marching Cubes algorithm present in games like Astroneer to create smooth features. The issue is...well...I really have no idea how to implement it into my engine. And besides, I wanted to create an algorithm myself, not to create meshes, but to take meshes and smooth the vertex positions. With this in mind, I took a new approach to the problem.

I took each vertex, got it's respective voxel, then scanned through all of it's neighbor voxels to and obtained an average for x, y, and z depending on which voxel in which location was air or not. It's extremely quick since it only loops through the vertices that are already there as a result of mesh loading, and can produce some pretty smooth looking features:



Of course there is a minor issue involving chunk borders not lining up, and my temporary solution to this is just to snap all vertices on chunk borders to integer coordinates. At any rate, that's basically how I handled mesh smoothing. Smaller post today, but I'll hopefully be caught up to my current progress by the end of the week.

[Permafrost11]

Terrain Generation

Ever since I decided to make this project, I always wanted to have a terrain generation system that didn't look boring or basic, and had interesting features that would give each island a distinct "personality" of sorts. Let's go into how I'm trying to make that happen.

At the source of the terrain generation itself lies an algorithm known as "OpenSimplex Noise". You can read up on it and even get the source for Java here: https://uniblock.tumblr.com/post/97868843242/noise. Using 3D OpenSimplex Noise on it's own, with higher values representing solid voxels and lower values representing air would yield different results depending on what the tolerance value for your implementation is. Here's a good representation of what I mean using the older, simpler version of Simplex Noise: Perlin Noise.



The image on the far left is perlin noise, visualized by coloring higher values with lighter colors and lower values with darker colors. The next 3 images show what a low, medium, and high tolerance value would look like in 2D voxels respectively. In order to get this generation to look like actual terrain, all I do is change the tolerance value depending on elevation. The lower the elevation, the lower the tolerance value. The higher the elevation, the higher the tolerance value. The difference between the noise value and the tolerance value is also also useful for determining which voxels should be grass or sand. Of course, there are other features that I'm planning on adding to the terrain generation, such as a 2D noisemap with a high tolerance value to determine where other islands should generate, but in the meantime, here's what the game is currently looking like:

[Permafrost11]

Hello Again

Due to a family trip I took a week-long break from working on the game, but now that I'm back, I got one last interesting thing that I should talk about before getting to what I'm presently working on. One of the last things I implemented before taking that week-long break was a new lighting engine:



For those experienced in GLSL programming and lighting stuff, this is pretty basic. Currently there are two types of lights: directional and point. Directional lighting essentially takes into account the direction a certain face of a mesh is...well...facing, and uses that to calculate how bright the face should be. Point lights are like lightbulbs; illuminating a short (or large) range around them, but not facing any particular direction.

Another thing I also got around to implementing was semi-transparent water. Semi-transparency is a little tricky with OpenGL, as it required the creation of separate mesh-entities for the visible water on each sector that was applicable, but I figured I would take full advantage of this by giving these their own animation:



Finally, I also implemented a day-night cycle after finishing the lighting engine I currently have, which I'll hold off on demonstrating for now since it kinda feels incomplete.

With that being said, this devlog has now officially caught up to the present when it comes to development. So I'll see you when I get around to implementing an inventory system.

[Permafrost11]

The Inventory

Still a WIP, especially the appearance, but the basic functionality of the inventory is pretty much complete! 

When it comes to how I structured the inventory, I created an object called a "Slot" which stores data for a stack of items in the inventory (it contains an id value for the item and the amount value). The first 5 slots make up the "hotbar" as seen to the right. The other 15 are only visible when you open the inventory.

Items are stored automatically when you break voxels, though I'll probably be adding item drops soon. The main features of the inventory are that you can add, remove, and check for items. Some additional functionality is needed, but I think this is enough for my next challenge: Placing Voxels.

[Permafrost11]

Placing Voxels & The Road Ahead

After a whole two hours of work, placing voxels has been implemented. Of course, it's still a little buggy, and it's kinda hard to tell where exactly the voxel will be placed, but it's a start!




Since the development behind this particular feature is rather straightforward and uninteresting to talk about, I've got some plans ahead of me, specifically for when and how I'm planning on releasing this game, as well as the version conventions I'm using.



I more or less use this as a basis for where I am in terms of the project. The release months are placeholder, besides the engine tests. I have no idea how I'm planning on releasing the game and making it available to the public, especially if I'm planning on charging for it later down the road. All of these questions will eventually be answered, so for now I'm not too worried about it.

The next feature I'm adding is probably some new stuff to the world generator, as well as crafting, and this is where my own ideas for the project (not just standard 3D voxel game stuff) starts to come into play, and I'm excited to share these ideas once implemented.