• Register

The game you are trying to view has ceased development and consequently been archived. If you are a member of this game, can demonstrate that it is being actively developed and will be able to keep this profile up to date with the latest news, images, videos and downloads, please contact us with all details and we will consider its re-activation.

A 2D action, arcade game that blends Breakout with RPG mechanics. You play a knight storming a castle saving a princess from the clutches of an evil dragon rumored to have kidnapped her. Armed with your magical flail and spikey ball, you fight hordes of fantasy-themed evil creatures in a satirical setting.

Report RSS Indie Quest -- Week 12; Crossroads & Feedback!

We need your feedback now more than ever, 2 demos to try, can you help us by picking the most fun one?

Posted by on

This is the eleventh 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.

While this week the work done on the game hasn't been as much I would like to, we finally managed to keep a promise I made earlier (or at least half of it). That said we did learn the lesson. Alright, let's get to the meat of it...

Misc:

We have been working on the game for 12 weeks right now and still within the prototype phase which I don't like much. I'd like to exit that phase into Alpha, seriously. But I have come to believe I can't just do it alone coding wise. As I am still learning code and making the game, I have monitoring my progress internally. I learned a lot, a huge amount I can attest to that. However on the hand I have lost a ton of time looking around for answers to simple problems that I discovered in the end shouldn't have taken all that time. Now, I am not complaining and actually searching and finding the answer is something I enjoy. I love this "expedition" of knowledge. Problem is, this doesn't mean I'll be able to finish this on the time I allotted for it. As such I started looking for a 4th person to jump in with me to code and explain things out for me.

Luckily, I was able to partner with another programmer. We've started looking at the code together and he has helped me figure a few problems out (more on that later). Ironically, the progress for the game wasn't as fast as I hoped as he was quite busy with other arrangements.

If you've read the previous entry you'd know that we've been cooking up a new gameplay mechanic to cater for the feedback that we received from our last Feedback Friday we did (2-3 weeks ago). The thing is we are too used to the game to judge fully. Not to mention that both gameplay experiences deliver unique kind of gameplay that is fun in their own, which is more appealing is something we shouldn't decide alone so we thought we'd present you with both. We are asking that you'd help us with a play test and telling us your opinion on which you liked the best. Here is a little more information:

  1. The first gameplay system we made and the original idea. The game functions like a normal breakout with an RPG-esque feel to it. You play with a character that is restricted to the left and right movement. You throw a ball at enemies trying to kill them. You can influence somewhat the direction of the ball with your character. You have special attacks that you can use through your mana. You get XP and loot from killing enemies (which will attack you in different ways) that you use to level up and upgrade both your character and weapons. The upgrade system isn't implemented yet. Here is a GIF to showcase this:


  1. The second gameplay system. This is slightly different, the ball (your weapon type will change later, but now a ball for testing) has a lifetime based and speed based on how long you press the left mouse button (the more you press the more powerful the ball is). The lifetime is affected by collisions from everything, however some decrease the lifetime more than others (such as walls). As the ball hurts enemies, it does hurt you -- imagine shooting a bullet at an enemy and it ricochet into you. You get 5 balls to throw and when you are out they recharge again at a rate of 1.5 second per one. Same as before, you can level up and upgrade your weapons. A GIF to showcase this is below:


However I understand that a GIF may not be appropriate to judge on these things so you can test the first game mechanics on a Windows and Mac. As for the new one, you can try the Windows and Mac versions. It would help us immensely if you try them out and give us feedback. We've even posted on #WIPWednesday thread on Reddit and the Wednesday Game Design thread for feedback.

Bugs and Code:

When my coding partner jumped in I was facing a problem where I wanted the ball to go through enemies at times and other times to collide with it. On the other hand, I wanted the ball to have a "lifetime" where it gets affected by collisions; the more you collide the less lifetime you have and therefore the ball dies. I was able to get most of that functioning but the collision and going through enemies based on the player's choice wasn't something easy. The scenarios I tried up to that point:

  • Changed the ball into a trigger which determines which object it "collides" with and then turn on or off the "isTrigger" option on the collider. Unfortunately that doesn't work as by the time "OnTriggerEnter2D" fired in Unity, the two collider circumferences have already touched and one is inside the other. As such, sometimes this worked and many other times it didn't.
  • Changed the ball into a pure collider, added a child object that has a trigger and made that trigger a lot larger than the original ball's collider. The ball's collider is controlled by the child. In the "OnTriggerEnter2D" of the child the "isTrigger" of the parent (the ball) is turned off or on depending on what is colliding with the child trigger. This didn't work. For some reason sometimes it worked perfectly and others no.
  • Changed the ball to a pure collider, had on the "OnCollisionEnter2D" a controller that turns on the "isTrigger" or off depending on the colliding object type. Again, didn't work just like the first

At last my partner came in and he changed all enemies to a trigger. Since I wanted the ball to collide with walls and go through enemies (or collide with them based on a variable) why not set it to a trigger and control that trigger from the ball? So we went with that and lo and behold, it worked! I set up the variable, set up the references and calls while he changed the OnCollisionEnter2D to OnTriggerEnter2D. But then I realized we need the variable to turn on and off the trigger so we set up 2 scripts. The first with OnCollisionEnter2D logic and the other with the OnTriggerEnter2D. At the beginning of the game the player determines what kind of effect he has (not intended real gameplay option but the player will definitely get to choose but not in this manner) and the appropriate script gets added to the enemy with the trigger being turned off or on.

The funny part, I spent 3 days looking for a solution to this and nothing on the internet worked. It was only this one solution that did. Since I didn't find anything similar on the internet (perhaps my research skills are lacking, I don't know), here is the code I have been using:

protected PlayerProjectile pp;
void Start()
{
pp = GameManager.instance.CurrentBall.GetComponent();

if (pp.ProjectilePenetrateTarget == true)
{
GetComponent().isTrigger = true;
gameObject.AddComponent();

}
else if (pp.ProjectilePenetrateTarget == false)
{
GetComponent().isTrigger = false;
gameObject.AddComponent();

}

}

Quickly I wrapped things up and made a build for the posts. Hopefully we can get feedback on the gameplay and see which people prefer.

Art; Graphics and Eye Candy:

On the other hand, Serg has been working hard on the art side of the game. He has finally finished the animations for the Ghost character and here is the projectile that he'll shoot at the player.

attack 10


He has also produced a few colored concepts for the dark wizard which you can see below:

4

I liked the colors of the 2nd one most with the skin color of the 3rd so we agreed we can make a mix and see how it goes from there. Next time hopefully we can provide you with a better drawn final. Meanwhile you can see the final product of the goblin here:

a836e67b18b4


That said he has finished coloring the armory level which you can see below:

72532acd5aee

Progress Results:

I did learn a lesson with promises as I have been promising a few updates a couple times and a few times I miss the promise (although I promised 2 demos this week and I delivered). As such I am not going to promise anything from now on with time and date. What I can say is that once we have the feedback about the gameplay we can move on to actual production and leave the prototype stage and jump into Alpha. All of this, can't be done without your feedback, so I can't stress enough how important it is that you try out both gameplay and reach out and tell us what do you think.

That is it for today, we do encourage you to try out the demos and let us know what do you think. Thanks a lot for reading and see you next week!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: