Hi!

I've noticed that every time I try to prototype a game idea of mine, I end up very confused as to the general, basic, structure of the game in terms of program design.

If you have a set of basic classes, say some abstract "GameObject" interface, and subsequently classes implementing that, a "World" handling the state of your game, etc - What do you allow them to access, and how? 

Say I have some class that handles Input for me. Do I want the "objects" of my game to be able to access that input? If so, do I pass an instance of my "main"-class to every object? Do I declare global, static, variables? 

I am aware that this is a very bad and very very broad and general question, but I was just wondering how you guys usually define and implement the relationships between your basic classes, no matter what type of game you are writing. 
On one hand, I'm trying to keep things as simple as possible so I can actually get a prototype done, but on the other hand there needs to be at least a bare minimum of well thought-out design in order to not let everything get messy way too soon. 

(Oh, and just about the two "ways" of doing things which I mentioned above - I personally dislike both. But I also feel like coming up with something else requires a more well thought out design that just isn't fit for fast prototyping. I don't know.)

Any opinions, suggestions? Thanks!

If you're prototyping, don't worry about all that nonsense. Make everything public, and get your prototype done.

I say this as a person who prefers writing the "engine bits" of a game to writing the game's themselves. Designing a robust game framework is hard/nontrivial, and it's going to take a few iterations for you to become satisfied with your work product. If you're trying to finish a game prototype, don't worry too much about the engine details. Just make something that works.

But to answer at least some of the questions you floated, yes your GameObjects should be able to access user input. How you do it is up to you. One big-ass global GameLogic object that has everything in it? Sure, why not. Or, an event queue that contains user input events obtained from whatever library you're using (DirectX, SDL)? Yup, that works, too. Pick a way and run with it. If you get stuck, pick a different way :-D

What is the intention of the prototype? If you want to check the working of a technical (i.e. implementation oriented) aspect, then the architecture obviously plays a bigger role than for prototyping a gameplay (e.g. balancing) aspect.

Prototyping is about quick and - somewhat - dirty programming. However, that does not exclude usage of middleware (including your own successful stuff from previous attempts). If you have a particular solution at hand it may be even quicker to integrate that instead of again making one from the ground up.

A game object should normally not have access to user input. In general user input (assuming we mean usage of a physical or simulated input device here) should be translated into "intentional actions", and that is what selected game objects should see. This is one step of input abstraction and makes input mapping easier. Regarding prototyping, however, you may want to ignore this rule.

I totally agree with masskonfunzion and haegarr: making a prototype means getting the core gameplay ready as fast as possible. It's so easy to fall in the traps of pre-planning and pre-optimizations, but that's the real evil.

I would also suggest you to avoid OOP too. Simply put your data in a bunch of structs (if you're using C), load them, then update and render in your game loop. That's all.

In my blog I'm even making a very basic game within a single .cpp file

Its hard to say what is : gameobject.

I personally dont pass anything, no device nothing, keep it all global.

Why would you pass device, because its in the examples ?, no pass is less typing.