Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
9. January 2014

 

Right off the hop for my new game I have to deal with a problem that many games have to deal with but one that could have a huge impact on how my game is structured, so I am going to address it with a proof of concept right up front.   That thing, as the title probably spoils, is character customization.

 

As I said earlier, this is a pretty common problem in games and something you see questions about quite often if you hang around game development forums for any period of time.  So what do I mean with character customization?  Ever played Diablo or a similar title?  When you change your gear in Diablo, your character is updated on screen.  This behaviour is pretty much expected in this day and age… personally I really hate when I am playing an RPG and the weapon I equip has no affect on my avatar.  That said, it is certainly a non-trivial problem and one that could have a pretty big impact on your game.

 

Let’s start by taking a look at the various options… at least the ones I can think of.

 

2D - Pre-render all possible configurations

Of course, brute forcing it is always a possibility and in a few cases may actually be ideal.  Basically for a 2D game, you simply create every combination of sprite for every combination of equipment.  So if you have an animation sequence for “walk_left” and “walk_right”, you would have to create a version for each possible equipable item.  So you might have “walk_left_with_axe” and “walk_left_with_sword” sprite sheets for the different weapon combinations.  If you are rendering your spritesheets automatically from a 3D application, this could actually be the easiest approach.  Of course there are some seriously massive downsides to this approach.  Memory usage quickly becomes outrageous.  For each piece of equipment you double the size of your original sprite sheet for example.  Once you start adding more and more options, this approach quickly becomes unfeasible.  If you only have a very small amount of customization ( two or three weapon options ), this approach may appeal due to it’s simplicity.  With anything more than a couple combinations though, this approach is pretty much useless.

 

2D – Pre-rendered spritesheet + pre-rendered weapon animation frames.

You can use a regular sprite sheet and simply keep the weapons separate.  So basically you have two separate sprite sheets, one of the character without weapons, one with just the weapons.  Then at run-time you combine them.   Consider these two sprite sheets ( taken from a StackOverflow question ).

Animated Character:

Player SpriteSheet

Weapon:

Weapon SpriteSheet

Then at run-time you combine the two sprites together depending on what is equipped.

In fact, if your weapon isn’t animated ( as in, it doesn’t move, like a sword, as opposed to a weapon like a whip or nunchucks ) you can get by using a hard point system, where you define the mount position of the weapon ( for example, the players right hand ) and orientation.  Basically for each frame of animation, you provide an x and y coordinate as well as rotation amount that represents where and how the weapon should be mounted.  Then at runtime you combine the two sprites, positioning and rotating the weapon sprite relative to the mount/hardpoint. This way, you only need a single image per equipable weapon.

This approach has a couple downsides.  First, you need a separate data file to hold mount point data and possibly a tool to generate it.  Second, it makes bounding/hit detection more difficult as the mounted weapon may exceed the dimensions of the originating sprite.  Third, you need to deal with z-depth issues, you cant simply paste the weapon on top of the sprite, as what happens when the character is walking right but carrying the weapon in the left hand?  To handle this your workflow needs to basically be: render obscured weapons, render character sprite, render foreground weapons.  Finally, weapons with their own animation, like a whip snapping, would require even more effort.

All told, this is probably the easiest while still flexible system for 2D animation.  It requires a bit more work than simply brute forcing your sprite sheets, but the payoffs in reduced size and complexity are well worth it, especially if you have more than a couple items.  One other big win about this approach is then weapons can be re-used across different sprites, a huge win!  Then you can model a single sword and it will be available to all sprite sheets with hard/mount point information available.

 

3D - Bone/hardpoint system

If your game is pure 3D this is often the way you want to go.  If you character is a knight for example, in your 3D modelling application you create named hard points in your model, either as bones or as an object of some form such as a null object, point or invisible box.  Then at runtime you bind other models to those locations.  So for example, if you equip a long sword and shield, your code searches for the “right_arm_shield” bone and uses it as the parent object for a shield 3D model.  Then you bind a sword to say… the “left_arm_hand” bone.  You can see an example of this behaviour in this UDK example.

