I have been working on this game for just under two weeks. I hadn't chronicled anything for the first week, which I have corrected this week.

I'm not pushing myself incredibly hard on this project. I have other hobbies and responsibilities to get to. Everyday, I sit down and set a five minute timer. I tell myself that I'm allowed to stop working after this timer goes off.  By the time the timer goes off, I'm sucked into the work, so without fail, I always work for at least twenty minutes every day. The exceptions are Saturdays, which I will dedicate towards writing devlogs, taking a break from programming, and getting screenshots.

Sunday

The day started with me wanting to change the collision a little bit so that the game was more isometric. After looking at the gameplay, I realized that I was actually happy with where it was, and the isometric tweaks would be difficult, lead to problems, and actually look worse in my opinion.

I then decided to implement the first enemy: A possessed coffee cup. The art went well, by my standards, and I managed to fully implement the coffee cup.

When the coffee cup senses the player positioned in a straight line to its left, right, top, or bottom, it will fly in that direction. It can hit walls perfectly fine, but it breaks if it hits the player, if it hits another coffee cup, or if it gets shot. I am very pleased with the animation I created for the breaking coffee cup.

I added a sound effect for getting hit, a sound effect for when the coffee cup breaks, and a sound effect for when the coffee cup first launches itself at you.

While testing, I forgot to make it so that the coffee cup can’t change direction mid dash. This led to the coffee cup terrifyingly flying in a spiral with the player at its center, getting faster and faster as it spins around the player. Sometimes I could get it to fly off the screen. Logically, if it flies up and to the right outside of the room, it should be impossible for me to enter its attack zone again. But it always finds a way, briefly appearing at the edge of the screen until it slowly begins to circle in. I dub this temporary version of the coffee cup “The Hell Cup.”

This gives me an idea: I’ve been thinking of having hidden challenges in the game. Maybe there’s some cryptic hints at the beginning and end of the level that can direct you to the secret challenge area. The coffee cup alone has given me some ideas for a challenge level:

• You can’t fire your gun, so you have to dodge the coffee cups.
• You play through the level again, but with an unbreakable Hell Cup chasing you the entire time.
• You play through the level again, but you can only destroy coffee cups by having them crash into each other.

Maybe the challenge level itself is that you can’t fire your gun. Once you beat that challenge level, you unlock the third challenge. And if you beat that, you unlock the second challenge. Beating that allows you to, in the options, switch out coffee cups with Hell Cups. This could be a post game customizable mode, with all of the enemies having overpowered upgrades that you can toggle. It actually reminds me of the custom nights in the first two FNAF games, now that I think about it. That always was the best part.

I used bfxr to make the sounds. The website’s crazy useful and all, but it can only make pretty harsh sound effects. Since the first level has a café theme, I feel like the music would be pretty calm and smooth. I don’t think that music like that would fit well with the Atari-like sounds. Hopefully I can get my hands on ways to make more fitting sounds.

Originally, this game had eight-way shooting. However, I discovered that this caused a problem when playing with a keyboard. Every time you pressed down on two arrow keys to shoot diagonally, you would press one arrow key a fraction a second before the other. This would lead to you shooting right as you try to shoot up-right. Since the gun as a cool down between each shot, this problem would delay any diagonal attack that you try to make. 

I tried fixing this by changing the shooting to a key-up system instead of a key-down system. Now, you had to release a key for a shot to be registered. This led to a problem where turning from shooting diagonally to shooting cardinally would cause you to shoot once as you turned. I was able to find a solution to this, but there was still a problem. I can’t quite remember what that problem was, but needless to say, the controls were more annoying and unwieldy than ever. I decided to accept defeat and returned to a four way shooting system. I also made these changes to the controller, of course.

Before, here was the way the game decided which way to make the player’s sprite face:

• Is the player shooting?
• If yes, face the direction that the player is shooting.
• If not, is the player moving?
• If yes, face the direction that the player is moving.
• Is the player neither shooting nor moving?
• If yes, keep the same direction as before.

Since shooting took precedence over walking, you were able to walk backwards as you shot. With the key-release system, you would always have a period where you weren’t holding down a key, so Hank (the main character) would keep turning back and forward as you moved away form something that you were shooting. I changed everything so that after you stop shooting, Hank will continue to look in that direction for a second before returning to a movement based facing system.

When I began writing this, I was under the impression that I still had it this way. It turns out that I undid it after reducing the shooting directions.

Monday

My biggest problem at the moment is that I can’t quite think of new enemies to add. Like I said, I want the first level to be café themed, but I’m having trouble thinking of more enemies that fit the theme and have interesting behaviors.

Despite this creative block, I have added new features. The camera will now move with the player. When the player leaves the camera’s field of view, the camera smoothly and quickly shifts over one screen.

