Introduction

Hello everyone, let's gets this out of the way. The one reason I wanted to make this game is well, I just wanted to have SOMETHING to my name as a game developer y'know?  I've had that dream of making a game ever since I was a kid, like literally almost every other modern game  developer nowadays. 

I think I've been trying to learn how to make games for years now and failed due to:

1.  Absolute lack of knowledge in coding. Limiting what I could even do most of the time.
2. In the cases where the engine I'm using doesn't required coding, I never bothered to make a plan or went too big. Thus giving up before the game I was working on was even finished.

I was in this cycle of getting back in, giving up and getting back in again months later. It felt like I was getting nowhere,  along with my own personal flaws, it made me feel down sometimes, and the fact that even someone like Yandere Dev managed to make it further than me really did not make me feel better. 

I think it was only until 2 years ago when I just sat down and just learned a programming language instead of learning how to make a game. I did have a better time doing so! But even  then I did take months long breaks because I didn't know what to make or what I'm trying to learn was to complicated. Looking back at my previous attempt at game development, it was obvious what I did wrong. I also soon realize I didn't COMPLETELY start from zero whenever I try to make a game, as with each attempt, I gain a little bit of experience, and I guess that's what's really important in the end or something.

So here I am, alive for move than 17 years, attempting to make a game again. It's gonna be different this time as the game I want to make is within my skill range, and I have made a plan and a "To Do" list to keep myself on track. I will be doing this without a game engine and I don't think the programming language I'm using is really relevant.

The Game

Finally,  let's talk about the game, I spent way too long talking about my sappy backstory that million others already when through. The gist of this game is simple,  so simple that it can fit in the title of this post. All you have to do is complete an list of objectives and exit to win, but of course , it's  never that simple right?

The idea is that the only primary way you have to defend yourself from enemies is a Musket with a long reload time. On top of that your shot accuracy depends on how fast you're moving. Only shooting with perfect accuracy if  you standing completely still. To make things worse, you don't really move really fast by default and you're squishy so enemies can kill you really fast.

There are other methods the player has to survive is their Secondary Item which uses a resource called "Spades" and their  Dash which I will not delve into how that mechanic  will work, but I can say that it will have a very long cooldown so don't waste it.

I want it so that precision is important and the player has to take their time as more than one enemy targeting you could mean game over if they're not careful. I am taking notes from The Legend of Zelda and Castlevania for mechanics and I will be using an NES color palette for the graphics.

Progress Report

It's been 20 days since I started working on this and I've finished what I considered to be the Prototype or Minimum Viable Product. Now, I know it looks like all you can do is run around and shoot inanimate object, but believe me, there's like a lot going on under the hood, and there's is tons a things I have to write just to get something playable. 

Here's a video and a couple pictures of the Prototype:

So what do you think? I would really appreciate your feedback! I'll be posting updates on my progress.

Progress Update - July 29th,  2023

Hello, I'm  back with another update. It's been like two days and I done quite a bit. Stuff like cleanup, optimizations , tweaking variables, and all that. I'm here to showcase  a core  mechanic in the game and it's uses: Dashing (or orbiting, I'm still thinking about the name , considering it's not really dashing.)

As you saw in the video , instead of directional dashing, the player orbits around the  mouse cursor 's position relative to what  it position would be in the level. This simple change allows for unique opportunities . The player could dash around obstacles or to  safety. I've even made a last second decision to make it so the camera stops following the player when dashing and added a little window of opportunity to get a shot in before the camera repositions itself. The cooldown time has been shortened in this video for the sake of  testing and the convenience. I'm intending for the cooldown time to  be at least 20 seconds.

What's next?

I'm planning to smooth out camera movement when dashing as it can get pretty disorienting . Maybe after that, I may add basic GUI.  As of now, I consider this game to be in the pre-alpha stages. I'm not sure when I would consider this game to be in alpha, but I'll most likely consider this game to be  in Beta once there is a win and lose condition but it'll take a while before I'll get to that.

Well, see you later.

Progress Update - August  20th, 2023

Hello everyone. After 23 days, I've climbed from the everlasting darkness that is page 4; to bring you another progress update. Not gonna lie it's been a bit since I last posted .  I thought creating the HUD and the first enemy would only take a couple days, but I became occupied with other things.

Here's a list of roughly everything I did during these 23 days. Luckily I already have a list ready to copy and paste in. 

• Implementation for the foundation for Enemy AI
• A proper implementation of the pause feature, capable of pausing timers as well.
• Reworked audio system for sound effects. Now a function can be called to play a specific sound effect on any inactive sound channel
• Cleaned up the GUI and written a Progress Bar class for future use
• Added "Armor Points to the Player which acts as damage reduction and sometimes as a second health bar.
• Written an entity event handler for deleting entities and other stuff in the future
• Rewritten the chunk system and how collisions are checked for better performance.
• Written an entire freaking particle system!
• With all that, I created a new enemy called the Spider.
• A bunch of bug fixes and tweaks.

As you can see, during the development of the Enemy AI. I kept feeling the need to do optimize and rewrite certain systems to improve them. I found that I need to write entirely new systems to  make the  new Enemy work! Don't get me wrong, I enjoyed doing all these things and I know that all the work I put in would really help me in the future and makes things faster. At the time of writing this, I remembered starting to work on the Enemy AI shortly after the beginning of this month.

There are  a couple things I want to explain in more detail.

While implementing this , it has gone through a couple iterations. I don't really know how to draw well, but I do have a bit of experience doing pixel art so I'm kind of glad of how it turned out. Of course, it's not the final result. There may still be  more changes to come. Other than that,  what the HUD will contain is self-explanatory and it already accomplishes it's purpose alright. The segmented bar design is inspired by the classic  Castlevania games.  You may notice a common theme of me taking a couple things from the Castlevania series.

Armor (AP)

Although the idea of adding Armor/Temporary Health has been in my head since before  the development of this game even began. I was just shrugging it off as something I thought was " not needed" until very recently. I saw two ways I could go about implementing this mechanic. I could make it so Armor just reduces damage you take or just have Armor act essentially  as a second Life bar. The first method was too boring ,and I thought the second method was too op for the game I'm trying to make.  So I tried to combine the two methods... only to realize much later that I basically written a glorified version of the second method... oops. Well, I did have fun implementing Armor into the game and writing the damage calculations,  so all's well that end well I guess.

