Building an XNA Game Studio XBox360 Indie Game.

[page 0055] ~ Neon Designs:

Updates – QuickTime 7.7.5 and Windows ShutDown Updates.

The theme this month, is NEON.

And Unity4 has grown to become Unity5.  But the task at hand is that I get an MVP from my SOB where the book this month is, Unity 4.x Game AI Programming , to wit, obtain my Minimum Viable Product from Safari Online Books to produce a neon kind of game in Unity.

So I read on from my various sources and continue to view tutorial videos.  This brings me to the conclusion that what I need for this months game is to start out with a Particle System.  This is a component that is created through the dropdown of the Hierarchy tab within the Unity Game Engine.  This particle system produces what initially looks like a cascading fountain of fuzzy light gray sprite fluff balls.  This component also reminds me of the XBLIG samples, Particles and Particles 3D and the banter in XBox LIVE, for example, in the Community Forums.  With Unity, one thing I have noticed is that the “free” version has been given to use as a base model, in comparison to the Pro Unity version which is full featured.  But this free version gives me an opportunity to get an understanding of what this Game Engine is all about and what it can do.  Then, because of my previous experience with the Xbox LIVE Indie Games Developer site I have a better understanding of the code that builds up particle systems and further, what makes this Unity Game Engine a game engine.  Now with Unity taking care of the technical aspects of the implementation and usage of, for now, the particle system, I can work on differing aspects which will include building the Materials.  This then will also take me into the wonderful world of Shaders, free up some time to dig deeper into ZBrush and continue on with the many other parts of game building.

Well it looks like, I would guess with this version of Unity, I’m still in the kiddy pool.  With that I will start this game from scratch and see how far I can get, without any training wheels.  As I continue to study how to use all of the programs that are needed to create my game assets, be it 2D art, 3D models, code scripts, story lines, or countless other understandings, tasks and processes, I need to consider how I will be consolidating all of these within the Unity Game Engine as my game, with neon things in it.  And after that brief jaunt I find that that didn’t last long, because for now, starting from scratch will need to become another self modified project from using the base game of Unity Tutorials called Project: Roll-a-Ball.  And the name of my new game will be “Neonlithic”, where neon is an element and lithic is of stone.  This may sound strange for the name of a game but my direction within One Game A Month and my direction for game building because of One Game A Month has also taken a strange turn.  I have realized that there are many parts and varied processes that are involved in the creation of video games.  So my direction needs something lucid but also something solid to build from and upon.  Instead of focusing on a whole game per se, I will go into the different aspects of game parts and make those concepts into mini games that revolve around something that can be used within many games.  In short, what I will be doing with the Theme of the Month for One Game A Month, is to come up with reusable game parts, like a wizards wand blast in this months case.  The game will have nothing to do with a wizard nor the wand, but will focus on the blast, which will be in neon colors.  This will be the game part that comes under scrutiny for this month.  It will then be placed into a game format so a unit test can be performed while it also retains some gamish quality or enough so as to pass for a game of the month.  This way I will get another validated game part into my tool box, I get a finished game to submit for One Game A Month and I’ll get a little more back-story and future reference for the game and the part just built.  But beyond this I’ll become more confident in my own understanding of the different programs that are used to construct the varied assets needed to make a game an interesting and hopefully fun game to play within my own production pipeline.

To this end I will be reviewing the Roll-a-Ball tutorial in full, again.  And then why waste time, as I have already gone through viewing this whole tutorial project video sequence once, just recently, before.  It is time to learn and build, both together, just like math class lectures and home work assignments, learn and fail, just be consistent, test and adjust, remember and pass, it all works out for the best.  One thing I am noticing about using this game engine is that the object names assigned within Unity and MonoDevelop no longer need to be as long winded as I had become accustomed to making them.  I will never see these objects names outside of the game engines’ scripting API and the game engine itself.  So the variable names for the objects and the structures that make up the features of these objects, for all practical purposes, are encapsulated within Unity and Mono.  There is no longer any real need to make variable names any more type specific than that of just knowing what they are or possibly named for what they do in the game.  No longer will they need to incorporate prefixes for the implementation in the code because of, the slightly higher than low-level purpose that the naming conventions would normally provide, like in the c or c++ naming conventions.  Rather amazing, indeed.  But this does not preclude the use of syntax or pragma, so be it, such is life.