I also changed the way that controller vibration works in my game. Before, the controller only vibrates if you get hit. Now, whenever the screen shakes, the controller will vibrate a proportional amount. The controller’s vibration motors can be set from 0 to 1, while the shake variable that I added to the camera can have a value from negative infinity to positive infinity. At the moment, the most powerful shake in the game is a value of 8. The controller vibration is the shake value divided by twenty, or in this case, 0.4. So the most powerful shake would occur at shake = 20. 

I also changed the way that the camera chooses the shake value. Before, every event that caused shaking would set the camera’s shake value to its own intensity. A consequence of this was that if the player got hit (5 shake) but immediately an enemy gets hit by a player’s bullet (3 shake) the camera would shake at 3 shake, even though it would logically be shaking at 5 shake at least. 

Now, any event that causes shakiness sets the shakiness to max(o_camera.shake, X), So that the shakiest event is always being represented. (The max() function will always select the larger of the options provided).

What causes the shake of 8? Why, the bombs of course! 

Now, when you press E or right trigger, Hank will place a bomb right under his feet. This bomb explodes after one second, and has a decently small range. However, I can see how this bomb could be upgraded in many ways, which could be a good progression system. Some ideas for bomb upgrades:

• Bombs that explode after you release the right trigger. While this does mean that you can only have one bomb active at a time, it gives you a much greater control over your bombs.
• Bigger bombs, of course.
• Homing bombs.
• Bombs that can’t hurt the player.
• Vortex bombs (Probably not, as they are functionally the same as homing bombs while being much harder to implement.

The bombs have also given me some ideas for challenges.

• Hank is constantly placing bombs, forcing you to always be on the move while the bombs cause chaos. 
• Enemies explode after killing them.
• You can only use bombs.

Actually, this may have actually inspired my next enemy design. I could definitely do something with bombs. Maybe it’s an explosive enemy that charges at you, or an enemy that throws bombs, or an enemy that sets mines around the room. I’m learning in game development that just playing around with what you already have is a great way to come up with new ideas.

The bombs can also explode walls at the moment. Of course, I will eventually make it so that bombs can only destroy certain types of walls. 

Today was a lot more productive and fun than I expected it to be when I first forced myself to sit down at my computer.

Edit: After an intense bout of motivation, I added a fully functional pause system! This is the first time that I have ever done this. All of my other systems were both primitive and overly complicated at the same time.

Tuesday

When an enemy is off camera, they are functionally deactivated. So now the coffee mugs can’t charge in from the other room. There is a bug where if a coffee mug flies out of the room, it will freeze in place. Going to the other room doesn’t help. The coffee mug cannot be destroyed. While this is definitely not what a working game should look like, I don’t believe that it will really matter, as each room will be separated by doors that don’t open until all of the enemies are beaten.

I made a few minor changes to the menu. A little blip noise will play whenever you change options, and the menu now works with controller.

Tuesday was a day where I had very little creative inspiration. However, I still managed to make some important additions and changes to the gameplay. These aren't changes that many people will notice or care about, but they are integral.

Wednesday

I woke up today with a horrible pain in my shoulder that I acquired yesterday and an unexplained headache. Despite this, I was able to get more done than yesterday.

I’ve added a new enemy! There are now cakes that follow the player, floating, and explode if they hit the player or if they get damaged.

On top of this, I fixed a small issue with the menu. 

While I did do a decent amount today, this particular content is able to be described in just a few sentences. There were no wacky bugs or anything interesting like that.

Thursday

This wasn't just any Thursday, this was fourth Thursday of November Thursday.  I allow myself to eat as much sugar as I want on major holidays. This sounds fun on paper, but in practice results in me feeling unfocused all day. It's hard to describe, there's this mental hotness in your head and you just feel kind of disconnected from your body and the world around you.

So, I said to myself, "Alright, I don't have that much creative drive or motivation. I'll do something simple. I'll just add some options in the options menu."

I severely underestimated how difficult and confusing this would be. However, I am proud to say that I successfully added options to the menu!

While I did run into a lot of problems, only one is interesting enough to talk about.

As you may recall, controller vibration is dependent on screen shake. This led to a problem: Deactivating screen shake would always deactivate controller vibration. However, I did manage to find a loop hole.

The controller vibration is based off of the "shake" variable. The camera tries to reach a certain position which is determined by another object. This target position is displaced by the shake variable

By making the camera's target position dependent on the camera shake option, I can have the camera ignore the shake variable.

If you take anything away from this, remember that no matter how unfocused you feel, just sitting down for five minutes can help wonders.

Friday

My original notes for Friday read: "I added doors. It sucked."

It's a pretty accurate summary. Unlike The Binding of Isaac, where the doors are flat objects attached to the wall, my doors are just as thick as the walls. To add a door, I have to delete the wall blocks and replace them with door blocks. This leads to one major problem: How does the door not close on the player?

I spent a frustrating hour and a half working on this problem. After a bit of tweaking, I managed to come up with single door objects that are stretched to fit the door frame.

I thank you for reading this. While games usually have less glamorous progress as they get more and more complex, I am pleased by the amount that I am able to get done in one week. If I stick to it, I'm sure that I can have a demo for playtesting up in about five weeks.