Spider

After adding the Life bar to the game, I thought that the logically next step would be  to add something to damage the player. Enemies are important as they will be one of the few obstacles to the player. Ladies and Gentlemen, I present to you the thing the was working on for the past 18 days!

How the Spider behaves is very simple. It will chase the player once they enter their radius and perform a lunge once the spider is close enough to the player. That's it, this is what I've spent 18 days making... Granted, since this is the first enemy, I had to write the foundation that all future enemies will use, edit the subclass for handling damage to give handling for when a entity dies, had to account for multiple , and other stuff I don't feel like mentioning. On top of that, this is my first time writing something like this completely in code, so it was inevitable that I would make mistakes and  had to retroactively fix them. It wasn't that bad to be honest. Now  I'm confident that adding in the next enemy would be a lot faster.

Personal Thoughts

I'm starting to notice the unique relationship between the developer and the game, and how it contrasts with the  player's relationship with the game. You may have noticed from the video and screenshot  that only 4 of things mentioned in the list are visible. I don't  have any more to add to this point, but it is interesting to think about.

Right now my game has a total of 1455 lines of code. This is probably the furthest I've made in the game. Sometimes, I think  how far in the game I would've made it if I was using something like Unity. I heard about the stigma of not using a game  engine to make games but I don't really understand it. People have been making games without an engine long before any general purpose game engines came into existence right? Besides, I like the charm and novelty of  making a game this way. The idea of making something something practically nothing sounds pretty cool! Probably the reason I like the programming language I'm using as well. So you'll probably see me making more games without an engine in the future.

What's Next?

Right now I'm in the middle of doing cleanup and optimizations, trying to fix anything I may have missed . After that, I may try to see if I could have my game work in the browser as well as natively. Doing that makes the task of  finding people to playtest the game a lot easier, as I'm  pretty sure people are less likely to download a game made by complete nobody. If I can successfully make my game run in the browser, I upload it to a site like Newgrounds. I would want my game to be accessible on as many websites possible to gain the most traction. I'm planning to set up the Itch.io and Gamejolt page as well.

Then I will put some work in implementing interactable objects/pickups and keys.

With that, I'll see you guys in like, a month I hope.

Progress Report - September 4th, 2023

Man, I guess posting monthly is  gonna be my thing now.  Bi-Weekly at least. Anyway, hello everyone. I've returned with another update that has barely any visual changes to the game! Well, except for one or two things.

What's changed.

As you can see from the video there are about 2 noticeable changes I've made. 

I revamped the title screen so it isn't just a single screen with a button in it. There now a main menu where you can read the controls, and close the game if you are in full screen.

The big part of this update, is that I added reset functionality! After revamping the title screen, I thought the next best thing to do is implement a way that the game can be reset infinitely without having to close the program altogether. Better to get that done early. Before doing that I took the time to get a better idea of the order of which my scripts are executed and which scripts are used to set up the important stuff. After figuring it out it was surprising simple... at least to me.

After implementing reset functionality, I decided to finally program a losing condition. The game now ends when the player dies. I've also created a quick game over screen.

Other Changes

• I've finished some cleanup after the last update.
•  Did some great performance improvements.  Apparently the problem was the way stuff was drawn in the game scene. Without the fps cap, I remember the game was running at 100-150 FPS, now it runs at 250-300 fps! Although it sometimes drop to 200 FPS I don't remember the framerate dropping below that. 
• Re added bullet tracers
• I completely redone how the musket hit scan works. So now the delay is nearly nonexistent!
• The Life Bar now ticks down when taking damage and it will flash upon reaching low health.

About porting to web.

I've decided that this game is only going to be available natively instead of being playable in the browser. It's not like I couldn't get it to work. After a ton of debugging I got it to work perfectly fine in the browser. Everything was fine until I encountered a bug with the death particles not showing that only seems to occur in the browser.

Don't get me wrong, I later encountered the same bug on the native version and fixed it. Apparently it was due to how I get the time stamps for the particles. When I encountered the bug for the first time, I immediately realized the issue of  essentially maintaining two versions of the same game at the same time.  On top of library I was using to port the game to the web was new and didn't have much documentation, meaning if I come across some issue, I can't just google for the solution. I thought it would be too much for me. Especially when working on my first game, so I removed web functionally.

Game Page

I finished the game page for the game on Itch.io and Game Jolt. I will be posting dev logs there as well.

Personal Thoughts

Around 3 weeks ago, I starting a writing a design document for the game to get a concrete idea of what I want the game to be. Right now the document is around 223 lines long. So long that I decided to add a table of contents.  In my head, I thought that a game where you "complete  objectives to win" would be simple. Turns out it would be a lot more complicated when I put it on paper. Let's hope it would work well in execution.

What's Next?

After this, I may experiment with  saving the player's stats and playtime. Then I would probably consider adding more fonts to the game. Don't worry, I'm still deciding to implement interactable objects and keys. After that I would post another update. 

If you are interesting in playtesting my game, you can contact me on discord. My discord username is: "Proarch."  (With the period, ignore the double quotes) If this game is popular enough, I may consider creating a discord server for it.

And with that, I'll see you guys later.

Progress Report - October 26th, 2023

Hello guys, right back at ya with another monthly update. Can't believe this project is taking about 4 months . I massively underestimated how long this would take. I think at the pace I'm going, I would assume the project would reach it's beta stages in the next  8 months or so probably. Oh yeah, I have something to say first.

The game is now in alpha.

Unfortunately, this does not mean I'll be releasing the game on early access. (Not like there anyone dying to play my game anyways) It just means I've changed the threshold of when I think the game would be in alpha. Before, I thought that when I implemented all the core mechanics, then the game would be in Alpha. However as I implement more and more, the  project is beginning to feel more like a game, so I'm starting to reconsider. 

Maybe the point of which the game would be Alpha for me would be when the project is actually starting to feel like a game. While the point of which the game is in Pre-Alpha would be when the game reaches a playable state I guess? Anyways, I will release the game on early access when  it reaches the beta stages. Which is when I've implemented the core mechanics, added some music, and think of an actual name for the game.

The Changes

Now let's talk about the actual changes I've made. There was supposed to be much more, but has been too long since the last update. The changes I did make were already pretty substantial if you were worried. I have a lot of cool stuff to show you!

Final Map Expansion

