Hello everyone!

It's been a while, and I'm not sure if that's forgivable. This past year has been very busy, and schoolwork has consumed most of my free time. Unfortunately, this has meant that I was not able to work on the games as much. Despite my downtime on Crevis, I have still made additions to the game. Before I talk about them, I would like to talk about the changes to the site and its structure.

I have decided to post all of my projects and games on this website. One of the reasons why I was lacking in activity on this site during the past year was because my focus was on schoolwork and on another project, Nesus. I had no way of communicating my progress on Nesus and what I was doing, resulting in the extended period of time between my current post and the last post.

I came to the conclusion that I should write about all of my projects on the Crevis website, as creating a new website would a) be problematic for current viewers, as they would have to make the switch from Crevis to the new website, and b) it would cost more money (money doesn't grow on trees, especially for students).

In order to merge my content, a website redesign was required. I also had intended to refresh the look of the site for a while now. Here is how the blog will work when discussing multiple projects:

• ​​There are now categories that separate the content that posts will be discussing
  • These categories include Crevis, Nesus, Life, Site, etc.
  • ​To view a particular category, locate it on the right hand side of the blog, and click; this will exclusively show content from a particular project or category

 While I will be working on Crevis, Nesus, and other projects much more often as of now, the schedule is tentative, as schoolwork may interfere at any moment.

Towards the end of 2017, I realized that the way data was handled in Crevis was very inefficient. The inefficiency of data handling was leading to loss of performance and memory, and spikes of lag whenever new chunks were generated. This is a very difficult problem to approach, because in my mind I thought I was using an efficient method.

The data structures utilized were ds_grids, and there were three ds_grids per chunk. One would represent block data, another background block data, and the third would represent metadata. Grids must be represented with integers, and for block data grids are optimal.

However, metadata (data that describes each block) must be versatile and must have the capacity to store more information. Metadata tells the game what state a block may be in. For example if the block is on fire, the metadata of the block describes this. Metadata is also used to identify chests, as each chest must have a unique identifier so that their inventories may be saved and retraced.

Metadata was extremely slow to process in the previous iteration of the chunk system, and was a main factor in the cripple of the chunk system. I (currently) have no idea how to approach the problem of storing metadata and am open to any suggestions.

The entire chunk saving/loading system in Crevis is really slow, and I honestly have no idea how to fix it. I have seen other systems that use shaders to save/load, though I do not know the languages associated with shaders in GameMaker. I have also looked into buffers but am unable to get them to work with the system I have set up. Buffers seem to be the only lead that I have, so I had no choice but to break down the current saving system and start from the ground up.

The inventory system is similarly broken, though it is easier to fix than the chunk system, as it requires less memory. I also already have a few ideas of what to do with the inventory system, so it should not be long before it is optimized.

In addition to working on Crevis, I have worked heavily on Nesus, a game that I began in 2016. My motivation for working on Nesus was based solely off of the fact that it was Greenlit on Steam as part of the last batch.
For those that do not know, "greenlight" on Steam indicates that the game was accepted onto the platform.

​Upon its admission to Steam, my vision of the game had completely changed from 2016. A story had festered in the crevices of my brain - one of loss, tradegy, and finding oneself again. I do not want to reveal what the story is, so I cannot give many details. I created a character and completed most of its mechanics (movement, dashing, combat, guns, etc). Here is the progression in design, from the earliest mockups to the final design.

I also created a parallax system that can accept an infinite amount of layers that each possess their own speeds relative to the player. This is achieved by saving parallax data to .ini files.

I used some free backgrounds to test the parallax system, and they work perfectly! The system is well-optimized and versatile, so it should last the duration of this project. There are tons of things I've done behind the scenes, including creating a combat system, dashing system, and fluid animations. I have also begun work on bosses and their mechanics, and I have just been jumping around. Now, I have a clear focus on levels and content and that will be my priority.

Until next time!

Hello everyone!

Sorry for the extensive break I've had from Crevis. I've several things in the past month and a half, most of which are fairly boring.

I first continued where I left off and implemented the day/night system into the game. It looks great, but I plan to add shaders to the sun to give it an edge of realism.

I spent the rest of the time trying to resolve a particularly annoying lag spike, and I've been pressed with a particularly hard decision. A major lag spike happens when entering a new chunk and lasts for about a fourth of a second. It may not seem very long but it can be very annoying when exploring new terrain. Unfortunately, I wasn't able to find a way to remove the lag. One way of reducing the overall lag is to rewrite the inventory system, as its pretty inefficient.

My personal knowledge of memory management and arrays have grown greatly over the past year, and the inventory system that I created last March is not as efficient as it can be. I plan to rewrite the inventory system shortly, which should bump the game's frames up by at least fifty.

Now, onto the meat of the post - using color to store multiple values.
​
make_color_rgb(r,g,b);

The GameMaker coding language doesn't have very many datatypes. For example, a vector3 ​would have easily allowed us to put three values into a grid cell. Unfortunately we don't have that data type. This presented me with a problem. I needed at least one metadata slot, so I created a separate grid to hold metadata. As time went on the need for metadata kept coming up - durability, random block sprites, enchantments, and so on. These are values that cannot be held by a single slot.

I had to find a way to put multiple values into one grid cell. At first I used ds_lists but they ate up way too much memory. I made a post on the forum and someone mentioned make_color_rgb.

This function allows you to create your own colors by inserting a value for red, green, and blue. The value it produces is a 24 bit number that stores the three values, perfect for what I need. Today and tomorrow I will be re-organizing item property lists and will be implementing a system that can incorporate the function into the game.

Until next time!

Hello everyone! I have completed the day/night system in a test room! It now must be put into the game, but that's as easy as dropping the object in the game room. It needs a bit of tweaking and I'm going to replace the sun and moon with proper sprites eventually. Here's what it looks like.

So, how does it work? There are a ton of different elements in within the day/night system that you probably would not have thought of.

Time
The day/night system correlates with the time. Time is a value between 0-1440. There's one minute to an hour, making each day 24 hours. 1440 is the amount of seconds in a day. I will be referring to the numeric value of time (0-1440) as "raw time."

A proportion calculates the angle of the sun based on the raw time. The sun is then drawn on the ellipse at that angle.

In this example, the proportion calculates that the sun should be at 90 degrees on the ellipse at 12:59 PM (780 raw time). It gets the position of the sun from a series of scripts.

The fading backgrounds was done very simply with a phase system. Phases are certain spans of time with specific backgrounds. There is a phase for every fading animation as well as static backgrounds. To get the fading effect, two images are stacked: the image to fade from and the image to fade to. The image to fade to starts with zero opacity and then increases to maximum opacity as time goes on. This system uses NO alarms and is very dynamic.

Until next time!

Hello everybody!

I'm not really sure what happened last month, but I didn't post anything. Oops! In the beginning of the month I was quite busy with school activities, but I started to pick up development towards the end of the month, forgetting about the blog... sorry about that guys! So... here's everything I've been working on/am still working on!

Buffers
I was experiencing severe lag spikes when going from chunk to chunk. I did a bit of debugging and found that the source of the lag was saving the chunks. To optimize it, I made sure that the chunk had been modified for it to save to assure I'm not just saving the same exact thing.

After receiving help on the GMC, it was deduced that the GameMaker function ds_grid_write was slowing the game down immensely, so I tried using buffers (a faster way of saving/loading in short). It worked perfectly except for the fact that I was getting some weird bugs with it so I switched back. I will probably try to get this working again in the future.

Saving objects within chunks
I have also been working on being able to save objects within chunks. These objects are created when the chunks are initially loaded and then deleted when the chunk is unloaded. I am having trouble deleting them when the chunk is unloading, but I think I can get this working by tomorrow or the next day.

Preloading chunks
As you know, severe lag spikes happen when crossing into other chunks. I optimized it a tad by making it so that chunks had to be different than what's already saved for them to be saved again. By preloading all of the chunks, it eliminates pretty much all the lag, which is awesome.

Cellular automata caves
Today, I completed underground cave generation using cellular automata (4-5 rule)! It needs tweaking, but it's a great start. I'm excited to start adding vines, stalactites and stalagmites, and pockets of ore.

I also did some minor things:

• Lightmaps can be toggled visible
• Spawnpoints are now set
• Ice spawns on the top of water in cold biomes
• Water ceases  to exist in hot biomes
• Settings can be set and saved for easy access
• Chests say their ID when opened
• Metadata can now be transferred to objects created by chunkloaders
• Chunkloaders now only unload/load chunks that are just entering the view and not chunks that are already in the view for efficiency
• Cleaned up the code in many places
• Toggled on old animations

Until next time, folks!

Hello everyone!

Sorry for the lack of posts recently - I've been busy with schoolwork (yes, it's that time already). Today I perfected background blocks and made it so that separate chunks are generated for the biome, creating interesting background terrain. Check it out!

I also created lightmaps - essentially, they're grids that store light data (chunk cells that can either be 0 or 1, depending on whether there's a block there). This allowed me to incorporate background blocks with lighting and it also allowed me to create light blocks - more on this tomorrow. However, with all the new additions, I've noticed a surprising drop in framerate. I plan to fill next month with optimizations (or the remainder of this month).

In the screenshots you can also see that the player rig is in complete disarray... still working on it. After I sort the rig out I'll focus on incorporating light blocks & optimizing the game. I'm also going to be implementing water in the near future.

Until next time!