Building an XNA Game Studio XBox360 Indie Game.

[page 0059] ~ To Be or Not To Be:

Updates: – Adobe Reader Version X (10.1.9) to Adobe Reader Version XI (11.0.06) && QuickTime 7 on Windows 7.
DownLoads: – Maya LT 2015 free 15-day trial.

Yep, still Water.

Hmm, well, that’s actually pretty nice.  Customers with an active Autodesk Softimage Subscription contract can migrate to the latest release of either Maya or 3ds Max, at no additional cost.  But it’s getting close to the end of my Maya 2014, 30 day trial and I’m not as sad as I thought I would have originally been.  It was a lot of give and take, with the shuffling around of my own thoughts, of why SoftImage was what I was saving up for and now would need to change my focal judgments and scry as to what my next best options have in store.  So while weighing the cost against my needs, I got an e-Flier that said the AutoDesk 2015 product line was out.  In fact, what I have done, is to see if I can get the Maya LT 2015 free 15 day trial during my Maya 2014 30 day trial and be able to compare the two products, simultaneously.  And I can.  So right now, I have ZBrush 4R6 connected to this Maya 2014 free trial, and am going to test if Maya LT 2015 also hooks into ZBrush through GoZ.  If it does, then I think its a done deal for the purchase of Maya LT 2015.

But after looking around at some banterous internet critiques, and after my own trial and error work-arounds, the Maya LT product does not support the GoZ paradigm.  But, Maya LT, from its main menu File dropdown list command item does have a link that provides an asset insertion point right into the Unity Project/Assets/folder interface.  But there is a limitation of 65,000 vertices with the file transfer directly into Unity’s internal folder directory.  At this point in time, I don’t believe that that transfer file size will be much of any issue seeing that animatable characters should be in the range of 3000 to 8000 vertices each.  This smaller vertex count is also needed for the CPU and GPU to keep the FPS(frames per second) in a range that does not slow down the frame rate, changing the players game focus to finally de-immerse the player from the gaming experience.  Building other meshes as environment and set props will, I would guess be of a comparable size limitation also.  And as for collision meshes, those are constructed to have much fewer vertices than the textured meshes they surround as seen in the game.  But in any of those cases, building many small pieces would be to the advantage of the designer, as unit testing of small pieces could be done incrementally.  The stress loads could be varied more easily while using many pieces instead of having the only option as one big mesh that could not be switched out.  And it isn’t like what is built in ZBrush can not be opened in Maya LT, or visa versa, with some limitations.  Both programs have the capacity to import and export .obj files.  It just comes down to the extra time used to access those files from the systems folder directory, a small inconvenience, not a dead stop from a fabricated dead end in the work flow of asset creation.

So, somehow I need to think that this seamless transfer process built into Maya LT that links the game assets directly into the Unity Game Engine will lessen the time spent digging through Windows Explorer, as all that is needed now is to click and watch the transferred files appear from one app to the other.  This might be a small, but positive, factor in my calculations for a ROI as I duke it out between the pros and cons of what my next best option for a 3D model mesh asset creation program will be.  It was really nice to see that transfer happening between Maya and ZBrush, where GoZ affords to the designers the best of both worlds in tweaking iterations back and forth of the same model mesh.  But seeing that I am a low-poly-count Indie Game Creator and not a high-poly-count Movie, Commercial or Cartoon Producer, I must relegate Maya to the back burner, for now, and Maya LT to the front burner to get cooking with some low-res 3D mesh interactive game characters, set props, environments, animations and storylines.

I’m not writing a story book that when read will follow the same story plot, in the same time frame, with the same characters, saying the same thing, in the same place, to further the same ends, in the same order, every time, that the same book, or in this case, same movie, same cartoon or same commercial is viewed, with “high” poly count meshes.  But, I will be designing and creating video games that are seen, by playing through the games with different characters, having different points of view, doing different tasks, at different times, to accomplish different strategies, obtained by different objectives, through adhering to different directives, using different means, that achieve different goals and produce different rewards, with “low” poly count meshes.

