So, I am creating a base prototype for some of the game mechanics. Just the ones that are different and I don’t really have a reference for. Creating the stuff in Unity is exceptionally simple, but I do not intend to make some rough sketch of the whole game in such a way. That is a waste of time.
There is a lot of preaching these days about how to make indie games, and what the process is and how to do it properly. Most people that have not made a game or understand why they did it that way, tend to just mimic the way it has been done because the process is not fully understood.
“You have to make a prototype!”
I have heard this line from a number of people and this is not the first thing I did. I only make a rough prototype for the game mechanics I think are original in some way. Making a prototype for items that are to be found in other games you should not bother with. Don’t get caught in checklists and formulas. You should be confident enough to analyze what needs to be done, how and when. If you would take the time to master an instrument, create music, create art, draw, sculpt or paint, you would be introduced to some heuristics and processes that can be applied to engineering that most engineers don’t take seriously. Don’t commit to detail to soon! This will ruin music, drawings, paintings, sculptures, software and games. If you start focusing in on one item too soon, you can break the continuity of the whole.
If you can make your prototype out of board game components then don’t bother with programming. But, where the mechanics call for behaviors that are very hard to implement with board game components, you are actually forced to make an executable demo. When you can use board game components, you can even have friends come over and play the game with you to find where it fails or succeeds. You don’t have to worry about the board game resetting itself or crashing while they are playing it. Complete stability of intended features.
The problem with using heuristics and advice that come from successful teams is that you can only assure yourself that it works for that particular problem in that particular environment. That is why software engineering practices change every other year. What is the new way of making software. What system, language, IDE and methodology are showing the most favorable statistics?
Be adaptable and throw conservatism out the window.
If I actually see a way to create a rough sketch of my mechanics with board game features, I would drop using Unity for prototyping as fast as my system could kill that process.
V 