Rodney

I always look forward to these.

What I prefer doesn't particularly matter as the project was already a game app before I was invited on board. The success of the pitch will dictate how much detail can be put into the app. The app should have some video in the form of short cut scenes to set up, transition and end the gameplay so there should be some out-of-gameplay animation. It will likely have a news feed type function in the form of score keeping and I assume there will be some sort of pitch/marketing trailer to garner interest in downloading and playing the app..

Thanks again Gerald!

Besides the obvious (the fact that Unity is well developed/used) Is there any particular reason that Unity stands out to you in the mobile arena?

Thanks for the input Gerald!

I'm researching software for the initial workup of a game app proposal and have been asked to investigate software to build the proposed application. At this time the project is pre-pitch/prefunding with much of the material confidential so I can't go into detail on specifics of the game itself but the following is basic criteria: The team is affiliated with an Educational Institution and likely eligible for education/student licensing. The team consists of approx 14 people most of which are technical experts in the games subject matter (not gaming, graphics or software development). -- Depending on funding/green light to go ahead the team may involve students and previously established (paid) programming outlets with that expertise The game proposes to target 'Clash of Clans' quality and playability (probably more 2D than 3D) but graphics may be created in 3D and rendered to 2D sprites etc. I've mentioned Unity and Unreal Engine as possible software development platforms (although they may be slight overkill for the initial app) I believe it unlikely the app will cross the threshold requiring licensing payments to Unity/Unreal Engine but that is all guesswork from me. Here is a breakdown of some various software and the level of appropriateness to the project from my perspective: Unity/Unreal Engine - Likely more complex than required but would be excellent should the app garner support and need to be extended Flash - Possibly incompatible unless HTML gaming is an option for the project (unsure if institution already has appropriate licensing as most have students foot own license from Adobe) Game Salad and similar- probably too low end but could be an option especially if the student/game programmer is familar with the software - Game Salad's licensing may not be ideal however. Added: Python/Pygame is another option but is very technical and lacks GUI support. This is the gaming approach I am more familiar with than other mentioned above. Let's see, what else can I say... The game is to be developed for iOS and/or Android. Should the game development be green lit a mockup demonstrating basic play may be created in one software while the final game developed in another. Any information you can provide will be much appreciated. Thanks!

Most definitely. That's a dangerous question to ask me. I'm a big fan of dopesheets/xsheets although they've largely gone out of fashion and are often misunderstood. The primary purpose of these tools in the past was to drive forward the plan for animation whereas now it's largely for automation. Those that don't use xsheets/dopesheets use other methodologies to organize and move production forward. Automation can be seen as a dirty word in animation circles but isn't that the purpose of computers in the first place? To take the drudgery out of the process. I'm of the opinion the dopesheet is sorely underused especially when it is considered only as a tool for automating lipsync. The dopesheet can drive ANY pose... that makes it all the more powerful. Having said that I would also say that the majority of automation should be used just to get the initial staging set. The use of finer controls and character (personality) performances can then be focused on. (As you've suggested above) The question one might ask would be whether or not a pose can/will be reused. Similarly to canned Actions they have their proper uses. Imagine a set (before a character has been placed into it). There is no limit to the number of things that could be automated (as driven by dopesheets) to create better environments, crowds, background characters, etc. Anything that can be 'posed' can be leveraged/driven by a dopesheet. Of course the bottom line of dopesheets is that it's use is largely for early production/preproduction; to get the flow of production moving... economically. By automating 80% of the more laborious tasks we then can spend the majority of time directly focused on the fine tuned details of most important work. And here's the imporant point: if any of the work (automated or otherwise) doesn't have a compelling need to be further refined... it's done. Disclaimer: At present Dopesheets cannot be saved by themselves in A:M (as they were in the past). The workaround/improvement(?) to this is to save the Action wherein you've created the Dopesheet, then reuse that Action as necessary. That Action/Dopesheet can then be edited in any text editor, automated further or even created wholy in another program.

