Hacker News new | comments | show | ask | jobs | submit login
Godot Engine open sourced (godotengine.org)
341 points by beefsack 1402 days ago | hide | past | web | favorite | 111 comments



The site is totally hammered right now but I managed to grab a copy and get a feel for what's in this. There's some truly exciting stuff to comb through since it's a well-used engine with a lot of history, not someone's hobby hack.

What I've seen so far:

A custom scripting language(GDScript) which is roughly Python-esque. The wiki explains that after trying the other common choices(Lua, Squirrel, Angelscript) over a period of years, they rolled their own solution that could be more closely integrated to the engine.

An in-editor help, it has some API docs.

Classes for GUI controls, including layout containers.

A fairly rich audio API, including positional audio, streamed audio, common sample playback controls(pan, volume, pitch, looping), and some effects(reverb, chorus, frequency filter).

Some networking functionality, including HTTP, TCP, and UDP(unclear?) mechanisms.

Keyboard, joystick, mouse, and touchscreen input classes.

And of course lots of rendering and physics-related stuff, including various shapes, cameras, meshes, sprites, animation, tilemaps, texture atlasing, internationalized fonts, particle systems, and multiple viewports.


One specific reason why they rolled a custom scripting language is that they needed vector/matrix types (i.e. vector3f, etc) exposed to scripts, and adding those through an interface like cpython or lua's embedding api would have produced scripts that were incredibly slow at manipulating vectors. Presumably luajit might have fixed this, but I can understand that they didn't go that far.


Torch seems to be a concrete example of a numerically oriented luajit embedding that provides high performance linear algebra primitives. http://torch.ch/


Yeah.. luajit and its amazing ffi module to the rescue here..


AngelScript can use them directly, though. Perhaps it was too immature when they made the decision.


It looks pretty neat. I'm leery about their custom scripting language, but it at least sounds pretty bulletproofed. I'm interested in how much (if any) of the lower layers of their system are separated out from the higher ones; I'm more interested in how those layers could be used with my own engine than theirs itself.


I get frustrated with people who think they can and should rewrite the scripting language.

>I'm more interested in how those layers could be used with my own engine than theirs itself.

You and me both. Also looking at Proton [1] and Allegro [2] for similar reasons. And just came across a Blackberry-backed engine [3] which looks interesting (and also Lua-driven).

I actually have my OWN game engine (based on LuaJIT, thank you ;) that already targets Windows, Android, and iOS, but I'd like to rip out the platform layer and replace it with something that someone else is maintaining. I mean, it works now, but leveraging open source and other developers' efforts would be much better.

I've considered just using SDL 2.0 and calling it good, but I'm tempted to pick up some of the higher-level functionality some of these other engines offer.

None offer all the features I want, unfortunately. One of the big features they mostly miss is really good script/C++ cross-functionality. Aside from that, there are typically one or two other things that make me want to avoid them.

[1] http://www.rtsoft.com/wiki/doku.php?id=proton

[2] http://alleg.sourceforge.net/

[3] http://www.gameplay3d.org/


I get frustrated with people who think they can and should rewrite the scripting language.

I actually have my OWN game engine (based on LuaJIT, thank you ;)

This comment would be better if it wasn't snubbing everyone who dared try to shake up the status quo of programming languages. People two hundred years from now won't be using LuaJIT. Therefore why wait two hundred years to invent the future? We could have it within our lifetime, if we remain supportive.


If this comment were made about any other scripting language than LuaJIT, I'd be in agreement.

But LuaJIT is the future of scripting. It's truly a stunning achievement.


LuaJIT is superior to anything else I've been able to find, it blows me away. Though there can always be something better!

That being said, the "better" things I'm thinking about could be added to LuaJIT just as well as they could be to other scripting languages. For example, the LuaJIT compiler could try its best to auto-vectorize (really really hard) or could leverage the developer with SIMD-like vector operations that would adapt to whatever SSE/NEON/...-like instructions the target platform has. GCC/Clang already dod this to some extent with their vector extensions. Although for many instructions you still need to use specific intrinsics which are not cross-architecture compatible of course. The ones that are:

- add/subtract - mul/divide - shuffle

Which are already pretty important. One could argue over implementing some "generic" intrinsics and possibly emulating them on platforms that don't have it. But then one could be left scratching one's head when suddenly everything gets slow.... So I can understand the gcc/clang devs.


I and a colleague have been looking a little bit at using Nimrod [1] as a game language.

Nimrod is pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking like Python), and it's just amazingly fast, but not at the expense of ease of use.

What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer.

In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right.

[1] http://nimrod-lang.org


Very interesting. I'm currently still a bit enamored with Go as it allows me to be very productive and makes deployment, cross-compiling and concurrency such an absolute dream. The performance tradeoffs have been rather good to me I find, it's very speedy for the tasks I try to use it for (almost all of them web-based). But if Nimrod is better... well I can't be sad about that!


The foundation for SIMD vector operations has already been laid by Mike Pall, and his plan is to implement a pretty full API for supporting architectures. See:

http://lua-users.org/lists/lua-l/2012-02/msg00207.html

I think he's looking for a sponsorship to accelerate this feature[1], so if you know of someone who might be in a position to sponsor the feature, it's a very worthy project!

1. http://wiki.luajit.org/Open-Sponsorships#Vector/SIMD-Data-Ty...


I'm happy to see people do innovative things with programming languages.

But there are a lot of people doing that right now. I didn't get a vibe from this one that it could do anything interesting that you can't already do in either LuaJIT or Julia. Other innovative languages I've been tracking include Go, D, Nimrod and Dart.

The world is improved by innovations; it's not improved by script language proliferation, or "me too!" projects. Lua in particular is a very well documented language, and is the de facto standard in video game development. I think the bar has to be pretty high to justify creating a new language.

Yes it would be more fun than figuring out how to get 3d matrices to work and be fast in LuaJIT, if you don't already know how the FFI works. But there's a LOT of value in using LuaJIT, and unless you're bringing something else of value to the table, no, I don't think it's worthwhile backing Yet Another Language.

I know of at least a half dozen other engine-specific scripting languages, and I would wager NONE of them are as robust as Lua, as well known as Lua, as well defined as Lua, or even as well designed as Lua. The value of having a shared language does outweigh every new programmer's desire to write their own language.


I am no expert but, I'd retarget your platform specific stuff to SDL. AFAIK Emscripten has SDL1 support and SDL2 support is on the way. This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl. Most of your graphics primitives should already be targeting OpenGL ES 2.

http://www.infoq.com/news/2013/05/lua-vm-javascript

https://github.com/kripken/emscripten/issues/457

https://github.com/kripken/emscripten/wiki/Roadmap

Is your engine open source? I anticipate a JS backend to LuaJIT in the not-too-far future.


>Most of your graphics primitives should already be targeting OpenGL ES 2.

My engine had a chance to rot for a while; I'll be upgrading to GLES2 as soon as I'm developing on it again. (Pesky clients paying me to do other work has been slowing down development on my game and engine.)

That is one of my hesitations about Proton; they're still on GLES1.

>This would enable your engine to target HTML5 robustly with Emscripten via lua and sdl.

Not a bad thought. Hmm. Not a bad thought at all. In fact, part of the game I've been trying to work on involves an HTML component, and I've been planning to do it in JavaScript, but if I could do it in my own engine...wow. Thanks for rebooting my brain there. :)

>Is your engine open source?

Not yet. There are a (very few) parts that I don't want to publish, for reasons from "they're broken and I want to fix them first" to "this class prevents pirates from copying games in a novel way, and publishing it would just make it easier for them to pirate my games."


Maybe you could port your GLES1 to a compat layer like

http://www.jwz.org/blog/2012/06/i-have-ported-xscreensaver-t...

https://code.google.com/p/gles2-bc/

https://github.com/p3/regal

http://www.gamasutra.com/view/news/177233/Indepth_Bringing_R...

Depending on how difficult it is. Might be an interesting way to bring codebases that target OpenGL ES 1 onto WebGL


Thanks for the links!

My current code is pretty trivial; dropping in a pair of standard shaders and tweaking the code would probably be sufficient.

WebGL is interesting, but it only just got support in IE11 [1]. My only current project with a web requirement would need to support older browsers, including older mobile browsers, and Safari and Android browsers also lack support.

But it doesn't hurt to prepare for the future. :)