I've expanded the map into it's final size. What you see here in the screenshots and videos will actually be 1/4 of the map.  To accommodate for this change, I've written an Region Manager which tracks which area the player is currently in, and only checks chunks of that specific area for collisions and stuff. It was a pretty fun experience creating the new tiles for decoration and redesigning the streets area. I can actually feel myself getting better at better at pixel art and the tools I use. 

Of course, when expanding the map, a major problem emerges. In hindsight, it was a problem just waiting to happen ever since I first implemented the layering systems. (It's how things are drawn to the screen btw) The game was taking up too much memory around 750 MBs in facts. That was a clear problem as a game like this shouldn't be taking up that much RAM in the first place, but I've put off for longer than I should've. Combined with the fact that the IDE I was using was taking up over 1 GB of RAM, I eventually got annoyed and went to track down the problem using a memory profiler.

I've spare you the details . The problem was that each layer is too big, so I have to fix it by completely changing how game entities are drawn to the screen. It was tough, but on the bright side, the game as using less memory than it  using before I expanded the map. At around 180 MBs to be precise.

Sprinting and Player Animations

I replaced the dash/orbit mechanic with sprinting. While yes, one of the reasons is due to the confusing naming. The main reason for this change is that dashing/orbiting isn't really that helpful to the player.  The mechanic's original purpose is as a last ditch effort to avoid damage or put yourself into a better position, but in it's current state,  it couldn't even do that most of the time and it doesn't work smoothly.  So that's why I outright removed the mechanic and replaced it with sprinting. While I'm at it, I also removed walking as it isn't really that useful either.

If you ever been ever been alive for more than 5 minutes, you know what sprinting is. However, I will need to explain how sprinting works in this game.  You have a stamina meter that drains really quickly while sprinting. The stamina meter recharges slowly and you can only activate sprinting once the meter is halfway full. You can't not perform any special actions while sprinting like interacting with stuff and shooting your musket. The way this is designed so it's meant to be used as an evasive tool. Not something you could use to get around the map quickly.

While I was at it, I gave the player new sprites and animations. One of which includes an idle animation to make the player feel more alive I guess. So yeah, there was a lot of major changes to the player. In fact, we're about to go to another major change to the player.

Sub-Weapons and Morale (MP)

Sub-Weapons were something I had planned for the game ever since I was writing down the concept art into my journal. Don't know If I ever told you that. 

For a while during development, I couldn't settle on what I should name the resource that will fuel Sub-Weapons. I think was about go with cards but then I went with "Spades". My thought process was since Castlevania use "Hearts", why not use "Spades" as it is part of the 4 playing card suits. As time went on, I realize that symbolism of the Spade suit doesn't really align with what I'm going with for this game/series. I don't know. The most common meaning seem to find for spades is that they represent "the pinnacle of human development when humans attain, change, and acceptance.", but other interpretations throw in that they represent old age or winter.

I'm more of a "gameplay-first" kind of guy, stuff about symbolism, tone, or story comes second for me and it's usually something I think about when I had nothing else to think about. I mean, at the end of the day, the most important element in a GAME is the GAMEplay right? The gameplay is the cake base, and everything else is the frosting. (I don't know if that was a good analogy.) 

Even outside the symbolism perspective, Spades were awkward to refer to as... "Spades", so much so that I mostly refer to them in my code comments and documentation as "SP". Personally if I have to use the abbreviation than... y'know, the actual name, then there's a problem.

Eventually while going on a run outside, I had the idea to have the resource used for Sub-Weapons to be referred as "Morale" and just have Spades represent it. Not only that the symbolism for "Morale" will be more concrete and less awkward to refer to, I could now use the standard "MP" abbreviation which feels good to think about. Along with the fact that it will be a lot easier to explain Morale in-universe if I every felt the need to.

So yeah, I feel good that I've finally have implemented a core mechanic like this. Sub-Weapons and Morale can be gained by opening crates. The logic handled when you get a Sub-Weapon from a crate are quite different than how other drops are handled.

Full Video

Links

Itch.io Page

Game Jolt Page

I'm am still looking for play testers. If you're interested, you can add me on discord. My discord username is "proarch." (With the period)

What's Next?

Now that I have Sub-Weapons done and over with, all the core mechanics I have left are Familiars and Objectives. But before I get to that I have to rework the subclass for enemies and fix a couple issues with the spider enemy. While I'm at it, I will experiment with effects like after-images and trails. I'll post a quick update once I'm done with that.

Anyways, I'll see you guys later.

Progress Report - November 12th, 2023

Hey guys, I'm here to drop a quick update. Over the past few weeks, I've been taking a bit of a break to rejuvenate myself. While it ain't much, I still got somethings done during the period of time.

The Changes

At best there are 3 minor things I have to show.

Enemy Rework

So I finished the enemy rework to be more efficient and made it so spiders will go to the last location they saw you if you went out of their sight. As a result of the changes, the game feels a bit more smoother. Not sure if it is a placebo effect or something. I tried running the game at an uncapped framerate and it shows to be consistently hitting 300 FPS on my computer. I don't think I've ever seen it go below 250 FPS. 

Eh, any amount of optimization is always good as they dictate what you can fit in your game. Which is something I think game developers are beginning to not care about. Sure, average computers of today are pretty powerful but still...

Screen Effects and Pre-Game Splashes.

I  decided to experiment with screen effects instead of stuff like trails of after-images. It's just a simple effect of fading the entire screen to certain color. It's ain't much, but pretty good for transitioning between scenes.

Now onto Pre-Game Splashes. Which is a term I will use to refer to the two messages that will show up on the screen, one after another when the player starts a game. The first message will actually be randomly chosen from a list, while the second message explains how to beat the game.

It's just this small that I've had in my mind for a while. I only decided to add it in after I finished the screen effects and transitions. I also think it would be a cute way to give hints to the player about certain mechanics. You could tell by some of the messages in the above image.

What's Next?

Since the next thing I'm gonna be working on will be familiars, which are entities that will follow you around, I gotta implement a pathfinding system of some kind. I do know how to implement pathfinding before, using the A* algorithm. However, that was on a smaller scale project that I worked on long before I began working on this game. 

The way I previously did it was tile based but very inefficient. It works okay in a smaller grid but I realized in a game like this, it wouldn't work out, so I thought of a different method to implement pathfinding. That method is something like AI Nodes from games that are made in the Source Engine. I do have experience in the engine so I wasn't that hard to figure the general idea of how it works. I fairly confident that this system will work, and I will be implementing a new enemy to test it along with familiars.

Links

Itch.io Page

Game Jolt Page

I'm am still looking for play testers. If you're interested, you can add me on discord. My discord username is "proarch." (With the period)

So that's all I have to say for now. Just had the post an update on what I'm doing. I'll be making more of an effort to find people to playtest my game. I'll see you guys later.

Progress Report - December 17th, 2023

Hi, it's been a while hasn't it? It's been a whole month in fact. Some of that time is due to me getting a better computer. It took me around a day to transfer all my data and adjust to it. I also spent a couple days working on the video that's basically an overview of everything I added. 

The process was alright though. It gave me a much needed break after the work I put in. I've been that that grind over the course of the month. I guess that break I took really does wonders. So let's get into it.

Video Overview

If you're not interested in reading. I took the time to prepare a video detailing everything that I've implemented. The video is fully voiced, and scripted which is something I haven't done before. For most of you, this may be the first time you heard my voice.  

My voice can be incomprehensible  at times. Which is why I took the time to add closed captions to the video as well. The process of adding captions is actually super easy as I pretty already had the script. Makes me wonder why other youtubers add captions to their scripted videos as well.

So all you really have to do to catch up is to watch this video. Although, this post may contain some after thoughts about the changes I made. If you want to know, you can continue reading.

AI Nodes and Pathfinding

You remember in the previous progress report where I said I do this one thing? I did the thing! I implemented actual pathfinding using AI nodes. Probably the most complicated thing I've every written in programming, but most likely not.

The best explanation I could give on how it works is that it uses the A*  Pathfinding Algorithm, but with designated preset points on the map instead of tiles. These designation points can be referred as AI Nodes. Every AI Node is  link together to form a node graph. Which will be used by enemies and familiars for pathfinding.

If you don't know already, this system is taken from how games made in the Source Engine used to handle pathfinding for their NPCs. Even though how they've done it is probably more complicated than how I done it, I'm still proud of the fact that I could understand how it would generally work just by looking at it. Just goes to show how my programming and problem solving skills have improved. On top of that, the pathfinding system is very efficient as there were no freezes whenever it's used. Even on my old computer.

The Wraith Enemy

This enemy is created to test the pathfinding system. Literally took me only around 2 hours to implement this enemy's full functionality which is crazy. This enemy shoots projectiles at the player. When the player gets out of their field of vision, using pathfinding, it will go to the last place it saw the player to try to find them again. Pretty much works exactly as I wanted it to. I have nothing else to say for now.

Familiars

The main focus of the update, and one of the core features of the game that I've been waiting to add for a long time. Familiars are supernatural beings you can contract. Think of them as party members that follow you around and try to assist you in any way they can. 

Familiars typically have magically/supernatural capabilities while the player themselves and their sub-weapons are more grounded. Each one of them  will be designed with different purposes like: Offensive, Defensive, Supportive, and Utility. As such, I would want familiars to be a necessity to survive in the final area in the game.

Sigils

By default, the player starts with no familiars  assigned to them. However, they can contract one by interacting with these objects called Sigils. Every time you start a new game, there is a chance that a Sigil can spawn in a set location around the map. The chances on them spawning depends on the area and what familiar you'll be contracted with upon interacting with them also depends on that factor as well.

Healing

Like the player, familiars also have a life bar that depletes when they take damage. A familiar's vitality derives from your willpower. This means that you can heal your familiar at the cost of your Morale. A cost  that varies depending on how much health the familiar is missing. If your familiar dies, they will be rendered completely unusable. You can revive them if you have enough Morale to heal the familiar back to full health.

Originally the player would have to use their own health to heal their familiar, but I decided against it for reasons that will be explained later. I think I made the right call by having  the player's Morale as the cost. Before, MP is only used as ammo for Sub-Weapons. It's fine on it's own, but considering that the chances getting sub-weapons are completely random. It's possible for players to go through the majority of the game without even obtaining a sub-weapon. Making Morale Points useless most of the time. 

Not only will this give another use for Morale for the time being. I feel this will create a layer of depth on how players should use their Morale.

Enemy Targeting

The enemies now factor in the player's familiar if they have one. How enemies decided who to target is based on a single integer that will be incremented or decremented depending on the player's or familiar's actions. I refer to this integer as aggro.  When I was implemented the aggro system, I didn't have to change the current enemies that much in order to adapt to the changes. I'm proud that my code is that flexible I guess.

Abilities and their cost.

The player can order their familiar to activate a special ability. This special ability is different for every familiar and it costs some of the player's health to use it. While the ability is activating, the player and familiar will be locked into a special state. that when interrupted, the ability activation will be canceled entirely.

Deciding what the cost would be for activating a familiar's ability took me a while. Originally, familiars would have a special resource known as Mana used for activating abilities. (This was way back when  the resource used for sub-weapons are referred as "Spades) I have thought of making it so abilities costs the familiar's own health, but that is a problem for multiple reasons. One of which being that enemies will be able to target the familiar as well, and the fact that familiar's are AI controlled instead of being fully controlled by the player.

Since offensive familiars will regularly be attracting the attention of enemies, they will constantly take unavoidable damage as they can't dodge. This also acts as a reason I decided to rethink how familiars are healed as the player would have to constantly use their health just to revive their dead familiar. 

I eventually settled on having the familiar use the player's health as the cost to their ability instead of their own. This would be an reliable option as the player will be able to dodge enemy attacks and not be damaged as easily. (Well as long as that player doesn't have a skill issue)

My decision to have familiar abilities use the player's health does have an effect on the game. For one, armor is now more important to have as they basically act a second source of health that won't be affected when using familiar abilities. So I may consider increasing the odds of gaining armor from a crate.

What's Next?

I'm gonna continue work on the game on Monday. When the day comes, I will fix some that bugs that were discovered after I finished the update. I will make some changes to balance the game, like changing the maximum amount of armor the player can have. Then, I'll perform some experiments in an attempt to optimize the game further.

I'll be doing all of this to warm myself up to implementing the last core mechanic to the game: Objectives. Yeah, remember when I said this is supposed to be a game where you complete objectives to win? Can't believe I spent so much time  without adding what's pretty much the win condition to this game.

Links

Itch.io Page

Game Jolt Page

I'm am still looking for play testers. If you're interested, you can add me on discord. My discord username is "proarch." (With the period)

Well, I'll see you guys next month, hopefully.

Progress Report - January 16th, 2024

Video Overview

Introduction

So I'm back again after a month like I said. How are you guys doing? I'm doing quite fine myself since I just finished the last core mechanic for the game. Let's talk about it.

Objectives

It's about time I get to this. More than 6 months time in fact. Remember when this was supposed to be a game where you complete objectives to win? I would like a moment to thank those who followed the game for so long.

Anyway, I implemented objectives. Each time you start a game, you'll be assigned a random number of objectives. The chances are actually weighted, meaning you'll get a small amount of objectives more often than a large amount.

There only one objective in the game at the moment. I call it, Item Retrieval. When you get this objective, a random special item will spawn at a random set location. You just have to interact with it to complete the objective.

 

Goal Doors

Before implementing implementing objectives, I felt like I should implement the way the player ends the game after completing them.  At the time, It was difficult to think of how the player wins the game after completing all objectives. I could have the game immediately end once the player completes all of their objectives, but I don't want to do it that way. I preferred that the player interact with a special object to win the game instead.

I know it may sound weird but, that was when I realized that how I'm go about this would define the story of the game. It was so obvious. Besides getting a game over, how the game ends is equivalent to the ending of the story. The game's story is something I thought about from time to time. It was never on top of my list of priorities. I never thought about WHY the player has to go around completing objectives.

After some time, I finally decided on the thing the player has to interact to win the game. A simple green door. The player will spawn near it and it will be unlocked once the player completes all of their objectives. I even made small little sequence when the player interacts with it. While I was at it, I programmed a sequence for when the player dies as well.

Story and Design

After I designed Goal Doors, I've gotten a more clear idea on what the story will be. Now, the story is not gonna have a major presence in the game itself. It'll just be something I've leave in the game's description to add context. The general premise is that you play as a military soldier that was left behind. You have to earn the trust of the city's civilians by complete a number of tasks that serve to improve the safety of the city as a whole. 

Personally, I think it fits for the game I'm trying to make. Every objective will be designed around this premise. If you want to see the more detailed version of the story, I've updated the game's pages to include it, but you may have already seen it.

I even went out of my way to revise the game's design document and create a whole flowchart as you can see from the image above. I did this so I would have a concrete idea on how this game is going to end up. (As if they aren't concrete enough.) I know it's obvious, but one thing I've learned from making this game is that I really have to make sure the core mechanics are good, and every other mechanic in the game must be connected with at least one core mechanic. I never thought I would do this level of planning in my life.

