Entry One Hundred And Ninety Six

Some rooms are more problematic than others since they have wide gaps where the player can fall in, and die. According to my - now standard - way rooms work, it would instead teleport the player to another room. I have to find a way to fix that before I can release the 2nd playable version. I was thinking something like death pits everywhere.

I was also thinking of releasing a commented playthrough for the people who want to see 100RTBD without playing through alpha versions, maybe that would work? At least people could see everything there is right now in my game!

Currently working on: Refactoring the whole thing

Time spent on the project so far: 364 hours

Entry One Hundred And Ninety Five

I know it might not be the wisest thing to do about a week before release, but I've decided to implement some major changes in the architecture of how 100RTBD works in order to help me build the rest of the game. While it is true that such changes aren't very gratifying - I barely modified how the game engine works and it won't add anything to the player nor to the 'designer' part of my work - and that it's going to be a bit of work right now, making new rooms will be much easier and less frustrating than it had been before.

In order to purify the scenes I work in - placing blocks, enemy spawn points, etc - I've decided that the Room Controller object would be instantiated by the game controller and added to each scene when you enter them. Then I'll automatically add the right script file (each room has its own script) based on the scene name, instead of having to manually find the RoomControl and select the right file and drag it in. I've also deleted the MainCamera from my scenes and will add one programatically - this doesn't help, but it removes clutter from the scene view. Lastly, I'll remove all my MapTransition circles everywhere you can exit a room to go into another one. Now all rooms will be bordered by 4 huge rectangles that automatically send you to the appropriate room when you leave the bounds of the one you're in. I had to add some code for me to be able to delete some of these rectangles because some maps have bottomless pits, but it's no big deal.

Now I have to basically go into each room and delete the superfluous stuff. I also need to go into each room script and remove a few lines of code. It might take a few hours - and then I'll test the whole thing, probably - but rooms made after that will be much easier to make.

Currently working on: Refactoring the whole thing

Time spent on the project so far: 363 hours

Entry One Hundred And Ninety Four

Since I work only one or two hours a day on 100RTBD and that I'm doing it in my free time, all of this project's chance of being completed hinges on my motivation, motivation is driven by making things that work and not by futzing around for ten or twenty hours on an idea that might not work. Not doing anything productive for 10 days would be crazy and I might even lose interest if that happened.

That said, there are the weekends where I could theoretically take a bunch of time and try something that modifies the core of my code in order to help me in the future. A lot of the tasks I have to do when I create a room could probably be automated, such as changing the hue of all tiles, or creating the room script, or adding it to the RoomControl object of the room.

It's like that thing I said a while ago, maybe I should create all the content; all guns, skills, enemies, items, gear, etc. Maybe I should also create all the maps and all the scripts and add them right then and now. It would take a while, but at least it would be done. At least automating that process would help. I miss procedural generation of things :P

Currently working on: Continuing the story

Time spent on the project so far: 361 hours

Entry One Hundred And Ninety Three

There is no cool tech in 100RTBD. I've tried looking for things to add that would be neat and would make the game stand out from the stream of awesome stuff that the internet will tirelessly produce forever, stuff that I can't frankly compete with. The initial idea I had of the game would've been all pixelated and the enemies would have looked much more cooler, the gameplay is more or less what I thought during the design process, but I do have to make concessions in the interest of time and my drive to work on this.

I give one or two hours per day to a game that might take me another year or so to complete, and I fear that by looking like a prototype for a real game - or by looking like a project made by college student - no one is going to care. At least I'm making my own vast metroidvania with plenty of systems to go around, but I also wish it had a hook, something anyone could look at in a screenshot and go "that's kinda neat".

Maybe I'll spend some more time looking for that hook, or maybe I'll just console myself in the realization of what I want to make without comparing it to what others are doing.

Currently working on: Continuing the story

Time spent on the project so far: 359 hours

Entry One Hundred And Ninety One

I've finally got back to where I was in the game's design, and boy was it tough. I figured out that my bosses had much more hit points and damage than they should, so I tweaked that. I also fixed a few bugs where items and gear would get duplicated for no reason. While I was frustratingly failing to kill Defender D, I briefly wondered about counting the number of times the player died, and after a certain number I could give them an item that increases the life you get when you resurrect to 50% instead of 25. 

Maybe after another number of deaths I could give another one to heal you fully. 100RTBD is of course a game of some skill - you can't just 'facetank' everything and come out fine, and healing items are as of right now, in short supply - so I don't want players to just die in every room in order to heal themselves. On the other hand, it would be quite a shame to lose people to difficult fights. 

Only nine updates to go! I'll really try to send it out there so more people see it and give me feedback, I think?