[1] http://caniuse.com/#feat=webgl


I'd be very surprised if you had a seriously novel method of avoiding piracy. I get the desire to do so, but realistically, not so much. (If only because they just have to find its code and nop it out.)


You can be surprised if you like. But it was novel enough to prevent my game from ever being pirated. [1]

>If only because they just have to find its code and nop it out.

If they changed a single byte in the executable, then none of the encrypted data files (i.e., the actual game) would load. I used a cryptographic key generated from the signature of the binary.

More than one byte would need to be changed. :)

I know I just raised the bar, but due to that feature and the additional obfuscation and misdirection I added, no one ever cracked it. I'm sure that the bar has been raised higher on commercial PC apps (self modifying anti-debugger code comes to mind), but what I did was at least novel on Android.

My technique was dead in the water on iOS, unfortunately; Apple mucks with the binary (encrypts it?) in the production version. But no one pirates on iOS anyway, right? ;)

[1] Successfully, I should say. Pirates thought they'd hacked the game and uploaded it all over the various pirate web sites multiple times. Thing is that the game always detected that it had been pirated, and as a result it downgraded to the "free demo" behavior, so people downloaded the same app they could have gotten for free from the store.


Why don't you make that a product? Esp the downgrade to demo, it is a great feature.

I am sure you could take the signature of the executable in memory and create a key from that for iOS? You just can't _write_ to executable memory but you can read it.


Allegro is pretty janky, in my experience. I haven't tried Proton, thanks for the pointer.

I use AngelScript, because the C++ interop is about as good as it gets. Chaiscript isn't bad, but its lack of coherent community scared me off.


Thanks for the Allegro thoughts; I'll just drop that one off my list. It was close to the edge anyway, since it seems to have only recent (beta-quality, untested) Android support.

I'm using Dub for my C++/Lua bindings, which provides exceptional C++ interop. Dub also is easily modified, and with my modifications I can have C++ objects referenced by smart pointers that are wrapped in Lua objects, and those objects can have additional Lua "tags" added to them that persist for the lifespan of the C++ object (even if all Lua instances of the object are collected).

You just can't beat LuaJIT for speed; speed isn't that important for scripting on desktops, but can be relevant on mobile. And it's hard to beat Lua syntax to enable non-programmer scripting options.


>I use AngelScript

Have you seen the LuaJIT FFI by the way? Very similar to what AngelScript offers. But it's also JIT-compiled by the best dynamic JIT compiler in existence. :)


I've done a little toying around with GamePlay3D, and I must say it's a nice engine, with a clean API and it's relatively easy to get started with it and get some results early on.

I'm actually rather disappointed almost nobody is using it. I hope it doesn't get canned.


I imagine it is related to Blackberry's current situation.


Perhaps, but the engine seems robust and well made, and is available with very permissive licensing and works on all major platforms. Should it really matter who the primary sponsor of the framework is?


Sometimes it does, because many just want to use the framework, not support it.


Did you have a look at urho3d ( http://urho3d.github.io/ )? (just curious)


Another interesting feature is the wide range of target platforms:

> One-Click deploy to several platforms, such as Windows, Linux, Mac, Android, iOS, BB10 and HTML5.


Godot! Just what I've been waiting for!


Haha.

http://en.wikipedia.org/wiki/Waiting_for_Godot

(P.S. not what, but who.)


More pedantically, shouldn't that be "just whom I've been waiting for"?


Edward Sapir says no ;-) In fact he devoted significant space in his 1912 book "Language" to the death of "whom."


Pff, descriptivists.


German maintains the difference (and a lot of other stuff), but yeah, as a substitute for the direct object it's pretty much dead. (Nobody says "Whom did that")


> Nobody says "Whom did that"

Also, nobody suggests doing so would be correct. In "who did that", "who" is the subject of "did" and takes the nominative case.


German still has a dative case. We lost our dative case in England around the time Middle English developed.


Yeah, but Whom is used in the indirect object case, as in "To whom does this belong"


Indirect object is similar to dative, sort of.

Seriously, most people would say "Who does this belong to?" We can argue whether it is good style or not, but descriptively it is standard grammar.


Googling "to whom it may concern" returns ~2050000 results, "to who it may concern" returns four time as less results (~479000).