Colors, Armor and, New HUD

As development went on, I started to keep track of what colors I use and what colors should represent important mechanics.

• Enemies tend to be represented by the color red and be given a red outline.  That also goes for anything bad, like the player dying.
• Familiars and anything related to them are represented by the color cyan.
• Anything related to Morale and Sub-Weapons are represented by the color purple.
• Stamina is represented by the color yellow.

It's nothing that groundbreaking. It's just basic color theory or whatever it's called. Objectives and almost everything related to them will be represented by green colors. This also goes for anything good like recovering health or winning the game. Although, armor was also green so that brings me to my next point.

I removed Armor from the game. Not only does it's color conflicts with the "color theory" I established,  (Which is something that was bothering me to no end.)  there's just not many interesting things I could do with armor.  I implemented it when I was working on the first enemy, and in hindsight it felt like something I just tacked-on without much thought. 

The process of removing Armor wasn't even complicated at all. Proving that Armor was simply an unnecessary mechanic. It truly was not needed. After I did it, I felt the need to redesign the the hud. 

The redesign took a lot longer than a thought. I really wanted to get this right.  Once I was finished, I thought it looked pretty good, so it would probably be the final design.

New Map, Collisions, and Balance Changes

Before I went to work on objectives. I reworked the collision system. Rather than using the inefficient tile based method, I went and used the Tiled Map Editor's object layer. Now I can be a lot more efficient with how many colliders are on the map.  Although, I'm not seeing a tangible difference here. 

