Building an XNA Game Studio XBox360 Indie Game.

[page 0053] ~ The Unity Game Engine:

Updates – Windows shutdown update.

The theme this month is still LOOPS.

I started reading “Unity 4.x Game Development by Example Beginner’s Guide” from Safari Books Online as another way of getting some idea of what to expect while jumping into this new type of game creation environment.  So far, but back in the day, game programming was all line numbers with code pages and auto-Make files, then it turned into classes, sprite sheets, .obj, .fbx and .x files, height-maps with some fairly fancy precompiler things that wouldn’t bark at all even if there were errors, but which, when done running through that pipeline found their way into the main compilers prolific debuggers that would bark at everything if it would work at all, if it got to that point.  Now I’m looking at this Unity Game Engine trying to figure out how it will become of any use.  Although, I really think it may become of some great use because, of the features I have seen so far.  They have made sense and are things that I was looking into building or was more like looking into figuring out how to start building to use for what I was looking to do, which is build video games, and not reinventing another wheel that helps build video games.  I guess this is going to turn into more of that “Its got to work or all of this wouldn’t seem like it should”, kind of deal.  And that is what I have run into already.  In the Unity web documentation and tutorials the C# language protocol is emphasized while in this Safari Unity book the JavaScript language protocol is initially emphasized.  But, as I read along, I find a C# appendix at the end of each chapter that gives a translation so as to not just “dust” the reader and leave them to hunt and peck their way through the differently coded language contents of the books games, good for them, good for me.

Well then, after uploading my .unity3D file and its accompanying .html file, that provides access to my game, and then going to where I thought I would see my first try at something like a game in my browser , I found instead from the built in the given Unity Web Player page, “Failed to download data file”, how special.  So, like most things in life, it was not the end of the world but more Search and Research.  The first thing to do was to paste, “Failed to download data file” into the Unity – Search eyeglass on their website and voila it seems to be a common problem for those who don’t work with the IIS of their website directory that much.  It seems that each server provider has their own specific way of dealing with this problem, being that the file cannot be downloaded from the uploaders site because the file extension type is unknown and therefore inaccessible.  Simple enough, so here it is, Failed to download data file, and that’s the homework.  The other half is, is to read the documentation for the specific server platform from your provider and follow their directions to allow Multipurpose Internet Mail Extensions (MIME) access to the types of files that are to be recognized by putting them in a config-like file on the topmost directory of your websites folder structure.  Here are some other searches, one on Unity’s site Publishing the game, and one on Google, iis add mime type.  Of course it will take a little, “does this work, how about this, hmm, well, and so on and so forth …”, but in the end it does work from the given files of the build from the Unity API when placed in the owners directory to be accessed from the web, beautiful.  And as a bonus, I added a second file type, that for Processing, a .pde file type, then low and behold, that also works from their given .html file and the constructed .pde file on my web directory.  So I have figured out that mystery, thanks Unity, I no longer will need to have my entire running code base accessible from my web page, nice.  I think I might backlog my chess games and let them be accessed by the .pde files, oh well, all that happy logic and code was out there for a time.  Now back to Unity.

After reading another chapter or two of the “Unity 4.x Game Development …” book I went back to the Unity 4 website and started to review the Space-Shooter video tutorials.  With a flash of inspiration I thought, “Hey, I’ve already built HUD-On”, so maybe I could see if any of that previous work would fit into the Unity pipeline.  And per usual, it’s an ongoing battle to get things to work by trying to remember how they used to work, or at least how I would like to remember that they actually did work.  And now I have my big terrain in Unity.  Also from all that camera transforms and rendering stuff back from the XBox 360, I could find Unity’s “fog” in their Render Settings.  I gotta tell ya’ that those Unity sliders and input text boxes are a good thing, it beats building a bunch of code lines to capture the variables of object positions, converting all that to some lines of text and then figuring out where on the game screen it would fit so as to not be in the way and still be viewable in a discernable fashion.  I think I like this Unity Game Engine thing, and, I might be able to use it to build games for the XBox 360 for their Indie Games for XBox Live, maybe, but I might be jumpin’ the gun on that one.  So anyway, after getting my terrain in the Unity Game Engine and having the camera along with the fog with its near and far viewing frustum set up well enough I took it a step further and thought, “Sure, what the heck, that Space Shooter game has a free 3D space ship that isn’t doing a whole lot in their 2D game, so, maybe if I imported it into what I’m working on now …”.  Then, after clicking on the Download Assets in the Space Shooter introduction page and following their instructions I now have an all Pink/Fuchsia colored space ship, along with all the other assets from their space shooter game, thank you, again.  But fuchsia isn’t quite the color that I was thinking, for my space ship, at least, and there are some other textures that were downloaded along with that ship, hmm, more research and development.  Wow, now that’s cool.  I now have two ships that look like the ones in their given tutorial that work with, and in, my new 3D Unity game.  This could be HUD-On’s big resurgence, ok, now back to the tutorial videos.

