Kind of Antsy

So, I’m going to start dating these instead of saying week whatever, because I’m apparently awful at sticking with this.

What have I done during the last 6 months?! Well, I’ve switched over to Godot for everything, and started yet another hobby… Dungeons and Dragons. Lately though, I’ve been trying to prioritize game dev.

After switching everything to Godot, I noticed a weird issue when lights overlap. The first time the level loads, everything looks great. The second time a level loads, one of the lights won’t blend with the others. After some research, it turns out there’s an issue with the light blending after reloading levels. Unfortunately, the whole game was kind of predicated on mixing lights. After some soul searching, I found that you can add glow by using HDR, so instead of there being lights in the level, I’m now going to use glow to show when things are interactable. I think this actually works a bit nicer. Also, shadows!

Finally, I decided to plan out a few levels so I could test the idea of tutorializing the game through gameplay instead of explicit tutorials. Super Mario Bros. does this, where something is introduced in isolation, and you need to overcome the challenge presented before they start mixing challenges together. For my first draft, the idea was to (try) to do the same thing. I also used gray and white boxes for now, just to get the levels kind of figured out.

If you want to check it out, I have a build here: https://tinyurl.com/LightAlive20240315

Next time, hopefully, I’ll have something new! I did create some new art, but I haven’t implemented it yet. My next goals are to make the game just kind of “feel” better and work out little kinks with movement and collision that I’m not a huge fan of.

Hello! I’ve been away for a bit, but working on this project where I can. Updates: I went through a ton of ideas for names and settled on Light Alive, for at least a temporary name.

More importantly: I’m switching engines! Unity announced a weird pricing structure, and it’s almost certain to never affect me due to the fact that this is my first game and I don’t anticipate it being a smash hit (although, you never know), but it was enough to make me think that Unity, as a company, is short sighted and more concerned with squeezing profit than treating its developers well for long-term gain from loyal customers. From what I’ve seen regarding their pricing model, concerns were brought up internally at Unity and ignored. I don’t think anyone really had an issue with Unity wanting money, that part totally makes sense to me. Unity devs gotta eat. However, the problem is that they went about it in the worst possible way and clearly didn’t think about the impact it would have. Alternatively, they did think about it, and decided to go ahead and do it anyway. Regardless, it shows a lack of good leadership and who knows what they’ll decide to do next week/month/year. As such, I decided to check out Godot! I’ve been messing with it for about a week and I’ve got the project mostly ported over. There are still some kinks to work out, but it seems like working in Godot is going to be way faster and easier than working in Unity. I wasn’t super eager to learn GDScript because I liked the idea of doing REAL engineering in C#, but then I asked myself “Do I want to be a master coder who does everything by hand, or do I want to make games to the best of my ability?” The answer, if I have to chose, is that I want to make games. If I spend years coding from scratch something that can be done in minutes in Godot, and the result is exactly the same, then I’d chose to take the Godot route. Not that there’s no value in learning how to do things the hard way, but my goal isn’t to become a Unity master, it’s to become someone who can make games on a small budget in a short(ish) amount of time. Additionally, using Unity isn’t coding from scratch, obviously, considering there’s a whole engine there for you to interact with. I read once that if you want to make bread from scratch, you first have to invent the universe. I really like that quote and I’m going to use that mindset to use the best tools I have available to make the best games I can.

Next time I’ll try to remember to take a video of what I’ve got so far! It looks almost identical to before, so it’s not super exciting… but I’m making moves!

I’m a day late! To all my loyal reader, I apologize. I was in Boston yesterday celebrating a friend’s birthday. I also attended the MIT flea market and coincidentally ran into a member of Freezepop, a band I love, so that was pretty damn cool. In regards to accomplishments this week, I wrote up a decently long to-do list that will help me stay on track with polishing the stuff I already have in place. I was watching a YouTube video today on game dev mistakes, and they were talking about how they added stuff without polishing it, and how the game looked like garbage when they first showed it off. As such, I figure I should dedicate some time to polish.

The first thing I did was to get death and hit animations created. Previously, when the player was hit, nothing happened to indicate they were hit except the light level going down. Similarly, when the player died, the game just kind of ended. The hit animation has been implemented, but the death animation got me thinking about how I want to handle player death. This lead me down another path, starting with adding in differentiators in the code for when the player dies by just running out of light, or if it was a hit from an enemy that took the last of their light away. Based on how the player died, different things will occur:

1. If the player is just running out of light, once they hit a certain threshold (perhaps a 10 second countdown), the screen will start shaking and the camera zooming in on the player character. This will indicate to the player that they’re about to die without needing to explicitly put in a timer. I recognize that screen shake isn’t for everyone, so I’m trying to make it relatively subtle, and I’ll have to include an option to disable it entirely for folks that really hate it. Once the countdown is over, the circle of light will contract fully to 0, and the screen will be black.
2. If the player is hit and the last of their light is taken away, the death animation will play while the camera zooms in on the player and the circle will contract to 0.
3. In the event that the player is running out of light, then they are hit, the step 1 will occur, then step 2 will override.

