Making, Selling, and Thinking Indie Games. draft 1

Miscellaneous Forums/General Discussion/Making, Selling, and Thinking Indie Games. draft 1

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

knowing how to make a bitmap rotate, or how to re-order a list of items in code or not, has no bearing on your ability to apply those actions.

If you think that knowing the ins and outs of hash-tables will somehow help you to design a videogame, you are sadly mistaken.

Ideally, a game should be designed by the people who will play it. One day, that will be the case. (Ala holodeck)

Today, it is best to be able to step back and see the game from the point of view of someone who is playing it. What they will think is fun.

That, is far far more important than knowing how to code it. That is the programmers job. Figureing out how to apply realistic physics to a ball that has just been struck by a bat in 2D.

Knowing what it should play like, and how to make it work are 2 different things.

The programmer might think to use a vector line for the bat to calculate the angle the ball was struck at. The designer need only know the ball will fly in the right direction. Knowing how it got there might help him compromise his ideas later on, but that is all it will enable him to do.

Still... Knowing that it uses a vector line, is all he needs to know. He doesn't need to know how to code that. Indeed, trying to keep things like that in mind will take his attention away from the big picture. Which is what the player is going to see.

The player will never see your elegant solution. They will just feel how the game plays. What feels right, and what doesn't.