Indie Quest — Week 10; refactoring
This is the tenth entry in my devlog about my endeavor in making a game within 2 months (supposedly ) and releasing it as part of my course’s capstone. You can read the previous entry of the series below:
This is the ninth entry in my devlog about my endeavor in making a game within 2 months (supposedly ) and releasing it…medium.com
While the progress this week is mostly internal you can see many of the results in the game. This week has been a bit of a roller coaster and the first visible update is the below section, it used to be called “Mood, feelings and motivation” but I thought we should change it to Miscellaneous as it talks about a few things including the game design and what I learned in the past week.
As mentioned in the previous week I started refactoring my Enemy code to use OOP concepts.
That said, I have also rethought many of the game mechanics dependent on some of the feedback I received. Recently I had a chat with a great indie developer (in which I can’t name until I am given permission) and he mentioned the game doesn’t feel RPG-esque. Perhaps so as a skin but not in depth. Also some of the feedback mentioned (quoted in the previous week’s entry) stated that the gameplay is somewhat difficult since you can’t always pay attention to the ball and the enemies at the same time.
So I redesigned the game mechanics to allow for that. Here is what a level looked like in the game previously:
However the design has been changed so now, the penalty for missing the ball is a wait time. The ball will take 3.5 seconds to respawn again; a window in which you are open for attack but can’t retaliate (unless you have special attacks and mana enough to use them). The enemies aren’t an easy kill anymore, if they fall off the room, they don’t die as before, they respawn again in their original place.
This means you can’t just wait around for them to come to you and fall in the fire to die, rather you have to kill them one by one to advance in the level. Of course, the fire will change to something that makes more sense, Serg is currently working on it. Here is the new mechanic in action:
Not only that, but I introduced the XP mechanic; one of the most commonly borrowed mechanic from the RPG genre. The plan is to have the player get upgrade points to use it to upgrade his special attacks.
Bugs and Code:
As mentioned in the previous post, I started refactoring my EnemyCollisions.cs code. Unfortunately I wasn’t all too happy about my code structure, coupled with my newly learned information I set out to refactor all of my scripts (well, about 85% of it).
I had a GameManager script that managed the whole game; GUI, Waves, Enemy counts, Audio, etc… everything. Needless to say it was a jumbled mess and I hated the moment I had to edit something to fix inside that script.
I have changed the approach and now I have 4 different scripts on my Game Manager object; GameManager (this manages the scenes, win and lose conditions, spawning of the player and audio — for now, audio will have its own thing later on), WaveManager (this manages the enemies, waves, their spawn and despawn as well as trigger the win condition), GUIManager (this manages everything related to GUI; pause, win, lose, main menu, loading, etc…) and finally the XPManager (manages the XP and leveling up system).
Now, when I need to fix something, it is limited to that script.
I had a minor inconvenience with the XPManager where I tried to add the XP manually (since I wanted exponential growth on the values, not just 100, 200, 300, etc…). But quickly found that is really a bad idea so I resorted to loading them out at the beginning of the game and fill them automatically in a list. It isn’t a major thing but I found that there are a few questions on the internet about, here is the code I have used for this:
LevelXPs = new int;
public void InitializeXP()
for (int i = 0; i < LevelXPs.Length; i++)
LevelXPs[i] = 25 * (i + 1) * (1 + i +1);
NextLevelXP = LevelXPs[CurrentLevel - 1];
public void CheckLevelUp()
if (CurrentXP >= NextLevelXP)
CurrentXP = NextLevelXP - CurrentXP;
if (CurrentXP < 0)
CurrentXP = -CurrentXP;
NextLevelXP = LevelXPs[CurrentLevel - 1];
if (CurrentLevel / 3 > TotalLevelPoints)
TotalLevelPoints = CurrentLevel / 3;
I have to say while refactoring the project, I almost just stopped and threw everything off. It is a really frustrating endeavor since everything gets broken and you have to deal with a heap of bugs that surface because of the new setup. It wasn’t easy. I backed up the entire project before I started it and twice I almost went back to the backup just because it was easy.
At the end, however, I reached the same stage I was in with 2 new features one of them a proper, working wave system for all levels and the XP and leveling up system. Not only that but many bugs that were present before are now fixed.
Lesson learned: Start the project with better planning for your code, try to abstract everything and only use 1 class to do 1 specific thing. Don’t just group things up in 1 class.
Art; Graphics and Eye Candy:
We had a heap load of comments last time that was directed to both bugs (most of them resolved with the refactoring) and the art. I did disagree with the feedback that said the art wasn’t good. That is a personal preference and everyone to his own, for me, I really loved it. That said, I did agree that some things need to be polished and look better.
To that end Serg, has been working on a few new concepts due to the design changes. For example we received feedback that if the player uses a shield how come he gets damaged by enemies? Shouldn’t the shield protect him? So we changed the weapon he is using for deflection; it is now the end part of the flail he uses to throw the ball. Here are some concepts:
I liked the idea of it acting like a spear so the below came into existence:
But a new problem presented itself, the shield looks much larger in the knight’s hands than on the knight’s back. If we increased the size of the shield, you won’t see the player. Reducing the shield size will make the player vulnerable. So Serg is actively redesigning the shield at the moment.
Due to that, the shield is now a special attack that can protect the player from taking damage for a period of time.
On the other hand, work hasn’t stopped in creating new rooms for the game. Here is the latest sketch from Serg; the Throne Room where the final battle will occur:
We also seized the chance and worked on the rat as the feedback for it wasn’t great. Here are the concepts for the new rat:
I really liked the 3rd one as it is a combination between the 4th and 1st if we ever wanted to use these (as I liked them a lot) so we went with it. Here is the final look:
Honestly, I had a plan before the feedback to release 0.099 today and hopefully next week we release 0.1 and probably start on a proper Alpha after that. However due to the refactoring of code and the redesign of some of the game mechanics, that had to wait until I fix all bugs and implement the new art.
All in all, I think we had a very productive week and a lot has changed in the game in one week. A lot is currently in the works too so hopefully we can have better feedback next time we submit the game for it.
With that said, I think that concludes our post for this week and hopefully we have more to show you the next.
If you’d like what you’ve read so far or tested in the build, consider subscribing to our newsletter (if you don’t want to signup for Medium) to get instant news