I also added in a few ‘cheats’ for the purposes of debugging. One adds invincibility (which also may be useful for invincibility frames after taking a hit or during a dodge). The second just turns on the environmental lighting so I can see what’s going on outside of the circle of light.

I wonder if I should start actually tracking the hours I spend on this. Maybe it’ll encourage me to dedicate more time and focus harder. Also, I’m trying to get some ADHD medication adjustments so I can actually focus… so that’ll be cool.

The last thing I really did this week was go through some previous software purchases and downloaded some music making and editing tools. I’ve always wanted to make my own music and this might be a good opportunity to try that out!

Another week, not a ton of progress. This week, I replaced the player and enemy artwork with lower-res art because I’m going for a semi-retro look. There’s still tons to do, especially determining what the best option is for level objectives. I want to add some light puzzle elements, and there are enemies and light sources. Right now, the objective is just to kill all the zombies, but I definitely do not like this as final objective. The issue I have with “kill everything” in this game is that you can barely see anything, and I feel like it would be super frustrating to kill all but one enemy, then need to search for the last one while your light runs out. The goals I’m thinking of at the moment are escaping or searching for a specific item. This has the same issue though, to where your light can be running out, but you can’t find the item and can’t find more light. This next week I’m going to spend figuring out what good objectives would be given the current restraints of the game. Things can always be adjusted, but I currently like the idea of the light reducing your vision and your time to survive. It forces you to go and look for the objective, whatever that might be. You can’t wait for things to come to you, you can’t just hide and hope for the best, you need to face the problem and put yourself in danger to escape.

One potential option: each level has a goal that isn’t immediately apparent to the player or explained. It requires the player to try different things until the level is completed. This could be killing everything in the level, or finding a specific item, or getting to a location. You’re dropped in with zero guidance, and you just need to explore until you figure out the goal of the level. There’s a lot to consider for sure.

I just want to make the best game I can (given a very small budget, working part time, and having a super small scope).

Here’s a video of what I’ve got so far:

I keep shifting my days of posting, and I think I’m going to revert back to posting on Sunday and make a habit out of it. I feel like I’m not making progress fast enough, so I’m like “one more day!”, but all that does is just push my logging out while also potentially making zero progress.

In positive news, I have a build of the game! A lot of the menus aren’t entirely coded properly, so if you try to exit the game, you’ll need to press Alt+F4. Right now, you can move around, fight zombies, collect light, and level up. Tons of tweaks need to be made to make this game complete, but my initial goal of having something technically playable is complete. So this is milestone 1.

If you want to give it a shot: https://drive.google.com/file/d/11PuVCnupi40k7d912UeWmeve_I4z-7du/view?usp=drive_link

The stuff I posted as my to-do list in the the week 4 update still applies, however I have a new, more immediate list (mostly quickly jotted down notes):

• On the build version, stats aren’t kept between loads of the game – need to add a save
• Finish the menus
  • Do better anchoring for position
  • Redo for controller support
  • Make sure all buttons work
• Fix the menu system – sometimes the wrong menu briefly pops up. No bueno!
• Rearchitect the level-up menu so it’s more intuitive
• Add a start menu
• Add in the better player character animations
• Ensure zombies don’t randomly stop moving
• Make everything look better!
  • Particle effects for sucking in light
  • Make the light-pickups look better
  • Make your light flicker a bit?

At GDC I saw a talk where a guy talk about the most successful teams he had been on followed a process of essentially stripping the game down to its absolute core, then creating that and iterating on it until it was polished and complete. Then they would the next feature until it was complete. The thought being that if they ran out of time, they could drop the remaining features and still have something worthwhile. I’m going to try taking a similar approach, where I’ll get the current stuff working properly, then add more until it becomes what I want! The other option is to just create crappy versions of everything, then iterate on everything until it’s good. The issue I have with that is that I think it will be overwhelming seeing a huge pile of crap. My to-do list will just say “make everything better”.

Well, another week with not too much exciting progress happening in the game. I finished most of the logic for the menu systems. The Level Up menu is the latest thing I’ve been working on. I recognized after the fact, that it’s not the best for controller navigation, but this definitely isn’t meant to be final. My current goal is to get the menu system fully implemented and add some more enemies, then it’s time to collect tons of feedback and find the fun!

Here are some screenshots of the menu, just for something to look at:

Things I want to add:

• A slightly better combat system. I feel like it may need more weapons or more attacks to make the game more versatile. Not 100% sure about how to go about this, so there’s definitely going to be some iteration and trial and error.
• More enemies. Enemies that are unique and inspired by classic horror movie tropes.
• Puzzle elements. I want to play with the light and a few objects that can react to the light or react to being hit. Just something to spice the game up a bit!
• Randomization. I don’t want fully procedurally generated levels, but I’m thinking that I can create level ‘chunks’ that are procedurally assembled at runtime.

Hopefully more progress to be made this week!