57.10 Acceptable Use; Safety-Critical Systems. Your use of the Lumberyard Materials must comply with the AWS Acceptable Use Policy. The Lumberyard Materials are not intended for use with life-critical or safety-critical systems, such as use in operation of medical equipment, automated transportation systems, autonomous vehicles, aircraft or air traffic control, nuclear facilities, manned spacecraft, or military use in connection with live combat. However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.
Not just lawyers. Someone in charge must have authorized that. Which is, frankly speaking, amazing! Too many companies are too serious for their own good, it's a refreshing change.
Just curious - why am I suddenly seeing so many people referencing occam's razor? It is happening way too frequently to be a coincidence. Was the idea featured someplace recently? It seems like just about every tech-ish thread on reddit and HN has one "Occam's Razor" dude for the last couple weeks.
Certain types of safety-critical systems are regulated with liabilities coming in. They have to be built in a rigorous way to show the developer attempted to counter some amount and types of risk. There's a niche market that uses tech like OpenGL to build GUI's and simulators for safety-critical systems. I think this clause is a smart dodge of unknown risks rather than a joke.
Digging into the details, it seems this is largely a fork or adaption of the CryEngine, with all the advantages and disadvantages that brings.
As I said about Autodesk's offering, Stingray, I think that even a giant like Amazon is going to have an uphill battle bringing a new game engine into mass use. Having been testing game engines just this week, I'm reminded just how much of an ecosystem has built up around Unity in particular - displacing an engine with that is like displacing Wordpress as the dominant blogging engine.
It's early days yet but they've got some serious catching up to do. For example, it appears that 3D assets can only currently be created in Max and Maya (no Blender, no Cinema4d), as rather than using FBX or similar as an interchange format they're using their own custom formats with an exporter. Most other game engines stopped doing that a while ago, for good reason.
Likewise, the level editor is either underdocumented or feature-light. The docs currently just cover creating terrain and vegetation. I assume that the engine has the capability to handle non-outdoor scenes too, but it's not explicitly documented anywhere I can find in a quick look.
There's also no documentation on non-sky lighting, lighting builds, light types, or similar that I can find. There's one mention that the engine supports Global Illumination, but no details as to whether it's realtime or requires a bake process. Searching for "lighting", "lights", or "light" in the documentation returns no results!
Interestingly, there's a full-featured cinematics system, which means it's of considerable interest to me, but that's very much a minority thing.
I wish them luck and I'll certainly be checking it out, having said all that. Another fully open-source 3D engine is no bad thing.
> No. We make the source code available to enable you to fully customize your game, but your rights are limited by the Lumberyard Service Terms. For example, you may not publicly release the Lumberyard engine source code, or use it to release your own game engine.
That's a contradiction "FOSS" encompasses the software which meets the (nearly-equivalent in practical application) FSF Free Software definition and/or OSI Open Source definition.
If it is open source software (which this is emphatically and expressly not), it is FOSS.
Software can be commercial and open source meaning you can read the code but you have to purchase a licence to make copies and/or use it - that's open source but not Free[-Gratis] Open Source Software (FOSS).
Although FOSS has a broad definition[1], most technical people refer to Free Software by the GNU interpretation, in which the Free in FOSS is "Free as in Freedom, not Free as in Beer". FOSS is generally considered a subset of Open Source software.
You can charge as much as you like for FOSS[2].
Open Source is not the same as Source Available[3].
"Open source" generally means not only can you get the source code, but you can use it freely and make your modifications available to others. There's some wiggle room for exactly what qualifies there, but Amazon's terms are pretty far from any gray areas.
So this was the secret deal which, according to rumors, saved Crytek. This is the second fork of the CryEngine that I know of (other is the Farcry fork of Ubisoft), and I find it interesting that they keep forking it instead of offering a library designed to work with it. I wonder if it says something about the codebase.
Another major engine fork is for Star Citizen / Squadron 42.
They've hired several ex-Crytek engineers at the Foundry 42 office in Frankfurt, and among other changes have modified the engine to support a 64 bit data in coordinate system and rendering, multithreaded physics, and independent physics grids for inside the larger ships while they're moving around. Probably other things, but those are the main ones.
This sort of thing is actually pretty common in games; you end up doing some engine customization to fit your needs, and eventually you have to say "We've diverged too far to try and keep following the main updates anymore," and you stick with a customized version of an old release.
Nearly every AAA game is going to fit into that pattern, it's just that the 64 bit coordinates overhaul in Star Citizen is probably a larger and lower level architectural change than what most things bother with.
I don't think we're done making game engines. We're not done making blogging engines. Wordpress may be one of the largest incumbents but it's not the dominant platform and there are plenty of competing alternatives along every axis. Unity may be one of the current incumbents but it's not the best engine and won't be the last.
More competition is good. It means Unity won't be able to stand still and we'll get to see more features and interesting ideas. Cloud + Twitch integration? Pretty cool!
Oh, definitely not. We aren't at The Last Game Engine by a long way - but currently it's an uphill battle to introduce a new one, and I'm dubious this engine is differentiated enough to succeed.
There might be a lot of competing blogging engines, but there's only really about 3 that have any significant market share, and you can explain why each of them are has at least one radically superior feature to Wordpress in about a sentence and a half.
They do seem to have some Alembic support: they ship the libraries as part of the engine download, in their 3rdParty folder.
Alembic is an open 3D file format supported by pretty much all the major 3D modellers these days - including Blender, Modo, Houdini, Cinema4D and plenty of others besides the Autodesk tools.
Neither Unity nor Unreal currently support Alembic - this is the first indication I've had that the Amazon engine might have some features the others don't.
I've never been able to get Assimp to successfully load anything other than .obj format models, despite what they claim in their docs. Last time I tried was about two years ago though, so maybe it's improved since then.
I've used the .NET wrapper to load up quite a few different model formats. Sometimes it takes a little fiddling to get the right set of flags, because it seems like every model is setup just a little differently...
Yea, which is a shame for them, as lots of the smaller shops starting out and actually deciding which game engine to use are likely to be starting with something like Blender. I don't even think 3DS Max exists anymore? Isn't it just Maya now?
3DS Max definitely exists. Autodesk is still supporting them, and not as a 'oh this is just an auxiliary side project'. The breakdown (oversimplified) is Maya is more for complicated models used in animation/CGI (MEL scripting is their 'killer' tool that puts it ahead of Max), while things like architectural and game models are mostly done in 3DS Max (but theres a lot of overlay between the two, i.e., I've seen tons of work done in game modelling on Maya LT).
Speaking of which, Maya LT is not that badly priced for what you get - I have no animation ability but I've seen my friends do some incredible things with it. If you're artistically inclined, have a play. Regardless, the lack of Blender support makes me sad.
All game studios I have worked at have used Maya. I do know of some that use Max but it's definitely not the case that Maya is only used outside of games.
As a side note, Maya added Python as a scripting language a while back. You can also write plugins in C++, which can be a nice way to write custom exporter code sharing engine code files for file formats and such.
3dsmax definitely still exist, although I wish Autodesk learned cloud pricing from Adobe because 240€ a month just for 3dsmax is way way too much, especially compared with Creative Cloud which is barely 60€ yet contains almost all their softwares.
Also note that you can not use other cloud platforms for your games backend. While I understand their position, I consider that a deal breaker.
Q. Can my game use an alternate web service instead of AWS?
No. If your game servers use a non-AWS alternate web service,
we obviously don’t make any money, and it’s more difficult for
us to support future development of Lumberyard. By “alternate
web service” we mean any non-AWS web service that is similar
to or can act as a replacement for Amazon EC2, Amazon Lambda,
Amazon DynamoDB, Amazon RDS, Amazon S3, Amazon EBS, Amazon EC2
Container Service, or Amazon GameLift. You can use hardware you
own and operate for your game servers.
Q. Is it okay for me to use my own servers?
Yes. You can use hardware you own and operate for your game.
That seems pretty crazy to me. I get that they're using this as a loss leader to promote their services, but it seems to me that they'd do much better if they just made it work great with AWS such that it was the natural choice. If you integrate AWS heavily then people will pick it anyway, but if they think it's their own decision they'll be a lot happier with it.
Definitely agree. You'd be at the mercy of Amazon's AWS pricing for the whole lifecycle of your game. Let's say they suddenly increase the price tenfold... you either shut off your multiplayer (not an option for some games), host it all yourself (which would mean buying servers, paying people to maintain them, changing the game to use a new backend, etc.), or switch to another engine (essentially, recreate your game from scratch)
You have to weigh these risks against the likelihood of them actually happening. If AWS made a first-ever price increase, yes, you'd then have to consider whether you could beat that pricing by doing it in-house but you have to balance that against the very low odds of it actually happening and the up-front costs of hiring a ton of staff (e.g. just having 24x7 support requires something like 5 people when you factor in leave, vacations, etc.), buying or renting a lot of hardware, developing and getting operational confidence in a complicated software stack, etc.
That's a LOT of money to spend up front on a gamble that something which has never happened before occurs with so little notice that you wouldn't be able migrate away first. It's hard to see anyone but the major players having enough economy of scale to see positive returns on that investment, much less having enough budget room to where that makes sense rather than spending the same amount of money on something which users actually see.
That gets to the other reason why this is so unlikely: raising prices in a predatory manner would be a loud message to every AWS customer to find alternatives. Since AWS generates something like 7-8 billion dollars a year that's an enormous amount of money to risk — far greater than any short-term return they'd see.
But they do lock themselves up all the time, on console deals, on cloud platforms (Azure for Xbox, anyone). Isn't this something a proper contract would solve? We are talking about an AAA studio after all.
Exactly. When people see "free, with source code included", they may tend to think that it is open-source. I hope this answer from their FAQ section clears it:
Q. Is Lumberyard “open source”?
No. We make the source code available to enable
you to fully customize your game, but your rights
are limited by the Lumberyard Service Terms. For
example, you may not publicly release the
Lumberyard engine source code, or use it to
release your own game engine.
57.6 Registration; Release. Before distributing your
Lumberyard Project to End Users, you must register it at
aws.amazon.com/lumberyard/registration. You must obtain our
prior written consent if the initial public or commercial
release of your Lumberyard Project is based on a version of
the Lumberyard Materials more than 5 years old.
Updates would clearly not be an "initial public or commercial release of your Lumberyard Project".
It's about the first version, you just can't sit on your project forever and still use an old version of the engine when you finally go public. I see no harm in that clause.
This is probably a way to limit supporting legacy versions of AWS as they anticipate the service will evolve over time. It also means that any game based on Lumberyard might not work past 5 years without continued developer updates.
Doesn't being called that require that there are AAA games developed with it? According to wikipedia,
"In the video game industry, AAA (pronounced "triple A") or Triple-A is a classification term used for games with the highest development budgets and levels of promotion or the highest ratings by a consensus of professional reviewers."
So if it's an engine for games with highest development budgets, why would they care about the engine being free? Clearly choosing a free engine is a cost-saving measure, at which point you're no longer making an AAA game by definition.
> Doesn't being called that require that there are AAA games developed with it
Lumberyard looks like it's mostly CryEngine plus extras, and CryEngine has been used for a number of "triple A" games for a decade now. (including recent titles like Crysis 3, Ryse: Son of Rome, Star Citizen, Evolve, Homefront, State of Decay, etc).
> choosing a free engine is a cost-saving measure, at which point you're no longer making an AAA game by definition
Not necessarily. 2 of the most popular game engines, Unreal Engine and Unity3d, have very good free offerings now and many AAA games have been made with them.
You can have multi-million dollar development budgets and only be using "free" engines without issue nowadays.
Except that, at that level, it is no longer 'free'. Unity will likely be the Pro version (still peanuts). Unreal will also get a chunk of the pie. It's only free up to a point, which is reasonable.
They mean the engine is capable of powering AAA titles (and it is, because it's CryEngine at heart). So users get that level of utility from something that doesn't cost anything.
I would understand "AAA game engine" as merely meaning that it is suitable for making AAA games. I don't see why that phrasing would require an existing AAA game developed with it, unless you require an existence proof of its capabilities before you believe it.
Devils advocate: An argument could me made that this is a AAA grade engine, referring to it's capabilities not customers. Much like the US Army doesn't necessarily buy all clothing labeled 'Military Spec' or 'Tactical' etc
"Tactical" label is mostly empty fluff, "milspec" means it meets a published military specification -- which, absent specifying which specification, is also fluff.
So, if the point of your analogy is that this use of the AAA label is empty fluff, then, mission accomplished.
Royalty based models are quickly becoming the norm for even AAA engines. Source 2, Unity, Unreal, and now this version of crytek utilize this model. This pretty much means that the top 4 game engines now have a "free" option.
It's describing the engine and the games that have been produced with it, not necessarily the games that will be created with it in the future. Crysis 3 was definitely a AAA game.
If they were just interested in getting developers, to use their cloud services. Wouldn't they simply release plugins for all major engines? And wouldn't Unreal and Unity be much more interesting targets (based on their usage in the industry), than CryEngine?
Business. Amazon re-invests almost all their profits in itself(Wall Street hates this a lot). Getting a sweetheart deal from a company about to go under to fill a gap in their software technology to grow out their game section was probably too hard to resist.
Doesn't look like it at the moment, though I imagine the .Net SDK will have support sooner rather than later. Hopefully they'll wrap GameLift into the unity sdk shortly thereafter, but to be honest I don't know where the difficulty lies in just using the regular .Net SDK.
I got pretty excited and rushed through the article trying to clarify what engine and language it is based on.
Got a little bleak when I saw CryEngine and C++. As someone who uses C# and Java it's becoming pretty clear I need to start learning C++ if I want to explore game dev.
I realize Unity uses C# but when I compare UE, Unity and CryEngine it really feels like Unity still has a long way to go. The features you get out the box with UE for example are far superior to Unity.
Anyway, I just went off topic. It looks like an interesting option for developing multiplayer focused games.
Trust me when I say they all lack a fully polished end to end solution when it comes to authoring modern games.
Depending on the graphical fidelity you're chasing Unity is probably the most polished of the 3 majors.
UE4 is a great tool but has a slower development cycle.
CryEngine is almost broken unless you're willing to do a deep dive in the source.
If by "explore game dev" you mean, "make games" Unity or UE4 will serve you well. UE4 has a nexus of great artists using the tool so recruiting artists that are familiar with the toolset is easier. Unity is some multiple of more productive, pending your skill level with C#.
I've evaluated all 3, am a proficient programmer in C++ and C#(among others), and have shipped several games with Unity. I've also worked on a couple of shipped titles with UE4.(nothing major)
UE4's editor is also filled with bugs and inconveniences, and tooling and documentation for programming outside of Blueprints is haphazard at best. Crossing the C++/Blueprint boundary can be a pain, especially with interfaces. And the 2D support pales in comparison to Unity's.
On the other hand, Blueprints and the node-based material editor are really nice for quickly snapping content together.
Depends on what you mean by "exploring game dev". I would say Unity is pretty perfect for that and you have a lot to learn before you will reach its limits, if ever. After all, some of the best and most successful games are made with Unity. If you want maximum eyecandy, then UE or CryEngine might make more sense, but even there Unity in its latest version is not that far off.
I just recall doing things like setting up path finding and AI was much easier in UE and setting up player characters etc was all already built into UE templates.
The whole UE IDE or workflow also just made more sense to me, and was more polished. Maybe I just didn't give Unity enough of a chance.
Five years ago using C# for a serious game would get you laughed at. But every day the balance shifts: computers get faster, but developers don't get smarter, so a language that sacrifices performance for ease of development becomes a better choice. If you're looking to the future I'd recommend sticking with C#.
isnt the main problem with C#, Java and similars the garbage collector? which can at its worst kick in while you're in the middle of a fight or something. Even if its just 20ms, in a online FPS it potentially makes the difference between winning and loosing it.
edit: I am a Java guy myself, and would like to do some amateur gamedev in that direction (online FPS), but im worried about above mentioned point.
True as far as it goes. Modern GC can mostly be done concurrently (it's only heap compaction that requires stopping the world). Fully pauseless GC is very much possible (see e.g. Azul C4), as are e.g. architectures involving multiple short-lived processes with individual heaps. Even without that, it's often possible to do a relatively small amount of manual work to do the things that require pausing only at appropriate times.
C4 is absolutely a production product. It's used in systems that insane amounts of money depend on. As for the manual approach, I've seen it work in production.
Could you link to the feature you're talking about? Unity uses a relatively ancient version of Mono IIRC, so it's unlikely that the feature is available in Unity unless your definition of "modern C#" is "after generics were added".
> If you're looking to the future I'd recommend sticking with C#.
Not really. If you look to the future, I'd recommend Rust for making game engines. They by nature should be latency sensitive, and any kind of non deterministic behavior caused by garbage collector is really unacceptable.
Yeah, especially when you consider Carmack basically volunteered to rewrite Minecraft in C++ for Microsoft (and VR use). I'm not a game developer so I have no idea if C++ is as widespread as it seems but to me that's a pretty big indication.
The rewrite had already taken place (the pocket version of Minecraft).
He "just" tweaked the graphics pipeline to minimize latency using techniques such as asynchronous timewarp, optimize framerate and add the other VR related stuff.
I spent some time going through tutorials for different game engines, UE, Unity, Chaos and researching others, it became pretty clear that C++ the most pervasive and valuable across them, which is probably obvious to some of the more involved players in that space.
I think it's become something of a chicken and egg problem. All the hard-core game developers moved up from assembly to C, then introduced bits of C++ in the late 90s. All the books and tutorials end up getting written in C++ (or C with classes...). APIs get written in C/C++. More people learn C++ because its what the game devs do, and it's harder to find resources on learning how to do it in any other language. It's usually possible to make a wrapper for C++ code in a managed language, but it's not easy, if somebody else hasn't made a good binding already.
Garbage-collection has a bad name for some reason in game-dev circles, which maybe makes sense if you're developing a fast-twitch action game or shooter - a GC pause might drop enough frames to matter there, but for most games, Java or C# should be fine.
The console manufacturers have typically provided a C/C++ compiler and nothing else, so it was very difficult in the past to use any other language for developing console games. Some studios did retarget existing compilers like gcc but it was pretty rare; you don't usually have the time for that! If you're doing cross-platform that then limits your code base, so you can't even use the latest features of a language on one platform but not another (e.g. some platforms don't support C++11 in their compiler).
"if you're developing a fast-twitch action game or shooter - a GC pause might drop enough frames to matter there, but for most games, Java or C# should be fine."
Are most games adventure, puzzle solving, or turn-based?
Well, yes, the idea that there will be GC pauses and you just cannot get a _consistent_ framerate no matter how hard you try does not sound good. (Disclaimer I currently write games with Unity ;D)
That and to get people into their ecosystem. Make a game that runs on their firestick and a user might stick around to use Amazon Prime and rent a movie or something.
That seems like a bit of a stretch. CryEngine isn't going to run on a Firestick or a cheap tablet, it's a full-on game engine meant for desktop computers or consoles, not mobile gaming.
As far as I know Amazon are going to start making their own games as well. Makes sense to use their own engine so they don't have to share any profits.
Some interesting legal stuff with this engine, which their FAQ(1) goes over.
Basically, use it for whatever, free of charge, but not with any other cloud services that mimic amazon's services(2).
Except cloud services for some things, which are fine:
Your game may read and write data to platform services and public
third-party game services for player save state, identity, social
graph, matchmaking, chat, notifications, achievements, leaderboards,
advertising, player acquisition, in-game purchasing, analytics,
and crash reporting.
Is it a game changer?
Hard to say, but like they say, you can't beat free.
If nothing else, a lot of people are going to download this and have a look at it and mess around with it.
Also: You can use hardware you own and operate for your game servers.
So, it's a fair deal. You can use your own servers and not AWS for anything, but you can't use other web services which are competing with AWS. You can also modify source code as you see fit, but not distribute it. That's about it. Can't complain.
My guess is Amazon plans to use this engine for their in-development AAA PC game [1][2] announced last year. Usually the engine spin-off happens after the game itself is released, so I wonder what their motivations are for promoting the standalone engine so soon.
I'm pretty wowed.The quality of code that's being opensourced lately really seems to be ticking up. I didn't take the time to play with it so I'll be interested to hear the first reactions but it certainly looks pretty good in the screenshots. And integration directly into AWS could really streamline a lot of the difficulty of making online multiplayer games. I suspect this will put a new class of games in reach for indie development which is going to be really cool.
Extended support until 2020 though. :) Personally I have no need for Windows 10 on anything I own or use, maybe MS will offer something better by 2020.
Sure it can't be redistributed, but if it could wouldn't someone just repackage it and make it such that you didn't have to use AWS for the servers? Their goal is to make game devs go to AWS, so this makes sense to me
What is this auto-scaling back end system about? How does it work? Does it just launch more nodes in a cluster or does it actually expand the VM that you are running in like expanding an OVZ container.
AWS autoscaling is service that can be used to scale applications based on different metrics, one being CPU load and another is ELB traffic. I'm sure there is probably more options but the idea is it scales up and down depending on the policies put in place. It'll launch either VMs or containers, which is really how you design the autoscaling configuration.
The thing I find weird about this is how Lumberjack is not compatible with any of Amazon's own devices. I would have expected their engine to support Fire tablets and Fire TV, at least.
On the main page Lumberyard is described as a 3D game engine, which is the case because it's based off of the 3D CryEngine game engine.
If they're to add 2D support, it'll probably be a while. And it'll likely be something built using the 3D technology, unless they want to put in a lot of work to optimize for a 2D use.
Not even going to try it on principle. Amazon is a big tentacled octopus thats tightening its grasp over any and every area it can. Lets leave Amazon for ecommerce and AWS.
57.10 Acceptable Use; Safety-Critical Systems. Your use of the Lumberyard Materials must comply with the AWS Acceptable Use Policy. The Lumberyard Materials are not intended for use with life-critical or safety-critical systems, such as use in operation of medical equipment, automated transportation systems, autonomous vehicles, aircraft or air traffic control, nuclear facilities, manned spacecraft, or military use in connection with live combat. However, this restriction will not apply in the event of the occurrence (certified by the United States Centers for Disease Control or successor body) of a widespread viral infection transmitted via bites or contact with bodily fluids that causes human corpses to reanimate and seek to consume living human flesh, blood, brain or nerve tissue and is likely to result in the fall of organized civilization.