Day 3 – Feedback time for Prototype


For a Clicker based game I was working on, the MVP is ready and I had asked a couple of friends to play it to give me some basic feedback.

Here are a couple of snapshots

In a gist, its production and supply sort of a game.

Since this is the first feedback session, there were bunch of issues and lot of confusion on how to play. BTW MVP doesnt cover tutorials. For starters I just want to know if the game itself was fun enough. In case its fun and people like it, i will goahead and implement tutorials.

I had gotten a decent list of feedback i need to work on. I will get it fully done tomorrow and then go about asking for more feedback. I assume atleast 5 to 6 iterations will go on like this before the game gets to a decent place.

Also, it keeps hitting me about how often i use Assertions and intentionally throw exceptions. Here is a snippet.

I have a habit of writing down all the Checks before i put down any logic. This way, any in-appropriate data when received, it throws an error immediately. So whatever I write, it gives me a peace of mind knowing that if the execution reached beyond checks, everything is going to be fine.

Some of the developers try to run the build/game despite errors. They put trys and catches and make sure it doesnt crash. I feel thats not very wise thing to do when it comes to a game. because 1. since it might break somewhere else and we would have to waste development time to find the root cause of the issue 2. On exception, subsequenct lines of code wont be executed causing even more issues, unless u handle it carefully 3. Code will be super messy with too many try, catches & logs.

Instead of all that, i prefer putting a bunch of Asserts which will let me know if something isn’t alright. it will be easy to track down as well. Also helps in code readability as other developers will quickly understand what this method needs to have.

Leave a Reply

Your email address will not be published. Required fields are marked *