I know I may sound like a broken record, but this is important:

A well designed product in the beginning leads to an easier time later on!

This is why designers get paid the big bucks (or at least they should). A designer anticipates the problems before they happen. Most of this comes from experience with whatever you are working on. You learn what the roadblocks can be, so you design ahead of time to avoid them. I'm not saying that you can design everything at once. Honestly, I think that is a terrible idea. You need to focus on one problem at a time.

"Boris... isn't that contradictory to what you just said?" Hell no, it isn't. You have to look at it from the proper perspective. Up front, it might appear easier to do just all of your programming in one file (not to those who are experienced with design). The problem ends up being that your code will not be portable into something else. You will spend all of this time creating a product or a game, and you will never be able to re-use it without retyping or copy/pasting to a new file/object.

Think of all of the enemies, projectiles, players, obstacles, and anything else in a game. Now, imagine having to retype everything all of the time. You will NEVER finish your work. So we have this stuff called inheritance and polymorphism. Forgive me for not going into much detail. You can check out the Wikipedia links for those if you want to learn more. Here's an example that I recently just went through. I have an Enemy class. It can update and do other random things, but then I want a different kind of enemy. I created the Enemy class a base class that can be inherited by other types of enemies. I wanted to create an enemy that strafes the whole of it's existence. I override how a typical enemy moves, and I put in the specific behavior for this strafer. It took me about an hour or more to get my base enemy class setup. It took me all of ten minutes to get the strafer up and going.

Reason it took so much less time is I only changed what was different about the strafer versus the generic enemy. The rest of the logic doesn't change, and it gets destroyed, shoots, and draws to the screen as designed in the base class. The movement is the only part that I call out as different. Most of that comes from having a little experience with how game objects work in this environment, so I was able to design the objects accordingly.

This next part is going to be a little exercise for you to try.

1. Pick your head up from your screen, and identify the first thing that you see
2. At a very basic level, what is that object?
3. What can the object do?
4. What are the properties of that object?
5. Now think of a similar object, and start to classify what makes them different and the same.

Here's my results for the exercise:

1. A Sriracha sauce bottle
2. At the very basic level it's a container
3. What it can do:
   • Hold sauce
   • Squirt sauce
4. What are its properties
   • Amount of sauce it can hold
   • Composed of plastic
5. There is also a glass bowl on my desk
   • The glass bowl can hold a substance, and it has a specified amount of substance it can hold
   • It's different because it can't squirt the substance, and it is composed of glass and not plastic

In my example, a base class of container could have a property of "Amount of substance" and "Contain substance" (along with all the basic actions of containing a substance). The differences between a bowl and the sauce bottle can be distinguished when we just add "Squirt speed" property and a "Squirt" action. The container class will still handle all of holding functionality for the sauce bottle.

That's one of the things I love about the design process. You break objects down into their essence. What gives a bottle its "bottleness"? Here is a basic way to help understand a little more succintly how to break down these objects. We will use the "Is A" relationship using my example above. Feel free to try it on your own as well.

The sauce bottle Is A container. The bowl Is A container. Then there is also the "but" clause. But a sauce bottle Is Not A bowl. 

That is probably the easiest way to make distinctions between different objects in programming. I will have more to say on design later. Hopefully that should be enough.

Since this seems to be a theme amongst my partners-in-crime, I'll weigh in too...

I have no problem with people getting paid to play games for other people. They are providing a service the people are willing to pay/donate for. Why should we deny them this? Should we deny any entertainer money if people are willing to pay? No (as long as what they are doing is legal).

From the perspective of a novice game developer, I can see why some people would maybe be upset by this. For me, game development is not a means to an end. I'm not in this to make money. I'm in it to learn, make awesome games, and teach others. I'm not saying this to belittle others that do this as their job, but that is my situation. 

When we finish a game, if I go on Twitch and I see someone playing a game that I've made, I will be ecstatic! I would probably jump on the chat and start talking to the person playing. If someone would see fit to play a game in a public forum that I had a part in, it would be the highest form of praise for me. It would be an affirmation of everything that we had worked on to get it out there. If you are selling it, then the sale of your product could rocket if the right person plays it. Most gamers use that as a way to see what games they might want to buy. If they like it, they most likely will go and buy it.

I would probably go out of my way to market games that I work on to get these people with hundreds or thousands of viewers to play it. In fact, that's one of my goals for indie development. I want someone to play my game on Twitch. I want to see someone and an audience talking about and enjoying the game. So for all of you streamers out there, keep on doing it. I know that I love it.

Thanks for putting up with my rants,

Boris