This approach is basically identical to the last 2D method mentioned except in 3D and that you dont generally need to define your own hardpoint system, as most 3D packages and engines already support it out of the box, either by binding to a bone or by accessing and parenting 3D objects to named locations.  Like working in 2D, then your weapon and character are two separate entities, like so:

3P_Weapon_Attach.JPG

One of the major advantages of 3D over 2D is flexibility.  Most animations in 2D need to be pre-calculated, while in 3D you have a great deal more flexibility with the computer filling in the blanks for you.  Unlike in 2D, additional 3D animations add very little to the data file sizes.

 

2D Bone based animation

One of the major downsides to 2D animation is, as you add more animations, it takes up more space.  People have been working on solutions, one of the most common of which is 2D bone animation.  How exactly can you use bones on a 2D image file you ask?  That’s a good question!  In 3D, its pretty simple… the motion/influence of the bone transforms the attached geometry.  In 2D, there is no geometry, so how can you do this?

Well, the simple version is, you cut your bitmap or vector image up into body parts.  So instead of a single image of an animated character, you instead of an image for the foot, lower leg, upper leg, torso, waist, shoulder, left upper arm, etc…  Then you can draw 2D bones that control the animation of this hierarchy of images.  There are applications/libraries that support this, making it mostly transparent for you.  Here is one such example from Spine from Esoteric Software.

 

The character:

Creating Bones

 

It looks like a single image ( and you can see a couple bones being drawn in the foot/leg area ), but it is actually composed of a few dozen source images:

Set Parent

 

Basically the workflow goes, you create your traditional image in your regular art program, except instead of creating a single image, you create dozens of hopefully seamless ones representing each body part.  You stitch them together, setting the drawing order ( what’s covering what ), then define bones to create animations.  This has the double advantage of massively decreasing space requirements while simplifying the animation process.  The downsides are creating your initial image are a great deal more difficult and of course, you need to buy ( or roll your own ) bone system, such as Spine. 

 

Spine is not the only option, there is also Spriter from BrashSoftware and probably others I am unaware of.  Both of these are commercial packages, but then, both are dirt cheap ( IMHO ) with price tags between $25 and $250 dollars, with $60 and $25 dollars being the norm with each package respectively.

The nice thing about taking this segmented bone approach… you basically get the ability to swap components or bind weapons for free.

 

2.5D hybrid approach

2 1/2D is becoming more and more popular these days.  Essentially a 2.5D game is a 3D game with 2D assets ( such as 2D sprites over a 3D background ), but more commonly its 3D sprites over a 2D background.  How does this work?

Well there are two basic approaches.  You model, texture, animate your 3D model as per normal.  Any character customization you perform you would do as if you were working in full 3D.  Now is where the two different approaches vary, depending on performance, the hardware you are running on, etc…  You can either generate a sprite sheet dynamically.  Essentially when your character is loaded or you change equipment, in the background your game renders a sprite sheet of your updated character containing every animation frame, then you use this sheet as if it was a normal 2D sprite sheet.  The other option is, you render your character each time it moves.  Creating a spritesheet consumes more memory, but very little GPU or CPU demand.  Generating your characters current animation frame dynamically on the other hand, takes almost no memory, but at a much higher CPU/GPU burden.  Which is right for your game is obviously up to you.

Of course the 2.5D approach certainly has it’s share of problems too.  First off, it is the most complicated of the bunch.  Second, you cant do any “by hand” calculations on your generated sprite/spritesheets, as they are now being rendered dynamically.  This means no ability to create pre-calculated bounding volumes for example.  On the other hand, the 2.5D approach gives you most of the advantages of 3D ( compact animation data structure, easy programmable modification, ability to alter texture mapping, lighting effects, etc… ) that 3D does, but with the simplicity of dealing with a traditional 2D world.

One animation to rule them all!

