RSS

Ball Ball Post Mortem

18 Jun

Ball Ball is a prototype 2D fixed camera physics based ball interaction game. It was created using Unity 5.3.3f1 and in collaboration with another team member –

Programmer: Jordon Dodds. https://lifeofdodds.wordpress.com/

It’s a free download on Itch.io.

What Went Right:

Communication & Effort

The amount of effort and communication between Jordon and myself was great. Throughout the entirety of working on Ball Ball we spoke on an extremely frequent basis on everything ball ball related. It made the creative process so much easier and more enjoyable. Both Jordan and I put in the amount of effort required to get Ball Ball to a prototype stage. While Ball Ball still might not be the originally sized planned game, it wouldn’t be what it is without the great communication and collaborative effort.

Game Elements

How accurately this game transformed from an idea, to a concept and then to a prototype. Ball Ball turned out to have the exact play style and game feel as originally intended and documented. Almost every game object and the way it interacted with each other was also exactly as intended, with the exception of sticky goo (see what went wrong).

Documentation

Documentation

Even though the GDD, TDD and HCD could have used many more iterations, what information, design principles, visual aids and game systems were in place greatly bolstered the design process of Ball Ball. In this case, partly figuring out the game before it’s even been started makes so much more time for actually creating the intended thing, rather than a bunch of head scratching and thinking “what now?”. The task schedule was even being created on the go. Before Ball Ball was underway I quickly went through the TDD and GDD and made a list of some of the things that needed to be done. Once some of the objects had been completed, I’d add a few more tasks that needed to be done. With major objects like the ‘Ball’ and TNT for example, those as headings don’t break down exactly what needed to be done. Breaking down a task into what actually needs to be done set a pathway to achieve small milestones.

Task Schedule & breakdown.JPG

 

What Went Wrong:

Aspect Ratio

When converting from playing in the unity inspector to a build or maximized screen, some game objects were not in the camera’s view. That’s because I’d been constructing the level in a free aspect. Free aspect makes the camera show the amount of space that’s been allowed in the unity editor.

Aspect Ratio 1

What the camera sees in 16:9 Aspect Ratio

Aspect Ratio 2

What the camera sees in Free Aspect

And that is just because of the current unity window layout. Depending on how you have the layout in the Unity editor, the camera will adjust its view. I was making levels in free aspect on the computer at home and it worked fine because I had the same layout every time. But when opening a build of Ball Ball, or just playing in maximize screen, half of the level’s objects aren’t within the cameras view. I had to reconstruct all of the levels in a 16:9 aspect ratio. That way the levels will always be in the cameras view.

Scope / Time Frame

Without detailing an entire list of what didn’t go right, to sum it up – certain aspects that were planned, didn’t end up making it into the game. For example, the sticky goo made it into the game but had completely different functionality as intended. Particular aspects such as the ball launching mechanic and the finish zone could have been greatly improved. I also never got to create my own 2D assets, which I was genuinely looking forward to. This is partly because it was only a 3 week project, two of which were documenting the idea and making the game concept more solid. It was also partly because maybe we should have realized that it was only a 3 week project and toned down the scope. It was either have a completely perfect design concept with systems ready to be created and have no game. Or have a somewhat functional design with a working prototype.  Or alternatively, a perfect design and a perfect game, but no sleep.

Repository Pushing

I had issues with GitHub commits, pulling and pushing towards the end. This was because the git ignore was in the wrong location. If it’s not in the very base layer of the project, and by that I mean not in the very first folder that holds the contents to the project, the git ignore file doesn’t do its job. And because of this, it subsequently adds a whole bunch of stuff to the upload that stops it from uploading.

Gitignore.JPG

This is Right

Until next time –

FeenikxFire

Nic

Advertisements
 
1 Comment

Posted by on June 18, 2016 in Uncategorized

 

One response to “Ball Ball Post Mortem

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: