Project ‘KeepBall’ Week 1 – Working Solo, Learning A LOT

Hi there! DynaZor here.
I’m currently on week 2 of developing my new game code-named ‘KeepBall’.
(the name is taken so I’ll need to be extra creative soon)
It’s my first solo game dev project, which is mostly targeted at learning and
gaining experience in all areas of Game Development.
I won’t reveal the game yet,
but I will share some thoughts, experiences and lessons I got along the way!

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 🙂

Game Ideas, Game Mechanics and Questions

I was looking for an idea for a game to develop for some time,
and I finally found one a few weeks ago.
After I had the basic idea for a game mechanic
I wanted to make a game to revolve around,
I sat down to think up;

  • Will the mechanic will be fun?
    Does it have a room for evolving into something bigger?
    Would I play a game revolving around this mechanic if I had bumped into one?
  • Does a game revolving this mechanic would need a story?
    If not, what would make the players stick to the game and want to finish it?
  • Is this mechanic
    basic enough that there must be other games revolving around it
    or similar mechanics?
    If not, would it be hard to learn to play the game with its unique mechanic?
    If so, in what ways can I teach the mechanic while keeping it fun?
  • How much effort would be needed in making such game?
    How basic can the game be and still be fun and compelling?
  • Can I make this game alone?
    What skills would I need?
    What engine should I use? Should I make one?

The same questions made me reject the last 5 game ideas I had.
But this time, they all pointed out that this game is a must for me.
So I stuck to it!

Proof of concept and new ideas

I set the project up by 30/04/2019,
after writing all the essential information above.

I decided to go with Unity engine
because it is very common,
includes all the features I needed,
and handles C# (my preferred programming language) natively
and because I feel comfortable with it.

I started making the most basic level to test out the mechanic,
as a proof of concept.
Making it took me about 2 days.
I had to learn a lot about features I never used in the engine and C#,
because I never focused on game development or programming.
I’m mostly an artist.

While testing the basic level I had to make note of;

  • How does the mechanic hold up by its own?
  • Is it easy\hard as I thought?
  • Limits I discover.
  • Many new ideas that come up when first testing a mechanic.

I want to touch a bit on the last thing.
In any art form I participated in,
at the moment I see or feel the basic shape of the product,
my brain is untangling and the complexity of the product is made simpler.
Therefore, I use this as a technique.
For me to know if the idea is dull or is it just me not creative at the moment,
I go on making a simple replica of the end product,
and then try to experience it to its fullest.


I already had fun with it,
had a few levels in mind and some ideas for additional mechanics.
So I decided to go all the way with the idea I’ve come up with!

“So let’s begin development!” said the excited DynaZor, excited-liest-ly.
“NO!!!!! NOT YET!!!!” quickly shouted its somewhat experienced mind.
“Why, would you ask?” calmly added the crazy out of control mind,
“Well then, because you didn’t set up Source Control, of course!”
“Oh…” gasped DynaZor, and then set up a repository very responsibly.

So I made some decisions before I go on,
but right after setting up my source control.
I can’t stress enough how important it is to source control…

  • I want this project to be mostly a learning experience.
    Therefore, I will learn each thing I learn as properly as I can.
  • I want to learn to optimize all aspects of a game, so I set this goal:
    I want the game to be able to run on any Unity-supported device,
    performance wise.
    And to do so I’ll need every aspect of the game to be optimized!
    From lighting to physics, from textures to models;
    everything I make or know I can modify.
  • I want to have a working demo as soon as possible,
    so I can play test  and show the game early on.
    Also, in each stage the game works well enough, I will make a build.

Now, after making a plan for the game development,
I can finally go back to the engine and go on developing!

First week goals and the outcomes

I wanted to reach these goals at the end of the first week:

  • Have a working demo with a couple of levels in varying difficulty to play test.
  • Have a clean and organized code before making the build.
  • Have at least 3 people to play test and send me feedback.

So, everything went well and worked great on Thursday!
I actually had reached the 2 first goals quicker than I thought!
I was ready to finish up some details and send the game to the testers!
For some reason… on the next day…
Unity decided it has had it (!) with all “Find” related commands,
making the game completely non functional because of that.

I spent 10 hours testing and searching for a solution.
After which I spoke with a fellow game dev I worked with,
and he handed me a solution to replace the “Find” command.
Basically using a Singleton, but it had more to do with the following lessons:

The most important lesson was:
When I want to change a variable inside another class,
the best way (to my knowledge) is to do it using a public method.

The 2nd most important lesson was:
Don’t rely solely on code,
it’s better sometimes to set public variables from the inspector.

The 3rd most important lesson was:
Prefab all consistently needed components already set up,
even if it seems easy to set them up manually each time.

The 4th most important lesson was:
– RTFM –
(Read The Fine Manual, please)
I already go by that, but boy how much it helped me in this project!

And also,
try to avoid MonoBehaviour classes that rely on each other on their init time.
(Awake, OnEnable and Start methods
which call other classes that might have not been loaded yet)
It makes a mess.
My solution was to assign each of the 5 first frames of each level to some
commands and only then let the player interact with the game.
I’m still looking for other solutions to my problem…

After solving the huge problem, the game worked again
and I could send the build to the testers.
And so I did 🙂

Handling the first feedback wave

As with everything in life, feedback has two faces (or sides)
One side is nice to know and hear,
soothing feedback which gives a direct boost to going your way.
The other side is a bit harsh, and most don’t want or know how to deal with.
But what makes a good feedback is a feedback that touches both sides!

So here’s how I handle feedback for my art\products:

On one hand

  • I must take into account that the game isn’t finished yet and therefore
    will unavoidably look amateurish to the testers.
    Just remember to polish it when the time comes.
  • Some parts of the game aren’t finished, implemented or even exist!
    The testers (should) only know what they’re shown.
    So if a tester suggest a feature or a fix which you already planned –
    be glad (!), and there’s nothing to be mad at the tester for.
    Another tip, don’t tell the testers when you change stuff –
    let them experience it themselves
    and notice their reaction to the change.
  • Not all feedback is relevant to your game;
    Sometimes the testers get the same inspiration push
    you experienced when first play testing your mechanic,
    and they’ll occasionally come up with ideas for their own different game.
    Stay true to your own idea and keep notes for the next projects.
    This way you have a better chance to finish your project!
    Changing the core idea every so often will eventually
    halt the development until it’s stable.
    I believe this process should be done before mechanics and levels are made.

On the other hand

  • I must do something with the feedback I get!
    If it was said, then it must have some value,
    why else would a person tell you that they’ve said?
    (except lying and manipulation… Something not often discussed in game dev)
    At least write the feedback down in the project’s feedback database.
    (that I suggest you make and maintain)
  • The feedback might seem dumb, lazy or just false,
    But you must know that your perspective is different from other people’s!
    Especially when making art!!
    You made the mechanic and you (in most cases) know the most about it,
    others might even be completely new to it!
    Also, different people have different skills.
    Decide what audience your product is made of and act accordingly.
  • The feedback can feel a bit harsh and you need to learn how to cope with it.
    Good feedback don’t take your feelings into account
    while also being a bit sensitive.
    At the beginning of the development,
    DO NOT rely on good feedback as a source of motivation!
  • Also you put a lot of effort into your project
    and you might have emotional attachment to it.
    That’s always a thing…
    As an artist I learned over the years how to
    detach myself from the project
    when observing it and when I show it to other people.
    I only let myself feel the attachment to the project
    after good feedback was delivered, to enjoy it.

You might notice that I made more points on the other hand,
that’s because most often than you might think – feedback will be negative.
Sometime rightfully and sometimes not so much.
But even more when the game is in development, as I’ve already stated.

The feedback I got on my project was so warm and nice…
I didn’t like it! Ha! I want to hear the truth;
The game looks bad, isn’t accurate, too hard at parts and too easy at others, etc…
I kept it together, and didn’t criticize myself,
as I, too, know the game is still being developed.
I noted what people liked – and will probably keep it,
and what people didn’t like – and will probably improve or change it.
Also, it was nice getting 2 new sub-mechanic ideas! (they’ll get credit of course)

Looking forward & planning ahead

Now, after I’ve got the first wave of feedback,
I can go back to making the game!
My main goals for the 2nd week are:

  • Fix a hidden game-breaking bug that can occur but didn’t yet.
  • Improve the game according to the feedback and my vision.
  • Improve the main mechanic.
  • Make the systems in the game more scalable,
    which will give me more freedom in the future
    and will reduce development time.
  • Make the next few levels and sub-mechanics,
    one by one, while testing and perfecting.
  • Keep on writing organized code
    with explanations where they might be needed.

I know I won’t be able to achieve all the goals this week,
especially as I’m “wasting” time writing a blog post,
but I must plan ahead to make the path clearer.
(I believe making dev-blog is a mandatory task in the development process)

So I’ll leave you here, with a greeting of course,
go rest a little and then back to developing…!

Have a nice day,
Shahar DynaZor Alon.




Leave a Reply

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