You may be thinking WAHOO… I can cut my work way down now!  All I need to do is animate an attack sequence and then I can simply substitute the different weapon images.  Not so fast I am sorry to say.  Think about it this way…  are the images for swinging an AXE and a Sword the same?  What about a pole arm?  You are still going to have several different animations to support different classes of weapons, but these techniques will still vastly reduce the amount of data and work required while allowing a ton of customization.

 

 

So then, what am I going to do?

So, which approach am I taking?  Ultimately I am going to require a great deal of customization, going far beyond the examples described above.  One such example scenario is a Mech with a customizable left weapon… this weapon could be an arm holding a gun, a turret containing one or more guns, or possibly even a large pack of rockets.  Each “weapon” could have it’s own animation set.  Oh, and I am much more proficient in 3D than 2D.  On the other hand, the game itself is a 2D game and I would prefer to keep it that way for the simplicity that brings in a number of areas ( level creation tools, path-finding and other AI tasks, physics, cheating at art, etc… ).  As a result, I am going to try the 2.5D approach, where the mech is created and animated in 3D, dynamically equipped, then rendered to 2D.  I am going to try both pre-rendering sprite sheets and dynamically rendering a single frame and see what the overhead of each is.  I actually have the compounded issue of dealing with enemy characters that are also dynamically generated, so any impact will be magnified many time over!

If I can’t get adequate performance from each approach, I may be forced to go full 3D and emulating a 2D look.  As I said, it’s one of those things that can have a major impact on your game!  That said, I am pretty confident performance wont be too much of a factor.  My immediate take away task list is:

  • get a LibGDX project set up that can load and render an textured, animated 3D model exported from Blender. I am pretty new to 3D in LibGDX ( okay… completely new to it )
  • bind another model to a bone on this model ( aka, a sword to a hand bone )
  • try to dynamically generate a sprite sheet of the character’s complete animation.  Measure resulting memory usage and time required to generate sheet
  • re-architect the code to instead generate each frame of animation per frame on demand.
  • scale both scenarios up to include multiple instances and see results on performance
  • measure performance impact of each approach on both desktop and mobile.

 

The outcome of this experiment will ultimately decide what approach I take.  Stay tuned if that process sounds interesting!

 

Oh, and of course, these are only the scenarios I could come up with for dealing with dynamically equipped characters, if you have another idea, please share it!

Design Programming


23. October 2013

 

I just received the following information from Autodesk about Maya LT, an indie focused version of the Maya 3D software we covered back in August.  Today’s release adds some new functionality and addresses one of the biggest complaints, the low polygon limit.

 

Autodesk Releases Maya LT Extension 1 for Indie and Mobile Game Developers


Advances asset export and 3D modeling through enhanced interoperability with Unity3D and increased polygon count


Today Autodesk launched the first extension for Autodesk Maya LT - the company's recently released 3D modeling and animation tool designed specifically for independent and mobile game developers. With new features such as improved interoperability with Unity3D, an increased polygon count and more, Maya LT Extension 1 simplifies the export of 3D content into artists' desired game engines and expands 3D modeling capabilities. Extension 1 is available today to as a free download for customers on subscription and pay-as-you-go plans.


Key features in Maya LT Extension 1 include:
- Improved Interoperability with Unity: A new “Send to Unity” workflow allows artists to export 3D assets with unlimited polygon counts from Maya LT directly into the asset folder of a Unity project.
- Increased Polygon Count for Export: Export high-resolution models or scenes up to 65,000 polygons in the Autodesk FBX asset exchange format to the desired game engine.
- New Retopology Toolset: First integrated in Maya 2014 and now part of Maya LT, NEX modeling technology streamlines the retopology workflow. Artists can optimize meshes for cleaner deformations and better performance using a single toolset within Maya LT.
- Advanced Booleans: Maya LT now employs a robust and efficient new library for faster and more reliable Boolean operations on polygon geometry.
- FBX Export Improvements: Advanced support for exporting accurate geometry normals (binormals) facilitates consistent surface shading when assets are rendered in-engine.


More information about Maya LT and a free trial of the software are available via http://www.autodesk.com/mayalt and http://area.autodesk.com/mayalt .

 

Is 65K polygons a better limit, or still to low for your games?  It’s certainly an improvement on the old 25K limit.  One of the big flaws of a polygon limit is if you are using Maya as a level design tool, which is nicely solved if you are working in Unity which no longer has an limits.  If you are working in UDK or Project Anarchy on the other hand, there is still a problem. On a somewhat off topic note, I am not sure what I think of the “extension” versioning system.  It makes sense and its nice to see a fast support cycle but there is something about that I find off-putting.

News


22. October 2013

 

Hot on the heels of their 100,000$ contest announcement the guys at Project Anarchy have another major announcement.  The latest update to Project Anarchy now includes Scaleform… for free!

 

SAN FRANCISCO – October  22, 2013 –Havok™, a leading provider of 3D game development technology, announces today that it has integrated the full version of Autodesk® Scaleform® software into Project Anarchy, Havok’s completely free end-to-end mobile 3D game production engine. The addition of Autodesk’s industry leading UI solution to Project Anarchy complements Havok’s Vision Engine, Physics, Animation and AI technologies and offers developers a complete solution for faster, more efficient game development.  Games built using Project Anarchy can be deployed for free on iOS, Android and Tizen mobile platforms without commercial restrictions on company size or revenue. The latest version of Project Anarchy, which now includes Scaleform is available for download now at www.projectanarchy.com/download.


Autodesk Scaleform has helped game developers create immersive UI for over 1,500 game titles. Leveraging the power of the Adobe Flash toolset, Scaleform provides streamlined, artist-driven workflows that help developers create 3D game menus, HUDs, animated textures, in-game videos and mini-games more quickly.


“Project Anarchy was created to give mobile developers a complete solution for all aspects of the game development process, and Scaleform is the perfect addition to round out that package,” said Ross O’Dwyer, Head of Developer Relations at Havok. “We have an incredibly active community and their feedback is really important to us. We saw demand for an improved UI system and we’re happy to be able to deliver it and further empower our developers with the strength of the Scaleform toolset.”


“Scaleform provides a robust solution that allows developers to rapidly create high production value user interfaces for a wide range of game genres.  Coupled with the comprehensive Project Anarchy toolset, developers are empowered to design innovative user interfaces seamlessly across many platforms,” said Marc Bennett, Director Interactive Display Solutions, Autodesk Media & Entertainment. “The Scaleform toolset and the robust functionality offered by Project Anarchy allow developers to give their mobile titles a level of polish usually reserved for big-budget console games.”    
Project Anarchy includes Havok’s Vision Engine together with access to Havok’s industry-leading suite of Physics, Animation and AI tools as used in cutting-edge franchises such as Skyrim™, Halo, Assassin’s Creed®, and Uncharted. With features like an extensible C++ architecture, a flexible asset management system, Lua debugging, customizable game samples and tutorials, and a full fmod® integration for audio, Project Anarchy offers game developers the ability to quickly iterate on their ideas and create incredible gaming experiences.


For further information on Project Anarchy, developers can visit www.projectanarchy.com and www.havok.com. More information on Scaleform can be found at: http://gameware.autodesk.com/scaleform  

 

You can read the official announcement here.  If you’ve never heard of Scaleform it’s basically a striped down game oriented version of Flash intended to be embedded in games.  Tons of AAA games use Scaleform for their UI layer ( Crysis, Deus Ex, Witcher 2, etc ).  Scaleform is also available for Unity as a plugin, but in the case there is a 300$ price tag attached!  Scaleform is also available for the UDK although I am unsure of the licensing conditions.

 

So, if you are looking for a cross platform mobile 3D engine, Project Anarchy just got a great deal more attractive.  Oh yeah, in case you didn’t know, GameFromScratch does have a series of tutorials available! If you just want an overview of what Project Anarchy actually is, start here.

