Notgames Forum
October 12, 2024, 02:25:57 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Calendar Login Register  
Pages: [1] 2
  Print  
Author Topic: Unity is driving us apart  (Read 59394 times)
Michaël Samyn

Posts: 2042



View Profile WWW
« on: October 05, 2011, 03:03:37 PM »

Auriea and I have analyzed our previous 18 months of prototyping two new projects. One of the things that came out was an issue with Unity. For our two major productions (The Endless Forest and The Path), we have used an authoring package called Quest3D. As a realtime visual programming tool, it stimulates improvisation and experimentation, which make it very well suited to artistic creation. It has a lot of flaws, however. It suffers from a lack of coherence in its design, gaps in documentation, plain bugs in some of its systems and an excruciatingly terrible asset import system. It also doesn't compile to any other platform than Windows.

The latter was the main reason why we used Unity to make The Graveyard, Fatale and Vanitas. We were also pleased to discover an application with a clear design focus (making video-games) and excellent asset import features. Since programming was done through scripting, however, we knew Unity would only be suitable for small projects.

Unless, of course, we were hoping to publish on other platforms.
Both games we have been prototyping are candidates for console publication. So we used Unity to produce them, even if they were both bigger and more complex projects than anything we had built so far with the package.

One of the prototypes, Cncntrc, was entirely programmed in Javascript. The early versions of the other, The Book of 8, were too. And the final version (that we're still working on) is being programmed through the visual interface of Antares Universe, an extension for Unity available in their Asset Store. Universe is a node-based programming interface similar to Virtools. And while it is possible to save Universe graphs while a game is running in the Unity editor, the program remains constrained to Unity's Edit/Play dichotomy.

This Edit/Play dichotomy is at the root of our issues with Unity, I believe. In Unity, you program a game and import assets first. Then when everything is done, you press play and your game level starts running from the beginning. If you need to change anything, you need to stop the playback, make the changes and start playing the level again, from the beginning. Repeat ad infinitum.
(this opposed to Quest3D where you're essentially programming a single frame -the game loop- and it is always on)

Unity, ironically despite of its name, forces an unwelcome separation between programming and art, and as such between Auriea and myself. Our strength is precisely the combination of technology and art. And, while we each have the final say over our own terrain, being able to influence the visuals through programming, and the algorithms through art creation is at the core of our practice. Unity does not encourage this. Unity splits up programming and art into two distinct fields. Visual programming extensions like Universe alleviate this somewhat, but the graphs are still too far removed from the 3D scene.



Quest3D's symbolic representation of assets as parts and chunks of flowchart may seem strange at first, but it does promote a unity between art and programming. Every element of every asset is directly available for manipulation through programming. There's no need to create a separate script (or separate graph) to be able to add a realtime algorithm or interactivity to an object. You can do it right then and there. Everything is expressed in the same -visual- language. I believe this is the key to artistic programming.

Since Microsoft has seriously ruined the Windows platforms in its latest versions of the OS, and we are still very much fond of the idea of publishing to Mac OS, consoles, phones and tablets, we're stuck with Unity for the time being. This means that we are forced to change our way of working. We are forced to separate (which is extra ironic since we are lovers: Unity is forcing us to divorce). We are actually making plans for our future projects along these lines: distributing our collaboration (giving one of us the lead over a particular project) and even considering hiring outside help with the respective aspects of production (asset creation and programming). We deeply dislike this evolution. But until another authoring tool comes along that allows us to work together again, we don't really see what else we can do -apart from not making games anymore.
Logged
Thomas

Posts: 384



View Profile WWW
« Reply #1 on: October 05, 2011, 04:56:41 PM »

Have you tried Unreal engine?

It has a visual script language along with it: http://en.wikipedia.org/wiki/Kismet_(gameplay_scripting)#Kismet

Not sure how good it is or how much of the game that can be done with it, but might be interesting to give a try?

Also interesting that Unity force you to restart the game/level when making a change. For our current (post-Amnesia) engine it has been a goal that it should always be possible to update everything without having to reload (not all things at possible of course, but a good deal is).

Regarding visual languages, I never thought about it that it might make the artistic process more simpler for you. The only visual scripting I have tried is what comes along with Star Craft, which is not really that visual (more like the branching dialog version of programming). I have always thought of them as something that simply was easier to learn for a non-tech person, and not as something that that actually allowed more artistic expression. Could you elaborate more on this?
Logged
Michaël Samyn

Posts: 2042



View Profile WWW
« Reply #2 on: October 05, 2011, 05:40:12 PM »

I don't like how Unreal brands everything made with its engine. But if it is a good authoring tool, I guess I should look it at.
Logged
Michaël Samyn

Posts: 2042



View Profile WWW
« Reply #3 on: October 05, 2011, 06:29:41 PM »

Regarding visual languages, I never thought about it that it might make the artistic process more simpler for you. (...) I have always thought of them as something that simply was easier to learn for a non-tech person, and not as something that that actually allowed more artistic expression. Could you elaborate more on this?

In my experience, visual programming languages are not easier to learn at all. If only because they are all so different (as opposed to scripting languages which resemble each other a lot). It takes me several months to get up to speed in a visual programming environment (as opposed to hours or maybe a few days with scripting) and even at optimal speed, I haven't found it to be faster than coding either (with the exception of math problems and debugging).

For me programming in code always feels like a rupture in the process. Playing a game and programming a game is something that I can do with the same parts of my brain, as it were. Both require aesthetic sensibility, pattern recognition, short-term logical thinking, holistic intuition, etc. Coding on the other hand requires an entirely different kind of concentration. Probably because it's language-based and leans towards  mathematics (if not in the actual algorithms then definitely in its syntax). Coding is more symbolic, more rational.

Visual programming constantly triggers my sense of aesthetics. Even if I'm constructing elaborate logic systems, I'm continuously aware of the visual presentation: I align the blocks, make sure that the lines that connect them are neat and straight: I make pretty visual compositions with the "code." It often feels to me as if a neat graph will also run better in the engine. Even if that is untrue, the kind of magic and superstition involved with such intuitions ensures that my mind remains in the artistic zone. You're constantly dealing with aesthetics, in the game that you're making as well as in the programming logic behind it.

If the visual programming language exposes everything (logic as well as assets), as Quest3D does, then the artist is stimulated to make connections between all those things. And this is exactly where games become interesting: when the appearance of the objects in the games are influenced by the behavior of the player, for instance, or when the sound is influenced by the state of the game, or the speed of an animation by the time of day, etc. It's all numbers, in the end, and a visual interface allows you to make calculations with all of them. This can lead to wonderful environments that feel much more alive than things that can only be built through careful and rational construction.


But a visual interface is only one part of the solution (and one that is now available in Unity too, thanks to Antares Universe and uScript). The other aspect is realtime programming: to be able to change something in the "code" and see the change immediately reflected in the game. This is extremely powerful as it puts programming closer to other artistic activities as drawing and painting and making music. Realtime editing allows for a direct connection between producing and experiencing: the two happen simultaneously.

Artistic creation gets more fluent this way: you do something and see its effect. If the editor works well, you can do this very quickly, even instantly. So if I want to, say, change the color of the light, I simply drag a slider until it is exactly correct. Done. Or if I want to make this color depend on the x position of the avatar, I connect the two values. If that looks weird, I can connect it to the speed of the wind instead. If that's too extreme, I just add another block that smoothes it out or inverts the value or something. All in realtime, directly in the code, and thus part of the game. When I'm done tweaking, the game is done. Such a process makes even concept art largely unnecessary: you just work directly in the game engine.


An important helpful aspect of visual programming that is sometimes overlooked is visual representation of the logic flow. In both Quest3D and Universe, the parts of the graph that are active are highlighted. This way you can know exactly what code is being executed at any given time. This is incredibly useful for finding bugs.


And finally: compiling. Compiling is evil. The requirement to compile code before you can see your work disrupts all artistic flow. This requirement pushes an artist to a behavior of constantly switching between the two. Because we need to see the result of every little tweak, you'll see us compiling after changing a single character. If this character is a value after the period in a float, you can imagine how frantic the back and forth can become. It's completely idiotic and soul-crushing. Even the minor time it takes Unity to compile scripts before running is too much (not to mention that it starts from the beginning of the level every time). Not only are we forced to speak like machines (to talk in code), but we're also forced to do the repetitive behavior of a machine (code/compile cycle + getting to the relevant point in the level over and over again).


I do think that visual programming needs to fit someone's mind. Some people -including many artists- are perfectly comfortable with the separation between creation and experience that script-based programming enforces. I guess they are more like engineers or architects, or like more classically inclined artists who would make many studies and an elaborate sketch before starting with a painting. But people who are more sense-oriented, more spontaneous in their art work, like more romantic painters, performers and musicians, perhaps, will do much better when programming in a realtime visual programming environment (sadly, of course, most people capable of building such a system with the tools currently available belong to the first category, which explains why this form of programming has been explored so little).
Logged
Thomas

Posts: 384



View Profile WWW
« Reply #4 on: October 05, 2011, 07:19:10 PM »

Thanks for the write-up! Interesting to hear your thoughts on this. Using your aesthetic sense when writing logic makes sense, especially when you can see the changes directly. Gonna have to try and add something simple for our more high level parts of the engine.

About compiling: Totally agree. For some reason it works pretty well when doing technical stuff. But for more artistic endeavours (example would be the insanity effects in Amnesia) it makes it really hard to accomplish anything. Guess it depends on the unclear goal creating art has. I am guessing it might be the same with visual programming and it is at its best when you are trying to do something where you are not sure of the outcome.
Logged
Kjell

Posts: 129


View Profile
« Reply #5 on: October 05, 2011, 08:43:23 PM »

I wholeheartedly agree with Michaël's sentiments. Compiler-free / real-time programming is the most important feature for any development environment ( for me at least ). Imagine having to wait for feedback on your input in Photoshop / Maya / Cubase Undecided
Logged
Michaël Samyn

Posts: 2042



View Profile WWW
« Reply #6 on: October 06, 2011, 09:56:42 AM »

Guess it depends on the unclear goal creating art has. I am guessing it might be the same with visual programming and it is at its best when you are trying to do something where you are not sure of the outcome.

Indeed. And it's not like you ever really know. You need to constantly check your own emotional response and tweak things until they feel right. It's virtually 100% intuitive. Direct response is essential to this.
Even if that direct response is somehow wrong: errors can be very inspiring.
Logged
Erik Svedäng

Posts: 194



View Profile WWW
« Reply #7 on: October 07, 2011, 04:02:27 PM »

I have felt a bit the same about Unity too... we work in a very divided way with long periods of agony when the art is to be imported into the project. It's not healthy. To be fair the Unity developers actually try to make some real-time editing possible from the inspector, but it's definitely not good enough (especially since the changes disappear when you turn off the game). Perhaps a bit embarrassingly, I have kinda accepted that that's how game development is though... this experience with a system as runtime-centric as Quest3D that you describe Michael is one that I've never had. I want to try it. It actually sounds a bit like the Smalltalk environment (called Squeak nowadays) which was developed to try out ideas regarding object oriented programming. It's a very different experience from programming c++ (which I guess "won" the battle).

I have also been thinking about this thing where it's hard to switch between different "modes"... more specifically artist vs. engineer. I don't know if it's age or what but it takes me days, maybe even weeks to do the switch and be able to focus completely on one side of things. Without the switch I just can't see the other side clearly. It's a confusing feeling, and difficult to pull off in a small team where you have to do very different things from day to day.
Logged
Kjell

Posts: 129


View Profile
« Reply #8 on: October 07, 2011, 04:58:02 PM »

ZGameEditor is a good example of a IDE that combines traditional coding with real-time feedback.

http://www.youtube.com/watch?v=NE59pMACiFQ

The code shown in the video should look very familiar to anybody who has worked with the OpenGL API.
Logged
Thomas

Posts: 384



View Profile WWW
« Reply #9 on: October 07, 2011, 05:20:50 PM »

Note sure if I have shown, but here are two videos that detail the basics of our new system:
http://www.youtube.com/watch?v=5OKFik2IEZU&hd=1
http://www.youtube.com/watch?v=UmQjO1C_Q90&hd=1

I still do not feel it is as fluent as I want it to be though. I guess a step further would be some kind of setup like ZGameEditor (that Kjell linked to). Now that I have coded a bit I still think there is a problem with structuring things though. Game logic often touch upon so many other pieces and I do not want to blunder in and just add stuff as the code might end up being too messy. What I do is to often sketch out from start and then clean up a little when I get something that I like.

I really feel what Erik describes though and that changing between doing tech stuff and art stuff is not always that easy. I think there is a certain focus one has when doing technical stuff that I do not really feel when for example painting, writing (or more related building a level). It just seems to me that the damn gameplay does not need to be all that technical, since it is not about figuring out algorithms, optimizing, etc.

Visual programming is one way to attack it, but perhaps one can do so with normal code too? As has become obvious too my, the problem is not really ease-of usage or speed, but rather that you want to have  nice feedback loop and not get stuck stuff that do not matter. Perhaps a good analogy is making a webpage in pure HTML (which I have done a lot in the past) VS using some visual editing tool. You are doing basically the same work, but the process is very different.

That said, I still think that the goal must not necassary be to skip code, but instead to provide a coding environment that is more "relaxing" and where you do not have to think so much about secondary issues (like orgainizing code in a good way). So having some kind of framework that takes care of this for you might be a big step. AN example here would be the IDE for making GUI in Visual Basic where a simple double click on a widget creates the bulk code for some type of action. One problem I have always had with that though is that once you need to go outside of this system (and write code directly) it can become really tiring as the code is in such a mess.

This came about a bit more rantish than I first thought, but summed up I looking for tricks to make the code even easier to write. If anybody has ideas on that it would be interesting to hear.
« Last Edit: October 07, 2011, 05:22:22 PM by Thomas » Logged
Kjell

Posts: 129


View Profile
« Reply #10 on: October 07, 2011, 06:31:04 PM »

The power of environments such as ZGameEditor is not just that you can change logic instantly, it's that you can create & modify & delete any resource ( scripts, meshes, textures, sounds, shaders etc. ) while your game is running. So in theory you could start a empty project, hit the play button, and then create a entire game without ever having to stop playback.
Logged
Michaël Samyn

Posts: 2042



View Profile WWW
« Reply #11 on: October 07, 2011, 08:09:44 PM »

Our friend Dave Griffiths has built a live-coding environment called Fluxus.
Logged
Michaël Samyn

Posts: 2042



View Profile WWW
« Reply #12 on: October 07, 2011, 08:11:49 PM »

Flexible code is probably a good intermediary solution for engineers to be more artistically creative. But to get the artists to program, we really need a visual interface. That's just how our brains work optimally.
Logged
Erik Svedäng

Posts: 194



View Profile WWW
« Reply #13 on: October 12, 2011, 08:09:40 PM »

this was neat: http://worrydream.com/LadderOfAbstraction/
Logged
Erik Svedäng

Posts: 194



View Profile WWW
« Reply #14 on: October 12, 2011, 08:48:10 PM »

I think there is a deeper problem with programming though, one that cannot be solved through visual interfaces alone. There seems to be a big group of people (50-60% of the population according to this paper http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf, though I can't judge how correct this is) that are not able to properly learn programming of any kind, simply because they don't understand the extreme brutality of it's logic. They would want to tell the computer what to do in natural language, as if it was a human.

I think that the kind of mental state that you put yourself into when programming leads to a de-humanization of the self (and the computer, obviously) which is very problematic for a person who wishes to explore the human condition ("create art"). It's a lot like thinking too much about the game mechanics when designing a game.

Also - although writing code (text) never feels like painting, for me it often feels like writing a book. I format things, move it around, make up good names for things, etc. In theory the logic that text equals engineering and visuals equals art is flawed, at least if you are OK with calling some books art.

In practice though I think that you're right Michael about a visual interface helping us to break away from some of the destructiveness of programming... not only because of it's aesthetics but also because it is simply easier on the brain and focuses less on small, irrelevant details. In the end it might be the best solution (except for having your personal code monkey that obeys your smallest whim and that you just talk to in your mother tongue).
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2006-2008, Simple Machines Valid XHTML 1.0! Valid CSS!