To be honest, I wasn't all too excited when I finished objectives. After I did that I had an idea to remake the map again, so I could figure out what the game's level design would be. I think it took me around 1 day to make this map with AI Nodes and everything.

Man, I keep having these moments where I think that the area is too small, but while playtesting,  that was far from the truth. It actually does take a bit to walk from one end from the area to another. I couldn't imagine how long it would take to traverse a cramped are like the sewers. I'll try to do something  if it does become a problem. At worse, I may have to shrink the map.

After some playtesting and reasons, I decided to make some balance changes. One of which being lowing to spiders health to 5 so they can be killed in one shot by the musket. I noticed that wraith enemies tend to clump up when pathfinding, so made it that each wraith enemy's "preferred distance" is random.

This next balancing change is a little bit more major. I made it so that the familiar uses the player's stamina to activate their ability. If the player doesn't have enough stamina, their health will be used instead. The reason I did this is because I thought that using the player's health would be too costly. Especially since the player won't have Armor to act as a safe guard anymore. To attempt to balance it out, I lowered the stamina regen speed, and make it so the player can sprint for much longer.

After some testing, I'm starting to consider attempting to further balance this. Maybe by lowering the amount of morale you get from familiar sigils or increasing the amount morale needed to heal your familiar. Or maybe I won't do that because I designed the first area to be easy enough to traverse with just a flintlock musket. Familiars is meant to be the last tier of power progression, so course the area would be trivial if you have them. 

Either way,  expect some more balance changes in the future.

What's next?

I'll be making preparations to release the game on early access. Y'know stuff like making music, drawing thumbnails, and thinking of an actual name for the game. The game will be free, and you'll have an option to donate. I think it's reasonable that I would want some compensation after 6 months of work. At this pace, the game should be released on early access by the time spring arrives, and I live in the US.

You may have already figured out that this game is written in Python. Python is a very important language to me as it truly got me into programming after years of failing for most of my life. Right now, I'm trying to branch out to other things, like participating in collaborative projects, switching to code editors like Neo Vim.

Right now, I'm even trying to learn C++! I know it may be a weird decision to go from something like Python to C++, but I'm adapting to programming language surprisingly well. C++ was pleasant to code with and stuff like pointers was simple for me to understand. I guess it was because of my experience of programming in python, or I was just built different.