That was awesome Robert! (and your project file is the example of simplicity in presenting a solution) While Stefan never suggested it was impossible to do... you managed to sneak an 'It can't be done' video in on us too. Talking out of the side of a mouth (or at least asymmetrically) is such an important aspect of character dialogue that I'm really glad you guys have explored this. He's got me curious too. I'm going to guess he wouldn't generally use a dopesheet to drive the lipsync as his approach but would rely more on direct animation of the mouth opening and closing. In other words, in a similar fashion to how he animated the dialogue in the video without resorting to use of a dopesheet.

Looking very good Bobby! Another great 2D/3D node based compositor is Black Magic Fusion (formerly Eyeon/Digital/Fusion). It is free also and although quite different on many fronts has a feel about it that is very similar to A:M.

Hear! Hear! I don't think they realize just how appreciated they are! That is an excellent idea and a great way forward. Some don't care for Libraries but if those libraries could be accessed more directly via character/object settings/interface they might appreciate those more as well. I am reminded of ToaA:M's tiny write up on 'Talent Pools' and it applies to real people just as much as it does the labor they produce. If animation is hard it is mostly because of the many obstacles that must me overcome before animation can begin. While it doesn't always see us getting to our destination I suppose that is the fun of taking the journey... there will always be one more thing. Thank YOU Steve for sharing your experience.

Nancy said: I agree! Is that bone at the top of the UI for moving it to other locations? That's sure to be useful.

There are lots of 'features' (more than we could reasonably itemize) that could be created simply via the same means that many of the current plugins were made to work. Howard Trickey's contribution is an excellent example; he leveraged his understanding of bezier curves to put together the first font wizard and then extended that further to include adobe illustrator (.ai) files via the AI wizard. Emilio Leroux leveraged his knowledge of spline bias, etc. to create the Sweeper, Set Bias, plugins, Libary Manager and more. Mike Flynn created a stand alone Terrain generator. Richard Swika created A:M Loft. Marcel Brickman... too many too list... Soulcage Dept shared their Matcap shaders, There is an embarrassment of riches here... Jenpy, Malo, Woebling, Aaver, Rasikrodri... and the list goes on and on... and we should properly highlight that list with the highly esteemed Steffen Gross who so thoroughly studied the SDK that he became the master of it. And I apologize to all the folks whose ideas, inspirations and contributions I've missed... which includes those who actually hired folks to write programs/plugins (i.e. Anzovins) or worked with Hash Inc programmers to see their visions realized. Side story about Steffen Gross's programming prowess: I once pondered the possibility of drawing splines/bezier curves in other applications (such as Illustrator) and then bringing them into A:M (via AI wiz or something similar) where A:M would then automatically stitch the splines together into a mesh. A month or so later Steffen announced the creation of his Connect plugin that does exactly that process. And he did it as an exercise in programming because he saw it as a challenge. Yes, there is always a risk of watering down or weighting down A:M with too many plugins but I'd rather have those plugins (and be able to remove them) than to not have access to them at all. But the bigger risk is of not taking advantage of the tools that are at our disposal right now. What is used... will get improved and enhanced... what doesn't will be mothballed, stagnate, wither away or be replaced. If we, as a community, have failed in the development arena it's likely because we haven't been able to articulate what we need to each other and to share the information we already have with each other. There are a whole lot of features, programs and plugins that have faded away... not because no one cared... but because we, as a community didn't use/need them enough. While I don't know what lies ahead for the future we are in a different arena than before. Hash Inc doesn't provide free programming. That sounds like a big negative at a glance but it does free us up considerably to ponder new innovations that we as a community can get behind. The one thing I would emphasize... to save folks a lot of time and heartache... is that the odds of getting rich from your great programming idea are tiny. But if you really need the tool and have the talent, patience and fortitude to drive forward I'm confident it'll happen. Some folks have pondered how impossible it would be to build A:M (or similar/compatible programs) from scratch for this or that platform and my answer to that would be that it isn't impossible, but it will take considerable time. How much time? As such a project would never truly end (unless the effort faltered/failed) I will suggest that such a thing would take 'one-step-at-a-time'. We've strayed a bit from the topic but when considering any question what I always like to ask in response is, "What would success look like?"

We could actually use of few more of those.

