Hi there! DynaZor here.
Project ‘KeepBall’ has passed its 2nd week of development!
In this post I’ll talk about my development process, organization
and how I manage to keep going through all this hard work.
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 🙂
It is mandatory to take a break from a subject occasionally to not burn out.
But I had the urge to keep developing!
One of the advantages in a solo game dev project –
is that you need to do every part of it.
(it is sometimes a disadvantage.. a huge one)
So after last week’s 22 hours of development, I took two days off;
I worked on visuals rather than code and gameplay.
I fixed a major problem the game had because of the lighting
and optimized the graphics of the game.
I’ve set some goals at the end of last week.
(written on my last post, you can read it HERE)
Here’s how I’ve held up:
- I fixed the hidden game-breaking bug.
- Improved the game according to the feedback and my vision.
I have a new subject to research regarding mouse control.
- Improved the main mechanic.
- Made the systems in the game more scalable.
- Kept on writing organized code.
- Made 1 new mechanic and 3 new levels (2 with the new mechanic)
Also, I made a Save System, a Level Select screen and Options menu,
many many visual improvements and some gameplay improvements.
So I can say confidently that I held up pretty good!
So here are my goals for next week:
- Make a High Scores system
- Clean this week’s code further
- Make at least 1 new mechanic and 7 new levels
I want this week to be new-levels-centric,
and it is the most time consuming and exhausting so I don’t plan much else.
Also, learning from last week, I take into account that
I might decide to make some unplanned features in the game.
This isn’t be the case when I work in a team,
but now I have more freedom and I want to use it for the good of the game.
Feelings – Week 2
The first week ended with getting all the feedback,
getting excited of how well the project is going
and feeling the advancement in the development.
I would describe the 2nd week of this small game development as
~The Grounding Week~
After all that adrenaline rush, the fall was predictable.
And so it came.
The 2nd week felt slow, technical and unsatisfying.
I don’t know by how much,
but it must be harder for people with ADHD, like me…
We must feel excited about what we do or else we lose interest.
To combat those feelings I use some tools;
- The weekly goals
look back on and remember where the game stood
last week compared to now.
- Mission tracking
in which I separate each week’s done tasks.
- The dev blog
to see how much is being written about the week.
I’ll touch the 2 former tools in this blog post.
But now is time for a different matter, to keep things fresh!
Players’ Learning Path
This week I was dealing with the choice of learning path.
I needed to choose between:
- Self Explanatory Game;
In this method we’re relying solely on the players
to understand the mechanics.
For that we need to make the levels introduce the mechanics to the players at the right pace, which requires a lot of game testing
but builds confidence and gives the feeling of success and excitement when players progress.
- Visual Tutorials Throughout The Game;
In this method we don’t rely on the players to understand,
but instead we teach them step by step and make sure they got it all.
This makes the game easier to understand
but makes it a bit too predictable for my taste.
- Self Explanatory Game with a Help Button;
In this method we combine both previous methods.
We give the players the opportunity to understand
by themselves and get the success,
while they always have the option to get guidance.
I try to ‘get away’ without making a visual tutorial because I don’t like those.
The main target audience of the project is
puzzle loving, control freak, casual gamers.
I’m part of it. Which is good for me. Yeah. Go me.
The people I know love figuring things out by themselves but not to get totally stuck in a game.
Maybe I already gave it away but I chose the third option.
Mostly because the game is pretty casual and needs any additional boost,
and it is targeted at that specific audience which would prefer it AFAIK.
It’s quite important to keep track of time, missions and issues,
even when you’re not working commercially.
Having an accessible and organized storage of past ideas
is a must for games in early development stages.
(I may change the last part to be more general in the future)
I use Trello (not affiliated with them) for my mission tracking.
I keep track of issues and missions in a “Tracker” board,
have a storage of ideas sorted by category in “Ideas” board
and keep links to all my builds in “Information” board.
This way I can always reach anything related to the game!
When using source control,
I stick to detailing differences made between the commits.
This way it’s easier to find specific commits
and I can look back to see how much was done this week.
I want to keep track of how much time was invested in the project,
and for that I use ManicTime free (again, not affiliated).
At the end of the day I choose all the programs I used to work
and add a tag to them.
This way I get a huge database of daily,
weekly and monthly work hours!
I also use it to prevent exhaustion;
I just check each time I get back to the computer
how much I worked today and act accordingly.
A great reason to keep track of time
is better evaluating amount of time each task takes.
This is very important while working commercially
as you need to manage missions and plan efficiently.
The dev blog is made both for you and for me.
You and other people can benefit from my experiences,
while I have another way of tracking progress and a solution ‘bank’.
I try to make the posts the easiest to read and navigate.
I use titles so it will be easy to find and read only the most interesting subjects to us at the moment
and bold words to let us read only the actual important information while still getting the point.
(just look at this bolding-job!)
I only write information that might be useful
and the lessons I learned that week.
To make dev blogging easier,
after writing last week’s post I make a list of subjects to write about.
Gradually adding more subjects while working during the week.
This way I spread the time needed for a post on the whole week.
Also, this way I don’t have to sit and try to remember what was happening during the week, I just write when it happens.
Game Mechanics – In or out?
At the beginning of this week I was pretty sure that one of the mechanics
I made for ‘KeepBall’ is not fun and shouldn’t be in the game.
I had the urge to at least keep the mechanic as a visual feature for the game,
if not a gameplay mechanic.
After much thought and testing, I came up with an alternative solution;
I’ll make this mechanic harder and then I can use better.
It doesn’t always work that, I mean it rarely does…
My point is it’s important to keep even the ‘bad’ parts;
back them up somewhere, for when you come up with a related idea –
you can just reuse them.
It might sound basic, but while developing we need to keep things neat,
and throwing stuff away is mandatory.
In the process of cleaning assets we meet with the decision
of whether to keep or delete the unused ones.
Relying on source control in that regard might introduce difficulties when the need of restoration arises.
My simplest solution for this whole mess is to
make a folder named “Unused”, ignored by the source control,
in which I keep those assets locally.
Tips and tricks
Here are a few notes for using Unity (currently 2019.1.0)
- Playing animations while time.TimeScale = 0
>On the Animator component, set ‘Update Mode‘ to ‘Unscaled Time‘
useful for making GUI and HUD while pausing the game.
- GUI doesn’t respond to the mouse
Make sure there’s a parent ‘Canvas‘ with ‘Graphic Raycaster‘ component.
- (Binary) Save data from older versions crash newer version
Inside the loading method make some conditions to check if
the data is compatible and add fallbacks.
In the new save data there’s a new List<int> for storing High Scores.
(I currently prefer Lists rather that Arrays…)
So I add the following lines inside the loading method:
if (HighScoresList == null || HighScoresList.Count == 0)
// -1 is my default value for an empty score.
// Add to the top of the file: using System.Linq;
New levels added in later version, now what?!
Add these lines right after the last ones:
else if (HighScoresList.Count < NumberOfLevels)
(-1, NumberOfLevels - BestLevelResets.Count));
SaveGameData(); //Just to be sure it won't happen again
- The scenario is:
There’s a RigidBody moving around, hitting stuff.
One item should not be affected as much from the RigidBody,
or even, should knock the moving one back.
(while searching solutions I defined it as having stopping force)
If it’s only a collider of a static object – add a RigidBody, freeze it.
Then, increase the static item’s RigidBody Mass to be
well above the moving one’s.
I also made a Physics Material with a high Bounce value for the static object.
(*by static I mean non-moving, not the ‘Static’ setting of a GameObject)
This is it for now!
This time I’ll take a real rest and leave the project alone for some time,
and then come back with more energy and new ideas.
Have a nice day,
Shahar DynaZor Alon.