There are going to be some problems in taking this Space Shooter 2D game into a HUD-On 3D game.  The first is when adding a Rigidbody component and not being in Space Shooter space.  This 3D game takes place on the fringes of the atmosphere where there is gravity, and by selecting Use Gravity on the Player ship Rigidbody component, when the game is started, the ship plummets towards the terrain.  And so the gears start turning, “How long before the collision when the ship hits the ground?”, that would be some kind of altimeter gauge for the HUD.  Next, having added a collision detection component to the Player ship model they also request that the Prefab engines are to be added to the ship.  One problem though, this is a 3D game and the thruster light from the burning fuel is positioned to only shoot out of the back of the ships engines when facing one direction as in what is seen in the 2D game.  This could probably be fixed by some kind of script that aligns the engine thrust to the rotation of the ship, somehow, but also another question, where in the HUD is the fuel gauge and where does the ship get refueled for all that thrust. On to the next video.

Alright, this video has to do with the lighting and so it has to do with the API and the models that make up the game.  And, as things tend to make sense through repetition, or at least are realized to be in correlation because of their continuity being in close mental proximity I have found that this Unity game and GeoControl2 both have a similar system of saving parts of the API as a separate file and then that of the game project as another file.  I would guess being able to keep those settings separate helps keep the continuity between differing instances from different game build types while keeping the same feel from the same API settings would prove to be useful.  I’m good with that, makes sense to me.  I’ll just have to remind myself of that when I start digging into ZBrush 4R6, that interface is somewhat, no, more like most intriguing, but that will be later on.

I’ve gotten to the Move Player video and they don’t use the “Y” axis in the video or give it in the “Done” C# script in the downloaded assets either.  It looks like I’ll need to hook all that up myself if I would like to see this ship fly around in my game.  Whoa that is simple, double click on the script to open it up in MonoDev and in less than three seconds, one copy, one paste and two change “x” to “y” for the Min Max values in the script declaration, save and enter Unity and there are the new values with labels and input boxes, way cool, gotta love it, this is goin’ to be good.  But that doesn’t change the fact that adding that PlayerController script makes my ship disappear, now why would that be?  That’s good enough for now, the Player ship moves, but the camera doesn’t chase after the ship or follow it around.

And now it does, but flying a space ship around using a keyboard does not bring any fluidity to the actions that help the player realize, from viewing the game, how to grapple with flying in 3D space.  Joysticks are the best way as they use values from [-1.0, 1.0] decimally to provide an accurate transition through an increasing and decreasing magnitude of input variables.  If I want to move left, just a little, I press left on the joystick just a little and ease back just a little while getting into the line of sight that I would like next.  A keyboard is kind of clunky when it comes down to things like that, but it could be done by using a timer to count off how long the key is pressed.  Using that mode of input would allow the player to always slowly add to the desired turn and while the button is held down longer the rate would increase more quickly.  But what if you would want to make a slow sweeping turn with a constant low rate of input.  On a button configuration, either another button set would need to be used via an alt or ctrl key mix or a new set of assignments to the keyboard map would need to be laid out and constructed.  I can see why there are so many 2D games out there and why so many faux 3D games, games that use 3D assets on a 2D surface (no Y axis) are so prevalent.  But I like my XBox 360 joystick controller and it works with both my PC via wireless receiver and XBox console through its built in wireless receiver.  One thing that this Unity Game Engine does provide is a robust set of C# script programing that can be easily incorporated into a game building methodology.

Or, to move the ship, I could just try something like building a Reticle and by using the mouse to move that reticle around the game screen the ship would then follow the reticle, it might work.  But first I need to figure out how to get this script for the ship to work because I used that same script for the camera to navigate in tandem with the ship as it flies.  The only, well more than only, thing that happens is that, because that script is used to also fire the weapon for the ship that too is incorporated when given to the navigation of the chase view camera within the same script.  So, of course there needed to be some tinkering around with that because the camera threw an error where those laser bolts had no launcher incorporated with that camera.  A camera doesn’t shoot laser bolts.  Now its time to have two separate scripts, but what might be more likely is to have supra script and sub script builds so the overlap of code that is needed and referenced because the ship needs Bounds checking and so does the camera.  But if both scripts try to build a Serializable class of the same name and type there is a conflict where one could possibly overwrite the other, thus the thrown error.  It can’t build the inspector panel because of the error, bark goes the compiler, par for the course.

Slightly familiar my mind says to my brain, in 15.Counting points and displaying the score of the Space Shooter tutorial video.  It was some time ago that I was trying to do the vary thing that they are talking about.  Theirs had to do with a method that was called to do an internal search for an object <type> to get the running in-game instance of a class that would access its runtime variable, change its value and update that what was seemingly disconnected to be seen as a change on the game screen, all quite magically.  But before this little jolt, at the time, way back when, it was a very mysterious and strange way of taking care of business, which may also have seemed to be too much work, as a one man operation, and that may be why I would always opt for the global variable route where everything is accessible from anywhere simply and easily.  Old methods die a slow death from the school of hard knocks.  BASIC, line numbers, 64k of memory and of course global variables, are my version of the good ol’ days.  But this video did spark a vague remembrance of intrigue which is better off left in a haze of twilight just so I can use what this tutorial chapter has made more clear for what needs to be done here within Unity.  Back then is just some dark and spooky stuff, like an old forgotten dungeon that I remember I had walked through from time to time and then when something new that is actually quite old passes by like a specter becomes the thing that is pointing the way out, strange brain, but its mine.  Two more videos to go.

And that’s it, two times through this Space Shooter tutorial with the second time through having an incorporation of one of my old XBox 360 games.  Now for some more reading and then to do this all over again with this month theme LOOPS in mind.  ‘Till then.


February 23, 2014 Posted by | 2014 [0050] to [00??], The Process | , , | Leave a comment

[page 0052] ~ Back to the Beginning:

Updates – .

DownLoads – Unity Web Player for Windows v4.3.4.0,  and free Unity 4.3.4, just for the fun of it.

The theme this month is LOOPS.

After updating my website by adding another calendar year, 2014, section of pages, and after installing Unity as my next API (application programming interface) for video game construction, I have begun to go through the Unity help files, tutorials and starter programs on their website.  As I watch the videos explain how things need to come together in order to build the given starter games, I realize, from all of my previous Xbox 360 programming that I have done, I can see all of the classes and variables behind the UI (user interface) drop-downs, check and text boxes in my minds eye, bully for me.  So far this is making some good sense and I hope that the scripting language for this game engine, one of which uses C# (see-sharp), can expand the out-of-the-box freedom of experimentation that I have become accustomed to with my previous Xbox programming.  One bonus is that the Xbox uses .NET4.0 and a dedicated subset of gaming declarations known as XNA.  Some circles of people seem to enjoy the fact that Microsoft hasn’t changed the protocols for the Xbox in some time, and thereby have come to the conclusion that XNA is dead.  But in all actuality I really don’t see why they should feel a need to.  The big push, lately, has been for the touch screen market of non-keyboard pad readers and smart phones.  That really has nothing to do with base units or consoles so why put any self gloating in the direction of something that has actually become stable within the world of computing?  What ever.  In any case Unity uses C# to run its scripts and the Xbox uses C# exclusively seeing that it has no UI, Xbox game creation has no skin, it is all code pages of classes and a compiler that is very good at barking at your every mistake.  It seems that I will be championing XNA, C#, the XBOX and now Unity as this year progresses, so be it.

Another thing that Unity has consolidated and has made more easy to use is shaders and the implementation of them.  Previously, in Xbox programming, shaders needed to be given within the draw method, possibly via a preprocessor, while using the projection, view and world matrix transforms of the object that had the lighting focus.  In Unity, that has been simplified into the check boxes and drop-down text boxes that set the type and amount the selected object will use.  Thus far, in the SpaceShooter game, it seems that all of the assets have a static position in concern to the light source position, maybe later on dynamic positioning will come into play through the use of their scripting language.  But so far the use of shaders and their incorporation into the games lighting system looks to have been simplified.