Although, try figuring out how to get C++ working, let alone install a library was frustrating. I guess it's because just wanted to use Neo Vim  to code in  C++  rather then using a heavyweight IDE like Visual Studio. I managed to get it working though. I'm now 18, and at the rate things are going, it seems like being a software developer will be my future.

Links

Itch.io Page

Game Jolt Page

With that, I'll see you guys later.

Progress Report - February 9th, 2024

Overview Video

Introduction

In case you haven't noticed, the games now in it's beta stages, and I released it on early access, days before I began work on the update video. If you want to check it out, you probably know where to go. Not gonna lie, making these kinds of scripted takes a lot of time, so I probably won't do them as often.

There are still things I want to talk about. It ain't much, but I did somethings to prepare the game for public release. So let's get right into it.

Making this a series.

I'm thinking about making this game the start point of a series. Now, it won't be anything big. Even I know that the series would never get close to the likes of the Megami Tensei or Final Fantasy franchise.  It'll just be something that I will slowly build upon from time to time. Either by myself, or even by collaborating with other people. 

It probably won't last a long time, but if I get the chance, I would like to pass the reins to someone I trust in the event that I retire or pass away. That way, the series would outlive me. There's always the possibility that it fail, and the series would die with me with this game being the only entry. On the internet, I'm pretty much a nobody, but life is short and I'm already 18. No harm in giving it a try.

Another thing I could also do is have the series be a full on collaborative project similar to the backrooms and SCP wikidot, where  anyone could add an entry to the series as long as it fit's withs the Series' main idea and theme. I don't know how I would convince other people to get in on it, but a man can dream.

Like everyone else, I had multiple dreams throughout my life. Like owning a popular Minecraft server, being a leader of an online faction or clan, running a successful roleplay with others, and of course, being a game developer. While only one of those dreams came true, there is something I realized while typing this. I think I just realized why I'm making the series the way it is.

It was 2016. I was probably 10-11 years old at the time, and FNAF was still popular. As cringe as it may sound, I used to participate in FNAF roleplay. Was I too young to be doing that? Most likely, but it was a very fun experience nonetheless, and I obtained a lot of good memories from it. I tried to get into roleplaying a couple times over the years to attempt to get the same experience, but it never worked.

What's notable is that through all that, I only ever roleplayed as a human OC that has nothing special about them. I'm guessing that I've liked the idea of a regular person interacting and facing supernatural stuff like possessed animatronics. I don't know. I'm not good at self evaluation.

Main Idea and Theme.

Enough of that all that yapping.  The main idea of what this series will be about that it is A Urban Fantasy anthology series where each entry is about  an average human rising up to fight the supernatural. The setting of each entry will be in the modern setting with fantasy, sci-fi, or supernatural elements added on top on it.  Basically the textbook definition of Urban Fantasy.

The human protagonists would have no innate magical or supernatural capabilities of any kind, nor would they have the potential to gain any. They won't even be anyone special. Usually they would have to make use of tools to extend their capabilities, recruit allies, be strategic, and make the best use of their prep time and resources to achieve their goal. 

As for the main theme of the series, it is something that's been on my mind for a while and it's based of past media that I consumed. I only got a solid idea of what it would be when I was thinking of the game's name. I hope it make sense.

The main theme is that no matter how weak you are, your actions will always have some effect on the world and the people around you. It can even influence the future actions of others. Even after you're long gone, the effects of your actions will persist. You can overcome anything as long as you're clever with the resources you have, and the actions you take.

It's kind of why Batman is my favorite superhero. I know people complain about his prep time or him being unrealistic. I just like the idea that you don't need to be blessed with special powers to fight the supernatural or make a real difference.

I believe that as long as you're alive, you have the ability to ACT on your free will. It could very powerful if you're smart. The ability to ACT is available to everyone, and it could be a great equalizer against supernatural threats as it adds uncertainty to the equation. The human protagonists are those who realized this.

While it may not be perfect, that's the main theme of the series, and I certainly know that people would make fun of it to hell and back. I can see the memes now: "Average True Human Tribulation fan immediately dying to a boundless level character. (Apparently, the ability to ACT on their free will doesn't make that much of a difference.)".

Title Screen and Graphics.

I would want the title of the game to reflect the series' theme in some way. I thought of multiple ideas on what it could be before eventually settling on True Human Tribulation: Errand Run. The first part is the title of the series, while the suffix refers to the game itself.

Once I thought of a name, I went and changed the title screen. Personally I like the look of it. Especially with the flashing "PRESS ENTER" text and music.

 The title graphic is made using Aseprite, while the background is made using gimp because it has the 3D transform tool. Overall, besides it's small problems like the suffix of the title graphic not be pronounced enough, I like how they turned out. Especially when the background graphic can be used as a desktop wallpaper.

As for the thumbnails for the Game Jolt and Itch io pages, I made them using paint.net. Which is something I had a lot a experience using. Thanks to how I did them, I'm confident that the game will stand out visually against the other games out there.

Other changes.

• Added a settings menu, which saves between play sessions.
• Wrote two music tracks for the game. One for the title screen, and one for the streets area. You could check out the Overview Video to hear what they sound like.
• Serialized the games files to stop most people from snooping around, and spoil secrets and future game mechanics.

What's Next?

I'm probably just gonna take a short break and wait for feedback on the game while fixing some bugs. After that, I will go to drawing board to think about what I should add to the game going forward. If you have any suggestions, please let me know and I'll consider it,

I'm still branching out. I made some good progress in learning C++, and I'm considering learning Lua and how I could embed it into my programs and making modding APIs. On top of that, learning Lua would expand my capabilities in modding games that use Lua as it's scripting language like Garry's Mod.

While I'm at it I may participate in game jams and collaborating with people. Now that I set up my pay pal account, I'm ready to throw myself there. If you're ever in need of a programmer, hit me up!

Links

Itch.io Game Page

Game Jolt Game Page

Youtube

Twitter

Contact Email: lorenarcdev@gmail.com

With that, I'll see you guys later.

Beta 0.1.1 Changelog

Hey guys, didn't expect me to be back so soon right? I been thinking that now that the game's out on early access, I should probably do things in a different way since the game will be updated regularly. From now on, whenever I update the game, either because I added something or fixed some bugs, I will post a devlog detailing the changes I made, and what I'm working on.