News


1. September 2013

 

One of the oldest and most popular articles on my site is I want to be a game developer… now what?  It offers a collection of advice for new game developers.  I keep intending to update it but frankly, not enough changed.  The following was recently posted on GameDev.net:

 

https://www.gamefromscratch.com/post/2011/08/04/I-want-to-be-a-game-developer.aspx
This article was written 2 years ago, and is very informative about each game development language, but 2 years sounds like too much for how events quickly change now, XNA is partially dead, more books released, etc..

Is there a newer article of that kind of information? and is C++ still a bad choice (with the introduction of SFML 2.1 and SDL 2)?

 

Which got me to thinking about what all has changed since I wrote that guide.  The following was my answer.  Of course, I have no idea how many thousands of things I forgot to mention.  All told, the world hasn’t changed all that much, languages don’t really move all that fast.

 

Truth is, I keep meaning to update it, then look at the state of the game development world and there hasn't really been enough changes.  I will be doing a v2 eventually, but in summary, here is what's changed since the article was written:

C++

-----------------------------------------------------------------------------

SFML 2/2.1 released.  Frankly it's not all that different.

SDL 2 was released.  Again, not massive changes.

Gameplay3D engine released  Site Link My Look

Hands down the biggest change to C++ ( and over the last two years ) was the release of C++11.  This completely changes the C++ book recommendations.  C++ changes a lot about the language, especially how it should be taught.  Some books did a horrid job updating to the new standard ( just bolting on the new features ), while others did a better (less lazy) job.  I will probably do a post specifically about C++11 books at some point in the future.

C#

-------------------------------------------------------------------------

XNA was put out to pasture by Microsoft.  Fortunately, Monogame also got a lot better.  XNA is still an option, just not as good of one as it used to be.

PlayStation Mobile was released and C# based.  SDK Link (My Tutorials)

Unity 3D is now free.

Mono for iOS and Android 100$ cheaper

C# 5 released.  Outside of parallel programming functionality (async), not much changed.  Nowhere near the change of C++ for example.

Java

-------------------------------------------------------------------------

Slick2D is dead or abandoned.

Java took a few hits in terms of deployment due to security concerns ( Apple yanked it for example ).

LibGDX is probably the strongest option in Java now.

Don't believe there were any major language updates ( 1.7 then and now ), just service releases.

Python

-------------------------------------------------------------------------

Um.... anything?

Otherwise there would be a few things I would mention that weren't as relevant 2 years ago.

Misc

---------------------------------------------------------------------

Rise of the Lua game engines.  Add Dreemchest to that list as well.

In the mobile space, Lua just simply put got big.  Lua is also the scripting engine of choice for CryEngine, Gameplay and Project Anarchy.  Lua is a very very very good starting point for people looking to just start out.  Corona is now available free and at the same time, is more expensive...

HTML5 got a little bit more viable ( but still limited ) Flash suffered some major blows ( but still viable ).  There are now a number of solutions that make appifying HTML5 applications possible, such as CocoonJS.  Tons of libraries exist for HTML5 game development..

Previously niche/limited game maker software ( GameMaker, Construct2 ), as well as cross platform tools like Haxe (tutorial series) or LoomScript ( my look ) have made cross platform game development a hell of a lot easier.

The 3D engine space saw a bit more activity.  As mentioned earlier, RIM released GamePlay3D.  On top of that Torque was released for free, CryEngine leaked it's developer information in a hack attempt... ( thanks for that btw... :( ) and Project Anarchy (my look) was announced and released.  Project Anarchy is a bundle of Havok's game developer technology released completely free for mobile development.  On the 3D game engine space the story is Unity Unity and Unity.  Frankly Unity had a good year, made partnerships with pretty much every single platform available and is available in a free version for pretty much every platform now.

Grand total, not all that much happened, not really enough to full write a v2 version, hands down the biggest changes in the last two years:

C++ 11

XNA killed

Unity took over the world.

