Project ‘KeepBall’ Week 3 – Priorities

Hi! It’s DynaZor again,
Project ‘KeepBall’ just passed 3 weeks of development!

 Disclaimer:
Everything in this blog post is written from my own point of view
which is based solely on my own experiences and knowledge.
I might be wrong and I know it.
Also, not everything written on the internet is factual 🙂

Weekly goals

As with every week of the development, I set myself goals to reach.
This week’s goals

  • High Scores system – done
  • Code cleaned
  • 0 Mechanics and 2 levels made (planned 1 and 7)

Also,
I made an Achievements system with 3 achievements and fixed major bugs.

I underestimated the work needed for the High Scores system
and I ended up making the Achievements system, too.
So I didn’t have much time for making new mechanics and levels.

Making 2 new systems in a week is still fast for a solo developer with little experience in programming so I’m proud of myself.

It will be easier to work creatively on levels when my mind is clearer without the worry of a non functioning or missing system.

Here are my next week’s goals:

  • 1 New mechanic and 4 levels
  • 3 Achievements, 2 of which are complicated
  • Graphics for the achievements
  • Make the GUI responsive (to support different monitor ratios)

Let’s see how I’ll hold up next week.

“And how does it feel, Week 3?”

I really wanted to get things done and see more visual results this week…
But I need to keep the testers engaged as they volunteer
and have good reasons for them to test the new versions thoroughly.
So I couldn’t delay making the missing systems anymore,
for the sake of smoother workflow and engaging the testers team.

Most of the week I was fixing bugs
and trying to figure out how to program the systems.
It was quite exhausting and non rewarding most of the time.

A mistake I made was working when exhausted,
because then I made new bugs I had to fix later.

Now, after the systems are in place, I can work  on levels without worries.
Which will help me make them better!

Importance of feedback

I believe in listening to feedback and measuring its usefulness,
without jumping to conclusions and changing the product.

Also, I believe the best way to get feedback is to
introduce the product to an audience while looking at them.
(when it’s a game, record the screen to look back later)
This way you’ll get the real reactions without any filtering and masks.
You can find problems immediately and sometimes even
find a simple solution quicker than trying to understand spoken feedback.

This week I had a chance to do exactly that with one of the testers
and I found some problems in gameplay I didn’t know of
and some I couldn’t replicate on my own.

Those I couldn’t replicate on my own
were happening only when playing the levels slowly,
which I don’t do anymore because as a developer,
I’m mastering the game mechanics while making the game,
and then I keep playing fast.

Also, the players couldn’t notice easily enough
that they fail in a button sequence.
I asked the tester “You failed the button sequence, didn’t you notice?”
listening to myself talking, the solution was so obvious to me –
add auditory feedback.
It sounds so obvious! But while making the game myself,
I need to prioritize tasks, and sound wasn’t in my top priority.
Now it is 🙂

Similar games – a game-dev nightmare

While making any start-up, there’s always the stage
of checking whether the product already exists or not.
It’s one of the most depressing things to know that
the idea you’ve been working on (or planning to) was already made.
I call this “the moment of truth” in finding out how creative I am.

Because this project was mostly a learning and passion project,
I delayed this check, just so I have motivation to go on with it
even if similar games already exist.

That moment has come when I researched the gameplay of my game,
and as part of the research
I need to find similar mechanics in existing games,
test them and find the problems that could also be in my game.

My game’s main mechanic was used in a few games,
but they didn’t feel polished and complete.
To relieve my stress further, I compared the state of my game to those.
I don’t condone comparing pieces of art,
but when talking business it’s a must as part of market research.

Tips and tricks

Those are written with Unity (2019.1.0) in mind

  • yield return new WaitUntil(() => BoolToBecomeTrue);
    Thanks to developers from Game Dev League I finnaly got it.
    Basically it checks at the end of every frame if the statement is true.
    When it is, the coroutine it’s in will go to the next lines.
    You can also use it like this:
    yield return new WaitUntil(() => i++ == Number)
    And every frame, before the function checks the statement,
    it increments the integer.
    This way you can make an Enumerator (Coroutine)
    wait a specified number of frames! (which is what I needed)
  • yield return null;
    This will make the coroutine wait for the end of the frame
    to execute next lines of code.
    Putting it one time will make the function execute on the 2nd frame,
    two times for 3rd frame and so on.

I hoped there would be more to talk about but there wasn’t much…
So this is it for this week!

Have a nice day,
Shahar DynaZor Alon.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.