UnityVersum

Repost of GameDevUniverse: http://www.gamedevuniverse.com/blog/2011/09/visual-scripting-holy-grail-or-apocalypse-for-game-development.html

Visual Scripting has gained a lot of attention the last years, by various indie designers that don’t want to learn coding its considered to be kind of a holy grail to enabled them to do things they would otherwise never have been able to do.
The likely widest known usage in the game development is Unreals Kismet which is powerfull and well integrated and especially makes cinematics creation very easy. But its also Kismet that shows the limits compared to going with UnrealScript, there are just things it can not do or things that look that clumsy that you really don’t want to do it there. So lets talk about the pro and con in detail.

The raw potential
The main benefit of visual scripting is a simple yet important one: Its not text! All the limited functionality they normally provide are easy approachable, making it possible for people without knowledge in one or more coding languages to create interactive functionality. But it requires that simple yet powerfull nodes for the specific tasks in question are available.
Through Nested nodes (sub graphs) its additional possible to raise the readability of a graph and make parts of it easy reusable.

The problems
The largest problem that anyone will unavoidably hit within hours at maximum is the ubiquity of the information. A functionality written in code taking 5 lines of code can easily lead to a graph spanning dozens of nodes and more to be represented in visual code. As an example of this problem of readability and „just beeing“ please see the following simple graph (done with uScript Retail Beta3) that does nothing but bounce a game object by a given Vector3 over time and back again. The screenshot shows just the small part of it handling the position forward backward handling

Enumerating collections is another thing in visual scripting that basically is a pure nightmare. Even if there were any visual scripting technology that would be able to represent this process in a LINQ alike form, it would still be very hard to grasp for designers.
As mentioned under the raw potential, one of the benefits of graphs is also a drawback and thats nested nodes (subgraphs), which if used right offer an easy way to reusability and making a graph more readable. But unhappily when not used right they can make it near impossible to maintain a graph at all. Especially if the designer uses nested nodes within nested nodes and even deeper hierarchies it becomes impossible to handle them any longer.

The options in Unity

PlayMaker
Not a visual scripting technology per se as it does not allow to create free form code, its an editor to design Finite State Machines, and important and very easy to grasp concept as we use it all day long without knowing about it.
Out of my view the best solution for pure designers with no coding knowledge because it is not only easy to approach and backed by piles of tutorials etc, but first and formost its not „just code“ that the developer will create but a clean and solid interaction broken down into states. Other solutions as well as pure code in the hands of non coders often lead to messy code and spaghetti code, while PlayMaker does not allow that, it requires that the designer thinks about the interaction and how it „plays out“ to create corresponding states and transitions.
The result will be code that he can maintain much easier and which is much more readable as only the states end on the ‚graph‘, which will enable him to get more done and especially done in a working form.
A usefull feature to make this even easier is the capability to visually debug the FSM, so you see in which state it is and where it transitions etc.

uScript
  uScript is the youngest of the 3 solutions, approaching its release version (Retail Beta 3 at the time of writing). It follows the design principles that are applied in other technologies too, especially Kismet from the Unreal Engine / UDK.
It has well done and polished visual appearance that not only helps being productive but especially being able to grasp the meaning of a graph with a glimpse or two.
One unique feature it advertises to have is that the graphs actually generate C# code, which makes it platform independent. But to be fair, out of my view that generated code has relatively little meaning cause its impossible to work with it beyond „looking at it“ and being granted to work on any platform as its not designed and written for usage in a pure code form. Also when the corresponding graph is resaved, it will be overwritten!
Its major drawback compared to the competition at the time is the lack of visual debugging, which brings back one of the main problem for designers on normal coding to uScript too and thats that you need to know what you do and where an error comes from to fix it basing on educated guessing.

Antares Universe
Like uScript its a full visual scripting solution, which unlike uScript does not base on the Kismet style of working but a more „programmer style“ approach without the temporal variables for transfer or the coroutine yielding directly on the connectors (the + buttons along the lines)
It clearly loses on the front of visual appeal and easy graspability due to the graphics and the layout of nodes and connectors, but it compensates for that through two major benefits over uScript, which are the visual debugging (like PlayMaker) and the possibility to create GUIs in realtime within the editor basically.
Also it offers many very high level and high usage nodes out of the box (LoD node for example) and at least from a subjective point of view a clearly higher execution performance than uScript.

Conclussion
Its neither a holy grail nor the apocalypse. It surely has its good points and when used correctly, for example to expose high level logic in a designer friendly form to allow them to create that code on their own while the programmers focus on the low level and core systems, then it surely can turn into a diamond for a project.
But on the other hand if a designers with no programming knowledge has the hope to create whole games purely on it, I personally consider this completely unrealistic and a major source of frustration for the designer more sooner than later, because there will be limits which he will just not be able to solve without a programmer.
None the less visual scripting can enable a talented designer to create a simple game or a prototype to grasp the interest of others or an investor, so its not per se bad or deal breaking at all

Crosspost of http://www.gamedevuniverse.com/blog/2011/06/ios-5-and-what-it-means-to-us-as-users-and-developers.html