While chopping right into the scripting aspect of Unity, I seem to already have a general understanding of how scripts are used to augment the objects behaviors.  The objects in the game are altered by calling properties and methods of the object that then become affected and change the modifiers that create aesthetic appeal, promote a challenge for the player or somehow evolve game play that could not normally be accomplished with static processes.  While previously building games completely through code using XBLIG and Microsoft Visual C# 2010, I began to try to understand how I could add scripting to the games I had already written in C#.  What I really didn’t quite grasp at the time, was that, for all intents and purposes, that was pretty much all of what I was doing already.  My games, although precompiled into an .exe, were one huge mega script that became a homogeneous, part and parcel, game and game engine integral combination.  I would guess that is why, for me, the Unity Game Engine is so intriguing.  Back when writing pure C# games, but of course while also incorporating .obj’s and .bmp’s and the like, I began to run into stumbling blocks that took the form of something that could have been remedied, from what I thought would be some kind of flowchart.  I was trying to come up with some type of schematic that would help me consolidate the “whole lot of everything”.  All of that had need, for me, to come together and become more apparent in structure in that: it would have the capacity to retain orderliness while building, would be seen as rather amorphic until put to use and once again intriguing in facility because of its vast and varied scope of conjointed implementations.  I think I like this Unity Game Engine, even though I am still learning what it does and how it works.

But this current game is going to be a template for better things to come.  What I’m working on now is getting the Roll-a-Ball ball to move around on a flat surface, but then to also have a third person camera follow that “Avatar” around.  The problem currently is trying to figure out how to have the camera follow behind the Avatar.  I have gotten the camera to pivot 360 degrees horizontally from the offset point, which looks down at the Avatar at an angle.  It is from the tutorial, but it is always attached to the Avatar from the south so the Avatar is completely out of view when looking south.  And as there are four walls that are barriers that help to keep the Avatar on the board, but the Avatar is always hidden when the camera is facing south and blah de-blah de-blah.  Hmm.  And, there is something else that is going wrong here, that is, if while moving the Avatar about the playing field and the camera is spun to look backwards the controls that were N,S,E&W are also backwards and do not work as intended.  The camera turns but the controls do not follow the Avatar and subsequently the camera, well they do but left is right and so on and so forth, it gets backwards, dumb stuff and stupidity, whatever.

Almost done, maybe not, so,

To Be Continued …



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

[page 0054] ~ One More Time to the Well:

Updates – NotePad++ DSpellCheck 1.2.12.

And still, the theme this month, which is actually for last month, is LOOPS.

A late submission courtesy of …, how the (!) does it work?  And so, back to the Unity Tutorials/Projects.  Their Space Shooter game is the base template that I was attempting to get the ideas and assets from.  From there I was then to add my take of HUD-On and turn that all into a mash-up in a Unity WebPlayer game for February with loops.  And of course this was not the case.  Flying in 3D space takes a little more work to figure out than flying in 2D space, that is, that Z-axis adds a whole new level of unaccounted for complexity.  So once again it is time to break out the ol’ mind-machete and enjoy my third screening of the Unity video series: the Space Shooter Project.

Math and molasses comes to mind where both move along with just about the same consistency.  So, instead of trying to figure out what might have worked and what was just a half baked guess, I have a new game called FastFlight.  This new game project has a fresh asset download, of Space Shooter, from the Unity AssetStore, as well, because there was a lot of ham-fisted knumbskullery going on, that I added and deleted, bent, folded, spindled and mutilated to say the least, inside of the script files with that first download game.  In the viewing, I have been whisked along to Chapter 4) Camera and lighting.  This is where the fun began before.  The type of projection that the camera uses in the tutorial is an orthographic top down view while my game is going to use the perspective view with a skybox background.