You are not right.


> Googling "to whom it may concern" returns ~2050000 results, "to who it may concern" returns four time as less results (~479000).

"Four times as less" -> "four times fewer" or "one-fourth" ??


"To whom it may concern" is formulaic though, just like "Dear Mr. President."

Those are words used as they are, verbatem, in a specific context. They are thus ossified and preserved in a much more conservative state than the rest of the language.

It is not unreasonable to suppose that even as our language changes, that phrase will continue to remain intact in root and morphology even if the morphology disappears elsewhere.


Thank you! Your Sapir reference led me to Googling "sapir whom", which led me to http://www.bartleby.com/186/7.html. Paragraph 10 is where his "whom" discussion starts. Good reading.


Oh well! My humble self standeth corrected.

Anyway, we should not forget that Beckett wrote Godot in French, so the correct form is:

"Godot! Exactement celui que j'attendais!"


IMO if you're going to be that pedantic, it doesn't sound right to end on a preposition.


You're right, a preposition is never a good thing to end on. It's one of those rules that people seem to never abide by...


I just can't wait for Godot.


The problem with these things is, they show you screenshots of the types of games you can supposedly make, but that is literally nothing to do with the game engine itself. That's art assets, which are a whole other ball of wax.

Most of these games, the programming itself is trivial. If you can't hack it together in Java without a game engine, then you're not going to be able to hack it together in the game engine.

If you want to make casual indie games that look great, you need to be focusing on your artwork, and how to make artwork that works well in games.

And for the love of god, do not neglect sound until the last minute. Good sound in a game can be as complex to create and program as graphics. You absolutely must develop it in tandem with the rest of your program. We are so focused on visuals, but bad sound will ruin a game more certainly than bad visuals, just as bad sound will ruin a movie more certainly than bad camera work. Bad visuals could be a stylistic choice, but bad sound never is.


Any suggestions on where to start with the artwork for a complete newbie? I'm very interested in game programming but the artwork has somewhat discouraged me for quite a bit.


3D: get Blender and focus on learning it. Treat it like learning a programming language. You get out of it as much as you put in. The only reason people don't use Blender is because it's not 3DSMAX or Maya and that was what they used in college, so that is what they've spent the most time on. Blender is much better now than 10 years ago. It was garbage 10 years ago, but I've done real work in it and found it to be quite easy to use even 2 years ago.

2D: study cartooning. Buy a Wacom tablet. Suck it up and buy Photoshop and Illustrator.

Adobe Creative Cloud membership is $50/mo, which is basically the price of Photoshop alone in a year, but gets you access to everything.

Audio: I started using Audition because of the CC membership, and it's been great (I've also put together a few, simple videos with Premiere because of CC). I find Audition is actually kind of fun to use.

Get yourself a drum machine of some kind. I have one of the older Korg Kaossilators, a handheld device that runs on batteries. The new ones are even better. I plug the headphone jack into the microphone jack of my computer and I record directly into Audition. Making serviceable music for games is quite easy with it. Just remember that less is more when it comes to music, and don't be afraid to do non-traditional stuff, off beat, dissonant. It's easy to make and creates much more atmosphere.

Neither I was able to figure out on my own, but they were all quite easy to use after reading a few tutorials on them.

Just remember, treat it like programming. You're not going to get it overnight.


+1 Excellent suggestions. Thank you for taking the time to write this! :) I'll start with Blender and see where things go. Really appreciate it.


Oh, the documentation for Blender does suck, though. There are certain key UI features that were moved after the documentation was written. Your best bet is to get into an IRC channel or a forum.


You can easily make music in software. Download Cockos Reaper and add some free VST synths. Its MIDI editing features aren't superb, but they'll do the job.


You should take a look at Unity. There is a wealth of assets available for free or astoundingly cheap on their store.



Just playing around with this.... cross platform, doesn't try and be a "no programming required" environment, GDScript looks good enough. Whole env is intuitive. The live docs are decent. A couple of minutes in and I'm already making something. This is pretty damned cool!


Impressive! I didn't know Godot. I just downloaded for Ubuntu and it works 100%, this is really awesome.


Multi-platform including Linux, pretty impressive for sure, I'll check this out for fun.


