Hello,
In regards to the frequency of these posts; sorry. I'll try to maintain a weekly/biweekly posting schedule moving forward. You can expect these blog posts to go out on either Friday or Saturday. In recent times I have been looking at the cinematic requirements of the game. Certain elements are required to make the game feel cohesive. These may be small things like the transitions between levels, or cutscenes to introduce certain plot points to the player. In response to these needs, I will be developing a cinematics system.

The cinematics system will function similarly to the native timeline in legacy versions of GameMaker. The purpose of the timeline was to execute events consecutively. Instead of events, this system will execute scripts consecutively. For example, imagine a door is about to be opened. Here are the series of events executed once the player touches the door:

1. Transition: Fade in to black
2. Change level: Next level
3. Transition: Fade out

This is a rather simple example, so here is a more sophisticated example, possibly for what may happen when the player enters a boss room:

1. Deactivate: Boss and player movement
2. Camera lock: Boss monster (lock the camera onto the boss sitting on the opposite side of the player)
3. Animate: Boss monster taunting
4. Screen shake: 3 seconds
5. Camera lock: Player
6. Activate: Boss and player movement

The cinematics system should solve transitional and cinematic problems. It is also a more streamlined method of creating desired transitions and screen effects without creating multiple unnecessary objects dedicated solely for the purpose of one effect.

Until next time!

Hello!
Apologies for missing last week's post, but here we are. Unfortunately I didn't meet the February deadline of improving the combat system/creating a system for enemies and their AI. This process will probably be more drawn out, and will take longer than one month. Therefore, these tasks will be something that I complete in March and April.

In other games that I have developed, their interfaces have been clunky and seemingly unprofessional. I want to change that in Nesus, because I feel that a developed interface can solidify the game as a serious project, rather than the work of an amateur. Here are two separate concepts for the item tooltip.

The first example is a condensed version of the tooltip. It shows the item rarity, attack/speed statistics, and its monetary worth in the bottom right.

Overall, I am quite pleased with the result. The only thing that I may want to change is the font used for the currency in the bottom right of the tooltip. Another aspect of the game that I failed to mention was the aspect of discovery - as the player discovers the world, they will be able to find, use, or sell a slew of weapons designed by me, as well as some that may be procedurally generated.

In addition to these UI concepts, I also worked on the sound engine. Sound is vital to having an immersive experience in the game, and I want the music to be seamless in most instances. The engine will consistently run tracks throughout levels, with the capability to play tracks when certain events are triggered, or when the character reaches a certain stage in the level.

​Until next time!

Hello everybody!
Once again, I apologize for the inactivity. I want to outline some of the plans for 2019, albeit I am a little late. This year I will try to remain faithful to the schedule that I set for myself here, though this is a very busy year for me.

I realize that Crevis has been a project of mine for a very long time, and though I believe that it is within my grasp to finish the project, Nesus would probably be a better option right now just because it is less challenging and it is easier for me to be creative with it. I actually have been working on Nesus for the past year, in the little bits of time that I had. What I had done with the game was outlined in the last post.

I also would like to standardize the time of these posts, because I know that people have no clue when I post these. You can expect posts before 11:00 PM on the weekends. Weekends are when I have the most free time, though I may post sporadically on weekdays (for example, today). Weekends for sure, though!

My channel has been inactive for some time now, but will try to put out weekly/biweekly development videos. I cannot promise that every week will be met, though I can say that there will be at least one video per month.​

I really, really want to get this game out this year. Really x1000. I may even get a few other people on board to assist with the development of levels.

I know that I have set many ambitious goals for myself in the past, but I know what I am capable of now. I have set a number of realistic goals for myself so that I am able to achieve what I have outlined within the post.

Now that that's all out of the way, I can finally start talking about nerdy stuff. I thought I had talked about everything I had done with Nesus in the previous post, but this is not true. I totally forgot to mention the lighting system! The lighting system was one of the first things that I wanted to tackle, because of its initial difficulty and its importance to the aesthetic of the game. Here are some fancy screenshots of the lighting system in different environments:

The lighting system utilizes multiple "modes" for drawing. To create the illusion of being inside, everything will be dark except for areas of light. In outside areas, light adds to the ambience of the environment by adding small gradients to art, creating variance. Ultimately, it is a very powerful lighting system and it can basically do whatever I want it to.

A few days ago, I added a debug console using a useful asset from the marketplace. Now, I can configure a series of commands that can help me navigate through experimental levels. Awesome!

That's all for today. Hopefully I'll have a video out this weekend.

Until next time!

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!