Productivity and Tile Saving Issues

Hello everyone!

I hope to make these blog posts consistently from now, but for starters, a quick update to the upload schedule: I’m going to be doing one video per month, and blog posts in the weeks between those videos. I don’t want to post videos with little content in them (which is what happened with devlog #2). Thank you for the feedback and support on devlog #3! For #4, I’m trying a new format where I record as I develop, instead of creating the videos when I’m done with all of the content shown in the video.


From the time devlog #3 was released, I have been hard at work. I’ve adopted a new schedule, in which my days begin at 5am, and end at around 10:30pm — it has been an adjustment, but it’s been working well for me. I am mostly productive in the morning, and it follows that waking up early maximizes my productivity.

I have also adopted a “sprint” development schedule, a schedule popular in professional development. I have a rough idea of what needs to be completed by which months (in the grand scale of the project), and as those times approach, I break down those big ideas into individual tasks. In Notion, I assign the priority, due date, and point value for each task. Points refer to the amount of time it takes to complete a task, where one point is roughly equivalent to half of a work day (4 hours) or less.

Every two weeks, I plan what tasks will be completed in the following two weeks — this two-week period is referred to as a sprint. With the point system, I can take on tasks and have confidence that I will have time to finish those tasks. Then, once a sprint has been completed, any tasks that are leftover (if any) will be transferred over to the next sprint, and the process repeats.

This may seem like an excessive amount of planning for someone who is working alone, but I have always had trouble in deciding what to do next. In my previous projects (Crevis, a sandbox game), instead of starting the content for the game after I had completed the engine, I would keep going back to perfect systems — a classic case of over-engineering. Scope creep was also a big issue (the scope of the game gradually becoming bigger and bigger).

This new system of planning what tasks to work on tells me exactly what I have to do next, so there is no room for me to go back and revamp systems. When I want to add/revamp a feature, I don’t get to work on it in the middle of the sprint — I have to finish everything planned for that sprint first. Then, I would need to create a new task in Notion, and put that task in the backlog. Then, in the next sprint, I can decide if it will be worked on. It keeps me accountable, and it’s easy to check if I’m on-task or not. I plan to post these sprint boards in the Discord, but I would probably have to blur some stuff out if it were content-related (a note: I’m not really sure how to draw the line between showing too much and showing too little of the game).

Tile Saving Issues

Recently, I went on a vacation to Hawaii and brought my laptop to work on the game in the early mornings. I created a new tile set, and voila — the level tiles broke!

The textures before the change
The textures after the change

What’s happening here is that the newly created tile set and the one that should be used have swapped. GameMaker assigns all assets (including tile sets) an index at runtime. Crucially, these indices are volatile. but when I was creating the tile save system over a year ago, I neglected that fact. So, despite the indices remaining static for over a year with no problems, it inevitable that they would eventually change.

The solution that I have conceptualized is quite simple. I will have a simple JSON object with the names of the tilesets as the key, and the my own static index as the value. These will never change (unless I change them myself) and this file will grow automatically with any additional tilesets. You may be wondering — and reasonably so — why not just save the tileset as a string, and use asset_get_index() to get the GameMaker index? This is because each layer in a level saves two grids: one that holds the tile set index of a cell, and the tile index of a cell, the distinction being that the tile index is the tile within the specified tile set. These grids are then saved as buffers for additional performance.

To make this work with strings, level files would be larger and deserializing the buffers would take longer (in theory). Another solution could be to restrict each layer to one tile set, but I don’t want to do that. I value having multiple tile sets on one layer, and the lack of this feature in the native room editor was very irritating.

There are definitely more optimal solutions to the problem I’m dealing with, most of which would involve rewriting my save system. But a crucial point is that it’s already good enough. It doesn’t need to be re-engineered, because it already works! This is the same problem I would always fall into in my previous projects — I would convince myself that I couldn’t build upon poorly designed systems, and that they undoubtedly needed to be redesigned. In my early projects, this may have been true, but it made every project an unfinished pipe dream. And that is something that Nesus will not be.

So, I will be proceeding with this solution, and in doing so, I will also have to write a converter script to convert levels in the old format to the new format.

Time for me to get to it! I’m not sure if anyone has read this far, and if nobody has, that’s perfectly fine — these posts are more of a development journal. Perhaps I’ll post later this week about basic in-level scripting (sort of) which is a feature that I’ve been very excited about.

Until next time!

Combat Overhaul, Demo, and Delays

Hello everyone,

Two weeks ago, I released the devlog for the combat overhaul, and I realized I haven’t made a blog post about it – so, here it is! Here’s the video if you have not watched it yet.

In summary, I added the new grunt enemy to test out the existing enemy frameworks, and I also added a turret enemy. The addition of these new enemies helped me to set up an enemy system that can be the foundation for all future enemies, and it was also helpful to test the combat mechanics of the player. I also tweaked the dash attack and the downward dash stab – the dash attack now damages all enemies that you dash through, and the downward dash stab locks the direction to straight down.

I also implemented the dash energy bar, which depletes when you dash and regenerates when dealing damage to enemies. In the future, this bar will serve other purposes, but I am still working out those specifics. Visually, I added blood particles, body parts, and flashes to aid the feel of the combat, but there is still a long way to go until it feels as good as I want it to.

Now, jumping to the present: unfortunately I have not been able to work on the game at all for the past couple of weeks. I had to take the time to refocus on school to catch up in certain classes, and as a result I am very behind with this month’s goals. This week is finals week, and afterward I will be able to continue on the game at full capacity.

The combat demo is yet to be released, but during the week of the 21st I intend to release the combat demo, and catch up on much of the lost time from the last couple of weeks.

Despite this setback, this does not change the release date of January 2022. When planning out the development schedule, I allocated a buffer period of about two months to allow for unexpected setbacks.

Once again, I apologize for the lack of updates, but development will continue as normal soon.

Combat/Dashing Tweaks & New Enemy

Hello everyone!

If you’re coming from the Crevis site – welcome! This is the new place for all of my projects and creations. Anyway, back to Nesus. First and foremost: thanks for all the support on the latest devlog! It inspires me that there are people interested in what I’m doing.

February Goals

For February, I’m aiming to release a short combat demo that will feature 3-4 enemies in various combat situations. This will be to test the feel of the combat system, and to make sure that I’m on the right path. We’re already more than a week into February, so I did not come empty-handed to today’s blog post! Here’s a little of what I’ve been working on.

Brute Walking Animation

The first image is a gif of the initial walking/running animation, and the second is a video of me fighting an unnecessarily large amount of these things! The video also shows a bunch of the little tweaks I’ve been doing to combat. To name a few: enemies now flash red and white when hit. In addition, their healthbars flash white to indicate that their health has been decreased. Hopefully this helps to provide more visual feedback to the player to make combat feel better.

On enemies’ death, they will now explode into a bunch of little pieces. I’m planning on adding blood and other particles before the combat demo, but this is where we’re at now! The video also shows me using several different attacks – the standard attack combo, the dash stab attack, and the downward dash stab attack. The standard attack is achieved by attacking normally, the dash stab by attacking and dashing at the same time, and the downward dash stab by dashing down and attacking at the same time.

While the dash stab only does 1 damage, it is effective in damaging several enemies at once. The downward dash stab does 3 damage, making it the most powerful single attack that the player has. I’ve been looking into ways to restrict the use of dashes and dash attacks, and here’s what I’ve come up with.

The Light Energy Bar

There will be a new bar next to the health bar called the light energy bar. This bar will deplete by 60% when using a dash. The dash stab will deplete it by 80%, and the downward dash stab will deplete it by 100%. The only way to replenish light energy is by dealing damage to other enemies, or to objects around the player. The amount of energy gained is something I still have to work out, but this system is to discourage players from hitting enemies, and then dashing away immediately. Instead, the player will be encouraged to take fights to gain light energy so that they can utilize the dash, and more powerful attacks. I’m considering having jumps use light energy as well, to discourage players from jumping away to safety – jumps may use 30% of the light energy.

That’s all for today! If you want to participate in the combat demo, you can do so by joining the Discord (the first couple of users to join will be given access).

Until next time!

Devlog #1 – Level Editor

Hello everyone!
Here’s the first devlog of 2021. I hope to make this a biweekly thing, but I don’t know if I’ll be able to keep that up. I’ll say monthly, just to be safe. Anyway, enjoy the video!

In the beginning of 2020, my friend Nate and I went up to Yosemite for New Years – and it was on this trip that I weighed my options for Nesus. There were only really two options – to use a different game engine that could accommodate my needs for parallax and lighting, or to create a custom, in-game level editor.

I decided to create a custom, in-game level editor, because I did not want to take the time to recreate the game in a different engine. It was the perfect solution – I wouldn’t have to recompile the game every time I wanted to make a change, and I could automate everything about the creation of levels so that I wouldn’t have to do repetitive tasks that disrupt my workflow. Oh, and I could add literally anything to the editor.

UI was difficult in the beginning, but early-on I found IMGuiGML, a port of the popular Dear ImGui development UI framework, perfect for creating editors. For months I worked with more drive than I have ever had in game development – and despite being in school I managed to spend 5-8 hours daily working on the editor. (2)

First, I incorporated the basic necessities first – systems for placing tiles/objects, and a layer system of object/tile layers, with saving specifically in mind. I incorporated tile brush sizes, in addition to making it so that you can place tiles from different tilesets on the same layer. This was something you could not do in GameMaker’s native editor – it required you to use a different tile layer for different tilesets. Internally, tiles are represented by ds_grids – and there are two ds_grids per layer. One grid holds the tile index, while the other holds the tileset index. (3)

After tile/object editing was possible, I had to make it possible to “run” levels. It was not yet possible to play the levels being created. To do so, I created a system called the “editor runtime” – this system deactivates all of the helper objects of the editor (including the object placeholders) and creates all of the instances based on the locations of the placeholders. Tiles did not need to be loaded, as they were already loaded by the editor.

Now that I had the editor runtime, I had to find a way to run a level separate from the editor. As of now, the game needed the editor to run, as it stored many of the data structures and information necessary to “run” a level. I created a new system, dubbed just the “runtime”, which was a little more work, and it runs in a separate room than the editor. The runtime must wipe itself of any old level content, load the tiles, and finally load the instance data, keeping saved variables and save information in mind. I had to recreate the data structures and systems provided by the editor, but in a standalone manner. (4)

Several days later, I completed the runtime, and the foundations for the level editor were complete. Afterward, I sought to solve the issues that plagued me in the first place – first, the parallax editor. I could now adjust the values of the file in real time, and readjust the values based on what I was seeing. I then added the lighting system into the editor – allowing me to view the effects of the lighting in real time and adjust the lighting values accordingly. The work on the level editor was finally starting to pay off! (5)

Following these features, I added the instance variable editor – allowing for the setting and saving of specific instance variables, the variable channel system – allowing for triggers to “trigger” a specific channel and instance variables to listen to specific channels, and generic instance variable saving – which allowed me to specify specific variables that would always be saved in an object, in addition to remembering that object was created/destroyed during the runtime. With the recent addition of the dialogue editor, the editor has become much more powerful than I originally thought, and now I can finally start working on what matters – the content.

TLDR; watch the video! Thanks for reading and stopping by – see you in a few days!

What happened?

Hello everybody,

I must admit that it’s my fault that there has been no activity on the forums or on the site. So much has happened since my last post, and I’ll try to capture it all in this one.

First of all, Nesus was put onto Steam Greenlight. It’s not doing to well at all, and the outcome of the Greenlight is the opposite of what I was anticipating. My first Steam Greenlight project was a learning experience, and now I’m more prepared for future game releases. I’m planning on putting Crevis onto Steam Greenlight before summer ends, and hopefully it will do better than Nesus.

After the first few days of Nesus’s Greenlight, I decided to take a break from game development because it was so heartbreaking to see the Greenlight filled to the brim with “no” votes and negative responses – people didn’t really like the idea of the game.

I’m going to start focusing more on Crevis now, as it’s the game that started all of this.

Until next time folks!

Crevis 2.0

Hello everyone!

It’s been so long since I’ve posted on this website, and for that I’m sorry! Not much I can say, anyway. Today, I came back to Crevis for the first time in a few months, and I realized something…

There’s no way we can get this game up to Steam’s standards anytime soon.

I thought a little bit about my options and what I can do about the situation… in my mind I laid out the many issues with the current build of Crevis.

  • Development is way too slow
  • Little to no control over caves and biomes
  • Full of glitches and bugs in the inventory
  • Extremely laggy when generating more terrain in a world that’s supposed to be infinite
  • The story is 0% complete

So, I thought to myself…

What if I created maps for every playthrough? What if I made the game based more on the story?

I came up with the idea of:

  • Handmade map(s)/universes
  • An entirely separate world for underground exploration
  • Softening the pixelated graphics
  • Redoing the character movement
  • Heavily basing the game off of the story

Thus, the idea of Crevis 2.0 was born! 

Let me know what you think in the comments about this new “Crevis 2.0” (snapshots tomorrow!)

Until next time!

(P.S. Some sprites will come from Nesus!)\

Trailer and GoFundMe!

Hello everyone!

I have been very busy recently with Nesus, and there’s finally a trailer! Woo-hoo! I feel that it’s time to try and get the game on Steam, but before we do that, we need to get our game Greenlit. If you don’t know what Steam Greenlight is, it is the process used to get games onto Steam – a certain amount of votes must be acquired to get the game onto Steam. To get into Greenlight, it requires a $100 entry fee. I don’t have this kind of money, unfortunately, so I started a GoFundMe page that allows people to donate! I’m not expecting to get very many donations, unfortunately, but if I want to get the game on Steam I need to try somehow.

Here’s the link to the GoFundMe:

And here’s the trailer!

Until next time!

I’m back

Hello everyone,

It’s been a while since my last post. I’ve used these months to take a breather – to be refreshed. It has been very stressful in school during these last few months, and I am ready to return to the games that I have promised to release… and these are not promises that I will break. I will work on Nesus 1-2 hours every day, and it should be ready in early October for release.

Crevis is paused at the moment, as I am focusing on Nesus.

I’m sorry for the long stretch of silence… let’s hope that we can have a good end to this development year.

Until next time!

Wrapping up the 1st area

Hello everyone,

We have about 16 levels currently, and, after doing 4 more, we’re going to move onto the next world. Awesome, right? We’re finally on-schedule! We’re going to give 1 month for each area, and, as there are 3 areas, it’ll take about 3 months – finishing the final area in May, and constructing bosses in June.

We’ve also started to work on the trailer for the game, and, after the trailer is complete, we can start looking toward Steam Greenlight and Kickstarter! I would really love to have the game on as many platforms as possible, so we’re going to try and raise $800. Looking at other games’ Kickstarters, it’s quite a low stretch goal – I haven’t needed money until now.

Until next time!

Levels, levels, and more levels!

Hello everyone,

Today is March 14th, 2016… Pi Day! Except… 3/14/16… eh, whatever. Anyway, I’m deeply sorry for the lack of posts recently, just haven’t gotten around to making them. School life has become increasingly work-filled, and, unfortunately, this is clashing with my development schedule. That doesn’t mean I haven’t gotten anything done, though – because I have! And quite a lot, too.

So, over the past week or so, I’ve created a few levels – not, however, finished levels. With my busy schedule I only have time to quickly sketch the idea in the game editor – which takes a total of about 10-20 minutes to do (yes, making levels is that time consuming). Later on I’ll refine the levels and design them completely.

My goal is to completely finish the green area of the game by the end of March – 25 levels or more, plus a boss. All by the end of March. I have about 2 weeks to get it done, so I’m going to try my hardest (not saying I’m not trying my hardest now, but not saying I am either).

I have to admit, though, some of the level concepts I’ve made are pretty challenging… hopefully you guys are up to the challenge.

Until next time!