So basically, it's exactly what I've been doing before, except there's less time between updates. That's all I have to say for now. Let's get into it.

Changes

• Fixed an bug with the fade transitions when they would desync depending on the framerate. This was an issue because when the game's running on 120 FPS and the player interacted with the goal door, it would cut to the win screen before it fully faded to green. I fixed this by learning how to do linear interpolation, so that the screen the fade at the same speed no matter the framerate the game is running on, and having the goal door wait until the screen has finished fading before having the game transition to the win green. I did the same for the player's death sequence as well.
• Handled the exception for when user_settings.json can't be decoded due to it having an invalid syntax for whatever reason.
• Did some refactoring that will be absolutely unnoticeable so I might as well not even mention it.
• Screenshots will now be saved in the png format instead of jpeg. 

Project Migration

I guess I should inform you that process migrating the project from PyCharm to Neo vim was unsuccessful. Ruff, the diagnostic linter I was using for Neo vim is a lot more strict on the structure on my code than PyCharm. I realized in order to satisfy it, I would pretty much have to restructure the entire codebase so no thanks. 

I will continue to work on this game using PyCharm. I will use Neo vim for any future projects though. It's not like I hate Ruff, it's really good for telling me when my code is unsafe. It's just that this game was made back then when I had a lot less knowledge so of course some of it's code would be questionable.

What's next?

I think I had this thought in my head every since I finished the 0.1.0 beta release. It's more about an issue about the game's first objective, and the size of each area. It's been well known to me that it takes a bit of time just to traverse the game's map. I realized that no matter the number of "Item Retrieval" Objectives the player get assigned to, it doesn't really affect the player experience that much.

At first glace, I assumed having a small amount objectives assigned to you would mean that wouldn't have to traverse the map that much. In some scenarios, that may be true. However, whether it be 1 or 4 objectives, it doesn't make a difference as there's a high chance the player could get unlucky on the place they decide to look and end up searching the entire map. Wasting an unnecessary amount of time.

 Combined with the repetitive "music" playing in the background. I could see how that would be a bad experience. It wouldn't be odd to think that most would stop playing if this was their first impression of the game. So I had to think of a solution.

Adding a mini map or quest markers was something I refused to do for the long time. I'm afraid it devolve into a Fallout 3 situation where the player would be more focused on the mini map and quest marker instead of everything else. Even so, I'm a programmer. Solving problems is supposed to be my job. I have already thought of a  compromise.

Rather than having a full mini map, it's gonna be like a radar that only displays what chunk the player and objective entities are located.  So it kind of like overworld mini map of the first Legend of Zelda. The radar will only display the chunks of the current area the player is in. I could make it so the radar also displays what chunks the player as visited as well.

To better demonstrate what I mean, I created two mockup images as I haven't implemented the feature yet. I basically used a screenshot to make the first image. In a funny way, doing this motivated me to change what format the screenshots are saved in.

While I'm at it, I may as well plan on remaking the pause screen, and changing it into something better looking instead of a black screen. I also made a mockup for it using the same screenshot. I thought it looked pretty good, so what do you think?

So I will release the next update when I'm done with them. I'm still trying to think of other thing I could add to the game. So if you have any suggestions, please let me know.

Personal Thoughts

You know, sometimes I wonder: who's reading this? Throughout this game's development, I've had a single person comment on it. After I released the game on early access, no one has downloaded it either. Sure, judging from the analytics, people have been viewing the game page, devlog, tweets, and videos. But other than that, it's just radio silence. 

Could there be some big problem with my game and I just don't realize it? How could I know if no one is bothering to speak up? It's just frustrating you know? Apart from one friend, I basically have no source of feedback.

I have been doing something about it though. I have been downloading, and reviewing other people's games that they recently uploaded. Y'know, give them the feedback I never got and trying to build a connection with other developers. Hoping that they would check out my game too. It's the best I could think of to be honest, and I'm trying  to participate a bit more in the gamedev community.

With that, I'll see you guys later

Beta 0.1.2 Changelog

Hey guys. It's that time of the month again! Or maybe week? It's been eight days since the last post. Which is usually the second quickest time between updates. Anyway, let's get into the changes.

Changes

• Remade the pause menu.
• Implemented the radar. 
• Increased the max FPS cap from 120 to 300.
• Created a new pause sound.

Pause Screen

So I implemented the new pause screen I was talking about, and rather successfully too! I'm rather proud of the myself for managing to make it nearly identical to the mockup outside of some differences. I also made the black bars slide in as well using linear interpolation. Not gonna lie, the effect look so good, I kept pausing and unpausing the game just to see it. Y'all have to see it for yourselves, because the 16 FPS gif is not doing it justice.

Overall, I like how I did it. It really gives to the opportunity to display extra information to the player. I also went ahead to whip up a new pause sound, since I'm not really a fan of the old one.

Radar

Implementing the Radar to the game was quite challenging. Getting the chunk position of an entity was easy. The hard part was translating said chunk position to the correct spot on the radar. After some trying, I managed to come up with a formula that solves the problem.

Now I know this looks bad, but if you actually know math, it ain't that complicated. To run it down this formula involves multiplying a vector, and subtracting the product by another vector. We'll go through this step by step.

The Radar's icons are drawn on a 129x129 canvas that separate from the actual sprite itself. Think of it as an extra layer. The g is represented by the gap between the top left of the canvas, and bottom right of the first icon slot. In this case, it's 24.

cx and cy is actually easy to figure out as it's a vector for the chunk position, and the second vector represents what size the icon is going to be which is 15. So to unpack, the formula is actually this.

cx * g - sw = rx

cy * g - sh = ry

I pretty sure I just scared off most of the people reading this. If anyone is reading this anyway. This seems to be the only solution I could find, but if you have any better ideas, please let me know. Or I could just be met with radio silence again...

Well, the radar works exactly how I wanted it to be. It updates every second or so to show the chunk positions of the player and entities that are tied to objectives. It really streamlines the game's progression.

Links and Contacts

Itch.io Download

Gamejolt Download

Contact Email: lorenarcdev@gmail.com

Discord: proarch. (With the period.)

What's Next?

Well, I've crossed most things of my list for what to do. My Trello "todo" list is like very small than it was before. Like there's only seven items. What I'm going to do is to review my game design document and decide what to do from there. I'm really in that "drawing board" phase of development.