Ok, now the Unity tutorial, SpaceShooter, is talking about classes in the C# scripting language.  And for me, that is a good thing because back when I was using Processing to build my first web games, although everything was written in code in one page, there wasn’t any easy way, for me, to build classes that would consolidate sets of variables into discrete and reusable blocks of code.  This looks promising, but when using classes serialization is the vehicle that affords to Unity the ability to have its variables and their values viewable in the Inspector panel, and that is a subject more attune to higher or possibly lower level programming, when looked upon from differing points of view, and not one to be reckoned with in this beginning tutorial.  But as it turns out the utilization for serialization is given in respect to the API although not the specifics of what serialization actually is, which is understandable.

The tutorial is beginning to talk about how to add the laser bolts that are shot from the ships cannons.  It uses textures and materials that remind me of what I had been using in SoftImage when building 3D assets to use in my Xbox games.  After going back into Softimage, the texture coordinates and projections that are needed for the materials with their fx files that transpose a picture onto a mesh of vertices formed from an object that produces a representation of anything from a biped to a ship to a laser bolt, yikes, in a flood it all rushes back into my head, OK, whatever.  I hope Unity makes all of that easier to do.

More Unity study.  Having worked a little with XMLSpy by Altova which I have used to build some search and storage systems using hierarchical and SQL database structures and have noticed that while they are building and placing the different parts together in Unity’s SpaceShooter tutorial training, the techniques are similar.  The gist of the tutorial is how to figure out what they intended that makes the consolidation of resources work together and thus become a Game Engine.  I haven’t gotten to the point where I have added any resources myself so I don’t know what that entails, so back to the show.

That’s pretty cool.  While watching these Unity YouTube tutorials, I just had a flashback to when I was writing code back at school on the Universities Unix/Linux computers for my C++ classes.  That was a lot of coding back in the day, day after day, where when at home I was using Microsoft C++ to figure out the given assignments while building classes and UDT’s and then afterward connecting to school using Telnet and sending in those finished assignments, done.  The C# scripts shown and used in Unity are comparable to those classes and UDT’s where now, in the end, the whole finished game gets sent to the Web, as something for fun, not a graded assignment, of course.  So that flashback seems kind of “loopy” to me, and maybe even a little recursive.

I’m starting to get the script thing.  It looks like the public variables in the class becomes a label with an accompanying input value textbox that is then added to the IDE of the Unity Engine interface.  That is a really nice thing to have.  It is concise and makes the connection between the art assets and their  mechanics that drive their actions and motions within the game more charted, without an actual flowchart, per se, although I do like flowcharts.

The next thing that I have noticed is that when something is highlighted in the “Hierarchy” tab, the properties fill out the “Inspector” form with the values for that highlighted selection.  That is a nice tidy way of keeping all of the relevant classes together where all of that items capacities are seen without needing to scroll up and down a code pages lines or trying to remember which other tabs contain the code needed for a particular event to occur.  I’m good with that.

Building scripts that are modular and reusable seems to be the trick in keeping the Unity IDE workflow moving along smoothly.  This might be where keeping track of what needs to be done with the objects used in this game and ideas for future games could become problematic but necessary.  Hmm, things that do the same thing but differently elsewhere with open ended tweaking through the inspector interface.  Prefabs seem to be classes of classes that become reusable objects that can be called as a single unit that performs as the original.  But I still don’t get some of the drag and drop stuff that provides access to an objects properties by reference.  It’s my first time through this show, OK, back for more.

Simple is over, they just said something about “co-routines”, not quite ominous nor disconcerting, but it still makes me think, unfamiliar.  It must be a Unity thing.  Ha hah!  Finally, IEnumerator, which makes me think of the name of my Xbox360 Indie Developer name, MyI, pronounced “my-eye” which in its inception was a play on all of the “My” stuff back in the day.  And so the “I” in IEnumerator is the Interface which became my Xbox Gamer tag name MyInterface and of course that came from MyI which is short for my interface.  Yikes, I am such a geek.  So anyway,  IEnumerator in spawning waves is something that will go into the research bin for now.

Another interesting concept in concern to the scripts in Unity is that they seem to be being used like the scripts when building a website.  To get a website to work well, or at least to have it present itself uniformly it needs to have code pages that perform duties that maintain a consistent structure while each page is loaded into the browser.  The CSS script page, known as the Cascading Style Sheet, is what makes the webpage look as it does, that is if the web page accesses a css script page from its header section.  Each portion of a webpage uses little snippets of code so text and images are placed in the positions that the web designer intended.  With Unity the same seems to hold true where little snippets of code are accessible by many game objects to have them perform consistently within the game environment, just a note to self or an FYI thing about this Unity game engine.

