MyI@FarNiche

Building an XNA Game Studio XBox360 Indie Game.

[page 0012] ~ Consolidating a Base-Line Game Level:

June and July were a time to deprogrammefy myself, (see Vlog).

It’s August, and in three days the Curiosity, Mars Science Laboratory, is set to harmlessly land on the planet … , wait for it, … terror ensues 7 minutes, … Mars!

What?

I finally jumped into Facebook for FarNiche, and will leave Facebook to showcase my highlights as what’s new within FarNiche.

Now to get this gaming idea somewhere, I’ll need to get back to my reading, web site Research page, game creation, code testing and more things that I’ll think about as I get to it. First off, in my web, I’ll shift my previous game assets from its existing page on the HOME page off to a subheading under the HOME page such as Prototype. Done, the HOME page is empty again along with some link tweaks. I’ll need to start a Review page for the books that I read as a left column topic under the About page. Lastly it looks like SpaceWar II is the game that I’ll be working with to get back into the swing of things. Yes, that’s nice, it’s nice and messy and it works on both the computer and the console versions. Now, how to get my Babbage engine brain back to work.

It’s time for a walk through to refamiliarize all that was once headway.

The solution “BasicGameSize” has kept the best programming format. Its layout and tidiness should make the placement clear for the desired robustness which will add new features needed to exemplify my generic game shell. For my purposes, this starts with adding the GameStateManagement code class pages and declared initialization variables in there proper locations to connect the logic flow. Ah yes, event handlers, and delegates, and eventargs, and the PlayerIndex all placed and arranged, not. Integration of the GSM Sample will need some research. But already included in BasicGameSize is PadJoin with PadIO as PadJoins dependency. These two small classes affirm connection between the console and the game pads. While going through trying to remember how it fit together to do what it does, I’ve found something about the assignment of the pads within the console and computer receivers. It’s something somewhat unnoticeable but here goes.

A Bit of Recognition Testing.

The Xbox 360 is on. Having been started with the button on the console and not a game controller, then seeing that a controller is needed to interact with the screen interfaces, a game pad is turned on. The console assigns it to slot one for the first controller. Then as other controllers are turned on, they are sequentially assigned to the next open slot, up to four slots, therefore a maximum of four controllers per console. Opening the battery compartment of an active pad, effectively turning off that controlling pad, PadJoin alerts the running game that a pad has disconnected. So when the controller is turned back on, the consoles receiver correctly reassigns the pads previous slot position and previous PlayerIndex as it was initially assigned since the Xbox 360 had been turned on. If the Xbox 360 is turned off, the controller order is lost and as the pads are again turned on, the order of connection as the console recognizes them becoming active, rebuilds a new sequence in the console as a new list ordering PlayerIndex. This might seem blatantly insignificant, but while building this on the computer, then running the debug version which is seen on the computers monitor, the sequential order of the game controllers becomes inconsistent. To see this behavior it requires that the controllers are reset from the Xbox 360 receiver to the Xbox 360 Wireless Receiver for Windows. Now the USB receiver attached to the computer is recognizing the game pads. Doing this while PadJoin is running in BasicGameSize shows on the computer monitor the order of recognition from the now active pads. Here is where the inconsistency becomes obvious. Running the computer version, all the pads are on. The indication of the pad and the owning player index is in a specific slot which is seen as text on the screen. Pads two and four are turned off. Pad four is restarted first and now becomes pad two and fills up the PlayerIndex sequence in order of availability, leaving pad two when restarted to become pad four as indicated by PadJoin. This became a matter of concern while going through a sample game called NetRumble. Because this game can run on both the computer and console at the same time with a network connection in debug mode, the need for consistent pad recognition became apparent. Having an interface that will allow any player to jump back into the game after a disconnect, and then have the pad assigned to the correct PlayerIndex in the game on either the computer or console, must be the reasoning behind my PadJoin class. It seems that tweaking PadJoin will continue as each implementation reveals the slighted intricacies of each solution which utilizes PadJoin. This type of play testing is apparently the “modus de facto” while stabilizing a class for generic use.

Back to the Research Page.

MenuMechanism has come under construction and is the next entry into the research section in my site, so for now, this concludes the monthly synopsis. I think I’ve got my game brain back, now for some reading. G’day.

Advertisements

August 26, 2012 Posted by | 2012 [0006] to [0018], The Process | Leave a comment