Reflection on Progress: Devlog #7

Oh No

         The main purpose of the demo from Sunday was to be transparent about the state of Enchanterland’s development progress. It's difficult to write about what I'm working on to an audience who… can't see what I'm working on. As of right now, the game is quite a step down from bare-bones. It's riddled with bugs and issues that would be unforgivable for a final product. Despite this, putting what I had on the main page seemed necessary to writing actual devlogs as opposed to short essays with only vague connections to the actual project.

         With the demo as a frame of reference, I can now focus much more on writing about whatever direction I'm taking the project in. This log will be a reflection on what's been done, what existing things can be improved, and where I believe I should go from here. Most of it will just be coming from what I observe about the current build. Instead of writing about generalized game design concepts, I can write about the more tailored design decisions I'm making. Hopefully, this will be a nice change of pace from the last several weeks. It'll be like the start of a brand new season for your favorite show, but with way more Skyrim namedrops. Here it goes...

What is Done

         The player character can use basic movement (left/right walking, sprinting, and jumping) as well as basic attacks. Even better, the code for all of these actions is extremely generic. Making a new attack is as simple as creating a resource with all the properties of the attack. A resource, in Godot, is a class used for storing data without the need for a node. The Unity equivalent of a resource would be a scriptable object. Resources are, at risk of putting it lightly, VERY useful. Having the properties (damage, duration, etc.) for every attack just lying in a folder makes everything so much easier. The only reason I can't add all the attacks I want is, as you may have guessed, animation. Making assets isn't as easy as changing up numbers, no matter what ChatGPT tells you. In addition, every “action”, such as jumping or attacking, is managed by a node entirely separate from the entity. This means not every entity needs to use the code for, let's say, jumping. If an entity flies around, then it doesn't have much of a need for the jump script. Some entities might not even need the node that manages attacks.

         The main idea here is that most of the code, as it is right now, is very manageable. I took a few dubious shortcuts to make the deadline I set for myself, but it's nothing that can't be ironed out. However, there are many quirks of how the game plays right now that I also want to fix, not just the bugs. The most obvious mechanical issue that stood out to me during testing was collision. Sure, the collision does cause some jank, but that isn't the main problem. Kobolds will often form a conglomerate and hide one-another from the view of the camera. This, I have found, is a massive complication when designing a 2D platformer around combat. I could allow enemies to collide with each other, but this just causes the kobolds to stumble over each other with how their AI currently works. Ideally, enemies should be able to both collide with each other and get around one another effectively. Finding the right path to dealing with this will take time.

         Something else that stood out was the controls. Originally, they felt intuitive. When there were no enemies to fight, everything felt smooth and functioned well. Then the stupid dumb kobolds ruined everything. In practice, fighting enemies with the extremely limited moveset is very frustrating. One thing I could do is remove the enemies entirely, which would be a very time-effective strategy for dealing with all these issues Unfortunately, this laziness has the potential to backfire. What really needs to change how fluidly the character can get around, and what the player can do to avoid attacks. I mentioned in the first log that I didn't want any instant dodges or dashes, but I think it would be perfectly reasonable to give the player a useful dodge that isn't a total get-out-of-jail-free card. Increasing the overall speed and adding some new options for getting around would absolutely support my idea of a more strategic action platformer. The current sprinting system also just isn't good. The player needs to hold a constant horizontal velocity for a little over two seconds before the character starts moving faster. The idea behind it was to remove the need for a sprint button, but the more obvious solution should've just been to increase the base speed of the character. I also wanted the player to have another way to vary their jump arcs, but that can likely be done just as well from the momentum of a dodge. As mentioned before, the limited speed also makes combat more frustrating. Making it just a little bit less limited will spark improvements on that side of things as well. Sometimes the best solution actually is the easy one; good news for the chronically lazy.

         Finally, I'm fairly proud of the asset work I've done thus far. Most of the animations look fluid, and the individual sprites in the environment are particularly noteworthy. However, I can't shake off the feeling that the surface of the ground is overcrowded. Many tiles in this space seem to obscure the characters a little bit; since the characters have so much stuff behind them. The original idea behind making the background surface tiles so abundant was to make the scene look more natural, so I'm going to look into other ways to achieve this effect. I'll also slightly alter the color pallet of the background tile set so that I can remove the grey tint I put over them. That originally seemed necessary to allow foreground assets to stand out, but the colors will look much better without it. The first thing I'll try is making a wider variety of larger tiles that are more dispersed. If that doesn't work... I'm sure I'll figure something out.