Crosspost from http://www.gamedevuniverse.com/blog/2011/03/ios-43-the-future-has-landed.html

That iOS 4.3 and a new iPad 2, if it then were to happen, would happen at the same time was expected, but what not everybody (non beta users) would potentially not have expected is how it landed.


The all new development IDE

With the iOS 4.3 SDK, Apple officially pushed XCode 4 onto the big stage, pushing back XCoode 3.2.x one which was used as the XCode version for the iOS SDK on any previous build.

XCode 4, which has been available as public preview and beta for many months now, adds a few very usefull features for productivity enhancements, if you happen to develop native applications with Object C and C++, as the integrated interface builder, the much better integrated SCM support and what Apple likely would call a simpler, cleaner, more productive interface and out of my view as user of Visual Studio who never understood how Apple can still be stuck in developers stoneage: XCode 4 finally does realtime code checking that goes through the real compile process behind the scene basically instead of good guessing by an artificial checking which had a tendency to end on code that seemed right until the compiler or linker touched it.

As usually with Apple, this all new great world that we have entered comes at the price of basically relearning all we knew, because XCode 4 really deserves its new major number, nearly nothing is where it used to be, some things are not even available anymore.

Along XCode 4, iOS 4.3 officially favors now the LLVM 2 based GCC instead of GCC 4.2 which was previously the standard one.
I would recommend anyone who has no good reason against this compiler to use it, your compile time and performance will thank you for doing so!



Dropping out the the "old devices"

The second big thing about future that landed is that iOS 4.3 unlike many know from its presentation, not only supports the today released iPad2. In addition, iOS 4.3 also removed support for any of the ARMV6 based devices (iPhone 2G, iPhone 3G, iPod Touch 1st and 2nd Generation), which for Apple likely is a first timer, that they did a major hardware cutoff on a software / OS midway the same major version. We have seen feature limitations already along iOS 4, so the shock is not that large but the impact is still not to underestimate as the consequences on ARMV6 supporting builds done with the 4.3 SDK are not known yet, there are reports of strange performance problems with iOS 4.3 SDK based builds and alike though.

For end users that are on the 3rd generation or newer this naturally is great news, not only because there are a host of new nice features, but it also means that the start to focus stronger on ARMV8 devices happens ealier than the expected iOS5, which will benefit 2/3+ of all currently still in use iOS devices, resulting in either better battery runtime or smoother experiences performance wise.



This is all an interesting development out of my view for us developers that work for or against iOS to achieve their target, as we can work productively now and soon without having to fight the very slow, OpenGL ES 1.1 only, low RAM devices that pestered us long enough if you ask me.

So for a day, the cat is now officially out of the bag.
We have seen what Apple has been working on to fight the Android 3.0 hype, where they listened to their users and especially devs and how far Apple is willing to drag the fight.
But what do this things mean to me, to you, to probably all developers working on iOS and Android?

First off I've to say that I am pretty happy with what we've seen.
The rumors previously indicated, that Apple might not upgrade the graphics chip in the iPad reasonably, after already the original iPad suffered reasonably from it on the gaming end, but the claims they put out indicated that they did not only upgrade the SGX535 to an SGX543 but even to an SGX543MP2 or MP4 gpu (as in Samsungs Enyxos 4210 also used in the Galaxy S II and Galaxy Tab 10.1), while at the same time keeping the screen resolution on the same 1024x768 level the previous iPad had, which would be massive leap ahead.
With power like that, the 2 tech demos Epic put on the AppStore (Citadel and Infinity Blade) will look like last generation games. Still good but they won't compare to the high profile games that we will likely see happening.

The first impact of the iPad 2 is pretty clear, with the additional power, the camera, Verizon, the same prices and battery lifetime as the original iPad andstarting on a massive collection of applications right from day 0 on all on native resolution we are talking about a power horse here which Motorola surely didn't want and expect to see that fast when they brought the Xoom to market.
I already considered the original iPad as a rather solid replacement for most tasks I had a netbook, but the new iPad 2 (as the Tegra 2 / Enyxos 4210 Android 3 tablets) make netbooks obsolete if you hook them up to bluetooth input devices at home.

The second impact the iPad 2 will have for us developers is that the competition on the Android side will not be able to get away with its dream pricing.
Yes we all know that Tegra 2 tablets are fast, but we have also seen their shocking, unreasonable prices. Prior to the iPad 2, they had room to say that it is for the sake of power as they were ahead of the iPad by a fair leap.
But now with the iPad 2 coming up in weeks (March 11th in US, 26 major countries planned for March 26th, I'm reasonable and expect them by April 9-16th ie 2-3 weeks later as on the original iPad), at the same price as the original iPad, this excuse will likely no longer work out.
This baby will force them to cut their margins and get their prices in line with the iPad prices or they will kick themself and even more so the chances for Android 3.0 out of the game for another 6+ months. With the Xoom prices we have seen we talk about price drops for Android 3 tablets in the range of 20-30% of their original target and initial release prices.


Crosspost from http://www.gamedevuniverse.com/blog/2011/03/the-ipad-2-and-its-impact-for-developers.html