I miss anything?

 

Anything else I missed in the last two years of game development?

Programming


28. August 2013

 

As you may have noticed yet we ( somewhat prematurely ) reported on Maya LT, a new indie focused version of Maya.  Today marks the official release of Maya LT. I also got the opportunity to get some additional clarification from Autodesk, in an interview below.

 

Here is the official press release:

Autodesk Unveils Maya LT for Indie and Mobile Game Developers Starting at $50 a Month

 

 


Powerful Tools and Affordable Pricing Expand 3D Options for Independent Game Developers and Small Studios

SAN FRANCISCO, Calif., August 28, 2013 — Autodesk, Inc. (NASDAQ: ADSK) today introduced Autodesk Maya LT 2014, a new 3D modeling and animation tool tailored for independent and mobile game developers. Available immediately and compatible with certain industry-standard game engines, Maya LT draws inspiration from award-winning Autodesk Maya software to bring an intuitive, affordable new toolset for the creation of professional-grade 3D mobile, PC and web-based game assets.MayaLT__HyperShade_DX11_UberShader__1920x1080

“We see indie game developers as a key part of the industry, driving innovative new production techniques and gameplay,” said Chris Bradshaw, senior vice president, Autodesk Media & Entertainment. “The market is fiercely competitive, and Maya LT can provide indie developers and small studios with a powerful, yet simplified workflow for designing and animating remarkable 3D characters, environments and props – at a price that fits within even the most modest budget. It’s a practical solution that closely matches the needs of the mobile game development production cycle and helps developers rise above the noise and really shine.”

Smaller studios like Phyken Media, creators of the mobile game Wizard Ops Tactics, saw both the economic and workflow benefits of the new product.
“I jumped at the chance to try Maya LT, as the cost flexibility means we could grow the studio much more comfortably,” said Phyken Media President Kunal Patel. “With an option like Maya LT, our small team can accept bigger challenges and take on various new types of projects that may require more artists without having to worry much about any large upfront expenses. We even found operating expenses are much easier to determine.”

Maya LT for Game Developers
Maya LT debuts with an easy-to-navigate user interface (UI) and industry-renowned 3D modeling and animation tools that enable independent game developers to rapidly deliver 3D assets into game engines. The software integrates seamlessly into game development workflows with out-of-the box support for Unity 3D Engine and Unreal® Engine™ through the FBX file format for primary data exchange, and the ability to import certain 3D asset formats [Maya (.ma, .mb), Maya LT (.mlt), OBJ, FBX, AI, EPS] and texture formats (BMP, PNG, DDS, EXR, TGA, TIFF), as well as export 3D assets in FBX and .mlt.

MayaLT__HumanIK_AnimationGraph_and_Outliner__1920x1080Key Features
Maya LT has a number of features customized specifically for the needs of mobile and independent game developers: powerful modeling tools to help create and alter 3D assets of any size and export FBX files containing up to 25,000 polygons per object, animation tools that include a skeleton generator and inverse kinematics with Autodesk HumanIK, and high-quality viewport previews to help developers view assets as they would appear in game, reducing iteration and asset creation time. Other key features are lighting and texture baking, giving designers professional global illumination tools to help simulate near realistic lighting through baking lighting data into texture maps, and vertex maps.

 

Pricing and Availability
Autodesk Maya LT 2014 is now available for Mac and Windows at a starting price of $795* SRP per perpetual license. Term licenses will also be available as part of a monthly, quarterly or annual rental plan in the near future, starting at $50* SRP, $125* SRP and $400* SRP respectively.

Learn More About Game Development with Autodesk Maya LT
For more information, and to download a free** trial of Maya LT, visit: www.autodesk.com/mayalt. Connect with the Maya LT development community at: http://area.autodesk.com/mayalt.

 

I got the opportunity to get a bit more detail from the team at Autodesk.  Answers where provided by Wesley Adams (WA), Autodesk Industry Market Adams  and Frank Delise (FD), Autodesk Director of Game Solutions.

 

