Indie Quest — Week 9; the creep news - Castle Mashers

This is the ninth 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:

Indie Quest — Week 8; finally a demo!
This is the eighth entry in my devlog about my endeavor in making a game within 2 months (supposedly ) and releasing it…medium.com

This week we have made a progress with the demo and we have added a few features. We stand now at version 0.098 of the game. We’re that closer to an Alpha, yay!

Mood, feelings and motivation:

Taking a moment to reflect on what has transpired in the past 3 months it was overwhelming to see my design has evolved and changed as the days go by.

In the first post of this series I mentioned that this was an old design I had shelved. Back then (and still was so if I recall correctly) when I started the project, the idea was just to make a breakout clone with boss fights. Something simple I can finish in 4–6 months maximum.

Dear GOD, I was so wrong… oh my GOD, feature creep is incredible. The first plan was just to finish a complete game I’d upload on Kongregate part of the course and be done with it. I’d recruit an artist to help out and I’d use free music from the internet. So what happened?

I was taken by the rush of the feedback I got when I showed the game to people. All of a sudden the planned 3–4 enemies became 10, the first 3 bosses are now close to 8. Effects, polish and full GUI design and a professional musician are now part of the project.

While that isn’t bad at all and I don’t regret one bit of it — I am thankful if anything, it wasn’t my original plan at all.

Does that mean I surrendered to feature creep? Not particularly. To be honest, I had a much more elaborate design once I received that my design was solid enough for a full scale game. Much more was planned (multiple character, multiple upgrades, leveling up, choose your own path in the game, etc..), it was to be a full RPG and I still have that design document. I was hard at work trying to make it happen the first month until I realized the sheer amount of work needed.
There is no way we (my partner artist, our musician and myself) in the period of 4–6 months. NO WAY! Times and times again I have read on the internet that you need to cut down your design and between you and I, I thought with the above mentioned original document that it was cut down. I wanted a full RPG with battles only happening in a breakout atmosphere. However, I quickly realized that is way too much and imagined that by cutting the “full scale RPG” down, I stopped featuring creep in its track. I didn’t.

When people talk about feature creep on the internet and say that you need to cut down things that aren’t essential to your design, they aren’t talking about sacrificing “100 KM x 100 KM levels” to “10 KM x 10 KM”. While that is sacrifice, that is still considered “feature creep” if you won’t be able to deliver on that. Eliminating feature creep is about preserving the most important, essential, core elements of your design and stand guard against changing them into a monster of their former self.
It is about realizing what you can do and gauge features based on that. Realizing the time limits and team limits as well as business limits you have and change the goal of your game to suit that.

It was hard at first and I tried to deny it for a long time. But I’ll be honest, I feel much more confident and much more “free” the moment I cut down a few features.

Here is a quick list that won’t be available at launch because of the current constraints we are tied by:

• Multiple characters to play with; only one character will be available at release date.
• Each character would have its own play style and its own abilities.
• Multiple castles; currently only 1 castle is available with multiple rooms (levels).
• Ability to choose your path, interact with NPCs like a normal RPG. This point is completely gone from the design (not only it is a feature creep, it doesn’t fit the game pretty well).
• Buy and sell weapons, shields, armors, etc… Completely removed but we’ll still have upgrade based abilities.

That said, if Castle Mashers becomes a success, we might be able to release most of the above features as part of a DLC or an upgrade perhaps. I am not a fan of releasing “features” as a DLC to get more money but if we have a sizeable DLC it would be worth it (if we get enough players that want it).

Bugs, Design and Development:

Recently we participated in Feedback Friday on Reddit to get some feedback on the game using a slightly updated build (linked below). Honestly, the feedback was really helpful, our fellow developers brought up many bugs that I have noticed and have been delaying till the point I forgot about it and others I didn’t know of. That said, they also had a lot to say about the art and the general polish of the demo.
It was an insightful experience that I will gladly go through again once we have fixed what has been mentioned. I whole heartily recommend posting your game there ASAP, the feedback is just irreplaceable.

But I wasn’t sure if I was moving on the right track, there are still many things I’d like to confirm in my understanding. So normally I wanted to seek help, ask some of the veteran members of the indie industry and see what they can advice me with. I did just that, I sent an email to a few of the most recognizable names in the indie industry — those devs that you hear lots of talk from and always tell you to approach them? To ask them or others for advice? Not to be shy and network?
Each email I sent, I praised their skills, told them a quick overview of what I wanted (have a chat) and recognized they are quite busy so the time and date they choose. The email didn’t exceed 15 lines (if you count the greeting and such). Guess what? I never heard back in every single case. A few weeks past and I didn’t even receive an email saying “Sorry I can’t do that”. I even included in the email, if you are busy and can suggest someone else, please do. Nothing, nada, null, nill!

Luckily I had a chat with someone that introduced a few aspects that I didn’t think of when making Castle Mashers. I should start using OOP rather than just component based coding only. What does that mean?

To give an example that would explain this; the enemies in the game. I made a global script called EnemyCollisions.cs this handles the moment of impact between the ball and the enemy. This script handles reducing HP, destruction of enemy, spawning the loot and reducing the number of enemies for the wave mechanic.