Hmm, icky sticky stuff, I have it kinda done in the other project but, I can only have one instance of this Unity API open at a time and therefore only one project open at a time.  Yeah, it’s all flip flop, grab a setting, open the other project, view an argument, back to the first project, check how things were there with how I would like them to be here, back and forth, sure, ok, got it.  Their little Unity Project Wizard should be of some help with all this, and it is, the load new project and reload times, for this small game, are fast enough.  But this is where the guess work begins and the faltering with the head scratching starts all over, again.  They are talking about a blank background but I need a skybox.  And instead of a flat picture used as the floor of the game, I need to import the 3D terrain from HUD-On.  OK, first the terrain, then the skybox, we’ll see how that works out.  And for the life of me I can’t remember how I got that terrain imported for my last game, ha!  Alright, in the API’s main menu under GameObject/CreateOther/Terrain is where it is, and that is it, back in the game.  That’s right, I had to convert that height map into a .raw format in Photoshop before I could do anything with it, now it’s just a matter of copying that terrain asset folder out of the last projects directory and into this new games directory, done.  Well, at least it will let me readjust the Length, Height and Width settings for the map with the argument text boxes after I’ve imported it.  And it’s a lot better than having to run all over trying to figure out the searches looking for which class was used to build the terrain and then to find and change it all inside my head first to get it to work later in actuality as the game build, oh no, but yes.  But now, off to get a quick set of screenshots to get all of the settings from the old project to transfer, as best I can, over to the new project.  And finally Assets/Import New Asset … to get the color map for the height map.  So far so good.  Now I need that skybox thing to happen.  But first a little coffee and to press on with more of that video tutorial.

I guess the good side of redoing this game build is the remembering part.  Not only the how but the why and where are proving to be more illusive as time moves away from that last build.  But I have it back, and slightly better than before.  Now to think up what the game is, as that of which I can actually do something as I get the old HUD-On into Unity.  As it stands, my ship starts at one end of the terrain.  There is a constant velocity to keep the ship moving forward so the only controls are the up-down and left-right movements.  A camera follows the ship across the 3D map and that is about it.  My game, it’s done, it’s great, on to bigger and better things.  Well better at least.  But it has no loops, so it is not done, yet.  I still have some time, a matter of hours, before this month expires, and who put so few days in February anyways.

The next thing that I’ll need is a loop for this ship to fly through.  Seeing that the Space Shooter project only has one other ship, the enemy ship, and an assortment of asteroids, three kinds, I’ll take a look at what ZBrush has to offer.  Opening it up I find that they have a loop, a Torus shaped “tool” as they like to put it and with that I’ll begin to try to do some prep work on it with Polypaint inside of ZBrush.  And after that refresher video I have a Loop that looks like a life saver, kinda like a Lifebuoy with a white ring ad red loops at ninety degree angles, it is exported into a folder and is waiting to be placed inside this FastFlight game.  Sounds easy, but this is where their step-by-step tutorials end and my take of this games evolution begins, where things tend to get real messy with that ham-fisted plop it down and see how it works, or doesn’t work, knumbskullery, again.

The weirdest thing about ZBrush is the way that saves are made, or what each different type of save consists of because of the 2D, 2.5D and 3D painting and/or modeling configurations that can be accomplished in the application, much weirdness.  I hope that what I have built can be accessible in Unity somehow because I closed the ZBrush 4R6 program and now have a folder with .bmp, .mtl, .obj, .zbr and ztl files in it.  And what I would like to do with these is to trade off the asteroids for the life saver loops, but for now my computer thinks its time for a security scan so I’ll just go away for a while, back in a bit.

Well that’s it, as done as done.  It has potential, and much room for more potential but it is another game that will once again become my template for the next few months.

Just fly the ship through the loops and score big, (100 points).  Get a bead on the loop with your laser blaster, (1 point for each hit).

Controls :

A-W-S-D keys and Up-Down-Left-Right arrows move the ship in those directions.

The tracer rounds are shot with the left mouse button.

The forward thrust is constant from the start to the end of the game.


Play Fast Flight Here.


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