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 | , ,

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s