I'll see you guys later

Beta 0.1.3 Changelog

Hey guys, it's been 18 days since the last update, so everything is back to normalcy at least. This update mainly consist of quality of life changes and additions I made in response to recent feedback. Let's get into it.

Changes

I took the time to list all of the substantial  changes I made, and sorted them into this neat little list. I'll explain some of the more interesting features in more detail later on in this post if you're interested.

• Menus
  • Elements of the pause menu will now fade back out once the game is resumed instead of an instant cut.
  • Now a fading transition will trigger when the player clicks any buttons that take them back to the Main Menu/Title Screen.
  • Written a sub-menu system for the pause menu.
  • Added a button that displays the controls using the sub-menu system.
• Enemies
  • Lowered the distance of which enemies target you.
  • Raised the Spider enemy's HP.
• Player
  • Flintlock Musket
    • The Flintlock Musket's accuracy is no longer affected by the player's movement velocity.
    •  Now inflicts more damage if the player is standing still while shooting.
  • Stamina
    • Reworked how stamina usually works with the implementation of the Exhaustion mechanic.
    • The stamina value in the pause menu will now be red if the player's exhausted.
    • While the player is exhausted, the stamina bar will be flashing.
    • The player is now able to activate sprinting, even if their stamina is below 50.
  • Miscellaneous
    • The player is now invulnerable to taking damage during the win sequence.
    • As such, the player can now interact with the goal door to win the game while they're in combat.

Sub-Menus

So I added a button that displays the controls in a little sub-menu. That way you wouldn't have to quit the game, losing all of your current progress just to see the controls. The sub-menu system is something I've written to make it work, and it could easily be extensible to add other sub-menus to the pause screen.

 I do see the potential to adding something like this as it could be a way to display more useful information to the player. So I may add more stuff to the pause menu in the future. You can see how the sub-menu system works from the gif below. Although, it is at a low framerate as Itch.io has a ludicrously low file size limit. Trust me, the effect looks better in-game.

Perfect Shots

So I completely replaced the Musket Inaccuracy. Now the flintlock musket will inflict extra damage if the player was standing still when it was shot. I felt it's probably better to reward the player for standing still while shooting rather than punishing them for not doing it.  It also makes sense "lore-wise" (Not like there's any deep lore in the first place.) as it could be explained that the protagonist is take the time to get a better shot in order to inflict more damage.

I've also removed the yellow text that hints at Musket Inaccuracy from the controls image. I probably won't have the "Perfect Shot" mechanic explained to the player as it's not really vital to know in my opinion. In fact, there are already stuff in the game that hints at this mechanic. 

Exhaustion

When someone pointed out that not being able to activate sprint while stamina is under 50 doesn't make sense, that was when I had the idea. So I replaced that mechanic with something much more defined in my opinion. I shall introduce you to: Exhaustion!

Okay, so now the player is able to activate sprinting even if their stamina is below 50%. Now if the player's stamina goes below 0 for any reason, they will become exhausted. While the player is exhausted, they are unable to utilize their stamina for anything at all. That includes sprinting, or activating familiar abilities.  Although, with familiar abilities, it's a bit different as they will consume the player's health rather than their stamina if they're exhausted. I'm also planning of making it so the player is immune from stamina draining effects from "certain enemies" while they're exhausted.

The player's stamina still regenerates while the player is exhausted. That means when the player's stamina has reached 50 or higher, they will no longer become exhausted and be able to utilize their stamina like normal. Overall, I think this is a decent rework, and I like how I did it. Although I understand if it still needs a few tweaks.

Links and Contacts

Itch.io Download

Gamejolt Download

Contact Email: lorenarcdev@gmail.com

Discord: proarch. (With the period.)

What's Next?

So I was playtesting the game myself for a bit, and I realized that even with the player having the knowledge of which chunk an objective entity is located in, it's doesn't shorten the travel time that much. I eventually deduced that the problem is due to layout of the area itself.

If you ever played the game before, you'd notice that after you leave the spawn room, there's only really two main paths to go. I guess a proper way to think of about this is to visually the game's current layout as one circular branch. While there are connected branches that go away the the main branch, the ultimately lead to the dead end. Down below is two visualizations to understand what I mean.

If the player is on one side of the main branch, but an objective entity is completely on the other side. They would would have to traverse across the main branch to reach it. They cannot instantly jump from one side of the branch to the other.

The way the game is supposed to be structured is that there would be 4 areas. The first area, the Streets, is supposed to act as a hub of sorts, where the 2 other main areas could be accessed, with the final area being only accessible through the 2nd or 3rd areas. Looking back, it's still the same circle branch design!

Or maybe I'm looking at things the wrong way. Maybe the current layout of the Streets area directly contradicts what it supposed to be. I guess it makes sense, all this time the area was designed to be standalone when I should've designed it with the intention of being of nexus point to other areas in mind.

Either way, expect another map redesign in the future. The image below is a representation of what I want the first area's layout to be.  A layout that would be open ended.

Wait a minute... oh my god... how did I not notice this earlier?! It's the same damn circle design!! Is it really unavoidable? I guess the best thing I could do is to make the metaphorically "circle" as small as possible.

Anyway, I will also be adding another sub-weapon and familiar to add a little bit more variety to the game, and I'm putting work toward tweaking the two soundtracks of the game.  ESSPECIALLY the streets theme. Maybe if I feel like it, I may make extra soundtracks for the win or game over screen.

Personal Thoughts

Ever since I released the game on early access, I've been taking development a bit more slowly. Or faster? Not gonna lie, I do not recall ever being quick with the game's development, except for the early stages maybe? 

Back on topic, I've been taking the time working on other things while learning stuff like C++ in the process. I've recently participated in a game jam, and that got me a lot more exposure than I usually get. I'm pretty happy with that so I may participate in more of them in the future.

I'm also very eager to team up with other developers as I still haven't gotten a chance to properly do that yet, and game jams is the best way of doing it as I'm not looking to working on long-term projects right now. (At least not for free anyway.) Although considering that most game developers use game engines like Unity, Unreal or Godot, I guess I should at least take the time in  learning how to use them for the scenario of them being the only option my teammates are willing to work with.

I'm still gonna be working on this game though. Most likely at a slow pace. I would love for this be something I would just add onto every now and then.

With that, I'll see you guys later.