With this next tutorial video it sounds like my games will finally get something for the players to listen to, if I can figure out how to use Unity and get something done as this months show case for One Game A Month.

More fun stuff, in the Unity tutorial when getting the game to keep score of the asteroids blown up by the ship.  I can vaguely remember what I needed to do for my Xbox programming when adding game objects and components.  There was some universal game reservoir that held objects that were built as either drawable or just game components.  You would have them built in code as a class then when the game would start they would be instantiated as a class instance and have the variables assigned.  After that, the program would call .add(classInstance) so it would sit inside the draw call loop, and I think there may have been an option to assign a numeric value to that instance so it has the possibility to be called before some other instance in that component storage heap.  Yeah, its been a while since I’ve done any Xbox360 programming but there are still a couple of light bulbs that go on occasionally.

Well, that is one time through the Unity Space Shooter Tutorial, I’m sure it won’t be the last.  After that I found a couple more inspirational videos on the Unity What’s New page.  Hmm, looking around Unity is a little bit like looking around Softimage, but I’m not building 3D art assets I’m looking to put a game together into a package.  Yeah, I’m lost and feel like a noob again, back to the beginning.


February 12, 2014 Posted by | 2014 [0050] to [00??], The Process | Leave a comment

[page 0051] ~ Home Sweet Xbox:

Updates – Windows, Adobe Reader X 10.1.9. Version, Adobe Flash Player, Adobe AIR from: to and then to

The theme this month is RESPAWN.

And what kind of small game can I build as my January Web Game 2014 and how can I use last months game “Flakey Kitten” as the base template for this month.  I thought I might be going to the Global Game Jam 2014 and then get a game finished there, but, my car battery died.  I wasn’t going to leave my car outside in -10 to -15 degree weather and then hope that it would start after I had just charged it back up.  So getting stranded at the GGJ 2014 was a no-go.  But what goes along with being able to respawn.  What needs to happen to have a need to respawn.  Why would I think it would be to my benefit to get someone or something in a video game to respawn.  Many things respawn in a video game.  And if you want to get technical about it, everything in a video game respawns, all the time.  Each time the screen is redrawn that part of the game has been respawned.  But like it was said a while back in this One Game A Month adventure, Keep It Simple Stupid, and use the KISS methodology to demystify the uncertainty of the quest being taken.  And that is what I will be doing for this game.

The name of this new game is “Bone Hunter”.  Once again the Hero of this story had died and has left the party behind.  Maybe others will be following shortly?  But this Hero, having been laid low, is now a ghost and has been taken one step further from the party.  As a ghost the Hero still has a chance to get back to the fight and rejoin the party.  The Hero’s ghost must gather the bones of its past corporeal being to be able to return and carry on.  There is one small problem.  The Netherworld is forever calling all ghosts to enter the light and lose all chances of returning in its abandon of forgetfulness.  The feat here is to collect the bones of your former self and avoid the spots of light that seek to consume you.  If time runs out or you cannot avoid the light it will be your final quest.

This little game is kind of sappy, but it’s just something to shake things up and add some diversion while still keeping on a coding track but to also be less serious than I might need to be while working through something for my Xbox 360.  For starters, it builds on my last game and uses the same ideas to move the main character around the screen, that is, just hold down the left mouse button and the main character will move toward that point.  The last game had a cat that needed to evade the snowflakes to keep from being frozen.  In this game, a ghost needs to collide with its bones as they move about the game screen.  The last game was avoid collision while this games objective is to move into a collision.  The last game used a bunch of lines, rectangles and ellipsis to draw pictures on the screen while this months game uses more computer built pixel drawings to generate the ghost and its former lifes’ skeleton.

The coding in this game is by far the most messy unruly bunch of unarticulated gibberish that I have yet thrown together and still have it do what it was intended to do.  Find and Replace was used to change the names of the variables from Kitten to Ghost and there were some other very unorthodox less than kosher practices that even by my standards makes me chuckle and hmmm at the same time.  It has nearly no comments nor remarks to give much if any guidance as to what does what or why something happens because it is where it is or needs something to do something somewhere sometime.  But I did keep the collision bar at the top of the screen.  Above that bar is a timer and now, in this game, below the bar is a label for what Level the player is on.  This game also relies heavily on RND, randomize, random() whatever in what ever language it might be known in or as.  The idea is for the ghost to capture the bones by colliding with them as they fly by.  This means that for a greater part of the game things will be moving toward the edges of the screen and them off the edges of the screen.  So to be mindful of this but not being quite too attentive to this predicament, when in doubt, give it a new random location.  Keep the action going and hope for the best.  There really is no assured way of winning this game, it’s more of a fly by the seat of your pants kind of deal.