I suppose that is something I should have known already but you just made a huge aspect of relationships click for me. Very interesting. Thanks David!

It's great that you had a backup!

I wonder how we could get a few good A:M tutorials into some of these digital courses... Enough to let folks know that A:M is there for them should they want to pursue that route. I see the 'guest tutor' link is as follows: http://www.digitaltutors.com/11/tutors.php#JoinDT There are more than a few talented folks with production experience in A:M (TWO, etc.) with knowledge that would be valuable to others.

Ha! I like that Robert. One of the likely outcomes of 3D displays might be to see the timeline channels take on depth (as opposed to their 2D representation in Timelines today). The question at that point then becomes one of also projecting the same channels/keys into the main viewport where they can be turned on/off and be seen from any angle as well. If we can see the channels/paths taken by CPs etc. in real space there is less reason to interact with them on the abstracted planar timeline.

Looking very good!

I don't recall specifics about 7. If you'd have asked me about 8 I'd have a plate full of reasons to share. At a guess I'd say WIn 7 introduced some features that made it slightly harder to organize my desktop (this was the era where I moved to the Chrome browser because Explorer became unusable so that overshadowed any more minor issues with Win 7. 7 worked. 8 was very frustrating and I immediately upgraded to 8.1 upon release. 8.1 restored basic functionality they should have considered more carefully before taking away.

Well, that's good news! I didn't care for 7 or 8 but 8.1 has been very reliable. Hopefully 10 won't be too rough around the edges. I see this note tucked in the article as well: Interesting.

To make this a little bit easier here are the basic phonemes/poses that comprise the Preston Blair set. Any dictionary defined with a breakdown of these phonemes will animate the basic lipsync 'correctly'. For additional extension to the set you can create your own but understand that other models without those poses/relationships/phonemes assigned wont drive any poses via the dictionary. So the short of it is that with the basic Preston Blair phoneme set we have 9 basic values to choose from that form all lip positions.

I don't think some of the extra symbols are used currently in A:M but they are useful when trying to actually say the words. Example: 'f versus f The apostrophe appears to designate which part of the word is emphasized. This won't show up in the dopesheets usage of the f phoneme though as both 'f and f will be assigned an f phoneme. Similarly, the comma appears to be a lowering of the emphasis when added before a phoneme. The / character separates the phonemes. @ is interpreted by A:M the same as the AI phoneme as is the & character... although they are pronounced differently in spoken language. The underline character appears to be used when joining two words by an underline character. This tells A:M that they are two words although they occupy the same word entry. In short, if you only use the basic phonemes without the special characters you should be fine (and you can always add those special characters later). More importantly, every phoneme used in the breakdown must be a phoneme that exists as a pose in your model/character or else A:M wont be able to assign it automatically via the dictionary. Of course you will still be able to assign any pose that exists in the model via the dropdown menu when selecting the option to 'Add Single Phoneme'. Words found in the dictionary will be a blue color while those not found will be red. For those looking in it may help to replace the word Phoneme with Pose each time you read it. Phoneme simply applies to a pose create for the purpose of articulating lipsync. The poses driven by the dopesheet can be any pose that assigned a wordname. (although I don't think A:M will accept spaces between words in a wordname, Hence the reason for the underline special character in the dictionary)

If they did more as a team it hasn't been well published. I don't know about that specific team but there is a certain CG virtual idol followed by millions that got her start in the A:M arena: LINK* Disclaimer: Minor demonstrations of manipulation of dynamic splinage which may not be appropriate for all audiences. *I've been looking for more conclusive reference to current use of A:M for some japanese games etc. but they are hard to come by these days. The public use of A:M has mostly gone underground since the Japanese distributor of A:M moved on to other venues. I figure by the time I move back to Japan A:M will be seen as sufficiently new and exciting and the fun will start all over again.

According to Martin Hash:

Hash Inc uses the Preston Blair phoneme set. I'm not sure that will fully clue you in to the breakdown in the dictionary file though. Some write ups by Gary Martin discuss the minimum set that you'll want to work with: http://www.garycmartin.com/mouth_shapes.html http://www.garycmartin.com/phoneme_examples.html