Here is a snippet of the code I am using to get an understanding:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class EnemyCollisions : MonoBehaviour {

    public int hp;
    public int minCoins;
    public int maxCoins;
    public bool NoParent;
    public bool Orc;
    //public int minHPManaChance;
    //public int maxHPManaChance;
    public int coinValue;
    public int manaCollectibleValue;
    public int hpCollectibleValue;
    public int hpManaMaxChance;
    public Object bloodSplatter;
    public Object damageEffect;
    public Object deathZoneDamageEffect;
    public GameObject lootSpawner;
    public Object goldPrefab;
    public Object hpPrefab;
    public Object manaPrefab;
    

    private List<GameObject> gold = new List<GameObject>();
    

    // This checks if there is a collision between the ball and the enemy.

    void OnCollisionEnter2D (Collision2D collider)
    {
        // If there is a collision between the ball and the enemy we deduct HP and then create a damage effect + shake the screen. All as long as
        // hp is more than 0.
        if ((collider.gameObject.CompareTag("Ball") || collider.gameObject.CompareTag("Ghost Ball")))
        {
            if (hp > GameManager.instance.Ball2EnemyDamage)
            {
                hp -= GameManager.instance.Ball2EnemyDamage;
                Instantiate(damageEffect, transform.position, Quaternion.identity);
                StartCoroutine(ShakeCamera());
            }
            else if (hp <= GameManager.instance.Ball2EnemyDamage)
            {

                DestroyEnemy(false, true);
            }
        }

        // If in case hp is 0, then we spawn damage effect, blood splatter, set animation for the enemy to die, destroy it and start the spawning sequence.
        

        // Reduce HP bar size to simulate damage taken
        HPBarManipulator();
        
    }

Each game object enemy has that script. But to handle movement and attacking each enemy has his own movement script and his own attacking script. So the zombie has two scripts; movement and attacking script and EnemyCollisions script. The rat is the same.
Yet, things get quite interesting when it is a boss, the boss in the demo for example has 3 scripts; movement, attacking and EnemyCollisions. While others had easier movement and attacking patterns, my setup required that I’d have those 3 scripts.

It was suggested however that I should take advantage of OOP; create a general “Enemy” class that has everything like Destruction(), LootSpawn(), Movement(), Attack(). Derive all other enemies from it. In all honest, I knew these concepts and they weren’t completely new to me. Thing is, when I watched the tutorials to learn Unity, almost none of them did this.
What they’ve resorted to is to use the methodology I’ve used at the beginning. Shockingly some of these tutorials are Unity’s official ones. I can understand that perhaps they have general scripting tutorials describing these concepts, but not all of their game making tutorials (specially the 2D ones) take advantage of these.

So now I am restructuring my code to look more like this:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;

public class Enemy : MonoBehaviour {

    public bool parent = false;
    public int maxHP;
    public int HP;
    public int GoldValue;
    public int HPValue;
    public int ManaValue;
    public int CoinAmounts;
    public int MaxHPManaChance;
    public int DestroyWait;
    public int Speed;
    public Object BloodSplatter;
    public Object HitEffect;
    public Object GoldPrefab;
    public Object HPPrefab;
    public Object ManaPrefab;
    public Object LootSpawner;
    public Object[] Waypoints;

    protected List<GameObject> gold = new List<GameObject>();
    protected enum EnemyType { StaticRunner, DynamicRunner, DynamicTargetRanged, DynamicStaticRanged, DynamicMeleeRanged, DynamicMelee };
    protected EnemyType type;


    void OnCollisionEnter2D (Collision2D other)
    {
        if (HP > GameManager.instance.Ball2EnemyDamage)
        {
            HP -= GameManager.instance.Ball2EnemyDamage;
            Instantiate(HitEffect, transform.position, Quaternion.identity);
            StartCoroutine(ShakeCamera());
        }
        else
        {
            DestroyEnemy();
        }
    }

    void DestroyEnemy()
    {
        Instantiate(HitEffect, transform.position, Quaternion.identity);
        Instantiate(BloodSplatter, transform.position, Quaternion.identity);
        gameObject.GetComponent<SpriteRenderer>().color = Color.red;
        StartCoroutine(ShakeCamera());
        SpawnLoot();
        Destroy(gameObject, DestroyWait);
    }

Not much difference but it is a start I believe in a better more manageable and easy to handle code. At least now when a bug happens, I don’t have to hunt 4–5 scripts to fix it. Just one or so.

Art; Graphics and Eye Candy:

Serg is still working on many aspects of the game and hard at work pumping out art. I have to say every time he just surprises me with the great work he creates. Here are a few new art pieces he has made:

Looking however at our progress so far, I have to say it was quite fulfilling when I compared the progress we had over the last 3-4 months working on the game. We started out this game with this:

As you can see barely any "art" in the screenshot and things look far more bland. Here is the same level now:

We aren't done yet and there are many, many things that need adjustment. Serg is still working on the animations for many of the game characters. Not to mention that based on the feedback we got, we have to change quite a few things. So hopefully with the upcoming public build we have new things to show.

Progress Results:

We’ve managed to release another public build and posted it on Feedback Friday thread. You can download and play the game by going to the Downloads section and finding the appropriate build for your system.

We are approaching Alpha and hopefully in the upcoming 2–3 weeks we’d be able to release a solid Alpha build.

With that said, I think that concludes our post for this week and hopefully we have more to show you the next. We may not have a build but know fully well that we are actively working to make the game better.

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