So anyway, the way it goes is, with the levels, capture the skull, chest, pelvis, arms then legs, in that order.  Also for each level, the skeletal piece when it has been hovered over, (I don’t know if the ghost is chanting over it, casting some charm, or trying to eat it), will add time to the collision bar.  When the bar reaches its capacity the skeleton piece pops off the board and into place in the upper right hand corner.  Getting all of the pieces into the coffin is what is needed to RESPAWN and bring the Hero back to life.  But there are three endings to this game two losing and one winning scenarios.  As mentioned, collecting all of the skeleton pieces is the winning scenario.  Then there are the other two, losing scenarios.  While playing there is a timer at the top of the screen that counts down from sixty seconds in one second increments.  Each skeleton piece needs to have a spell cast on it long enough to fill out the bar at the top of the screen.  But as that bar is being filled the beckoning light also grows making it more difficult to hunt down the skeleton piece and complete the chant.  Being in the light fills the same bar with red and if it is completely filled, the Ghost has spent too much time in the light and is drawn into the NetherLand, and the game ends.  The other scenario is that there are seven levels to this game because there are seven sections of the skeleton that need to be collected.  With each level the skeleton piece can move faster, the Ghost can move faster and the light will grow faster.  The time remains the same, sixty seconds per piece, and is reset at the beginning of each level.  If time runs out before collecting the given piece for that level, the game once again ends.

Now all I need to do is get this little game onto my website and see if it runs from there.  Then hop on over to One Game A Month and check it in, get this bit of scrawling into WordPress then call it a day.  Then I can get back to thinking about where I’ve been and where I would like to be doing what with this upcoming year.  PS: The arms and legs of the skeleton have its central collision point at the top rotator balls, not at the elbow or knee which is central to the arm or leg as a whole, oops.  But to continue.

Last year at this time I had no idea of what I would be doing in 2013.  As it turned out I took a complete hiatus for the year from my Xbox project solution building process and turned my attention to building web games for my website because of One Game A Month.  This was very fortuitous because just after reading that sites creators book, “The Game Jam Survival Guide“, that creator built that #1GAM site and the invited was sent out, but everyone seemed to join him in building one game a month.  And so I got in and started building web games.  At first my jump out of the gate was more than a little rough.  I began with a Global Game Jam and posted that for my first entry on my Far_Niche channel on OGAM.  As I built my games for each month I would keep the code build from the previous month, take the theme for the current month and try to bend the logic to fit the narrative of that months theme.  It worked pretty well as the year progressed and now I have a bunch of completed web games on my site that anyone can play for free.

Now for this year, 2014, I am to run off and begin excavating that old Xbox site and begin to mine what is mine, the treasures of Xbox Live Indie Games.  I’ll try to keep up with the short game entries for One Game A Month, but my main push will be to go through my old Xbox project stubs, trials and tests so I can consolidate what I have built so far and archive the rest.  There is a bunch of junk that has taken up residence on my hard drives and that space would be better served as empty space rather than clutter.  So this year will be a reclamation and consolidation time for all of the stuff that I had previously build to get me to this point.  Art assets, 3D model assets, half baked project code, semi-inspiring logic paths, incremental builds that are no longer pertinent, copies of copies just in case something got overwritten, a whole slew of nuts and bolts from all over the place, everything that isn’t done and will more than likely never be finished will go into storage, not deleted yet, but just eternal storage, the black hole.

But unlike a black hole, I can choose just what I would like to go past that event horizon and become lost from the realm of information existence.  And so I start with my pinnacle of game creation, HUDOn, (Heads-Up-Display On).  This game uses many parts from the Xbox 360 Education Catalog.  With these many parts from this content catalog I have put together a myriad of game stubs, each becoming a further progression that stabilizes a greater test environment for forthcoming additions.  The best thus far are a 3D game HUDOn and a 2D game SpaceWar II both built to run on the Xbox 360.

Play Bone Hunter Here.


February 1, 2014 Posted by | 2014 [0050] to [00??], The Process | Leave a comment