Currently working on: Testing the whole game

Time spent on the project so far: 355 hours

Entry One Hundred And Eighty Nine

I'm still going through the game, testing the more or less critical path and giving some thought to side areas and challenges. I've fixed a few bugs here and there - mostly mistakes on my end - and I've spent a good long time trying to figure out why you couldn't use the Energy Blade while having the Fire Gun equipped. 

It took a bit of messing around, but I figured out that when you use the fire gun, if you're holding the attack button the gun fires continuously - like a flamethrower - but if you release it, the flames stop. To do so, I'm destroying all player projectiles when the key isn't pressed, therefore, the blade is never there. I've fixed that by making it so it only destroy your flame bullets.

Onward with the rest of the game I haven't tested yet, then I'll continue with my actual work on new stuff!

Currently working on: Testing the whole game

Time spent on the project so far: 352 hours

Entry One Hundred And Eighty Seven

Today I've advanced with a few rooms in the mine tileset. The minecarts were on fire in State-2, but now they're carrying globs of poison. It still means you have to be wary of them although they can be used to reach higher areas. The first visit to State-4 is quite quick so I should be done with it - and ready for Ensign E's boss fight - quite soon. Probably a week would do it.

Currently working on: Continuing the story

Time spent on the project so far: 348 hours

Entry One Hundred And Eighty Five

I've changed the way status ailments work now on enemies. More specifically the calculation that is done in order to see if you manage to get them affected by an ailment. As such, enemies are now easier to take down. I've also upped their damage output in higher states. As it was, they still dealt the same damage no matter if it was an octobit, an octopyrobit or an octoretrobit, now they have multipliers, like they do with life and armor. Poisoned enemies deal less damage, so this kinda balances itself out!

Fifteen updates until I release Playable Version 2!

Currently working on: Continuing the story

Time spent on the project so far: 346 hours

Entry One Hundred And Eighty Four

Not much done today, I've made two new rooms, one with a mini boss and the other with a chest and an infopack. The chest will contain a gun part. I'm not sure which one yet. I've also tweaked the minimap tiles a bit because they didn't look particularly great to me. I'm still not happy with the result so I'll probably go at it some more tomorrow.

Currently working on: Continuing the story

Time spent on the project so far: 345 hours

Entry One Hundred And Eighty Two

According to my design docs, State-4 is going to be pretty straightforward. You'll have to backtrack a bit between locked doors and various paths at crossroads but there won't be any breaking down or restoring. That is, if I'm reading my design docs right. State-4 is acid land, enemies deal poison damage and leave puddles of damaging acid wherever they go. Clouds of gas and flowing bubbles are also pretty common there. Fun times for all!

Currently working on: Continuing the story

Time spent on the project so far: 339 hours

Entry One Hundred And Seventy Nine

And now I'm properly working on the fight against Defender D - after having to fix the glaring omission that there are no restoration altars for you to go back to state-3 after you get the 29th infopack. Defender D shouldn't be too bad to program, he jumps on top of ice pillars, shoots at you occasionally and he has a barrier that blocks attacks. Probably tomorrow I'll be done with that guy! I feel like the hardest part of the fight to code is the jumping on pillars part.

Currently working on: Boss fight with Defender D

Time spent on the project so far: 333 hours

Entry One Hundred And Seventy Eight

On my next game, I'll make sure to use unity's physics engine, if it's appropriate. Right now in 100RTBD I'm using a bit of both. Some of my game objects use rigidbodies and the engine calculates gravity, pull, friction, all of these things. Some of my objects are just moved around by translation commands and they're not impacted by anything else. It's a bit of a hassle to mix both of these things.

My TeraBit enemies, for instance, behaved quite weirdly if I just did their movement myself. They would jump up and then slam down, but they would clip through walls, stand on air, things like that. Adding a rigidbody made them unable to go through solid objects and the gravity pulled them down when they were above pits, but it took a bit of messing around.

Which one's better? Using Unity's physics or calculating everything yourself? Could I do enemies that walk on walls using the basic stuff? This is mostly why I tried to do physics myself with simple translations!

Currently working on: Boss fight with Defender D

Time spent on the project so far: 331 hours

Entry One Hundred And Seventy Seven

I had to fix some challenges that you can attempt way earlier in the game because they were broken by your ability to double jump. I have nothing against players being able to complete challenges more easily as they get stronger but being able to double-jump on a ledge and skip 100% of the actual challenge is a bit broken, so I added some blocks that become solid when you start the challenge.

I'm also making a new enemy type, it's the Terabit. These guys jump high and try to charge at you!

Currently working on: Creating rooms that you can explore after you got the double-jump

Time spent on the project so far: 327 hours