Building an XNA Game Studio XBox360 Indie Game.

[page 0025] ~ Profound Sound all Around:

Moose Juice and Goose Juice – The Sleep Book by Dr. Seuss

Processing is small, but I like it. It will also become my way to gamify myself within One Game A Month.  But, this blog will concern its self with how naked I feel while building the February game in Processing, in comparison to using my usual GS-XNA IDE.  **DISCLAIMER** – these are observations I have come across as I build, and may have solutions that I am not aware of at the time of this writing.  So anyway.

How things get done.

The syntax is familiar between the two programming languages and that adds to my comfort.  The help files given by both are uncluttered and easy to understand. The debugger in either is well defined and in general gives good guidance as to where I should look to find where my exception may be found.

The first thing of difference that I had noticed is in where the logic and render code is placed while constructing my programs.  In Processing and GS-XNA the include/using statements along with the declaration statements are still positioned at the top of the project class.  I have yet to find the implementation use of function prototypes, or where or why they would be used or needed in either.  C++?  My bad?  But in GS-XNA the Update and Draw methods are separated, while in Processing the code logic and draw methods are combined.  In either case some pre-thoughts need to be addressed as to the order in which the precedence of each code line should be placed.  A dual line of thought given for the codes step into and through with GS-XNA divides how variables and function calls are executed by the CPU, while in a separate thought and process, the visuals are consolidated and fed through the graphics pipeline and from there are given to the GPU.  And so the Update feeds the CPU with code logic while the Draw feeds the GPU with graphics.  All of this happens while GS-XNA tries to keep a sixty frame per second call consistency, while the logic is free to update within those draw calls.  In Processing the cycle of code iteration is perpetually captured by the draw method/function alone, and therefore, are both seemingly CPU driven.  These two types of implementation are intrinsic because of the IDE’s construction. Given these characteristics, they both express the ideals for which each of the IDE’s were constructed and for what each type of usage they were intended to convey.  Processing is simple, light weight, portable, easy to install and lends itself well to general coding practices, thereby claiming the title as a coders Sketchbook.  GS-XNA is specialized to speed the processes through which the complex tasks of: implementing a window to draw in, accessing the DirectX and other assorted Direct(?), porting a game from the PC to an XBox, and then, with further programmer desire and a subscription, submission of completed games to eventually reside in the XBox Marketplace.  In short, each has their own flavor and charm.

Things that are missing, and sometimes not.

In both, when a function brace is selected the accompanying brace of the selected function is also highlighted.  But, (this is where my nakididity becomes apparent), when I select a variable name in Processing, all the like named variables are not also highlighted within the classes page as in GS-XNA.  Keeping track, in Processing, of where all these variables are placed within the code page, for me, becomes unwieldy.  But this will only make me a better programmer seeing that, although my programs may be smaller, I will be more concise with the naming of each variable used.  Also giving the variables and functions more clear documentation by means of remarks, should again provide a degree of recollection because of repetition in the thought of their meaning arising from the connections I make in the comment about the variable, good for me.  Another concern is my use of global variables and the building of functions that take arguments, something that I haven’t gotten around to yet in Processing, but has come to mind.  Come to think of it, I’m glad I went back to the University for some formal code creation training in C++, the pressure cooker, broasted not baked, although grilled is definitely preferable, and of course in all cases, seasoned to taste.

Another thing I have noticed is that, in Processing, the code page doesn’t have any regions that collapse long code blocks and shorten the scroll distance like in a GS-XNA class page.  For example, in GS-XNA, when a large switch/case, or code block that is no longer in need of change and therefore has no need for further recognition, would then, because of an XML code page format with collapsible nodes, has the capacity to be hidden from view.  Something likened to that of the Wizard of OZ behind the curtain in that merry ol’ land of OZ, where things work as they should, “so pay no attention to that man behind the curtain!”  Somehow, I would presume, in Processing I would be able to build classes in different tabs to hide them, but so far this would only be a fleeting thought never put into practice.

Another thing that I have become accustomed to, in GS-XNA, is selecting a variable and either going to its definition or having all its references displayed in the “Find Symbol Results” list.  I think Processing will show me a lot about how I am used to making my way around the IDE.

Another thing, is setting a bookmark so I can quickly scroll up to where my variables are at the top of the class and then quickly scroll back down to the visual que of the bookmark on the left edge of the code page.  A break point works just as well when the variable is on another page and I have forgotten exactly where I need to go back to, just run in debug and the program breaks where I need to be, that is, if it compiles.

OK, this is a little weird going back and forth in-between Processing and GS-XNA, but it is kinda fun, something new to do, to do, to do.  That’s right, I need to get some music into this game.

Hm, it seems that if a key is pressed, in Processing, only one key will register, therefore there isn’t any chance of having a shift+(some other key) pressed at the same time.  Needs some research.

Eeeek! – well almost.

New in Processing 2.0.  It had seemed that it has lost its web ready capability but with a little searching, it seems that Processing.js has continued on along side it.  And like that, this blog will continue on.  With some sound, really.



February 4, 2013 - Posted by | 2013 [0019] to [00??], The Process

No comments yet.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s