Question: What are your target audience with this release.  Are you aiming primarily at game developers working with UDK and Unity, or indie developers in general?

Answer (WA) : Maya LT was specifically created to address the needs of indie game developers who want to create 2D and/or 3D assets for mobile platforms and much of its feature set is dictated by these requirements. It is primarily a 3D asset creation tool although it has a broad range of animation tools as well. It is engine agnostic and the assets created in Maya LT can be exported to any game engine via FBX including both Unity and UDK. Maya LT is designed to expand our portfolio of mobile game development tools, which already includes the Scaleform Mobile SDK with a Unity plugin. The Mobile SDK is based on the core technology of Autodesk Scaleform, but enables developers to use it as a standalone Flash runtime to port games to mobile platforms. This gives indie and mobile developers two different ways to access technology that was somewhat inaccessible to them previously.

 

Question: Are you considering launching a similar program for other tools such as Softimage or Max?

Answer (WA): Although we cannot talk specifically about future product releases, we do intend to continue to evaluate many different productization strategies, including LT versions, for our core entertainment markets of Film, Games and Television as well as to address new markets. However, it is not our intent to release multiple products for new markets. In this case we are targeting game developers who want to create 2D (sprite sheets) and 3D assets for mobile games. They require a solution that works both on PC and Mac and so we chose Maya as the basis.

 

Question: Will it be possible to white list certain plugins.  For example, the current no plugin policy will make it impossible to use Maya with Project Anarchy's art tools from Havok.  Will Autodesk be working with third parties in this regard?

Answer (WA): Yes, our intent is to work with third parties to build a healthy plug-in eco-system around Maya LT. In many ways Maya LT is a v1 product and we plan on an aggressive development path for it.

 

Question: Any possibility of an end-to-end Autodesk bundle ( such as versions that output specifically to Scaleform ) at indie friendly pricing. Or in a Creative Cloud type subscription service?

Answer (WA): We have no further announcements to make at this time regarding other new products and offerings, but we will indeed offer customers the option of purchasing either a perpetual license (with or without subscription) or a monthly rental plan.

 

Question: Are there going to be upgrade options available like other Autodesk LT products to move from LT to full versions?

Answer (WA): Right now there are no upgrade options available to move from Autodesk Maya LT to Autodesk Maya or any other Autodesk 3D animation product, primarily because it was not designed as an entry level product to Maya but to go after a new market.

 

Question: Is LT based on 2014? Is the intention to keep them at release parity? How long is the outright license purchase eligible for support?

Answer (FD): While Maya LT is based on Maya 2014 it is not intended to just be a reduced version of Maya but follow its own trajectory as a solution for indie developers developing for mobile platforms. So while we plan to keep Maya LT and Maya very close in terms of those Maya features that are relevant to indie game development, in some cases we may take different approaches to solving certain problems or needs. This could mean Maya LT specific capabilities not available in Maya for example.

 

Question: Doesn't the 25K limit on export heavily handicap certain usage scenarios, such as using Maya as a level editor?

Answer (FD): No, Maya LT can handle the same scene sizes as Maya. Therefore you can create large complex scenes. When exporting to a game engine, you’ll need to export the scene in modular pieces, up to 25k per object via FBX. This is a typical scenario when building games, using modular design. For example, you can create a car that’s over 70k polys, but export the body separate from the wheels. Maya LT also supports hi-res to low res texture baking for complex asset work.

 

Question: Does removal of MEL also prevent creation of toolbar shortcuts? What is the reason for removing MEL in general, is it not remarkably core to the Maya experience?

Answer (FD): In Maya LT, you can still create custom toolbars; however, Mel was removed. Maya LT is not a replacement for Maya in games; it is designed for asset creation for many indie game assets. We still expect Maya to be used by game developers who want the functionality to build custom pipelines\tools and advanced features.

 

Thanks for taking the time to answer guys!

Art


GFS On YouTube

See More Tutorials on DevGa.me!

Month List