Just curious, does anyone have any recommendations for something similar, but Javascript/HTML5 based?

What would the framework of choice be for a browser-based multiplayer game?


Phaser, which uses the really awesome pixi.js rendering engine, can read in files from Tiled, the map editor, and Spine animations. No 3d really as such but pixi.js does have a webgl renderer that lets you add in glsl "filters" and has some built in.


I'm also curious about this. Ideally I'd like to find an engine which allows to develop a game in browser and then port it into a mobile app. I found this link through Google which lists available JS/HTML5 engines: [https://github.com/bebraw/jswiki/wiki/Game-Engines]. It'd be great if anybody can make recommendations out of their experience.


You might want to take a look at our company PlayCanvas[1]

We've got the game-building stuff covered, with Javascript engine and designer tools.

And a few of our users are pushing the multiplayer part of it e.g.

http://apps.playcanvas.com/playcanvas/scifi/latest

http://boxes.moka.co/

[1]http://playcanvas.com/


It's not there yet, but we're working hard to make it happen at gootechnologies.com. Main focus is 3D games for now, but we're going to attack 2d in early summer.

Right now you can prepare your scenes and do some basic interaction, but to make a full game you'd export the scenes and code javascript directly against our goo engine.

It's still in private beta, but if you PM I might be able to speed things up.


I don't actually have any experience with it, but Monkey X looks like a nice way of creating HTML5 games (and cross platform) quickly: http://www.monkeycoder.co.nz/

The guy who coded it wrote the language I first learned to programme on (Blitz Basic, back on the Amiga in 1992 or so).

Has support for most things you'll want (3D, input, sound etc).


Here's a similar project. http://polycode.org/ It's still under development but it's ready enough to start playing around with it.


Polycode looks a little quiet, which is disappointing, it looks really nice.


The screenrewrite branch has commits from 5 hours ago, so it's not really quite in my opinion.


It's definitely alive, but my second-hand observation through seeing a friend attempt to use it for years, and even submitting numerous patches, is that it's in perpetual churn and still is only really usable for its lead maintainer.

Said friend went back to the homegrown engine and is much happier.


Where are you looking? I see "ivansafrin authored 6 months ago"

edit: just realised you were talking about one of the branches, attention to detail fail


This looks awesome!

Sorry to go off on a tangent. I've only been into (indie) game development for the last year or so (blog: http://www.ckcopprell.com).

It looks to me like game development has lagged behind web development by decade or so in terms of the democratization of tools. Free (as in beer) and open source game development software have grown by leaps and bounds over the last few years. Unity, GameMaker, Unreal/UDK, Anarchy, many many others have become both viable and available.

In the 90's and early naughts, did web developers regularly write their own servers, templating engines, databases, and all else that goes into web development? Didn't game developers more-or-less have to write the whole thing from scratch or license an expensive engine?

These are not rhetorical questions. I'd love to hear the perspective of someone more knowledgeable than me.


Web development has stayed pretty democratic since the early days because there is a small number of people pushing technological boundaries while the vast majority work in a well understood space.

Game development has consistently been the opposite: in a race to better graphics, better physics, bigger and better everything, game complexity has only gone up. Companies are working with tech that is not open to access by "mere mortals" because they are often proprietary hardware from Microsoft/Sony/AMD/nVidia. As a result of the technological arms race, there is a LOT of platform fragmentation in the graphics world.

So the problem is that game development is consistently a "big team" task, and industry expertise is monopolized by companies. Tech trickles down very slowly to hobbyists, so while there are engines for the rest of us to use, they don't benefit from the kind of industry battle-testing that web technologies get.

Game engines like Unity and Godot seem to be changing this a little bit by simplifying game development - standardizing complexity by abstracting away low level optimization concerns that you'd really only care about when you need to push technological boundaries. But in general the concept of "convention over configuration" and its related ideas hasn't really caught on, so there isn't even a standard way of thinking about game engines.

The last thing to consider is how much more complex games are than web. Web is mostly a mixture of 2-D graphics and user input handling code. Games are often 3-D graphics (3-D is just much harder than 2-D), often have more algorithmically complex input problems, require audio, and sometimes require real-time networking for multiplayer (web can tolerate latency better). There's just a lot more in there.

Another problem: because of performance requirements, the vast majority of the core libraries for physics, graphics, etc. are written in C++. C++ is not easy to pick up.


Looks great! What are the benefits of using this over something like Unity?

EDIT: Sorry if this sounded sarcastic. I was genuinely curious. Always happy to see a new engine out in the open!


Lets see:

- you are not stuck with .NET 3.5

- you can use Linux as your development environment

- you have the full package, instead of the various SKUs

On the other hand, if you have Unity experience, it is a plus in the industry.


> Looks great! What are the benefits of using this over something like Unity?

For my industry (gambling) Unity costs $200K/title. Price gouging IMO but it's their business to charge what they like.


I had a look at https://store.unity3d.com/products/pricing and I don't understand how it can cost you $200K per title.


The page doesn't disclose the price of the license for gambling. It says to contact them down at the bottom of the page. "Other Unity licenses available."


Ah, thanks. I didn't see that. It's crazy that they can charge that much though just because it's used in gambling. I mean, the software is the same, right?


No black box? Ability to actually debug problems and change the source when you need? Lack of licensing fees (to support all platforms)?


Puts on Richard Stallman cap

Freedom.


Nope. Not GPL-licensed.


MIT License is GPL-compatible.


Cue the BSD vs MIT license flame wars over whether the BSD license is free enough or whether one needs the sublicense right grant in the MIT license to achieve full freedom ;-)