Unrelated screen capture of Skyrim gameplay.

The Next Steps

         Fixing all of the issues with the current build still won't produce a publishable product. Unfortunately, many needy players will likely want more than 60 seconds of gameplay content.  This section will focus on the new systems that I'll likely be adding after the current ones have been cleaned up. Particularly,  I'll be discussing potential systems that would expand upon the systems already in the build, such as attacks or basic movement. I already brought up the idea of a dodge, so let's look into some other additions that may satisfy the completely unjustified user demands for a finished game.

         The main character can currently perform three standard attacks, all with slightly different properties. This includes the standing slash, the overhead swing, and the aerial overhead swing. The system in place for managing these attacks works really well: the "sequence" of the ground attacks are stored in an array (list) of 'Attack' resources.  The air attack is stored in a separate array. This works well for a very narrow set of different attacks, but what if I wanted to add more? What if there was a directional component of each attack input, similar to Super Smash Brothers? Under the current system, I would need more arrays to account for that. The thing is, having a bunch of different arrays for each and every different attack seems like.. a lot. To get out of having to do this, I'm planning to introduce a new resource class entirely: the 'Attack Sequence'. This type of resource would only need to store a couple values: the list of attacks in that sequence, a value determining the direction of this sequence, and the necessary "context" for this sequence to be performed. The list part is self explanatory; a sequence of attacks should have a sequence of attacks... go figure. The 'direction' would refer to what direction needs to be held when the attack button is pressed for this attack to be performed. Holding the 'W' key could result in a different attack than not holding any direction at all, perhaps one that is aimed further upwards. To reduce complexity, I'll most likely design this system so that only vertical directions have an influence on the attack input. This would make it so that the same attacks could be performed whether you're moving around or standing still, and it would also reduce the sheer amount of different attacks available compared to something in the fighting game genre. Lastly, the "context" of the attack would just be a flag that marks if the attack should be performed while grounded or airborne. All this does is arrange things so that I don't need two separate lists of attacks for each state.

         Implementing this new attack system will make a huge difference. The combat is very cut and dry right now, and it didn't take me very long to get tired of spamming the same button. Adding more attacks in this way allows for the addition of some necessary depth while keeping the control scheme very simple. Of course, the enchantments, otherwise known as the entire reason this project exists, will also contribute to making combat more of a strategic venture than a button-mashing fest. The castable spells from these enchantments will likely use a very similar system to the one in place for attacks, although the spells will be cycled in and out of the list much more often. By the time I release the second demo, I'm hoping to have a more fleshed-out combat system than the super primitive one currently in place.

Angled attacks with different properties could add a lot of depth to the game without adding too much complexity, just think of Super Smash Brothers.

         The enemy system needs some iteration as well.  Many parts of the system I described a couple logs ago aren't in the build yet. The kobolds can detect walls that need to be jumped over, but they don't interact with the environment much outside of that. Currently, they can only track the horizontal position of the player; they can't distinguish between the 'y-segments' quite yet. One of the next major steps is fleshing out their AI so that they can function in more level contexts than the layout used in the first demo. Consequentially, I'll also have to design different platform layouts that might show up in actual levels to test whether or not the AI can deal with them.  Now, I don't know about you, but the urge to design obstacle courses for kobolds was the exact reason I became a game developer.

         Depending on what kind of game is being made, the difficulty of the development process can fluctuate pretty significantly as it goes on. In my case, I think development is becoming easier and will continue to in the future. The few game systems I currently have implemented likely only need to be iterated upon to create the new systems brought up in this section. This process may have started off extremely slow, but it will only accelerate with time as I continue to create recyclable codebases and begin drawing new assets and animations more effectively and efficiently. I hope the four of you will stick around to see the progress come to fruition.

Phew

         That's all for now. I'll keep on juggling these essays, the actual project, and college. I have no better use for my time. I hope at least one thing I brought up in here was either vaguely interesting or mildly amusing. I'll likely write a much more focused log next week, but it will still be much more specific to my personal process than past logs have been. With that, I'll be off to file my taxes, or whatever it is normal adults are supposed to do. Good night.