So my two major concerns, which I have addressed, will be, am I going to build for Film Rendering or will I build for a Game Engine.  I think I have just about made up my mind with how, I think, this should turn out best for me, with Maya LT, 2015.  Well then … back to the next reality, and, as Inspector Clouseau would say, “Until then, a case is sol-ved”.

Or maybe not.  I’m going through another Digital Tutors training module, Retopology Techniques in Maya, and am using both Maya and Maya LT to see any differences between the two, (see: Maya vs. Maya LT), that may make some final difference to me.  The tutorial theme is the speed of mesh transforms, which here, is made out to be the central issue because that is what this Digital Tutors video is intending to express.  It shows why and how to escribe methods that lower the poly count for a model mesh that is to be sent to a game engine.  Initially, when the entire model is selected, it is approximately one and one third million polygon faces with over twenty million edges and in the end it becomes a character mesh with about 2700 faces and 5500 edges.  The UV’s are flattened and the high resolution texture is baked over to the low resolution where both models are compared side by side.  After this tutorial my thoughts remain the same, High poly vs. Low poly, Rendered Viewing vs. Animated Interactivity, Film vs. Game.  In other words my final decisions will be best served as I look to my next direction from what I will be creating.  So will I be moving towards: Static Sequential Video Story’s using Maya with its Rendering Engine and topping it off with something like Storyboard Pro 4 or will I be putting my efforts into Random Variable Input Games using Maya LT 2015 and topping it off with the Unity 5 Game Engine.

Next on the list is the Indie Game Development Pipeline.  This is a set of nine Digital Tutors volumes using Maya LT, Photoshop, ZBrush, Mudbox and Unity to build a Boss Battle.  The run time is about 28h and 23m in length, but with breaks in between it will assuredly run longer.  Then actually doing what is taught in each of the lessons inside each course will also add to that time.  So, so far they have gone through the lead up phases in getting the general idea of the game together as a side scroller using 2D and 3D elements to show how many layers it may take to formulate this Boss Battle.  They have gone through the Hero and Boss prototyping to agree on what they should look like as 2D characters in Photoshop.  Then they moved on to the 2D environment where the Boss Battle is to occur also in Photoshop.  As of now, I’m up to volume 3 where they are beginning to get the Hero and Boss proto-animation hooked onto the environment so they can have that interact using scripts to transfer their information using game Triggers and Event Handlers provided in Unity.  And per usual, I began to recall what I had to come to grips with in the Microsoft Game Studio using C# with XNA from MSDN(Microsoft Developer Network).  There they also used the concepts of Handling and Raising Events, here, just as a side note.  But I’ll need to research both to compare the similarities and differences at a later date.  And with that, back to the show.

After the concept of a working game mechanic prototype with place holders is finished, the next couple of volumes deal with the Hero and Boss 3D meshes as they are created in Mudbox and ZBrush.  Each character is fashioned in 3D space where afterwards the UV’s are flattened out and painted in a mixture of Photoshop, Mudbox, ZBrush and Maya LT.  After that, the Hero and the Boss characters get the “Rig” they both need as the skeleton that will be used to build and drive their animations with their meshes that are “skinned” to the skeleton rig.

But it is the end of the month and for all I have gotten done this month, apart from my game, I have also built a small game, using the One Game A Month theme, Water.  This “let’s see what I’ve learned how to do so far”, game is about a plumber that was quested to repair the plumbing in a small brick house on an island, somewhere.  In the morning, the plumber stands victorious on top of the brick house but then realizes that he can’t remember exactly where his watercraft is so that he can move on to the next island, his next quest.  This game is only concerned with him running around the current island in search of his water craft.  To aid him in his search, he has a GPS-like display that gives the player an (X, Y, Z) position that will move closer to (0, 0, 0) as he moves closer to his watercraft.  There is no time limit, there is no problem with breathing underwater or climbing any mountains and there really is no leaving the island.  There is only finding the watercraft, somewhere along the shoreline of the island.

Play WaterPod Here.


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