[page 0014] ~ Class Resolution:

Using application entry and run point interfaces.

My namespace MyI is my interface for MyInterface. FarNiche has no cognizes of things done before its namespaces ‘using’ statements, save that they are observed through seemingly vestiged ideals. And yet they retain need as required References which provide connections umbilically, through the use of interfaces. Now, my Game1 solution in the namespace CameraAI is on one side of a pinch point while the IDE, integrated development environment, is on the other. The production of MAKE files exuded from the compiler make it that way. Good enough, all I need is to deploy my exe with its xnb and other compiled resource files, thank you once again. Now its time to use my newest language, C#, see if I can get a grasp on this OOP paradigm, and get myself to the other side of this new pinch point set from between, top-down Structured Programming and over to Object Oriented Programming.

Reinventing the wheel, the inside not the outside.

And so, to emulate the concepts that promulgate scope and focus, inclusivity of the object oriented language syntax are engaged. With flows of data streams running throughout my games class interfaces, references to systemspace are made from my namespace. With there return, my namespace classes, which are utilized in-house by playerspace, the space the player intrinsically occupies, corroborate response cues. Reciprocation through the games interface elements provided through pad interactions present the player directional options. Inside these classes, methods and properties consume, ingest, digest and distribute data.

And so, what exactly does this OOP do? For instance.

In the main game class the one reference that instantly comes to mind is GraphicsDeviceManager. When given an instance variable, the class, because of references to systemspace, can draw to its type specific interface, the screen. To keep the scope of this class instance variable consistent, allowing other class objects access to this current instance and so can write to this current graphics device is what this OOP paradigm is about to lead me through. If, by poor design, a classes instance inclusivity is lost, the focus toward this dedicated instance variable, and therefore its utilization because of its lack of scope, forces it to become unattainable. The draw-calls provided to the screen no longer agree, the arguments are disjointed and the screen does not function correctly, if at all. Yep.

Hmmm, it worked in rehearsal. Veneration.

The question I have before me now is how to make an array of ScreenManager classes connect to there respective player controllers. Then, because there is a possibility of four players seeing their own player info above a main game board screen, which is subsequently the screen underlying the players info screens, the need of at least five game state management instances are needed. But, seeing that there are four players maximum allowed per console, I won’t be networking more players in just yet, only one PadJoin instance is all that is needed per game console instance to facilitate all four players. Each pad instance, of the four possible, from PadJoin is singularly assigned as an element within the array of the screen managers, leaving only stack index [0] with the background screen as a shared state player interface utilized by all players.

More candidates.

Just when you think you’re moving ahead, there are more choices which deny preclusion. “SpaceOn” is another game that I had started. This game was to be a simplification of the combination of the Chase Camera sample and the Shader Series 1: VertexLighting sample. Each of these contain a 3D camera perspective from either the ChaseCamera or the SampleArcBallCamera classes, respectfully. The direction of this game was to give the main background screen an ArcBall point of view using a position functionally set between player one and player two. The two dedicated split screens for player one and two would use mainly a ChaseCamera class to provide the view connected to their respective players controller. This is the simplified version which makes up SpaceOn. Another work in progress.

The thick gets ever thicker.

GameStateManagement has a ScreenManager and an InputState, the RPG – Role Playing Game has a ScreenManager and in lieu of InputState uses InputManager through the Update method, NetRumble uses three lists of GameScreen and also uses InputState, while NetworkStateManagement sample only uses two lists of GameScreen along with InputState. It looks like there might be a possibility of making PadJoin a GameComponent and just allow it to connect to the game from the this.Components.Add(PadJoin); in LoadContent. The question here is do I want or need it to be a DrawableGameComponent or simply a GameComponent for what it is to accomplish. Then with that in mind, will that move me closer to the OOP paradigm or back to structured programming. If I keep it a DrawableGameComponent, I’ll need the Draw method to be pronounced while in a specific menu option screen from the shared state of the background screen and accompanying menus. And where would that be found? I guess that would land me back into game startup and game level creation. Suoo-per-rrr. I think it would bode well that the drawing of the PadJoin test screen writes are made only provisional to the debug methods, leaving the utilization and drawing to other game play specific objects and components. The other half is that the data that makes PadJoin relevant is used continuously throughout the game, initially noticed all the way back to “Press Start” at the beginning of the game and ending at the point where the game asks “Are You Sure You Want To Exit The Game?” So at any rate, somehow the game needs to read the data from which will remain DrawableGameComponent PadJoin, because of internal test and visual debug processes, and from there the game can figure out how to obtain and utilize data that is relevant. It looks like I’ll need to configure more provider and consumer classes.

The Vlog.

Before this one finishes up, there is yet another UTube addition, “the gamb and his forest friends (Canoe & Rack)”. I’m trying to figure out just how this production was of any help with Object Oriented Programming. I could try to say something but in some cases silence is golden.

Enough for now, G’day.