I consider the MIT license to be freer than the GPL. Nonetheless, you can fork it and slap the GPL license on it if that lets you sleep at night.


and here we go..




Their site could maybe use some WP Super Cache :p http://wordpress.org/plugins/wp-super-cache/

This looks amazing!



I've seen that the editor only runs on OpenGL 2.1 supported platforms, but can it compile games for OpenGLES platforms?


Looks that way. There are iOS, Android and BB10 targets in the "platform" directory:

https://github.com/okamstudio/godot/tree/master/platform


Thank you.

Very impressive project. I looked at the code in core folder and it looks very clean and there are is a lot of good stuff in there.


Has anybody managed to run it on linux? I must be missing something obvious, but I don't know what to do once I downloaded it. Running `upx -d godot_x11.64` as mentioned on the download page doesn't do anything.


I had no problems. the upx command is only decompressing it. you'd have to do: `chmod a+x godot_x11.64` then you can run it with ` ./godot_x11.64`


For those who want to use Sublime Text as the external text editor: https://github.com/beefsack/GDScript-sublime


I have never done game programming. Can anyone recommend whether it is easier to pick this up compared to Unity? Also, isn't Unity expensive [edit: for a newbie]?


http://answers.unity3d.com/questions/7720/is-unity-really-fr...

> Unity Free is free for any individual to use

Feature comparison: http://unity3d.com/unity/licenses


+1 Superb! I was not aware of this at all! Thank you so much.


Let me Google this for you: https://store.unity3d.com/


Sorry! Made an edit to my post. I wanted to ask if there was a cheaper way to learn game programming than investing so much in Unity upfront. Thanks for the pointers anyways.


Downloaded and giving it a try! Amazed that its under 10mb!


Is there any IRC channel for this project?


Wow this engine is really amazing... Need to start stressing it out to se What's its made of...

Congrats


Look quite nice. I will surely give it a try.


This looks like a solid product but any reason I should give up my unity3d? It does look much easier to pick up than unity but I wonder what are the benefits of this.

Also, if someone knows where I can find some free assets I can use. I thought of ripping game sprites from old ROM games but stopped at the thought of hypothetical lawyers rising from the dead.




Note to self: Do an Ask HN about open art assets for games sometime in the future


Undead lawyers raising from graves to once again protect the IP they were once working on... I'd like to play that game :)


What I like about Unity is I can write in what is basically JavaScript.

I've not yet tried Godot but I jumped into useful results with Unity following a basic tutorial. I'm impressed by what Unity gives you right out of the box.


You mean UnityScript. It's not JavaScript!

  Though many in the Unity development community (and even
  in the Unity corporation) refer to UnityScript and 
  JavaScript as if they were equivalent or interchangeable, 
  the two are very different languages. Though they 
  resemble each other syntactically, they have very 
  different semantics.
http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScr...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: