Because he's not ready for full release. He's working towards it though, but right now it is still effectively in development but not fully ready for release.
> Those build steps seem a bit obtuse (as someone used to a "brew/pip/gem/npm install").
They don't strike me as particularly obtuse. But I write a decent amount of C++ already, and I've come to terms with the reality that there is always some assembly required.
Binaries don't strike me as particularly useful for C++ projects. C projects, moreso, but with C++ you've got to support a number of different C++ runtimes per platform (the various MSVCRTs on Windows, libstdc++ and libc++ on OS X) and it's probably just better to have the user--who is going to be the one stuck with it--build it themselves.
I built it and it was dead easy just following the build instructions for Unix makefiles in the BUILT.txt (I'm on OS X but I never use XCode).
Although I don't get why they do not distribute a shell script wrapper for these build steps, they have no variables.
The build steps seem to miss the IDE though.
The part I was most interested in. I have postponed playing with Polycode until I get that to work on OS X.
That would be unfair for game devs who made it through and making money just using the free version. It does lack features vs Pro but it is still viable for a production release.
Yes, it is certainly viable and I don't mean to discount what Unity offers for free. However, IMO the restrictions matter as in, for instance, the free version does't come with pro's lighting and shadow etc. GAme devs do resort to small "hacks" to get around but it is a slight inconvenience at the least.
Unity is a great product for what it is, but it enforces upon you a particular view of the world and it's one I personally do not share. It puts you into its editor environment (which I don't find to be very good) and more or less expects you to be using the visual tools for most of what you're doing. I don't like that workflow; I prefer to work in a data-driven environment and in a real IDE. It is not as quick to prototype, but I enjoy it more and the end result satisfies me. I also prefer to know exactly what's going on in my game code, and there's enough obscuring that in Unity or another closed-source runtime that I'm not comfortable with it.
And I don't trust Unity not to close up shop one day and leave me high and dry with closed-source, bit-rotting libraries. Or to not target a platform I care about in the future, again leaving me screwed. I need to control the stack, and Unity is antithetical to this. (This is also why I have moved away from Xamarin's stuff--while enough of their stuff is open that I could spend multiple man-years re-implementing it if it went away tomorrow, it's a much better investment of my time to use the platform APIs directly.)
I was initially hesitant to use Unity or to give their workflow a chance, but now I have to admit I really love it. I use my own text editor vs. Monodevelop, and like a truly good visual editor, it really is just augmenting the code experience (you could do everything in code if you wanted). There really isn't that much magic going on.
That being said, I share many of your frustrations, but I think the root cause is that its closed source and not any particular design decision they made. At the end of the day the design is straight forward, but its hard to wrap your head around since you can't easily just look at the code and go "ah ok FixedUpdate gets called right after WhateverFunction, now this makes sense". This is severely exacerbated by bad documentation. Here is one of my favorite examples: http://docs.unity3d.com/Documentation/ScriptReference/Time-s... "Time.smoothedTime - A smoothed out Time.deltaTime (Read Only)." Great, no idea why I'd ever want this or what it actually does. In OS land I'd just go to the function, but not such option here.
On the other hand, I have considerable more faith in Unity than some OS tool to be around in the future and to support new platforms. They have a really great track record of this (they've been around forever), and the fact that they make money is more comforting to me than some random group of developers doing it for the love of programming. However, more tools is better, I'm in no way suggesting Polycode isn't cool or shouldn't exist or anything.
Moai [1] is very mature, used for a bunch of commercial games, broad support for Mac, Windows, iOS, Android, Chrome (via NaCL), with Linux support forthcoming. Scripted with Lua and/or used directly through C++. Open source.
Extremely clean api and C++ code. Code in C++ or Lua (http://polycode.org/features/). Editor base like Unity (albeit still just 2D support). Simplified interface and nice looking coding environment using powerful languages for gamedev. This is off to an excellent start.
Very Unity like look and feel but with the added open source and deeper C++ access that is still required in games. In Unity you can build plugins for each platform like I am sure you would need for extra libs here.
I really like this, but in absolute honesty, I am not the biggest Lua fan. I would prefer if it were Ruby or JavaScript, but I am guessing Ruby/JavaScript is a lot heavier (not counting in mruby) than Lua and hard to implement (well, implementing rbx would be very possible), but V8 would be easy to implement.
I did embed Ruby into C++ once, but it was rather clumsy and it would sometimes cause a segmentation fault (my C++ was beginner level at best then, so I just abandoned ship without trying to fix it, since I wouldn't know where to look). I wish someone smart does this successfully. Daydreams
39 comments
[ 3.1 ms ] story [ 97.3 ms ] threadThey don't strike me as particularly obtuse. But I write a decent amount of C++ already, and I've come to terms with the reality that there is always some assembly required.
Binaries don't strike me as particularly useful for C++ projects. C projects, moreso, but with C++ you've got to support a number of different C++ runtimes per platform (the various MSVCRTs on Windows, libstdc++ and libc++ on OS X) and it's probably just better to have the user--who is going to be the one stuck with it--build it themselves.
The build steps seem to miss the IDE though. The part I was most interested in. I have postponed playing with Polycode until I get that to work on OS X.
Either way, doesnt hurt to have competition :)
And I don't trust Unity not to close up shop one day and leave me high and dry with closed-source, bit-rotting libraries. Or to not target a platform I care about in the future, again leaving me screwed. I need to control the stack, and Unity is antithetical to this. (This is also why I have moved away from Xamarin's stuff--while enough of their stuff is open that I could spend multiple man-years re-implementing it if it went away tomorrow, it's a much better investment of my time to use the platform APIs directly.)
That being said, I share many of your frustrations, but I think the root cause is that its closed source and not any particular design decision they made. At the end of the day the design is straight forward, but its hard to wrap your head around since you can't easily just look at the code and go "ah ok FixedUpdate gets called right after WhateverFunction, now this makes sense". This is severely exacerbated by bad documentation. Here is one of my favorite examples: http://docs.unity3d.com/Documentation/ScriptReference/Time-s... "Time.smoothedTime - A smoothed out Time.deltaTime (Read Only)." Great, no idea why I'd ever want this or what it actually does. In OS land I'd just go to the function, but not such option here.
On the other hand, I have considerable more faith in Unity than some OS tool to be around in the future and to support new platforms. They have a really great track record of this (they've been around forever), and the fact that they make money is more comforting to me than some random group of developers doing it for the love of programming. However, more tools is better, I'm in no way suggesting Polycode isn't cool or shouldn't exist or anything.
For me, that tool based approach was a deal breaker, didn't care about it's closed source...
But damn, this is how you build a product website.
Seriously, looks very interesting.
[EDIT] I will actually have a go with polycode to see if it solves the issues I have now with some other projects. Looks good.
[1] http://getmoai.com/
Very Unity like look and feel but with the added open source and deeper C++ access that is still required in games. In Unity you can build plugins for each platform like I am sure you would need for extra libs here.
I did embed Ruby into C++ once, but it was rather clumsy and it would sometimes cause a segmentation fault (my C++ was beginner level at best then, so I just abandoned ship without trying to fix it, since I wouldn't know where to look). I wish someone smart does this successfully. Daydreams