

Polycode – Open Source, cross-platform framework for games and interactive apps - ariejan
http://polycode.org

======
norswap
Looks slick.

But damn, this is how you build a product website.

~~~
tolmasky
Having a page that says "binaries coming soon" instead of a download is the
difference between me trying it today and forgetting about it for months.

------
drawkbox
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.

------
icemelt8
Please don't down vote me. But can I ask that in a world where Unity exists,
how is this relevant?

~~~
eropple
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.)

~~~
tolmasky
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...](http://docs.unity3d.com/Documentation/ScriptReference/Time-
smoothDeltaTime.html) "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.

~~~
zerr
Could you please point me to the resources documenting "doing everything in
code"?

For me, that tool based approach was a deal breaker, didn't care about it's
closed source...

------
spoiler
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_

------
gavanwoolery
cross platform c++, or just cross platform via LUA? I would imagine it would
need to be somewhat bulky (like QT) to support cross-platform C++.

------
ioquatix
Another one!?

Seriously, looks very interesting.

~~~
Total_Meltdown
I've actually been looking for something like this (specifically the 2D game
support in C++) for a long time. What other options are there?

~~~
samjohnson
You might be interested in Cinder. It's a mature C++ library with
multiplatform support: <http://libcinder.org/>

~~~
yeureka
Cinder is not written for performance. I use it just to open an window and get
a basic update/render loop. It is too slow to write games in.

[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.

------
davedx
Lots of inspiration from Unity there. Looks good!

------
rip747
why is it that i cannot find a link to the github repo?

~~~
virtualritz
Go to 'Download'. There is /only/ a link to the github repo.

~~~
avolcano
Oof. Those build steps seem a bit obtuse (as someone used to a
"brew/pip/gem/npm install"). Wonder why there are no binaries distributed?

~~~
eropple
_> 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.

------
camus
looks great !

