This is the thirteenth 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 here.
A few interesting things happened this week and while most of the progress isn't visual we did take a few steps forward, so let's start...
Misc:
Last week I mentioned that we've reached a fork in the road; we've been developing two different mechanics for the player's weapon and the player movement. You can find the details in the previous post. To get feedback I posted the two builds on TIGSource's Play testing forums, /r/GameDev's WIP Wednesday, Game Design Wednesday and Feedback Friday. Not to mention the blog post which had the two demos and the explanation as well as an article with download links on our IndieDB page. In all honesty, I was expecting a large sample size (10+ is usually large in my perspective compared to what I have seen before). However, reality rained hard when all we've got was around 6 people over all the channels mentioned previously. I even did a few tweets about this specific subject with and without pictures. Nothing!
Realizing we are pressed with time (due to us trying to meet a few deadlines including this blog post), I didn't want to wait for another week with doing nothing just to get more feedback (and I am pretty sure at that time the number would drop, since previous people that played wont' play again). So without further ado, here are the results:
All 6 people liked the old gameplay in comparison to the new one.
All 6 people mentioned the new system was more fun, 1 out of the 6 however commended the second approach but ended up saying the first one is better.
All 6 people focused on the fact that the second system seemed to weird and too unfamiliar and they had to literally go through a learning curve, albeit the first one was intuitive and easy to pick up right away.
1 out of 6 people noticed and commended the art.
What I learned from this whole experience:
People usually don't read or it seems they don't retain information very well when it is just presented to them in instructional manner. Despite mentioning the mechanics almost twice for each game in the posts. A tutorial for second gameplay system, I guess would have gone a long way. The reason I am saying that is that people kept giving feedback that isn't quite correct and had to correct them due to how the game is presented. Unfortunately if I took the time to implement a tutorial then that is a whole lot of time that is a plain waste (since everybody didn't like the second system).
If presented with unfamiliar and non-familiar situation people will pick the familiar. While I understand that most of the 6 people didn't choose the first style just because a familiar gameplay concept, I believe it was a factor in the decision. It isn't inherently bad, as good game design uses familiar situations to ease in the introduction of a player to something new. However, a player is far more receptive when introduced with alien mechanics in a completely new environment that you have to discover rather than having something to compare against.
What we've decided to do so far:
With the above feedback I started working on a new revamped gameplay that uses the first system while still trying to be innovative and more "actiony". In other words, a redesign was in order... again!
People have mentioned they did like the control the second prototype provided both in vertical movement and aiming the ball that the first lacked. The first thing I did was implement both in the first system. Now the ball can be targeted at launch and the player can move horizontally and vertically.
Mid development I have been dabbling with the idea of giving the player a melee attack to fend off enemies. However I dismissed as it didn't feel natural in a game that most of the "fighting" happens in a ranged like setting. However, it was brought up again when my programmer partner suggested it. Also one of the commentators mentioned a game called Firestrike I think where the player uses melee attacks to deflect the ball at enemies. I did watch a video but I hated the way the ball was controlled, it was utterly chaotic and weird. It sparked in my mind a ping pong/tennis like attack; what if the player right before the ball touches the shield would attack the ball and due to that the ball increases its speed and instead of bouncing, it penetrated enemies (just like the way it works normally in the second system) but for a few seconds only before turning to normal again. That said, it felt overpowered, the player now can just finish a level in two well placed hits. I had to come with a disadvantage and that is where I introduced the idea of dying by the ball. Since the ball acts like a super ball (imagine a bullet ricocheting) then it should also damage the player. So if the player uses that ability he has to avoid the ball or he gets as much damage from it as an enemy. Now there is a trade off. Meanwhile we have reduced the ball respawn time from 3.5 seconds to 0.5 seconds and had the "super ball" duration set to 3.5 seconds.
Bugs and Code:
Coding the changes wasn't easy. I literally messed up the Git a few times as I forked the first version to iterate over while it was far better to just use the second. It took 3 commits and pushes to fix it. Finally however I was able to implement the whole thing.
What took a bit of thinking was the super ball mode mentioned above. Since the code at first checks what type of ball are you using and adds a collision appropriate to whether it is a penetrating ball or not on Start() only, I had to rework the code to fire on when the MeleeAttack() occurs. Here is a snippet of my code:
public IEnumerator ActivateSuperBall(Vector2 newDirection)
{
// Make it that the ball go super fast, penetrate enemies but also is like hot iron ball with a bullet shape that can damage
// the player too
Vector2 originalVelocity = rb.velocity;
MaxSpeed = Speed + ExtraSpeed;
rb.velocity = newDirection * MaxSpeed;
PenetrateMode = true;
foreach (Enemy enemy in enemies)
{
enemy.BallTrigger(true);
}
yield return new WaitForSeconds(3.5f);
foreach (Enemy enemy in enemies)
{
enemy.BallTrigger(false);
}
MaxSpeed = MaxSpeed - ExtraSpeed;
rb.velocity = originalVelocity;
PenetrateMode = false;
}
Once this has been tested enough and everything seems to work and in order, I believe the next order of things is to work on enemies to polish and fix their movement in general.
Art; Graphics and Eye Candy:
There hasn't been much work in that department as Serg hasn't been quite active as of late due to a few personal issues and the fact that I asked him to stop working on a few things till we decide which gameplay to go through. However, he started working on a more generic item which is the game's icon/logo. Here are the sketches below:
I liked the 2nd one of the most but I didn't like the Yin Yang reference (it has no representation in our game). He is currently working on an updated final version for it.
Music:
We don't mention music too often in our posts, however at this time, Aleix is currently hard at work on the SFX for the game. Hopefully you can check out some of these soon.
I guess that is it for today, there are no new builds as I'd like to have a more polished build as a public one instead of just another prototype/test build. Once we are done working on the systems and incorporate some of the updated enemies we'll try to work on a post for it. Until then, have fun, take care and see you later everyone!
