So, we’ve started evaluation of Lumberyard. One of the main questions that
came up was, why? What’s the game plan? Because Amazon have based this on an
engine notoriously difficult to use and feature incomplete compared to its competitors.
From initial evaluation, not much has changed…
Whilst it’s a perfect fit for the sort of commercial based games we do
(RPG’s, FPS’s), there has to be some concerns addressed before pursuing said
engine as a commercially viable option. As training / bug fixing / tool
implementation can be costly to us and take a while.
Ultimately what I’d like to know is, will Amazon give the time it needs for
the community to grow before pulling the plug? Also what is the overall goal
Personally, I’ve always envisioned an enticing engine to have the simplicity
of Unity, the toolsets of Unreal and the real time rendering prowess of
CryEngine. If that is the ultimate goal, where do I sign up? (That was a figure of speech, I know where to sign up :)).
In short, I want to make sure it’s a viable / reasonable plan to switch over if the engine direction is going down the right path.
The FAQ doesn’t quite cover it, although in the release statement they talk about simplifying workflow and making a better experience for all. Seems your priorities / responses and willing is in the right place and for me that counts more than the engine being the best on the market.
Appreciate it, also we are tracking bugs and discussing possible fixes / actual fixes for them. How would we go about submitting them to master branches?
Thank you @Chef_JC
see many people are coming to use this engine and many in doubt to use it or not, for example how is release schedules, time between developments RC 1, 2 … how fast is development and bug fixes? some even
have fear about license, many doubt about Community and Documentation (one of the biggest problem for now), how easy would be to use C++, like
be able to easily create part of the code and expand engine, or even some indie developer like to participate on bug fixes.
First off, I appreciate the feedback. I know the
choice of engine technology is one of the biggest decisions a developer can
make. Our Lumberyard plan is simple – start with customers and work with them
to build great game technology. We aspire to provide technology that handles
all the undifferentiated muck of game development, so your team can focus on
your gameplay and building and connecting your community. I believe games will
increasingly become more connected, and leverage the compute and storage of the
cloud in ways that we’re just beginning to see, and we’re building Lumberyard
with that future in mind.
We’re just getting started with
Lumberyard, and have hired a team of industry veterans that are really excited about listening to our
customers. If you haven’t already, you can read about the additions, updates, iteration improvements, and fixes we’ve made already in our release notes, and we have more on the way.
We’re investing heavily in Lumberyard and we’re in it for the long haul.
Thanks again for joining us here on our
Including most of the fourty something required libraries would be a fantastic way to start. Then maybe reducing the amount of libraries needed? Because frankly some of these just seem overly redundant. I can’t see the need for seven different versions of zlib.
Thanks for the reply, I guess it’s a case of lets see what happens then.